תיאור ותאריך קצרים [ ] SEV

1) עקרונות ותרבות

ללא רבב. שגיאה היא תכונה של המערכת, לא אדם. אנחנו מחפשים ”למה זה קרה”, ולא ”מי אשם”.
עובדות וחוקרים. כל יציאות מבוססות על ציר זמן, SLO, עקבות ויומנים.
פרסום בתוך החברה. סיכומים ושיעורים זמינים לצוותים קשורים.
פעולות חשובות יותר מפרוטוקולים. המסמך לא השתנה זמן אבוד.
הוצאה לאור מהירה. טיוטה לאחר המוות בתוך 48-72 שעות לאחר האירוע.

2) טקסונומיה וקריטריונים של אירוע

• SEV1 - אי נגישות מוחלטת/אובדן כסף/נתונים;
• SEV2 - הידרדרות משמעותית (שגיאות> SLO, p99 בחוץ);
• SEV3 - עיוות חלקי קיים.
• השפעה: אזורים/דיירים/מוצרים מושפעים, משך זמן, מדדים עסקיים (המרה, GMV, כשל בתשלום).
• תקציב SLO/שגוי: כמה תקציב מותש, איך הוא משפיע על מהירות השחרור והניסויים.

3) תפקידי תקרית ותהליך

מפקד אירוע (IC): מנהל את התהליך, נותן עדיפות לצעדים, מקצה בעלים.
תקשורת מובילה: מידע על בעלי עניין/לקוחות בתבנית.
מבצעים/בכוננות: חיסול, פעולות מקלות.
שומר על ציר זמן וחפצים.
מומחים לחומר נושא (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 התראה p99> 800ms (שער)

13: 24:00 מוקצה, חדר מלחמה פתוח

13: 27:30 מטבע-אפי ”הצלחה איטית” זוהה

13: 30:15 פיצ 'ה-דגל מעופש תעריפים על (10% תנועה)

13: 41:00 שיעורים מעופשים 100%, p99 התייצב 290ms

13: 52:40 נסיגה מגבילה לשער

תקרית 13: 58 נסגרה, ניטור 30 דקות

11. 2 Solutions and Validation (DoD)

פתרון: אפשר מפסק (slow_success)

משרד ההגנה: תסריט כאוס ”+ 300ms למטבע” - p99 <450ms, error_rate <0. 5%, stale_share <12%

11. 3 Policy "gate" (check)

deny_release אם בכלל (postmortem_action. סטטוס = ”נעשה” ופעולה. חומרה ב [ ”קריטי” ])

12) אנטי דפוסים

”ציד מכשפות” ועונש כפול הסתרת טעויות, אובדן אותות.
פרוטוקול למען הפרוטוקול: מסמכים ארוכים ללא פעולות/בעלים/מועדים.
רמת אוקה ”באג בקוד” ללא גורמי מערכת.
סגירת האירוע מבלי לבחון מחדש ולעדכן את קווי הבסיס.
חוסר פרסום בתוך החברה: חוזר על אותן טעויות בצוותים אחרים.
התעלמות ממשוב מתמיכה/שותפים והשפלה ”בלתי נראית” (הצלחה איטית).
אין שינויים בארכיטקטורה/תהליכים.

13) רשימת אדריכלים

1. האם יש לך תבנית אחת שלאחר המוות ופרסום SLA צוין 72 שעות?
2. האם תפקידים (IC, Comms, Scribe, SME) מוקצים באופן אוטומטי?
3. צירי זמן מבוססים על טלמטריה (שבילים/מדדים/יומנים) ותוויות שחרור/דגל?
4. שיטות RCA מיושמות באופן שיטתי (5 למה, אישיקאווה, מחסום)?
5. לפעולות יש בעלים, מועדים ומשרד ההגנה, הקשורים לסיכון ושחרור שערים?
6. האם התקרית מעדכנת את התסריטים/התראות?
7. ערוצי VOC/Support מובנים, האם יש סקירה קבועה של ”כאבי צמרת”?
8. האם תקציב שגוי משפיע על מדיניות השחרור והניסויים?
9. האם מדדי הבגרות נמצאים במעקב (זמן לאחר המוות, קצב פתיחה מחדש, חזרות)?
10. ניתוח פנים-צוות ציבורי ובסיס ידע עם חיפוש זמינים?

מסקנה

פוסטמורטים ומשוב הם מנגנון למידת ארכיטקטורה. כאשר ניתוחים נטולי אשמה, אפקט מדיד של פעולות ואינטגרציה של אותות מייצור הופכים לנורמה, המערכת נעשית יציבה יותר, מהירה יותר וברורה יותר מדי שבוע. הפוך עובדות גלויות, פעולות חובה, וידע נגיש, ותקריות להפוך דלק לאבולוציה של הפלטפורמה שלך.