通过

卓越运营设计原则

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

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

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

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

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

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

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

拥抱 DevOps 文化

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

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

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

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

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

方法 优点
使用促进协作环境的常见系统和工具 进行通信和跟踪进度。 通用工具和流程可实现 透明通信。 开发团队和运营团队都受益于各种环境的态势感知、常见的支持问题以及总体挑战和胜利。

如果发生事件，则团队能够从容地应对，因为已经熟悉现有的升级路径。

共享积压工作 (backlog) 可以使优先事项（例如开发新功能或修复 bug）变得清晰。
在整个开发周期内构建 持续学习和试验思维模式 。

支持跨团队共享知识，并维护文档以供重复使用。

进行无责任分析、发布后和/或事后回顾与审查。		 通过 A/B 测试和开发概念证明等试验机制，你可以鼓励创新，同时降低成本。

通过协作共享知识，使团队精通设计方法、工具和流程。

在项目之后进行回顾有助于 确定改进和 庆祝成功的领域。
采用成熟的行业敏捷做法 ，专注于行动的优化。

在运营中寻找机会，将手动和自动化流程、部署和质量保证实践以及可观测性等“左移”。		 敏捷开发实践导致较短的发布生命周期，这是业务价值的指标。

及早检测、解决和预防问题通常对过程的干扰较小。
为所有开发和作过程设置标准，并定期审查和验证它们。

这些过程包括日常任务、带外流程、应急演练和情况、工具选择、监视过程、技能计划，甚至包括与利益干系人的通信和客户披露内容。

要有意图且明确表达你的决定。		 标准增加了运营的可预测性，并使流程和实践具有可伸缩性。 验证标准是找出改进点的好方法。

通过定期进行演习，为紧急情况和恢复情况做好准备。

精准执行并加强治理，以预防引发风险的异常。
利用具有专业知识和广泛经验的集中式运营团队。 使用共享资源对运营和资源管理具有成本效益。

尽管你拥有工作负荷，但集中式团队可帮助你掌握跨职能技能，例如事件管理、主动监视视角以及信任外包专业知识。

建立开发标准

目标图标 通过标准化开发实践、强制实施质量大门，并通过系统变更管理跟踪进度和成功，从而优化工作效率。

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

方法 优点
记录工作负载特点 并展现客户收益。

确定体系结构的作用域以及详细的功能和非功能需求。

创建大小估算模型 ，以报告涉及的任务的范围和成本。		 良好的规范通过支持更高效和简化的开发周期 来降低运营成本和失败机会 。

开发人员在开始编码周期之前了解 技术设计、目标和完成条件 。

良好的文档可促进新团队成员的可重复 沟通 和 加入 。
根据您的工作负荷和团队规模需求，调整并使用适合的行业标准软件开发方法。

维护在所有角色之间共享的积压工作。		 采用一种众所周知的方法 可设置项目的节奏。 它通过为团队成员提供明确的期望和责任来消除流程歧义。

通过针对常见列表进行跟踪，可以使用标准做法 对任务进行优化和优先处理 。 项目将有更好的机会按时交付。

标准方法有助于 进行风险管理。 通过精细的里程碑评审，开发人员可以在潜在问题成为明显问题之前解决它们。
对所有代码、脚本、部署模板、管道定义和相关文档使用统一源代码管理。

分支策略必须支持顺畅地发布独立和相互依赖的功能、bug 修复和修补程序。

在整个组织中使用共享的知识来构建分支策略和部署过程。		 正确使用源代码管理对于支持 并发更改 和版本控制至关重要。

维护可重复的工作流，以发布不同规模和风险的更改，在此过程中进行同行评审，并保留审核线索。
具有 在 开发生命周期早期强调测试的质量保证流程。

包括所有用于计划测试过程的项目，包括作为功能发布或更新一部分的应用程序组件、基础结构和数据平面操作。

当生成工件在环境中升级时，将其视为不可变的生产工件，这样你就会在生成工件通过质量关卡时获得信心。

在可行的情况下，自动执行例行检查。		 质量保证可确保功能和非功能要求得到满足，从而对客户产生积极的影响。

测试计划可确保质量和完整性，并考虑可能的故障案例。

借助质量入口，可以强制实施最佳做法来降低风险。

不可变性带来了置信度，因为它可确保测试的系统完全是发布的内容。

除非满足质量条件，否则测试周期会有效阻止进度。
通过使用 样式指南和工具（强制实施 约定）来推动一致性，并采用 一个通用的工具链 来开发、测试和与利益干系人进行通信。

开发人员的技术标准应 需要实现 模式、API 设计、 日志记录、异常处理和其他过程。		 代码中的一致性可提高可读性并简化维护。 它还可降低复杂性并启用代码重用。

常见的工具和约定还有助于团队优化流程，而无需解决一次性选择问题。
一始终如一并有意识地坚持要求开发人员在编写代码的同时编写相应文档。 清晰的代码文档可确保在需要回顾旧代码或开发团队轮换时，能够轻松理解逻辑和功能。
报告进度和趋势 以衡量效率。 发布有关 bug、失败更新、部署时间、反馈循环和其他指标趋势的数据，从而推动改进。

通过可观测性改进操作

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

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

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

监视的一个关键方面是应用使用健康建模来帮助您在问题变成事件并影响客户体验之前预测这些问题。 高效的监视可减少在事件管理上花费的被动周期。

方法 优点
使用自己的堆栈和流生成监视系统。

将监控系统视为与其用途分离的工作负荷的一个维度。 堆栈必须涵盖所有层，包括基础结构、应用程序运行状况以及生成和发布过程。

捕获或采样业务数据 超出可观测性实现的范围。		 将监视和工作负荷堆栈分离， 以分离功能要求和可观测性要求 ，并使独立演变成为可能。 代码中的更改不应影响监视，反之亦然。

由于可观测性要求与功能要求分开，因此业务数据不会因监视配置更改或中断而中断。
确保每种类型的数据源的收集过程保持一致。

通过采用行业标准使代码中的检测标准化，包括遥测、基础结构指标的收集以及工具的使用。		 一致性可防止感知和测量方面的差异，因为类似资源的熟悉 可减少关联和分析数据所花费的时间。 你有一个整体视角来预见问题。

从应用程序代码发出遥测数据，这些代码关联执行流的关键点，并提供不同粒度级别的端到端视图。 根据严重性级别确定操作的优先级，并根据其详细程度来理解上下文。 此信息对于故障排除至关重要。
拥有发出和收集数据的责任，即使数据接收器由多个团队共享并由中心团队管理也是如此。 通过将监视数据本地化到工作负荷环境，团队可以访问日志和指标来解决工作负荷问题。
收集 足够多的数据 ，并保留足够 时间。

考虑与日志记录和存储数据相关的成本权衡。		 有意的数据收集可帮助你优化与收集更多数据相关的 财务和运营成本 。

尽量减少干扰，避免在分析期间进行密集计算 ，并降低存储不再需要的数据的成本。
区分不同的监视信号：概要、日志、指标和跟踪。 将每个信号用于正确的用途。

优先考虑使用指标来触发依赖数值衡量的动作。

使用配置文件获取系统中较低级别的可见性，例如内存分配。

保留日志和跟踪的使用，为流和依赖关系提供上下文。		 通过将信号用于正确的目的，可以防止监视系统的低效实现。

例如，使用日志记录动作需要进行解析。 可以使用指标更快地实现相同的目标。
在仪表板中聚合和可视化 数据，以展示面向受众的监控数据，同时兼顾业务背景。

使用 情况仪表板 显示数据，以提高利益相关者的意识。

使用具有向下钻取功能的操作仪表板和工作簿来支持操作员的活动，如事件响应。 经常刷新仪表板并提供精细数据。		 借助可视化效果，可以分析趋势、跟踪业务目标和管理事件。

为客户兴趣量身定制的仪表板能提供相关解释，并加快检测和采取行动的时间。
通过向有责任的角色发送带有标准化说明和严重级别的通知，使警报更具可操作性。 提供从各种来源整理的信息，并跟踪与业务目标的偏差。

仅对需要采取行动的事件触发警报。

努力实现主动且能引发思考的警报，在降级状态变为故障之前启动操作。		 警报引起人们对组织定义的重大事件的关注。

良好的警报系统可识别作和严重性，并提供足够的数据来促进清晰度和目的。 操作员可以立即开始修正工作。

自动执行以提高效率

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

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

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

方法 优点
评估所有工作流，以确保其复杂度、工作量、频率、准确性、时效性和生命周期处于适当水平。

基于该评估自动执行工作流，并优先处理具有最高预期回报的工作流。

删除冗余工作流 或增加价值来证明人工工作量是正当的。		 你可以将团队能力重新投入到更高的价值工作中，并提高工作效率和一致性。

生成工作流清单可确保自动执行正确的任务。 移除冗余任务可降低复杂性和减少错误。
当你评估是 构建自定义工具还是购买软件时，请明确你的决定。

为高度专业化且价值较高的工作保留自动化构建。		 通过购买现成的软件并利用支持合同，可以节省维护成本。

通过构建软件，你可以拥有更多控制权，并且可以迎合团队和工作负载特有的用例。 但是，成本影响较大。

工具的选择为您的运作带来了一定程度的标准化。 通过培训，你可以实现统一的采用准备水平。
设计工作负载组件以支持 自动化功能。 避免出现系统设计中缺少自动化，促进重复任务的反模式、减缓增长，并开始积累技术债务的情况。
将所有 自动化视为工作负荷的关键依赖项 。 适应工作负载的预期增长。

自动化工具是工作负载不可或缺的一部分，它应遵循五个架构良好的框架支柱。		 设计自动化组件以抵御安全威胁等风险。 使用已应用的最佳做法，可以避免实现中出现混乱。

如果此依赖项保持正常和安全运行，则工作负载将在高级别保证下继续运行。
通过探索当前工作负载以外的选项，实现大规模自动化。

通过提供模板和框架来载入新项目并提升现有设计和实现的重用，支持“设计一次，随处运行”模型。		 采用经过尝试和测试的方法并降低失败的可能性。

采用安全部署做法

目标图标 通过使用防护措施减少错误和意外条件的影响，实现部署中的一致性。

构建自动化和模块化的工作负载供应链，以确保在所有环境中实现一致、可预测和可重复的部署。 尽早应用安全做法可以确保对生产的信心，并在问题到达客户时实现快速恢复。

所有更改（无论是代码、配置还是项目）都必须使用相同的严格级别进行部署。 测试、监视和版本控制是实现一致性的常见做法。

方法 优点
使用基础结构即代码（IaC） 定义所有基础结构的所需状态。

使用模块化分层方法，但避免不必要的抽象。

使层与生命周期需求保持一致，使基础层保持稳定。		 IaC 支持部署自动化和一致性，并充当可用于跟踪的自文档。 IaC 组件将成为您的软件开发生命周期的一部分，这可以促进测试和质量审核过程。

IaC 还有助于检测和缓解配置偏移。
优选频繁部署的小型增量更新。 较小的更新通过减少并发错误数来简化验证。 当同时发布多个有缺陷的更改时，会显著增加故障的影响范围。
使用 自动化管道 在所有环境中部署代码和基础设施的每项改动。 一致的部署方法可减少错误和差异，使部署可靠且可重复。 部署过程会自行记录，每次运行都会创建活动记录。
在整个开发生命周期中，在预生产环境和生产环境中严格测试更新。 早期测试会更快地捕获问题，允许迭代修复，并在更新准备好生产时减少问题。

拥有多个预生产环境可实现各种类型的测试，从而提高成功生产版本的信心。
使用部署模式推出新功能，允许用户逐步公开和逐步采用。

测试向后和向前兼容性。		 受控的更新推出可降低存在缺陷的广泛问题的风险。 逐渐增加的曝光有助于确保兼容性和稳定性，从而增强对发布的信心。
准备好补救措施，以便在部署出现故障或生产中出现严重缺陷时进行恢复。

使用 测试支持的自动化 来推出修补程序。

对于紧急更新，采用经过利益相关者预先批准的快速流程。		 缓解计划可降低潜在影响持续时间。

可以快速部署紧急修补程序（如安全修补程序）以更快地使用户获得安全版本。

后续步骤

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

卓越运营清单