你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 上任务关键型工作负载的操作过程
可靠有效的操作必须尽可能基于 自动化 原则和 配置即代码。 此方法需要在 DevOps 流程中投入大量工程投资。 自动化管道用于部署应用程序和基础结构代码项目。 此方法的优点包括，只需最少的手动操作过程即可获得一致且准确的操作结果。
此设计领域探讨如何实施有效且一致的操作过程。
重要
本文是 Azure Well-Architected Framework 任务关键型工作负载 系列的一部分。 如果不熟悉本系列，建议从 什么是任务关键型工作负载？开始。
DevOps 进程
DevOps 将开发和操作流程和团队合并到单个工程职能中。 它包含整个应用程序生命周期，并使用自动化和 DevOps 工具以快速、高效且可靠的方式执行部署操作。 DevOps 流程支持和维持持续集成和持续交付 (CI/CD) ，同时培养持续改进文化。
任务关键型应用程序的 DevOps 团队必须负责以下任务：
- 通过 CI/CD 自动化创建和管理应用程序和基础结构资源。
- 应用程序监视和可观测性。
- Azure 基于角色的访问控制 (应用程序组件的 RBAC) 和标识管理。
- 应用程序组件的网络管理。
- 应用程序资源的成本管理。
DevSecOps 通过在整个应用程序生命周期内将安全监视、应用程序审核和质量保证与开发和操作集成来扩展 DevOps 模型。 对于安全敏感和高度管控的方案，需要 DevOps 团队，以确保在整个开发生命周期内整合安全性，而不是在特定发布阶段或入口处。
设计注意事项
发布和更新过程。 避免手动过程对应用程序组件或底层基础结构进行任何更改。 手动过程可能会导致结果不一致。
中央 IT 团队的依赖项。 当集中式函数存在硬依赖项时，DevOps 过程可能难以应用，因为这些依赖项会阻止端到端操作。
标识和访问管理。 DevOps 团队可以考虑将精细的 Azure RBAC 角色用于各种技术功能，例如用于数据库管理的 AppDataOps。 跨 DevOps 角色应用零信任模型。
设计建议
将配置设置和更新定义为代码。 通过代码应用更改管理，以实现一致的发布和更新过程，包括密钥或机密轮换和权限管理等任务。 使用管道管理的更新过程（如计划的管道运行），而不是内置的自动更新机制。
不要使用中心进程或预配管道来实例化或管理应用程序资源。 这样做会引入外部应用程序依赖项和其他风险向量，例如与干扰邻居方案关联的风险向量。
如果需要使用集中式预配过程，请确保依赖项的可用性要求与任务关键要求完全一致。 中心团队必须提供透明度，以便实现端到端应用程序的整体操作化。
在每个冲刺期间，将一定比例的工程能力用于推动基础平台改进和提高可靠性。 建议为这些改进分配 20-40% 的容量。
开发符合核心 设计原则的常见工程标准、参考体系结构和库。 通过使用 Azure Policy 的策略驱动方法，强制实施一致的基线配置，实现可靠性、安全性和操作。
还可以跨组织更广泛的应用程序生态系统中的其他工作负载使用通用工程条件和关联的项目，例如 Azure 策略和 Terraform 资源，用于常见设计模式。
在关键应用程序环境中应用零信任模型。 使用Microsoft Entra Privileged Identity Management等技术来确保操作保持一致，并且只能通过 CI/CD 过程或自动化操作过程进行。
团队成员不应对任何环境具有长期写入访问权限。 你可能希望在开发环境中创建异常，以便更轻松地进行测试和调试。
定义用于实时访问生产环境的紧急流程。 确保在身份验证提供程序出现严重问题时存在破窗帐户。
请考虑使用 AIOps 来持续改进操作过程和触发器。
应用程序操作
应用程序设计和平台建议会影响操作过程。 各种 Azure 服务还提供操作功能，尤其是高可用性和恢复功能。
设计注意事项
Azure 服务的内置操作。 Azure 服务提供默认启用的内置 (，) 可配置的平台功能，例如区域冗余和异地复制。 应用程序的可靠性取决于这些操作。 某些可配置功能会产生额外的成本，例如 Azure Cosmos DB 的多写入部署配置。 除非绝对需要，否则请避免生成自定义解决方案。
操作访问和执行时间。 大多数必需的操作都通过 Azure 资源管理器 API 或 Azure 门户公开和访问。 但是，某些操作需要支持工程师的帮助。 例如，只能由Azure 支持工程师通过支持案例执行从 Azure Cosmos DB 数据库的定期备份还原或恢复已删除的资源。 此依赖项可能会影响应用程序的停机时间。 对于无状态资源，建议重新部署，而不是等待支持工程师尝试恢复已删除的资源。
策略强制实施。 Azure Policy提供了一个框架，用于强制实施和审核安全性和可靠性基线，以确保符合任务关键型应用程序的常见工程标准。 更具体地说，Azure Policy构成 Azure 资源管理器控制平面的关键部分，通过限制授权用户可以执行的操作来补充 RBAC。 可以使用Azure Policy跨平台服务强制实施重要的安全性和可靠性约定。
修改和删除资源。 可以 锁定 Azure 资源 以防止修改或删除它们。 但是，锁会在部署管道中引入管理开销。 对于大多数资源，我们建议使用具有严格限制的可靠 RBAC 过程，而不是资源锁。
设计建议
自动执行故障转移过程。 对于主动/主动模型，请使用运行状况模型和自动缩放操作，以确保不需要故障转移干预。 对于主动/被动模型，请确保故障转移过程是自动化的，或者至少在管道中编码。
优先使用支持 Azure 本机自动缩放的服务。 对于不支持本机自动缩放的服务，请使用自动化操作过程来缩放服务。 使用具有多个服务的缩放单元来实现可伸缩性。
使用平台原生功能进行备份和还原，确保它们符合 RTO/RPO 和数据保留要求。 根据需要定义长期备份保留策略。
使用内置功能进行 SSL 证书管理和续订，例如 Azure Front Door 提供的功能。
对于外部团队，请为需要帮助的资源建立恢复过程。 例如，如果错误地修改或删除了数据平台，则应充分了解恢复方法，并且恢复过程应到位。 同样，建立在注册表中管理已解除授权的容器映像的过程。
作为标准业务连续性准备的一部分，提前对非生产资源和数据执行恢复操作。
识别关键警报并定义目标受众和系统。 定义与适当利益干系人联系的清晰渠道。 仅发送可操作的警报，以避免白噪声，并防止操作利益干系人忽略警报和丢失重要信息。 实施持续改进以优化警报并消除观察到的白噪声。
应用策略驱动的治理和Azure Policy，以确保在所有应用程序服务中正确使用操作功能和可靠的配置基线。
避免在临时区域资源上使用资源锁。 而是依靠适当使用 RBAC 和 CI/CD 管道来控制操作更新。 可以应用资源锁来防止删除生存期较长的全局资源。
更新管理
任务关键型设计强烈支持临时无状态应用程序资源的原则。 如果应用此原则，通常可以使用新的部署和标准传递管道执行更新。
设计注意事项
与 Azure 路线图保持一致。 使工作负载与 Azure 路线图保持一致，以便定期更新平台资源和运行时依赖项。
自动检测更新。 设置进程以监视和自动检测更新。 使用 GitHub Dependabot 等工具。
测试和验证。 在任何发布之前，在生产上下文中测试和验证包、组件和依赖项的新版本。 新版本可能包含中断性变更。
运行时依赖项。 像对待应用程序的任何其他更改一样对待运行时依赖项。 旧版本可能会引入安全漏洞，并可能对性能产生负面影响。 监视应用程序运行时环境并使其保持最新状态。
组件卫生和家务管理。 解除授权或删除未使用的资源。 例如，监视容器注册表并删除未使用的旧映像版本。
设计建议
监视这些资源并使其保持最新：
- 应用程序托管平台。 例如，需要定期更新 Azure Kubernetes 服务 (AKS) 中的 Kubernetes 版本，特别是考虑到无法维持对旧版本的支持。 还需要更新在 Kubernetes 上运行的组件（如证书管理器和 Azure 密钥保管库 CSI），并使它们与 AKS 中的 Kubernetes 版本保持一致。
- 外部库和 SDK (.NET、Java、Python) 。
- Terraform 提供程序。
避免手动操作更改以更新组件。 请考虑仅在紧急情况下使用手动更改。 确保有一个过程来协调任何手动更改回到源存储库，以避免偏移和问题重复发生。
建立从Azure 容器注册表中删除旧版映像的自动化过程。
机密管理
密钥、机密和证书过期是应用程序中断的常见原因。 任务关键型应用程序的机密管理必须提供必要的安全性，并提供适当的可用性级别，以符合最高可靠性要求。 你需要使用托管服务或作为更新管理的一部分定期执行密钥、机密和证书轮换，并应用代码和配置更改过程。
许多 Azure 服务支持Microsoft Entra身份验证，而不是依赖于连接字符串/密钥。 使用Microsoft Entra ID 可大幅减少操作开销。 如果使用机密管理解决方案，则它应与其他服务集成，支持区域和区域冗余，并提供与Microsoft Entra ID 的集成，以便进行身份验证和授权。 密钥保管库提供这些功能。
设计注意事项
有三种常见的机密管理方法。 每种方法都会从机密存储中读取机密，并在不同的时间将它们注入到应用程序中。
部署时检索。 此方法的优点是机密管理解决方案仅在部署时可用，因为在此时间之后没有直接依赖项。 示例包括将机密作为环境变量注入 Kubernetes 部署或 Kubernetes 机密。
只有部署服务主体需要能够访问机密，这简化了机密管理系统中的 RBAC 权限。
但是，这种方法有缺点。 它引入了 DevOps 工具中与控制服务主体访问相关的 RBAC 复杂性，并在应用程序中引入了保护检索到的机密方面的复杂性。 此外，不会应用机密管理解决方案的安全优势，因为此方法仅依赖于应用程序平台中的访问控制。
若要实现机密更新或轮换，需要执行完全重新部署。
应用程序启动检索。 在此方法中，会在应用程序启动时检索和注入机密。 优点是可以轻松更新或轮换机密。 无需在应用程序平台上存储机密。 需要重启应用程序才能提取最新值。
常见的存储选项包括用于机密存储 CSI 驱动程序的 Azure 密钥保管库 提供程序和 akv2k8s。 本机 Azure 解决方案（密钥保管库引用的应用设置）也可用。
此方法的缺点是它在机密管理解决方案上创建了运行时依赖项。 如果机密管理解决方案遇到中断，则已运行的应用程序组件 可能 能够继续为请求提供服务。 任何重启或横向扩展操作都可能导致失败。
运行时检索。 在运行时从应用程序本身内部检索机密是最安全的方法，因为即使是应用程序平台也永远也无法访问机密。 应用程序需要向机密管理系统验证自身身份。
但是，对于此方法，应用程序组件需要直接依赖项和与机密管理系统的连接。 这使得单独测试组件更加困难，并且通常需要使用 SDK。
设计建议
如果可能，请使用Microsoft Entra身份验证连接到服务，而不是使用连接字符串或密钥。 将此身份验证方法与 Azure 托管标识一起使用，因此无需在应用程序平台上存储机密。
利用 密钥保管库 中的过期设置，并配置即将到期的警报。 使用标准发布过程执行所有密钥、机密和证书更新。
将密钥保管库实例部署为区域标记的一部分，以减轻单个部署标记失败的潜在影响。 对全局资源使用单独的实例。 有关这些资源的信息，请参阅任务关键型工作负载的典型 体系结构模式 。
若要避免需要管理服务主体凭据或 API 密钥，请尽可能使用托管标识而不是服务主体来访问密钥保管库。
实现编码模式，以确保在运行时发生授权失败时重新检索机密。
应用在解决方案中定期运行的完全自动化密钥轮换过程。
使用 Azure 密钥保管库中的密钥即将过期通知获取有关即将过期的警报。
使用 VM 时特定于 IaaS 的注意事项
如果需要使用 IaaS VM，本文档前面所述的某些过程和做法可能会有所不同。 VM 的使用在配置选项、操作系统、驱动程序访问、低级别操作系统访问以及可安装的软件类型方面提供了更大的灵活性。 缺点是增加了运营成本，并且对使用 PaaS 服务时通常由云提供商执行的任务负责。
设计注意事项
- 单个 VM 不提供高可用性、区域冗余或异地冗余。
- 部署单个 VM 后，不会自动更新这些 VM。 例如，Windows Server 2019 上部署的 SQL Server 2019 不会自动更新到较新版本。
- 如果要通过基础结构即代码部署和配置 VM 中运行的服务，则需要特殊处理和其他工具。
- Azure 会定期更新其平台。 这些更新可能需要重启 VM。 需要重新启动的汇报通常会提前宣布。 请参阅 Azure 中虚拟机的维护 和 处理计划内维护通知。
设计建议
避免对 VM 执行手动操作，并实施适当的流程来部署和推出更改。
- 使用基础结构即代码解决方案（如 Azure 资源管理器 (ARM) 模板、Bicep、Terraform 或其他解决方案）自动预配 Azure 资源。
确保部署 VM、更新以及备份和恢复的操作过程已到位并经过正确测试。 若要测试复原能力，请将故障注入应用程序，记下故障并缓解这些故障。
如果较新的版本无法正常工作，请确保策略已到位，以回滚到上一个已知的正常状态。
为有状态工作负荷创建频繁的备份，确保备份任务有效工作，并针对失败的备份过程实施警报。
监视 VM 并检测故障。 用于监视的原始数据可能来自各种源。 分析问题的原因。
确保计划的备份按预期运行，并根据需要创建定期备份。 可以使用 备份中心 获取见解。
优先使用虚拟机规模集而不是 VM 来启用缩放、自动缩放和区域冗余等功能。
优先使用Azure 市场中的标准映像，而不是需要维护的自定义映像。
根据需要，使用 Azure VM 映像生成器 或其他工具自动执行自定义映像的生成和维护过程。
除了这些特定建议之外，请根据需要为任务关键型应用程序方案的操作过程应用最佳做法。
后续步骤
查看任务关键型应用程序方案的体系结构模式：