Postmortem
Kısaca
Postmortem, bir olaydan sonra yazılan; ne olduğunu, neden olduğunu ve tekrarlanmaması için ekibin neyi değiştireceğini açıklayan yazılı bir incelemedir.
Yazılım mühendisliğinde postmortem nedir?
Olay incelemesi (incident review) olarak da anılan postmortem, kesinti, veri kaybı ya da güvenlik ihlali gibi bir arızayı çözüldükten sonra analiz eden bir belge ve toplantıdır. Olayların zaman çizelgesini, kullanıcılar üzerindeki etkiyi, kök nedenleri ve katkıda bulunan faktörleri ve sahipleri olan bir eylem maddeleri listesini kaydeder. Amaç olaydan ders çıkarmaktır, suçlu aramak değil.
Çoğu ekip suçlayıcı olmayan bir yaklaşım izler: inceleme, insanların sahip oldukları bilgiyle makul davrandığını varsayar ve hatayı kimin yaptığını değil, sistemin hatayı neden kolaylaştırdığını sorar. Tipik bir postmortem birkaç gün içinde, anılar tazeyken yazılır ve kesin bir zaman çizelgesini yeniden kurmak için sohbet geçmişini, gösterge panellerini ve uyarıları kullanır. Sürekli neden diye sormak, yani beş neden (five whys) gibi teknikler, kötü bir yapılandırma değişikliği gibi ilk bariz nedenin ötesine geçip o değişiklik canlıya alınmadan önce otomatik kontrollerin olmaması gibi daha derin nedenlere ulaşmaya yardımcı olur.
Uygulama tıptan ve havacılıktan ödünç alınmıştır; oralarda araştırmacılar pilotu cezalandırmak için değil, herkes için güvenliği artırmak için her kazayı inceler. Yazılımda postmortem'ler site reliability engineering ve olay yönetiminin temel bir parçasıdır ve birçok şirket, müşterilerin neyin ters gittiğini görebilmesi için bunları yayınlar. Değerleri takibe bağlıdır: bir uyarı, bir test ya da daha güvenli bir dağıtım adımı eklemek gibi eylem maddeleri gerçekten izlenmeli ve tamamlanmalıdır.
Postmortem sıklıkla bir retrospektifle karıştırılır. Retrospektif, her sprint sonunda ekibin genel olarak nasıl çalıştığına dair rutin bir toplantıdır; postmortem ise belirli bir olayla tetiklenir ve o arızanın teknik ve kurumsal nedenlerine odaklanır. İkisi de gelişimi amaçlar, ancak postmortem tek bir olayın ayrıntılı yazılı kaydını üretir.
Önemli noktalar
- Postmortem, bir olayı çözüldükten sonra analiz eder ve öğrenilen dersleri kaydeder.
- Zaman çizelgesi, etki, kök nedenler, katkıda bulunan faktörler ve eylem maddelerini içerir.
- Suçlayıcı olmayan postmortem'ler bireylere değil, sistem ve süreç hatalarına odaklanır.
- Eylem maddelerinin sahipleri olmalı ve izlenmelidir; aksi halde aynı olay tekrarlanma eğilimindedir.
- Retrospektif düzenli işi, postmortem ise belirli bir olayı gözden geçirir.
Örnek
# Postmortem: checkout errors on 2026-09-12
## Summary
From 14:02 to 14:49 UTC, 38% of checkout requests failed.
## Impact
About 5,200 orders failed. No payment data was lost.
## Timeline (UTC)
- 14:02 Config change deployed; error alert fires at 14:06
- 14:31 Change identified as the cause and rolled back
## Root causes and contributing factors
## What went well, what went poorly
## Action items (owner, due date)Sık sorulan sorular
Suçlayıcı olmayan (blameless) postmortem ne demektir?
Suçlayıcı olmayan postmortem, son hatayı yapan kişiyi suçlamak yerine sistemlerdeki ve süreçlerdeki zayıflıkları arar. İnsanlar cezalandırılmaktan korkmadıklarında olanlar hakkında daha dürüst olur; bu da daha iyi düzeltmelere yol açar.
Bir ekip ne zaman postmortem yazmalıdır?
Çoğu ekip, kullanıcıları belirli bir eşiğin ötesinde etkileyen, veri kaybına yol açan, nöbetçi mühendislerin devreye girmesini gerektiren ya da çözülmesi beklenenden uzun süren her olay için postmortem yazar. Ramak kalan olayları incelemek de değerlidir, çünkü gerçek zarar vermeden önce sorunları ortaya çıkarırlar.
Postmortem ile retrospektif arasındaki fark nedir?
Retrospektif, genellikle her sprint sonunda yapılan ve ekibin nasıl çalıştığına dair düzenli bir toplantıdır. Postmortem ise belirli bir olaydan sonra yazılır ve olayın nedenlerini, etkisini ve tekrarlanmaması için gereken düzeltmeleri derinlemesine inceler.
İlgili sayfalar
- Site Reliability EngineeringDevOps ve Bulut, s. 48Site reliability engineering, operasyona yazılım mühendisliğini uygulayan ve hizmetleri otomasyon ile ölçülebilir hedeflerle güvenilir tutan bir disiplindir.
- RetrospektifEkipler ve Süreç, s. 20Retrospektif, ekibin her sprint sonunda nasıl çalıştığını değerlendirip bir dahaki sefer için somut iyileştirmelerde anlaştığı toplantıdır.
- SLODevOps ve Bulut, s. 50SLO, bir hizmetin ölçülebilir güvenilirlik hedefidir (örneğin 30 günde isteklerin %99,9'unun başarılı olması) ve yeterince güvenilirin ne olduğunu belirler.
- GözlemlenebilirlikDevOps ve Bulut, s. 22Gözlemlenebilirlik, çalışan bir yazılım sisteminin içinde olup biteni log, metrik ve trace verilerini toplayıp analiz ederek anlayabilme yeteneğidir.
- RollbackDevOps ve Bulut, s. 43Rollback, yeni bir dağıtım hatalara, kesintilere ya da beklenmedik başka sorunlara yol açtığında yazılımı önceki, sorunsuz sürüme döndürme işlemidir.
- DevOpsDevOps ve Bulut, s. 13DevOps, yazılım geliştirme ile BT operasyonlarını birleştirerek yazılımın daha hızlı ve güvenilir sunulmasını sağlayan bir kültür ve pratikler bütünüdür.
Bu sayfada bir hata ya da eksik mi gördünüz?Düzeltme önerin