GH GambleHub

근본 원인 분석

1) RCA는 무엇이며 왜 필요한가

근본 원인 분석은 재발을 방지하기 위해 사고의 근본 원인을 식별하기위한 구조화 된 프로세스입니다. 중심에서 - 사실, 인과 관계 및 체계적인 개선 (프로세스, 아키텍처, 테스트) 은 비난을 찾는 것이 아닙니다.
목표: 재발 방지, MTTR/사고 율 감소, SLO 개선, 규제 기관 및 파트너와의 신뢰 구축.


2) 원칙 (정당한 문화)

요금이 부과되지 않습니다. 우리는 사람들이 아니라 위험한 관행을 처벌합니다.
사실. 검증 가능한 데이터 및 아티팩트 만.
E2E보기. 고객에서 백엔드로, 공급자로.
가설의 테스트 가능성. 모든 진술-테스트/실험.
CAPA 폐쇄. 소유자 및 마감일에 대한 수정 및 예방 조치.


3) 입구 유물 및 준비

UTC 타임 라인: T0 감지 → T + 동작 → T + 복구.
관찰 가능성 데이터: 로그, 메트릭 (코호트 포함), 트레일, 합성, 상태 페이지.
변경 사항: 릴리스, 기능 플래그, 구성 요소, 제공자 이벤트.
환경: 버전, 아티팩트 해시, SBOM, 인프라 태그.
사건 기반: 영향에 대한 설명 (SLO/SLA, 고객, 이직률), 의사 결정, 해결 방법.
양육권 체인: 누가 증거를 수집/수정했는지 (규정 준수에 중요).


4) RCA 방법: 언제

1. 5 이유-좁은 문제에 대한 인과 관계를 신속하게 파악하십시오. 위험: 복잡한 시스템을 한 줄로 "롤업" 합니다.
2. Fishbone-요소를 사람/프로세스/플랫폼/정책/파트너/제품으로 분류합니다. 처음에는 유용합니다.
3. FTA (Fault Tree Analysis) -이벤트에서 원인으로 공제 (AND/OR). 인프라 및 트리 오류.
4. 인과 그래프/이벤트 체인-확률과 기여 가중치가있는 종속성 그래프. 마이크로 서비스 및 외부 공급자에게 좋습니다.
5. FMEA (실패 모드 및 효과 분석) -예방: 고장 모드, 심각도 (S), 주파수 (O), 탐지성 (D), RPN = S × O × D.
6. 변경 분석 - "그대로/그대로" (구성 디프, 스키마, 버전).
7. 휴먼 팩터 검토-사람들의 결정 맥락 (경고 피로, 나쁜 플레이 북, 과부하).

권장 조합: Fishbone → Change Analysis → Causal Graph/FTA → 5 주요 지점별 이유.


5) 단계별 RCA 프로세스

1. 이니셔티브: RCA 소유자를 임명하고 보고서 발행 마감일 (예: 5 일 근무일) 을 결정하고 팀 (IC, TL, Scribe, 공급자 담당자) 을 구성하십시오.
2. 수집 사실: 타임 라인, 그래프, 릴리스, 로그, 아티팩트; 수정 버전 및 금액 제어.
3. 지도 영향: SLI/SLO가 영향을받은 국가 (국가, 공급자, VIP).
4. 가설 구축: 기본, 대안; 지금 확인할 수있는 것을 확인하십시오.
5. 테스트 가설: 스테이지/시뮬레이션/카나리아에서의 재생, 추적 분석, 결함 주입.
6. 기술, 프로세스, 조직과 같은 근본 원인과 기여 원인을 제거하십시오.
7. CAPA 양식: 교정 (정확한) 및 예방 (예방); 성공 지표 및 타임 라인.
8. 내부 지식 기반 +, 필요한 경우 클라이언트/레귤레이터를위한 외부 버전.
9. 확인 효과: 14/30 일 후 체크 포인트; 폐쇄 조치.


6) "근본 원인" 으로 간주되는 것

"인간 오류" 가 아니라 가능하고 보이지 않는 조건:
  • 약한 테스트/기능 플래그, 제한/경고 누락, 모호한 문서, 잘못된 기본값, 깨지기 쉬운 아키텍처.
  • 종종 이것은 요인 (게이트 × 하중 × 공급자의 구성 × 부족) 의 조합입니다.

7) CAPA: 시정 및 예방 조치

수정:
  • 코드/구성 수정, 패턴 롤백, 제한/타임 아웃 변경, 인덱스 추가, 복제/샤딩, 트래픽 재분배, 인증서 업데이트.
예방:
  • 테스트 (계약, 혼돈 사례), 경고 (연소율, 합성 쿼럼), 릴리스 정책 (카나리아/청록색), 구성 요소 GitOps, 교육/체크리스트, 제공자 중복, DR 연습.

각 작업: 소유자, 마감일, 예상 효과, 검증 지표 (예: 변경 실패율 감소, 90 일 반복 없음).


8) 가설과 효과의 검증

실험: 결함 주입/혼돈, 그림자 트래픽, A/B 구성, 실제 프로파일로로드.
성공 지표: SLO 복구, p95/p99 안정화, 오류율 스파이크 없음, MTTR 감소, 연소율 및 30 일 동안의 제로 재개 추세.
제어점: D + 7, D + 30, D + 90-CAPA 구현 및 영향 수정.


9) RCA 보고서 템플릿 (내부)

1. 짧은 요약: 누가 영향을 받았을 때 일어난 일.
2. 영향: SLI/SLO, 사용자, 지역, 회전율/처벌 (있는 경우).
3. 타임 라인 (UTC): 주요 이벤트 (경고, 결정, 릴리스, 수정).
4. 관찰 및 데이터: 그래프, 로그, 추적, 구성 요소 (확장), 공급자 상태.
5. 가설 및 테스트: 허용/거부, 실험 참조.
6. 근본 원인: 기술, 프로세스, 조직.

7. 기여 요인: "왜 눈치 채지 못했거나 멈추지 않았습니까?"

8. CAPA 계획: 소유자/마감일/지표가있는 조치 표.
9. 위험 및 잔류 취약점: 모니터링/테스트해야 할 사항.
10. 응용 프로그램: 아티팩트, 링크, 그래프 (목록).


10) 예 (짧음, 일반화)

이벤트: 19: 05-19: 26 (SEV-1) 에서 35% 의 지불 성공.
영향: 21 분 e2e-SLO 위반, 영향을받는 3 개국, 반품/보상.
이유 1 (그들): 새 버전의 카드 유효성 검사기는 대기 시간을 1로 늘 렸습니다. 공급자에게 2 초 → 타임 아웃.
이유 2 (%): 공급자 "A" 에 대한 카나리아가 없었으며 릴리스는 즉시 100% 였습니다.
이유 3 (org): 비즈니스 SLI의 경고 임계 값은 특정 BIN 범위 (VIP 코호트) 를 다루지 않았습니다.
CAPA: 이전 버전의 유효성 검사기를 반환합니다. 카나리아 1/5/25% 입력; BIN 코호트에 의한 비즈니스 SLI 추가; 공급자 "B" 에 대한 장애에 30% 동의합니다. 혼돈 사건 "느린 업스트림".


11) RCA 프로세스 성숙도 지표

CAPA 완료 시간 (% 30 일 후에 종료)

재개 율 (90 일 만에 재개 된 사건).
실패율 변경 전/후.
체계적인 원인이 발견되는 사건의 비율 ("인간 오류" 뿐만 아니라).
RCA의 새로운 시나리오에 대한 테스트 범위.
릴리스 시간을보고하십시오 (게시 SLA).


12) 규제 도메인의 특징 (핀 테크/아이 게임 등)

외부에보고: 민감한 세부 사항이 없지만 반복을 방지 할 계획이있는 보고서의 클라이언트/규제 버전.
감사 로그 및 불변성: 아티팩트 저장, 서명 된 보고서, 티켓 링크, CMDB, 로그 해제.
사용자 데이터: 샘플 로그에서 개인화/마스킹.
통지 기간: 계약 및 규정 (예: 초기 통지 당 N 시간).


13) 반 패턴

"Vasya는 비난해야한다" -체계적인 이유없이 인간의 요소를 멈춘다.
가설 테스트 부족-직관에 의한 결론.
너무 일반적인 RCA ("서비스가 과부하되었습니다") -특정 변경 사항이 없습니다.
CAPA 또는 소유자/마감일이 없음-보고서를 위해보고하십시오.
정보 숨기기-신뢰 상실, 조직 교육 불능.
비 SLO/비즈니스 SLI 지표로 과부하.


14) 도구 및 실습

메타 데이터가있는 RCA 저장소 (위키/지식 기반): 서비스, SEV, 이유, CAPA, 상태.
템플릿 및 봇: 사고 (타임 라인, 그래프, 릴리스) 에서 보고서 프레임을 생성합니다.
인과 관계 그래프: 이벤트 인과 맵의 구성 (예: 로그/추적 기반).
카오스 카탈로그: 무대에서 과거 사건을 재현하기위한 스크립트.
"RCA 이후" 대시 보드: 개별 위젯으로 CAPA 효과를 확인합니다.


15) 점검표 "게시 준비"

  • 타임 라인과 인공물이 완성되고 검증되었습니다.
  • 테스트/실험으로 식별되고 입증 된 근본 원인.
  • 뿌리와 기여 원인이 분리되어 있습니다.
  • CAPA에는 소유자, 마감일, 측정 가능한 효과 지표가 포함되어 있습니다.
  • 14/30 일 안에 검증 계획이 있습니다.
  • 외부 이해 관계자를위한 버전이 준비되어 있습니다 (필요한 경우).
  • 보고서는 기술/백분율 검토를 통과했습니

16) 결론

RCA는 형식을 위해 회고하는 것이 아니라 시스템의 학습 메커니즘입니다. 사실이 수집되고 인과 관계가 입증되고 CAPA가 측정 항목에 고정되어 실험을 통해 테스트되면 조직이 더욱 안정적이됩니다. SLO가 더 안정적이고 재발 위험이 낮으며 사용자 및 규제 신뢰도가 높아집니다.

Contact

문의하기

질문이나 지원이 필요하시면 언제든지 연락하십시오.우리는 항상 도울 준비가 되어 있습니다!

통합 시작

Email — 필수. Telegram 또는 WhatsApp — 선택 사항.

이름 선택 사항
Email 선택 사항
제목 선택 사항
메시지 선택 사항
Telegram 선택 사항
@
Telegram을 입력하시면 Email과 함께 Telegram에서도 답변드립니다.
WhatsApp 선택 사항
형식: +국가 코드 + 번호 (예: +82XXXXXXXXX).

버튼을 클릭하면 데이터 처리에 동의하는 것으로 간주됩니다.