사후 브리핑
1) 사후 분석이 필요한 이유
사후 브리핑 (사후/AAR) 은 실패 후 조직을 훈련시키기위한 구조화 된 프로세스입니다. 목표는 비난을 찾는 것이 아니라 근본 및 기여 원인을 식별하고 재발 위험과 사고 비용을 줄여 SLO, MTTR 및 고객/규제 신뢰를 향상시키는 측정 가능한 조치 (CAPA) 를 통합하는 것입니다.
2) 원칙 (정당한 문화)
고발없이: 우리는 성격이 아닌 시스템, 결정 및 상황을 분석합니다.
타임 라인, 로그, 메트릭, 트레일, 변경 아티팩트 등 의견보다 사실이 더 중요합니다.
E2E 관점: 고객의 증상에서 내부 종속성 및 외부 제공자에 이르기까지.
검증 가능성: 각 가설은 실험/데이터에 의해 뒷받침됩니다.
루프 닫기: CAPA → → 체크 포인트 → 재테스트.
3) 구문 분석을 실행할시기와 형식은
필요: SEV-0/1; SLA/규제 요건 위반; 데이터 유출; 심각한 PR 위험.
가속 (빛): 눈에 띄는 영향 또는 반복되는 증상이있는 SEV-2.
통신 AAR: 장애가 상태 페이지/지원에 영향을 미치는 경우 업데이트 및 메시지 품질의 SLA를 확인합니다.
이용 약관: 최종 버전 인 48-72 시간 초안-최대 5 일 (달리 동의하지 않는 한).
4) 역할과 책임
RCA Lead: 프로세스를 구성하고 회의를 이끌며 보고서의 품질과 CAPA를 담당합니다.
사건 사령관 (IC): 사건 사실과 해결책을 제공합니다.
기술 리드 (시스템 별): 아티팩트를 확인하는 원인 분석.
Comms/Support/Legal: 커뮤니케이션 및 규정 준수 요구 사항 평가.
스크라이브: 프로토콜, 증거 수집, 구조 준수.
제품/비즈니스 이해 관계자-고객 영향/회전율, CAPA 우선 순위
5) 준비: 회의 전에 수집 할 내용
타임 라인 (UTC): T0 감지 → Tn 복구; 출시/기능 플래그/구성, 공급자 상태.
관찰 가능성 데이터: SLI/SLO 그래프, 오류율, 백분위 수, 로그, 추적, 스크린 샷.
변경 사항의 맥락: PR/배치 링크, DB 마이그레이션, 기능 플래그, 작업 계획.
영향: 영향을받는 코호트/지역/공급자, 가동 중지 시간, SLA 크레딧.
커뮤니케이션: 상태 페이지의 초안/게시물, 지원 답변, 내부 알림.
정치인/플레이 북: 편차가있는 과정에서 무슨 일이 있었는지.
6) 분석 절차 (선택 조합)
5 이유: 인과 사슬의 빠른 부검 (위험-지나치게 단순화).
피쉬 본 차트: 사람/프로세스/플랫폼/정책/파트너/제품.
FTA (Fault Tree Analysis) -이벤트에서 여러 원인으로 공제 (AND/OR).
변경 분석: 사고 중 변경 된 사항 대 안정적인 조건.
인과 그래프: 복잡한 마이크로 서비스 및 외부 종속성을위한 인과 그래프.
휴먼 팩터 검토: 피로, 정보 노이즈, 관련없는 런북 및.
7) 보고서 구조 (템플릿)
1. 행정 요약-누가 영향을 받았는지 최종 상태.
2. 영향: SLI/SLO, 사용자, 지역/공급자, 최소 가동 중지 시간, 재무/규제 효과.
3. 타임 라인 (UTC): 주요 이벤트, 릴리스, IC 솔루션, 커뮤니케이션.
4. 관찰 및 데이터: 그래프, 로그, 추적, 구성 요소/체계의 확산.
5. 가설 및 테스트: 허용/거부, 실험/시뮬레이션 참조.
6. 근본 원인: 시스템/프로세스/기술 (명확한 문구).
7. 기여 요인: 왜 일찍 눈치 채거나 멈추지 않습니까?
8. 작동 한 것/작동하지 않은 것: 프로세스, 도구, 사람.
9. CAPA: 소유자/마감일/성공 지표를 사용한 수정 및 예방 조치.
10. 검증 계획: D + 14/D + 30 제어점, 마감 기준.
11. 외부 버전: 클라이언트/규제 (민감한 데이터 없음).
12. 응용 프로그램: 아티팩트, 티켓/PR 링크, 대시 보드 스크린 샷.
8) CAPA: 행동을 작동시키는 방법
각 작업에는 소유자, 마감일 및 효과 KPI (예: X% 의 변경 실패율 감소, 90 일의 제로 반복, 스파이크의 연소율 감소) 가 있습니다.
별도의 교정 및 예방 조치.
코드 정책 링크: 경고, SLO 게이트, 자동 스케일/제한, GitOps.
CAPA는 주간 운영 회의에서 리뷰와 함께 공개 잔고에 들어갑니다.
9) 효과 점검 및 폐쇄
체크 포인트: D + 7 (중간), D + 14/D + 30 (주), D + 90 (총).
검증: 테스트/시뮬레이션 (게임 일), 섀도우 트래픽, 관찰 가능성 (녹색 영역의 안정적인 SLI), 재발 없음.
완료된 CAPA 및 검증 된 메트릭에서만 닫을 수 있습니다.
10) 통신 및 준수
내부: 제품/지원/관리에 대한 명확한 상태, SLA 업데이트가 충족됩니다.
외부: 상태 페이지, 클라이언트/파트너에게 우편 발송; 비난없는 언어, 명확한 예방 계획.
규제: 알림 마감일, 예제의 개인화, 보고서 및 아티팩트의 변경 불가능한 저장.
11) 프로세스 성숙도 지표
보고 게시 시간: 실제 vs SLA (예: 영업일 5 일).
CAPA 완료율: 활동의% 가 마감일에 마감되었습니다.
재개율: 90 일 동안 반복 사고의 비율.
체계적인 원인과 "인간 오류" 의 비율.
위생 경보: 잘못된 페이지의 감소, 런북으로 덮인 경고의 증가.
DORA 메트릭 변경: MTTR, 전후 변경 실패율.
12) 점검표
파싱하기 전에
- RCA 소유자 및 멤버십이 정의되었습니다.
- 수집 된 타임 라인 및 아티팩트 (로그/그래프/릴리스/플래그).
- 코호트/지역/제공자에 의해 평가 된 영향.
- 충격 및 타임 라인 섹션의 초안이 준비되었습니다.
- 관련 정책/플레이 북은 실제 작업에 매핑됩니다.
동안
- 허용/거부 된 가설과 근거가 기록되었습니다.
- 뿌리와 기여 원인이 확인되었습니다.
- KPI 및 마감일이있는 CAPA 계획이 수립되었습니다.
- 외부 당사자에 대한 보고서 버전이 합의됩니다 (필요한 경우).
후
- 정시에 게시 된 보고서, 역할 별 액세스.
- CAPA가 기록되고 소유자가 확인됩니다.
- 검증을 위해 테스트 포인트 및 미니 시뮬레이션이 할당됩니다.
- 업데이트 된 런북/SOP/경고/문서.
13) 반 패턴
"Guilty man X" -체계적인 이유없이 → 를 반복하십시오.
CAPA없이 또는 소유자/마감일없이 종이에 대해보고하십시오.
사실/인공물이 없습니다-감각에 대한 결론.
특정 변경없이 너무 일반적인 언어 ("데이터베이스 과부하").
커뮤니케이션과 규정 준수를 무시하는 것은 평판 위험
효과 테스트없이 폐쇄-몇 주 후에 재발합니다.
14) 미니 템플릿
보고서 헤더
Incident: INC-2025-10-31 (SEV-1)
Window: 2025-10-31 18: 05-18: 47 UTC
Owner of the analysis: @ rca-lead
Affected: EU region, payments (success -28% peak)
Status: corrected; 48 hours monitoring뿌리 원인 공식화 (예)
CAPA (조각)
카나리아 라우팅을 PSP-A (1% → 5% → 25%) 로 사용하십시오. 소유자: @ payment-tl, 2025-11-07, KPI: 공급자가 30 일을 릴리스 할 때 0 P1 사건.
800ms의 총 SLA 시간, 소유자: @ platform-sre, 최대: 2025-11-05, KPI: p99 <600ms의로드 N.을 재구성 한 타임 아웃/배상을 재구성하십시오.
BIN Cohort, 소유자: @ data-lead에 의한 비즈니스 SLI 추가: 2025-11-10, KPI: 악화 감지 <5 분.
15) 매일 연습에 포함
주간 RCA 검토: CAPA 상태, 새로운 수업, 프로세스 업데이트.
태그 (서비스, SEV, 이유) 및 검색이있는 위키의 사후 사후 디렉토리.
조치를 확인하기 위해 2-4 주 동안의 사고를 기반으로 한 시뮬레이션.
온 콜보드 및 교육 시나리오 업데이트에 대한 수업 포함.
16) 결론
사후 분석은 체계적인 개선을위한 메커니즘입니다. 사실이 수집되면 인과 관계가 입증되고 조치가 측정 가능하고 검증되며 조직은 신뢰성 운영 자본을 축적합니다: MTTR 및 반복 사고 감소, 방출 예측 성 및 고객 신뢰 증가.