问题描述
在紧急修复的情况下，如何实施四眼原则？假设出现了以下情景：凌晨3:07，你接到了一个紧急支持电话，对方报告生产环境出现问题。你连上了系统，没有时间喝咖啡。经过一番检查，你发现了问题并准备修复。在凌晨3:17，你通过源代码管理工具修复了问题，进行了测试，一切正常。然后，你联系了运维团队，准备发布修复并恢复生产环境。然而，在准备发布时，突然出现了问题，需要得到另外两名审批者的批准，以符合四眼原则。你开始犹豫，是否需要叫醒其他人来获得批准，然后你开始考虑如何在这种情况下实施四眼原则，以便尽快恢复生产环境并关闭支持电话。
解决方案
在处理紧急修复的情况下，有一个常见的做法是使用“缩减批准列表”程序。下面是一种具体的实现方法：
首先，定义你的业务工作时间，比如从早上8点到晚上6点。
然后，定义一个完整的批准列表，包含3个级别的审批角色（比如角色X、Y和Z）。
接着，定义一个缩减的批准列表，只包含一个级别的审批角色（比如角色X）。
对于“计划内变更”（Planned changes），始终需要从完整的批准列表中获取所有的批准。
对于“非计划内变更”（Unplanned changes），如果需要在业务工作时间内进行批准，同样需要从完整的批准列表中获取批准。但如果变更需要在业务工作时间外进行批准，只需要从缩减的批准列表中获取批准（仅包含角色X）。
对于在业务工作时间外进行的“非计划内变更”，需要在一定的时间（可以是几个小时或几天）内获取所有未包含在缩减批准列表中的完整批准列表中的批准。如果在规定的时间内未获得所有后续批准，可能需要考虑回滚变更。只要存在未处理的后续批准，变更状态将标记为“等待后续批准”。
使用上述方法，你可以在凌晨3:23左右关闭电话，因为在凌晨3:21时就不再会出现红旗标识。这样，你可以庆祝修复成功，尽快恢复生产环境，而无需过多担心后续批准的问题。
请注意，实际操作中需要根据组织的需求和流程进行具体调整，以确保在紧急情况下能够快速恢复生产并且保持审批的合规性。
补充说明
这种方法的关键在于灵活性，它在紧急情况下允许缩减批准列表，以便尽快恢复服务。然后，在规定的时间内，通过获取完整批准列表中的所有批准来确保操作的合规性和可追溯性。这种方法可以平衡在紧急情况下的操作速度和安全性，同时也可以避免在半夜叫醒更多人员来批准变更。