런북 — 잘못된 배포 롤백 절차

이 런북은 잘못된 배포가 감지되었을 때 서비스를 이전의 안정된 상태로 되돌리기 위한 공식 절차를 설명합니다. 실제 사례로는 2026-05-12 API 장애 (45분) 당시 14:47에 롤백이 수행되어 14:55에 서비스가 복구된 사례를 참고하십시오. [Engineering — Incidents & Decisions.md]

1단계 — 장애 확인

대시보드에서 에러율 또는 레이턴시 지표를 확인하여 회귀(regression)가 실제로 발생했는지 검증합니다. [Engineering — Incidents & Decisions.md]

2단계 — 마지막 정상 커밋 찾기

CI 시스템에서 main 브랜치의 마지막 그린(green) 파이프라인을 찾습니다. 이 커밋이 롤백의 대상이 됩니다. [Engineering — Incidents & Decisions.md]

3단계 — 배포 잡 실행

해당 커밋에 고정(pinned)된 배포 잡을 트리거합니다. [Engineering — Incidents & Decisions.md]

4단계 — 복구 검증

롤백 후 5분 이내에 에러율이 기준치(baseline)로 돌아오는지 확인합니다. [Engineering — Incidents & Decisions.md]

5단계 — 인시던트 채널 공지

#incidents 채널에 롤백한 커밋과 한 줄 원인 요약을 게시합니다. [Engineering — Incidents & Decisions.md]

DB 스키마가 변경된 경우, 앱만 단독으로 롤백하지 마십시오. 반드시 마이그레이션 상태를 먼저 확인한 후 절차를 진행해야 합니다. [Engineering — Incidents & Decisions.md]

DB 커넥션 풀 관련 문제(예: 커넥션 소진)가 장애 원인인 경우, 2026-05-12 포스트모텀의 후속 조치 항목도 함께 확인하십시오. 스키마 마이그레이션은 ADR-014에서 결정된 대로 Alembic을 통해 관리됩니다.