MichaelGrünewald最近发表了此评论:


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


如果我错了,请纠正我,但是我被告知“四眼原理”是关于至少有2个人(和/或自动化过程)给予他们事先的祝福后,“批准发生”。或使用维基百科中有关“两人制”的(略有修正)措辞:


两人制是旨在实现较高水平的控制机制特别重要的材料或操作的安全性。根据此规则,所有访问和操作都始终需要有两个授权人员在场。 ”,那么这种四眼原则的可能的概念实现是什么,它可能适用于所使用的任何平台/操作系统/硬件?

#1 楼

代码的一种实现是GitHub流行的Pull Request模型(PR)。

其背后的主要理由是,只允许该产品的一小部分维护者将代码合并到发行版中科。每个新功能/错误修复都将在新分支上发生,一旦完成将被定义为请求请求。

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

自动测试通过后,对于四眼原理,仍然需要可配置数量的人员来审核并批准更改,然后合并至少至少1个人(不是公关作者)要求四只眼睛查看更改。

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

可以将查看和合并的权限分开,这有助于赋予更多人对合并状态进行“投票”的权利,同时还可以限制谁可以实际执行合并。

评论


请检查您答案的细微修改(错别字)。如果您不喜欢它们,只需回滚或重新编辑,好吗?另外,我还没有考虑过这些PR,所以我认为确实很适用。我将这个答案标记为已接受(我从中学到的东西,当然是我自己知道的答案)。尽管我不能保证将来会发布更好的答案,但我可能会改变主意(不接受)。关于:“这允许自动测试实际发布(主)代码与PR中代码的合并”,我不明白,我应该发布一个新问题吗?

– Pierre.Vriens♦
17年3月13日在18:03

@pierre您可以自由地改变主意:)为了测试建议的代码,Travis CI(例如)可以在合并了请求请求代码的实际master的结果上运行,因此它将如果无法合并,或者travisci.yml中定义的命令返回非零退出代码,则失败。 FWIW,谷歌搜索最好的方法恕我直言,主题很大

–滕西拜
17年3月13日在20:18

@pierre,对于编辑,只有一点,四眼原则是要再有1个人进行查看,这意味着2个人确实查看了更改(作者没有查看过此更改),因此单数表示可变的人(因为它可能只有一个,而在法语中可能只有一个是单数:p)。我的英语说得不太流利,但是我认为第一点是有效的(2位读者,2位确实看过它,使它成为一项评论),第二点我可能有偏见:)

–滕西拜
17年3月13日在20:25

啊哈,这就是您的意思,现在我明白了(并随意将多余的说明复制/粘贴到您的答案中)。 BTW:示例(在EN中),而不是示例(在FR中)...

– Pierre.Vriens♦
17年3月13日在20:41

@ Pierre.Vriens责备自动纠正双语言:)

–滕西拜
17年3月13日在20:42

#2 楼

代码评论

这是关于让至少一个其他人查看某人编写的代码,例如,评估它是否符合某些预定义的条件,例如:


编码标准(缩进等)。
内联文档。
代码的可维护性。
错误处理。
完整性(例如,if/then/elsecase/when结构涵盖所有可能的情况)。

批准更新某些目标环境

这是关于在允许更新某些目标环境(可能是实时的)之前,至少要获得某人和/或自动化系统的两​​次确认,也可能是某些主文件/基准库之类的东西。以下是一些示例:


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


#3 楼

这些是我可以想到的策略/模式:

职责分离

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

例如,如果要在SQL语句上执行一条SQL语句,实时环境,一个人编写SQL,另一个人执行SQL。
这是一个执行需求,即也需要对SQL有了解,而不仅仅是执行。

部署触发器
/>
尽管有不断部署的优点。受到更严格监管的行业中的团队可以任命另一(独立)方来触发部署,而不是自动进行部署。清单,自动测试,校验和是触发部署之前可能进行的检查。

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

配对编程

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

MFA

我可能对此有所延伸,但由于某些原因,您可能不这样做要单方面进入系统,某人可以持有密码,而另一人可以持有令牌或设备一次代码。因此,必须有2个人在场以评估系统。

评论


感谢这些有趣的变化!以前从未听说过“配对编程”,这的确像是用“ 4手”弹钢琴的变体!

– Pierre.Vriens♦
17 Mar 23 '17 at 18:47

我最近采访了一家公司,该公司从事我所见过的最密集的结对编程形式。他们有两台机器的“ pod”设置,每台机器都有一台专用显示器和一台共享显示器。所有开发都是成对完成的。它并不适合所有人,但从所有报告来看,它对他们都有效。

–戴夫·斯沃斯基(Dave Swersky)
17 Mar 23 '17 at 19:25