[SEV] Qısa təsviri və tarixi

1) Prinsiplər və mədəniyyət

Blameless. Səhv insan deyil, sistemin xüsusiyyətidir. Kim günahkar deyil, «niyə belə oldu» axtarırıq.
Faktlar və invariantlar. Hər hansı bir nəticə time line, SLO, tracking və log əsaslanır.
Şirkət daxilində ictimaiyyət. Nəticələr və dərslər əlaqəli komandalar üçün mövcuddur.
Hərəkətlər protokollardan daha vacibdir. Sənəddə heç bir dəyişiklik ≡.
Sürətli nəşr. Postmortem layihəsi - hadisədən sonra 48-72 saat ərzində.

2) Taksonomiya və hadisələrin meyarları

• SEV1 - tam əlçatmazlıq/pul/məlumat itkisi;
• SEV2 - əhəmiyyətli deqradasiya (səhvlər> SLO, p99 xaricində);
• SEV3 - qismən deqradasiya/bypass ssenarisi mövcuddur.
• Təsir: təsirlənmiş regionlar/tenantlar/məhsullar, müddəti, biznes metrikası (dönüşüm, GMV, ödənişlərin rədd edilməsi).
• SLO/səhv büdcə: nə qədər büdcə tükəndi, buraxılışların sürətinə və təcrübələrə necə təsir edir.

3) Hadisə rolları və prosesi

Incident Commander (IC): prosesi idarə edir, addımları prioritet edir, sahiblərini təyin edir.
Communications Lead: Steykholderləri/müştəriləri şablona görə məlumatlandırır.
Ops/On-call: ləğv, mitiging hərəkətləri.
Scribe: Taymline və artefaktlara rəhbərlik edir.
Subject Matter Experts (SME): dərin diaqnostika.

Mərhələlər: aşkarlama → eskalasiya → sabitləşmə → yoxlama → bərpa → postmortem → təkmilləşdirmələrin tətbiqi.

4) Postmortem şablon (struktur)

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 Alert p99> 800ms (gateway)

13: 24:00 IC təyin, war-room açıq

13: 27:30 Müəyyən «yavaş uğur» currency-api

13: 30:15 Ficha bayrağı stale-rates ON (10% trafik)

13: 41:00 Stale-rates 100%, p99 sabitləşdirilmiş 290ms

13: 52:40 gateway-də retrajların məhdudlaşdırılması

13: 58:00 Hadisə bağlı, monitorinq 30min

11. 2 Solutions and Validation (DoD)

Həll: breaker daxil (slow_success)

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

11. 3 Policy "gate" (check)

deny_release if any(postmortem_action. status!= "Done" and action. severity in ["critical"])

12) Anti-nümunələr

«Cadugər ovu» və cəzalar → səhvləri gizlətmək, siqnalları itirmək.
Protokol üçün protokol: uzun sənədlər heç bir hərəkət/sahibləri/vaxt.
Sistem faktorları olmadan RCA səviyyəli «kodda səhv».
Hadisənin retest və yenilənmədən bağlanması.
Şirkət daxilində ictimaiyyətin olmaması: digər komandalarda eyni səhvlərin təkrarlanması.
Sapport/partnyorlar və «görünməz» deqradasiyalardan rəylərə məhəl qoymayın (yavaş uğur).
«Hər şey düzəldildi, davam edirik» xülasəsi - memarlıq/proseslərdə heç bir dəyişiklik yoxdur.

13) Memarın yoxlama siyahısı

1. Postmortem və SLA nəşr vahid şablon var ≤ 72 saat?
2. Rollar (IC, Comms, Scribe, SME) avtomatik təyin olunur?
3. Zaman laynları telemetriya (treys/metrika/log) və reliz/bayraq etiketlərinə əsaslanır?
4. RCA metodları sistemli şəkildə tətbiq olunur (5 Why, Ishikawa, Barrier)?
5. Aksiyaların sahibləri, şərtləri və DoD var, risk və buraxılış geytləri ilə əlaqəli?
6. Hadisə runbook/xaoc-script/alert yenilənməsinə gətirib çıxarır?
7. Daxili VoC/Support kanalları, müntəzəm «top ağrı» baxış var?
8. Səhv büdcə buraxılış və təcrübə siyasətinə təsir edirmi?
9. Yetkinlik metrikləri izlənilir (time-to-postmortem, reopen rate, təkrarlanabilirlik)?
10. İctimai komanda daxili təhlil və axtarış ilə bilik bazası mövcuddur?

Nəticə

Postmortemlər və rəy memarlıq öyrənmə mexanizmidir. Heç bir ittiham olmadan təhlil, ölçülə bilən hərəkət effekti və istehsaldan gələn siqnalların inteqrasiyası normaya çevrildikdə, sistem hər həftə daha sabit, daha sürətli və daha aydın olur. Faktları görünən, hərəkətləri məcburi və bilikləri əlçatan edin və insidentlər platformanızın təkamülü üçün yanacağa çevriləcəkdir.