조사 진행 방식
- 트리거 — Pulse 클러스터가 에스컬레이션되거나 인시던트 상세 페이지에서 수동으로 인시던트가 생성되면 조사가 시작됩니다. 클러스터 에스컬레이션은 클러스터 요약과 모든 멤버 신호를 에이전트의 컨텍스트에 주입하므로, 조사는 전체 신호 기록이 로드된 상태에서 시작됩니다. CloudThinker는 백그라운드에서 RCA 작업을 큐에 추가하고 전용 AI 대화를 엽니다.
- 에이전트 활성화 — Anna가 조사를 조율하고, 전문가들이 연결된 인프라를 기반으로 각 도메인을 담당합니다.
- 컨텍스트 수집 — 에이전트가 인프라 토폴로지를 탐색하고, 기준 메트릭을 수집하며, 영향받은 서비스를 식별하고, 최근 배포 및 구성 변경 사항을 검토합니다.
- 분석 — 에이전트가 경쟁 가설을 수립하고 로그, 트레이스, 의존성에 대해 각 가설을 검증합니다.
- 해결 — 확인된 가설이 근본 원인이 됩니다. 증거가 정리되고, 수정 제안이 생성되며, 신뢰도 점수와 함께 처분이 설정됩니다.
에이전트는 이러한 도메인 전반에서 병렬로 조사하고 실시간으로 발견 사항을 상관합니다. 증상이 근본 문제와 멀리 나타나는 경우에도 근본 원인을 파악합니다.
조사 단계
RCA는 구조화된 3단계 워크플로를 따릅니다. 에이전트가 새 단계로 이동하면 이전 단계가 아직 진행 중이면 자동으로 완료됩니다.| 단계 | 목표 | 활동 |
|---|---|---|
| 1. 컨텍스트 수집 | 기준 조건 설정 | 토폴로지를 통해 영향받은 서비스 및 의존성 매핑; CloudWatch, Prometheus, Datadog에서 메트릭 수집; 인시던트 메트릭을 역사적 기준선과 비교; 최근 배포 및 구성 변경 식별 |
| 2. 분석 및 가설 검증 | 근본 원인 범위 좁히기 | 증상에서 경쟁 이론 생성; 로그, 트레이스, 의존성, 리소스 증거 수집; 증거가 모순되는 가설 배제; 증거가 쌓임에 따라 신뢰도 추적 |
| 3. 해결 | 증거와 함께 근본 원인 확정 | 나머지 모든 가설 해결; 승자를 근본 원인으로 확인; 가장 강력한 증거 정리; 수정 단계 생성; 처분 및 신뢰도 점수 설정 |
처분 설정은 조사를 종료하기 위해 필수입니다. 처분이 없으면 인시던트는 Investigating 상태로 남습니다.
증거 체인
RCA는 자동 계산과 함께 구조화된 증거 체인을 구축합니다. 각 항목은 특정 가설에 연결하여 어떤 발견이 각 이론을 지지하는지 표시할 수 있습니다.| 증거 유형 | 포착 내용 | 필드 |
|---|---|---|
| 메트릭 | 자동 계산된 편차 백분율과 함께 인시던트 대 기준선 비교 — 예: “CPU 95% 대 기준선 25% = 280% 편차” | incident_value, baseline_value, baseline_period, threshold, unit |
| 배포 및 변경 | 인시던트 시작으로부터 자동 계산된 시간 델타가 있는 최근 변경; 양의 델타 = 인시던트 이전(원인 가능성) | type, description, timestamp, correlation, service |
| 로그 | CloudWatch, Splunk, Datadog 등 로그 콘솔로의 딥 링크가 포함된 관련 로그 항목 | source, description, deep_link, timestamp, severity |
| 트레이스 | 요청 흐름 및 지연 시간 분석을 보여주는 분산 트레이스 데이터 | source, description, raw_data |
| 구성 | 정확한 매개변수 수정이 포함된 구성 변경 | source, description, timestamp |
| 알림 | 인시던트 기간 동안 모니터링 시스템의 관련 알림 | source, severity, description |
신뢰도 점수
식별된 모든 근본 원인은 0.0에서 1.0 사이의 신뢰도 점수를 가집니다.| 점수 범위 | 카테고리 | 의미 | 조치 |
|---|---|---|---|
| 0.9 – 1.0 | 매우 높음 | 압도적인 증거로 근본 원인 식별 | 즉시 수정 조치 시행 |
| 0.7 – 0.9 | 높음 | 강력한 증거로 근본 원인 식별 | 일반 우선순위로 수정 조치 시행 |
| 0.5 – 0.7 | 중간 | 가능성 높은 근본 원인이나 갭 존재 | 수정 조치 시행; 대안 모니터링 |
| 0.3 – 0.5 | 낮음 | 가능한 근본 원인이나 증거가 정황적 | 조치 전 수동으로 발견 사항 검증 |
| 0.0 – 0.3 | 불확실 | 근본 원인 특정에 충분한 증거 없음 | 판단 불가; NOT_FOUND 고려 |
가설 추적
RCA는 “5 Whys” 및 Fishbone 방법론에서 영감을 받은 가설 기반 조사를 실행합니다.| 상태 | 의미 |
|---|---|
| Investigating | 이론을 검증하기 위한 증거 활발히 수집 중 |
| Confirmed | 충분한 증거가 이것을 근본 원인으로 지지 |
| Ruled out | 증거가 가설을 모순하거나 반증 |
조사 타임라인
RCA는 모든 조사 단계의 실시간 타임라인을 스트리밍하며, 타임스탬프와 함께 단계 진행, 가설 검증, 증거 수집을 표시합니다. 각 조사는 최대 100개의 항목을 보유합니다(데이터베이스 수준에서 적용).| 항목 유형 | 의미 |
|---|---|
info | 일반 조사 메모 |
finding | 분석에 영향을 미치는 특정 발견 |
warning | 검증이 필요한 잠재적 문제 |
error | 실패한 조사 시도 |
success | 확인된 발견 |
hypothesis_created | 새로운 이론 제안 |
hypothesis_ruled_out | 이론 반증 |
hypothesis_confirmed | 가설이 근본 원인으로 검증됨 |
처분(Disposition)
모든 조사는 인시던트 상태를 업데이트하는 처분으로 종료됩니다.| 처분 | 의미 | 재개 가능? |
|---|---|---|
IDENTIFIED | 지지 증거와 함께 근본 원인 발견 | 아니오 (최종) |
NOT_FOUND | 조사 완료, 명확한 근본 원인 없음 | 아니오 (최종) |
FALSE_ALARM | 실제 인시던트가 아니었음 | 아니오 (최종) |
ON_HOLD | 외부 입력 또는 추가 데이터 대기 중 | 예 — 새 정보 도착 시 재개 |
조사 시작
자동으로
웹훅 통합을 구성하여 RCA를 자동 트리거하세요. 인시던트가 심각도 임계값을 충족하면 조사가 백그라운드에서 시작됩니다:수동으로
결과 읽기
| 섹션 | 표시 내용 |
|---|---|
| 근본 원인 요약 | 신뢰도 점수 및 식별 타임스탬프와 함께 근본 원인의 명확한 설명 |
| 가설 추적 | 생성 → 검증 → 확인 또는 배제 라이프사이클과 추론이 있는 모든 가설 |
| 증거 체인 | 유형별로 정리된 증거, 심각도 랭킹, 소스 귀속, 딥 링크 |
| 조사 타임라인 | 조사 단계 및 단계 전환의 시간순 로그 |
| 수정 조치 | 우선순위 수준(critical, high, medium, low)이 있는 제안된 수정 방법 |
| 영향받은 서비스 | 인시던트 중 영향받은 서비스, 토폴로지가 연결된 경우 피해 반경 시각화 |
예시: EC2 종료 및 EKS 네트워크 장애
지속적인 모니터링을 통해 하나의 워크스페이스에서 두 가지 상호 연결된 발견 사항이 나타났습니다: 빈번한 EC2 인스턴스 종료와 EKS의CreateNetworkInterface 실패. 에이전트가 이를 함께 조사하는 방법입니다.
먼저, Alex가 종료 패턴을 분석합니다:

AutoScaling 이벤트를 보여주는 EC2 종료 패턴 분석
다음으로, Alex가 네트워크 장애와 종료를 교차 상관합니다:
CreateNetworkInterface 오류 및 IP 고갈과의 네트워크 장애 상관 분석
마지막으로, Anna가 Alex(인프라 및 비용), Kai(EKS 네트워킹), Oliver(보안)의 발견 사항을 하나의 문서로 종합합니다:
발견 사항 및 수정 단계가 있는 종합 RCA 보고서
모범 사례
- 인시던트 발생 전에 토폴로지를 연결하세요 — 피해 반경 분석과 서비스 상관 관계가 여기에 의존합니다.
- Medium 이상 심각도의 인시던트에 대해 RCA를 자동 트리거하도록 웹훅을 구성하세요.
- 인시던트 설명에 컨텍스트를 추가하세요; 에이전트가 어디를 먼저 볼지 안내합니다.
- 조사 중에 타임라인을 확인하여 어떤 가설이 검증되고 배제되었는지 추적하고, 증거 타임스탬프가 인시던트 시작과 상관관계가 있는지 확인하세요.
- 신뢰도가 0.7 미만일 때는 수정하기 전에 근본 원인을 수동으로 검증하고, critical 우선순위 수정 조치부터 시작하세요.
- Runbooks를 연결하여 에이전트가 향후 조사 중에 수정 절차를 찾아 실행할 수 있도록 하세요.
관련 문서
Pulse
노이즈를 억제하고 실행 가능한 클러스터를 인시던트로 에스컬레이션하는 업스트림 신호 인텔리전스
웹훅 통합
PagerDuty, Datadog, Prometheus 등에서 RCA 자동 트리거
토폴로지
인시던트 중 더 빠른 피해 반경 분석을 위한 실시간 의존성 맵 구축
Runbooks
에이전트가 수정 단계를 실행할 수 있도록 운영 Runbook 연결