Production’da kritik bir hata çıktı. 45 dakika etkilendik. Site down, checkout çalışmıyor, support kanallarında patlama. Ekip elinden geleni yapıp çözdü. Kahraman hissi var.
Ertesi gün ne yapıyorsunuz? Birçok ekip “halloldu, sıradaki iş” diyor. Bu postmortem yazmamak, aynı hatayı 6 ay sonra yine yapmanın garantisi.
15 incident postmortem yazdım son 3 yılda. Hiçbiri hoş bir deneyim değildi. Ama hepsinden sonra aynı hata tekrar etmedi. Bu yazıda pratik framework.
Postmortem’in amacı
Postmortem şunları yapıyor:
- Öğrenme: ne oldu, neden oldu, nasıl fark ettik, nasıl düzelttik
- Sistem görünürlüğü: gizli zayıflıklar artık kağıtta
- Team memory: 6 ay sonra yeni işe gelen kişi bu dokümanı okuyup bağlamı anlıyor
- Accountability without blame: kim ne yaptı ama kişiyi değil sistemi hedefliyor
Postmortem BRM (bug root cause) ile karıştırılıyor. BRM teknik. Postmortem teknik + organizational. Niye süreç bu incident’a izin verdi, niye tests yakalamadı, niye alarm geç geldi.
48 saat kuralı
Incident kapandıktan sonra 48 saat içinde postmortem draft hazır olmalı. Daha geç olursa:
– İnsanlar detayları unutuyor
– Enerji düşüyor, “artık geçti” hissi
– Yeni işler üstüne geliyor
48 saatte hot, rahat ama keskin.
Template
Kullandığım template:
# Incident Postmortem: [Özet Başlık]
**Date**: 2026-04-20
**Duration**: 45 dakika (14:22 - 15:07 TRT)
**Severity**: P1 (critical, checkout down)
**Author**: [isim]
**Status**: Draft / In Review / Final
## Özet
2-3 cümlede ne oldu, etki neydi, nasıl çözüldü.
## Kronolojik Akış
14:22 - PagerDuty alarm: checkout 500 error rate >%10
14:23 - On-call ack aldı
14:25 - Incident channel açıldı
14:32 - Kök neden tahmin edildi: recent deploy
14:40 - Rollback başlatıldı
14:45 - Hata azalma başladı
15:07 - Error rate %0, incident kapandı
## Etki
- X sipariş fail etti (revenue impact: ~$Y)
- Z kullanıcı hata sayfası gördü
- Support ekibine W ticket geldi
- SLA impact: ilk iki ayki 99.9% hedefinden %99.87'ye düştük
## Root Cause
[Teknik neden, en derin seviyede]
Bir deploy'da `orders` tablosuna migration yapıldı. Migration'da bir index drop edildi, yeni index production traffic altında create edildi. Index rebuild sırasında lock contention oluştu, `SELECT ... FOR UPDATE` query'leri queue oldu, connection pool doldu, API 500 döndü.
## 5 Whys
1. Neden checkout down oldu? → DB connection pool doldu
2. Neden connection pool doldu? → Query'ler queue oluyordu
3. Neden query'ler queue oluyordu? → Index rebuild lock tutuyordu
4. Neden index rebuild production traffic altında yapıldı? → Migration script'i online index creation kullanmamıştı
5. Neden migration review'da fark edilmedi? → Migration review checklist'inde online DDL kontrolü yoktu
## Ne iyi gittik
- Alarm hızlı geldi (2 dakika içinde)
- On-call ack hızlıydı (1 dakika)
- Incident channel ve communication net
- Rollback pattern hazırdı, 8 dakikada execute edildi
## Ne kötü gitti
- Migration review yetersizdi, breaking change prod'a gitti
- Staging'de aynı traffic pattern yok, sorun test'te yakalanmadı
- Rollback sırasında deploy history UI yavaştı, versioning unclear
- Customer communication geç kaldı (status page 12. dakikada güncellendi)
## Action Items
| Action | Owner | Due | Priority |
|--------|-------|-----|----------|
| Migration review checklist'e online DDL maddesini ekle | Ayşe | 2026-04-25 | P1 |
| Staging'de production traffic replay kurulumu | Burak | 2026-05-15 | P2 |
| Deploy UI'da version pinning görünürlüğü iyileştir | DevOps ekibi | 2026-05-30 | P2 |
| Status page auto-update (alarm'dan tetikleme) | Cem | 2026-05-10 | P1 |
## Lessons Learned
- Online DDL her zaman. Large table'da özellikle.
- Staging traffic replication olmadan production-only issue'lar sadece prod'da görülür.
- Auto-status-page update customer trust için kritik.Blameless dil
Postmortem’in en hassas kısmı dil. “Ali rollback’i geciktirdi” yerine “Rollback süresi 8 dakika sürdü çünkü deploy UI’sındaki version history aranması yavaş”. Kişi değil, sistem hedefleniyor.
Blameless dil değişiklikleri:
- “X kişi hata yaptı” → “Sistem X durumda yanlış yönlendirdi”
- “Niye farketmedin?” → “Farkedilmesini sağlayan sinyal yok muydu?”
- “Bunu yapmamalıydın” → “Bu aksiyonu desteklemek için daha iyi bir tool olabilir mi?”
Bu sadece kibarlık değil. Blame kültürü olan ekiplerde insanlar hata yaptığında saklıyor, postmortem’e gelmiyor, gerçek root cause görülmüyor.
Review meeting
Draft yazıldıktan sonra review meeting. Tipik 30-45 dakika.
Katılımcılar:
– Incident’ta involved olan herkes
– On-call rotation’dan eğitimli herkes
– Engineering manager
– (Büyük incident’larda) product + support
Meeting’de:
– Author draft’ı anlatır (5 dk)
– Kronolojik akış doğrulanır (5 dk)
– Root cause üzerinde uzlaşma (10 dk)
– Action item’ların owner ve due date’i netleştirilir (15 dk)
– Q&A (5 dk)
Meeting sonunda draft “In Review” → “Final” state’ine geçiyor.
Action item takibi
Postmortem yazıp aksiyon item tamamlanmıyorsa, bir sonraki incident aynı root cause’dan tekrar oluyor.
Pratik discipline:
– Action item’lar Jira/Linear’a ticket olarak giriyor
– Sprint planning’te P1 action item’lar ilk önce alınıyor
– Her ayın ilk engineering all-hands’inde geçmiş 90 gün action item completion rate rapor ediliyor
– %70’in altındaysa retrospective yapılıp neden kapanmıyor anlaşılıyor
Pattern arama
Tek incident postmortem = microscope. 10+ postmortem birikince pattern’lar ortaya çıkıyor:
- “Son 12 incident’ın 7’si deploy kaynaklı” → deploy pipeline’a yatırım
- “3 incident’ta on-call alarmı geç gördü” → PagerDuty konfigürasyon gözden geçirme
- “5 incident’ta root cause staging’de yakalanmadı” → staging environment investment
Quarterly incident review yapıyorum. Tüm postmortem’leri açıp pattern’ları çıkarıyorum. Sonuç engineering roadmap’e yön veriyor.
Küçük incident’lar
5 dakikalık minor outage için postmortem gerekli mi? Ben “lightweight postmortem” yapıyorum: 2 paragraf + 1 action item. Uzun template zorlaması overkill.
Ama 2 kere olan minor outage artık major pattern. İlk ikisini lightweight, üçüncüsünü full postmortem.
Paylaşım
Postmortem confidential değil, team-wide shared olmalı. Knowledge base’de, Notion’da, ortak bir yerde.
Bazı şirketler public postmortem yayımlıyor (Cloudflare, GitHub, Gitlab meşhur). Customer trust ile ilgili güçlü sinyal, ama şart değil. En azından internal’da açık olun.
Son not
Postmortem formalite değil, öğrenme pratiği. İyi yapıldığında aynı hata tekrarlanmıyor, ekip daha güvenli hissetmiyor, sistem her seferinde biraz daha rafine oluyor.
Kötü yapıldığında veya atlandığında ise sessiz bir teknik borç birikiyor. 6 ay sonra gelen yeni mühendis aynı bug’a çarptığında “bu zaten vardı” diyor kimse, çünkü kimse yazmamış. Kayıp kurumsal hafıza geri gelmiyor.