緊急修正のための4目原則を実装する方法は？

このシナリオを考えてみてください（実際の状況との比較はすべて偶然によるものです）：

• 3:07 am：サポートコールの着信「生産中の何かがダウンしました。あなたの助けが必要です！」。
• 午前3時12分：システムに接続（ログオン可）...コーヒーの時間はありません。
• 3:15 am：幸運なことに、すぐにどこかのエラーメッセージで問題を見つけることができます。
• 3:17 am：SCMツールボックスを使用してコードを取得し、問題を修正し、テストします。素晴らしい...私の修正は機能します！
• 3:20 am：Dev Opsチームと連絡を取り、修正を出荷し、運用を再開します。
• 3:21 am：赤旗...「4つの目を尊重するには、この修正の承認を得るためにさらに2 つの目が必要です」。
• 3:22 am：ggggrrrreat、今何を、他に誰に電話すればいい（=マネージャーを起こす）？

「四眼の原則の可能な実装（または例）とは？」に対する私の答えに似た承認手順を実装した場合、運が悪い...ここにあなたの選択があります：

• あなたの修正は、さらに2人の目が関与するまで行き詰まります（読んでください：生産が停止します）。
• あなたは、失われた目を回避する方法を見つけ出します。

それでは、緊急修正のための4目原則をどのように実装するのでしょうか？...生産をできるだけ早く、つまり午前 3時25分頃に実行 できるようにするため...そして、通話を終了する（そして元の場所に戻る）こともできますか？

私がよく知っているSCMの世界では、上記のシナリオは通常、「短縮-承認リストプロシージャ」と呼ばれるもので対処されます。

以下がその青写真です。

• たとえば、午前8時から午後6時までの営業時間を定義します。
• （たとえば）3レベルの承認の完全な承認リストを定義します（ロールX、Y、およびZ）。
• （たとえば）1レベルの承認のみの簡略承認リストを定義します（ロールXのみ）。
• 計画的な変更には、完全な承認リストからのすべての承認が常に必要です。
• 以下のために計画外の変更、完全な承認リストが使用されても、必要な承認を収集するための承認を発行することが提供される時に定義された業務時間。
• 定義された営業時間外に発行される予定外の変更の承認の場合：
  • 変更を承認するには、短縮承認リスト（上記のロールXなど）からの承認のみが必要です。そして、簡略化された承認リストによる許可が与えられた後、（ターゲット環境で）変更の展開が実際に実行されます。
  • しかし、追加のポスト -approvalsは（時間/日の合理的な量の範囲内）、その後、必要とされるであろう、すなわち完全な承認リストに含まれるすべてのロールからも簡略承認リストに含まれていない、（そのような役割YとZ上記のように） （上記のロールXなど）。（前もって）合意された時間/日以内にすべての承認後が発行されていない場合（たとえば、修正が「今回」機能したが一時的な修正に過ぎなかったため）、変更はロールバックの対象となる可能性があります。少なくとも1つの未承認の承認後がありますが、変更は「承認待ち」としてマークされます。

このような解決策があれば、午前3時23分頃にコールを閉じることができます... 午前3時21分には赤旗がなくなるので... ggggrrreat、ビールが私の生産を再開するための修正を祝う時間です（コーヒーの代わりに）...そして、指が渡った顕著なポスト承認がすぐに来る...

営業時間外の緊急修正の場合、通常の手順よりも変更のサインオフを少なくする方が実用的です。通常、修正プログラムを展開して、翌営業日に承認後を行うことができます。修正が承認されない場合、元に戻して永久的な解決策に置き換えることができます。

停止状態では、サービスを復元することが最優先事項です。停止中に組織がこの緩和されたプロセスを認識しない場合、はい、あなたの唯一の選択肢は、サインオフのためにより多くの人々を起こし始めることです。