[译] DevOps VS 职责分离

原文地址：
medium.com/@jeehad.jeb…
原文做者：Jeehad Jebeile
翻译君：CODING 戴维奥普斯

在国内很多的研发组织依然经过职责分离的方式来管理研发团队，这种状况下就会形成团队之间合做效率低下、责任互相推诿等问题。咱们翻译了如下这篇文章来与读者们一块儿探讨 DevOps 与职责分离究竟该如何结合在一块儿，从而更好地提升研发团队的效率。

引言

如何把 DevOps 与职责分离完美地融合在一块儿？

DevOps 和职责分离（SoD：Segregation of Duties）一般不会相提并论。DevOps 旨在消除障碍并最大限度地减小交接，而职责分离则是经过增长隔离以最大限度地下降风险。

在受到高度监管的行业（如金融、医疗保健）工做时，采用 DevOps 工做方式来运做团队可能很是具备挑战性。这是由于监管机构但愿只有通过请求、批准以及充分测试的变动才能进入生产环境。在这些状况下，主要的控制方式其实是职责分离。

职责分离

什么是职责分离？

职责分离（SoD）是不止一人来完成任务的概念。在商业中，经过在一个任务中经过多我的来实现分离是一种旨在防止欺诈和错误的内部控制方式。
—— 维基百科

在软件工程领域，这基本上意味着开发代码的人或团队没法批准他人或者本身部署代码。 这是为了防止意外或恶意将未经受权的代码发布到生产环境中。

相比之下，DevOps 是将开发和运维两个分离的功能合二为一。一个团队同时能够开发和测试代码，还支持部署代码。隔离，意味着将人或者事物从主体中剥离出来，这仍然是目前常见的控制生产环境的方法之一。

在 DevOps 团队中实行职责分离的缺点是什么？

• SoD 会经过添加没必要要的切换来下降团队速度，而且可能会引入错误。每次发生切换时，都须要进行信息传递，这不只会下降速度，还可能会致使信息传递有误。交接不只会影响变动的部署，还会影响生产环境中紧急事件的处理。在这种状况下，处理事情的责任人最好是能更好地响应事件而不是负责变动的人（或团队）。
• 职责分离代表对团队缺少信任，这滋长了“恐惧”文化的培养。DevOps 团队须要自主，以得到这个理念所宣扬的所有价值和速度优点。为了实现这种自主权，团队须要始终被信任他们正在作正确的事情。在他们作错事的时候，依然会被要求负责并纠正错误。请记住，能力越大，责任就越大。
• SoD 没法解决与共同决策有关的问题。这涉及到有人（或团队）故意将未经受权的变动推向生产，不管他们是出于恶意仍是出于紧急状况来企图破坏这过程。例如，他们会说：“咱们没有时间进行完整的回归测试，由于咱们须要明天发布，你能不能立刻签名？”。不管有多少控制措施，你都没法摆脱这个问题。

若是你别无选择，只能实施 SoD 该怎么办？

正如文章开头中所提到的，有一些受到高度监管的行业不容许 DevOps 团队彻底自主地工做。若是你发现本身遇到这种状况，如下是你的团队应该关注的一些事项。

最大限度地减小交接次数

DevOps 的主要原则之一是改进你的工做流，以便执行任务的效率是最高的。在 DevOps 中，重点一般是 SDLC（即 CI/CD），但其实最小化切换能够应用于团队中的大多数流程。在最开始，须要首先经过确认工做流之间的相关性来评估现有流程；随后，你能够经过简化流程来得到实现目标所需的最少步骤数。肯定新的工做流后，你能够加上自动化了。但要记住， 即便自动化很重要而且一般也是一个好主意，但自动化一个糟糕或者冗余的流程是没有任何意义的。因此先确认工做流，优化它，而后自动化。
译者注：SDLC（systems development life cycle）即系统发展生命周期，也称软件生命周期，用于描述一个信息系统从规划、建立、测试到最终完成部署的全过程。

自动化

自动化你的构建、测试和部署。经过自动化交付流水线，你能够最大限度地下降人为错误致使的风险。

• 持续集成： 是一种开发实践，须要开发人员天天屡次将代码集成到共享代码存储库中。而后经过自动构建和单元测试过程验证每一个签入，可让团队尽早发现问题。
• 持续交付： 是持续集成的天然延伸：团队确保对系统的每次更改都是可发布的，而且咱们只需按一下按钮便可发布任何版本。持续交付旨在使发布成为一件无聊的事情，咱们能够常常快速交付而且快速获得用户的反馈。
• 持续部署： 在以上环节准备好后可当即自动部署某个版本的代码，进一步扩展了持续交付。

即便最终生产环境的部署须要由另外一我的或团队完成，你也能够实现持续交付，至少可让研发组织在最快的时间内达到生产环境就绪状态。

删除外部依赖项

消除对外部团队的依赖，并尝试在团队中保留全部审批权力。拥有外部依赖关系，例如须要特定利益相关方的批准，或者让另外一个单独的团队执行部署会下降流程的速度。这并非说应该跳过或忽略这些操做，但应该可以由本团队成员完成。再次回到 DevOps 原则， 团队应该包括全栈或 T 型开发人员，他们能够出如今须要执行团队各类任务的地方。

消除这些外部关系的主要缘由是，与团队以外的人员相比，与团队中的人员沟统统常更容易。另外，团队中的人员知道发生了什么以及须要作什么，无需上下文的解释。这两个好处都将会提升团队的速度。

若是您没法删除依赖关系，请查看是否能够考虑将相关人员添加到你的团队中。 例如，若是你须要公司业务利益相关方在部署以前批准你的发布，看看你是否可让你的产品负责人（即 PO）来表明业务方执行此功能。这样的话 SoD 依然存在（由于 PO 一般不直接参与特性的开发）而且团队再也不依赖于团队以外的人。

实施安全网比控制重要

维持高水平的风险规避：最大限度地减小交接并实现快速交付的最佳方法之一是实施安全网，而不是控制。这是什么意思呢？

在马戏团中，当空中飞人艺术家表演他们的杂技表演时，他们一般会经过安全网来进行防御。另外一种方法是将他们连到安全带上，但这显然会限制他们的运动。另外一方面，安全网容许他们尽量流畅高效地运动，并确保若是出现问题而且碰巧掉落，他们可以安全地落入网中并避免受到严重伤害。

别误会个人意思，在时间和地点上确定须要控制。例如，在航班起飞前进行例行检查，而且在每次起飞以前都要强制检查，由于在这种状况下咱们不能承受任何重大事故，失败的结果将是毁灭性的。不只是由于物质成本高（飞机并不便宜），更重要的是，生命是无价的。

对于构建软件的人来讲，在大多数状况下，若是软件失败，人们并不会所以失去生命。所以，在这些状况下失败是容许的， 只要你能够“安全地”失败，快速恢复并从失败中吸收教训，以便不会再重复这样的失败。

在软件开发方面， 安全网包括对生产环境的质量系统监控。 这容许团队了解系统的当前状态以及在用户作出响应以前处理突发事故或者避免事故产生。在发生重大事故时，可以经过快速回滚来恢复服务，例如 蓝/绿部署是另外一种能够应用的安全网。

蓝/绿部署

这种技术是一种众所周知（但利用不足）的云模式，用于最大限度地减小发布的停机时间，并在出现问题时提供快速回滚方式（即安全网）。

Martin Fowler（敏捷宣言的最初共同创造者之一）解释以下：

自动化部署的挑战之一是切换自己：将软件从测试的最后阶段带到生产环境当中。你一般须要快速执行此操做以最大限度地减小停机时间。蓝/绿部署经过确保你拥有两个尽量相同的生产环境来实现此目的。在任什么时候候，其中一个，例如蓝色指的是生产环境。在准备软件的新版本时，您将在绿色环境中进行最后的测试阶段。一旦软件在绿色环境中工做，您就切换路由，以便全部传入的请求都进入绿色环境，同时蓝色环境处于空闲状态。

蓝/绿部署还为你提供了快速回滚方式，若是出现任何问题，您能够将路由切换回蓝色环境。

—— Martin Fowler - martinfowler.com/bliki/BlueG…

这里的要点是， 不要等到软件被认为是完美的才容许发布。 在具备 kill-switch 机制下咱们容许全部版本投入生产，由于在须要时咱们能够快速恢复服务。因此咱们强调快速恢复，而不是试图去避免（不可避免的）失败。

译者注：常见的带有故障恢复效果的部署策略还有灰度发布／金丝雀发布，经过将更改先推广到一小部分用户，而后将其推广到整个基础架构并使其可供全部人使用。以保障总体系统稳定的状况下，尽早发现、调整问题。参考：martinfowler.com/bliki/Canar…

总结一下

在软件交付控制方面，职责分离应该是最后的手段。除非失败可能致使生命损失，或者监管机构强制要求，不然若是你但愿得到 DevOps 原则和实践的最大好处，则应避免职责分离。话虽如此，若是你被迫在团队中使用 SoD，那么实现如下技术将容许你成功实现 DevOps ，即便不是完美地实现 DevOps。

• 最大限度地减小交接次数：经过最小化步骤数和所需人员来优化你的工做流。
• 自动化：自动化一切，但必须得在你确认好自动化的内容以后。请记住，持续集成、持续交付和持续部署，这些都是你良师益友。
• 删除外部依赖项：与团队中的人合做更容易，所以请删除或尽可能减小外部依赖项。
• 安全网控制：故障恢复，而不是试图彻底避免故障。

译后记

做者在文中很是强调自动化的实践，而且强调了，若是须要进行严格的权责分离（这是许多中国团队面临的实际问题），更加须要依赖于自动化，以减小效率的损耗。这与 CODING 的理念不谋而合。咱们也认为自动化能帮助研发组织解放研发效能。

CODING 的持续集成和制品库帮助你轻松搞定自动化流水线，实现软件的快速交付。CODING 持续集成（CCI）全面兼容 Jenkins 的持续集成服务，支持 Java、Python、Node.js 等全部主流语言编译环境，而且支持 Docker 镜像的构建。只要几步配置，就能够开启 Git 代码仓库的持续集成。构建产物还可经过 CODING 制品库进行统一管理。目前 CODING 支持 Docker Image、Maven/Jar、Kubernetes Helm、Node.js NPM 包等常见软件包类型。

CODING 帮助您控制每一次从引入代码变动到发布的整个过程，从而更好地优化软件交付的速度和质量。