rollback 보다 forward fix 가 빠를 때
복구 버튼을 누르기 전에 먼저 물어야 할 질문 하나.
rollback 은 기본값이 아니다
장애가 나면 반사적으로 rollback 부터 찾는다. 그게 훈련된 반응이다. 그런데 실제로 시간을 재보면 rollback 이 느린 경우가 꽤 있다.
- DB 마이그레이션이 이미 실행됐을 때 — 되돌리려면 down 스크립트, 검증, 재배포. 20분 이상.
- 외부 연동(웹훅, 결제 콜백)이 새 스키마로 데이터를 이미 쌓았을 때 — rollback 하면 데이터 정합성이 더 꼬인다.
- 배포 파이프라인이 느릴 때 — rollback 도 결국 파이프라인을 탄다. 이전 버전이라고 빠르지 않다.
이 세 가지 중 하나라도 해당하면 forward fix 가 더 싸다.
판단 기준을 미리 정해둔다
사고 중에는 판단이 느리다. 그래서 기준을 사전에 고정해 둔다.
rollback 먼저인 경우
- 마이그레이션 없음
- 외부 연동 없음
- 원인 파악에 5분 이상 걸릴 것 같음
forward fix 먼저인 경우
- 버그가 한 줄짜리 조건문 혹은 config 값
- 마이그레이션이 이미 커밋됨
- hotfix 브랜치 → 배포까지 5분 이내 가능
기준이 있으면 “rollback 할까요 fix 할까요” 라는 채널 토론이 사라진다. 토론이 사라진다는 건 MTTR 이 줄어든다는 뜻이다.
팀에 이 기준이 없으면 장애 직후가 아니라 평온한 날 30분 잡고 정한다. 한 번만 하면 된다.
실제로 달라진 것
최근 한 사건. config 값 하나가 잘못 들어가 특정 유저군 요청이 전부 500 으로 떨어졌다.
- rollback 예상 시간: 약 12분 (파이프라인 + 검증)
- forward fix 실제 시간: config 수정 후 재기동 3분
채널에서 “rollback?” 이 올라오는 순간 기준표를 붙여넣었다. 3초 만에 forward fix 로 결정. 사용자 영향은 4분.
이게 항상 되는 건 아니다. 조건이 맞을 때만 빠르다. 조건 확인이 핵심이다.
다음 한 가지
팀 런북 첫 줄에 rollback / forward fix 판단 기준을 오늘 추가한다.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.