롤백 리허설은 컷오버 며칠 전에 하나

결함 마감과 겹치지 않는 주에 한 번, 데이터나 연계, 권한이 바뀌면 한 번 더 한다. 오픈 전야에 첫 실행을 넣지 않는다.

스테이징 성공을 운영 시간으로 써도 되나

계정, 배치 잠금, 대외 공지가 같은 환경이 아니면 안 된다. 그 세 가지가 빠진 40분은 개발자 로컬 기록이다.

리허설이 계획을 크게 넘기면 Go를 미루나

복구 시간을 다시 적고 잔여 조건을 붙인다. 숫자를 숨긴 채 Go하면 실패 순간에 시계가 없다.

문서 절차만으로 리허설을 갈음할 수 있나

점검표는 단계를 보여 준다. 분은 손을 움직여야 나온다. 손이 안 움직인 역할은 오픈 날 전화로 찾게 된다.

오픈 전 롤백 리허설 잡기 - 컷오버 실패 시 복구 시간 측정

컷오버 당일 새벽 3시에 롤백을 처음 돌려 본 현장이 있다. 계획서의 복구 시간은 90분이었는데 실제는 4시간이 넘었다. 스크립트는 스테이징에서만 돌았고, 운영 계정과 배치 잠금은 리허설 목록에 없었다. 리허설을 문서 첨부만으로 통과시킨 프로젝트는 오픈 날 권한 오류에서 멈춘다. 실패 경로를 시계로 한 번도 재지 않으면 Go 결정은 성공 경로만 본 결정이다. 이번 포스팅에서는 롤백 리허설을 오픈 전에 어디에 박고 무엇을 재야 하는지를 현장 기준으로 다뤄보도록 하겠습니다. 컷오버 주간에 복구 절차를 찾고 있다면, 리허설 한 번의 기록이 회의를 줄입니다.

기록 칸	자주 빠지는 것	오픈 날 증상
No-Go 선언 시각	누가 선언하는지	권한 논쟁으로 10분 소모
스크립트 시작	운영 계정 위치	개인 PC를 찾다가 지연
데이터 복구 완료	실데이터 규모	스테이징의 두 배가 걸림
배치와 연계 재개	기관 공지 양식	회선은 열렸는데 상대가 모름
사용자 공지	문장 확정본	부서마다 다른 안내

롤백 리허설에서 남길 시각과 깨지는 지점

성공 경로만 리허설하면 왜 부족한가

Go는 성공 경로의 합격이 아니다. 실패했을 때 몇 분에 되돌릴 수 있는지가 같이 있어야 한다.

컷오버 리허설이라고 적힌 산출물을 열어 보면, 이관 순서와 성공 화면 캡처만 있는 경우가 많다. 그 문서는 이관 리허설이지 롤백 리허설이 아니다.

성공 경로는 낮에 여러 번 돌아간다. 실패 경로는 새벽에 한 번 만나고, 그때 담당은 이미 열두 시간을 서 있다.

WBS에 컷오버를 한 칸으로 묶어 두면 리허설 종류가 안 나뉜다. 이관 리허설, 데이터 대사, 롤백 리허설, 운영 호출 테스트를 칸으로 나눠야 어느 주가 비었는지가 보인다.

빈 칸을 오픈 전주로 미루면 그 주는 이미 결함 마감 주다. 결함 마감과 롤백 첫 실행을 같은 밤에 넣지 않는다.

롤백 리허설에서 시계로 재는 것은 뭔가

결정 시각, 실행 시작, 데이터 복구 완료, 배치 재개, 사용자 공지. 다섯 시각이 계획과 실제 두 줄이다.

롤백 절차서에 단계만 있고 분이 없으면 그 문서는 점검표다. 시계가 아니다.

리허설 기록은 다섯 시각을 남긴다. No-Go를 선언한 시각, 스크립트를 돌리기 시작한 시각, 데이터가 기준 시점까지 돌아간 시각, 배치와 대외 연계를 다시 연 시각, 사용자 공지가 나간 시각.

계획과 실제를 나란히 적는다. 실제가 계획을 두 배 넘으면 그 줄이 Risk(위험)다.

위험을 이슈 목록 맨 아래에 두지 말고, Go/No-Go 자료 첫 장에 올린다. 첫 장에 없으면 회의는 성공 캡처만 본다.

성공 캡처만 본 회의의 Go는 조건부 Go가 아니라 분위기 Go다.

스테이징에서 된 롤백이 운영에서 깨지는 이유

계정, 배치 잠금, 대외 기관 회선, 공지 채널. 스테이징에 없는 네 가지가 운영에서 시간을 먹는다.

스테이징 롤백이 40분에 끝났다고 운영도 40분이라고 적으면 그 숫자는 이관이 아니다. 운영에는 배치 잠금 승인이 있고, 대외 기관 장애 공지가 있고, 계정은 개인 USB에 들어 있는 경우가 있다.

리허설 환경에 운영과 같은 권한 매트릭스가 없으면, 리허설은 개발자 한 명의 로컬 성공이다. 운영 당번, 보안 담당, 배치 운영, 현업 공지 담당을 리허설 명단에 넣고 그 자리에서 한 번씩 손을 움직이게 한다.

손 안 움직인 역할은 오픈 날 전화로 찾게 된다. 전화로 찾는 10분이 다섯 번이면 이미 계획 90분은 끝이다.

Go/No-Go 회의에 리허설 기록을 어떻게 올리나

합격 여부만 올리지 않는다. 실제 복구 분, 실패한 단계, 잔여 조건 세 줄을 같은 슬라이드에 둔다.

회의 자료에 롤백 리허설 완료라고만 적히면 질문은 나오지 않는다. 완료는 상태가 아니라 결과 숫자다.

실제 복구가 몇 분이었는지, 어느 단계에서 막혔다가 우회했는지, 오픈 날에도 남는 조건이 무엇인지. 세 줄이 있어야 검증(Validation) 시나리오의 실패 분기도 같이 읽을 수 있다.

시나리오에 장애 시 이 화면은 조회만 가능하다는 문장이 없으면, 롤백 중의 사용자 안내가 즉석 문장이 된다. 즉석 문장은 부서마다 다르게 나간다.

다르게 나간 공지는 오픈 다음 날 민원이다. 민원 문장을 리허설 때 한 장으로 고정한다.

리허설을 한 번만 하면 안 되는 경우

데이터 규모가 바뀌었거나, 연계 기관이 늘었거나, 권한 체계를 고친 뒤에는 한 번 더 돌린다.

착수 때 한 번 돌리고 산출물에 체크만 남은 리허설은 세 달 전 시스템이다. 이관 데이터가 두 배로 늘면 복구 시간도 같이 는다.

연계 기관이 하나 늘면 잠금 전화가 하나 는다. 권한 모델을 검수 직전에 바꾸면 롤백 계정이 그 모델을 모른다.

세 변화 중 하나라도 있으면 리허설을 다시 잡는다. 다시 잡을 시간이 없으면 복구 시간 숫자를 계획서에서 지우고 실측 중이라고 쓴다.

지운 숫자가 회의를 불편하게 해야 정상이다. 불편하지 않은 계획 90분은 아직 재지 않은 90분이다.

재지 않은 숫자를 Go 조건에 넣지 않는다.