安全部署实践

有时一个版本没有达到预期。 尽管使用了最佳实践并通过了所有质量检查，但偶尔会出现一些问题，导致生产部署给用户带来无法预见的问题。 为了最大限度地减少和减轻这些问题的影响，我们鼓励 DevOps 团队采用渐进的曝光策略，在给定版本的曝光与其经验证的性能之间取得平衡。 随着一个版本在制作中得到证明，它将向更广泛的受众提供，直到每个人都使用它。 团队可以使用安全的部署实践，以最大限度地提高生产中发布的质量和速度。

控制对客户的曝光

DevOps 团队可以采用各种实践来控制更新对客户的曝光。 从历史上看，A/B 测试一直是团队的热门选择，他们希望了解不同版本的服务或用户界面如何实现目标。 A/B 测试也相对容易使用，因为更改通常很小，并且通常只比较面向客户的服务边缘的不同版本。

通过环的安全部署

随着平台的增长，基础结构的规模和受众需求也趋于增长。 这就产生了对部署模型的需求，该模型平衡了与新部署相关的风险及其承诺的更新带来的好处。 一般的想法是，一个给定的版本应该首先只曝光给一小群对风险容忍度最高的用户。 然后，如果发布如预期的那样工作，它可以曝光给更广泛的用户群体。 如果没有问题，那么这个过程可以通过更广泛的用户组或环继续进行，直到每个人都在使用新版本。 借助 GitHub Actions 和 Azure Pipelines 等现代连续交付平台，任何规模的 DevOps 团队都可以使用环构建部署流程。

特性标志

某些功能有时需要作为发布的一部分进行部署，但最初不会向用户公开。 在这些情况下，功能标志提供的解决方案可以通过基于环境、环或任何其他特定部署的配置更改来启用功能。

用户选择加入

与功能标志类似，用户选择加入提供了一种限制曝光的方法。 在这个模型中，给定的功能在发布中被启用，但除非用户表明需要，否则不会为其激活。 风险承受能力的决策被分配给用户，这样他们就可以决定采用某些更新的速度。

通常同时采用多种做法。 例如，一个团队可能有一个针对特定用例的实验功能。 由于这是有风险的，他们会将其部署到第一个环中，供内部用户试用。然而，即使这些特性在代码中，也需要有人为环中的特定部署设置功能标志，以便通过用户界面公开该特性。 即便如此，功能标志也可能只显示用户选择使用新功能的选项。 任何不在环中、不在部署中或没有选择加入的人都不会接触到该功能。 虽然这是一个相当做作的例子，但它有助于说明渐进曝光的灵活性和实用性。

团队早期面临的常见问题

随着团队转向更敏捷的 DevOps 实践，他们可能会遇到与其他从传统的整体交付中迁移出来的人一致的问题。 习惯于每隔几个月部署一次的团队有一种缓冲稳定的思维模式。 他们预计，每次部署都会带来服务的实质性转变，并且会出现无法预见的问题。

有效负载太大

每隔几个月部署一次的服务通常会包含许多更改。 这增加了出现即时问题的可能性，也使解决这些问题变得困难，因为有太多新东西。 通过转向更频繁的交付，部署内容的差异变得更小，这允许更集中的测试和更容易的调试。

无服务隔离

传统上，单片系统是通过升级其部署的硬件来进行扩展的。 然而，当实例出现问题时，会给每个人带来问题。 一个简单的解决方案是添加多个实例，以便可以对用户进行负载平衡。 然而，这可能需要大量的体系结构考虑，因为许多遗留系统并不是为多实例而构建的。 此外，可能需要为可能在其他地方更好地整合的功能分配大量重复资源。

随着新功能的添加，探索微服务架构是否可以通过更好的服务隔离来帮助您运营和扩展。

手动步骤会导致错误

当一个团队每年只部署几次时，自动化交付似乎不值得投资。 因此，许多部署过程都是手动管理的。 这需要大量的时间和精力，而且容易出现人为错误。 简单地自动化最常见的生成和部署任务可以大大减少时间损失和非受迫性错误。

团队还可以将基础结构用作代码，以便更好地控制部署环境。 这消除了在各种部署环境中引入新功能或依赖项时向操作团队请求手动更改的需要。

只有 Ops 才能进行部署

有些组织的策略要求所有部署都由业务人员启动和管理。 虽然在过去可能有很好的理由，但当开发团队能够启动和控制部署时，敏捷 DevOps 流程将受益匪浅。 现代连续交付平台提供了对谁可以启动哪些部署以及谁可以访问状态日志和其他诊断信息的精细控制，确保合适的人尽快获得合适的信息。

进行错误的部署，无法回滚

有时部署出错，团队需要解决。 但是，当流程是手动的，并且对信息的访问缓慢且有限时，可能很难回滚到以前的工作部署。 幸运的是，有各种工具和实践可以降低部署失败的风险。

核心原则

希望采用安全部署实践的团队应该制定一些核心原则来支持这项工作。

保持一致

在开发和测试环境中应该使用与在生产中部署相同的工具。 如果存在问题，比如经常由依赖项或工具的新版本引起的问题，那么应该在代码即将发布到生产环境之前就发现这些问题。

关心质量信号

太多的团队陷入了一个普遍的陷阱，即不真正关心质量信号。 随着时间的推移，他们可能会发现，他们编写测试或承担质量任务只是为了将黄色警告改为绿色批准。 质量信号非常重要，因为它们代表了项目的脉搏。 应每天持续跟踪用于审批部署的质量信号。

部署应要求零停机时间

虽然每项服务始终可用并不重要，但团队在进入 DevOps 交付和运营阶段时应该抱着这样的思维模式，即他们可以而且应该部署新版本，而不必在任何时候将其删除。 现代基础结构和管道工具现在已经足够先进了，几乎任何团队都可以实现 100% 的正常运行时间。

部署应在工作时间进行

如果一个团队的工作思维模式是部署需要零停机时间，那么何时推动部署其实并不重要。 此外，在工作时间推动部署变得有利，尤其是在一天的早些时候和一周的早些时候。 如果出现问题，应尽早追踪，以控制影响范围。 此外，每个人都已经在工作，并专注于解决问题。

基于环的部署

具有成熟 DevOps 发布实践的团队能够进行基于环的部署。 在这种模式中，新功能首先向愿意承担最大风险的客户推出。 随着部署得到证明，受众会扩大到包括更多的用户，直到每个人都使用它。

一个示例环模型

一个典型的环形部署模型旨在通过仔细划分用户和基础结构，尽早发现问题。 下面的例子展示了Microsoft 的一个主要团队是如何使用环的。

环形	目的	用户	数据中心
0	查找部署引入的大多数影响用户的 Bug	仅限内部，对风险和漏洞具有高度容忍度	美国中西部
1	团队未进行广泛测试的领域	使用广泛产品的客户	小型数据中心
2	规模相关问题	公共帐户，最好是使用多种功能的免费帐户	中型或大型数据中心
3	内部帐户的规模问题和国际相关问题	大型内部帐户和欧洲客户	内部数据中心和欧洲数据中心
4	剩余缩放单元	其他所有人	所有部署目标

允许烘焙时间

术语烘焙时间是指在扩展到下一个环之前，允许部署运行的时间量。 有些问题可能需要数小时或更长时间才能开始出现症状，因此在考虑准备好之前，该产品应使用适当的时间。

一般来说，对于大多数场景来说，一天 24 小时应该足够曝光潜在漏洞。 但是，对于在营业时间达到高峰的服务，这段时间应该包括高峰使用期，需要一个完整的工作日。

加快修补程序

当错误对生产造成严重影响时，就会发生现场事件 (LSI)。 LSI 需要创建修补程序，这是一种带外更新，旨在解决高优先级问题。

如果一个 bug 是 Sev 0，这是最严重的 bug 类型，则可以尽快将修补程序直接部署到受影响的缩放单元。 虽然修复不要让事情变得更糟很关键，但这种严重性的错误被认为是破坏性的，必须立即解决。

分级为 Sev 1 的 Bug 必须通过环 0 部署，但一旦获得批准，就可以部署到受影响的缩放单元。

严重性较低的 bug 的修补程序必须按计划部署到所有环中。

关键结论

每个团队都希望以尽可能高的质量快速提供更新。 有了正确的实践，交付可以成为 DevOps 周期中富有成效且轻松的一部分。

• 经常部署。
• 在整个冲刺过程中保持绿色。
• 在开发、测试和生产中使用一致的部署工具。
• 使用允许自动化和授权的连续交付平台。
• 遵循安全部署做法。

后续步骤

了解功能标志如何帮助控制向用户展示新功能。