DevOps ve Yazılım Kalitesi

Olay Sonrası İnceleme: Suçlamasız Postmortem Kültürü Nasıl Kurulur?

InsureHub Ekibi
17 Ağustos 2026

Her yazılım ekibi er ya da geç bir kesinti, veri tutarsızlığı ya da beklenmedik bir hata yaşar. Bu anlarda iki farklı tepki verilebilir. Birincisi "Kim yaptı?" sorusuyla başlar ve genellikle bir kişinin hatasını bulmakla biter. İkincisi "Sistem buna nasıl izin verdi?" sorusuyla başlar ve aynı hatanın tekrar yaşanmasını zorlaştıran iyileştirmelerle sonuçlanır. Suçlamasız olay sonrası inceleme, yani postmortem, ikinci yaklaşımın yapılandırılmış hâlidir.

Neden suçlamasız?

Karmaşık sistemlerde hatalar nadiren tek bir kişinin dikkatsizliğinden kaynaklanır. Bir yapılandırma değişikliği yanlış ortama uygulanmışsa, asıl soru o değişikliğin neden bu kadar kolay yanlış ortama uygulanabildiğidir. Kişiler suçlandığında bilgi saklanmaya başlar; insanlar ne yaptıklarını ve neden yaptıklarını açıkça anlatmaktan çekinir. Oysa iyi bir inceleme, tam da bu açık anlatıma dayanır.

Suçlamasızlık sorumsuzluk anlamına gelmez. İnceleme yine somut aksiyonlar ve bu aksiyonların sahipleriyle biter; yalnızca odak, kişiden sisteme kayar.

Ne zaman postmortem yazılmalı?

Her küçük hata için kapsamlı bir belge yazmak ekibi yorar. Önceden belirlenmiş tetikleyiciler, ne zaman inceleme yapılacağını netleştirir:

  • Kullanıcıların temel bir işi yapamadığı, belirli bir süreyi aşan kesintiler,
  • Veri kaybı ya da veri tutarsızlığı içeren her olay,
  • Güvenlikle ilgili her olay,
  • Geri alma ya da manuel müdahale gerektiren yayınlar,
  • Ekibin "bundan öğrenecek çok şey var" dediği yakın kazalar.

İnceleme belgesinin bölümleri

Özet

Ne oldu, kimler etkilendi, ne kadar sürdü ve nasıl çözüldü? Teknik olmayan bir okuyucunun bile anlayabileceği birkaç cümle.

Zaman çizelgesi

Olayın başlangıcından çözümüne kadar dakika dakika ne yaşandığı. İlk belirtinin ne zaman ortaya çıktığı, ekibin ne zaman fark ettiği, hangi müdahalelerin denendiği ve hangisinin işe yaradığı. Zaman çizelgesi, fark etme süresi ile çözme süresi arasındaki farkı görünür kılar.

Etki

Hangi kullanıcı yolculukları etkilendi? Örneğin yalnızca kasko teklif akışı mı, yoksa trafik ve DASK sorguları da mı? Web paneli ile mobil uygulama aynı şekilde mi etkilendi? Etki tanımı ne kadar net olursa, kullanıcı iletişimi de o kadar doğru olur.

Katkıda bulunan etkenler

Tek bir kök neden aramak yerine, olayın oluşmasına katkıda bulunan birden fazla etkeni listelemek daha gerçekçidir. Bir test eksikliği, belirsiz bir el kitabı, gecikmeli bir uyarı ve yoğun bir yayın günü bir araya gelmiş olabilir.

İyi giden şeyler

Bu bölüm sıklıkla atlanır ama değerlidir. Hızlı çalışan geri alma mekanizması, doğru kişiye ulaşan bir uyarı ya da kullanıcıya zamanında yapılan bilgilendirme gibi korunması gereken uygulamalar burada kayda geçer.

Aksiyonlar

Her aksiyonun bir sahibi, bir hedef tarihi ve bir takip kaydı olmalıdır. "Daha dikkatli olacağız" bir aksiyon değildir. "Bu yapılandırma değişikliği için hazırlık ortamında otomatik doğrulama eklenecek" bir aksiyondur.

İnceleme toplantısını yönetmek

  1. Belge, toplantıdan önce olaya müdahale eden kişilerce taslak olarak hazırlanır.
  2. Toplantıyı olaya doğrudan dahil olmamış biri yönetir; bu tarafsızlığı artırır.
  3. Sorular "neden yaptın?" yerine "o anda elindeki bilgi neydi?" biçiminde sorulur.
  4. Aksiyonlar toplantı sonunda sahiplendirilir ve önceliklendirilir.
  5. Belge, ekibin tamamının erişebileceği bir yerde yayımlanır.

Aksiyonların takibi

Postmortem kültürünün en zayıf halkası, yazılan aksiyonların unutulmasıdır. Aksiyonları normal iş takip sistemine aktarmak, düzenli aralıklarla açık aksiyonları gözden geçirmek ve tamamlananları ilgili incelemeye bağlamak bu riski azaltır. Aynı türden olayların tekrarlanması, önceki aksiyonların gerçekten etkili olup olmadığını sorgulamak için bir işarettir.

Acentelerle iletişim

İç inceleme belgesi teknik ayrıntılar içerir; ancak acentelere yapılacak bilgilendirme sade ve dürüst olmalıdır. Ne olduğu, hangi işlemlerin etkilendiği, verinin durumu ve tekrarını önlemek için atılan adımlar açıkça paylaşılabilir. Bu şeffaflık, acente yazılımına duyulan güvenin uzun vadede korunmasına katkı sağlar. Özellikle CRM verisi gibi kritik bilgilerin etkilenip etkilenmediğinin net biçimde söylenmesi, acentenin kendi müşterilerine doğru bilgi verebilmesi için önemlidir.

Kültürün işaretleri

Postmortem kültürünün yerleştiğini gösteren birkaç işaret vardır: Ekip üyeleri kendi hatalarını gönüllü olarak paylaşır, yakın kazalar da incelenir, aksiyonlar tamamlanır ve yeni katılan bir geliştirici eski incelemeleri okuyarak sistemi tanır. Bu noktada incelemeler, cezalandırma aracı değil, kurumsal hafıza hâline gelmiştir.

Kurgusal bir örnek üzerinden zaman çizelgesi

Zaman çizelgesinin neden bu kadar önemli olduğunu kurgusal bir olayla görmek mümkündür. Bir sabah, yapılandırma değişikliğiyle birlikte bildirim servisinin bağlantı ayarı hatalı bir değere güncellenmiş olsun. Yenileme hatırlatmaları gönderilmemeye başlar; ancak kullanıcı ekranlarında hiçbir hata görünmez.

  • Değişiklik yayına alınır; otomatik testler geçer, çünkü testler bildirim gönderimini taklit eden bir servisle çalışmaktadır.
  • Bir süre sonra kuyruk uzunluğu metriği yükselmeye başlar, ancak bu metrik için bir uyarı tanımlı değildir.
  • Öğleden sonra bir acente, müşterisine hatırlatma gitmediğini destek ekibine bildirir.
  • Ekip sorunu bulur, ayarı düzeltir ve biriken hatırlatmaların kontrollü biçimde gönderilmesini sağlar.

Bu çizelge, sorunun birkaç dakikada çözüldüğünü ama saatlerce fark edilmediğini açıkça gösterir. Dolayısıyla en değerli aksiyonlar düzeltme değil, tespitle ilgilidir: kuyruk birikmesi için uyarı eklemek ve yapılandırma değişikliklerini hazırlık ortamında gerçek bağlantıyla doğrulamak.

Örnekte dikkat çeken bir diğer nokta, olayın hiçbir aşamasında tek bir kişinin hatasından söz edilmemesidir. Yapılandırmayı değiştiren geliştirici, o an elindeki bilgiyle makul bir işlem yapmıştır. İnceleme, bu makul işlemin neden fark edilmeden sorun yaratabildiğine odaklanır ve bu sayede kalıcı bir iyileştirme üretir.

Sonuç

Suçlamasız olay sonrası inceleme, yaşanan her sorunu sistemi güçlendirme fırsatına dönüştürür. Net bir zaman çizelgesi, birden çok katkı etkeninin dürüstçe listelenmesi ve takip edilen somut aksiyonlar, aynı hatanın ikinci kez yaşanma olasılığını belirgin biçimde azaltır.