Tue Sep 29 2026
Merhaba! 👋
Ben de senin gibi bir geliştiriciyim ve son yıllarda gizlilik konusunda yaşadığım bir hikâye anlatayım.
Geçen yıl bir SaaS projesinde hızlıca bir çözüm entegre ettik. İki ay sonra bir denetim geldi ve logs’larda kişisel veri sızıntısı tespit edildi. Sonuç? Yasal para cezası + müşteri kaybı. O gün anladım ki: “Hangi aracı seçtiğin, projenin ömrünü belirler.”
Hadi birlikte doğru gizlilik yazılımını nasıl seçeceğimizi keşfedelim! 🚀
RoPA (İşleme Faaliyetleri Kayıtları), KVKK’nın 30. maddesi uyarınca her veri sorumlusunun tutmak zorunda olduğu bir evrak çerçevesidir.
Kısaca: “Hangi veriyi, neden, kimle, ne kadar süre işlediğimi” kanıtlayabileceğimiz bir defter.
| Zorunlu Alan | Açıklama |
|---|---|
| veri_sorumlusu | Şirket/kurum unvanı, iletişim bilgileri, temsilci (varsa) |
| isleme_amaci | Neden işleniyor? (ör. “Müşteri destek”, “Pazarlama e-postası”) |
| veri_kategorileri | Kişisel veri, özel kategori veri, biyometrik veri vb. |
| saklama_suresi | Kaç yıl/ay saklanacak, sonrasında nasıl yok edilecek |
| veri_alicilari | Üçüncü taraf servisler, bulut sağlayıcılar, avukatlar |
| uluslararasi_transfer | Veri AB dışına çıkıyor mu? Hangi mekanizma (SCC, BCR…) |
| guvenlik_onlemleri | Şifreleme, erişim kontrolü, loglama vb. |
Pratik ipucu: Otomatik güncelleme tetikleyicileri (trigger) koyarak, yeni bir işlem eklendiğinde veya mevcut bir işlem değiştiğinde RoPA kaydının yeniden üretilmesini sağlayabilirsin.
Örn: Yeni bir mikro servis “Kullanıcı analitiği” deploy edildi → CI/CD pipeline’ındaropa-updatejob’u tetiklenir → JSON kaydı otomatik yenilenir ✅
{
"veri_sorumlusu": {
"unvan": "Acme Teknoloji A.Ş.",
"iletisim": "privacy@acme.com",
"temsilci": "Ayşe Yılmaz"
},
"isleme_amaci": "Müşteri destek taleplerinin yönetimi",
"veri_kategorileri": [
"Kişisel veri",
"İletişim bilgileri"
],
"saklama_suresi": "3 yıl",
"veri_alicilari": [
"Zendesk",
"AWS (EU Frankfurt)"
],
"uluslararasi_transfer": false,
"guvenlik_onlemleri": [
"AES-256 şifreleme",
"RBAC erişim kontrolü",
"Yıllık penetrasyon testi"
]
}
Bu sayede her yeni özellik veya işlem değişikliği olduğunda geliştirici eliyle Excel doldurmak yerine, pipeline’dan çıkan bu JSON doğrudan RoPA veritabanına yazılır. Hem hata riski düşer hem de denetime “hazır” gidersin 🚀
DPIA (Veri Koruma Etki Değerlendirmesi) — KVKK ve GDPR'da "yüksek risk" varsa mecburidir 🎯. Ama ne zaman "yüksek risk" diyoruz? Kısaca:
Kural basit: Şüphe varsa DPIA yap. Ceza riskini almak yerine 2-3 saatlik bir değerlendirme çok daha ucuzdur 💸.
| Adım | Manuel mı? | Otomatikleştirilebilir mi? |
|---|---|---|
| Veri akışı haritalama | ❌ | ✅ (kod analizi / OpenAPI spec'ten) |
| Risk matrisi oluşturma | ⚠️ Kısmen | ✅ (kural motoru + skorlama) |
| Azaltma önlemleri önerme | ⚠️ Kısmen | ✅ (önceden tanımlı kontrol kütüphanesi) |
| Onay akışı (DPO → Yasal → Yönetim) | ❌ | ✅ (workflow motoru) |
| Rapor / kayıt tutma | ❌ | ✅ (şablon + e-imza + versiyonlama) |
İpucu: Risk matrisini kod olarak (YAML/JSON) tutarsanız, CI/CD'ye gömülür, her deploy öncesi "DPIA geçerli mi?" kontrolü yaparsınız ✅.
Hadi pratik bir akış üzerinden gidelim 👇
Tetikleme
Yeni bir mikro servis / feature branch pushlandığında dpia-check job'u devreye girer.
Veri Envanteri Toplama
@pii, @sensitive annotation'ları aranırRisk Skoru Hesaplama
Her veri alanı için:
skor = hassaslık_katsayısı × hacim_katsayısı × erişim_şiddeti
Toplam skor eşik değerini (ör. 70/100) geçerse → DPIA zorunlu ⛔️
Azaltma Önlemleri Eşleştirme
| Risk | Önerilen Kontrol |
|---|---|
| Biyometrik veri | Şifreleme + erişim loglama + 30 gün auto-silme |
| Profil oluşturma | Opt-out mekanizması + açıklama metni |
| Üçüncü taraf paylaşımı | DPA imzası + veri minimizasyonu |
Onay Akışı
Dokümanlaştırma & Dashboard
Sonuç: DPIA-2025-001.pdf + canlı dashboard 👇
| Bileşen | Açıklama |
|---|---|
| Genel Skor | 0–100 arası, renkli daire (yeşil/sarı/kırmızı) 🟢🟡🔴 |
| Risk Isı Haritası | Veri seti × işlem matrisi → hangi kombinasyon en riskli? |
| Trend Çizgisi | Son 6 ayda skor nasıl değişti? (yeni feature eklendiğinde artar mı?) |
| Açık Bulgular | Onay bekleyen, reddedilmiş, uygulanmamış önlemler listesi |
| Export | Tek tıkla PDF / Excel / Confluence sayfası |
Bonus: Dashboard'da "Bu servis için DPIA yenileme tarihi: 2025-11-15" uyarısı otomatik çıkarsa, unutma ihtimali sıfırlanır 🔔.
# .github/workflows/dpia-check.yml
name: DPIA Otomatik Değerlendirme
on:
pull_request:
types: [opened, synchronize, reopened]
paths:
- 'services/**/openapi.yaml'
- 'services/**/dpia-config.yaml'
jobs:
dpia-investigation:
name: 🔍 Veri Envanteri & Tetikleme
runs-on: ubuntu-latest
outputs:
requires_dpia: ${{ steps.check.outputs.requires_dpia }}
risk_score: ${{ steps.score.outputs.total }}
steps:
- uses: actions/checkout@v4
- name: OpenAPI'den PII alanlarını çıkar
id: extract
run: |
python scripts/extract_pii.py \
--spec services/${{ matrix.service }}/openapi.yaml \
--config services/${{ matrix.service }}/dpia-config.yaml \
--output pii_inventory.json
- name: Risk skoru hesapla
id: score
run: |
python scripts/risk_score.py \
--inventory pii_inventory.json \
--threshold 70 \
--output risk_result.json
echo "total=$(jq -r .total risk_result.json)" >> $GITHUB_OUTPUT
echo "requires_dpia=$(jq -r .requires_dpia risk_result.json)" >> $GITHUB_OUTPUT
risk-assessment:
name: ⚖️ Risk Değerlendirme & Önlem Eşleştirme
needs: dpia-investigation
if: needs.dpia-investigation.outputs.requires_dpia == 'true'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Azaltma önlemlerini öner
run: |
python scripts/suggest_controls.py \
--risk-score ${{ needs.dpia-investigation.outputs.risk_score }} \
--inventory pii_inventory.json \
--output mitigation_plan.yaml
- name: Mitigasyon planını artifact olarak kaydet
uses: actions/upload-artifact@v4
with:
name: dpia-mitigation-${{ github.run_id }}
path: mitigation_plan.yaml
approval-flow:
name: ✍️ Onay Akışı (DPO → Hukuk → Yönetim)
needs: risk-assessment
runs-on: ubuntu-latest
environment: dpia-approval
steps:
- name: DPO onayı bekle
uses: actions/github-script@v7
with:
script: |
const { data: reviews } = await github.rest.pulls.listReviews({
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: context.payload.pull_request.number
})
const dpoApproved = reviews.some(r =>
r.user.login === 'dpo-bot' && r.state === 'APPROVED'
)
if (!dpoApproved) {
core.setFailed('DPO onayı bekliyor...')
}
- name: Hukuk onayı bekle
# benzer mantık, legal-team reviewer kontrolü
- name: Yönetim onayı (eşik > 85 ise zorunlu)
if: needs.dpia-investigation.outputs.risk_score > 85
# management approver kontrolü
documentation:
name: 📄 DPIA Raporu Oluştur & Arşivle
needs: [dpia-investigation, risk-assessment, approval-flow]
if: always() && needs.approval-flow.result == 'success'
runs-on: ubuntu-latest
steps:
- uses: actions/download-artifact@v4
with:
name: dpia-mitigation-${{ github.run_id }}
- name: PDF rapor üret
run: |
python scripts/generate_report.py \
--inventory pii_inventory.json \
--mitigation mitigation_plan.yaml \
--score ${{ needs.dpia-investigation.outputs.risk_score }} \
--output DPIA-${{ github.event.repository.name }}-${{ github.run_number }}.pdf
- name: Confluence'e / S3'e yükle
run: |
aws s3 cp DPIA-*.pdf s3://our-dpia-archive/ --metadata \
service=${{ matrix.service }},score=${{ needs.dpia-investigation.outputs.risk_score }},date=$(date -I)
- name: PR'ye özet yorum bırak
uses: actions/github-script@v7
with:
script: |
github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.payload.pull_request.number,
body: `✅ **DPIA Tamamlandı**\n- Risk Skoru: ${{ needs.dpia-investigation.outputs.risk_score }}/100\n- Rapor: \`DPIA-${{ github.event.repository.name }}-${{ github.run_number }}.pdf\`\n- Sonraki gözden geçirme: ${{ fromNow(365*24*60*60*1000) }}`
})
Küçük bir başlangıç: dpia-config.yaml dosyasını her servise ekleyin, annotation'ları (@pii, @retention) kodunuza serpin. Gerisi pipeline halleder 🚀.
Veri nereden geliyor, nereye gidiyor, ortada ne oluyor? 🤔 Bu sorulara cevap veremiyorsanız, GDPR uyumluluğu zaten riske girmiş demektir. Veri haritalama (data mapping) tam da bu noktada devreye girer — bir nevi verinizin GPS'i gibidir 📍.
Modern araçlar şu kaynakları tarayıp haritalayabilir:
İpucu: Elle Excel'de tutulan haritalar güncellenmez, unutulur, hata yaparsınız. Otomatik keşif (auto-discovery) tek çözümdür 🤖.
Mermaid.js ile basit, okunabilir bir veri akışı:
flowchart LR
A[📱 Mobil Uygulama] -->|Kullanıcı verisi<br/>(JSON/HTTPS)| B[🔐 API Gateway]
B --> C[⚙️ İşleme Servisi<br/>(Kubernetes Pod)]
C --> D[(🗄️ PostgreSQL<br/>Kullanıcı Tablosu)]
C --> E[☁️ AWS S3<br/>Yedek/Log]
C --> F[📧 SendGrid API<br/>E-posta Gönderimi]
D --> G[📊 Veri Ambarı<br/>(Redshift/BigQuery)]
E --> G
F --> H[📈 Analitik Dashboard]
G --> H
style A fill:#e1f5fe
style D fill:#fff3e0
style E fill:#fff3e0
style F fill:#f3e5f5
style G fill:#e8f5e9
style H fill:#fce4ec
Ne oluyor burada? 👆
Bu şema canlıdır — bir tablo eklendiğinde, yeni bir mikro servis deploy edildiğinde, harita otomatik güncellenir 🔄.
Denetim günü geldi, müşteri veri haritası istedi, yasal ekip "veri akış şeması" dedi... Eski yöntem: haftalarca toplantı, screenshots, Word dosyası 😵💫.
Yeni yöntem: Araç arayüzünde "Dışa Aktar" butonuna basarsınız. Çıktı formatları:
Gerçek hayattan: Son denetimde 40 saatinizi alan raporlama, 3 dakika sürdü. Müşteri "nasıl yaptınız?" diye sordu, biz de "bir tık" dedik 😎.
| Özellik | Neden Önemli? |
|---|---|
| Otomatik keşif | İnsan hatasını ortadan kaldırır, eksik kaynak kalmaz |
| Canlı harita | Sistem değiştiğinde harita da değişir — asla "eski" kalmaz |
| Görsel akış | Teknik/teknik olmayan paydaşlar aynı dili konuşur |
| Bir tık dışa aktar | Denetim, müşteri talebi, iç raporlama — hepsi dakikalar |
Son söz: Veri haritalası bir "yapıp bitireceğiniz" iş değil, sürekli yaşayan bir üründür 🌱. Doğru araçla bu ürünü otomatikleştirin, gece rahat uyuyun 😴.
Yasal düzenlemeler (ör. GDPR 2026 revizyonları) aniden devreye girdiğinde, politikalarımızın otomatik güncellenmesi ve ilgili ekiplerin anında haberdar edilmesi hayati önem taşır 🎯.
| Olay | Aksiyon |
|---|---|
newArticleAdded |
Politika şablonunu güncelle |
templateUpdated |
Onay akışını tetikle |
approvalRequested |
İlgili kanallara bildirim gönder |
// 📦 Olay türleri
type PolicyEvent =
| { type: 'newArticleAdded'; article: Article }
| { type: 'templateUpdated'; templateId: string }
| { type: 'approvalRequested'; reviewers: string[] };
// 🛠 Merkezi event bus (basit bir in‑memory implementasyon)
class EventBus {
private listeners: Map<string, Function[]> = new Map();
subscribe(event: string, handler: Function) {
const arr = this.listeners.get(event) ?? [];
arr.push(handler);
this.listeners.set(event, arr);
}
publish(event: PolicyEvent) {
const handlers = this.listeners.get(event.type) ?? [];
handlers.forEach((h) => h(event));
}
}
// 🚀 Kural motoru – her olay için ne yapılacağını tanımlar
class PolicyEngine {
constructor(private bus: EventBus) {
this.registerRules();
}
private registerRules() {
// 1️⃣ Yeni madde geldi → şablonu güncelle
this.bus.subscribe('newArticleAdded', async (e: PolicyEvent) => {
if (e.type !== 'newArticleAdded') return;
await this.updateTemplate(e.article);
this.bus.publish({ type: 'templateUpdated', templateId: 'privacy-policy' });
});
// 2️⃣ Şablon güncellendi → onay akışını başlat
this.bus.subscribe('templateUpdated', async (e: PolicyEvent) => {
if (e.type !== 'templateUpdated') return;
const reviewers = ['legal', 'security', 'product'];
this.bus.publish({ type: 'approvalRequested', reviewers });
});
// 3️⃣ Onay istendi → bildirim gönder
this.bus.subscribe('approvalRequested', async (e: PolicyEvent) => {
if (e.type !== 'approvalRequested') return;
await this.notifyReviewers(e.reviewers);
});
}
// 📝 Şablon güncelleme mantığı (pseudo)
private async updateTemplate(article: Article) {
console.log(`🔧 Şablon güncelleniyor: ${article.title}`);
// Gerçek implementasyonda: DB'ye yaz, versiyonla, diff üret…
}
// 📣 Bildirim gönderimi (e‑posta / Slack / Teams)
private async notifyReviewers(reviewers: string[]) {
for (const role of reviewers) {
console.log(`📩 ${role} ekibine onay isteği gönderildi`);
// await sendEmail(role); await postToSlack(role); await postToTeams(role);
}
}
}
// 🎬 Kullanım örneği
const bus = new EventBus();
const engine = new PolicyEngine(bus);
// Simülasyon: Resmi gazetten yeni madde geldi
bus.publish({
type: 'newArticleAdded',
article: { id: 'art-2026-01', title: 'Veri taşıma kısıtlamaları' }
});
Hazırsan bir sonraki kriterde gerçek zamanlı uyumluluk dashboard’una geçelim 🚀.
Hazırsan bu kısımda mevcut teknoloji yığınına nasıl sorunsuz bağlanabileceğimizi, API’lerimizi nasıl tasarladığımızı ve bir “Hello World” webhook örneğiyle pratik bir akış göstereceğim 🚀
| Araç / Platform | Nasıl entegre ediyoruz? |
|---|---|
| GitHub Actions | Workflow dosyalarında jobs.<job_id>.steps içinde curl veya resmi SDK kullanarak RoPA API’larını tetikliyoruz. |
| GitLab CI | .gitlab-ci.yml içindeki script: kısmında aynı cURL komutları veya docker run ile CLI aracımızı çağırıyoruz. |
| Kubernetes | CronJob veya Deployment içinden sidecar container olarak webhook listener çalıştırıyor; Service Mesh (Istio/Linkerd) üzerinden mTLS ile güvenli iletişim sağlıyoruz. |
| Diğer CI/CD (CircleCI, Azure Pipelines, vb.) | Tümünde standart REST uç noktalarımız ve GraphQL şemamız olduğu için sadece endpoint + token yeterli. |
İpucu: Tüm pipeline’larda secret olarak
ROPA_API_TOKENsaklayın, loglarda görünmesin ✅
REST
POST /api/ropa → Yeni RoPA kaydı oluşturGET /api/ropa/:id → Kayıt detayıPATCH /api/ropa/:id → Kısmi güncellemeDELETE /api/ropa/:id → Kayıt silGraphQL (tek endpoint /graphql)
mutation CreateRopa($input: RopaInput!) {
createRopa(input: $input) {
id
name
status
}
}
Bu sayede frontend/mobil takımlar tek istekle ihtiyaç duydukları alanları çekebiliyor 🎯
Güvenlik için her webhook payload’ına HMAC‑SHA256 imzası ekliyoruz.
# Sunucu tarafı (Node.js örneği)
const crypto = require('crypto')
const secret = process.env.WEBHOOK_SECRET
const signature = crypto
.createHmac('sha256', secret)
.update(JSON.stringify(payload))
.digest('hex')
// Header: X-Ropa-Signature: sha256=<signature>
İstemci tarafında (CI/CD, kendi servisiniz) aynı secret ile imzayı hesaplayıp X-Ropa-Signature header’ı ile karşılaştırın. Eşleşmiyorsa reddet ⛔
| Dil | Paket | Kurulum |
|---|---|---|
| Node.js | @ropa/sdk |
npm i @ropa/sdk |
| Python | ropa-sdk |
pip install ropa-sdk |
| Go | github.com/ropa/go-sdk |
go get github.com/ropa/go-sdk |
SDK’lar token yönetimi, retry/backoff, tip güvenliği (TypeScript/Python typings) sunar; kodunuzda sadece:
import { RopaClient } from '@ropa/sdk'
const client = new RopaClient({ token: process.env.ROPA_API_TOKEN })
await client.ropa.create({ name: 'Yeni Kayıt', category: 'HR' })
Senaryo: GitHub Actions’da bir push olduğunda, webhook payload’ını alıp RoPA’da ilgili kaydın lastDeployedAt alanını güncelliyoruz.
// server.js
app.post('/webhook/deploy', verifySignature, async (req, res) => {
const { repository, head_commit } = req.body
await ropaClient.ropa.update(repository.name, {
lastDeployedAt: new Date(head_commit.timestamp).toISOString()
})
res.sendStatus(204)
})
# .github/workflows/deploy.yml
name: Deploy & Notify RoPA
on:
push:
branches: [main]
jobs:
notify-ropa:
runs-on: ubuntu-latest
steps:
- name: RoPA’ya bildir
run: |
curl -X POST "https://api.ropa.example.com/api/ropa/${{ github.repository }}" \
-H "Authorization: Bearer ${{ secrets.ROPA_API_TOKEN }}" \
-H "Content-Type: application/json" \
-d '{"lastDeployedAt":"'"$(date -u +"%Y-%m-%dT%H:%M:%SZ")"'"}'
Ne oluyor burada?
pushtetiklendiğinde workflow çalışır.cURLile PATCH (veyaPOSTupsert) isteği atarız.- RoPA kaydımız anında güncellenir, takip panolarında “Son dağıtım” saati görünür ✅
curl -X POST "https://api.ropa.example.com/api/ropa" \
-H "Authorization: Bearer ${ROPA_API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"name": "Maaş Hesaplama Süreci",
"category": "HR",
"description": "Aylık maaş bordrosu üretimi",
"dataSubjects": ["Çalışan", "Muhasebe"],
"legalBasis": "İş sözleşmesi",
"retentionPeriodDays": 3650
}'
Çıktı örneği
{
"id": "ropa_1G2H3J4K5L",
"name": "Maaş Hesaplama Süreci",
"status": "ACTIVE",
"createdAt": "2025-07-18T12:34:56.789Z"
}
Bu kadar basit! 🎉 Artık CI/CD pipeline’ınızdan, mikro servislerinizden veya manuel bir terminalden RoPA yönetimini tam otomatik hale getirebilirsiniz.
Özet:
curl/sdk çağrısı yeterliBir sonraki kriterde gözlemlenebilirlik & loglama konusuna geçeceğiz 👀
Hazırsan güvenlik katmanlarını tek tek inceleyelim 🎯. Bir mikro hizmet yığını tasarlarken veri bekleyen ve veri yoldaki şifreleme, kimlerin ne yapabileceğini belirleyen erişim modelleri ve merkezi loglama olmazsa olmazdır.
| Model | Ne Zaman Kullanılır? | Avantaj |
|---|---|---|
| RBAC | Roller net ve değişmiyorsa (ör. admin, viewer) |
Basit, denetimi kolay |
| ABAC | Özelliklere (zaman, konum, veri sınıfı) göre karar verilmeliyse | Esnek, ince taneli politika |
Her iki modelde de least‑privilege prensibi uygulanır; varsayılan reddet kuralı aktif olur.
timestamp, service, traceId, userId, action, result.Aşağıdaki docker-compose.yaml parçası, PostgreSQL (veri bekleyen şifreleme için pgcrypto eklentisi ve disk şifreleme varsayımı) ve Fluentd log aggregator’ı bir arada ayağa kaldırır. Gerçek ortamda POSTGRES_PASSWORD ve şifreleme anahtarları Vault’tan çekilmelidir.
version: '3.8'
services:
db:
image: postgres:15
environment:
POSTGRES_DB: appdb
POSTGRES_USER: appuser
POSTGRES_PASSWORD: ${DB_PASSWORD} # .env veya Vault'tan gelir
# pgcrypto eklentisi ile sütun bazlı AES‑256 şifreleme aktif edilebilir
volumes:
- db_data:/var/lib/postgresql/data # Disk şifreleme (LUKS / cloud encrypted volume) önerilir
networks:
- secure-net
deploy:
resources:
limits:
cpus: '0.5'
memory: 512M
fluentd:
image: fluent/fluentd:v1.16-1
volumes:
- ./fluentd/conf:/fluentd/etc # fluent.conf: <source> @type forward … </source>
- /var/log/containers:/var/log/containers # Konteyner loglarını merkezi toplar
ports:
- "24224:24224"
- "24224:24224/udp"
networks:
- secure-net
depends_on:
- db
networks:
secure-net:
driver: bridge
# İsteğe bağlı: network policy ile sadece db↔fluentd iletişimine izin ver
volumes:
db_data:
driver: local
# driver_opts ile encrypted volume (ör. AWS EBS encryption) tanımlanabilir
Bu sayede ne oluyor?
secure-net bridge ile izole edilir; ileride NetworkPolicy / mTLS ekleyerek sıfır güven (zero‑trust) modeline geçiş yapabilirsiniz 🔁.Özet: Şifreleme, erişim kontrolü, merkezi loglama ve denetim izleri bir arada düşünülüp kodda, altyapıda ve süreçlerde uygulanınca, hem SOC 2/ISO 27001 gibi standartları karşılarsınız hem de müşterinizin verisini “gizlilik tasarımı” felsefesiyle korursunuz 🚀.
Hazırsan bu kriteri bir kahve molası gibi hızlıca çözelim ☕️. Maliyet modeli, ürününüzün nasıl büyüyeceğini ve müşterilerinizin ne kadar ödeyeceğini belirleyen kalp atışıdır. İki ana yaklaşım var:
| Durum | Tercih Edilen Model | Neden? |
|---|---|---|
| Küçük startup, hızlı deneme | Abonelik (Starter paketi) | Düşük giriş maliyeti, bütçe planlaması kolay ✅ |
| Değişken trafik, mevsimsel yük | Kullanım başına ödeme | Sadece ne kadar kullanırsan ödersin ⛔ |
| Enterprise, SLA garantisi | Abonelik + özel SLA | Öncelikli destek, uptime garantisi 🛠 |
| Özellik | Starter (Startup) | Growth (Ölçeklenen) | Enterprise (Büyük müşteri) |
|---|---|---|---|
| Kullanıcı sayısı | ≤ 5 | ≤ 50 | Sınırsız |
| Veri hacmi (GB/ay) | 10 | 200 | Sınırsız |
| Destek | E‑posta (iş günleri) | Öncelikli e‑posta + canlı sohbet | 7/7 telefon + özel SLA |
| Fiyat (aylık) | $49 | $199 | Özel fiyatlandırma |
| Özelleştirme | Temel şablonlar | Modül seçimi, API erişimi | Tam beyaz etiket, özel entegrasyonlar |
Ne oluyor burada?
- Starter: MVP’yi test eden küçük ekipler için “başlangıç paketi”. Düşük maliyet, hızlı onboarding.
- Growth: Kullanıcı tabanı büyüdükçe veri ve destek ihtiyacı artar; plan bu ihtiyakları karşılar.
- Enterprise: Kurumsal sözleşmeler, SLA, compliance ve dedicated support gerektiren müşteriler için “özel paket”.
| Plan | Aylık Maliyet | Tahmini Yıllık Kazanç (örnek) | ROI (Yıl) | Not |
|---|---|---|---|---|
| Starter | $49 | $12 000 | ≈ 20× | Düşük risk, hızlı doğrulama |
| Growth | $199 | $85 000 | ≈ 35× | Ölçeklenebilirlik artar |
| Enterprise | Özel | $500 000+ | Değişken | SLA, compliance, özel geliştirme dahil |
Özetle:
Hadi bu tabloyu takip ettikçe maliyet‑fayda dengenizi sürekli gözden geçirin; böylece hem müşteriniz hem de siz kazanırsınız ✅.
Hazırsan bu kriteri birlikte inceleyelim 🎯. Bir ürünün gerçek değerini anlamak için sadece özellik listesine bakmak yetmez; müşterinin günlük akışında nasıl hissettiği kritik.
| Özellik | Neden Önemli? |
|---|---|
| 7/24 canlı sohbet | Acil sorunlarda bekleme süresini sıfırlar. |
| Özel CSM ataması | Stratejik hesaplarda proaktif denetim, yol haritası hizalaması ve quarterly business review (QBR) sağlar. |
| Otomatik ticket routing | Sorun türüne göre doğru ekibe (destek, mühendislik, güvenlik) yönlendirme. |
Onboarding sihirbazı
Hata ayıklama modu (debug mode)
debug=true query param veya dashboard toggle.email: ***@***.com).İpucu: Ürün demosunu veya deneme sürecini bir “pilot projesi” gibi planla. Gerçek bir kullanım senaryosu (ör. günlük 10k istek) ile test edersen, üretimdeki sürprizleri minimize edersin.
Bir sonraki kriterde “Güvenlik ve Uyumluluk” konusuna geçeceğiz. Görüşmek üzere! 🚀
Hazırsan bu kısımda konuşulan 8 kriteri tek bir kontrol listesi (checklist) halinde toplayalım 🎯
Kopyala-yapıştır, doldur, ekip paylaş — işte o kadar basit.
Her kriter için şu alanları dolduracaksın:
| Alan | Açıklama |
|---|---|
| kriter | Kriterin kısa adı (örn. "Güvenlik") |
| aciklama | Ne kontrol ediliyor? |
| durum | evet / hayir / kismi |
| oncelik | yuksek / orta / dusuk |
| not | Serbest metin: detay, ticket linki, sorumlu kişi vb. |
💡 İpucu:
durumalanındakismikullan — "biraz yapıldı ama eksik" durumları için tam gefallenir.
Aşağıdaki dosyayı degerlendirme-sablonu.json olarak kaydet, doldur, versiyon kontrolüne at 👇
{
"proje": "Örnek Proje Adı",
"tarih": "2024-01-15",
"degerlendiren": "Ad Soyad / Takım",
"versiyon": "1.0",
"kriterler": [
{
"id": 1,
"kriter": "Güvenlik",
"aciklama": "Kimlik doğrulama, yetkilendirme, veri şifreleme, bağımlılık tarama",
"durum": "kismi",
"oncelik": "yuksek",
"not": "OAuth2 entegrasyonu tamam, secret rotation henüz yok. #SEC-123"
},
{
"id": 2,
"kriter": "Performans",
"aciklama": "Yanıt süreleri, veritabanı sorguları, önbellek stratejisi, yük testleri",
"durum": "evet",
"oncelik": "yuksek",
"not": "p95 < 200ms. k6 ile 10k VU testi geçti."
},
{
"id": 3,
"kriter": "Gözlenebilirlik",
"aciklama": "Loglama, metrikler, tracing, alarmlar, dashboard'lar",
"durum": "hayir",
"oncelik": "orta",
"not": "Distributed tracing eksik. OpenTelemetry entegrasyonu planlandı. #OBS-45"
},
{
"id": 4,
"kriter": "Test Kapsamı",
"aciklama": "Birim, entegrasyon, e2e, contract testleri; CI'de zorunlu koşma",
"durum": "kismi",
"oncelik": "yuksek",
"not": "Unit %78, integration %42. E2E testleri flaky. #QA-88"
},
{
"id": 5,
"kriter": "Kod Kalitesi",
"aciklama": "Static analysis, lint, format, complexity, code review süreci",
"durum": "evet",
"oncelik": "orta",
"not": "SonarCloud quality gate geçiyor. PR'lar en az 1 approve zorunlu."
},
{
"id": 6,
"kriter": "Dağıtım & Çevreler",
"aciklama": "CI/CD pipeline, blue-green/canary, rollback, environment parity",
"durum": "evet",
"oncelik": "yuksek",
"not": "ArgoCD ile GitOps. Canary %10 -> %100 otomatik. Rollback < 2dk."
},
{
"id": 7,
"kriter": "Belgeleme",
"aciklama": "API dokümantasyonu, README, mimari kararlar (ADR), runbook'lar",
"durum": "kismi",
"oncelik": "dusuk",
"not": "OpenAPI spec var. ADR'ler eksik. Runbook sadece prod için."
},
{
"id": 8,
"kriter": "Operasyonel Hazırlık",
"aciklama": "Backup/restore, disaster recovery, capacity planning, on-call süreci",
"durum": "hayir",
"oncelik": "yuksek",
"not": "DR test edilmedi. RPO/RTO tanımlı değil. #OPS-200"
}
],
"ozet": {
"toplam": 8,
"evet": 3,
"kismi": 3,
"hayir": 2,
"yuksek_oncelikli_eksik": 3
}
}
evet = tam karşılanıyor, hayir = hiç yok, kismi = ilerleme var ama eksikyuksek = hemen aksiyon, orta = sprint içinde, dusuk = backlogdegerlendirme-sablonu.json olarak kaydetkriterler[].aciklama alanlarını özelleştirozet alanını script ile otomatik güncelle (küçük bir Node/Python betiği yetmez mi?)Ne oluyor burada?
Artık "gözlemler" Excel'de kaybolmuyor. Versiyonlu, sorgulanabilir, CI/CD'ye entegre edilebilir bir mühendislik artıkkanı oluşturdun 🛠
Bir sonraki bölümde bu JSON'u nasıl CI pipeline'ına kanca atarsın, görelim istersen 😉
Arkadaşlar, bu yazının da sonuna geldik. Kısa bir özetle geçeyim: doğru yazılımı seçmek sadece bir teknoloji kararı değil — riski azaltır, zaman kazandırır ve ekibinizle müşterileriniz arasında güven oluşturur ✅
Bunu bir alışkanlık haline getirin, dert etmez 👇
Küçük bir ipucu: Bu takvimi ekip takviminize "Gizlilik Sağlığı Kontrolü" ismiyle ekleyin. Görünür olsun, unutulmasın 👀
Bu süreçlerde hangi zorluklarla karşılaştınız? Hangi araçlar size kolaylık sağladı? Yorumlarda deneyimlerinizi paylaşırsanız hepimiz birbirimizden öğreniriz 🤝
Hadi, güvenli ve şeffaf yazılımlarla dolu bir geleceğe! 🚀
Bu içerik tamamen yapay zeka destekli otomasyon sistemi ile üretilmiştir.
All rights reserved