你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

卓越运营设计原则

项目
11/15/2023

卓越运营支柱的核心是通过 标准化工作流和团队凝聚力来确保工作负载质量的 DevOps 做法。此支柱定义了 开发实践、可观测性和发布管理的操作过程。目标是将流程差异、人为错误的可能性和对客户的干扰降至最低。若要评估运行运行状况，请从以下问题开始：

是否执行有规则的操作？
客户是否使用具有最大可预测性的工作负载？
如何从经验和收集的数据中吸取教训，以推动持续改进？

如果没有明确的所有权或领导权，工作负载操作可能会陷入混乱的做法。在这种类型的环境中，团队经常使用高工作量执行且产生低结果的方法，这会导致用户体验不佳。这些方法仅满足短期目标。长期效益是通过 持续评估和战略投资实现的。

设计原则为操作策略提供了指南，必须考虑这些策略 来解决根本原因，而不仅仅是治疗症状。从建议的方法开始，然后观察哪些方法有效，哪些不能确定改进领域。设置策略后，继续使用 卓越运营清单来推动操作。

工作负荷的操作要求与其业务要求一样重要。高效的流程可确保工作负载在合规性约束内实现业务成果，无论合规性是组织性的还是外部的。关键是找到一致性的可重复性。

卓越运营支柱的目标是 做正确的事，以正确的方式做，并解决正确的问题作为一个团队。

如果满足这些目标，工作负载将可靠且可预测地运行，即使在发生更改时也是如此。 无法满足操作要求可能会导致部署失败、用户体验不一致，以及通过适当规划和简化执行可以避免的成本增加。

拥抱 DevOps 文化

通过协作、共担责任和所有权的思维模式，使开发和运营团队能够不断改进其系统设计和流程。

DevOps 是一个实践社区，其中观点和技能的多样性推动着一个任务。团队必须 营造共享知识的协作环境 ，而不是孤立的学习环境。使用共享函数努力克服资源约束。

良好的 DevOps 文化在共同责任的基础上蓬勃发展。开发和运营团队应将其目标和优先事项与客户的期望保持一致，并牢记业务重点。开发团队应让运营团队参与反馈循环，以便改进上游推动，其他团队同样受益。相反，运营团队负责通过共享与工作负载相关的资源和反馈，使开发团队在业务成果中取得成功。

同时，DevOps 实践 将明确的所有权和责任线应用于每个团队。无论应用程序在何处运行，工作负载团队都负责该应用程序。

DevOps 优化操作任务，使其有效但不繁重。为了充分利用 DevOps 的优势，文化应通过技术优化流程，并让组织中的人员通过流程促进透明通信。

方法	优点
使用促进协作环境的常见系统和工具进行通信和跟踪进度。	通用工具和流程可实现透明通信。开发和运营团队都受益于各种环境的情况感知、常见的支持问题以及总体挑战和胜利。如果发生事件，Teams 已经熟悉现有的升级路径。共享积压工作使优先事项（如处理新功能或修复 bug）变得清晰。
在整个开发周期中构建持续学习和试验思维模式。支持跨团队的知识共享，并维护文档以供重复使用。进行无责备的分析和报告发布后和/或事件后审查。	通过试验机制（如 A/B 测试和开发概念证明），可以鼓励创新，同时降低成本。通过协作共享知识，使团队精通设计方法、工具和流程。在项目后进行回顾有助于确定需要改进的领域并庆祝成功。
采用久经考验的行业敏捷做法，专注于操作优化。寻找在操作中 “左移”的机会，以获取手动和自动化流程、部署和质量保证做法以及可观测性。	敏捷开发实践可缩短发布生命周期，这是业务价值的指标。检测、解决并提前防止问题通常对过程不那么侵入。
为所有开发和操作过程设置标准，并定期审查和验证它们。这些过程包括常规任务、带外流程、紧急演练和情况、工具选择、监视过程、技能计划，甚至与利益干系人和客户披露的沟通。有意而明确地做出决定。	标准增加了操作的可预测性，并使流程和做法可缩放。验证标准是得出改进点的好方法。通过定期进行演习，为紧急情况和恢复情况做好准备。精确执行并启用治理，以防止导致风险的异常。
利用具有专业技能和广泛经验的集中式运营团队。	将共享资源用于操作和资源都有成本优势。虽然你拥有工作负载，但集中式团队可帮助你掌握跨职能技能，例如事件管理、主动监视视角以及信任外包专业知识。

建立开发标准

通过标准化开发实践、强制实施质量入口以及通过系统变更管理跟踪进度和成功，优化生产力。

开发团队负责在发布前以最少的摩擦解决工作负载问题。请注意开发人员的效率，并针对从编码到测试结果的 快速周转周期进行优化。实施有效且规模合适的流程，规划和标准化技术活动，并在团队和利益干系人中推动共识。

方法	优点
记录工作负载功能并捕获客户权益。派生体系结构的范围和详细的功能和非功能性要求。创建大小估计模型，以报告所涉及的任务的范围和成本。	良好的规范通过支持更高效和简化的开发周期来降低运营成本和失败的可能性。开发人员在开始编码周期之前了解技术设计、目标和完成条件。良好的文档有助于新团队成员的可重复沟通和加入。
使用行业标准软件开发方法，该方法根据工作负载和团队规模的需求进行了适当优化。维护所有角色之间共享的积压工作。	采用已知方法可设置项目的节奏。它通过为团队成员提供明确的期望和责任来消除流程中的歧义。通过根据通用列表进行跟踪，可以使用标准做法优化任务并设置优先级。该项目将有更好的机会按时交付。标准方法有助于风险管理。通过精细的里程碑评审，开发人员可以在潜在问题成为演示者之前解决。
对所有代码、脚本、部署模板、管道定义和相关文档使用统一源代码管理。分支策略必须支持无摩擦地发布独立且相互依赖的功能、bug 修复和修补程序。使用整个组织的共享知识来构建分支策略和部署流程。	正确使用源代码管理对于支持并发更改和版本控制至关重要。维护可重复的工作流，以发布各种大小和风险的更改，在流程中执行同行评审，并保留审核线索。
具有在开发生命周期早期强调测试的质量保证流程。包括计划内测试过程的所有项目，包括作为功能发布或更新一部分的应用程序组件、基础结构和数据平面操作。在通过环境提升项目时，将其视为不可变项目，每当它们通过质量关口时，它们都会获得信心。在可行的情况下，自动执行例程检查。	质量保证可确保功能要求和非功能性要求得到自信的满足，从而对客户产生积极的影响。制定测试计划可确保质量和完整性，并考虑可能的失败情况。借助质量入口，可以强制实施最佳做法来降低风险。不可变性可带来信心，因为它可确保测试的系统与所发布的系统完全一致。除非满足质量标准，否则测试周期会有效地阻止进度。
使用强制实施约定的样式指南和工具，并采用通用工具链进行开发、测试和与利益干系人沟通，从而促进一致性。开发人员的技术标准需要实现模式、API 设计、日志记录、异常处理和其他过程。	代码中的一致性可提高可读性并简化维护。它还降低了复杂性并实现了代码重用。常见工具和约定还可以帮助团队优化流程，而无需处理一次性选择。
一致且有意地坚持编写代码的开发人员文档。	清晰的代码文档可确保在需要重新访问旧代码或轮换开发团队时轻松理解逻辑和功能。
报告进度和趋势以衡量效率。	发布 bug、失败更新、部署时间、反馈循环和其他指标的趋势，并推动改进。

通过可观测性改进操作

深入了解系统、获取见解并做出数据驱动的决策。

通过监视工作负载并考虑 Azure Well-Architected 框架的所有支柱，构建一种 持续提高质量 的文化。通过提供必要的数据、统计信息和趋势，使团队和利益干系人能够跨多个方面做出短期和长期决策。从数据中学习并推动改进。

为可观测性而构建的操作是主动维护应用程序、质量和安全保障、容量规划和产品管理的关键。

监视的一个重要方面是 应用程序使用运行状况建模来帮助在问题成为事件并影响客户体验之前预测问题 。高效监视可减少在事件管理上花费的反应周期。

方法	优点
使用自己的堆栈和流构建监视系统。将监视系统视为与其实用工具分离的工作负荷的维度。堆栈必须涵盖所有层，包括基础结构、应用程序运行状况以及生成和发布过程。捕获或采样业务数据不适用于可观测性实现。	将监视和工作负载堆栈分离，以分离功能要求和可观测性要求，使独立演变成为可能。代码更改不应影响监视，反之亦然。由于可观测性要求与功能要求是分开的，因此不会因监视配置更改或中断而中断业务数据。
推动每种类型的数据源的收集过程中的一致性。使用遥测、基础结构指标集合和工具的行业标准来标准化代码中的检测。	一致性可防止在感知和度量方面出现差异，因为对类似资源的熟悉可减少关联和分析数据所花费的时间。你有一个整体视角来预测问题。
从应用程序代码发出遥测数据，这些遥测数据关联执行流的关键点，并提供不同粒度级别的端到端视图。	根据严重性级别确定操作的优先级，并了解上下文的详细程度。此信息对于故障排除目的至关重要。
拥有发出和收集数据的责任，即使数据接收器由多个团队共享并由中心团队管理也是如此。	通过将监视数据本地化到工作负载环境，团队可以访问日志和指标来解决工作负载问题。
收集足够多的数据并保留足够时间。考虑与日志记录和存储数据相关的成本权衡。	有意的数据收集有助于优化与收集更多数据相关的财务和运营成本。在分析期间尽量减少干扰并避免密集计算，并降低不再需要的存储数据的成本。
区分不同的监视信号：配置文件、日志、指标和跟踪。将每个信号用于正确的目的。优先使用指标来触发依赖于数值度量的操作。使用配置文件将较低级别的可见性（例如内存分配）引入系统。保留日志和跟踪的使用，为流和依赖项提供上下文。	通过将信号用于正确的目的，可以防止监视系统的低效实现。例如，对操作使用日志需要分析。也许可以通过指标更快地实现相同的目标。
在仪表板中聚合和可视化数据，以呈现迎合受众并牢记业务上下文的监视数据。使用情景仪表板来显示数据，以提升利益干系人之间的认知度。将具有向下钻取功能的操作仪表板和工作簿用于事件响应等操作员活动。经常刷新仪表板并提供精细数据。	借助可视化效果，可以分析趋势、跟踪业务目标以及管理事件。根据客户兴趣定制的仪表板使解释相关，并加快检测和操作的时间。
通过使用标准化说明和严重性级别通知负责角色，使警报可操作。提供从各种源整理的信息，并跟踪与业务目标的偏差。仅针对需要操作的事件触发警报。争取在降级状态变为故障之前启动操作的主动且发人深省的警报。	警报可引起对组织定义的重大事件的关注。良好的警报系统可识别操作和严重性，并提供足够的数据来提升清晰度和目的性。操作员可以立即启动修正。

自信地进行部署

以可预测性达到所需的部署状态。

构建工作负载供应链，使你能够跨工作负载的托管平台、应用程序、数据和配置资源在所有环境中始终如一地实现可预测性的目标。 部署机制必须能够进行自动化、测试、监视和版本控制。它应该是模块化的，可以按需执行。不应将其表示为整体式端到端进程。供应链不一定是为了加快执行速度，而是为了在多次迭代中实现一致性和自我文档。

工作负荷团队负责供应链，因为它与自己的工作负载相关。

方法	优点
使用基础结构即代码 (IaC) 定义已准备好生产的供应链的可重复方面。优先使用声明性方法，而不是命令性方法。	声明性 IaC 技术在设计时考虑到了自动化和可重用性。可以将基础结构部署从个人卸载到工具中，并实现一致的质量。从基础结构的角度来看，选择较少的技术可以消除工具的差异，并使配置偏差易于检测。维护也更容易。如果你的选择与团队的现有技能集保持一致，团队可以轻松采用它们。
准备团队以使用所选的 IaC 技术。了解其扩展性模型、功能和限制。利用团队内部的专业化和组织内共享的知识。	提高技能通过共享学习提高工作效率并营造协作环境。你可以通过培训而不是招聘来填补空白。
遵循 IaC 开发和维护的软件建议。在审查中模块化。避免自定义或低值抽象。遵循分层方法反映不同的生命周期。形成基础层，其中较低层保持不变，上层根据需要更改。部署项目（如应用程序二进制文件、IaC 模板和参数）是攻击面的一部分。应用保证，例如机密管理、访问控制和安全支柱的其他原则。	项目具有与应用程序代码相同的工程严谨级别。通过同行评审和测试进行质量控制，让你对部署充满信心。分层方法使维护更容易，并创建建立明确责任线的边界。向项目添加安全控制有助于在部署过程中强化系统。
开发跨所有环境使用的通用部署清单。使用该清单作为绿地项目、增量工作负载更新或灾难恢复的默认机制。	消除维护多个资产的开销。如果发生灾难，恢复将快速且可靠，因为可以部署经过尝试且经过测试的清单，而不是创建即兴环境。
努力实现通过 IaC 自动化部署的不可变临时基础结构。	禁止配置偏移并使部署幂等。这种基础结构可消除严重的操作负担，例如修补。它还有利于核心验证方案，例如蓝绿基础结构部署。

注意

将门户的使用范围缩小为仅非重复的调查任务。

自动提高效率

将重复的手动任务替换为软件自动化，以便更快地完成这些任务，提高一致性和准确性，并降低风险。

工作负载的工作流可能涉及团队成员执行平凡、重复且耗时的任务，而实际上不需要人类智力。根据频率，你可能会花费大量时间进行这些工作，并随着工作负载的增长而投入更多时间。此外，由于人工输入，这些过程通常容易出错。

通过自动化，可以节省时间、精力和金钱，并避免错误。

方法	优点
根据复杂性、工作量、频率、准确性、及时性和寿命的适当级别评估所有工作流。基于该评估自动执行工作流，并优先处理预期回报最高的工作流。删除多余的工作流或增加价值，以证明人工工作量的合理性。	你可以将团队能力重新投入到更高价值的工作中，并提高工作效率和一致性。生成工作流清单可确保自动执行正确的任务。删除冗余任务可降低复杂性和错误。
在评估是生成自定义工具还是购买软件时，明确你的决定。保留建筑自动化，用于高度专业化和高价值的工作。	通过购买现成的软件并利用支持合同，可以节省维护成本。通过构建软件，你可以获得更多控制权，并可以迎合团队和工作负载特有的用例。但是，存在成本影响。工具的选择为操作带来了一定程度的标准化。通过培训，可以实现统一的采用准备程度。
设计工作负载组件以支持自动化功能。	避免在系统设计中缺乏自动化会助长重复任务的反模式、减缓增长并开始积累技术债务的情况。
将所有自动化视为工作负荷的关键依赖项。适应工作负载的预期增长。自动化工具是工作负荷不可或缺的一部分，它应遵循五个 Well-Architected 框架支柱。	设计自动化组件以抵御安全威胁等风险。通过应用的最佳做法，可以避免实现的蔓延。如果此依赖项保持正常运行且安全，工作负载将继续以高级别保证运行。
通过探索工作负载以外的选项大规模自动化。通过提供模板和框架来载入新项目，促进现有设计和实现的重用，支持“一次设计，随处运行”模型。	采用经过尝试和测试的方法，减少失败的可能性。

采用安全部署做法

在部署过程中实施防护措施，以最大程度地减少错误或意外情况的影响。

在开发周期中，工作负载项目在实现和测试以及修复 bug 时会经历许多更改。

部署过程必须遵循标准操作过程。 必须以相同的严格级别部署任何更改。此原则同样适用于代码、配置和所有相关项目。关键是尽早应用安全做法，以便在生产环境中具有可预测性。即使错误到达客户，也应该能够尽快推出恢复更改。

方法	优点
使用自动化部署过程（如管道）标准化部署任何更改的过程。所有环境都必须使用管道。按环境对资产和版本进行分类，使其易于跟踪和识别。	一致的部署方法可减少由过程错误和差异引起的问题，并使你能够将精力集中在工作负载关注点上。标准化可确保安全、可靠且可重复性地完成部署。通过分类，可以轻松查看以前部署的日志和已发生的问题。你可能能够使用该信息来加速回滚和前滚操作。
定期部署小型增量更新。	频繁、经过良好测试的小型更新使版本验证更加容易。由于占用空间较小，故障排除速度更快，对客户的影响最小。
在整个开发生命周期内，使用不同的机制严格测试更新。	在开发的早期阶段捕获问题。迭代修复和一致的部署做法会导致问题在更新准备好投入生产时逐渐减少。
逐步推出更新，并尽职尽责。使用提供控制权的部署模型逐步增加实例和客户的数量，直到所有人都安全采用更新。	以受控方式测试每个更新，以便在生产早期修复问题。避免推出影响整个客户群的错误更新。测试更新是否向后兼容和向前兼容。
制定缓解策略，从部署失败中快速恢复。该策略应包括根据问题的关键性对回滚或向前回滚的决策。具有定义完善的流程和自动化系统，可以使用标准部署管道快速推出修补程序。	缩短潜在影响的持续时间。将系统还原回以前的工作版本，或前滚到具有经过全面测试的修补程序的版本。
制定回退计划，以便在紧急情况下将系统重置为工作状态，并从意外故障中恢复。仅在必要时并在批准的情况下使用此策略。努力随着时间的推移改进计划。	可以快速跟踪高优先级修补程序，例如安全修正。加速管道可能没有对标准操作过程进行所有检查，但你会以最快的方式让客户获得安全版本，这超过了影响较小的故障。

后续步骤

建议查看卓越运营清单以探索其他概念。

卓越运营清单

方法	优点
使用促进协作环境的常见系统和工具进行通信和跟踪进度。	通用工具和流程可实现透明通信。开发和运营团队都受益于各种环境的情况感知、常见的支持问题以及总体挑战和胜利。如果发生事件，Teams 已经熟悉现有的升级路径。共享积压工作使优先事项（如处理新功能或修复 bug）变得清晰。
在整个开发周期中构建持续学习和试验思维模式。支持跨团队的知识共享，并维护文档以供重复使用。进行无责备的分析和报告发布后和/或事件后审查。	通过试验机制（如 A/B 测试和开发概念证明），可以鼓励创新，同时降低成本。通过协作共享知识，使团队精通设计方法、工具和流程。在项目后进行回顾有助于确定需要改进的领域并庆祝成功。
采用久经考验的行业敏捷做法，专注于操作优化。寻找在操作中 “左移”的机会，以获取手动和自动化流程、部署和质量保证做法以及可观测性。	敏捷开发实践可缩短发布生命周期，这是业务价值的指标。检测、解决并提前防止问题通常对过程不那么侵入。
为所有开发和操作过程设置标准，并定期审查和验证它们。这些过程包括常规任务、带外流程、紧急演练和情况、工具选择、监视过程、技能计划，甚至与利益干系人和客户披露的沟通。有意而明确地做出决定。	标准增加了操作的可预测性，并使流程和做法可缩放。验证标准是得出改进点的好方法。通过定期进行演习，为紧急情况和恢复情况做好准备。精确执行并启用治理，以防止导致风险的异常。
利用具有专业技能和广泛经验的集中式运营团队。	将共享资源用于操作和资源都有成本优势。虽然你拥有工作负载，但集中式团队可帮助你掌握跨职能技能，例如事件管理、主动监视视角以及信任外包专业知识。

方法	优点
使用自己的堆栈和流构建监视系统。将监视系统视为与其实用工具分离的工作负荷的维度。堆栈必须涵盖所有层，包括基础结构、应用程序运行状况以及生成和发布过程。捕获或采样业务数据不适用于可观测性实现。	将监视和工作负载堆栈分离，以分离功能要求和可观测性要求，使独立演变成为可能。代码更改不应影响监视，反之亦然。由于可观测性要求与功能要求是分开的，因此不会因监视配置更改或中断而中断业务数据。
推动每种类型的数据源的收集过程中的一致性。使用遥测、基础结构指标集合和工具的行业标准来标准化代码中的检测。	一致性可防止在感知和度量方面出现差异，因为对类似资源的熟悉可减少关联和分析数据所花费的时间。你有一个整体视角来预测问题。
从应用程序代码发出遥测数据，这些遥测数据关联执行流的关键点，并提供不同粒度级别的端到端视图。	根据严重性级别确定操作的优先级，并了解上下文的详细程度。此信息对于故障排除目的至关重要。
拥有发出和收集数据的责任，即使数据接收器由多个团队共享并由中心团队管理也是如此。	通过将监视数据本地化到工作负载环境，团队可以访问日志和指标来解决工作负载问题。
收集足够多的数据并保留足够时间。考虑与日志记录和存储数据相关的成本权衡。	有意的数据收集有助于优化与收集更多数据相关的财务和运营成本。在分析期间尽量减少干扰并避免密集计算，并降低不再需要的存储数据的成本。
区分不同的监视信号：配置文件、日志、指标和跟踪。将每个信号用于正确的目的。优先使用指标来触发依赖于数值度量的操作。使用配置文件将较低级别的可见性（例如内存分配）引入系统。保留日志和跟踪的使用，为流和依赖项提供上下文。	通过将信号用于正确的目的，可以防止监视系统的低效实现。例如，对操作使用日志需要分析。也许可以通过指标更快地实现相同的目标。
在仪表板中聚合和可视化数据，以呈现迎合受众并牢记业务上下文的监视数据。使用情景仪表板来显示数据，以提升利益干系人之间的认知度。将具有向下钻取功能的操作仪表板和工作簿用于事件响应等操作员活动。经常刷新仪表板并提供精细数据。	借助可视化效果，可以分析趋势、跟踪业务目标以及管理事件。根据客户兴趣定制的仪表板使解释相关，并加快检测和操作的时间。
通过使用标准化说明和严重性级别通知负责角色，使警报可操作。提供从各种源整理的信息，并跟踪与业务目标的偏差。仅针对需要操作的事件触发警报。争取在降级状态变为故障之前启动操作的主动且发人深省的警报。	警报可引起对组织定义的重大事件的关注。良好的警报系统可识别操作和严重性，并提供足够的数据来提升清晰度和目的性。操作员可以立即启动修正。

方法	优点
使用基础结构即代码 (IaC) 定义已准备好生产的供应链的可重复方面。优先使用声明性方法，而不是命令性方法。	声明性 IaC 技术在设计时考虑到了自动化和可重用性。可以将基础结构部署从个人卸载到工具中，并实现一致的质量。从基础结构的角度来看，选择较少的技术可以消除工具的差异，并使配置偏差易于检测。维护也更容易。如果你的选择与团队的现有技能集保持一致，团队可以轻松采用它们。
准备团队以使用所选的 IaC 技术。了解其扩展性模型、功能和限制。利用团队内部的专业化和组织内共享的知识。	提高技能通过共享学习提高工作效率并营造协作环境。你可以通过培训而不是招聘来填补空白。
遵循 IaC 开发和维护的软件建议。在审查中模块化。避免自定义或低值抽象。遵循分层方法反映不同的生命周期。形成基础层，其中较低层保持不变，上层根据需要更改。部署项目（如应用程序二进制文件、IaC 模板和参数）是攻击面的一部分。应用保证，例如机密管理、访问控制和安全支柱的其他原则。	项目具有与应用程序代码相同的工程严谨级别。通过同行评审和测试进行质量控制，让你对部署充满信心。分层方法使维护更容易，并创建建立明确责任线的边界。向项目添加安全控制有助于在部署过程中强化系统。
开发跨所有环境使用的通用部署清单。使用该清单作为绿地项目、增量工作负载更新或灾难恢复的默认机制。	消除维护多个资产的开销。如果发生灾难，恢复将快速且可靠，因为可以部署经过尝试且经过测试的清单，而不是创建即兴环境。
努力实现通过 IaC 自动化部署的不可变临时基础结构。	禁止配置偏移并使部署幂等。这种基础结构可消除严重的操作负担，例如修补。它还有利于核心验证方案，例如蓝绿基础结构部署。

方法	优点
根据复杂性、工作量、频率、准确性、及时性和寿命的适当级别评估所有工作流。基于该评估自动执行工作流，并优先处理预期回报最高的工作流。删除多余的工作流或增加价值，以证明人工工作量的合理性。	你可以将团队能力重新投入到更高价值的工作中，并提高工作效率和一致性。生成工作流清单可确保自动执行正确的任务。删除冗余任务可降低复杂性和错误。
在评估是生成自定义工具还是购买软件时，明确你的决定。保留建筑自动化，用于高度专业化和高价值的工作。	通过购买现成的软件并利用支持合同，可以节省维护成本。通过构建软件，你可以获得更多控制权，并可以迎合团队和工作负载特有的用例。但是，存在成本影响。工具的选择为操作带来了一定程度的标准化。通过培训，可以实现统一的采用准备程度。
设计工作负载组件以支持自动化功能。	避免在系统设计中缺乏自动化会助长重复任务的反模式、减缓增长并开始积累技术债务的情况。
将所有自动化视为工作负荷的关键依赖项。适应工作负载的预期增长。自动化工具是工作负荷不可或缺的一部分，它应遵循五个 Well-Architected 框架支柱。	设计自动化组件以抵御安全威胁等风险。通过应用的最佳做法，可以避免实现的蔓延。如果此依赖项保持正常运行且安全，工作负载将继续以高级别保证运行。
通过探索工作负载以外的选项大规模自动化。通过提供模板和框架来载入新项目，促进现有设计和实现的重用，支持“一次设计，随处运行”模型。	采用经过尝试和测试的方法，减少失败的可能性。

方法	优点
使用自动化部署过程（如管道）标准化部署任何更改的过程。所有环境都必须使用管道。按环境对资产和版本进行分类，使其易于跟踪和识别。	一致的部署方法可减少由过程错误和差异引起的问题，并使你能够将精力集中在工作负载关注点上。标准化可确保安全、可靠且可重复性地完成部署。通过分类，可以轻松查看以前部署的日志和已发生的问题。你可能能够使用该信息来加速回滚和前滚操作。
定期部署小型增量更新。	频繁、经过良好测试的小型更新使版本验证更加容易。由于占用空间较小，故障排除速度更快，对客户的影响最小。
在整个开发生命周期内，使用不同的机制严格测试更新。	在开发的早期阶段捕获问题。迭代修复和一致的部署做法会导致问题在更新准备好投入生产时逐渐减少。
逐步推出更新，并尽职尽责。使用提供控制权的部署模型逐步增加实例和客户的数量，直到所有人都安全采用更新。	以受控方式测试每个更新，以便在生产早期修复问题。避免推出影响整个客户群的错误更新。测试更新是否向后兼容和向前兼容。
制定缓解策略，从部署失败中快速恢复。该策略应包括根据问题的关键性对回滚或向前回滚的决策。具有定义完善的流程和自动化系统，可以使用标准部署管道快速推出修补程序。	缩短潜在影响的持续时间。将系统还原回以前的工作版本，或前滚到具有经过全面测试的修补程序的版本。
制定回退计划，以便在紧急情况下将系统重置为工作状态，并从意外故障中恢复。仅在必要时并在批准的情况下使用此策略。努力随着时间的推移改进计划。	可以快速跟踪高优先级修补程序，例如安全修正。加速管道可能没有对标准操作过程进行所有检查，但你会以最快的方式让客户获得安全版本，这超过了影响较小的故障。