3:07 am：即将来临的支持电话“生产中的东西下降了，我需要您
3:12 am：已连接到系统（已接受登录）...而且没有时间喝咖啡。
3:15 am：幸运的是，
3:17 am：使用SCM工具箱获取代码，修复问题，对其进行测试，很好，我的修复工作正常！
3:20 am：与DevOps团队保持联系，以发布修复程序并使生产再次运行。
3:21 am：危险信号... “为了尊重四眼，我们还需要2只眼才能获得此修复程序的批准。”
3:22 am：ggggrrrreat，现在呢，我们还能叫谁（=叫醒经理）
如果您实现了一些与我对“四眼原则的可能实现（或示例）有哪些实现（或示例）？”的回答类似的批准程序，那么您就不走运了……这里您的 选择：
您的修复程序将被卡住（阅读：生产将下降），直到再有2只眼睛介入为止。
您想出一种方法来避开丢失的眼睛。
那么，如何实施紧急修复的四眼原则？ ...这样您就可以尽快开始生产，也就是凌晨3:25 ... ...这样您还可以关闭呼叫（并返回到您的来源）？
#1 楼
在我最熟悉的SCM世界中，通常通过所谓的“缩写批准列表过程”来解决上述情况。它是一个蓝图：
定义您的工作时间，例如从上午8点到下午6点。
定义一个完整的批准列表，例如3个级别的批准（针对角色X，Y和Z）。
定义一个简短的批准列表（例如，仅1个批准级别（仅针对角色X））。
计划的更改始终需要完整批准列表中的所有批准。
对于非计划的更改，完整的批准清单也可用于收集所需的批准，前提是要在规定的工作时间内发布批准。
对于在规定的工作时间之外发布的计划外变更的任何批准：
仅需要缩写的批准列表中的批准（例如，上面的角色X）即可批准更改，并且在获得缩写的批准后，给出了st，实际上将执行更改的部署（在目标环境中）。
但是此后（在合理的小时数/天的数量之内），即从包含在其中的所有角色中，将需要额外的后批准。完整的批准列表（例如，上面的角色Y和Z），也没有包含在缩写的批准列表中（例如，上面的角色X）。并且，如果在（预定的）小时数/天数之内没有发布所有的后批准（例如，因为此修复程序在“本次”工作，但仅像临时修复程序一样），则更改可能会被回滚。虽然至少有1个未完成的后批准，但更改被标记为“等待后批准”。
有了这样的解决方案，就可以在凌晨3:23左右结束电话会议...因为在凌晨3:21不再有任何危险信号了... ggggrrreat，该喝些啤酒庆祝我的修复以恢复生产了（而不是咖啡）...并且很快就会获得出色的职位批准……
#2 楼
在下班时间紧急修复的情况下，与正常程序相比，需要较少的变更签核更为实用。通常，您可以部署修订，然后在下一个工作日进行批准。如果未批准此修复程序，则可以将其还原并用永久解决方案替换。在中断情况下，重中之重应该是恢复服务。如果您的组织在停电期间没有意识到此放松的过程，那么可以，您唯一的选择是开始唤醒更多人进行注销。
评论
我同意您的建议，该建议似乎与我自己的建议（答案）相似。您能想到一些您熟悉的SCM世界中的示例，以及如何在其中实现它吗？如果是这样，您可以在答案中进一步说明吗？
– Pierre.Vriens♦
17 Mar 9 '17 at 8:13
评论
您确实联系了一个团队，这意味着他们应该已经就现有的认可原则获得了满意。我真的开始讨厌那些反问的问题：（只是我的意见，不要太在意它@Tensibai怎么可能一个人“预先祝福了一些补丁”（或修复），却不知道“与您联系”时问题的原因是什么？另外，您能更具体地谈谈修辞吗？不太适合吗？
我的意思是您说您可以在3:20与团队联系，这意味着不仅您要解决问题。我将修辞作为“假设案例，根据经验与否，您已经知道正在等待哪个答案”。我对meta的担忧或多或少让我感到自己对这种“通用原则” Q / A并不感兴趣，所以我可能是错的。我可以肯定的是，如果我是该测试版的外行，我将不会两次访问通用原则的问答。
如果通用詹金斯问题即将来临，我可能会说同样的话
直到公开测试版才会计算承诺，目前，我们正在私下建立“承诺的”用户对此网站的模范问题，我认为在剩下的12天内还有很多工作要做，或者我可能只是必须经历悲伤的七个阶段