# 롤백계획서 (빈 양식)

> 독자: **장애 직전의 작업자·관리자** — "이게 잘못되면 어떻게 되돌리는가?"
> 핵심 원칙
> - **롤백계획서는 사후 문서가 아니다.** 반영 **전에** 작업절차서와 한 쌍으로 미리 쓰는 '보험증서'.
> - **조건이 절차보다 먼저**다. "어떻게 되돌리나"보다 "언제 되돌리기로 정했나"가 핵심.
> - **결정 시한(point of no return)**과 **롤백 선언 권한자(한 명)**가 없으면 현장에서 "조금만 더"를 반복하다 점검창을 넘긴다.
> - 가장 자주 빠지는 부분이 **D(롤백 불가 대비)**다 — 외부 결제망/비가역 마이그레이션은 단순 원복 불가.

---

## 개요

| 항목 | 내용 |
|---|---|
| 롤백계획서 ID | `RB-[YYYY-MMDD-NN]` |
| 연관 변경계획서 / 작업절차서 | `CHG-________ / WP-________` |
| 결정 시한 | `[HH:MM]` (변경계획서·공지와 동일하게 박아 둘 것) |
| 롤백 선언 권한자 | `[총괄 홍OO — 단 한 명. 이 사람이 시계를 본다]` |

## A. 롤백 발동 조건 (언제 되돌리는가)

> "정상화 안 되면"처럼 모호하게 쓰지 말고 **측정 가능한 신호**로.

- `[예: 헬스체크가 3회 연속 실패]`
- `[예: 스모크(테스트) 거래 승인 실패 또는 응답 __초 초과]`
- `[예: 결정 시한 HH:MM 까지 핵심 거래 정상화 미달성]`
- 위 중 **하나라도 해당 시 즉시 롤백** (`[권한자]` 판단·선언)

## B. 롤백 절차 (어떻게 되돌리는가) — 작업절차서의 역순

> 작업절차서에서 바꾼 것을 정확히 되돌리는 짝이 있어야 한다.

1. `[예: LB 트래픽을 다시 점검 페이지로 전환]`
2. `[예: 보존해 둔 현 버전(이미지/패키지)으로 재배포]`
3. `[예: 설정을 이전 값으로 원복]`
4. `[(필요 시) DB 다운 스크립트 실행 또는 백업 복구]`
5. `[예: 헬스체크·스모크 거래로 이전 버전 정상 확인 후 트래픽 복귀]`

## C. 데이터 복구 (되돌릴 때 데이터는)

- 컬럼 추가만 한 경우: `[신규 컬럼 미사용 → 데이터 손실 없음, 다운 스크립트로 제거 또는 보존]`
- 점검 중 실거래가 발생한 경우: `[트랜잭션 로그 보존, 복구 후 정합성 점검(중복/미정산 수동 확인)]`
- 백업 복구가 필요한 경우: `[작업절차서 1단계 풀백업으로 시점 복구(PITR)]`

## D. 롤백 불가 대비 (되돌릴 수 없을 때)

> "되돌리면 되지"라는 가정이 가장 위험하다. 비가역 변경/외부 거래는 단순 원복 불가.

- 발생 상황: `[예: 마이그레이션 비가역 / 외부 PG에 이미 결제 발생]`
- 전환 전략: **전진 복구(fix-forward)** — 앞으로 고쳐 나간다
- 트리거 기준: `[예: 롤백 시도 자체가 30분 내 실패하면 War Room 소집]`
- 비상 연락: `[변경관리자 / 서비스책임자 / (외부)PG 장애 핫라인]`
- 최악의 경우: `[예: 결제만 일시 차단하고 주문은 받는 '부분 축퇴 운영' 결정]`

---

> 점검: 이 롤백계획서는 작업절차서(WP-____)와 **한 쌍**인가? 절차서만 있고 롤백이 없으면
> "돌이킬 수 없는 작업"을 하는 것이다. ITSM에서 롤백은 패배가 아니라 **계획된 안전장치의 정상 작동**이다.