[SEV] მოკლე აღწერა და თარიღი

1) პრინციპები და კულტურა

Blameless. შეცდომა არის სისტემის საკუთრება და არა ადამიანი. ჩვენ ვეძებთ „რატომ მოხდა ეს“ და არა „ვინ არის დამნაშავე“.
ფაქტები და ინვარიანტები. ნებისმიერი დასკვნა ეყრდნობა დროულად, SLO, ტრეკებსა და ლოგებს.
საჯაროობა კომპანიის შიგნით. შედეგები და გაკვეთილები ხელმისაწვდომია დაკავშირებული გუნდებისთვის.
მოქმედებები უფრო მნიშვნელოვანია, ვიდრე ოქმები. დოკუმენტი უცვლელი და დაკარგული დროა.
სწრაფი გამოცემა. პოსტმორტემის პროექტი - ინციდენტიდან 48-72 საათის განმავლობაში.

2) ტაქსონომია და ინციდენტების კრიტერიუმები

• SEV1 - ფულის/მონაცემების სრული მიუწვდომლობა/დაკარგვა;
• SEV2 - მნიშვნელოვანი დეგრადაცია (შეცდომები> SLO, p99 გარეთ);
• SEV3 - ნაწილობრივი დეგრადაცია/შემოვლითი სცენარი არსებობს.
• გავლენა: დაზარალებული რეგიონები/ტენანტები/პროდუქტები, ხანგრძლივობა, ბიზნეს მეტრიკა (კონვერტაცია, GMV, გადახდების უარყოფა).
• SLO/მცდარი ბიუჯეტი: რამდენი ბიუჯეტია ამოწურული, როგორ მოქმედებს ეს გამოშვებების სიჩქარეზე და ექსპერიმენტებზე.

3) ინციდენტის როლები და პროცესი

Incident Commander (IC): მართავს პროცესს, პრიორიტეტულია ნაბიჯები, დანიშნავს მფლობელებს.
კომუნიკაციები Lead: აცნობებს სტეიკჰოლდერებს/კლიენტებს შაბლონის მიხედვით.
Ops/On-call: ლიკვიდაცია, მიტინგები.
Scribe: ხელმძღვანელობს დროსა და არტეფაქტებს.
Subject Matter Experts (SME): ღრმა დიაგნოზი.

ეტაპები: გამოვლენა, ესკალაცია, სტაბილიზაცია, გადამოწმება, აღდგენა პოსტმორტთან და გაუმჯობესების დანერგვა.

4) პოსტმორტემის შაბლონი (სტრუქტურა)

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 დაინიშნა, ომის ოთახი ღიაა

13: 27:30 იდენტიფიცირებულია „ნელი წარმატება“

13: 30:15 stale-rates ON- ის დროშა (ტრაფიკის 10%)

13: 41:00 Stale-rates 100%, p99 სტაბილიზირებულია 290ms

13: 52:40 რეაგირების შეზღუდვა gateway

13: 58:00 ინციდენტი დახურულია, მონიტორინგი 30 წთ

11. 2 Solutions and Validation (DoD)

გამოსავალი: ჩართეთ breaker (slow _ success)

DoD: ქაოსის სცენარი „+ 300ms 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) ანტი შაბლონები

„ჯადოქრების ნადირობა“ და სასჯელი შეცდომების დამალვა, სიგნალების დაკარგვა.
პროტოკოლი პროტოკოლის გულისთვის: გრძელი დოკუმენტები მოქმედებების/მფლობელების/ვადების გარეშე.
დონის RCA „bag in code“ სისტემის ფაქტორების გარეშე.
ინციდენტის დახურვა რეტესტრის გარეშე და ბაზლაინების განახლება.
კომპანიის შიგნით საჯაროობის ნაკლებობა: იგივე შეცდომების განმეორება სხვა გუნდებში.
საპორტო/პარტნიორებისგან უკუკავშირის უგულებელყოფა და „უხილავი“ დეგრადაცია (ნელი წარმატება).
შეჯამება „ყველაფერი შეკეთდა, ჩვენ გადავდივართ“ - არქიტექტურაში/პროცესებში ცვლილებების გარეშე.

13) არქიტექტორის ჩეკის სია

1. არსებობს ერთი პოსტმორტემის შაბლონი და SLA პუბლიკაცია 72 საათი?
2. როლები (IC, Comms, Scribe, SME) ენიჭება ავტომატურად?
3. Timlines ემყარება ტელემეტრიას (ტრეისი/მეტრიკა/ლოგები) და გამოშვებების/დროშების ეტიკეტებს?
4. RCA მეთოდები სისტემურად გამოიყენება (5 რატომ, იშიკავა, ბარიერი)?
5. მოქმედებები აქვთ მფლობელებს, ვადებსა და DoD- ს, რომლებიც დაკავშირებულია გამოშვების რისკთან და კარიბჭეებთან?
6. ინციდენტი იწვევს runbook/xaoc სცენარების/ალერტების განახლებას?
7. ჩამონტაჟებულია VoC/Support არხები, არის „ტოპ ტკივილების“ რეგულარული მიმოხილვა?
8. არასწორი ბიუჯეტი გავლენას ახდენს გათავისუფლებისა და ექსპერიმენტების პოლიტიკაზე?
9. თვალყურს ადევნებენ სიმწიფის მეტრიკებს (დრო-postmortem, reopen rate, განმეორება)?
10. ხელმისაწვდომია თუ არა საზოგადოებრივი შიდა გუნდური ანალიზები და ცოდნის ბაზა ძებნაში?

დასკვნა

პოსტმორტემები და უკუკავშირი არქიტექტურის სწავლების მექანიზმია. როდესაც ბრალდების გარეშე გაანალიზება, მოქმედებების გაზომვის ეფექტი და წარმოების სიგნალების ინტეგრაცია ნორმად იქცევა, სისტემა ყოველ კვირას ხდება სტაბილური, სწრაფი და გასაგები. გახადეთ ფაქტები ხილული, სავალდებულო მოქმედებები და ცოდნა ხელმისაწვდომი და ინციდენტები გადაიქცევა საწვავად თქვენი პლატფორმის ევოლუციისთვის.