DEPLOYMENT
00:00 경과
LABLAB-ITSM-30-ROLLBACK-PLANNING중급
작업계획서·롤백계획서·점검계획 — 실패를 가정하고 준비한다
ELAPSED
00:00
PHASE
0 / 4
SLA
55분
🗂️ ITSM 도구·AI
← 목록
INCIDENT RESPONSE
0 / 5 단계 완료
📚 PREREQUISITES
Theoryitsm/rollback-checklist
TRACK
ITSM
SLA
55분
LEVEL
중급
PHASES
3단계
ENV
local
INCOMING TICKET
발주사 PM: "지난번 결제 패치 되돌리는 데 4시간 걸린 사고, 다시는 없어야 합니다. 이번 결제 모듈 v2 반영은 작업계획서·롤백계획서·점검계획을 사전에 제출하고 승인받은 뒤 진행하세요. 실패하면 몇 분 만에, 어떤 기준으로, 누구 결정으로 되돌리는지 문서로 보여 주세요."
YOUR ROLE
SM 운영·변경 담당(작업계획서·롤백계획서를 검토·승인하는 통제자)
안 하면 나중에
롤백계획이 없으면 새벽 장애에서 원복 경로를 즉흥으로 찾다 복구가 몇 시간으로 늘어 새벽 매출이 통째로 날아가고, 성공기준 없는 점검은 "떠 있으니 됐다"로 끝나 목적 기능인 신규 카드사 결제가 아침 트래픽에서 전부 실패하며, 측정 불가능한 트리거는 매몰비용 심리에 밀려 롤백을 늦춘다.
📋상황 브리핑
협력사 엔지니어가 금요일 저녁 메신저로 한 줄을 보냅니다.
"결제 모듈 패치 운영 반영 완료했습니다."
토요일 새벽 2시, 결제 실패율이 치솟습니다. 당직자가 묻습니다 — "원래대로 되돌릴 수 있나요?" 돌아온 답: "이전 버전 파일이 어디 있는지 찾아봐야 합니다. 설정도 같이 바뀌어서요. DB 스키마도 한 번 건드렸는데..." 복구에 4시간이 걸렸고, 월요일 발주사 보고의 첫 질문은 "왜 되돌리는 데 4시간이나 걸렸습니까?"였습니다.
이 사고의 본질은 "패치에 버그가 있었다"가 아니라 실패를 가정하지 않고 반영했다는 것입니다. 잘 될 때의 계획만 있었고, 안 될 때의 계획 — 롤백계획서 — 이 없었습니다. 이 Lab은 운영 반영 전 반드시 준비하는 세 문서, 작업계획서·롤백계획서·점검계획을 한 변경(결제 모듈 v2)에 실제로 적용해 "실패를 가정하고" 설계합니다.
⏱ 55분📊 중급🔧 3단계#rollback#work-plan#checklist#change
MISSION
1
작업계획서 — 단계·담당·예상시간·롤백 포인트로 대본을 쓴다
운영 반영을 되돌릴 수 있는 최소 단위의 단계로 쪼개고, 각 단계에 실행/확인 담당·예상시간·롤백 포인트를 채우며, 누적시간을 점검창과 비교해 롤백 시간 예산을 확보한다.
2
롤백계획서 — 측정 가능한 트리거·복귀 절차·데이터 복구·불가 대비
롤백을 언제 결정할지 측정 가능한 트리거와 결정권자를 정하고, 원복 절차를 선 실행·후 보고로 위임하며, 작업 중 데이터와 롤백 불가 구간의 안전장치를 설계한다.
3
점검계획 — 두 개의 층과 성공기준으로 "정상"을 정의한다
반영 직후 점검을 1층 인프라 신호와 2층 핵심 기능 시나리오로 나누고, 이번 변경의 목적 기능을 성공기준에 담아 점검 실패가 곧 롤백 트리거로 이어지게 한다.
📌 선수 지식
ℹ️ 실습 환경
환경: local
🔒
실습 실행은 Pro 플랜 전용입니다
인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.
Pro로 업그레이드 →
>_ LAB TERMINAL↔ 너비 조절
NOTES