응급 수정을 위해 4 눈 원칙을 구현하는 방법은 무엇입니까?

이 시나리오를 고려하십시오 (실제 상황과의 비교는 순전히 우연입니다).

• 오전 3시 7 분 : 들어오는 지원 전화 " 생산에 문제가 발생했습니다, 당신의 도움이 필요합니다! ".
• 오전 3시 12 분 : 시스템에 연결 (로그온 허용) ... 커피 시간 없음.
• 오전 3시 15 분 : 운이 좋으면, 어딘가에 오류 메시지를 통해 문제를 발견 할 수 있습니다.
• 오전 3시 17 분 : SCM 도구 상자를 사용하여 코드를 잡고 문제를 해결하고 테스트하십시오.
• 오전 3시 20 분 : Dev Ops 팀 과 연락 하여 수정 프로그램을 제공하고 프로덕션을 다시 실행하십시오.
• 오전 3시 21 분 : 붉은 깃발 ... " 네 눈 을 존중하기 위해 , 우리는이 수정에 대한 승인을 얻기 위해 더 많은 눈이 필요합니다 .
• 오전 3시 22 분 : ggggrrrreat, 이제 우리는 누구를 부를 수 있습니까 (= 일부 관리자를 깨우십시오)?

" 네 눈 원리의 가능한 구현 (또는 예)은 무엇입니까? "

• 2 명이 더 눈에 들어올 때까지 수정 내용이 멈 춥니 다 (읽기 : 생산 중단).
• 실종 된 눈을 피할 수있는 방법을 찾아냅니다.

그렇다면 응급 수정을위한 4 안 원칙을 구현하는 방법은 무엇입니까? ... 그래서 즉시 생산을 시작하고 오전 3시 25 분쯤에 ... 그리고 전화를 끊을 수 있습니다 (그리고 당신이 어디에서 왔는지 돌아갈 수 있습니까?).

내가 가장 친숙한 SCM 세계에서 위의 시나리오는 일반적으로 " 축약 된 승인 목록 절차 "를 통해 해결됩니다 .

청사진은 다음과 같습니다.

• 오전 8 시부 터 오후 6 시까 지 업무 시간을 정의하십시오.
• 3 가지 승인 수준 (예 : 역할 X, Y 및 Z) 의 전체 승인 목록을 정의하십시오 .
• 약 1 단계의 승인 (역할 X에만 해당) 의 간략한 승인 목록을 정의하십시오 .
• 계획된 변경에는 항상 전체 승인 목록의 모든 승인이 필요합니다.
• 내용은 계획되지 않은 변경 , 전체 승인 목록이 사용됩니다 또한 , 필요한 승인을 수집하기 위해 승인을 발행 할 수 있습니다 제공 하는 동안 정의 된 업무 시간.
• 정의 된 업무 시간 외에 발행 될 계획되지 않은 변경에 대한 승인 :
  • 변경을 승인하려면 축약 된 승인 목록 (위의 역할 X와 같은)의 승인 만 필요합니다. 그리고 약식 승인 목록에 의한 승인이 제공된 후, 변경 대상 (대상 환경에서)의 배치가 실제로 수행됩니다.
  • 그러나 추가 포스트 -approvals은 (시간 / 일의 합리적인 시간 내에) 나중에 필요하게됩니다, 즉 전체 승인 목록에 포함 된 모든 역할에서 또한 축약 승인 목록에 포함되지 않은 (예 : 역할 Y 및 Z 위 등) (위의 역할 X와 같은). (선불) 합의 된 시간 / 일 내에 모든 승인 후가 발행되지 않은 경우 (예 : 수정이 "이번"시간에 효과가 있었지만 임시 수정과 같았 기 때문에) 변경이 롤백 될 수 있습니다. . 승인 된 사후 승인이 1 회 이상 있지만 변경 사항은 "사후 승인 대기 중"으로 표시됩니다.

이러한 솔루션을 사용하면 오전 3시 23 분경에 통화를 종료 할 수 있습니다. 오전 3시 21 분에 더 이상 붉은 깃발이 없기 때문에 ... (커피 대신) ... 그리고 손가락은 뛰어난 포스트 승인이 곧 올 것입니다 ...

업무 시간 외 응급 수정의 경우 일반적인 절차보다 변경에 대한 사인 오프를 적게하는 것이 더 실용적입니다. 일반적으로 수정 프로그램을 배포 한 후 다음 영업일에 승인 후 작업을 수행 할 수 있습니다. 수정 사항이 승인되지 않은 경우 수정 사항을 되돌리고 영구 솔루션으로 교체 할 수 있습니다.

정전 상황에서는 서비스를 복원하는 것이 최우선 순위입니다. 조직이 정전 중에 이완 된 프로세스를 인식하지 못하면, 유일한 옵션은 사인 오프를 위해 더 많은 사람들을 깨우기 시작하는 것입니다.