[SEV] 짧은 설명 및 날짜

1) 원리와 문화

블래 멜리스. 오류는 사람이 아닌 시스템의 속성입니다. 우리는 "누가 책임을 져야하는지" 가 아니라 "왜 그런 일이 일어 났는지" 를 찾고 있습니다.
사실과 불변. 모든 출력은 타임 라인, SLO, 추적 및 로그를 기반으로합니다.
회사 내 홍보. 관련 팀은 총계와 수업을 이용할 수 있습니다.

프로토콜보다 동작이 더 중요합니다. 변경되지 않은 문서는 시간을 잃었습니

빠른 출판. 사후 초안-사고 후 48-72 시간 이내.

2) 분류 및 사건 기준

• SEV1 - 완전한 접근성/돈/데이터 손실;
• SEV2 - 상당한 열화 (오류> SLO, 외부 p99);
• SEV3 - 부분 저하/해결 방법이 존재합니다.
• 영향: 영향을받는 지역/임차인/제품, 기간, 비즈니스 지표 (변환, GMV, 지불 실패).
• SLO/잘못된 예산: 예산이 얼마나 소진되었는지, 출시 및 실험 속도에 미치는 영향.

3) 사건 역할 및 프로세스

IC (Incident Commander): 프로세스를 관리하고 단계를 우선시하며 소유자를 지정합니다.
커뮤니케이션 책임자: 이해 관계자/고객에게 템플릿을 부여합니다.
Ops/On-call: 청산, 조치 완화.
스크라이브: 타임 라인과 아티팩트를 유지합니다.
주제 전문가 (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 IC 할당, 전쟁 실 개방

13: 27:30 통화-api "느린 성공" 식별

13: 30:15 Ficha-flag 오래된 요금 ON (10% 트래픽)

13: 41:00 현장 요금 100%, p99 안정화 290ms

13: 52:40 Retreas를 게이트웨이로 제한

13: 58:00 사건 종결, 30 분 모니터링

11. 2 Solutions and Validation (DoD)

솔루션: 차단기 활성화 (slow _ success)

DoD: 혼돈 스크립트 "+ 300ms ~ 통화" - p99 <450ms, 오류 _ rate <0. 5%, 부실 _ 공유 <12%

11. 3 Policy "gate" (check)

(postmortem _ action) 이 있으면 _ release를 거부합니다. 상태! = "완료" 및 동작. ["중요한"] 의 심각성)

12) 반 패턴

"마녀 사냥" 과 형벌 → 실수 숨기기, 신호 상실.
프로토콜을위한 프로토콜: 동작/소유자/마감일이없는 긴 문서.
시스템 요소가없는 OCA 레벨 "코드의 버그".
기준선을 다시 테스트하고 업데이트하지 않고 사건을 종료합니다.
회사 내 홍보 부족: 다른 팀에서도 같은 실수를 반복합니다.
지원/파트너의 피드백을 무시하고 "보이지 않는" 저하 (느린 성공).
아키텍처/프로세스의 변경 사항이 없습니다.

13) 건축가 점검표

1. 하나의 사후 템플릿과 SLA 출판물이 있습니까?
2. 역할 (IC, Comms, Scribe, SME) 이 자동으로 할당됩니까?
3. 타임 라인은 원격 측정 (트레일/메트릭/로그) 및 릴리스/플래그 레이블을 기반으로합니까?
4. RCA 방법은 체계적으로 적용됩니다 (5 이유, 이시카와, 배리어)?
5. 위험 및 릴리스 게이트와 관련된 소유자, 마감일 및 DoD가 있습니까?
6. 사건이 런북/xaoc 스크립트/경고를 업데이트합니까?
7. 내장 VoC/지원 채널은 "최고의 통증" 에 대한 정기적 인 검토가 있습니까?
8. 잘못된 예산이 릴리스 및 실험 정책에 영향을 미칩니 까?
9. 만기 지표를 추적합니까 (사후 시간, 재개 율, 반복성)?
10. 검색을 통한 공개 팀 내 분석 및 지식 기반을 사용할 수 있습니까?

결론

사후 및 피드백은 아키텍처 학습 메커니즘입니다. 비난없는 파싱, 측정 가능한 동작 효과 및 생산으로 인한 신호 통합이 표준이되면 매주 시스템이 더욱 안정적이고 빠르며 명확 해집니다. 사실을 보이게하고, 행동을 필수적이며, 지식에 접근 할 수있게하고, 사건이 플랫폼의 진화를위한 연료가되