四眼原理的可能实现方式（或示例）是什么？

MichaelGrünewald最近发布了此评论：

您没有提到的一个非常重要的方法是在金融中使用的“四眼原则” –作为监管义务或作为安全保障。在软件行业中，它以多种方式实现，例如代码审查，但也可用于验证影响实时系统的命令。

如果我错了，请纠正我，但是在至少2个人（和/或自动化过程）给予了他们先前的祝福之后，我被告知“四眼原则”是关于“被批准发生”的事情。或使用有关的（略修正）的措辞“两轮（WO）人治”从维基百科：

两人规则是一种控制机制，旨在为特别重要的物料或操作实现高级别的安全性。根据此规则，所有访问和操作都必须始终有两个授权人员在场。

可以肯定的是，监管义务不在本文的讨论范围之内，但是在“安全防范”的背景下，这种四眼原则的可能概念性实现是什么，它们可能适用于所使用的任何平台/操作系统/硬件？

在代码上的一种实现是GitHub流行的Pull Request模型（PR）。

背后的主要原因是，只允许产品的一小部分维护者将代码合并到release分支中。每个新功能/错误修复将在新分支上发生，一旦完成，将被定义为请求请求。

这允许自动测试实际发布（主）代码与PR中代码的合并（Travis实际上是公共项目中最受欢迎的代码），并首先反馈代码质量。例如，Travis CI可以在实际主服务器的结果上运行，并且合并了拉取请求中的代码，因此如果无法合并，或者travisci.yml中定义的命令返回非零退出，它将失败。码

自动测试通过后，对于4眼原理，仍然需要可配置数量的人员来审查和批准更改，然后才能将其合并，显然，至少有1个人（不是PR作者）强制执行4眼对变化。

有多种选项可以在满足审阅者的法定人数后自动合并，或者仍然需要维护者手动合并。

审阅和合并的权限可以分开，这有助于赋予更多人对合并状态进行“投票”的权利，同时保留限制实际执行合并的人员的可能性。

代码评论

这是关于让至少一个其他人查看某人编写的代码，例如评估它是否满足一些预定义的标准，例如：

• 编码标准（缩进等）。
• 内联文档。
• 代码的可维护性。
• 错误处理。
• 完整性（例如if/then/else，case/when结构涵盖所有可能的情况）。

批准更新某些目标环境

这是关于在允许更新某些目标环境（可能是实时的，也可能是某些主文件/基准库之类的东西）之前，从某人和/或自动化系统至少获得2条确认。一些例子是：

• 在可执行组件中转换（构建）源组件时，仅允许使用一组有限的警告。
• 某些自动化测试必须已经完成而没有任何探针。
• 有些人必须事先表示同意（否则，任何更新目标环境的尝试都会自动失败）。

这些是我能想到的策略/模式：

职责分离

至少在我看来，DevOps并不意味着将dev和ops都包含在一个人中。因此，仍然有可能将职责分开，以使编写代码的人（开发人员）而不是执行代码的人（运营人）。

例如，如果要在实时环境中执行一条SQL语句，则编写一个SQL，然后执行另一个。这种预设是一个执行需求，即也需要对SQL有一个理解，而不仅仅是执行。

部署触发器

虽然有不断部署的优点。受到更严格监管的行业中的团队可以任命另一（独立）方来触发部署，而不是自动部署。清单，自动测试，校验和是触发部署之前的可能检查。

一旦触发，自动化就可以继续执行部署。

配对编程

我个人没有将此技术作为审核员满足制衡原则的一种方法。但是我认为这可能是一种策略。

外交部

我可能会对此进行一些扩展，但是由于某些原因，您可能不想单方面进入系统，因此有人可以保留密码，而另一个人可以保留令牌或设备一次代码。因此，必须有2个人在场以评估系统。