안정화 긴급 패치 나누기 - 장애 조치와 변경요청의 승인 경로

오픈 다음 날 패치는 전부 장애 조치인가?

아닙니다. 이미 합의된 동작이 깨진 것만 장애 조치입니다. 새 문장과 새 규칙은 변경요청입니다.

오픈 다음 날 아침 회의에는 패치 목록이 한 장으로 들어옵니다. 그 장에 로그인 오류와 버튼 문구 수정이 같이 있으면, 둘 다 긴급으로 처리되기 쉽죠.

긴급의 기준은 시각이 아니라 증상입니다. 검수에서 합격한 시나리오가 같은 데이터에서 실패하면 장애 조치입니다.

합격한 적 없는 문장, 새로 원하는 검증 규칙, 화면 추가는 장애가 아닙니다. 변경관리 번호가 없는 문구 수정은, 안정화 기간을 무상 범위 확장으로 바꿉니다.

확장된 범위는 다음 패치의 회귀 시험에 안 들어가서, 사흘 뒤 다른 화면을 깨뜨립니다. 아침 회의의 첫 열은 배포 시각이 아니라 갈래입니다.

장애, 변경, 데이터 정정. 갈래가 빈 줄은 배포하지 않습니다.

긴급과 변경요청은 어느 칸에서 갈라지나?

당일 업무 중단이면 긴급 경로로 먼저 막고, 다음 영업일 변경위원회에 사후 보고합니다. 중단이 아니면 배포 전에 변경 번호를 받습니다.

변경위원회를 새벽 2시에 열 수는 없죠. 그래서 긴급 경로가 필요합니다.

다만 긴급 경로는 막기 위한 길이지, 기능을 넣기 위한 길이 아니죠. 당직 PM과 운영 담당이 두 가지만 확인합니다.

지금 업무가 멈추었는가, 되돌릴 배포 단위가 있는가. 두 가지가 아니면 새벽 배포를 멈춥니다.

멈춘 요청은 다음 영업일 안건으로 넘깁니다. 두 가지가 맞으면 패치를 나가고, 다음 영업일에 무엇을 바꿨는지 사후 보고합니다.

사후 보고가 없는 긴급은 기록이 없는 운영 변경입니다. Risk(위험) 대장에 긴급 패치를 위험의 현실화된 줄로 남기면, 같은 화면이 반복되는지 보입니다.

반복되면 다음 긴급은 임시 조치가 아니라 원인 수정 일정을 요구하죠. 원인 수정 없이 패치 횟수만 늘면 안정화 14일이 사실상 개발 연장입니다.

안정화 기간에 기능 추가는 왜 패치로 들어오나?

오픈 전에 못 넣은 요구가 장애 티켓의 제목을 빌립니다. 제목이 아니라 기준선에 있었는지를 봅니다.

안정화 기간은 고치는 기간으로 알려져 있어서, 넣기 어려웠던 문장이 이때 장애처럼 들어옵니다. 사용자가 못 해서 업무가 멈춘다는 말과, 원래 범위에 없었다는 말이 같이 나오죠.

기준선과 검수 시나리오에 그 문장이 있으면 누락된 결함입니다. 결함은 긴급 여부와 상관없이 잔여 결함 절차로 갑니다.

기준선에 없으면 변경입니다. 변경은 이번 안정화에 넣을지, 다음 개선으로 보낼지를 발주사가 고릅니다.

수행사가 새벽 패치로 먼저 넣으면, 그 선택은 이미 끝난 뒤가 됩니다. 끝난 선택을 다음 날 회의에서 뒤집으면 재배포가 한 번 더 나갑니다.

재배포는 긴급의 비용을 두 번 냅니다. 티켓을 열 때 기준선 ID 칸을 필수로 두면, 빈 칸은 배포 대기열에 올라가지 않습니다.

배포 대장의 한 행에는 장애 티켓 번호나 변경 번호를 반드시 적고, 둘 다 없으면 그 행은 미분류로 남기세요.

승인 없는 새벽 배포는 나중에 어디에 남나?

배포 기록, 승인자, 되돌림 방법이 없는 패치는 안정화 종료 보고에서 설명할 수 없습니다.

서버에는 새 빌드가 있는데 티켓이 없으면, 다음 장애의 원인 찾기가 추측이 됩니다. 추측은 회의를 길게 만들고, 긴 회의 동안 같은 패치가 한 번 더 나갑니다.

긴급이라도 남길 최소 기록은 있습니다. 빌드 번호, 바뀐 화면 또는 모듈, 승인한 사람, 적용 시각, 되돌림 방법.

다섯 칸이 채팅에만 있으면 교대 근무는 그 채팅을 못 봅니다. 운영 로그나 배포 대장의 한 행이어야 합니다.

QA vs QC가 다음 날 보는 회귀 범위도 이 행에서 나옵니다. 행이 없으면 회귀는 전 화면이 되거나, 아무것도 안 하게 됩니다.

전 화면 회귀는 안정화 인력을 초과하고, 무회귀는 같은 유형의 장애를 다음 주로 넘깁니다. 다섯 칸은 승인 서류의 대용이 아니라, 다음 근무자가 읽을 인수 쪽지입니다.

미분류가 다음 날 아침까지 남으면 그 빌드는 되돌림 후보로 올리는 편이 기록을 살리죠.

패치 뒤에 어떤 회귀를 다시 보나?

바뀐 시나리오와, 그 시나리오가 공유하는 배치와 권한만 다시 봅니다. 전 화면을 다시 열면 긴급 패치가 검수 재시작이 됩니다.

긴급 패치 뒤에 전체 시험을 다시 돌리자는 말은 안전해 보입니다. 안정화 인원으로 전체 시험을 하루 안에 못 돌리면, 그 말은 다음 배포를 막는 구호가 되죠.

회귀 범위는 패치 행에 적힌 시나리오 ID로 시작합니다. 그 ID가 쓰는 공통 코드, 권한, 야간 배치가 있으면 그 줄만 추가합니다.

추가 줄이 없는 패치는 공통을 안 건드렸다는 뜻이어야 하고, 건드렸는데 칸이 비었으면 배포를 보류합니다. 회귀에서 실패한 줄은 새 기능 요청으로 바꾸지 말고 같은 패치의 미종료로 둡니다.

미종료 패치가 있는데 다음 패치를 올리면, 어떤 빌드가 운영인지가 흐려집니다. 안정화 종료일에는 미종료 긴급이 0건이거나, 남은 건의 우회 절차가 운영 매뉴얼에 있어야 합니다.

우회 없이 종료를 선언하면, 종료 다음 주가 또 다른 안정화가 됩니다.