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

卓越运营设计原则

卓越运营支柱的核心是 DevOps 做法，通过 标准化工作流和团队凝聚力确保工作负荷质量。 此支柱定义了开发 实践、可观测性和发布管理的操作过程。 目标是最大程度地减少流程差异、降低人为错误几率和客户中断的可能性。 要评估运营健康状况，请从以下问题开始：

• 执行操作时是否遵守纪律？
• 客户是否以最大可预测性使用工作负载？
• 如何从经验和收集的数据中学习，以推动持续改进？

如果所有权或领导层不明确，工作负载运营可能会陷入混乱。 在这种环境中，团队通常会采用大工作量而低产出的执行方法，这会导致用户体验不佳。 这些方法只能满足短期目标。 长期效益是通过 持续评估和战略投资实现的。

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

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

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

如果你实现这些目标，则即使是在变化时期，工作负荷也会可靠且可预测地运行。 无法满足操作要求可能会导致部署失败、用户体验不一致，并增加了可以通过适当的规划和简化执行来避免的成本。

拥抱 DevOps 文化

使开发团队和运营团队能够本着协作、共担责任和主人翁精神进行合作，不断改进其系统设计和流程。

DevOps 是一个实践社区，在其中，观点和技能的多样性推动同一个使命的实现。 Teams 必须 培养共享知识 的协作环境，而不是孤立的学习环境。 使用共享功能来努力克服资源约束。

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

同时，DevOps 做法 对每个团队应用明确的所有权和责任线。 无论应用程序在何处运行，工作负荷团队都对该应用程序负责。

DevOps 优化运营任务，使其高效但不繁琐。 为了充分发挥 DevOps 的优势，该文化应该通过技术来优化流程，并为组织中的人员提供促进透明通信的流程。

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

建立开发标准

通过标准化开发做法、强制实施质量关卡以及使用系统化的变更管理跟踪进度和成功案例来优化工作效率。

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

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

通过可观测性改进运营

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

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

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

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

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

放心部署

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

构建工作负载供应链，以支持你跨工作负载托管平台、应用程序、数据和配置资源在所有环境中一致地实现可预测性目标。 部署机制必须能够进行自动化、测试、监视和版本控制。 它应采用模块化设计，并且可以随时按需执行。 它不应表示为整体式端到端过程。 供应链并不一定是为了更快速的执行，而是为了在多次迭代中实现一致性和自我记录。

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

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

注意

将门户使用情况的范围减少到仅重复的调查任务。

自动执行以提高效率

将重复的手动任务替换为软件自动化，使其更快、更一致性和准确性，并降低风险。

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

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

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

采用安全部署做法

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

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

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

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

后续步骤

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

卓越运营清单