Skip to main content
근본 원인 분석(RCA)은 Deep Response Engine의 조사 엔진입니다. 전문 에이전트가 가설 기반 조사를 실행하고, 구조화된 증거 체인을 구축하며, 모든 추론 단계에 대한 완전한 가시성과 함께 수정 방안을 제안합니다.

조사 진행 방식

  1. 트리거Pulse 클러스터가 에스컬레이션되거나 인시던트 상세 페이지에서 수동으로 인시던트가 생성되면 조사가 시작됩니다. 클러스터 에스컬레이션은 클러스터 요약과 모든 멤버 신호를 에이전트의 컨텍스트에 주입하므로, 조사는 전체 신호 기록이 로드된 상태에서 시작됩니다. CloudThinker는 백그라운드에서 RCA 작업을 큐에 추가하고 전용 AI 대화를 엽니다.
  2. 에이전트 활성화Anna가 조사를 조율하고, 전문가들이 연결된 인프라를 기반으로 각 도메인을 담당합니다.
  3. 컨텍스트 수집 — 에이전트가 인프라 토폴로지를 탐색하고, 기준 메트릭을 수집하며, 영향받은 서비스를 식별하고, 최근 배포 및 구성 변경 사항을 검토합니다.
  4. 분석 — 에이전트가 경쟁 가설을 수립하고 로그, 트레이스, 의존성에 대해 각 가설을 검증합니다.
  5. 해결 — 확인된 가설이 근본 원인이 됩니다. 증거가 정리되고, 수정 제안이 생성되며, 신뢰도 점수와 함께 처분이 설정됩니다.
에이전트는 이러한 도메인 전반에서 병렬로 조사하고 실시간으로 발견 사항을 상관합니다. 증상이 근본 문제와 멀리 나타나는 경우에도 근본 원인을 파악합니다.

조사 단계

RCA는 구조화된 3단계 워크플로를 따릅니다. 에이전트가 새 단계로 이동하면 이전 단계가 아직 진행 중이면 자동으로 완료됩니다. 에이전트는 어떤 가설을 확인하기 전에 지지 증거를 수집하고 충분한 시간 동안 조사해야 합니다.
처분 설정은 조사를 종료하기 위해 필수입니다. 처분이 없으면 인시던트는 Investigating 상태로 남습니다.

증거 체인

RCA는 자동 계산과 함께 구조화된 증거 체인을 구축합니다. 각 항목은 특정 가설에 연결하여 어떤 발견이 각 이론을 지지하는지 표시할 수 있습니다. 증거는 심각도 순으로 정렬됩니다: Critical(직접 원인) → High(강력한 지지) → Medium(맥락) → Low(배경).

신뢰도 점수

식별된 모든 근본 원인은 0.0에서 1.0 사이의 신뢰도 점수를 가집니다. 신뢰도는 시간적 상관관계, 50% 편차를 초과하는 메트릭 이상, 일치하는 오류 패턴, 배제된 대안, 여러 corroborating 데이터 소스로 높아집니다. 대안적 설명, 약한 시간적 상관관계, 검증 누락, 상충하는 증거로 낮아집니다.

가설 추적

RCA는 “5 Whys” 및 Fishbone 방법론에서 영감을 받은 가설 기반 조사를 실행합니다. 에이전트는 근본 원인을 설정하기 전에 최소 하나의 가설을 확인하고, 조사를 종료하기 전에 확인되거나 배제된 모든 가설을 해결합니다. 지연 시간 인시던트의 가설 체인 예시:

조사 타임라인

RCA는 모든 조사 단계의 실시간 타임라인을 스트리밍하며, 타임스탬프와 함께 단계 진행, 가설 검증, 증거 수집을 표시합니다. 각 조사는 최대 100개의 항목을 보유합니다(데이터베이스 수준에서 적용).

처분(Disposition)

모든 조사는 인시던트 상태를 업데이트하는 처분으로 종료됩니다. 처분이 설정된 후, 팀이 후속 조치를 완료함에 따라 인시던트는 추가 라이프사이클 상태(Resolved, Post-Mortem, Closed)로 진행할 수 있습니다.

조사 시작

자동으로

웹훅 통합을 구성하여 RCA를 자동 트리거하세요. 인시던트가 심각도 임계값을 충족하면 조사가 백그라운드에서 시작됩니다:

수동으로

1

인시던트 상세 페이지 열기

조사할 인시던트를 선택합니다.
2

Start RCA Analysis 클릭

CloudThinker는 중복 RCA가 실행 중이지 않은지 확인한 다음, 1~3초 내에 조사를 시작합니다. 에이전트가 발견 사항을 발견함에 따라 타임라인 항목이 실시간으로 나타납니다.

결과 읽기

동일한 인시던트에 대해 버전 추적(v1, v2, v3…)으로 여러 조사를 실행할 수 있습니다. 새로운 정보가 제공되거나 첫 번째 실행이 결론에 이르지 못했을 때 RCA를 재실행하고 히스토리 드롭다운에서 결과를 비교하세요.

예시: EC2 종료 및 EKS 네트워크 장애

지속적인 모니터링을 통해 하나의 워크스페이스에서 두 가지 상호 연결된 발견 사항이 나타났습니다: 빈번한 EC2 인스턴스 종료와 EKS의 CreateNetworkInterface 실패. 에이전트가 이를 함께 조사하는 방법입니다. 먼저, Alex가 종료 패턴을 분석합니다:
AutoScaling 이벤트와 타임라인을 보여주는 EC2 종료 패턴 분석

AutoScaling 이벤트를 보여주는 EC2 종료 패턴 분석

다음으로, Alex가 네트워크 장애와 종료를 교차 상관합니다:
CreateNetworkInterface 오류 및 IP 고갈이 있는 네트워크 장애 상관 분석

CreateNetworkInterface 오류 및 IP 고갈과의 네트워크 장애 상관 분석

마지막으로, Anna가 Alex(인프라 및 비용), Kai(EKS 네트워킹), Oliver(보안)의 발견 사항을 하나의 문서로 종합합니다:
발견 사항, 수정 단계, 예방 조치가 있는 종합 RCA 보고서

발견 사항 및 수정 단계가 있는 종합 RCA 보고서

모범 사례

  • 인시던트 발생 전에 토폴로지를 연결하세요 — 피해 반경 분석과 서비스 상관 관계가 여기에 의존합니다.
  • Medium 이상 심각도의 인시던트에 대해 RCA를 자동 트리거하도록 웹훅을 구성하세요.
  • 인시던트 설명에 컨텍스트를 추가하세요; 에이전트가 어디를 먼저 볼지 안내합니다.
  • 조사 중에 타임라인을 확인하여 어떤 가설이 검증되고 배제되었는지 추적하고, 증거 타임스탬프가 인시던트 시작과 상관관계가 있는지 확인하세요.
  • 신뢰도가 0.7 미만일 때는 수정하기 전에 근본 원인을 수동으로 검증하고, critical 우선순위 수정 조치부터 시작하세요.
  • Runbooks를 연결하여 에이전트가 향후 조사 중에 수정 절차를 찾아 실행할 수 있도록 하세요.

관련 문서

Pulse

노이즈를 억제하고 실행 가능한 클러스터를 인시던트로 에스컬레이션하는 업스트림 신호 인텔리전스

웹훅 통합

PagerDuty, Datadog, Prometheus 등에서 RCA 자동 트리거

토폴로지

인시던트 중 더 빠른 피해 반경 분석을 위한 실시간 의존성 맵 구축

Runbooks

에이전트가 수정 단계를 실행할 수 있도록 운영 Runbook 연결