在Google的站点可靠性工程（SRE）中，实践中Google拥有单独的SRE功能但是，在高操作负载时，开发人员会介入以支持SRE。
在“您构建，运行”模型中，没有单独的操作功能。 br />
花了几个月的时间深入研究职责隔离机制的根本原因后，看来似乎最主要的是要满足Sarbanes Oxley第404节：内部控制的管理评估：
（a）规则s必须。
委员会应制定规则，要求1934年《证券交易法》第13（a）或15（d）条要求的每份年度报告均应包含内部控制报告，该报告应- （1）陈述管理层的责任，以建立和维持适当的财务报告内部控制结构和程序；和
（2）包含对发行人最近一个会计年度结束时对发行人进行财务报告的内部控制结构和程序的有效性的评估。
（b）内部控制评价与报告。根据第（a）款要求的内部控制评估，每个为发行人准备或发布审计报告的注册会计师事务所均应证明并报告发行人管理层的评估。根据本小节作出的证明应按照理事会发布或采用的证明业务的标准进行。
根据评论，重要的是要指出我正在做的两个假设：
我主要是考虑到大众市场金融服务，即交易量高但价值相对较低。这与具有不同交易价值配置文件的商业金融服务相反。
金融机构的在线产品将由许多具有不同风险考虑因素的组件组成：
转移资金-在帐户之间转移资金或在不同所有者的帐户之间转移资金。该业务必须考虑反洗钱，欺诈保护和禁运国家等。
客户获取-与“移动资金”相比，它的交易量较低，因此“风险”较低仍然需要考虑。
互联网银行-涵盖了具有不同风险级别的广泛服务，Move Money将被视为其中的一部分。
对于每种风险，可以采用不同的方法，但是，为了简化操作，我正在努力寻求一种适用于某些风险最大的操作的解决方案。
; TL：DR：管理层有责任确保建立适当的内部控制措施，以符合美国证券交易委员会的规定。
通常，通过完成自上而下的风险评估可以使Sarbanes Oxley 404满意，其中一部分将评估合谋风险并提出缓解策略。
在一家采用DevOps实践和文化的公司中，开发人员通常会既可以使用源代码控制又可以使用生产，如何实现职责分离，或更普遍地讲，如何降低合谋风险。
#1 楼
您的问题似乎并未对要使用的平台/操作系统做出任何假设。这就是为什么在大型机环境中添加一个有关通常如何完成/解决此问题的答案的原因，在大型机环境中，“工程师”（如您的问题标题所示）实际上是一群人，其中有数十人（可能是数百人）参与。我的答案是基于使用我最熟悉的SCM产品（不确定是否需要透露产品名称）。1。架构
以下是我将如何回答您的问题的重点：
所有代码（以及相关的工件，如可执行文件等）都是存储在文件中，这就是我们所说的库结构。
对于每个（可能是远程）目标系统上的每个环境，都有一个服务器（在大型机中为“启动任务”），它负责ALL（重复：ALL）更新为库结构中的任何内容。有一些例外情况（例如安全人员或空间管理团队），但除此之外，没有人（重复：没人）有权将更新应用于该库结构内的任何文件。换句话说：服务器获得整个库结构的独占更新权限。注意：如果您进入以限制他们的访问权限，OPS人员将变得更加愚蠢（起初，他们将抵抗……），因此请确保您被高层管理人员（CxO）覆盖以强加这些访问规则...
实际的软件更改由一个组件（半夜中的一个小代码修复...）组成，或者也可能是成百上千个源，可执行文件或其他任何工件（在周末发布）。为了使它们易于管理，应将（或多或少）应同时移动的内容捆绑在一起，称为“软件更改包”。
通过上述操作，只有通过定义明确的工作流程，服务器才能对库结构应用任何类型的更新，我们将其称为软件变更包的生命周期（如果需要，则为SDLC）。要实际执行该工作流程中的各个步骤，需要执行以下操作：
只有服务器将执行所需（和预先配置的）步骤。
在获得所需的批准（来自人类）以执行此步骤之后，服务器将仅执行特定步骤（=更新库结构中的某处）。
只有拥有允许他们（=许可）发布此类批准的角色。
2。角色和权限
服务器将确保只有当用户许可时，试图使某事（例如“批准某事”）的用户才能这样做是适当的。这部分很容易。但是，您不想使用SCM系统为所有相关用户管理所有这些权限，这就是您的安全系统（不是SCM系统！）所属的权限，以便您可以调整工作流程（在SCM系统中）在适当的时候去检查那些权限。以下步骤提供了更多详细信息。
步骤1 ：（在安全系统中）配置权限
在以下位置定义安全实体您的安全系统，以及这些实体的明确定义的名称。一些示例（添加了许多类似的示例以满足您自己的需求）：
PrmUnit，用于获得许可以请求促销员说单元测试。PrmQA，用于获得许可要求推广员说Qa测试（假设这是最高级别的测试）。由参与某些级别测试的最终用户使用
PrdEnduser表示对某种测试所产生的结果感到满意。因此，这些最终用户同意库结构中不断发展的变化。PrdRelmgnt，版本管理者使用它授权生产中的激活（=库中的最后/最高级别）结构）。定义安全系统中的用户组。一些示例（添加许多相似的示例以满足您自己的需求）：
GrpDevs，（例如）与您的开发人员相对应（可能多于1个）。 GrpEnduser，它（例如）与您的最终用户相对应（至少1个，最好有更多类似的用户）。管理员（至少1个，最好是几个用户）。授予权限，也使用您的安全系统，以允许访问选定“用户组”。继续上面的示例，这似乎是合适的（适合您自己的需求）：
组
GrpRelMgnt可以访问（仅！）安全实体GrpDevs。 PrmUnit可以访问（仅！）安全实体GrpEnduser。组
PrdEnduser可以访问（两者！）安全实体GrpRelMgnt和PrmQA。步骤2：配置工作流程（在SCM系统中）
在安全系统中配置权限后（如步骤1中所述），剩下的要做的就是配置SCM系统中的各个步骤。生命周期与安全系统中的相关安全实体匹配。也就是说，只有那些对所需安全实体具有适当访问权限的用户才被允许请求服务器执行工作流程中的相应步骤。
以下是一些配置示例您的SCM系统来实现一些神奇的效果：
如果用户可以访问
PrdRelmgnt，则允许该用户请求升级为单元测试。显然，PrmUnit组中的用户是为此授权的用户（请注意：例如，不是GrpDevs组中的用户）。如果用户有权访问
GrpRelMgnt，则该用户可以请求升级为QA测试。显然，组PrmQA中的用户是为此授权的用户（请注意：例如，不是GrpRelMgnt组或GrpDevs组中的用户）。如果用户有权访问
GrpEnduser，则该用户可以授权更改在库结构中向前移动（这通常是PrdEnduser组中的用户甚至可以查看更改的先决条件）。显然，组GrpRelMgnt中的用户是为此授权的（唯一）用户。如果用户有权访问
GrpEnduser，则允许该用户授权生产中的激活（=库中的最后/最高级别）结构）。3。期望意外的事情，并为此做好准备。
上面只是一个蓝图，它有望最终帮助理解服务器是如何处理职责分离的。 ..只要您具有CxO的权限，您就可以强加一些并非所有人都会喜欢的访问规则。
为了完成上述说明，服务器会创建一个审计跟踪（日志记录），以记录发生的所有情况系统。因此，在任何时间点，始终可以回答诸如
的问题，何时何地发生了什么，以及哪个授权用户实际上批准了它……预先？
但是，最困难的部分可能是要有足够的可用报告工具（并知道如何使用它们）。至少（轻松）满足IT审核员的要求（他们的问题可能非常具有挑战性）。而且还要指向您的SCM系统中的相关日志记录，以回答各种（部分）生产下降的危机情况下的各种“发生了什么”问题。
PS：如果我的回答是“是”或“否”，则由每个人自己决定。
评论
这听起来像是自上而下的风险评估的基本实现，但我不知道它如何解决如何以开发人员有权触发“部署”切换的开发人员方式实施此问题。是不是您不能在devops组织中做到这一点？
–滕西拜
17 Mar 20 '17在20:36
@Tensibai“如果”开发人员将具有（例如）产品最终批准的授权（角色）（他们通常在此类组织中没有），则该服务器（启动任务）将开始部署。按照问题的标题，我认为这是一个“可能”的答案。但是，人们可能会质疑这是否就是我们所说的DevOps组织，但我确实知道审计师真的很喜欢这种“可配置”的职责划分（例如：四眼及其变化）。理查德也许可以在他的观点上帮助我们？
– Pierre.Vriens♦
17 Mar 20 '17在20:52
我同意审核员绝对喜欢它，我只是想念这与访问“爆炸”的关系/适合性，当列表包含6到7个人时，审核员通常不喜欢它。说它不合适是恕我直言的绝对有效答案。
–滕西拜
17年3月20日在21:00
谢谢您花了很多时间回答。我实际上是在考虑实施三人规则，即，一个开发人员编写代码，另一位开发人员查看代码，而第三人按下发布按钮以部署代码。另一个考虑因素是，因为这是整个公司采用敏捷/ DevOps的一部分，因此开发团队非常小，只有一小部分人可以从生产中获得生产的机会，因此从风险角度来看这似乎是有利的。
–Richard Slater
17年3月21日在8:01
@ Pierre.Vriens无法投票两次，很好的扩展:)
–滕西拜
17年3月21日在17:00
#2 楼
根据我对法国“内部控制”法规（相当于您所指的SEC法规）的了解得出的答案，我认为将此处链接至法国法律文本并不会真正有用，并且我也没有很好的翻译。在理想的“构建，运行”模型中，团队中的每个人都应对变更负责。不能通过职责分离来强制执行风险评估，而我知道要始终遵守法规，唯一的方法就是对交易进行定期的短周期审核，并进行不可更改的操作跟踪，以退回执行释放的人员。
这意味着所有事务和操作的日志都被推送到团队无法访问的限制区域，团队无法访问的功能测试应该“记录”更改所记录的内容，并且更糟糕的是，审计会捕获并跟踪其作者。
这不适用于所有产品，在法国撰写本文时，任何允许放款的公司（主要是银行）都必须确保每笔交易都将被记录在案，因此不能承担以下风险：缺少交易。
另一方面，当某人要求贷款时，他们没有法律义务跟踪任何商业报价或风险评估，因此处理此客户选择并计算费用的产品该提议更容易适合发布后的审核模型。
主要思想是必须根据风险评估义务来调整发布模型。
相关资源是ISO27001规范。
评论
有趣的答案和许多欧洲银行确实在法国开展业务非常相关。您是否有可能扩大“汇款”的含义，即仅从ATM提取现金还是包括余额转帐。在这种情况下，与法规的链接将是有价值的，因为它提供了指向相关法律的指针，无论它们所使用的语言是什么。
–Richard Slater
17年3月21日在7:51
@RichardSlater简而言之，任何有钱的公司都可以是一家仅投资公司，也可以是传统银行的贷款经纪人。大多数情况下，任何涉及财务影响的事情都会受到关注（在某些情况下，当局会给予少数例外）。法语中的合法“清单”在这里，但是即使是法语中的清单也并不总是很明显。
–滕西拜
17年3月21日在8:28
我假设与ISO标准的链接实际上应该是ISO27001：2013
–Richard Slater
17年3月21日在18:17
的确，@ Richard的法语到英语链接似乎尚未在Wikipedia上更新。我稍后再更新（或者，如果您愿意，随时进行编辑）
–滕西拜
17年3月21日在18:30
相关：我如何说服团队中的开发人员接受“您构建，运行”？
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 26 '17在3:49
#3 楼
恕我直言，开发人员和运营部可以仅由两个相同代码库的git存储库来表示，每个存储库具有不同的权限模型，因此团队完全不会干涉彼此的工作。让我们将其称为Dev.mygithub.co＆ops.mygithub.co。
想法是，开发人员可以自由地创建/分支/合并他们内心的内容-git是提供全面的可追溯性，这就是当前要紧的事情；与此同时，在监管框架暗示审查工作的时刻，可以提出“拉取请求”，以便以受控方式进行合并。
在下一级别，可以通过另一个“拉动请求”操作将开发分支传播到远程Ops的生产。
最后一部分必须由操作人员的手和眼睛来完成，因为他们有责任将其审核到生产中，并且他们选择审核级别。
这种方案允许无限的灵活性，全面性可追溯性，通过各种流程及早发现问题的能力，关注点分离以及流程中非常合理的用户体验！
NB即使Ops＆Dev完全重叠，也可以遵循上述模型！
评论
当然，可以通过拉取请求和提交后挂钩来实现相同的控制，以确保开发人员可以自由进行提交，但是，合并提交只能由经过批准的人员进行。同样，相同的提交后钩子可以确保构成拉取请求的提交的作者中不包括提出拉取请求的人。
–Richard Slater
17年3月21日在18:14
@RichardSlater：您可能希望拥有两个不同的存储库的原因是，您双重需要允许开发人员进行合并（当他们在开发人员模式下自由交换代码时）以及阻止大多数开发人员在合并时进行合并进行生产（采用SysOps模，即所谓的“经过批准的人员”）。
–fgeorgatos
17年6月24日在8:04
同样，您可以使用提交后的钩子和拉取请求来实现这一点，更不用说GitHub Enterprise允许受保护的分支了。
–Richard Slater
17年6月24日在9:05
#4 楼
更高的则更昂贵：与众不同的dev和ops站点和方法将工作从一个转移到另一个
与众不同的dev和ops系统和方法如上述
独特的dev和ops git / vcs存储库及相关方法
与众不同dev和ops git / vcs分支（受保护）及相关方法
根据您的工作，某些解决方案比其他解决方案要好，例如，如果您需要为两个团队工作，而每个团队中都有各自不同的角色，并且每个团队都拥有所有权并提供完整的可追溯性，那么您可以将鼠标悬停在前三个上。或gal不能独自接球并继续奔跑，他/他越过了开发人员和操作人员之间明确的明确界限。
现在，根据风险的程度，该界限可能会强制执行或不强制执行。
/>
评论
devops组织背后的主要思想是使团队中的每个人对生产中发生的事情负责，不能分工。这主要意味着，在有监管要求进行这种分离时，不能真正使用这种组织。@Tensbai我从根本上不同意DevOps与职责分离不兼容的说法。法律不是关于控制方式的规定，监管者也不是对银行和金融服务机构施加预定义的过程。很大程度上要由组织来确定合适的方法，并与监管机构及其任命的审核员完全透明。举例来说，ING和巴克莱银行都采用了DevOps做法，以使他们能够加快向客户提供价值的能力。
是的，他们致力于不受监管分离约束的主题，他们利用传统基于筒仓的组织中的自动化来限制主题（实际上很少）。他们只有两种组织，具体取决于软件将执行哪种操作
法规/法律和监管机构不对金融机构施加“监管隔离”之类的规定，它们对管理金融风险的管理机构施加“适当控制”的职责。就像敏捷将软件开发从长周期转变为小周期一样，DevOps会将操作分成小周期，金融服务中的DevOps需要找到一种将职责分离变成小周期的方法，例如，通过创建CD管道来实施“适当的控制”，例如基于同行评审和批准的促销。
@ Pierre.Vriens是的，标题中有一个广泛的问题，我已经尝试通过做一些假设来扩大它的范围。角色可能是解决方案的一部分，例如Break-Glass和Privileged Account Management。角色和职责是DevOps / Agile中一个有趣的概念，因为您曾经有过Java开发人员，F / E开发人员，设计师，PM，构建工程师，发布经理和Ops工程师-现在您拥有一群可以戴上多顶帽子-由“工程师”组成的跨职能团队，他们可能专门但最终承担责任。