74 lines
2.5 KiB
Markdown
74 lines
2.5 KiB
Markdown
# 런북 (대응 절차) · 문의 일괄 접수
|
|
|
|
- 이름:
|
|
- 이 파일을 `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 건 확인 · 결정 | | |
|