---
name: incident-triage
description: >
  서비스 장애, 지연·오류 증가, 작업 중단과 배포 실패를 조사할 때 쓴다.
  실제 환경의 지표·로그·상태·변경 이력을 연결해 원인, 완화책과 검증 방법을 제시한다.
  조사는 읽기 전용이며 변경 실행은 사용자가 요청한 운영 절차를 따른다.
---

# 서비스 장애 조사

증상이 나타난 시스템과 시간창에서 시작한다. 클라우드, 클러스터, 서버, 관리형 서비스,
배치 중 실제 대상에 맞는 관측을 선택하며 특정 공급자나 배포 방식을 전제하지 않는다.

## 대상과 관측

요청과 제공 자료에서 증상, 정상 기준, 영향 범위, 최초 이상 시각, 최근 변경과 지속 여부를
확인한다. 계정·환경·서비스 식별자는 실제 설정에서 얻는다. 결과를 바꿀 대상이 모호할 때만
질문하고 독립적으로 확인 가능한 읽기는 계속한다.

시각에는 시간대를 붙인다. 장애 시작점과 데이터 보존·해상도에 맞게 좁은 시간창에서 시작해
필요한 방향으로 넓힌다. 일간·주간 주기가 있으면 같은 주기의 정상 구간과 비교한다.

| 질문 | 필요한 관측 |
|---|---|
| 누구에게 어떤 실패가 발생했는가 | 오류율·지연·실패 작업 수·사용자 영향 |
| 어디서 실패하는가 | 요청 경로·로그·trace·프로세스나 리소스 상태 |
| 언제 무엇이 바뀌었는가 | 배포·설정·데이터·트래픽·의존 서비스 이력 |
| 정상 대상과 무엇이 다른가 | 같은 기간·조건의 정상 인스턴스·지역·버전 |
| 어느 경계가 아직 보이지 않는가 | 외부 서비스·네트워크·스토리지·권한의 추가 증거 |

현재 제공된 도구와 schema를 사용한다. 특정 관측 도구가 없으면 제공 로그와 자료로 조사하고
미관측 범위를 남긴다. Kubernetes나 AWS가 대상일 때만
[references/kubernetes-aws.md](references/kubernetes-aws.md)를 읽는다.

## 조사

1. 영향 범위를 측정하고 같은 조건의 정상 대조군을 찾는다.
2. 지표·로그·상태 전이와 변경 이력을 최초 이상 시각 앞뒤로 정렬한다.
3. 각 가설의 예상 관측, 지지 증거, 반증과 다음 확인을 정한다.
4. 원인을 시작시킨 계기, 실패가 발생한 경로, 영향을 키운 요인을 구분한다.
5. 새 관측이 가설을 지지하는지 확인하고 다음 조회가 더 이상 정보를 늘리지 않으면
   현재 판정과 필요한 추가 접근·자료를 보고한다.

관측·해석·미확인을 구분하고 사실에 출처와 시간창을 붙인다. 같은 원본에서 파생된 알람과
대시보드를 독립 증거로 세지 않는다. 단순한 시간적 상관관계만으로 원인을 확정하지 않는다.

쿼리는 대상과 시간창을 좁히고 페이지·잘림·보존 기간·비용 한계를 확인한다. 오류나 조회 실패를
정상·빈 결과로 바꾸지 않는다. 같은 실패 호출은 입력이나 접근 조건을 고칠 근거가 있을 때만 재시도한다.

## 판정과 대응

- 확인됨: 관측된 실패 경로가 시각과 영향 범위를 설명하고 반증·대조군에도 모순이 없다.
- 유력함: 증거가 일치하지만 결정적인 상태·이력·재현이나 복구 후 확인이 빠졌다. 빠진 근거를 적는다.
- 미확인: 증상만 확인했거나 여러 가설을 가를 수 없다. 가장 유용한 다음 조회를 제시한다.

즉시 완화와 근본 해결을 구분하고 대상·예상 효과·위험·검증·되돌리는 방법을 붙인다.
재발 방지는 확인된 실패와 직접 관련된 것만 제안한다. GitOps 관리 대상의 변경 실행을
요청받았으면 연결된 `gitops-change`를 사용한다. 다른 대상은 해당 시스템의 변경 절차를 따른다.
스킬이 없으면 확인한 절차와 권한 범위에서 진행하며 없는 도구를 가정하지 않는다.

조사 요청만으로 운영 상태를 변경하지 않는다. 실제 실행에는 사용자가 허가한 대상과 조치만
포함하고 이미 받은 권한은 다시 묻지 않는다.

## 보고

결론과 영향, 핵심 타임라인·증거, 원인 판정의 근거와 불확실성, 대응과 다음 확인을 적는다.
짧은 조사는 문단으로 충분하다. 원인을 찾지 못했으면 미확인으로 보고하고 관측하지 못한
시스템을 정상으로 표시하지 않는다. 로그 전문 대신 판단에 필요한 문맥만 인용한다.