사고 지표

1) 사건을 측정하는 이유

사고 지표는 혼란스러운 사건을 관리 가능한 프로세스로 바꿉니다. 응답 및 복구 시간을 줄이고 원인 재발을 줄이며 SLO/계약 이행을 입증하고 자동화 포인트를 찾는 데 도움이됩니다. 좋은 메트릭 세트는 전체주기를 다룹니다. 탐지 → 분류 → 에스컬레이션 → 완화 조치 → 복구 → CAPA → 구문 분석.

2) 기본 정의 및 공식

이벤트 간격

MTTD (Mean Time To Detect) = T0 (실제 영향 시작) 에서 첫 번째 신호/감지까지의 평균 시간.
MTTA (Mean Time To Acknowledge) = 첫 번째 신호에서 ack on-call까지의 평균 시간.
MTTM (Mean Time To Mitigate) = SLO 임계 값 이하로 감소하는 시간 (종종 = UX 해결/저하에 대한 시간).
MTTR (평균 복구 시간) = 대상 SLI의 복구를 완료하기위한 평균 시간.
MTBF (실패 사이의 평균 시간) = 관련 사건 간의 평균 간격.

작동 시간

선언 시간-T0에서 SEV/사건 수준의 공식 발표.
Comms to Comms-발표에서 최초의 공개/내부 SLA 업데이트까지.
상태 시간-각 단계에서의 지속 시간 (심사/당뇨병/수정/확인).

주파수 및 분수

사건 수-기간 당 사건 수.
사고 율-1k/10k/100k의 성공적인 거래 또는 요청 (정규화).
SEV 믹스-심각도 별 분포 (SEV-0... SEV-3).
SLA Breach Count/Rate-외부 SLA 위반 횟수/공유.
실패율 변경-변경으로 인한 사고의% (릴리스/구성/마이그레이션).

신호 및 프로세스의 품질

% 실행 가능한 페이지 - 의미있는 플레이 북 동작으로 이어진 페이지의 비율.
허위 긍정적 비율 (페이지) -허위 양성의 비율.
탐지 범위-자동화로 감지 된 사고의 비율 (클라이언트/지원이 아님).
재개 속도-근본 원인이 동일한 반복 된 사고의 비율은 약 90 일입니다.
CAPA 완료-시정/예방 조치의% 가 정시에 마감되었습니다.
SMA 부착-필요한 빈도로 게시 된 업데이트의 비율.

3) 사건 단계별 지표 맵

4) 정규화 및 세분화

카운터를 볼륨 (트래픽, 성공, 활성 사용자) 으로 정규화하십시오.
세그먼트 별: 지역/테넌트, 공급자 (PSP/KYC/CNC), 변경 유형 (코드/구성/인프라), 시간 (낮/밤), 검출원 (합성/RUM/인프라/지원).
비즈니스 SLI (결제, 등록, 보충의 성공) 는 비즈니스에 중요합니다. 사고 지표를 저하와 연결합니다.

5) 임계 값 목표 (랜드 마크, 도메인에 적응)

MTTD: Tier-0의 경우 λ5 분, Tier-1의 경우 10-15 분.
MTTA: 자연스럽게 5 분 (24/7), 10 분 (자외선).
MTTM: 계층 15 분 (계층 0), 계층 30-60 분 (계층 1).
MTTR: 10 분 (0 단계), 4 시간 (1 단계).
탐지 범위: 자동화 85% 이상.
% 실행 가능한 페이지: 80-90% 이상; FP 페이지: 소 5%.
다시 열기 속도 (90으로): 방법 5-10%.

CAPA 완료 (정시): 85% 이상

6) 변화의 원인과 영향

기본 원인 (코드/설정/인프라/제공자/보안/데이터/용량) 을 할당하고 각 사고에 트리거 (ID, 설정 변경, 마이그레이션, 외부 요인) 를 지정합니다.
변경 연결 MTTR/카운트 유지-릴리스 및 구성이 기여하는 양입니다 (게이트/카나리아 정책의 기본).
이와 별도로 공급자가 야기한 사고 (PSP/KYC/CNC/Cloud) 를 고려하여 경로 및 계약을 관리하십시오.

7) 커뮤니케이션 및 고객 영향

첫 공개 업데이트 및 업데이트 케이던스 시간 (예: 15/30 분마다).
불만-1 건의 사건, 추세에 대한 티켓/불만.
상태 정확도-철회없이 공개 업데이트의 비율.
사후 NPS (주요 고객 별) -SEV-1/0 이후의 짧은 부스트.

8) 사고와 관련된 품질 지표 경고

페이지 스톰 인덱스-사고 중 통화 중 페이지/시간 수 (중간/p95).
Dedup Efficiency-억제 된 복제물의 비율.
정원 확인률-프로브 정족수 (2 개 이상의 독립 소스) 가 트리거 된 사건의 비율.
Shadow → Canary → 새로운 규칙의 Prod 변환 (Alert-as-Code).

9) 대시 보드 (최소 세트)

1. 임원 (28 일): 사건 수, SEV 배포, MTTR/MTTM, SLA 중단, 재개, CAPA.

2. SRE 작업: MTTD/MTTA

3. 영향 변경: 릴리스/구성 사건 공유, 변경 사고에 대한 MTTR, 유지 보수 창 대 사고.
4. 공급자: 공급자 별 사고, 저하 시간, 경로 전환, 계약 SLA.
5. 서비스/지역별 히트 맵: 1k 트랜잭션 당 사고 및 MTTR.

SLI/SLO 그래픽과 릴리스 주석 및 SEV 마크를 결합하십시오.

10) 사고 데이터 다이어그램 (권장)

incident_id, sev, state, service, region, tenant, provider?,
t0_actual, t_detected, t_ack, t_declared, t_mitigated, t_recovered,
source_detect (synthetic    rum    infra    support),
root_cause (code    config    infra    provider    security    data    capacity    other),
trigger_id (release_id    change_id    external_id),
slo_impact (availability    latency    success), burn_minutes,
sla_breach (bool), public_updates[], owners (IC/TL/Comms/Scribe),
postmortem_id, capa_ids[], reopened_within_90d (bool)

11) 계산 예 (SQL 아이디어)

sql
SELECT PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_recovered - t0_actual))/60) AS mttr_min
FROM incidents
WHERE t0_actual >= '2025-10-01' AND t_recovered IS NOT NULL AND sev IN ('SEV-0','SEV-1','SEV-2');

sql
SELECT 100.0 SUM(CASE WHEN source_detect <> 'support' THEN 1 ELSE 0 END) / COUNT() AS detection_coverage_pct
FROM incidents
WHERE t0_actual >= current_date - INTERVAL '28 days';

sql
SELECT 100.0 COUNT() FILTER (WHERE trigger_id IS NOT NULL) / NULLIF(COUNT(),0) AS change_failure_rate_pct
FROM incidents
WHERE t0_actual >= current_date - INTERVAL '28 days';

12) SLO 및 오류 예산에 연결

사고 당 SLO 화상 시간을 기록하십시오-이것은 이벤트의 주요 "무게" 입니다.
사고 수보다는 총 화상 및 SEV 중량으로 CAPA의 우선 순위를 정하십시오.
재정적 영향으로 화상을 함께 스티치하십시오 (예: $/분 다운 타임 또는 $/손실 거래).

13) 프로그램 수준 지표

사후 리드 타임: 사건 종결에서 보고서 출판까지의 중요성.
증거 복잡성: 타임 라인, SLI 차트, 로그, PR/통신 링크와 보고서 공유.
경고 위생 점수: 실행 가능한/FP/dedup/quorum의 복합 지수.
핸드 오버 결함: 활성 사고의 맥락이 손실되는 변화의 비율.
교육 범위: 분기에 시뮬레이션 된% 통화 중.

14) 메트릭 구현 체크리스트

• 유니폼 타임 스탬프 (UTC) 및 사건 이벤트 계약이 정의됩니다.
• SEV, 근본 원인 분류 및 탐지 소스가 채택되었습니다.
• 메트릭은 볼륨 (트래픽/성공) 으로 정규화됩니다.
• 준비된 3 개의 대시 보드: 경영진, 운영, 변경 영향.
• 코드 경고: 각 페이지 규칙에는 플레이 북과 소유자가 있습니다.
• SLA 사후 부검 (예: 초안은 72ch이고, 마지막은 5 슬레이브입니다. 일).
• CAPA는 효과 KPI 및 D + 14/D + 30 날짜로 추적됩니다.
• 주간 사건 검토: 동향, 주요 이유, CAPA 상태.

15) 반 패턴

MTTD/MTTA/MTTM → 초기 단계의 제어 성 손실이없는 MTTR 만 고려하십시오.
볼륨에서 정규화하지 말고 → 큰 서비스는 "보인다".
체계적이지 않은 SEV → 이질적인 사건.
개선 대신 증거 → 논쟁의 부재.
화상/SLO 영향 대신 사고 수에 집중하십시오.
ReOpen과 CAPA → 영원한 재발을 무시하십시오.
Telemetry/ITSM에서 자동 업로드하지 않고 Excel의 메트릭.

16) 미니 템플릿

인시던트 카드 (abbr.)

INC: 2025-11-01-042 (SEV-1)
T0=12:04Z, Detected=12:07, Ack=12:09, Declared=12:11,
Mitigated=12:24, Recovered=12:48
Service: payments-api (EU)
SLI: success_ratio (-3.6% к SLO, burn=18 мин)
Root cause: provider (PSP-A), Trigger: status red
Comms: first 12:12Z, cadence 15m, SLA met
Links: dashboards, logs, traces, release notes

경영진 보고서 (28 일, 핵심 라인)

Incidents: 12 (SEV-0:1, SEV-1:3, SEV-2:6, SEV-3:2)
Median MTTR: 52 мин; Median MTTD: 4 мин; MTTA: 3 мин; MTTM: 17 мин
Detection Coverage: 88%; Actionable Pages: 86%; FP Pages: 3.2%
Change Failure Rate: 33% (4/12) — 3 связаны с конфигом
Reopen(90d): 1/12 (8.3%); CAPA Completion: 82% (2 просрочены)
Top Root Causes: provider(4), config(3), capacity(2)

17) 로드맵 (4-6 주)

1. 네드. 1-Timestamp/field 표준, SEV/reason 사전 기본 사건 쇼케이스.
2. 네드. 2: MTTD/MTTA/MTTM/MTTR 계산, 정규화 및 SEV- 대시 보드.
3. 네드. 3: 릴리스/구성, 감지 범위 및 경보 위생이 포함 된 번들.
4. 네드. 4: 집행 보고서, SLA 사후 부검, CAPA 추적기.
5. 네드. 5-6: 제공자 보고서, 연소 → $ 재무 모델, 분기 별 목표 및 분기 별 사건 검토.

18) 결론

사고 지표는 숫자 일뿐만 아니라 운영 안정성의 스토리 보드입니다. 전체 흐름 (감지에서 CAPA까지) 을 측정하고 메트릭을 정규화하고 SLO 및 변경 사항과 연관시키고 정기적으로 검토하면 조직은 응답 시간, 비용 및 사고 빈도를 예측할 수 있으며 사용자는 안정적인 서비스를 볼 수 있습니다.