테스트 인시던트 대응
gate failure를 릴리즈 판단 시스템 인시던트로 다루고 triage, release hold, rollback을 연결하는 방법
red build는 단순한 테스트 실패가 아니라 릴리즈 의사결정을 멈추는 운영 이벤트입니다. 인시던트 대응이 느리면 제품 버그보다 테스트 환경이 더 큰 병목이 됩니다.
심각도 분류
| 등급 | 예시 | 기본 조치 |
|---|---|---|
| Sev1 | release gate blocker, canary safe probe 실패 | release hold, 즉시 triage |
| Sev2 | main critical suite 연속 실패 | owner 호출, 원인 분류 |
| Sev3 | nightly full suite 일부 실패 | ticket 발행, 다음 영업일 triage |
triage 절차
- 변경 범위 확인: 앱 변경, 환경 변경, 테스트 변경, 모델/프롬프트 변경을 분리합니다.
- evidence 확인: trace, screenshot, network, console, event log를 먼저 봅니다.
- 재현 분류: local sandbox, preview, integration, prod-like 중 어디서 같은지 확인합니다.
- 원인 분류: product, test, data, infra, external, model로 라벨링합니다.
- 조치 결정: fix, quarantine, release hold, rollback 중 하나를 선택합니다.
10분 안에 답해야 하는 질문
- 실패가 릴리즈 blocker 정의와 직접 연결되는가?
- 같은 증상이 로컬 sandbox에서도 재현되는가?
- environment fingerprint가 이전 성공 run과 무엇이 다른가?
- evidence만으로 rollback 판단에 필요한 사실이 충분한가?
커뮤니케이션 기본 템플릿
[TestOps Sev1] release gate 실패
- gate: release
- probe: critical-checkout / browser
- 영향: 릴리즈 보류
- 최초 감지: 14:12 KST
- 현재 분류: Product Regression 추정
- owner: Payments team / QA Platform
- 다음 업데이트: 15분 후release hold 해제 조건
- blocker probe가 green으로 복구됨
- 또는 예외 승인 문서가 생성되고 release manager가 승인함
- 또는 문제 scope가 release 대상과 무관함이 evidence로 증명됨
rollback 판단 질문
- 실패가 제품 회귀인가, 테스트/환경 문제인가?
- 이미 canary나 production metric 이상과 같이 나타나는가?
- hotfix로 빨리 고칠 수 있는가, 아니면 즉시 되돌려야 하는가?
- evidence bundle이 rollback 사유를 충분히 설명하는가?
postmortem에 남겨야 할 항목
- 감지 시각
- triage 시작 시각
- environment fingerprint
- root cause
- temporary mitigation
- permanent fix
- 같은 유형의 재발 방지 액션
운영 팁
- red build는 "누가 잘못했는가"보다 "릴리즈 판단에 어떤 정보가 필요한가" 중심으로 다룹니다.
- 인시던트 채널에는 장황한 로그보다 현재 분류 / 영향 / 다음 액션을 짧게 업데이트합니다.
- agent가 patch를 제안하더라도 hold 해제는 evidence와 human gate를 기준으로 판단해야 합니다.