你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 上 SaaS 工作负载的 DevOps 做法
DevOps 做法对于管理 Azure 上的工作负载而言是不可或缺的，尤其是 SaaS 应用程序。 关键方面包括载入、卸载和修改客户实例。 这些做法不仅简化了操作，而且还提高了可伸缩性和可靠性，最大限度地减少了中断的可能性。
本文介绍高效客户生命周期管理和安全部署实践的设计注意事项。
管理客户生命周期
管理 客户生命周期事件 对于任何 SaaS 应用程序都至关重要。 通常，这些事件包括：
- 载入：客户注册时。
- 更改：修改客户的实例，例如更改其定价层。
- 卸载：当客户取消其帐户时。
可能会遇到其他生命周期事件。 例如，你可能允许客户暂停其订阅，同时保留其数据一段时间，并在以后恢复其订阅。 每个事件都可以对应用程序产生独特的影响。
在某些解决方案中，客户生命周期管理可能只需要在数据库表中创建或管理数据。 对于其他解决方案，它可能涉及协调 Azure 基础结构、应用程序代码和更复杂的配置部署。
生命周期管理是 SaaS 解决方案控制平面的关键责任。 最初，你的团队可能会手动处理这些活动，但随着时间的推移，请尝试将更多功能转换为正式的控制平面解决方案或应用程序。
设计注意事项
一致性。 规划生命周期管理策略时，请考虑每个客户生命周期事件所需的操作的复杂性。 这包括解决方案、客户群和组织开销的大小。 确保清楚地了解每个事件的必要步骤，并投入控制来保持一致性。 定期查看和更新你的流程，以帮助确保它们随着解决方案的发展而保持有效。
租赁模型。 处理客户生命周期事件的方法取决于租户模型。
- 具有基础结构资源的完全多租户解决方案。 载入或卸载客户通常涉及更新应用程序数据存储中的客户列表和关联数据。
- 每个客户的专用资源。 这些任务通常涉及启动到 Azure 的部署、监视进度和处理部署失败，这可能需要人工干预。
- 客户部署的资源。 可能需要直接与客户的工程团队进行界面，以便加入或卸载。
层。 请考虑定价模型和每个层的不同基础结构需求，尤其是在允许客户随时自由更改其 SKU 时。
- 例如，如果 SaaS 解决方案包含一个核心应用程序和多个付费加载项模块，请确保核心应用的资源在载入期间部署。 此外，允许动态添加和删除加载项模块。 删除模块后，决定是删除关联的数据还是存储它，以便进行可能的重新激活。
设计建议
| 建议 | 好处 |
|---|---|
| 记录每种类型的客户生命周期事件。 确保捕获每个事件的进程的分步详细信息。 |
通过了解事件，可以规划如何响应解决方案设计中的每个事件。 明确的说明有助于人工操作员保持一致性，并充当未来自动化的基础。 |
| 为每个生命周期事件传达你和你的客户之间的共同责任。 明确和提前地传达你期望客户执行的操作，以便完成生命周期阶段。 | 你可以减少因错误沟通而导致的潜在错误和客户挫折感。 |
| 为每个生命周期事件执行容量规划。 例如，在载入新客户时，如果现有实例没有足够的容量来处理额外负载，计划部署应用程序的新实例。 有关详细信息，请参阅 Azure 上 SaaS 工作负荷的计费和成本管理。 |
你可以支持更轻松地缩放并避免部署失败。 |
| 在实际情况下自动执行生命周期事件。 对于低容量或早期解决方案，手动部署和配置可能已足够，但仍应使用脚本，即使工程师每次发生生命周期事件时都会运行这些脚本。 随着解决方案的成熟，将这些职责集成到完全控制平面中，以减少人为错误并支持更高的规模。 |
可以降低人为错误的重大风险，并支持更高的规模。 |
规划基础结构管理策略
尽早制定部署、维护和管理 Azure 基础结构的策略。 缩放 SaaS 时，资源数量会增加。 从一开始就遵循管理策略比以后协调基础结构变得太复杂而无法手动处理时，更容易遵循管理策略。
设计注意事项
客户资源管理。 租户模型会影响 SaaS 解决方案中的资源部署。 可以为每个客户部署专用 Azure 资源，或者在一组客户之间共享资源。 或者，可以使用一组共享资源，在载入新客户时重新配置它们。 管理资源的生命周期的常见方法：
- 将客户列表视为要部署的资源的配置。 使用集中式部署管道来部署和配置这些资源。
- 将客户列表视为数据。 使用控制平面应用程序预配和配置基础结构。
基础结构自动化。 许多组织首先通过 Azure 门户 手动部署云基础结构，这最初很容易，但规模不佳。 计划使用基础结构即代码（IaC）工具（如 Bicep 或 Terraform）自动完成基础结构设置。 对于更复杂的要求，请创建直接使用 Azure 资源管理器 API 的控制平面。
基础结构归属。 跟踪哪些客户部署在哪个基础结构上。 跟踪对于准确的容量规划和成本归因非常重要。 可以在客户数据库中集中跟踪客户基础结构，或者，对于专用基础结构，可将 Azure 资源元数据与特定于客户的资源组和资源标记一起使用。 有关详细信息，请参阅 SaaS 工作负载的资源组织。
设计建议
| 建议 | 好处 |
|---|---|
| 使用团队熟悉的工具使用部署管道、脚本或模板生成基础结构自动化。 | 使用已知工具可降低错误风险，因为如果不了解这些工具，基础结构自动化可能会造成中断。 |
| 尽可能使用 IaC 部署基础结构。 | 随着基础结构数量的增长，手动维护基础结构变得更加危险和更负担。 |
| 将核心基础结构与客户级基础结构分开。 | 不同类型的基础结构具有不同的生命周期和管理活动。 通过分隔这些设置，可以单独按自己的计划管理每个集。 |
| 使用 Azure 托管应用程序部署和管理客户部署的资源。 | Azure 托管应用程序提供一系列功能，使你能够在客户的 Azure 订阅中部署和管理资源。 |
规划应用程序部署
定期更新应用程序代码和配置以增强功能。 客户期望在更新和安全推出期间保持一致的运行时间，以最大程度地降低中断的风险。
设计注意事项
标准化工具和流程。 行业认可的 DevOps 工具可确保在管理应用程序部署的流程中跨函数和成熟度保持一致性。 在大多数情况下，开发自己的工具被视为反模式。
权衡：复杂性和成本。 使用熟悉的 DevOps 工具在金钱和技能方面可以经济高效。 但是，它增加了单独管理每个工具的操作负担。 请务必保持对可能使工作负荷受益的新技术创新持开放性。逐步部署更新。 一次向一部分客户推出更新，将用户划分为逻辑分组。 对配置更改应用相同的严格性，因为它们可以更改代码行为并导致中断。 请遵循这些更改的部署过程。
采用版本控制策略。 允许客户选择其应用程序版本会增加灵活性，但使操作复杂化。 为弃用旧版本设定明确的预期，并概述不再支持旧版本时会发生什么情况。
自动化。 由于人为错误和缺乏一致性，手动部署容易产生风险。 即使手动触发部署，部署过程也应尽可能自动化，并且需要最少人工干预。 考虑部署过程的步骤以及如何最好地自动执行这些步骤。
测试。 通过运行以下操作将测试集成到部署过程中：
- 代码生成期间的单元测试
- 部署后集成测试
- 常规性能测试
- 常规安全和渗透测试
确定在任何阶段测试失败时要执行的操作。
部署失败。 通过考虑必要的操作和准备回滚策略来规划部署失败。
访问客户环境。 如果将资源部署到客户环境中，请了解如何在这些环境中应用更新。 考虑 Azure 托管应用程序提供的功能，例如 将更新部署到应用程序。
设计建议
| 建议 | 好处 |
|---|---|
| 使用经过行业证明的 DevOps 工具和流程来管理应用程序部署。 在大多数情况下，开发自己的工具被视为反模式。 有关详细信息，请参阅 OE：03 软件开发实践 |
无需学习自定义生成工具，即可确保工程团队能够有效地部署。 |
| 主动通知客户任何即将或已完成的部署。 | 可以确保客户就应用程序发生的更改设置适当的预期。 |
| 采用安全部署做法，使用渐进式曝光、运行状况模型等策略将更新部署到客户组。 在迁移到更重要的客户之前，先从不太敏感或早期采用者开始。 有关详细信息，请参阅安全部署做法建议。 |
此方法有助于在影响所有客户之前识别问题。 |
| 将配置视为代码。 | 可以降低停机时间的可能性，并为生产更改采用一致的流程。 这可实现集中的操作职责，例如测试更改并逐步推出配置和代码更新。 |
| 定义更改管理过程并传达版本更新策略，以确保客户知道谁触发更新、其频率和条件。 如果允许客户选择其应用程序版本，请为弃用旧版本设置明确的准则。 最大程度地减少生产中运行的应用程序版本数。 |
维护旧版本会导致操作效率低下。 通过设置明确的期望和策略，为客户提供必要的控制，同时避免过度负担团队。 |
| 避免为单个客户自定义应用程序。 若要支持不同的客户需求，可以创建解决方案的各个层，或使用功能标志为某些用户启用特定功能。 |
避免将哪些功能部署到哪个版本中存在歧义，并减少维护负担。 |
| 为失败的部署制定回滚计划，包括触发条件和必要的审批。 | 回滚计划有助于确保即使在不可预见的情况下也能从部署错误中恢复。 |
| 在软件开发过程中的多个阶段定期测试应用程序。 采用“Shift-left”思维模式，在生命周期早期捕获 bug 和偏差。 | 帮助防止严重错误影响客户。 |
其他资源
多租户是设计 SaaS 工作负载的核心业务方法。 以下文章提供有关采用 DevOps 做法的详细信息：
下一步
了解有关实现支持 Azure 上的 SaaS 解决方案的进程和工具的事件管理注意事项。