İlk 90 Günde Bir Dijital Ödeme Platformunu Nasıl Kontrol Altına Alırım?

--

BizOps Manager perspektifiyle gerçek bir senaryo

Press enter or click to view image in full size

Problem: 3 Olay, 1 Kök Neden

Bir ödeme platformunda işe başladığımı düşünelim.

İlk ayda üç kritik olay yaşanıyor:

• Production’da yanlış disk seçimi → veritabanı siliniyor
• Network tarafında erişim tamamen kayboluyor
• WAF sonrası memory leak → sistem destabilize oluyor

İlk bakışta bunlar ayrı problemler gibi görünüyor.

Ama aslında değil.

Bunlar aynı problemin farklı yansımaları.

Kontrolsüz operasyon.
Eksik değişiklik yönetimi.
Zayıf operasyon disiplini.

Teşhis: Sistem Çalışıyor Ama Kontrol Altında Değil

Bu platformda asıl sorun teknik değil.

Sistem çalışıyor. Ama güvenli değil.

Kontrol mekanizmaları yoksa:

• veri kaybı olur
• erişim kaybı olur
• incident’lar tekrar eder

Ve bu sadece zaman meselesidir.

Kök Neden

Bu üç olayın ortak noktası:

• Change governance eksik
• Production access kontrolsüz
• Observability yetersiz
• Acil durum senaryosu yok

Yani problem:
“teknoloji” değil, “operasyonel kontrol eksikliği”

⚠Öncelik Sırası

Her şeyi aynı anda çözmem.

Öncelik net:

1. Veri kaybı (P0)
2. Erişilebilirlik (P1)
3. Stabilite (P2)
4. Optimizasyon (P3)

Önce geri dönüşü olmayan riski kapatırım.

Faz 1: İlk 30 Gün — Stabilizasyon

Amaç: Kontrolsüz operasyonu durdurmak

Change Control

• Tüm production değişiklikleri çift onaylı
• rollback zorunlu
• change window tanımlı

kontrol yoksa risk vardır

Backup & Recovery

• restore testleri yapılır
• RTO / RPO netleştirilir
• point-in-time recovery kurulur

backup varsa yetmez
çalıştığını bilmelisin

Access Continuity

• out-of-band erişim kurulur
• emergency access tanımlanır
• runbook yazılır

sistem çökerse kör kalmamalısın

Incident Modeli

• Sev1–Sev3 sınıflandırma
• war room
• 72 saat içinde RCA

incident çözülür
ama asıl hedef: tekrar etmemesi

Faz 2: 30–60 Gün — Görünürlük

Amaç: Sistemi anlamak

DR Readiness

• failover test edilir
• DB consistency kontrol edilir

Test edilmeyen DR, DR değildir

Monitoring

• latency
• transaction success rate
• error pattern

Görünmeyen riski yönetemezsin

SLO / SLA

• SLA = müşteriye söz
• SLO = iç hedef

error budget ile disiplin sağlanır

Release Disiplini

• pre-prod zorunlu
• canary release
• feature flag

kontrolsüz deploy = risk

Faz 3: 60–90 Gün — Dayanıklılık

Amaç: Proaktif yapı kurmak

Otomasyon

• deploy / rollback otomatik
• manuel hata azalır

Stres & Chaos Testleri

• sistem kontrollü zorlanır
• sınırlar ölçülür

sürpriz production’da yaşanmaz

Risk Yönetimi

Senaryolar:

• replication lag
• sertifika expiry
• kapasite tıkanması
• vendor kesintisi

her biri için:

• runbook
• test planı

Organizasyon: BizOps Gerçekte Ne Yapar?

BizOps bir “yapıcı” rol değildir; bağlayıcı roldür

• Engineering ↔ Compliance
• DevOps ↔ Business
• Güvenlik ↔ Vendor

Rol Tanımı

İşi yapmak değil, doğru yapılmasını sağlamak

• ownership BizOps’ta
• execution dağıtılmış

Ritim

Haftalık:

• Ops review
• Risk review
• Aksiyon takibi

ownership yoksa yönetim yoktur

Maliyet vs Risk

İlk refleks:

❌ tool almak
✔ süreç kurmak

Yaklaşım

• önce boşlukları gör
• sonra yatırım yap

Gerçek

Tek bir P0 incident:

• ceza
• müşteri kaybı
• operasyon yükü

toplam maliyet = tüm yatırımlardan fazla

Sonuç

Bu plan maliyet değil, sigorta primidir

Başarı Kriterleri

90 gün sonunda:

• MTTR < 2 saat
• Change failure rate < %5
• DR testleri doğrulanmış
• runbook hazır

sistem:

• çalışır ✔
• ölçülür ✔
• yönetilir ✔

Bu planın amacı:

• sadece incident çözmek değil
• incident oluşmayacak bir yapı kurmak