2.5 KiB
2.5 KiB
런북 (대응 절차) · 문의 일괄 접수
- 이름:
- 이 파일을
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. 알림을 받으면 (순서대로)
uv run tools/flow.py ops로 고장 스위치 · DLQ · 알림 확인 (또는curl -s -XPOST localhost:5678/webhook/my-ops-status -d '{}')- 고친 뒤
curl -s -XPOST localhost:5678/webhook/my-replay -d '{}'(재처리) ops로 DLQ가 비었는지, 접수 건이 중복 없이 생겼는지
하지 말 것:
3. 장애 연습 기록 (Lab 03 예제 2 · cases/lab03-drill.json)
| 단계 | 한 일 | 본 것 | 걸린 시간 |
|---|---|---|---|
| 장애 시작 | |||
| 알아챔 | |||
| 원인 | |||
| 고침 | |||
| 재처리 · 확인 |
런북에서 빠졌던 단계:
4. 연락처 · 책임
| 무엇 | 누구 | 언제까지 |
|---|---|---|
| 1차 대응 | ||
| 데이터 API 담당 | ||
| parked 건 확인 · 결정 |