Web Operations Runbook
3줄 요약
- Runbook은 장애 중 생각할 일을 줄이고, 같은 증상에서 같은 순서로 확인하게 만드는 실행 문서다.
- 좋은 Runbook은 명령 목록이 아니라 “언제 멈추고, 무엇을 확인하고, 어떤 조건에서 다음 조치로 갈지”를 적는다.
- 배포 실패, API 장애, 원인 격리, Rollback/Restore, 운영 점검은 서로 다른 의사결정 흐름을 가져야 한다.
핵심 정리
- 배포 실패 Runbook은 새 버전, 설정, migration, readiness, smoke test를 기준으로 실패 지점을 좁힌다.
- API 장애 Runbook은 사용자 영향, endpoint, status code, 의존성, 최근 변경, 임시 완화 순서로 움직인다.
- 로그/메트릭 기반 원인 격리는 같은 시간대와 같은 요청을 기준으로 증거를 묶어야 한다.
- Rollback과 Restore는 다르며, 데이터 변경 여부와 복구 목표를 먼저 확인해야 한다.
- 운영 점검 체크리스트는 배포 전, 일일, 주간, 장애 후 점검을 나눠 반복 실수를 줄인다.
- 모든 Runbook은 마지막 검증일, 실행 권한, 기대 결과, 실패 시 다음 행동을 포함해야 한다.
헷갈리는 지점
- Runbook을 명령어 모음으로 만들면 장애 중 판단이 남지 않는다.
- 명령마다 실행 위치, 기대 결과, 다음 분기, 중단 조건이 있어야 한다.
- Rollback과 Restore를 같은 복구로 보면 위험하다.
- Rollback은 애플리케이션/설정을 되돌리는 일이고, Restore는 데이터를 되돌리는 일이라 영향이 다르다.
- 체크리스트가 있으면 운영이 안전하다고 착각하기 쉽다.
- 체크리스트는 마지막 검증일과 실제 장애 반영이 없으면 낡은 절차가 된다.
확인 질문
- Runbook의 각 단계에는 무엇이 있어야 하는가?
- 확인 대상, 실행 명령 또는 화면, 기대 결과, 실패 시 다음 행동, 중단 조건이 있어야 한다.
- 배포 실패에서 Rollback 전에 먼저 확인할 것은 무엇인가?
- 새 버전이 데이터 변경이나 migration을 이미 수행했는지 확인해야 한다.
- 운영 점검 체크리스트의 신뢰도를 유지하려면 무엇이 필요한가?
- 주기, 소유자, 마지막 검증일, 장애 후 업데이트 절차가 필요하다.