其核心是简化部署、监视、测试和自动化等关键做法。 旅程以强大的基础开始：共享词汇、标准化做法和鼓励协作和稳定性的 DevOps 思维模式。 从那里，标准化为流程引入了一致性和可预测性。 随着团队越来越熟练，各个任务演变成集成的工作流，由生产就绪的功能（如自动化测试、智能监视和持续集成）提供支持。
最成熟的阶段是关于优化和创新。 在这里，团队大规模运营，实时调整系统，以满足不断变化的业务需求和技术转变。 但是，这不是固定目标;这是一种动态的心态，总是改进，总是适应。
该模型分为五个不同的成熟度级别，每个级别都有一个主要目标和一组核心策略。 为了获得有意义的生产力提升，请从一开始就评估 AI 可以嵌入到您的运营中的位置。 使用下面的选项卡式视图浏览每个级别。 在推进过程中，也要回顾关键的权衡和相关风险。
通过有意嵌入 AI 驱动的工具实现作业现代化，以减少手动、容易出错的工作，并带来可衡量的价值。
端到端评估运营工作流，以确定 AI 可以在哪里提高一致性和工作效率，同时务实地平衡成本、风险和价值时间。
购买：现成的 GenAI 解决方案
现成的 GenAI 工具具有内置的 AI 功能。 它们可以按意向进行广泛分类。 一种是通用的交互式帮助工具，如 GitHub Copilot，这些工具依赖于上下文，可用于各种任务。 这些工具几乎无需任何设置，并且能够无缝集成到现有开发人员的工作流程中以提供上下文感知的帮助。 另一个类别是专用的工具和代理，例如部署代理、SRE 代理，专为特定功能而设计。 它们可以通过 IDE 和 CLI 助手实现开发人员工作效率的集成。
还有一些 Azure 服务具有集成的 AI 功能，因此可能会产生额外的成本。
生成：使用自定义实现的 GenAI
自定义 GenAI 将 AI 直接嵌入到针对特定工作负载量身定制的运营和开发工作流中。 自定义代理可以从票证、代码存储库、指标和监视系统中提取上下文，以生成反映当前作状态并在定义的边界内采取行动的见解。
更高级的实现可以根据内部标准生成和验证代码或基础结构，根据专业知识或可用性路由工作，并应用自定义 ML 模型进行专用预测。 此方法可实现更深入的自动化，并更紧密地与组织流程保持一致，但需要对工程、数据质量、治理、安全性和维护进行持续投资。
AI 功能模式
以下是在实践中使用的一些最常见且易接近的 AI 功能，但此列表并不详尽。 将此用作灵感来评估在运营中可以注入 AI 以提高工作效率的位置。
注释
采用应随着时间的推移而逐步进行：从重点用例（如摘要或内容生成）开始，然后引入能够对任务和工作流进行推理的代理接口，随着能力和信心的增强。 在更高级别的成熟度下，多代理系统跨集成系统和数据运行，以支持更复杂的作方案。
-
摘要。 从文档、报表、日志或对话中读取和压缩信息的 AI 工具，使用用户可理解的语言和术语生成简明的摘要、要点。
-
建议。 用于分析多个数据源、检测模式以及提供上下文感知建议以辅助操作决策的 AI 工具。
-
工件生成。 将书面要求转换为可执行代码、基础结构定义和自动化测试的 AI 工具，同时遵循定义的标准。
-
策略验证。 针对策略、标准和设计文档查看代码、配置和工作流的 AI 工具，以强制实施合规性。
-
优化措施。 使用跨工件见解的 AI 工具来分配工作并针对决策采取措施。
注意
涉及代理时，安全措施不是假想的。 一个未检查的模型、一个错误的自动化或一个过度宽松的访问设置可以大规模传播错误、泄露敏感数据或破坏作完整性。
若要保护敏感数据，所有平台都必须强制实施严格的 PII 掩码和安全修整。 用户仅看到他们有权访问的输出。 这意味着 AI 输出可能不完整，但完全可见性是潜在的暴露成本。
人工审查仍然是必须的，特别是对于架构、安全和运营问题。 评审应侧重于意向、风险，并符合组织标准，而不是低级别语法。 应捕获来自评审的反馈，以持续改进提示、模板和标准。
✓ 摘要工具
摘要代理通常使用简单的Copilot风格架构，具有直接的检索和响应生成功能，因此使其相对容易实现和操作。
风险： 摘要具有固有的正确性风险，尤其是在跨多个文档进行合成时。 虽然无法完全消除错误，但可以通过可解释性和增量导航来降低作风险。 系统应清楚地指示已汇总的内容，并允许用户钻取源材料进行验证。
推理成本可能会随时间而累积。 将简单请求路由到更小、成本较低的模型，并为复杂的多文档综合保留更高级的模型，并接受此过程可能需要的额外协调。 提供简洁的初始摘要，允许用户向下钻取支持详细信息和源内容。
数据管理引入了额外的隐藏成本。 主动管理数据生命周期，以防止由过时文档或冗余版本导致的索引膨胀。 如果需要历史上下文，请通过有意的版本控制保留先前内容，而避免不受控制的重复。
直接用户反馈很有价值。 捕获摘要质量和有用性的输入，并使用它来评估模型路由决策、索引有效性以及缓存或预处理策略的影响。
例子
推荐代理
提供建议的 AI 代理依赖于能够分析多个数据源的面向推理的模型。 这些模型必须具有足够的分析深度来支持跨源关联，而不是依赖于轻型或纯生成方法。
平衡： 虽然更广泛的范围可以增加价值，但交叉引用的来源可能会导致与原始意图不匹配或失衡；过度依赖此类 AI 生成的响应可能会放大错误，并使问题在迭代调用中更加复杂。
它们通常会增加每个请求的成本和推理延迟。 通过偏爱较少但更丰富的查询，而不是许多细粒度的查询，来最大程度地减少外部调用。 在运行时访问和关联多个外部源的成本可能很高，因此并行化数据访问，并在可行的情况下将数据预加载到共享索引中。
使用多个源会增加集成复杂性。 单个源中的错误可以通过建议管道传播。 组合输入时应用验证和安全防护措施。 需要低延迟时，并行查询源。 预处理不依赖于特定请求的步骤，例如分类、扩充和查找。 缓存中间结果和常用功能以减少重复计算。
将建议引擎视为决策支持系统，而不是黑盒。 可解释性是建立信任和操作可靠性的核心因素。 系统应为建议提供明确的理由，突出关键信号和贡献数据源。 考虑包括置信度指标（例如 0-100%），以帮助下游系统或用户衡量可靠性。
例子
-
OE：06 设计工作负荷供应链。 查找难以检测且经常被忽略在测试套件中包括的客户为中心的边缘案例和方案。
-
OE：08 事件管理。 通过让 AI 仅使用提供的文档、操作手册、运行状况模型和升级路径来模拟供应商的支持团队，以验证供应商的过渡计划。 模拟在交接前突显出间隙和隐藏依赖项。
-
OE：09 实现自动化。 评估自动化代码、遥测和事件数据，以建议应改进、停用或扩展哪些自动化。
产物生成代理
AI 代理可以帮助生成代码、基础结构定义和测试，但其输出可能成为生产工作负荷的一部分。 代码生成本质上是不确定的，并且将自然语言要求转换为可执行项目可能会产生与原始意向不同的结果。 因此，明确所有权、显式控制以及集成到现有工程实践中至关重要。 AI 在以下情境中最为有效：在问题空间可以很好地被理解且变化有限，例如对重复性或标准化的编码任务，应在其输出中应用护栏进行指导。
选择正确的模型至关重要。 使用适合代码生成和工具执行的模型，并在适当情况下将它们组合在一起。 推理模型可以帮助系统分析、规划或分解，以代码为中心的模型可以自行生成项目，其他模型可以支持测试或部署步骤。
生成应以模板、参考实现、编码准则和反映组织和行业标准的示例为基础。 明确标准有助于检测偏差并确保一致性。 通过使用模板，AI 输出更具可预测性。
如同大多数代理一样，代码生成器可能从多个源获取信息。 所有输出都应被视为不受信任，直到验证为止。 应用最低特权原则来限制工具执行权限和范围。 在未经明确、封闭的批准的情况下，代理不应部署或修改生产资源。
将生成的项目集成到标准开发人员生命周期中。 这包括拉取请求、代码评审、自动测试和安全扫描。 应用与人工创作代码相同的严格性，包括依赖项检查和基础结构即代码扫描，以确保可靠性和符合性。
权衡： 人工评审仍然是成本模型的一部分，必须纳入 ROI。 此外，工件生成增加会转移下游的吞吐量压力；必须相应地扩展测试、验证和部署流程，以避免引入新的瓶颈。 尽可能通过代码审核工具、测试、静态分析和策略检查进行自动验证，对于维护端到端流程并缩短实现价值的时间是必不可少的。
例子
• 策略验证代理
AI 代理可以帮助根据策略和标准审查和验证资产。 他们的作用是支持决策、标记偏差并强制实施合规性，而人类则保留最终监督。
在推出之前，验证从仔细评估和测试开始。 应对标准进行版本控制，每个资产应明确引用适用的策略，确保可追溯性。 随着策略的发展，必须考虑维护开销，并相应地更新验证过程。 尽可能对评审进行批处理和并行处理，并将增量检查集中在更改上，而不是重新扫描所有资产。
成本和性能需要仔细平衡。 考虑根据存储、处理和延迟的影响做出准确预测所需的历史数据量。 数据太少会降低可靠性，而数据过多则会增加成本。
安全性仍然是一个关键因素。 对验证输出的访问应仅限于授权用户，例如安全审阅者，确保敏感信息受到保护。
度量有效性，而不是假定。 使用仪表板跟踪指标，例如检测到的问题与在生产中发现的问题、误报率和覆盖范围。 将这些见解反馈到验证逻辑、提示和操作流程中，不断优化代理的贡献。
例子
动作优化代理
行动优化代理不仅限于分析和建议，还采取直接的操作行动。 由于它们的输出可以修改系统或进程，因此这些代理需要仔细设计、监督和集成到工作流中。
风险： 安全性是一个主要问题。 代理应在“人机协作”工作流中运行，其中建议的操作在投入生产执行之前经过评审和批准。 访问工具和系统应遵循最低特权原则，将代理限制为仅执行其任务所需的权限。 详细的审核至关重要，捕获提出的操作、批准这些操作的人员及其执行日志，以便实现可追溯性。
实施保障机制，确保影响范围最小化，从而将每次更改的力度限制在有限范围内。 工具执行应是幂等的，以允许安全重试，系统应包括验证和回滚机制。 检查点、备份或其他恢复策略可以支持安全更正意外更改。
例子
-
OE：08 事件管理。 一旦警报触发，系统将自动收集上下文信息、关联数据，并进行初步检查。 工程师从明确的事件图片开始，而不是手动数据收集。
-
OE：09 实现自动化。 在人工定义的范围内，使用从监控数据分析中推断的值，持续优化低风险生产设置，例如缓存大小和超时值。
-
OE：11 安全部署做法。 通过自主确定最佳推出时机以及 Canary 部署的正确目标段和百分比，自动执行渐进式曝光部署策略。
强调在解决问题方面的团队合作和团结，以建立一个坚实的基础，在后续阶段创建一致的稳定作。
在级别 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 自动化示例。
| 流程 |
益处 |
| 自动轮换证书、API 密钥和其他机密。 |
自动化可保证及时轮换，无需手动干预，从而节省时间并减少人为错误的可能性。 |
| 自动执行基础结构的例行维护。 |
例行基础结构维护需要广泛的测试和协调。 自动化可以加快这些任务，减少手动工作并降低风险。 |
| 自动执行紧急响应过程。 |
如果没有适当的自动化，人们可能会在紧急发布期间采取仓促、无协调的作，这可能会导致进一步的问题。 |
| 在负载高峰和下降时自动缩放资源。 |
自动缩放可确保根据需求动态分配资源。 这种分配会导致资源更高效地使用，因为当需求减少时，资源会解除分配，而不会造成过多的作开销。 |
| 自动执行数据检索和传递。 |
此方法减少了满足用户发送的数据请求所需的时间和工作量。 会触发脚本来访问数据库、检索相关数据并将其发送给用户，而不是手动访问数据库。 |
| 根据特定条件自动创建开发人员环境。 |
此方式确保环境创建一致，有助于在工作负载中安全变更，并作为 Day-2 运维的一部分。 |
注释
开发部署自动化策略时，请从已知和可预测的任务开始。 考虑常见故障点。 这些点自动化后，扩展覆盖范围来处理不可预见的问题，其中一些问题可能需要手动干预。 例如，首先自动执行基础结构更新等例行任务，因为它们更易于管理。 然后处理紧急热修复，因为其中可能包含未知故障情境。
例如，一个团队可能会通过在所有区域中逐步曝光用户来例行部署工作负载。 此过程可能需要几天才能完成。 他们还需要具备跳过特定步骤并更快部署热修补程序的能力。 自动化过程应考虑到这些加速部署。
主要目标是确定由于截止时间而可能在早期阶段被忽视的重复人工驱动任务。 但你不应该自动化所有事情。 投资回报应引导自动化。 更喜欢使用现有技术和知识，而不是从全新的工具开始。 如果需要轻型工具，请评估其生命周期和维护要求。
在级别 4 成熟度，通过评估工程资产和流程，专注于提高运营效率。 确定哪些资产至关重要，但不是业务的核心。
对于这些资产，请考虑以下几点：
预生成资产附带支持渠道，可以替换自定义解决方案。 此方法可减少您团队所创建的解决方案的运营负担。 评估这些资源如何满足你的需求，并确定任何剩余的差距。
探索以下工作量的领域：
评估自定义代码。 评估被视为行业标准的开源解决方案，而不是为分析等任务编写自定义代码。 使用这些工具可以减少对代码维护的需求，并导致代码库更小。 浏览组织中已可用的选项。 可能存在可以集成到工作负荷中的现有库来处理常规任务，例如身份验证。
评估您的工具链。 评估可依赖使用类似工具的其他团队的区域。 相应地调整库、模板和模块的使用。 使整个组织的基础结构即代码工具保持一致，以简化运营。
评估进程。 识别可以完成你可能自己实现的任务（例如安全扫描）的集中化流程。 无需自行管理 NuGet 包的隔离流程，可通知组织现有安全团队，让其处理相关模块。
可支持性是另一个关键领域。 早期，开发团队通常通过监视指标和解决实时问题来处理支持。 在此阶段，请考虑设置专用角色，例如呼叫工程师。 如果组织有共享支持团队，请使用它减少开发人员的支持负载。
注释
如果可能，请向外部供应商过渡日常支持。 供应商不像开发团队或架构师那样具备深厚上下文。 在将任务移交给供应商之前，请确保系统在生产中稳定，并明确定义管理任务。 供应商需要关键元素才能成功。 在表示 “正常”、“ 不正常”和 “降级 ”状态的运行状况模型中定义阈值。 为供应商提供关于playbook、工具和其他故障排除资源的培训。 如果他们无法识别问题根源，应建立明确的升级与问题转交路径。
• 定期管理技术债务
技术债务是由于在开发过程中为赶期限而采取捷径所导致，这可能会导致实现效果不尽如人意。 团队应通过分析维护复杂性和时间来减少此债务。 如果未解决技术债务问题，系统可能会变得更加复杂、更难维护或缩放。 这种复杂性会降低创新速度，因为开发人员花更多的时间来解决问题，而不是处理新功能。
请考虑以下用于处理技术债务的战术建议：
技术债务是发展的正常部分，也是改进的机会。 随着新增功能，债务累积。 平衡还清旧债务的努力与因开发新功能而产生的新债务。
不断改进和适应，但从未假设你已完成。
随着您从级别 1 到 4 的推进，您在 Azure 上建立一个良好架构的工作负载。 设计建立监控、测试、部署和自动化等操作实践，以便为生产环境做好系统准备。 系统投入生产后，你可以专注于稳定操作和变更管理，以保护用户体验。
在最终阶段，成熟度意味着以规模化方式运行工作负载，确保其可靠且保持更新。 它还需要熟练地识别当前设计已达到其极限的领域，并为业务需求变化做好准备。 随着生态系统的发展，有关约束的假设可能会过时。 保持静态可能会导致回归，因为环境、做法和工具不断发展。 如果不对第五级方法进行投资，您的工作负荷就会面临落后的风险。
级别 5 不是最终目标或技术检查点。 这是一种专注于现代化文化、流程、工具和技术的思维模式转变。 运维获得与工作负载应用相同的严谨、投入和创新关注。
关键策略
• 根据观察到的增长和未来潜力发现重新架构机会
工作负载体系结构是有意识地设计成具有特定限制，并且其寿命是有限的。 通过级别 4，体系结构可能有效地满足业务需求。 在此级别，评估系统如何处理新的使用模式、技术、增长和运营挑战。
例如，在扩展到数万用户时，适用于数千个用户的解决方案可能会失败。 数据量的增加可能会带来原子性问题，而对性能和合规性的需求增加可将体系结构推到极限。 这些压力可以防止交付新功能并造成缩放瓶颈。
在此级别，识别提示点并 识别可能需要重新架构的区域。 请考虑以下方面：
你 最初选择的工具、框架和平台服务 可能符合业务需求。 但是，随着系统的发展，这些工具可能会变得僵化或紧密耦合，库可能缺乏可扩展性，平台服务可能会达到生命周期结束，这会破坏现有依赖项。
探索更广泛的生态系统中的工具和服务，提供强有力的支持和广泛的社区采用。 选择模块化的松散耦合体系结构，以便于更换或升级。
在早期级别，工作负荷团队可以 管理整个技术堆栈。 这种方法在初期可能是有效的，但随着系统的扩展，通常会导致压力增加和运营开销上升。 为了减轻这种负担，请考虑将责任卸载到专用团队，例如专注于网络、安全性或可观测性的团队。 其专业知识使核心工作负荷团队能够专注于交付产品价值。
管理 客户专用实例（或单租户）实例 可以增加成本和运营开销。 这一挑战通常表明需要采用多租户体系结构。 这种转变需要更广泛的体系结构和运营投资，例如处理租户载入和数据访问隔离。
重新考虑您的部署策略，以可预测的方式实现扩展，并在规模化时处理故障隔离和性能优化。 探索经过验证的最佳实践，例如部署印章模式。
缩放单元 是一组逻辑资源，它们可以一起扩展以处理增加的负载，同时被独立监控。 这些单元根据定义的阈值自动部署为可重复块，并在需要时进行复制。
但是，这种方法可能导致特定服务过度扩展，从而增加成本。
有关详细信息，请参阅 扩展单元体系结构。
不可变的环境 是部署后永远不会修改系统的部署设置。 与其在原位更新部署单元，不如拆除旧单元并重新部署所需更改。 此方法需要并行部署模型，例如蓝绿部署。 为了采用这种做法，流水线必须准备好自动部署新单元，以应对超大规模扩展或替换不健康的组件。
级别 4 安全部署实践应该让你为此转换做好准备。 不应出现任何回退，用户应平稳过渡到新的部署单元。
• 使用自动化进一步减少摩擦
从级别 4 过渡到级别 5 不仅涉及提高自动化。 它还涉及使用自动化来减少摩擦，并决定何时应运行这些任务。
请考虑以下示例：
自动创建本地开发人员环境： 通过使用同一组工具、库版本和其他开发资产配置每个开发人员工作站来提供标准化体验。 无论体验级别如何，此一致性都允许所有开发人员访问统一环境。 它还有助于更好地协作、知识共享和载入。 使用虚拟化开发环境来简化此过程。
自动警报会审和解决工作流： 使用自动化根据预定义规则对警报进行分类和确定优先级，并触发解析工作流。 对于高优先级警报，系统可以通知相关团队并启动解决过程，以加快响应时间。
自动事件修正： 实现自我修复脚本，以便在检测到问题时自动重启服务或转移工作负荷。 例如，如果 Web 服务器崩溃，脚本可以重启服务或将流量重新路由到备份服务器，以最大程度地减少停机时间。
自动资源使用情况： 随着其他支柱的成熟度的发展，可能需要引入自动化来支持其目标。 例如，可以在非高峰时段计划非关键资源和环境，以降低成本并优化资源使用情况。
自动化租户管理： 简化多租户环境中的租户的加入和卸载。 当新租户注册时，自动化可以创建用户帐户、预配资源和配置设置。
• 为每个功能或更改创建开发人员环境
第二阶段操作的重点是执行安全变更。 每个更改都会经历为特定目的设置的不同环境，例如开发、测试和安全性。 按照级别 4 指南，假设你已自动创建这些环境。
与级别 1 到 4 不同，该级别侧重于在内部查看生产就绪情况和管理工作负荷更改，级别 5 是工作负荷团队与整个组织中的其他工作负荷共享其设计、成功、失败的机会。 任务团队无需亲身经历失败，他们可以从已经经历过的人那里预先学习如何避免失败。
• 分享知识并参与组织成熟度
级别 1 到 4 侧重于内部就绪情况和管理工作负荷更改。 级别 5 不同，因为它为工作负荷团队创造了一个机会，以便与整个组织中的其他团队共享其设计、成功和失败。 如果团队能够从遇到类似挑战的其他人那里吸取教训，则团队不必首先经历失败。
这种转变涉及从单个工作负载层次的运营卓越原则，过渡到投资于集中化运营的组织。 这些集中式团队由专门的工程组组成，这些团队构建了配备护栏、自动化、可观测性和测试的部署工具。
您的工作负载团队应与其他团队分享有效的技术、工具和经验。 首先，与你的工作内容所依赖的团队接洽。 然后与依赖于您处理工作负荷的团队进行连接。 分享经验和结果时，请从这些团队中学习。 你应该会看到通过共享平台、文档和社区参与增加的知识共享。
✓ 为工作负载的各类岗位启用自助服务能力
当你在工作负荷的例行开发职责中遇到重复、计划外的任务时，评估它们是否应作为脚本化解决方案交付，团队成员在需要时可以负责调用。 为这些计划外任务构建和维护自助服务功能，以提高团队敏捷性和自主性。
从耗时或容易出错的计划外任务开始，这些任务经济高效，以自助服务解决方案的形式交付给工作负荷团队。 解决方案必须优化团队成员的时间，并在这些任务中构建一致性。 此方法在自助服务解决方案的生命周期内产生投资回报。
遵循 “开始平台工程之旅”中所述的方法和功能。
AI 机会