# 런북 (대응 절차) · 문의 일괄 접수

- 이름:
- 이 파일을 `my-work/RUNBOOK.md`로 복사해 채웁니다. **새벽 3시에 처음 보는 사람도 따라 할 수 있게** 씁니다.

## 1. 실패의 종류 (Lab 01 · 02)

### 1.1 기준 워크플로우에서 본 것 (Lab 01 예제 1)

| 한 일 | 사용자가 본 것 | 실제로 생긴 것 |
| --- | --- | --- |
| 빈 글이 섞인 3건 |  |  |
| `flaky`에서 2건 |  |  |
| 정상 3건을 다시 |  |  |

### 1.2 고장 종류마다 (Lab 01 예제 3 · `cases/lab01-faults.json`)

| 고장 | 걸린 시간 | 결과 | 실제로 생긴 접수 건 |
| --- | --- | --- | --- |
| `flaky` |  |  |  |
| `error` |  |  |  |
| `slow` |  |  |  |

### 1.3 그물 지도 (Lab 02 예제 3 · `cases/lab02-nets.json`)

| 실패 | 어떻게 알아채나 | 자동으로 하는 일 | 사람이 할 일 |
| --- | --- | --- | --- |
| 잘못된 항목 · 같은 id · 10건 넘음 | 결과의 `rejected` · 400 | 그 항목만 거절 · 전체 거절, 이유 | 요청한 사람에게 이유 전달 |
| API가 잠깐 실패 | (없음) | 재시도 3번 |  |
| API가 멈춤 | 알림 `high · dlq` (10분에 한 번) | DLQ에 넣음 |  |
| DLQ도 멈춤 | 알림 `critical · dlq_down` (잃을 뻔한 id) | 결과 `dlq_saved: false` |  |
| LLM이 멈춤 | 결과의 `unclassified` | 미분류로 접수 |  |
| 예상 못 한 오류 | 알림 `critical · unexpected` | Error Workflow |  |
| 세 번 넘게 실패 | 알림 `high · parked` | 재처리에서 뺌 |  |

### 1.4 알림 등급

| 등급 | 무엇 | 받으면 몇 분 안에 | 누가 |
| --- | --- | --- | --- |
| `critical` |  |  |  |
| `high` |  |  |  |

## 2. 알림을 받으면 (순서대로)

1. `uv run tools/flow.py ops`로 고장 스위치 · DLQ · 알림 확인 (또는 `curl -s -XPOST localhost:5678/webhook/my-ops-status -d '{}'`)
2. 
3. 
4. 고친 뒤 `curl -s -XPOST localhost:5678/webhook/my-replay -d '{}'` (재처리)
5. `ops`로 DLQ가 비었는지, 접수 건이 **중복 없이** 생겼는지

**하지 말 것**:

- 

## 3. 장애 연습 기록 (Lab 03 예제 2 · `cases/lab03-drill.json`)

| 단계 | 한 일 | 본 것 | 걸린 시간 |
| --- | --- | --- | --- |
| 장애 시작 |  |  |  |
| 알아챔 |  |  |  |
| 원인 |  |  |  |
| 고침 |  |  |  |
| 재처리 · 확인 |  |  |  |

런북에서 빠졌던 단계:

## 4. 연락처 · 책임

| 무엇 | 누구 | 언제까지 |
| --- | --- | --- |
| 1차 대응 |  |  |
| 데이터 API 담당 |  |  |
| parked 건 확인 · 결정 |  |  |