你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
云技术的优势之一是持续改进和演变。 作为服务提供商，需要将更新应用到解决方案。 可能需要更改应用程序代码、Azure 基础结构、数据库架构或任何其他组件。 规划如何更新环境非常重要。 在多租户解决方案中，请务必明确更新策略，因为某些租户可能不愿意允许更改其环境，或者他们可能有限制可以更新其服务的条件的要求。
规划更新解决方案的策略时，需要：
- 确定租户的要求。
- 阐明自己的服务运行要求。
- 找到你和租户都可以接受的平衡。
- 将策略清楚地传达给租户和其他利益干系人。
本文为技术决策者提供有关更新租户软件的方案和所涉及权衡的指导。
你的客户要求
客户通常具有可影响系统更新方式的显式或隐式要求。 请考虑以下几个方面，以便形成对客户可能提出的任何关注点的理解：
期望和要求： 发现客户何时可以更新其解决方案的预期或要求。 这些期望或要求可能会在合同或服务级别协议中正式传达给你，也可能是非正式的。
维护时段： 了解客户是否需要服务定义的维护时段或自行定义的维护时段。 他们可能需要通知用户有关潜在的服务中断。 更新完成后，它们还可能需要测试服务的重要方面。
法规： 阐明客户是否有任何需要额外批准才能应用更新的法规问题。 例如，如果你提供包含 IoT 组件的健康解决方案，则可能需要在应用更新之前从美国食品和药物管理局（FDA）获得批准。
敏感性： 了解你的任何客户是特别敏感还是抵制应用更新。 如果是，请尝试了解原因。 例如，如果他们经营实体商店或零售网站，他们可能想要避免在黑色星期五周围更新，因为风险高于潜在利益。
历史记录：查看在不影响客户的情况下成功完成更新的跟踪记录。 应遵循良好的 DevOps、测试、部署和监视做法，以减少中断的可能性，并确保快速识别更新引入的任何问题。 如果你的客户知道你能够顺利更新其环境，他们就不太可能提出异议。
回滚： 考虑如果存在中断性变更时，客户是否愿意回滚更新，以及由谁来触发这样的回滚请求。
你的要求
你还需要从自己的角度考虑以下问题：
您愿意给予的控制： 是否合理让客户控制何时应用更新？ 如果要构建大型企业客户使用的解决方案，答案可能是是的。 然而，如果您正在构建一个面向消费者的解决方案，您不太可能让用户控制升级或操作解决方案的方式。
版本： 一次可以合理维护多少个解决方案版本？ 如果发现 bug 或安全漏洞，并且需要应用修补程序，则可能需要将其应用到当前使用的所有版本。
旧版本的后果： 让客户落后于当前版本的影响是什么？ 如果定期发布新功能，旧版本是否会很快过时？ 此外，根据升级策略和更改类型，可能需要为每个解决方案版本维护单独的基础结构。 因此，在维护对较旧版本的支持时，可能会同时产生运营和财务成本。
回滚： 您的部署策略是否支持回滚到以前的版本？ 是否要启用此功能？
注释
您是否需要考虑将您的解决方案脱机以进行更新或维护。 中断时段通常被视为软件即服务（SaaS）的过时做法。 新式 DevOps 做法和云技术使你能够在更新和维护期间避免停机。 但是，需要针对零停机时间部署进行设计。 规划解决方案体系结构时，请务必考虑更新过程。
即使未在更新过程中计划中断，仍可能定义常规维护时段。 此方法可帮助与客户沟通特定时间发生的更改。
有关如何实现零停机部署的详细信息，请参阅 通过版本控制的服务更新消除停机时间。
查找余额
如果将服务更新的节奏完全留给租户的任意裁量，他们可能会选择从不更新。 在考虑客户可能有的任何合理问题或限制情况下，重要的是要允许自己更新解决方案。 例如，如果客户对星期五的更新特别敏感，因为这是一周中最繁忙的一天，请考虑是否可以同样轻松地将更新推迟到星期一，而不会影响解决方案。
一种效果良好的方法是使用其中一种 部署策略逐个租户推出更新。 通知客户关于计划内的更新。 允许客户暂时但不能永久选择退出。在需要应用更新时，请施加合理的限制。
请考虑允许自己能够在不需要或几乎不需要提前通知的情况下，部署安全修补程序或其他关键修复程序。 确保租户了解这种做法及其在保护数据方面的重要性。
另一种方法是允许租户在选择期间启动自己的更新。 同样，你应该提供最后期限，此时你代表他们应用更新。
警告
请谨慎允许租户自行启动更新。 此过程非常复杂，需要大量的开发和测试工作才能交付和维护。
无论采用哪种方法，都请确保有一个流程可以监视租户的运行状况，尤其是在应用更新之前和之后。 关键生产事件（也称为 实时站点事件）通常在更改代码或配置后发生。 因此，必须主动监视和响应任何问题，以保持客户信心。 有关详细信息，请参阅 Azure 上的 SaaS 工作负荷的事件管理。
与客户沟通
明确的沟通是构建客户信心的关键。 请务必解释常规更新的优点，包括新功能、bug 修复、解决安全漏洞和性能改进。 现代云托管解决方案的优点之一是持续交付功能和更新。
考虑以下问题：
你会通知客户即将进行的更新吗？
如果这样做，是否通过提供选择退出过程来隐式请求权限，以及选择退出的限制是什么？
是否安排了一个在应用更新时使用的计划性维护时段？
如果有紧急更新（如关键安全修补程序）会发生什么情况？ 是否可以在这些情况下强制更新？
如果无法主动通知客户即将进行的更新，是否可以提供追溯通知？ 例如，您能否在您网站上的页面中更新您已应用的更新列表？
将在生产环境中维护多少个单独的系统版本？
与客户支持团队沟通
重要的是，你自己的支持团队能够充分了解已应用于每个租户基础结构的更新。 客户支持代表应能够轻松回答以下问题：
最近是否已将更新应用到租户的基础结构或共享组件？
这些更新的性质是什么？
以前的版本是什么？
更新应用于此租户的频率如何？
如果某个客户因更新而出现问题，则需要确保客户支持团队具有了解所更改内容所需的信息。
用于支持更新的部署策略
请考虑如何将更新部署到基础结构。 更新策略在很大程度上取决于使用的 租户模型 。 部署更新的三种常见方法是部署标记、功能标志和部署圈。 可以独立使用这些方法，也可以将它们组合在一起以满足更复杂的要求。
在所有情况下，请确保有足够的报表和可视性。 你需要知道每个租户使用的基础结构、软件或功能的版本、他们有资格迁移到哪些版本以及与这些状态相关的任何时间相关数据。 跟踪此信息通常是 控制平面的责任之一。
部署戳模式
许多多租户应用程序非常适合部署标记模式。 在此模式中，你将部署应用程序的多个副本和其他组件。 根据隔离要求，您可以为每个租户部署一个印记，或使用共享印记来运行多个租户的工作负载。
邮票是在租户之间提供隔离的好方法。 它们还提供更新过程的灵活性，因为你可以逐步跨戳记推出更新，而不会影响其他人。
功能标志
通过功能标志 ，可以将功能添加到解决方案，同时仅向部分客户或租户公开该功能。
如果以下任一方案适用于你，请考虑使用功能标志：
你定期部署更新，但希望避免显示新功能，直到它完全实现。
希望避免在客户选择加入之前应用行为更改。
可以通过自行编写代码或使用 Azure 应用配置等服务将功能标志支持嵌入应用程序。
部署圈
使用部署环可以在一组租户或部署缩放单元中逐步推出更新。 您可以将租户子集分配给发布序列中的每个环。
可以确定要创建多少个环以及每个环对你自己的解决方案意味着什么。 通常，组织会使用以下通道：
Canary：canary 通道包括您自己的测试租户以及希望在更新可用时立即获得更新的客户。 金丝雀环上的任何人应该明白，他们可能会收到更频繁的更新。 这些更新可能未像其他通道中的更新那样经过全面的验证。
早期采用者： 早期采用者群组包含租户，这些租户对风险较为谨慎，但仍愿意接收定期更新。
用户： 大多数租户属于 用户 圈，该圈接收频率较低且测试程度更高的更新。
API 版本
如果服务公开外部 API，请考虑应用的任何更新可能会影响客户或合作伙伴与平台集成的方式。 具体而言，需要注意 API 的中断性变更。 请考虑使用 API 版本控制策略 来降低 API 更新的风险。
供稿人
Microsoft维护本文。 以下参与者撰写了本文。
主要作者：
- John Downs |Azure 模式和做法的主要软件工程师
其他参与者：
- 查德·基特尔 |Azure 模式和做法的主要软件工程师
- 丹尼尔·斯科特-伦斯福德|高级合作伙伴技术解决方案顾问
- 阿森·弗拉基米尔斯基 | 客户首席工程师，FastTrack for Azure
若要查看非公开的LinkedIn个人资料，请登录LinkedIn。