Bir sunucu çöktüğünde, bir veri merkezi bağlantısı kesildiğinde ya da kritik bir servis saatlerce erişilemez hale geldiğinde, sorun çözüldükten sonra iş bitmiş sayılmaz. Asıl önemli adım, o kesintiden ne öğrenildiğinin sistemli biçimde kayıt altına alınmasıdır. Bu doküman genellikle "postmortem" olarak adlandırılır ve sistem yöneticileri ile teknik ekip liderleri için kesinti yönetimi sürecinin belki de en çok ihmal edilen ama en değerli parçasıdır.
Bir bakışta
- Postmortem, kesinti sonrası kök nedeni bulup tekrarını önlemek için hazırlanan yapılandırılmış bir rapordur.
- Suçlamadan uzak kültür, ekip üyelerinin olayı saklamadan dürüstçe anlatmasını sağlar.
- Zaman çizelgesi, etki analizi, kök neden ve somut aksiyon maddeleri raporun temel adımlarıdır.
Postmortem Nedir, Neden Önemlidir?
Postmortem, bir kesinti veya ciddi arıza sonrasında hazırlanan; olayın nasıl geliştiğini, neden yaşandığını ve tekrarını önlemek için ne yapılacağını anlatan yapılandırılmış bir rapordur. Amaç bir suçlu bulmak değildir. Amaç, sistemde, süreçte veya iletişimde nerede bir zayıflık olduğunu ortaya çıkarıp bunu düzeltmektir.
Bu ayrım kağıt üzerinde kolay görünse de uygulamada zordur. Bir ekip üyesi hatalı bir komut çalıştırdıysa, raporun odağı "kim yaptı" değil "bu komutun bu kadar kolay çalıştırılabilmesini hangi kontrol eksikliği mümkün kıldı" olmalıdır. Bu yaklaşıma genellikle "suçlamadan uzak" (blameless) postmortem kültürü denir. Ekip üyeleri, hata yaptıklarında cezalandırılmayacaklarını bildiklerinde, olayı olduğu gibi anlatmaktan çekinmezler. Suçlayıcı bir ortamda ise insanlar detayları saklama, sorumluluğu başkasına yükleme veya olayı olduğundan hafif gösterme eğilimine girer — bu da bir sonraki kesintide aynı hatanın tekrarlanma ihtimalini artırır.
Postmortem yazılmadığında ya da yüzeysel geçildiğinde, ekipler genellikle aynı kesintiyi farklı bir tetikleyiciyle tekrar yaşar. Kök neden düzeltilmediği sürece, sorun farklı bir kılıkla geri döner.
Ne Zaman ve Kim Tarafından Yazılmalı?
Postmortem süreci, kesinti çözüldükten sonra mümkün olan en kısa sürede başlamalıdır — ideal olarak birkaç gün içinde. Detaylar hafızalarda tazeyken toplanan bilgi, haftalar sonra hatırlanmaya çalışılan bilgiden çok daha güvenilirdir. En yaygın hatalardan biri, "işler sakinleşince yazarız" diyerek süreci ertelemektir; bu ertelemenin sonucu genellikle log kayıtlarına bakılarak tahmini bir zaman çizelgesi kurmak zorunda kalmaktır.
Rapora şu kişilerin dahil olması beklenir:
- Olaya doğrudan müdahale eden teknik ekip üyeleri
- Etkilenen sistemlerin sahipleri (örneğin ağ altyapısından veya yedekleme sisteminden sorumlu kişiler)
- Gerekirse, iş etkisini değerlendirebilecek yöneticiler
Sürecin dağınıklaşmaması için bir kişinin "rapor sahibi" olarak belirlenmesi önerilir. Bu kişi yazının tamamını tek başına yazmak zorunda değildir; görevi, bilgi toplama sürecini koordine etmek, taslağı bir araya getirmek ve aksiyon maddelerinin takip edilmesini sağlamaktır.
Adım 1: Doğru ve Eksiksiz Bir Zaman Çizelgesi Oluşturma
Postmortem'in omurgası, olayın dakika dakika (mümkünse) anlatıldığı zaman çizelgesidir. Bu çizelge en az şu noktaları içermelidir:
- Sorunun gerçekte ne zaman başladığı (bu, fark edilme anından farklı olabilir)
- İzleme araçlarının veya uyarı mekanizmalarının olayı ilk ne zaman tespit ettiği
- Ekibin müdahaleye ne zaman başladığı
- Uygulanan geçici veya kalıcı çözüm adımları
- Sistemin ne zaman tamamen normale döndüğü
İzleme sisteminin tespit anı özellikle önemlidir çünkü "sorun başlangıcı" ile "fark edilme anı" arasındaki süre, uyarı eşiklerinin ne kadar isabetli çalıştığını gösteren somut bir göstergedir. Bu süre uzunsa, ilerleyen aksiyon maddelerinde izleme yapılandırmasının gözden geçirilmesi gerekebilir.
Zaman çizelgesi oluşturulurken log kayıtları, uyarı geçmişi ve ekip içi iletişim kanallarındaki (sohbet uygulamaları, olay yönetim araçları) mesaj geçmişi taranmalıdır. Burada dikkat edilmesi gereken kritik nokta şudur: çizelgeye yalnızca doğrulanabilir bilgiler yazılmalıdır. "Muhtemelen şu sırada olmuştur" gibi varsayımlar, ayrı bir bölümde açıkça varsayım olarak işaretlenmeli, zaman çizelgesindeki kesin olgularla karıştırılmamalıdır.
Adım 2: Etkiyi Objektif Şekilde Tanımlama
Kesintinin etkisi, abartılmadan ve küçümsenmeden, elde bulunan verilerle anlatılmalıdır. Mümkünse şu sorular yanıtlanmalıdır:
- Kaç kullanıcı veya hangi oranda kullanıcı etkilendi?
- Hangi servisler veya bileşenler kesintiden doğrudan etkilendi, hangileri etkilenmedi?
- Varsa SLA (hizmet seviyesi taahhüdü) ihlali yaşandı mı?
Eğer kesin rakamlar elinizde yoksa, bunları uydurmak yerine etkiyi niteliksel olarak tarif etmek daha doğrudur — örneğin "giriş yapan kullanıcıların önemli bir kısmı belirli işlemleri tamamlayamadı" gibi. Gelir kaybı veya itibar etkisi gibi konularda da somut veri yoksa bu bölüm ["kaynak gerekli"] şeklinde işaretlenebilir ya da niteliksel olarak ele alınabilir. Amaç, elinizdeki gerçek veriyi net sunmak, spekülasyonu asgariye indirmektir.
Etkinin sınırlarının açıkça çizilmesi de önemlidir: hangi servisler etkilendi, hangileri kesintiden bağımsız kaldı? Bu netlik, hem okuyucunun olayı doğru ölçekte değerlendirmesini sağlar hem de ilerleyen kök neden analizinin kapsamını belirler.
Adım 3: Kök Neden Analizi – Yüzeysel Nedeni Asıl Nedenden Ayırmak
Bu, postmortem'in en kritik ve genellikle en çok atlanan aşamasıdır. İlk bakışta görülen tetikleyici genellikle asıl sorun değildir. "Bir sunucu çöktü" cümlesi bir açıklama değil, sadece olayın yüzeyidir. Asıl soru şudur: o sunucu neden çöktü, çökmesi neden fark edilmedi, çökmesinin sistem genelinde bu kadar büyük bir etkiye yol açmasına ne izin verdi?
Bu noktada "5 Neden" gibi genel yaklaşımlar faydalı bir çerçeve sunar. Yöntem basittir: bir sorunun nedeni bulunduğunda, "peki bu neden oldu?" sorusu tekrar tekrar sorulur, ta ki sistemsel bir zayıflığa ulaşılana kadar. Örneğin:
- Servis çöktü → Bellek tükendi
- Bellek neden tükendi? → Bir işlem bellek sızıntısı yapıyordu
- Sızıntı neden fark edilmedi? → Bellek kullanımı için uyarı eşiği tanımlanmamıştı
- Eşik neden tanımlanmamıştı? → İzleme yapılandırması yeni servisler için standart bir kontrol listesine dahil edilmemişti
Bu örnekte gerçek kök neden, "bellek sızıntısı" değil, "yeni servislerin izleme sürecine standart biçimde dahil edilmemesi"dir. Beşinci soruya ulaşmak zorunlu değildir; önemli olan yüzeysel belirtiden sistemsel nedene inebilmektir.
Ayrıca genellikle tek bir neden yeterli açıklamayı sağlamaz. Çoğu ciddi kesintinin ardında birden fazla katkıda bulunan faktör bulunur: bir teknik hata, bir izleme eksikliği, belirsiz bir sorumluluk dağılımı veya eksik bir iletişim adımı bir arada gerçekleşir. Kök neden analizi yalnızca teknik bileşenlere değil, süreç ve iletişim boyutuna da bakmalıdır.
Adım 4: Alınan Aksiyonları Somutlaştırma
Postmortem'in en somut çıktısı aksiyon maddeleridir. "İzlemeyi iyileştireceğiz" gibi genel iyi niyet ifadeleri pratikte hiçbir şey değiştirmez çünkü ölçülebilir değildir ve kimseye ait değildir. Her aksiyon maddesi şu üç unsuru içermelidir:
- Net ve ölçülebilir bir hedef (örneğin belirli bir metrik için uyarı eşiği tanımlamak)
- Bir sahip (hangi kişi veya ekip sorumlu)
- Gerçekçi bir tamamlanma tarihi
Aksiyonlar ayrıca kısa vadeli ve uzun vadeli olarak ikiye ayrılmalıdır. Kısa vadeli aksiyonlar genellikle geçici bir çözümü kalıcı hale getirmeye yöneliktir (örneğin manuel olarak yeniden başlatılan bir servisi otomatik yeniden başlatma mekanizmasına bağlamak). Uzun vadeli aksiyonlar ise yapısal iyileştirmelerdir — mimari değişiklik, kapasite planlamasının gözden geçirilmesi, yedekleme stratejisinin güncellenmesi gibi.
Aksiyonlar mümkün olduğunca ilgili alanlarla ilişkilendirilmelidir: izleme araçlarında yeni bir uyarı kuralı, ağ altyapısında bir yedeklilik iyileştirmesi, yedekleme sıklığında bir revizyon gibi. Bu ilişkilendirme, aksiyonun hangi ekip veya sistemin sorumluluk alanına girdiğini netleştirir.
Adım 5: Raporu Paylaşma ve Şeffaflık
Postmortem yazıldıktan sonra bir çekmecede kalmamalıdır. İlgili teknik ekiplerle, gerekiyorsa yönetimle paylaşılmalı; başka ekiplerin benzer bir hatadan kaçınabilmesi için erişilebilir bir yerde tutulmalıdır.
Eğer kesinti müşterileri etkilediyse, uygun düzeyde bir özet müşterilerle de paylaşılabilir. Bu özet, iç raporun teknik ayrıntılarını içermek zorunda değildir; olayın ne olduğunu, ne kadar sürdüğünü ve tekrarını önlemek için neler yapıldığını sade bir dille anlatması yeterlidir. Aşırı teknik jargon, hem iç paydaşlar hem de müşteriler için raporun anlaşılırlığını azaltır.
Şeffaflığın burada oynadığı rol küçümsenmemelidir. Ekip içinde açık paylaşım, gelecekteki olaylarda insanların çekinmeden bilgi vermesini teşvik eder. Müşteriyle paylaşılan açık bir özet ise, kesintinin kendisinden çok daha fazla, olaya nasıl yaklaşıldığı konusunda güven inşa eder.
Postmortem'in Kesinti Yönetimi Sürecine Geri Beslenmesi
Postmortem tek seferlik bir belge değil, kesinti yönetimi döngüsünün bir parçası olarak düşünülmelidir. Çıkan dersler, olay müdahale planlarına ve çalışma kitaplarına (runbook) işlenmelidir; böylece bir sonraki benzer olayda ekip aynı adımları sıfırdan keşfetmek zorunda kalmaz.
İzleme ve uyarı sistemlerinde yapılan güncellemeler, bir sonraki olayı daha erken yakalamayı sağlar — bu da zaman çizelgesindeki "tespit anı" ile "başlangıç anı" arasındaki farkı azaltır. Benzer şekilde, postmortem'de ortaya çıkan kapasite sınırlamaları veya performans darboğazları, kapasite planlama ve performans testi süreçlerine girdi olarak aktarılmalıdır.
Bunun gerçekleşmesi için aksiyon maddelerinin düzenli olarak gözden geçirilmesi gerekir. Aksi halde, özenle hazırlanmış bir rapor bile zamanla anlamını yitirir ve aynı kök nedenler bir sonraki kesintide tekrar karşımıza çıkar.
Sık Yapılan Hatalar ve Bunlardan Kaçınma Yolları
Postmortem sürecinde en sık karşılaşılan tuzaklar şunlardır:
- Çok geç yazmak: Detaylar zamanla bulanıklaşır, zaman çizelgesi eksik veya hatalı kurulur.
- Aşırı teknik detaya boğulmak: Rapor, sistemin her bir log satırını açıklamaya çalışırken asıl öğrenilmesi gereken sistemsel dersi gözden kaçırabilir. Teknik detay gerektiğinde eklenmeli, ancak ana anlatının önüne geçmemelidir.
- Aksiyonların takip edilmemesi: Aksiyon maddeleri belirlenip sonra unutulursa, postmortem yalnızca sembolik bir egzersize dönüşür.
- Suçlayıcı dil kullanmak: "X kişisi hata yaptı" gibi ifadeler, ekip içi güveni zedeler ve gelecekte insanların olayları eksiksiz paylaşma isteğini azaltır. Odak her zaman "sistem bunu neden mümkün kıldı" olmalıdır, "kim yaptı" değil.
Bu hatalardan kaçınmak, postmortem'i bürokratik bir formaliteden çıkarıp gerçek bir öğrenme ve iyileştirme aracına dönüştürür — ki asıl amaç da budur.
