Atlas / Skills / revfactory / Rca Methodology

Rca MethodologySAFE

skills/revfactory/rca-methodology
Verdict
SAFE
Grade
B
Trust score
89 /100
Version
—
Hosts
—
License
Apache-2.0
Stars
1,297
01

Overview

An agent skill published by revfactory.

Read from source at commit 459e1bb8f76eOBSERVED · 2026-10-12
02

What it tells the agent

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: rca-methodology
description: "근본원인 분석(RCA) 방법론 상세 가이드. 5 Whys, 피시본 다이어그램, Fault Tree Analysis, 변경점 분석 등 구조화된 RCA 기법과 인지 편향 방지 체크리스트. '근본원인 분석', 'RCA', '5 Whys', '피시본', 'Fault Tree', '원인 분석 방법론', '변경점 분석' 등 장애 원인 분석 시 이 스킬을 사용한다. root-cause-investigator의 분석 역량을 강화한다. 단, 타임라인 재구성이나 재발방지 대책 수립은 이 스킬의 범위가 아니다."
---

# RCA Methodology — 근본원인 분석 방법론 가이드

장애의 근본원인을 체계적으로 추적하는 구조화된 분석 기법 모음.

## 1. 5 Whys 기법

### 수행 절차
```
문제: 결제 서비스가 30분간 다운되었다.

Why 1: 왜 결제 서비스가 다운되었나?
→ DB 커넥션 풀이 소진되었다.

Why 2: 왜 커넥션 풀이 소진되었나?
→ 느린 쿼리가 커넥션을 장시간 점유했다.

Why 3: 왜 느린 쿼리가 발생했나?
→ 인덱스 없이 전체 테이블 스캔을 수행했다.

Why 4: 왜 인덱스가 없었나?
→ 신규 기능 배포 시 마이그레이션에 인덱스 추가를 누락했다.

Why 5: 왜 인덱스 누락을 감지하지 못했나?
→ 쿼리 성능 검증이 배포 파이프라인에 포함되지 않았다.

근본원인: 배포 파이프라인에 쿼리 성능 검증 단계 부재
```

### 5 Whys 주의사항

| 함정 | 설명 | 방지법 |
|------|------|--------|
| 너무 일찍 멈춤 | 2~3단계에서 원인 확정 | "이것을 고치면 재발 방지되나?" 검증 |
| 비난으로 귀결 | "누가 실수했나"로 끝남 | 시스템/프로세스 원인에 집중 |
| 단일 경로만 추적 | 복합 원인 놓침 | 각 단계에서 분기 검토 |
| 추측 기반 답변 | 증거 없는 가설 | 로그/메트릭으로 검증 |

## 2. 피시본 다이어그램 (Ishikawa)

```
                    ┌─ 사람 ──────── 배포 담당자 교육 부족
                    │                 코드 리뷰 생략
                    │
                    ├─ 프로세스 ──── 배포 체크리스트 미준수
                    │                 성능 테스트 미실시
                    │
결제 서비스 다운 ←──┼─ 기술 ──────── 인덱스 누락
                    │                 커넥션 풀 사이즈 부족
                    │
                    ├─ 환경 ──────── 프로덕션 데이터 규모 미반영
                    │                 스테이징 환경 불일치
                    │
                    └─ 모니터링 ──── 느린 쿼리 알림 미설정
                                     DB 메트릭 대시보드 부재
```

### 6M 카테고리 (소프트웨어 적용)

| 전통 6M | 소프트웨어 적용 | 조사 항목 |
|---------|---------------|----------|
| Man | 사람/팀 | 교육, 커뮤니케이션, 온콜 체계 |
| Method | 프로세스 | 배포 절차, 변경 관리, 승인 흐름 |
| Machine | 기술/인프라 | 서버, DB, 네트워크, 코드 |
| Material | 데이터/입력 | 입력 데이터, 외부 API 응답 |
| Measurement | 모니터링 | 알림, 메트릭, 로그, 트레이싱 |
| Environment | 환경 | 설정, 환경변수, 의존 서비스 |

## 3. Fault Tree Analysis (FTA)

```
                    결제 서비스 장애 (Top Event)
                          │
                    ┌─────┤ OR ├─────┐
                    │               │
              DB 장애            애플리케이션 장애
                │                    │
          ┌─────┤ OR ├─────┐    ┌───┤ AND ├───┐
          │               │    │             │
    커넥션 풀 소진    디스크 풀  느린 쿼리   높은 트래픽
          │                        │
    ┌─────┤ AND ├─────┐     ┌─────┤ OR ├─────┐
    │               │     │               │
 인덱스 누락    대량 데이터  신규 코드 배포  스키마 변경
```

**확률 계산:**
```
OR 게이트:  P(A OR B)  = 1 - (1-P(A)) × (1-P(B))
AND 게이트: P(A AND B) = P(A) × P(B)

예: P(느린쿼리)=0.3, P(높은트래픽)=0.2
    P(앱장애) = 0.3 × 0.2 = 0.06 (6%)
```

## 4. 변경점 분석 (Change Analysis)

```markdown
장애 발생 전후 변경 사항 조사:

| 변경 시점 | 변경 내용 | 변경자 | 영향 범위 | 장애 상관 |
|----------|----------|--------|----------|----------|
| T-2h | 결제 API v2.3 배포 | 김개발 | 결제 서비스 | ✅ 높음 |
| T-1h | Redis 설정 변경 | 박운영 | 캐시 서비스 | ❓ 중간 |
| T-30m | CDN 캐시 퍼지 | 이마케팅 | 프론트엔드 | ❌ 낮음 |

상관 관계 판단 기준:
1. 시간적 근접성: 변경 시점 ↔ 장애 발생 시점
2. 범위 일치: 변경 범위 ↔ 장애 영향 범위
3. 롤백 효과: 변경 롤백 시 장애 해소 여부
```

## 인지 편향 방지 체크리스트

| 편향 | 설명 | 방지법 |
|------|------|--------|
| **확증 편향** | 첫 가설에 맞는 증거만 수집 | 반례를 적극적으로 찾기 |
| **사후 확신 편향** | "당연히 이게 원인이지" | 당시 시점의 정보만으로 판단 |
| **가용성 편향** | 최근 경험한 유사 장애와 동일시 | 증거 기반 분석 강제 |
| **기본 귀인 오류** | 사람 탓으로 귀결 | 시스템/프로세스 원인 우선 |
| **앵커링** | 첫 보고 내용에 고착 | 다수 관점에서 독립적 분석 |

## RCA 기법 선택 가이드

| 상황 | 추천 기법 | 이유 |
|------|----------|------|
| 단순 장애, 빠른 분석 필요 | 5 Whys | 경량, 즉시 수행 가능 |
| 복합 원인 의심 | 피시본 | 다차원 원인 탐색 |
| 안전 관련 심각 장애 | FTA | 정량적, 체계적 |
| 배포 직후 장애 | 변경점 분석 | 원인 후보 좁히기 |
| 모든 경우 | 5 Whys + 변경점 분석 병행 | 빠르면서도 체계적 |
03

Trust audit

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

LayerWhat it checksResult
L0Provenance & inventoryPASS
L1Static analysis of the codeNA
L2Instruction surface (what it tells the agent)PASS
L3Class-specific surfacePASS
L4Behavioural (sandbox)SKIPPED

What the source does

Filesystem
none-observed
Network
none-observed
Shell
none-observed
Dependencies
pinned
Secrets in source
none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.

Audited 2026-10-12 · audit v0.4.1 · source sha 459e1bb8f76efull audit observations/trust-audit/skill/revfactory__rca-methodology.json · Report an issue / request a re-scan
04

Audit history

Every audit this skill has had.

DateSourceVerdictGradeScoreChange
2026-10-12459e1bb8f76eSAFEB89first audit
05

Questions

Is Rca Methodology safe to install?

The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.

What can Rca Methodology access on my machine?

The audit observed no filesystem, network or shell use at all in its source.

How current is this page?

The grade is for one exact copy of the source (459e1bb8f76e), read on 2026-10-12. The repository is watched, and a new audit runs when it changes — this is the first audit.

Advertisement