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 개수를 정확도 지표로 사용하지 않는다.

이 구조를 만든 이유

같은 통과율이라도 평가 데이터에 따라 확인한 내용이 다르다. 그래서 결과를 아래 네 범위로 나눠 기록했다.

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

평가 데이터에도 변경 이력과 비식별화 기준을 남겼다. 실제 환경의 Candidate를 Corpus로 옮길 때는 별도 검토와 승인 절차를 거치도록 했다.

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