[SEV] Kısa Açıklama ve Tarih

1) İlkeler ve kültür

Suçsuz. Hata, bir kişinin değil, sistemin bir özelliğidir. Biz "neden oldu'diye bakıyoruz," suçlu kim'diye değil.
Gerçekler ve değişmezler. Tüm çıktılar zaman çizelgesi, SLO, izler ve günlüklere dayanmaktadır.
Şirket içinde tanıtım. Toplamlar ve dersler ilgili ekipler tarafından kullanılabilir.
Eylemler protokollerden daha önemlidir. Değişmeyen belge ≡ kayıp zaman.
Hızlı yayıncılık. Taslak ölüm sonrası - olaydan sonraki 48-72 saat içinde.

2) Taksonomi ve olay kriterleri

• SEV1 - tam erişilemezlik/para/veri kaybı;
• SEV2 - önemli bozulma (hatalar> SLO, p99 dışında);
• SEV3 - kısmi bozulma/geçici çözüm var.
• Etki: etkilenen bölgeler/kiracılar/ürünler, süre, iş metrikleri (dönüşüm, GMV, ödeme hatası).
• SLO/hatalı bütçe: ne kadar bütçenin tükendiği, sürümlerin ve deneylerin hızını nasıl etkilediği.

3) Olay rolleri ve süreci

Olay Komutanı (IC): Süreci yönetir, adımları önceliklendirir, sahipleri atar.
İletişim Lideri: Paydaşları/müşterileri bir şablon üzerinde bilgilendirir.
Ops/On-call: tasfiye, hafifletici eylemler.
Scribe: Zaman çizelgesini ve eserleri korur.
Konu Uzmanları (KOBİ): derin teşhis.

Aşamalar: Tespit - eskalasyon - stabilizasyon - doğrulama - restorasyon - postmorty - iyileştirmelerin tanıtımı.

4) Ölüm sonrası şablon (yapı)

5) RCA Techniques (Root Cause Search)

5 Why - sequential clarification of causes to the system level.
Ishikawa (fish bone) - factors "People/Processes/Tools/Materials/Environment/Dimensions."
Event-Chain/Ripple - a chain of events with probabilities and triggers.
Barrier Analysis - which "fuses" (timeouts, breakers, quotas, tests) were supposed to stop the incident and why they did not work.
Change Correlation - correlation with releases, config digs, feature flags, provider incidents.

Practice: Avoid "root cause = person/one bug." Look for a system combination (debt + lack of guard rails + irrelevant runbooks).

6) Communications and transparency

Internal: single channel (war-room), short updates according to the template: status → actions → ETA of the next update.
External: status page/newsletter with facts without "guilt," with apologies and an action plan.
Sensitivity: do not disclose PD/secrets; legal wording to be agreed.
After the incident: a summary note with human language and a link to a technical report.

External update template (brief):
"31 Oct 2025, 13:40 UTC - some users encountered payment errors (up to 18 minutes). The reason is the degradation of the dependent service. We turned on bypass mode and restored operation at 13:58 UTC. Apologies. Within 72 hours, we will publish a report with actions to prevent recurrence"

7) Actions and implementation management

Each action is owner, deadline, acceptance criteria, risk and priority relationship.
Action classes:
1. Engineering: timeout budgets, jitter retreats, breakers, bulkheads, backprescher, stability/chaos tests.
2. Observability: SLI/SLO, alert guards, saturation, traces, steady-state dashboards.
3. Process: runbook update, on-call workouts, game day, CI gates, bipartisan review for risky changes.
4. Architecture: cache with coalescing, outbox/saga, idempotency, limiters/shading.
Gates: releases fail unless "post-mortem critical actions" are closed (Policy as Code).
Verification: retest (chaos/load) confirms the elimination of the risk.

8) Integration of feedback

Sources:
Telemetry: p99/p99 tails. 9, error-rate, queue depth, CDC lag, retray budget.
VoC/Support: topics of calls, CSAT/NPS, churn signals, "pain points."
Product/Analytics: user behavior, failure/friction, drop-off in funnels.
Partners/Integrators: webhook failures, contract incompatibility, SLA timing.

Signal → decision loop:
1. The signal is classified (severity/cost/frequency).
2. An architectural ticket is created with a hypothesis and the price of the problem.
3. Falls into the engineering portfolio (quarterly/monthly), ranked by ROI and risk.
4. Execute → measure effect → update SLI/SLO/cost baselines.

9) Post-mortem maturity metrics

% postmortems published ≤ 72 h (target ≥ 90%).
Average "lead time" from incident to closure of key actions.
Reopen rate of actions (quality of DoD formulations).
Repeated incidents for the same reason (target → 0).
Proportion of incidents caught by guards (breaker/limiter/timeouts) vs "breakthrough."
Saturation of dashboards (SLI covering critical paths) and "noise" of alerts.
Share of game-day/chaos scenarios that simulate detected failure classes.

10) Example of postmortem (summary)

Event: SEV2. Payment API: up p99 to 1. 8s, 3% 5xx, 31 Oct 2025 (13:22–13:58 UTC).
Impact: 12% of payment attempts with retrays, part - cancellation. Erroneous budget q4: − 7%.
Root Cause: "slow success" of currency dependence (p95 + 400 ms), retrai without jitter → cascade.
Barrier failure: the breaker is configured only for 5xx, not for timeouts; there was no rate-cap for low priority.
What worked: hand shading and stale-rates feature flag.
Actions:
Enter timeout budget and jitter retrays (DoD: p99 <400 ms at + 300 ms to dependency).
Breaker for "slow success" and fallback stale data ≤ 15 minutes.
Update runbook "slow dependency," add chaos script.
Add dashboard "served-stale share" and alert at> 10%.
Enter release-gate: without passing chaos-smoke - prohibit release.

11) Artifact patterns

11. 1 Timeline (example)

13: 22:10 Uyarı p99> 800ms (ağ geçidi)

13: 24:00 IC atanmış, savaş odası açık

13: 27:30 para-api "yavaş başarı" tanımlandı

13: 30:15 Ficha-flag bayat-oranlar ON (%10 trafik)

13: 41:00 Bayatlama oranları %100, p99 290ms stabilize

13: 52:40 Retreas'ı Ağ Geçidine Sınırlamak

13: 58:00 Olay kapatıldı, izleme 30 dakika

11. 2 Solutions and Validation (DoD)

Çözüm: enable breaker (slow_success)

DoD: chaos script "+ 300ms to currency" - p99 <450ms, error_rate <0. %5, stale_share <%12

11. 3 Policy "gate" (check)

Varsa ( . . Durum! = "Bitti've eylem. ["kritik"]'deki ciddiyet

12) Anti-desenler

"Cadı avı've ceza - hataları gizleme, sinyal kaybı.
Protokol uğruna protokol: eylemler/sahipler/son tarihler olmadan uzun belgeler.
OCA seviyesi "koddaki hata" sistem faktörleri olmadan.
Olayı tekrar test etmeden ve taban çizgilerini güncellemeden kapatmak.
Şirket içinde tanıtım eksikliği: Aynı hataları diğer takımlarda tekrarlamak.
Destek/ortaklardan gelen geri bildirimleri ve "görünmez" bozulmayı göz ardı etme (yavaş başarı).
Özet "Her şeyi düzeltti, devam ediyor" - mimaride/süreçlerde değişiklik yok.

13) Mimar kontrol listesi

1. 72 saat ≤ tek bir ölüm sonrası şablonunuz ve SLA yayınınız var mı?
2. Roller (IC, Comms, Scribe, SME) otomatik olarak atanıyor mu?
3. Zaman çizelgeleri telemetri (trails/metrics/logs) ve release/flag etiketlerine dayanmaktadır?
4. RCA yöntemleri sistemik olarak uygulanır (5 Neden, Ishikawa, Bariyer)?
5. Eylemlerin risk ve serbest bırakma kapıları ile ilişkili sahipleri, son tarihleri ve DoD'ları var mı?
6. Olay, runbook/xaoc komut dosyalarını/uyarılarını güncelliyor mu?
7. Dahili VoC/Destek kanalları,'en iyi ağrılar "için düzenli bir inceleme var mı?
8. Hatalı bir bütçe, serbest bırakma ve deney politikasını etkiler mi?
9. Vade ölçütleri izleniyor mu (ölüm sonrası zaman, yeniden açılma oranı, tekrarlanabilirlik)?
10. Arama ile genel ekip içi analiz ve bilgi tabanı mevcut mu?

Sonuç

Postmortemler ve geri bildirimler bir mimari öğrenme mekanizmasıdır. Suçlamasız ayrıştırma, eylemlerin ölçülebilir etkisi ve üretimden gelen sinyallerin entegrasyonu norm haline geldiğinde, sistem her hafta daha istikrarlı, daha hızlı ve daha net hale gelir. Gerçekleri görünür, eylemleri zorunlu ve bilgiyi erişilebilir kılın ve olaylar platformunuzun gelişimi için yakıt haline gelir.