Gerçek Öğrenme Üreten Olay Sonrası Analizler (Postmortem)
- Suçlamasız çerçeve duygusal bir nezaket değil, operasyonel zorunluluktur; suçlama varsa mühendisler bilgiyi sansürler.
- Tek kök neden arayışı neredeyse her zaman yanlıştır. Gerçek vakalarda üst üste binen üç ila beş katkıda bulunan faktör vardır.
- Postmortem belgesinin içinde kalan aksiyon maddeleri asla yapılmaz; onları ürün işleriyle aynı backlog içinde takip edin.
- Çeyreklik çapraz olay incelemesi, tekil postmortem belgelerinin kaçırdığı sistemik örüntüleri ortaya çıkarır.
Neredeyse her mühendislik ekibinde aynı döngü tekrarlanır: bir kesinti yaşanır, nöbetçi mühendis sistemi ayağa kaldırır, birkaç gün sonra bir postmortem dokümanı yazılıp Slack’te paylaşılır ve üç ay sonra önceki postmortem’deki önleyici işler hiç yapılmadığı için benzer bir vaka tekrar yaşanır. Sorun dokümanın kendisi değil, davranış değişikliği yerine belge yazmayı nihai çıktı sanan süreçtir.
İşe yarayan bir postmortem üç şeyden birini değiştirir: hatayı mümkün kılan kodu/konfigürasyonu, tespiti veya kurtarmayı geciktiren süreci ya da ekibin sistemin nasıl çalıştığına dair ortak bilgisini.
Suçlamasız Çerçeve ve Katkıda Bulunan Faktörler
Suçlamasız (blameless) yaklaşım bir slogan değil, bilgi toplama zorunluluğudur. Masada suçlama veya performans değerlendirmesi riski varsa mühendisler hafızalarını seçici kullanır, edilgen cümleler kurar ve hataya yol açan karar zinciri görünmez olur. Gerçek test, bugün yanlış olduğu bilinen bir kararı veren mühendisin o anki mantığını çekinmeden anlatabilmesidir.
Ayrıca “tek kök neden” (root cause) kavramı gerçek sistemlerde nadiren geçerlidir. 2025’te incelediğimiz bir vakada üst üste binen beş faktör vardı: cuma öğleden sonra çalışan şema taşıma, 30 saniyeyi aşan tablo kilidi, nöbet devir saatindeki boşluk, üç ay eski runbook ve test edilmemiş manuel veritabanı geri alma adımı. Tek kök neden olarak “uzun süren migration” yazılsaydı diğer dört kırılganlık bir sonraki vakaya kadar bekleyecekti.
Ana Backlog Takibi ve Çeyreklik Çapraz İnceleme
Postmortem belgesinde kalan aksiyonların tamamlanma oranı sıfıra yakındır. Her aksiyon maddesi bir mühendis-haftadan küçük olmalı, tek bir sahibi bulunmalı ve ürün özellikleriyle aynı görev takip sistemine (Jira, Linear vb.) girmelidir.
En yüksek kaldıraçlı pratik ise her çeyrek sonunda son üç ayın tüm vakalarını 90 dakikalık bir oturumda yan yana okumaktır. Son beş vakanın üçünün saat 16:00 sonrası dağıtımlarda yaşandığını veya dördünün aynı alt bağımlılıktan kaynaklandığını tekil postmortem belgeleri değil, yalnızca bu çeyreklik çapraz inceleme ortaya çıkarır.
Sıkça sorulan sorular
Ekipteki herkes her postmortem belgesini görmeli mi?
Mühendislik ekibi için evet, ürün ve yönetim için duruma göre. Geniş görünürlük sistemin gerçekte nasıl kırıldığına dair ortak anlayış inşa eder. Yalnızca hassas müşteri verisi veya hukuki konular varsa özet bir genel sürüm paylaşın.
Bir postmortem dokümanı ne kadar uzun olmalı?
İki ila dört sayfa. Daha uzun belgeler okunmaz. Zaman çizelgesi, katkıda bulunan faktörler, müşteri etkisi, aksiyon maddeleri ve önleme notları formatını kullanın; karmaşık detayları ek olarak iliştirin.
Postmortem toplantısı ne zaman yapılmalı?
Olay çözüldükten sonraki 5 iş günü içinde. Daha erken yapılırsa ekip hala adrenalin etkisindedir; daha geç yapılırsa detaylar unutulur. 2. gün zaman çizelgesini netleştirin, 3-4. gün belgeyi yazın ve 5. gün incelemeyi yapın.