postmortem-rca

Postmortem & RCA

Ortak Doktrin

agents/shared/severity-rubric.md ve agents/shared/escalation-matrix.md default-load sayılır (agents/coordination.md §11). Bu skill'in çıktısı Critical / High / Medium / Low + kanıt formatında olmak zorunda — spekülatif Critical yasak. Sahiplik dışı bulgu ilgili agent'a delege; karar yetkisi eşiği aşılırsa kullanıcı onayı zorunlu.

Ne Zaman Kullanılır

• Üretim incident'i sonrası (P0/P1/P2 — ekibin politika eşiği)
• Near-miss (etki olmadı ama "şanstan" — incident kadar değerli)
• Customer-impacting bug (uzun rollback, veri kaybı)
• Tekrarlayan incident (aynı tip 3. kez → daha derin RCA)
• Game-day / chaos drill sonrası (kontrollü ortam, prosedür gözden geçirme)

Felsefe — Blameless

• Kişiyi suçlama, sistemi sorgula. "Ali yanlış komutu girdi" → "Sistem yanlış komutu önlemeyen bir state'teydi".
• Hindsight bias yasak. Her aktör o anda elindeki bilgiyle "makul" karar verdi varsay; sonradan görünen "açık" hata değildir.
• Açıkça olanı ve sebebini ayır. What happened (timeline) ≠ Why it happened (RCA).
• 5 Why sistemik sebep'e zorlar; "people" değil "process/tool/architecture"a iner.
• Action item olmadan postmortem postmortem değil, hikaye.
• Follow-through action'ı kapatmadan postmortem kapanmaz.

Workflow

1) Bağlam topla

• Trigger: alert/page/customer report.
• Severity: P0 (full outage) / P1 (partial) / P2 (degraded).
• Detection: monitoring vs customer (customer = monitoring gap).
• Detection time (Tdet — first signal).
• Recovery time (Trec — incident closed).
• MTTD (Tdet - Tstart), MTTR (Trec - Tstart), MTBF (önceki incident'tan beri).
• Customer etki: count, %, duration, SLA breach var mı.

2) Timeline

Mutlak zaman (UTC), kim/ne, kanıt link.

| Zaman (UTC) | Kim | Aksiyon | Kanıt |
|---|---|---|---|
| 14:02 | Deploy bot | api-svc v1.4.2 canary 5% | gha run #1234 |
| 14:05 | Prom alert | error_rate{service="api"} > 0.05 | dashboard link |
| 14:06 | On-call ack | PD ack, Slack thread başladı | slack ts:... |
| 14:09 | On-call | rollback başlatıldı (helm rollback 0) | helm log |
| 14:14 | Recovery | error_rate normal'e döndü | dashboard |
| 14:18 | Incident closed | PagerDuty resolved | PD link |

Kurallar:

• Aksiyon seviyesi = "kim → komut → sonuç". "Ali bakındı" yetersiz.
• Kanıt link her satırda (Slack ts, dashboard, log query, gha run).
• "Bilinmiyor" zamanları boş bırakma; [unknown] yaz.

3) 5-Why (Kök neden)

Kural: Her cevap Why zincirine "people" değil "system" sokmaz. "Ali unutmuş" ilk cevap olabilir ama Why? "sistem hatırlatmadı" diye derinleşir.

Belirti: api-svc 5xx oranı %5 → %50, 4 dk
  Why? -> v1.4.2 deploy yeni endpoint'te 500 fırlatıyor
    Why? -> Yeni endpoint ENV var bekliyor, prod'da set değil
      Why? -> ConfigMap güncellemesi staging'de yapıldı, prod'da unutuldu
        Why? -> Deploy pipeline ConfigMap diff'i otomatik apply etmiyor
          Why? -> ArgoCD app-of-apps ConfigMap'i git'ten almıyor
                  (sealed-secrets workflow'u eksik)

Genellikle 5-why 3-7 katman. 5 mutlak değil; sistemik kök bulunca dur. Birden fazla "why" zinciri olabilir (multiple contributing factors).

4) Contributing factors

Tek "kök" yetersiz — incident'e katkıda bulunan diğer faktörler:

Kategori	Örnek
Process	Deploy onayı eksikti, change advisory bypass
Tooling	Alert eşik yüksek, monitoring blind spot
Architecture	Tek nokta failure, retry logic yok
Knowledge	Yeni feature dokümantasyon eksik
Resourcing	On-call tek kişiydi, escalation gecikti
Communication	Slack channel karışık, status page güncel değil
Time pressure	Release deadline gece, dikkat dağıldı

5) Customer impact

Metric	Değer
Etkilenen kullanıcı sayısı	12,450
Etkilenen istek sayısı	89,300 (toplam isteklerin %3.2'si)
Süre	14 dakika
SLA breach	Evet (99.9% aylık → 99.85%)
Veri kaybı	Yok / Var (detay)
Customer support ticket	47
Public communication	Status page + 2 tweet

6) Action Items

Format:

| Öncelik | Aksiyon | Sahip | Bitiş tarihi | Issue |
|---|---|---|---|---|
| P0 | ConfigMap diff'i ArgoCD'ye eklensin | @platform-team | 2026-05-14 | #1234 |
| P1 | Pre-deploy ENV var validation | @api-team | 2026-05-21 | #1235 |
| P2 | Deploy runbook'a ConfigMap check | @runbook-author | 2026-05-28 | #1236 |
| P2 | Alert eşik %3'e çekilsin | @observability | 2026-05-21 | #1237 |

Kurallar:

• Her action sahibi belli.
• Bitiş tarihi (vaat değil hedef).
• Issue açık (tracking yoksa "tamamlanmadı" sayılır).
• "Ekibi bilgilendir" action değil; bilgilendirme + dokümantasyon değişikliği action.
• "Daha dikkatli ol" action değil; kontrol mekanizması + otomasyon action.
• P0/P1 action 30 günü geçmesin (yoksa retro'da takip).

7) Follow-through

• Postmortem kapatma kriteri: tüm P0 action'lar kapandı.
• Haftalık postmortem review meeting: açık action listesi.
• 90 gün sonra same incident tekrar etti mi? kontrol — etti ise RCA yetersiz.

8) Yayın

• İnternal: tüm ekip okur (transparency).
• Customer-facing özet (varsa SLA breach): teknik detay yok, kullanıcı dilinde.
• Sektör/community paylaşımı (opsiyonel, learning).

Checklist

• Trigger + severity + detection (monitoring/customer)
• MTTD + MTTR + MTBF hesaplandı
• Timeline (UTC, kim/ne/kanıt) tamamlandı
• 5-why (sistemik köke iniş, "people" değil "system")
• Contributing factors (≥ 2 kategori)
• Customer impact (sayı + SLA)
• Action items (sahip + tarih + issue)
• Follow-through plan (tekrar kontrol 90 gün)
• Blameless dil (kişi suçlama yok)
• İnternal yayın
• Customer-facing özet (varsa)

Antipattern

• Blame: "Ali yanlış komutu girdi" — sistem hatasını gizler.
• Hindsight bias: "açıkça yanlış kararı seçtiler" — o anda bilgi farklıydı.
• 5-why erken durma: ilk "people" cevabıyla durmak.
• Action item yok: hikaye yazıldı, değişen bir şey yok.
• Sahipsiz action: "biri yapacak" → kimse yapmaz.
• Tarihsiz action: "yakında" → asla.
• Issue açılmamış action: tracking yok, kapanma yok.
• "Bir daha olmaz": kanıt yok, prosedür yok.
• Customer-facing özet teknik jargon: kullanıcı dilinde yaz.
• Postmortem kapanmadan benzer incident: RCA yetersiz, daha derin git.
• Yıl sonu retro yerine sıcak postmortem: 1 hafta içinde yaz, soğutma.
• Tek "root cause": genelde multiple contributing factors.

Örnek Agent Davranışı

User: /postmortem incident-2026-05-09
Agent (incident-commander):
1. PagerDuty + Slack thread + Prom dashboard'tan timeline çıkar.
2. Trigger: prom alert error_rate{service="api"} > 0.05; severity P1.
3. MTTD 3 dk (alert), MTTR 12 dk (rollback).
4. Customer impact: 12,450 user × 14 dk; SLA breach (99.9 → 99.85).
5. 5-why:
   - 5xx → yeni endpoint ENV var miss
   - ENV var miss → ConfigMap prod update unutuldu
   - Unutuldu → pipeline ConfigMap'i otomatik apply etmiyor
   - Etmiyor → ArgoCD app-of-apps eksik (sealed-secrets workflow yok)
6. Contributing factors: process (deploy onayı zayıf), tooling (alert eşik %5,
   2 dk geç tetiklendi), architecture (tek nokta).
7. Action items: 4 madde, sahip + tarih + issue.
8. Follow-through: 90 gün sonra "tekrar oldu mu?" kontrol; haftalık review.
9. Output: `templates/postmortem/postmortem.md` doldurulmuş hâli +
   `runbooks/postmortem-2026-05-09.md` yayın.
10. `runbook-author` delege: postmortem'in `runbooks/` altına yazımı.
11. Action item issue'ları açıldı (`gh issue create`).

Çıktı Formatı

# Postmortem: <incident-id>

## Özet (TL;DR — 3 cümle)

## Severity + Timeline
- Severity: P0/P1/P2
- MTTD / MTTR / MTBF
- Timeline tablosu

## 5-Why (Kök Neden)

## Contributing Factors

## Customer Impact

## Action Items
| Öncelik | Aksiyon | Sahip | Tarih | Issue |

## What Went Well
- (incident yönetimi pozitifleri — moral + öğrenme)

## What Could Have Gone Better
- (gelecekte nasıl daha iyi)

## Follow-Through
- 90 gün sonra kontrol tarihi