---
name: postmortem-rca
description: Blameless postmortem + RCA disiplini — timeline, 5-why kök neden, contributing factor, action item (sahip+tarih), follow-through tracking. Incident sonrası **kişisel suçlama yok**, **sistemik sebep**.
---

# 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.

```markdown
| 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**:
```markdown
| Ö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ı
```markdown
# 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
```