卓越运营成熟度模型

强调在解决问题方面的团队合作和团结，以建立一个坚实的基础，在后续阶段创建一致的稳定作。

在级别 1 建立 DevOps 思维模式，确保未来策略的成功。 实施完善的 DevOps 方法以提高流程效率。 专注于构建基本和常见的词汇、流程和工具，以确保运营稳定。

关键策略

• 鼓励协作，培养无罪的文化

在培养协作文化的同时，使团队努力与业务需求保持一致。

集中团队成员、专职员工、合作伙伴或供应商通常负责工作负载运营。 这些人应作为集体力量，相互尊重和承认对方的专业知识。 如果团队作为独立部件运行，可能会发生复杂性和摩擦。 独立团队破坏了作为推动业务成果的单一高效系统运作的目标。

为了减少孤立的所有权感，倡导统一解决问题的方法。 所有努力都应满足业务需求。 将成功和失败视为共享结果。

• 采用标准协作方法和工具

从行业证明的工具和软件开发生命周期（SDLC）流程开始，这些流程适合工作负荷并提高开发效率。 不要偏离经过验证的方法，避免使用自定义方法，因为它们通常会带来更高的摩擦。

热门选择包括敏捷开发、Scrum框架和看板管理工具。 大多数经验丰富的开发人员、DevOps 工程师和产品所有者都熟悉这些工具，从而最大限度地减少新员工学习曲线。

最初，使用既定的行业标准来整合标准化。 稍后优化进程。 确保选择的工具可以随需求而增长，而无需提前切换到尖端解决方案。

• 设置源代码管理进程

根据应用程序的规模，决定如何构建源代码。 对于较大的系统，每个团队都应有自己的流程来生成和部署他们负责的组件。 它们应明确定义接口，允许组件可发现性并与系统的其他部分共享。 选择源代码管理技术并设置流程，以确保团队成员不会相互干扰工作。

同样，单个部署管道对于较小的应用程序可能更有效。 这简化了协调，也可能更适合可靠性。 但是，更新或迁移系统的特定部分可能很困难。

• 使用基础结构即代码（IaC）作为主要部署方法

使用声明性方法作为部署的标准，以确保一致性、可重复性和长期优势，例如自动化、自我文档和更改历史记录。

首选 IaC 部署而不是门户部署，以避免出现不一致的配置和缺少测试的风险。 避免使用仅限于特定程序编译的语言或专有格式。

首先，使用 Azure 原生支持的工具（如 Bicep 和 Terraform）来构建良好的基础。 评估工具以确保它们简化未来的旅程。 确保技术提供商有良好的文档和可靠的服务支持计划。

风险： 将错过的现代化机会视为风险。 例如，应使在本地解决方案中使用的工具和流程现代化。 迁移到云时，这些工具通常需要难以管理的自定义脚本，如果不对其进行现代化，可能会导致问题。

若要缓解此风险，请探索新式技术选项并更新本地进程。

采用 IaC 的目标之一是一致性。 使模板足够灵活，可以跨各种环境进行部署。 使用参数、变量和配置文件修改每个环境的资源设置。 仅提取必要的设置，并避免对很少更改的设置过度抽象。 此外，通过依赖广泛的模板库避免过度复杂化解决方案。 这种做法可能会导致维护挑战。

建立坚实的 IaC 基础，为将来的水平部署和系统管理优化创造更多机会。 例如，可以添加所需的状态配置或 GitOps。

• 从一开始就确定安全性的优先级

即使在此早期阶段，也优先考虑安全性。 安全措施通常基于分段，例如角色、资源和网络，这带来了复杂性。 团队必须承认这些复杂性，尽早制定安全措施，并计划随着时间的推移投资安全。 此方法可避免将安全实现推迟到后续阶段。

风险： 开发、支持和运营流程可能会产生摩擦。 尽管团队以良好的意图开始强大，但安全努力往往面临阻力。

若要降低风险，请将安全任务添加到积压工作。 这种做法可确保团队内部的责任明确，并使进度与开发任务一同被跟踪。

使工具和流程透明，以便通过审核和对等评审轻松检测漏洞。 探索支持漏洞扫描和安全控件的行业标准工具，即使尚未完全实现它们。

确保工具和部署做法使用与生产环境相同的标识提供者来最大程度地减少不同的标识控制平面。

标准化基础流程。此方法简化了决策责任，并定义了系统部署和监视的要求。

在级别 2 中，团队应采用更结构化的方法，并将开发活动集中在工作负荷的核心功能上。 尽早建立一致性有助于在后续阶段尽量减少作负担。

关键策略

• 定义团队角色和决策责任

采用产品思维模式。 与其将工作负荷视为工具、技术或工作功能的集成，不如将其视为一种凝聚力产品，而是明确关注最终目标。 在级别 2 中，应用更结构化的方法，其中每个角色都明确定义并受到尊重。

团队中的专业知识通常有所不同。 这种多样性可用于在各种工作职能之间分配决策。 例如，特定团队成员可能擅长做出技术决策，而其他团队成员可能是定义业务成果以在生态系统中保持竞争力的专家。

风险： 某些工作负荷团队采用共识驱动的文化，只有在每个人都同意时，他们才会承诺执行任务。 这种文化促进包容性，但在未达成完全共识时，它通常会扼杀倡议。

使用以下原则确保结构良好的决策过程：

• 指定一个直接负责的个人，以确保决策在团队成员之间分配，并与其专业知识领域保持一致，而不是集中到一个人。

  记录决策者是谁，并将此信息包含在新员工的入职材料中。

• 请考虑采用明确定义特定角色和职责的决策方法。 请注意，这些方法可能引起分歧，并将注意力从产品目标转移开来。 建立制衡措施，防止孤立的决策并减少摩擦。

• 努力改进，无论多么小

培养持续改进的思维方式意味着今天做出决策，同时意识到明天可以进行优化。

延迟更改可能会导致团队错过当前的改进机会。 避免过度思考和犹豫不决。 争取完美的解决方案可能会阻碍小而有意义的进展。 专注于现在进行改进，同时不断寻求改进的方法。

技术债务是开发中用于记录短期决策的战略工具。 它可以充当增量更新的动力，从而防止不必要的积累。 将技术债务视为积压工作中的定期任务。

• 标准化基础进程

不同的工作负荷类具有根据其特定特征定制的独特流程要求。 例如，AI 工作负载依赖于机器学习操作和生成 AI 操作，将数据管道引入模型。 任务关键型工作负载优先考虑站点可靠性工程师可以快速操作的实时监控仪表板。

在工作负荷类中，努力实现标准化，以提高一致性并减少运营负担。 对于既包括判别模型又包括生成模型的 AI 工作负载，请标准化数据操作过程。 这些操作包括数据访问、清理和转换，然后再用于训练模型或生成型 AI 模型。

对于以下用例，建议标准化：

风险： 当团队稍微偏离既定标准以探索更好的方法时，通常会持续改进和创新。 应鼓励这些偏差，但进行结构化。 例如，托管创新日使团队能够专注于预先选择的改进项目，从而培养新的想法和实验。

• 购买工具而不是生成自定义工具

标准化流程包括用于有效实现的必要工具。 在此级别，优先处理现成的解决方案，而不是自定义生成的解决方案，稍后可以重新考虑专用用例。

适用于工作负荷的日常工具包括开发、测试、监视和部署工具。 购买的工具简化了工作流并确保一致性。 这种一致性使团队能够专注于交付功能，而无需开发和维护自定义解决方案的复杂性。

风险： 在考虑工具时，通常倾向于过度强调工具的可扩展性和未来潜力，而不是其核心功能。 在此阶段，请专注于实用工具、解决当前问题以及适合当前工作流的工具。

• 跨工作负荷采用自动化

开发新的或现有的工作负载时，寻求集成自动化的机会。 从一开始便在设计新工作负载时考虑自动化，使未来的采用过程更加顺利。 同样，在生命周期的早期将自动化合并到现有工作负载或 棕色地带 工作负载中，可帮助你提高效率并随时间推移保持一致性。

为了简化采用，请使用成熟的现成工具，这些工具与云平台兼容，而不是从头开始构建解决方案。 浏览云提供商提供的本机自动化工具以简化设计。 例如，许多 Azure 服务支持自动缩放以提高性能，并在灾难恢复中具备故障转移功能。 评估非Microsoft工具时，请考虑团队的专业知识和所有相关的业务标准。

以下方面可以受益于自动化：

• 常规操作任务，如监视、报警和更新管理

• 软件开发生命周期任务，如部署和测试

• 工作负荷性能优化，例如资源缩放

• 安全和治理机制，如扫描和策略强制实施

• 备份和恢复活动

• 成本优化策略如释放资源与关闭服务

风险：在工作负载开发初期，过于关注构建或集成自动化可能会影响向生产交付的效率。 采取有措施的方法，确保工作负荷在保持开发速度的同时可管理。

折衷： 如果任务不常、高效、安全地由人类完成，则它可能不值得自动执行。 例如，自动化证书的年度更新，可能不值得投入开发周期。

• 扩展基础结构即代码体验以配置基础结构和管理应用程序

在级别 1 中，重点是采用基础结构即代码 （IaC） 工具来部署应用程序代码的基础结构和管道。 在级别 2 中，扩展这种做法，包括该部署的基础结构和应用程序的配置和管理。

使用所需的状态配置方法启动资源并避免配置偏移。 不同的任务和平台需要不同的自动化工具。 例如，Ansible 适用于管理虚拟机（VM）的所需状态配置，而 GitOps 解决方案（如 Flux）适用于 Kubernetes 群集。

确定部署后任务的正确自动化级别，以尽量减少作负担，同时保持设计简单。 安装证书、OS 配置和数据库种子设定等任务都是自动化的好选择。 此外，请考虑扩展自动化，以包括在新部署的 VM 或容器主机上部署和配置应用。

风险：避免工具泛滥。 使用不同方法和技术的开发人员或开发团队可能会导致工具生态系统破裂。 针对满足你的要求的工作负荷，对选择数量的工具进行标准化，并确保在这些工具上训练工作负荷团队。 同样，在采用组织级工具标准时应保持审慎。 如果你的组织建议向工作负荷添加过多风险的工具，请评估更适合的替代工具。

• 定义工作负荷的部署策略

部署策略是卓越运营的关键组成部分。 设计良好的部署策略可确保服务在更新或更改期间减少或消除停机时间，确保服务可供用户使用。 就如何以及何时将更改部署到生产与利益相关者达成共识。 请考虑以下几点：

• 定义容许的停机时间。 确定工作负荷是否可以支持停机，而不会造成重大问题或财务损失。 明确指定零停机时间是否是例程部署的要求。

• 设定部署频率。 根据功能开发确定部署频率。 在每日、每周、季度或其他合适的方法之间，就时间安排达成一致。 如果可能，并且符合你的方案，优先考虑进行更小、更频繁的部署。

• 规划紧急部署。 制定计划，以实施管理紧急部署的程序，诸如安全修补程序。 此方法可确保团队成员了解其职责，并在需要时快速采取行动。

设计可自动执行的可重复部署系统，以最大程度地减少错误并确保一致性。 包括回滚机制，以便在上次部署发生错误时将系统恢复至正常状态。

• 设计工作负荷监视堆栈

设计监视系统需要选择要监视的内容，并了解这些指标对用户的重要性。

首先从工作负荷中的所有组件收集日志和指标。 利用平台提供的监视工具。 这些工具集成于服务，并通过很少的配置提供功能见解和操作见解。 安全地将此数据存储在可查询进行分析的可靠存储解决方案中。

风险： 避免收集过多的数据，因为它可能会产生噪音并增加成本。 从 CPU、内存使用情况和存储使用情况等基本指标开始。 随着时间的推移添加有用的应用程序运行状况指标。

根据初始分析，与利益相关者合作，定义健康状态和不健康状态对工作负荷的具体含义。 在后续阶段中使用此信息来开发一个准确反映健康状况的健康模型。

风险： 监视管道充当收集业务指标的工具，包括退款、事务服务级别协议、容量保证和销售总额。 保持工作负荷运行状况指标与业务指标之间的明确区别。

通过应用程序功能收集业务指标，而不是通过监视配置。 监控数据流可以进行采样，并且通常在灾难中无法恢复。 将业务关键型数据视为工作负荷数据，并将其与工作负荷运行状况信号分开。

可降低可能导致停机的部署错误的风险。如果出现停机，请确保站点可靠性工程师可以专注于关键问题，而无需浪费时间收集指标进行分析。

在早期级别，可以标准化软件开发生命周期，并就部署方法、测试和遥测收集做出关键决策。

级别 3 的业务操作应成熟，以增强部署信心。 测试已成为确保安全稳定部署的上线要求。 部署过程也不断发展，采用自动化管道生成工作负载并将其部署到生产环境。 为了尽量减少风险的爆破半径，在基础资源和应用程序代码之间保持适当的分段。

监视做法也成熟。 监控系统被扩展，以实施一种将操作知识转化为可操作见解的健康模型。 警报经过简化，以适应业务上下文，因此无关的警报不会导致虚假警报，也会导致监视系统中不信任。

关键策略

• 使用单独的环境来推广发布

在此级别，在上线之前，必须将 版本推广 纳入正式的变更控制协议中。 此过程将建议的更改通过各个阶段，每个阶段设有质量控制点来推进。 每个阶段都经过彻底的测试，变更只有在通过这些检查并获得批准之后才会推进。

为开发/测试、质量保证、用户验收测试（UAT）和生产等不同阶段创建不同的环境。 此方法可确保在进入下一阶段之前进行彻底验证。 其思路是在较低的环境中管理风险，因为应尽早捕获错误，以最大程度地减少爆炸半径。

• 执行足够的测试

在此级别，确定一种策略，其中测试优先用于系统的关键部分。 使用以下步骤来确保可靠的测试策略：

• 定义测试用例。 为应用程序代码、基础结构模板和配置创建测试用例。

• 执行各种类型的测试。 在每个环境中执行不同类型的测试。 开始在低风险环境中测试高风险更改。 随着置信度的增长，将高风险更改逐渐转移到高风险环境。

• 设置单独的测试环境。 为不同的测试活动创建不同的环境。 例如，如果执行 UI 测试，请创建独立于开发和生产环境的专用环境。

理想情况下，尽可能保持开发和测试环境与生产环境类似的环境。 确保测试数据与生产数据紧密匹配，即使它只是一个示例。 资源也应该是可比的。 例如，在某些情况下，具有几兆字节数据的小型测试数据库可能已足够，但使用包含数 TB 来评估实际性能的近生产大小数据库来验证功能至关重要。

权衡： 保持这些环境紧密非常重要，但需要考虑取舍。 在开发中部署生产环境的完整规模是不可行的。

在接近生产环境和具有经济高效的非生产环境之间找到平衡。 例如，请考虑创建临时开发/测试环境，这些环境在测试通过后被拆毁。

根据测试用例调整环境大小。 单元测试可能只需要在较小的设置中匹配库和 OS 版本。 复原测试可能需要具有相同服务 SKU 的预生产环境。 性能测试可能需要生产规模部署。

• 尽可能自动执行测试和其他质量检查

自动化非常适合确保一致性并快速发现意外的配置更改。 确定可以通过自动测试检查哪些更改。 例如，迁移到开发人员环境时，安全扫描非常适合自动化。 并非所有测试都需要自动化，某些测试无法自动执行。 例如，UAT 需要将实现与用户的期望进行比较，并得到他们的批准。

各种测试工具可用于自动执行和简化不同类型的测试，例如用于协调自动测试的 Azure 负载测试和 Azure Pipelines。

• 设置审批流程

随着部署在不同环境中移动，请务必使用测试和审批流程来验证更改。 此验证应成熟，随着时间的推移变得更加严格。 例如，从开发人员工作站迁移到共享开发人员环境时，基本安全扫描和对等评审通常已足够。 但稍后可能需要包括业务利益干系人。 请考虑以下准则以确保结构化且高效的部署过程：

• 定期发布的审批： 在定期发布方面，从过渡环境迁移到生产环境需要一组不同的条件。 有关发布决策（如迁移到生产环境）需要得到相关方批准、具有明确的文档，或同时具备两者。 工作负荷团队应定义谁是审批过程的一部分及其职责。 在某些监管案件中，审核员也可能包含在决策过程中。 在级别 2 中建立这些角色和职责。

• 为修补程序创建单独的过程： 对于部署安全修补程序等危急情况，可能需要即兴部署过程。 创建一个紧急过程来加速这些高优先级修复。 此过程可以仅包括关键利益干系人和技术成员的批准。 或者，可以开发一个管道，绕过某些审批来加快部署速度。

  确定要跳过哪些步骤时，请仔细考虑对业务或客户的风险。 在紧急情况下可以跳过高成本和低风险的测试，而高风险和低成本的测试应始终运行。 直接负责的个人（DRI）应根据主要利益干系人和技术决策者的意见作出最终决定。

• 实现自动化部署

根据不同层的预期更改率维护不同的部署周期。 在某些情况下，可能需要组合周期，具体取决于相互依赖性和停机时间要求。 但是，在大多数情况下，应以最低权限单独管理每一层，以提高细化程度。 确保一个层中的更改不会影响其他层。

例如，网络基础结构更改的频率应低于应用程序代码更改。 通过质量控制，以简化的过程单独管理这些更改。 若要创建进程，请生成与工作负荷层一致的部署管道。 在将基础结构即代码资产部署到生产环境之前，先对受控环境中的基础结构即代码资产运行测试。

开发健康模型

设置基本监视系统后，将业务上下文与监视数据相结合，以量化工作负荷组件的总体运行状况和总体状态。 此操作称为健康建模，即将监控值与业务上下文关联起来。 为了构建有效的健康模型，请考虑以下关键原则：

• 提供系统观察的数据上下文。 设置阈值是健康建模的重要组成部分。 若要确保阈值对工作负荷有意义，请提供具有上下文的数值。 例如，尽管 CPU 使用率在 70% 到 90% 之间的 CPU 使用率通常表示一个工作负荷中的 运行不正常 ，但对于有效使用可用资源的另一个工作负荷而言，该状态可能 正常 。

• 对变更发出警报。 这些值的变化反映出健康状态的变化，应促使 DRI 采取行动。 因此，警报是运行状况建模的另一个核心组件。 避免启用标准指标并将所有警报发送到支持中心。 而是根据健康模型中的变化引发警报。 警报中包含的信息必须有意义且可作，告知正确的团队需要调查或纠正措施的特定问题。

• 可视化您的健康模型。 使用监视平台中的可视化工具轻松与不同的利益干系人共享工作负载运行状况信号。 某些利益干系人可能需要特定的统计信息，例如应用程序可用性。 运营团队需要访问所有健康信号。 设置不同的仪表板有助于为每个团队提供所需的信息。

随着时间的推移，制定并实施策略来跟踪和分析历史工作负荷健康状况趋势。

• 设置事件管理过程

当工作负载处于生产环境中时，处理平台故障、数据损坏等事件是正常的。 关键是在为工作负荷设置的目标内有效处理这些事件。 因此，在投入生产之前，将结构化支持计划作为事件管理的第一步。

• 通过定义谁待命、职责是什么以及待命人员之间的交接方式，正式化支持作。 理想情况下，呼叫轮换不应存在差距，每个人都知道谁负责随时处理事件。

• 对于每种类型的事件，请确保您拥有一个明确定义的行动计划或响应过程。 例如，您可以使用故障模式分析（FMA）或安全基线的结果。

• 使用运行状况模型对事件管理的准备情况进行基本测试，操作员监视模拟问题的影响，而待命状态的开发人员可能需要排除故障。

确保系统符合用户承诺的质量标准，并防止违反服务级别协议。

在以前的级别，工作负荷团队侧重于构建功能和让系统投入生产。 在此级别，重点从构建功能转向维护和改进实时系统。 随着真实用户依赖系统，重点转为通过高效的 Day-2 运维管理变更，如分诊、维护、升级和排错。

主要策略是使用实际体验来改进运营。 测试也成为一种不可谈判的做法，以减少与更改相关的风险。 必须将测试集成到开发的每个部分，从修复 bug 到添加功能和优化事件响应。 如果没有它，严重的问题可能会被忽视，直到它们到达生产环境。

在这个水平上，技术债务成为真正的关注点。 不太理想的实现可能会生效，这可能会使维护复杂化。 团队应分析维护负担，并专注于减少维护负担。

关键策略

• 使用安全部署做法

生产后，这三种关键类型的更改通常包括例程更新、新功能更新和紧急更新。 在这些更改期间，使用安全部署做法使系统保持稳定。 无论更改类型如何，都将每个更改视为工作负荷用户的潜在故障点。

将以下策略集成到更改控制过程中：

• 持续、全面地验证。 在整个开发生命周期中及变更推进至不同环境阶段时，尽早且频繁地测试。 理想情况下，每次工件更改时，都要设计侧重于这些更改的测试。 然后运行完整的测试套件来验证流端到端。 测试结果提供验证数据，但业务利益干系人仍应批准这些更改。

  折衷： 运行整个测试套件可建立对部署的信心。 但是，由于时间和成本，所有更改都可能并不可行。 在彻底测试与成本考虑之间取得平衡。 根据更改的影响定制审批过程。 次要更改应具有简化的过程，而重大更改（如新功能）需要全面审查。

  在此级别，您可以采用高级操作概念，例如区域故障转移。 目标是以完全自动化这些流程，重点在于在大多数场景中的自我修复。 还必须广泛测试这些过程。

• 为 API 实现版本控制。 请仔细管理对数据模型的更改，以确保向后兼容。 API 版本控制策略可帮助现有系统在部署更改后继续顺利运行。 事后版本控制可能较困难，因此应尽早建立策略。

• 分阶段推出更新。 按级别 3，部署过程通过跨所有环境使用自动化管道进行标准化。 在四级成熟度，工作负载已进入生产环境。 重点转向优化增量更新，包括管理发布周期。

  部署小型、频繁的更新，以简化对少量更改的验证。 自动执行验证任务，例如负载测试、部署到测试环境和 A/B 测试。

  注释

  安全部署模式（如金丝雀部署和蓝绿部署）通过并行部署提供灵活性和可靠性。 例如，在蓝绿部署中，构建新环境、切换流量、废弃旧环境。 其他部署技术包括功能标志和暗发布。 这些方法允许在向所有用户推出更改之前在生产环境中进行测试。 此功能适用于特定的 Azure 服务，例如 Azure 应用服务，可通过在部署槽之间逐步交换来推出更新。

• 从部署错误中恢复。 预期某些更新会失败。 使用增量更新，当出现问题时，故障排除会更快。 如果发生故障，请停止系统以防止进一步损坏并实施更改以解决问题。 如果备份保持连续性，则从备份还原是可以接受的。 目标是推进至稳定版本，而非仅依赖回滚方案。

✓ 优化构建操作

在级别 3 中，应根据体系结构的不同层的更改率为不同的部署周期。 至少保留基础结构和代码管道。

现在工作负荷已投入生产，请重新审视分层策略。 如果可能，进一步分离体系结构组件以实现更灵活的发布节奏。 此方法可减少延迟并最大程度地减少各个组件中的故障。 此外，以并行作业的形式运行测试和长时间运行的进程，以节省时间并提高开发人员工作效率。

• 验证事件响应过程

在级别 3 中，你将建立一个待命支持系统，并使用剧本来定义对事件的响应。 但是，拥有策略手册只是第一步。 现在工作负荷已经进入生产阶段，必须验证和增强事件管理流程的有效性，并制定稳健的沟通计划。 请考虑以下做法：

• 测试事件响应。 合并来自技术、人员和流程的响应。 若要将现实主义引入验证工作，我们建议你运行游戏日。 游戏日是引入故障的计划事件，用于测试团队检测和解决问题的能力。 此方法可确保团队具有适当的工具、资源和过程。 混沌工程是另一种有价值的技术，它引入了受控中断来观察结果。 或者，还可以使用手动方法（例如在全局负载均衡器上禁用后端或执行数据库故障转移）来测试响应。

• 制定沟通计划。 明确定义工作负荷团队、支持团队和应急响应人员之间的沟通责任。 规范业务利益干系人内部状态更新的节奏和格式，可提高透明度和信任度。 在特定情况下（如安全漏洞），需要向最终用户进行负责任的披露。 确保在这些外部通信中明确定义了适当的信息和信息级别。

• 进行事故复盘。 将每个事件视为从生产中学习的机会。 使用此过程确定部署和开发过程中的弱点，并承诺进行系统改进。

使用生产中的监视数据优化操作

在第 4 级，高级监控应在业务上下文中生成、关联并分析指标。 在这个级别，通过从生产实践中学习来提高其精确性。 使用监视数据优化基于最佳猜测构建的进程。 请考虑以下关键示例：

• 三阶的主要重点是为工作负荷开发健康模型。 在级别 4 中，微调警报系统，并设置现实目标和服务级别指标。

• 作为 Day-2 运维的一部分，最小化配置偏移应是关键优先事项。 如果没有此焦点，运行时环境可能会逐渐偏离其预期状态。 首先捕获已知良好的配置的快照。 然后利用生产中的可观测性指标，将当前行为与该基线进行比较。 此方法可确保与预期系统状态保持一致。

• 此级别非常适合引入反馈循环，以便更好地了解系统在特定压力因素下的行为方式，并预测新功能的影响。 系统遥测通过提供关键见解来指导这些反馈循环，帮助预测工作负荷更改并塑造潜在问题的主动解决方案。 还可以使用此数据来帮助确定技术债务的优先级。

一般做法是，根据生产中的可观测性和模式微调监视堆栈。 请考虑以下做法：

• 调整日志记录级别，以平衡可见性和噪音，以捕获关键路径上的活动。

• 放大重要警报，同时抑制无关的警报。

• 自动维护

在级别 3 中，自动化工作主要侧重于部署到生产环境。 到级别 4，团队通过使用持续集成和持续交付管道自动执行生成、测试和部署过程，显著减少了手动工作。 与质量入口一样，还可以通过自动化工作流管理特定的审批。

在级别 4，运营自动化应由实际生产经验驱动，并专注于解决技术债务问题。

考虑以下 Day-2 自动化示例。

主要目标是确定由于截止时间而可能在早期阶段被忽视的重复人工驱动任务。 但你不应该自动化所有事情。 投资回报应引导自动化。 更喜欢使用现有技术和知识，而不是从全新的工具开始。 如果需要轻型工具，请评估其生命周期和维护要求。

• 通过将工具和流程与组织标准保持一致来提高效率

在级别 4 成熟度，通过评估工程资产和流程，专注于提高运营效率。 确定哪些资产至关重要，但不是业务的核心。

对于这些资产，请考虑以下几点：

• 使用组织中已有的共享工具。

• 对于特定任务（如数据转换），请考虑非Microsoft软件。

预生成资产附带支持渠道，可以替换自定义解决方案。 此方法可减少您团队所创建的解决方案的运营负担。 评估这些资源如何满足你的需求，并确定任何剩余的差距。

探索以下工作量的领域：

• 评估自定义代码。 评估被视为行业标准的开源解决方案，而不是为分析等任务编写自定义代码。 使用这些工具可以减少对代码维护的需求，并导致代码库更小。 浏览组织中已可用的选项。 可能存在可以集成到工作负荷中的现有库来处理常规任务，例如身份验证。

• 评估您的工具链。 评估可依赖使用类似工具的其他团队的区域。 相应地调整库、模板和模块的使用。 使整个组织的基础结构即代码工具保持一致，以简化运营。

• 评估进程。 识别可以完成你可能自己实现的任务（例如安全扫描）的集中化流程。 无需自行管理 NuGet 包的隔离流程，可通知组织现有安全团队，让其处理相关模块。

  可支持性是另一个关键领域。 早期，开发团队通常通过监视指标和解决实时问题来处理支持。 在此阶段，请考虑设置专用角色，例如呼叫工程师。 如果组织有共享支持团队，请使用它减少开发人员的支持负载。

  注释

  如果可能，请向外部供应商过渡日常支持。 供应商不像开发团队或架构师那样具备深厚上下文。 在将任务移交给供应商之前，请确保系统在生产中稳定，并明确定义管理任务。 供应商需要关键元素才能成功。 在表示 “正常”、“ 不正常”和 “降级 ”状态的运行状况模型中定义阈值。 为供应商提供关于playbook、工具和其他故障排除资源的培训。 如果他们无法识别问题根源，应建立明确的升级与问题转交路径。

• 定期管理技术债务

技术债务是由于在开发过程中为赶期限而采取捷径所导致，这可能会导致实现效果不尽如人意。 团队应通过分析维护复杂性和时间来减少此债务。 如果未解决技术债务问题，系统可能会变得更加复杂、更难维护或缩放。 这种复杂性会降低创新速度，因为开发人员花更多的时间来解决问题，而不是处理新功能。

请考虑以下用于处理技术债务的战术建议：

• 将技术债务与功能开发同步追踪。

• 在每个迭代中预留用于处理技术债务的容量，与功能开发工作分开。 有时，整个开发周期都用于解决技术债务问题。

• 如果您计划为新功能引入新的技术债务，请立即将建议的解决方案添加到待办事项中。

技术债务是发展的正常部分，也是改进的机会。 随着新增功能，债务累积。 平衡还清旧债务的努力与因开发新功能而产生的新债务。

不断改进和适应，但从未假设你已完成。

随着您从级别 1 到 4 的推进，您在 Azure 上建立一个良好架构的工作负载。 设计建立监控、测试、部署和自动化等操作实践，以便为生产环境做好系统准备。 系统投入生产后，你可以专注于稳定操作和变更管理，以保护用户体验。

在最终阶段，成熟度意味着以规模化方式运行工作负载，确保其可靠且保持更新。 它还需要熟练地识别当前设计已达到其极限的领域，并为业务需求变化做好准备。 随着生态系统的发展，有关约束的假设可能会过时。 保持静态可能会导致回归，因为环境、做法和工具不断发展。 如果不对第五级方法进行投资，您的工作负荷就会面临落后的风险。

级别 5 不是最终目标或技术检查点。 这是一种专注于现代化文化、流程、工具和技术的思维模式转变。 运维获得与工作负载应用相同的严谨、投入和创新关注。

关键策略

• 根据观察到的增长和未来潜力发现重新架构机会

工作负载体系结构是有意识地设计成具有特定限制，并且其寿命是有限的。 通过级别 4，体系结构可能有效地满足业务需求。 在此级别，评估系统如何处理新的使用模式、技术、增长和运营挑战。

例如，在扩展到数万用户时，适用于数千个用户的解决方案可能会失败。 数据量的增加可能会带来原子性问题，而对性能和合规性的需求增加可将体系结构推到极限。 这些压力可以防止交付新功能并造成缩放瓶颈。

在此级别，识别提示点并 识别可能需要重新架构的区域。 请考虑以下方面：

• 你 最初选择的工具、框架和平台服务 可能符合业务需求。 但是，随着系统的发展，这些工具可能会变得僵化或紧密耦合，库可能缺乏可扩展性，平台服务可能会达到生命周期结束，这会破坏现有依赖项。

  探索更广泛的生态系统中的工具和服务，提供强有力的支持和广泛的社区采用。 选择模块化的松散耦合体系结构，以便于更换或升级。

• 在早期级别，工作负荷团队可以 管理整个技术堆栈。 这种方法在初期可能是有效的，但随着系统的扩展，通常会导致压力增加和运营开销上升。 为了减轻这种负担，请考虑将责任卸载到专用团队，例如专注于网络、安全性或可观测性的团队。 其专业知识使核心工作负荷团队能够专注于交付产品价值。

• 管理 客户专用实例（或单租户）实例 可以增加成本和运营开销。 这一挑战通常表明需要采用多租户体系结构。 这种转变需要更广泛的体系结构和运营投资，例如处理租户载入和数据访问隔离。

• 重新考虑您的部署策略，以可预测的方式实现扩展，并在规模化时处理故障隔离和性能优化。 探索经过验证的最佳实践，例如部署印章模式。

  • 缩放单元 是一组逻辑资源，它们可以一起扩展以处理增加的负载，同时被独立监控。 这些单元根据定义的阈值自动部署为可重复块，并在需要时进行复制。

    但是，这种方法可能导致特定服务过度扩展，从而增加成本。

    有关详细信息，请参阅 扩展单元体系结构。

  • 不可变的环境 是部署后永远不会修改系统的部署设置。 与其在原位更新部署单元，不如拆除旧单元并重新部署所需更改。 此方法需要并行部署模型，例如蓝绿部署。 为了采用这种做法，流水线必须准备好自动部署新单元，以应对超大规模扩展或替换不健康的组件。

    级别 4 安全部署实践应该让你为此转换做好准备。 不应出现任何回退，用户应平稳过渡到新的部署单元。

• 使用自动化进一步减少摩擦

从级别 4 过渡到级别 5 不仅涉及提高自动化。 它还涉及使用自动化来减少摩擦，并决定何时应运行这些任务。

请考虑以下示例：

• 自动创建本地开发人员环境： 通过使用同一组工具、库版本和其他开发资产配置每个开发人员工作站来提供标准化体验。 无论体验级别如何，此一致性都允许所有开发人员访问统一环境。 它还有助于更好地协作、知识共享和载入。 使用虚拟化开发环境来简化此过程。

• 自动警报会审和解决工作流： 使用自动化根据预定义规则对警报进行分类和确定优先级，并触发解析工作流。 对于高优先级警报，系统可以通知相关团队并启动解决过程，以加快响应时间。

• 自动事件修正： 实现自我修复脚本，以便在检测到问题时自动重启服务或转移工作负荷。 例如，如果 Web 服务器崩溃，脚本可以重启服务或将流量重新路由到备份服务器，以最大程度地减少停机时间。

• 自动资源使用情况： 随着其他支柱的成熟度的发展，可能需要引入自动化来支持其目标。 例如，可以在非高峰时段计划非关键资源和环境，以降低成本并优化资源使用情况。

• 自动化租户管理： 简化多租户环境中的租户的加入和卸载。 当新租户注册时，自动化可以创建用户帐户、预配资源和配置设置。

• 为每个功能或更改创建开发人员环境

第二阶段操作的重点是执行安全变更。 每个更改都会经历为特定目的设置的不同环境，例如开发、测试和安全性。 按照级别 4 指南，假设你已自动创建这些环境。

与级别 1 到 4 不同，该级别侧重于在内部查看生产就绪情况和管理工作负荷更改，级别 5 是工作负荷团队与整个组织中的其他工作负荷共享其设计、成功、失败的机会。 任务团队无需亲身经历失败，他们可以从已经经历过的人那里预先学习如何避免失败。

• 分享知识并参与组织成熟度

级别 1 到 4 侧重于内部就绪情况和管理工作负荷更改。 级别 5 不同，因为它为工作负荷团队创造了一个机会，以便与整个组织中的其他团队共享其设计、成功和失败。 如果团队能够从遇到类似挑战的其他人那里吸取教训，则团队不必首先经历失败。

这种转变涉及从单个工作负载层次的运营卓越原则，过渡到投资于集中化运营的组织。 这些集中式团队由专门的工程组组成，这些团队构建了配备护栏、自动化、可观测性和测试的部署工具。

您的工作负载团队应与其他团队分享有效的技术、工具和经验。 首先，与你的工作内容所依赖的团队接洽。 然后与依赖于您处理工作负荷的团队进行连接。 分享经验和结果时，请从这些团队中学习。 你应该会看到通过共享平台、文档和社区参与增加的知识共享。

✓ 为工作负载的各类岗位启用自助服务能力

当你在工作负荷的例行开发职责中遇到重复、计划外的任务时，评估它们是否应作为脚本化解决方案交付，团队成员在需要时可以负责调用。 为这些计划外任务构建和维护自助服务功能，以提高团队敏捷性和自主性。

从耗时或容易出错的计划外任务开始，这些任务经济高效，以自助服务解决方案的形式交付给工作负荷团队。 解决方案必须优化团队成员的时间，并在这些任务中构建一致性。 此方法在自助服务解决方案的生命周期内产生投资回报。

遵循 “开始平台工程之旅”中所述的方法和功能。