Bir değişiklik planı ne kadar iyi görünürse görünsün, üretimde her şey “planlandığı gibi” gitmez. Asıl sorun, değişiklikten sonra çıkan hatalar değil; hata çıktığında ekibin ne kadar hızlı ve doğru tepki verdiğidir. Bu yüzden ben kritik değişikliklerde “postmortem” kadar “pre‑mortem” disiplinini de önemserim.
Pre‑mortem’in amacı basit: “Değişiklik başarısız oldu” varsayımıyla, hatayı ve etkisini önceden zihinde yaşayıp riskleri görünür kılmak.
Pre‑mortem ne zaman yapılmalı?
Her deploy için toplantı yapmak sürdürülemez. Pre‑mortem’i şu tip değişikliklerde kullan:
- Hata alanı geniş: platform, ağ, kimlik, loglama, DNS gibi ortak katmanlar
- Geri dönüş zor: veri şeması, stateful servis, güvenlik politikası
- İlk kez yapılıyor: yeni teknoloji/sağlayıcı/operasyon modeli
- Üretim erişimi / yetki değişimi içeriyor
30 dakikalık pratik akış
Ben pre‑mortem’i 30 dakikaya sığdırmaya çalışırım:
- Hedef (3 dk): Bu değişiklik hangi iş etkisini hedefliyor?
- “Başarısız oldu” senaryosu (10 dk): Hangi 3 şekilde kötü biter?
- Erken sinyaller (7 dk): Hangi metrik/log/alert bunu ilk yakalar?
- Geri dönüş (7 dk): 1) otomatik 2) manuel 3) “dur ve izole et”
- Karar noktaları (3 dk): Hangi eşikte rollback zorunlu?
Şablon: her değişiklik için aynı sorular
Ben şu soruları sabit kullanırım:
- Blast radius: En kötü durumda etki alanı ne?
- Bağımlılıklar: Hangi servis/katman sessizce etkilenir?
- Gözlem: Başarıyı ve bozulmayı hangi sinyal gösterir?
- Yetki: Kim rollback yapabilir? Break-glass var mı?
- Veri: Geri dönüşte veri tutarlılığı riski var mı?
- Zaman: Süreçte clock skew / TTL / cache etkisi var mı?
- İletişim: Kimin hangi kanalda bilgilendirileceği net mi?
Bu sorular “doküman üretmek” için değil, kararları hızlandırmak için vardır.
Pre‑mortem çıktısı nasıl kullanılmalı?
En iyi çıktılar:
- Değişiklik RFC’sine eklenen “risk ve geri dönüş” bölümü
- Runbook’a eklenen karar noktaları (eşik + aksiyon)
- Alarm/observability eksiklerinin kapatılması (deploy öncesi)
En kötü çıktı: toplantı yapıp hiçbir yere yazmamak.
Liderlik tarafı: pre‑mortem bir güven inşasıdır
Pre‑mortem, “ekibe güvenmiyorum” mesajı değildir; aksine ekip üzerinde baskı kurmadan güvenli hız üretmenin yoludur. İyi bir lider; riskleri saklamaz, görünür kılar. Çünkü üretimde asıl hız, hatayı erken yakalayıp doğru geri dönebilme kabiliyetidir.
Kapanış
Üretimde mükemmel plan yoktur; ama iyi hazırlanmış geri dönüş vardır. Pre‑mortem; değişiklik öncesi küçük bir yatırım, değişiklik sonrası büyük bir zaman kazancıdır. Disiplinli uygulandığında ekip “cesur” değil, kontrollü olur.