工程师部署和运行代码时，哪些流程或工具可实现职责分离？

在金融服务等高度管制的环境中，职责分工是避免具有发展责任和生产特权的个人之间发生冲突的重要机制。

传统上，这意味着开发人员先开发代码，然后将其移交给操作，但是在许多DevOps操作模型中，开发和操作之间的隔离至少是模糊的：

• 在Google的站点可靠性工程（SRE）中，实践是Google内有一个单独的SRE功能，但是，在高运营负荷时，开发人员被邀请来支持SRE。

• 在“构建，运行”模型中，没有单独的操作功能。

在花费数月时间深入研究职责隔离机制的根本原因之后，似乎似乎主要存在满足萨班斯·奥克斯利法案第404节：内部控制的管理评估：

（a）所需规则。委员会应制定规则，要求1934年《证券交易法》第13（a）或15（d）条要求的每个年度报告均应包含内部控制报告，该报告应-

（1）陈述管理层的责任，以建立和维持适当的财务报告内部控制结构和程序；和

（2）包含截至发行人最近一个会计年度结束时对发行人财务报告内部控制结构和程序有效性的评估。

（b）内部控制评价和报告。根据（a）款要求的内部控制评估，每个为发行人准备或发行审计报告的注册会计师事务所均应证明并报告发行人管理层的评估。根据本小节做出的证明应按照董事会发布或采用的证明业务的标准进行。任何此类证明均不应成为单独的约定的主题。

根据这些评论，重要的是要指出我所做的几个假设：

• 我主要考虑的是大众市场金融服务，即交易量很高，但价值相对较低。这与具有不同交易价值特征的商业金融服务相反。
• 金融机构的在线服务将由许多具有不同风险考虑因素的组件组成：
  • 转移资金 -在帐户之间转移资金或在不同所有者的帐户之间转移资金。必须考虑反洗钱，欺诈保护和禁运国家的行动。
  • 客户获取 -与“移动资金”相比，交易量较低，但“风险”较低，但仍需要考虑。
  • 网上银行 -涵盖范围广泛且风险程度不同的服务，“移动资金”将被视为其中的一部分。
• 可以想象，对于每种风险，可以针对每种风险采取不同的方法，但是，为了保持简单性，我正在努力寻求一种适用于某些风险最高的运营的解决方案。

TL; DR：管理层的责任是确保建立适当的内部控制措施，以符合美国证券交易委员会的 规定。

通常，通过完成自上而下的风险评估可以使Sarbanes Oxley 404满意，其中一部分将评估共谋风险并提出缓解策略。

在采用DevOps实践和文化的公司中，开发人员通常可以同时访问源代码控制和生产，如何实现职责分离，或更普遍地讲，如何降低合谋风险。

您的问题似乎并未对要使用的平台/操作系统做出任何假设。这就是为什么要添加一个有关大型机环境中通常如何完成/解决问题的答案的原因，在大型机环境中，“工程师”（如您的问题标题所示）实际上是一群人，其中有数十人（可能是数百人）参与。我的答案是基于使用我最熟悉的SCM产品（不确定是否需要公开产品名称）。

1.建筑

以下是我将如何回答您的问题的重点内容：

• 所有代码（以及相关的工件，如可执行文件等）都存储在文件中，这些文件统称为我们的库结构。
• 对于每个（可能是远程）目标系统上的每个环境，都有一个服务器（在大型机中为“启动任务”），它负责对库结构中的所有内容进行ALL更新（重复：ALL）。有一些例外情况（例如安全人员或空间管理团队），但除此之外，没有人（重复：没人）有权将更新应用于该库结构内的任何文件。换句话说：服务器获得整个库结构的独占更新权限。注意：如果您进入以限制他们的访问权限，OPS人员将变得更加愚蠢（起初，他们将抵抗...），因此请确保您被高层管理人员（CxO）覆盖以强加这些访问规则...
• 实际的软件更改仅由一个组件（半夜中的一个小代码修复……）组成，或者也可能是成百上千个源，可执行文件或任何其他构件（在发行周末期间）。为了使它们易于管理，应将应同时移动（或多或少）的事物捆绑在一起，称为软件变更包。

通过上述操作，只有通过定义明确的工作流程，服务器才能对库结构进行任何类型的更新，我们将其称为软件变更包（如果需要，请选择SDLC）的生命周期。要实际执行该工作流程中的各个步骤，需要执行以下操作：

• 只有服务器将执行必需的（和预配置的）步骤。
• 在收集（执行）所需的批准后，服务器将仅执行特定步骤（=更新库结构中的某处）。
• 批准只能由具有允许他们（=权限）发布此类批准的角色的用户提供。

2.角色和权限

步骤1：配置权限（在安全系统中）

• 在安全系统中定义安全实体，并为这些实体定义明确的名称。一些样本（添加尽可能多的类似样本以满足您自己的需求）：

  • PrmUnit，用于获取权限申请一个促进要说单位 -testing。
  • PrmQA，用于获取权限申请一个推动说QA -testing（假设这是测试的最高级别）。
  • PrdEnduser，由参与某些级别测试的最终用户使用，表示对某种测试产生的结果感到满意。因此，这些最终用户同意库结构中不断发展的变化。
  • PrdRelmgnt，由发布经理用于授权生产中的激活（=库结构中的最后/最高级别）。

• 在安全系统中定义用户组。一些样本（添加尽可能多的类似样本以满足您自己的需求）：

  • GrpDevs，（例如）与您的开发人员相对应（可能多于1）。
  • GrpEnduser，（例如）与您的最终用户（至少1个，最好是更多相似的用户）相对应。
  • GrpRelMgnt，（例如）与您的发布经理（至少1个，最好是几个用户）相对应。

• 授予权限，也使用您的安全系统，以允许访问选定“ 用户组 ”的选定“ 安全实体 ”。继续上面的示例，这似乎是合适的（适合您自己的需求）：

  • 组GrpDevs可以访问（仅！）安全实体PrmUnit。
  • 组GrpEnduser可以访问（仅！）安全实体PrdEnduser。
  • 组GrpRelMgnt可以访问（均为！）安全实体 PrmQA和PrdRelmgnt。

步骤2：配置工作流程（在SCM系统中）

在安全系统中配置了权限之后（如步骤1中所述），在SCM系统中要做的就是配置生命周期中的各个步骤与安全系统中的相关安全实体的匹配方式。也就是说，只有那些对所需安全实体具有适当访问权限的用户才被允许请求服务器执行工作流中的相应步骤。

以下是一些示例，说明如何配置SCM系统以使某些事情发生：

• 如果用户有权访问PrmUnit，则这种用户被允许请求促进到单位 -testing。显然，组GrpDevs中的用户是为此授权的用户（请注意：例如，不是组中的用户GrpRelMgnt）。
• 如果用户有权访问PrmQA，则这种用户被允许请求促进至QA -testing。显然，组GrpRelMgnt中的用户是为此授权的用户（请注意：不是，例如组GrpDevs或组中的用户GrpEnduser）。
• 如果用户可以访问PrdEnduser，则允许该用户授权更改在库结构中向前移动（这通常是组中用户GrpRelMgnt甚至可以查看更改的先决条件）。显然，组GrpEnduser中的用户是为此授权的（唯一）用户。
• 如果用户有权访问PrdRelmgnt，则允许该用户授权生产中的激活（=库结构中的最后/最高级别）。

3.期待意外，并做好准备

上面只是一个蓝图，希望可以最终帮助理解服务器是如何完成职责分离的……如果您有CxO的权限，可以强加一些并非所有人都会喜欢的访问规则。

为了完成上述说明，服务器创建了系统中所有活动的审核跟踪（日志记录）。因此，在任何时间点，始终可以回答诸如

什么时候以及为什么发生什么事，哪个授权用户实际上批准了它？

但是，最困难的部分可能是要有足够的可用报告工具（并知道如何使用它们）。至少（轻松）满足IT审核员的要求（他们的问题可能非常具有挑战性）。还要指向SCM系统中的相关日志记录，以回答（部分）生产下降的危机情况下的各种“发生了什么”问题。

根据我对法国“内部控制”法规（相当于您所指的SEC法规）的了解得出的答案，我认为将此处链接至法国法律文本并没有多大用处，并且我也没有很好的翻译。

在理想的“构建，运行”模型中，团队中的每个人都应对变更负责。不能通过职责分离来实施风险评估，而我知道要始终遵守法规，唯一的方法是对交易进行定期的短周期审核，并进行不可更改的操作跟踪，以退回执行释放的人员。
这意味着所有事务和操作的日志都被推送到团队无法访问的限制区域，“应”记录的更改应由团队无法访问的功能测试来捕获，更糟糕的是会被捕获由审核并跟踪其作者。

这不适用于所有产品，在法国撰写本文时，任何允许放款的公司（主要是银行）都必须确保记录每笔交易，因此不会冒错过交易的风险。
另一方面，当某人要求贷款时，他们没有法律义务跟踪任何商业报价或风险评估，因此处理此客户选择并计算报价中费用的产品更容易放入邮局中。发布审核模型。

主要思想是必须根据风险评估义务对发布模型进行调整。

相关资源是ISO27001规范。

恕我直言，开发人员和运营人员只能由两个相同代码库的 git存储库来表示，每个存储库具有不同的权限模型，因此团队完全不会干涉彼此的工作。

举个例子，我们称它们为Dev.mygithub.co＆ops.mygithub.co。

这个想法是，开发人员可以自由地创建/分支/合并他们内心的内容-git提供了完全可追溯性，而这才是至关重要的-同时，在监管框架暗示可以进行审核工作的时刻，可以提出“ 拉取请求”，合并以受控方式发生。

将该概念推向新的高度，可以通过另一个“ 拉取请求 ”操作将开发分支传播到远程Ops的生产中。最后一部分必须由操作人员的手和眼睛来完成，因为他们有责任对其进行审核，并选择审核级别。

这种方案具有无限的灵活性，完全的可追溯性，通过各种流程尽早发现问题的能力，关注点分离以及流程中非常合理的用户体验！

注意即使操作和开发完全重叠，也可以遵循上述模型！

越高越昂贵：

• 独特的开发和运营站点和方法，将工作从一个转移到另一个
• 如上所述的独特的开发和运营系统和方法
• 独特的dev和ops git / vcs存储库及相关方法
• 独特的dev和ops git / vcs分支（受保护）及相关方法

根据您的工作，某些解决方案要比其他解决方案好，例如，如果您需要为两个团队提供服务，每个团队中有不同的角色，每个团队都拥有所有权并提供完全的可追溯性，那么您可以将鼠标悬停在前三个之上。

简而言之，任何强迫一个人或gal采取的措施都不能孤军奋战，并且必须跨越开发人员和操作人员之间明确的界限。现在，根据风险级别，可能会强制执行该边界，也可能不会执行该边界。