如何实施紧急修复的四眼原则？

考虑这种情况（与现实情况的任何比较纯属偶然）：

• 凌晨3:07：即将到来的支持电话“ 生产中的某件故障，我需要您的帮助！ ”。
• 凌晨3:12：已连接到系统（已接受登录）...而且没有时间喝咖啡。
• 凌晨3:15：很幸运，您可以立即通过某个错误消息在某处发现问题。
• 凌晨3:17：使用您的SCM工具箱获取代码，修复问题，对其进行测试，太好了……我的修复工作正常！
• 凌晨3:20：与Dev Ops团队取得联系，以发送修复程序并重新开始生产。
• 凌晨3:21：危险信号……“ 为了尊重四只眼睛，我们还需要2只眼睛才能获得此修复程序的批准 ”。
• 凌晨3：22：ggggrrrreat，现在呢，我们还能叫谁（=叫醒经理）？

如果您实施了类似于我对“ 四眼原则的可能实现方式（或示例）有什么答案？”的回答的批准程序，那么您很不走运……这是您的选择：

• 您的修补程序将被卡住（阅读：生产将下降），直到另外2只眼睛介入为止。
• 您想出一种方法来避开丢失的眼睛。

那么如何实施紧急修复的四眼原则呢？...这样您就可以尽快开始生产，即大约 凌晨3:25 ...并且还可以关闭该呼叫（并返回到您的来源）？

在我最熟悉的SCM世界中，通常通过所谓的“ 缩写-批准列表”过程来解决上述情况。

这是它的蓝图：

• 定义您的工作时间，例如从上午8点到下午6点。
• 定义（例如）3个批准级别的完整批准列表（对于角色X，Y和Z）。
• 定义一个简短的批准列表，该列表仅（例如）批准级别为1（仅对于角色X）。
• 计划的更改始终需要完整批准列表中的所有批准。
• 对于“ 计划外变更”，完整的批准清单也可用于收集所需的批准，前提是要在定义的工作时间内发布批准。
• 对于在规定的工作时间之外发布的计划外变更的任何批准：
  • 只有缩写批准列表中的批准（例如上面的角色X）才需要授权更改。并且在给出了简短的批准列表的授权之后，将实际执行更改的部署（在目标环境中）。
  • 但是此后（在合理的小时数/天数之内），即从完整的批准列表中包含的所有角色（例如上面的角色Y和Z）中删除之后，都需要额外的后批准。 （例如上面的角色X）。并且，如果在（预定的）小时数/天数之内没有发布所有的后批准（例如，因为此修复程序在“本次”工作，但仅像临时修复程序一样），则更改可能会被回滚。虽然至少有1个未完成的后期批准，但更改标记为“等待后期批准”。

有了这样的解决方案，就可以在凌晨3:23左右结束电话会议...因为在凌晨3:21不再有任何危险信号了... ggggrrreat，该喝些啤酒庆祝我的修复以恢复生产了（而不是咖啡）...并且很快就会获得出色的职位批准……

在下班时间紧急修复的情况下，与正常程序相比，需要较少的变更签核更为实用。通常，您可以部署修补程序，然后在下一个工作日进行批准。如果未批准此修复程序，则可以将其还原并替换为永久解决方案。

在中断情况下，第一要务应该是恢复服务。如果您的组织在停电期间没有意识到此放松的过程，那么可以，您唯一的选择是开始唤醒更多人进行注销。