Production-like·Blind Corpus로 RCA 품질을 분리 검증하기

Rule을 만든 사람이 정답도 함께 보면 생기는 문제

Golden scenario를 이용한 회귀 테스트는 Detector를 빠르게 검증하는 데 유용하다. 하지만 입력 파일 안에 장애 이름과 기대 신호가 함께 있으면 테스트 구조가 구현에 맞춰질 수 있다.

또한 합성된 정상·장애 사례에서 precision과 recall이 높다고 해서 실제 운영 정확도가 높다고 말할 수는 없다. 그래서 RCA 품질 검증을 세 단계로 분리했다.

Golden Scenario
  → Production-like Corpus
  → Blind Evaluation

각 단계는 같은 Rule Engine을 실행하지만 데이터의 목적과 관리 경계가 다르다.

Golden Scenario

Golden fixture는 특정 Signal과 Rule의 기본 회귀를 빠르게 확인한다. DiskPressure, DNS latency, conntrack과 같은 대표 장애에서 기대 신호가 유지되는지 본다.

평가는 단순 통과 개수가 아니라 precision, recall과 Top-K hit rate를 사용한다. Rule을 추가해 recall을 높였지만 정상 사례의 false positive가 늘어나는 문제를 함께 확인하기 위해서다.

Production-like Corpus

다음 단계는 실제 Agent E2E 산출물의 필드 구조를 바탕으로 만든 비식별 재현 corpus다. 실제 Cluster ID, 주소, 시각과 로그 원문은 포함하지 않고 문서용 주소와 합성 로그를 사용한다.

13개 Scenario에는 다음 변형을 넣었다.

• 정상 containerd와 CRI-O
• 임계값 바로 아래와 정확히 같은 경계값
• Disk 장애 전파
• conntrack·DNS 복합 장애
• etcd·API Server 지연
• journal 접근 저하와 file fallback
• 잘린 로그와 순서가 바뀐 kernel/eBPF event

Positive Scenario뿐 아니라 정상 Negative가 모두 통과해야 한다. 장애를 잘 찾는 것만큼 정상 상태를 장애로 만들지 않는 것이 중요하기 때문이다.

Blind Evaluation에서 입력과 Label 분리하기

Blind Evaluation은 Evidence와 정답 파일을 물리적으로 분리했다.

Evidence에는 opaque case ID와 platform, runtime, 수집 window, Collector만 들어간다. 장애 이름, expected signal, root cause와 label을 추정할 수 있는 설명은 허용하지 않는다.

실행 순서도 고정했다.

Evidence 계약 검사
  → 19개 Case의 Detector 결과 확정
  → Sealed Label 로드
  → Case ID로만 결합
  → 품질 Report 생성

Report에는 label_loaded_after_detection=true, 입력과 Label의 SHA-256을 남긴다. Forbidden Signal이 하나라도 검출되면 Gate를 실패시킨다.

왜 이것도 완전한 외부 Blind Test는 아닌가

입력과 Label을 분리했지만 같은 저장소에서 관리하는 비식별 Holdout 데이터다. Analyzer가 Label을 직접 입력받지 않는다는 점은 확인할 수 있지만, 실운영 정확도나 독립적인 외부 평가로 과장할 수 없다.

이 한계를 문서와 결과에 명시했다. 좋은 숫자를 얻기 위해 평가의 범위를 넓혀 말하지 않는 것이 중요했다.

Managed Sample 승격 절차

실제 managed Cluster Canary에서 Collector-only Candidate를 만들 수 있도록 별도 Intake를 추가했다.

Candidate 생성 시 다음 정보를 제외한다.

• 기존 Signal과 RCA Report
• Timeline과 Action Plan
• Cluster·Node·Report·Incident 식별자
• IP, Credential과 Kubernetes Raw Metadata

두 명의 독립 판정자가 Analyzer 결과를 보지 않은 상태에서 같은 분류와 Signal에 합의해야 Label을 봉인할 수 있다. Evidence와 Label의 canonical SHA-256을 Manifest에 기록하되 Corpus를 자동 변경하지 않는다.

최종 승격에는 Platform Owner와 별도 평가 담당자가 검토한 PR이 필요하다. Canary 성공 횟수나 Candidate 개수를 정확도 지표로 사용하지 않는다.

이 구조를 만든 이유

RCA 품질은 하나의 테스트 파일과 하나의 백분율로 설명하기 어렵다. 그래서 각 숫자가 무엇을 의미하고 무엇을 의미하지 않는지 함께 남겼다.

• Golden: Rule 회귀
• Production-like: 운영 형태의 비식별 재현
• Blind: Label 분리와 Holdout 검증
• Managed Candidate: 실제 환경 표본을 안전하게 승격하기 위한 절차

평가 데이터까지 운영 자산으로 보고 변경 이력, 비식별화와 승인 경계를 적용한 것이 이번 단계의 핵심이었다.

프로젝트 저장소: Kubernetes Cluster Infra RCA Platform