通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

更新多租户解决方案时的注意事项

  • 项目

云技术的优势之一是可以不断改善和演进。 作为服务提供商，你需要对解决方案应用更新：可能需要对 Azure 基础结构、代码/应用程序、数据库架构或任何其他组件进行更改。 规划如何更新环境非常重要。 在多租户解决方案中，明确规定更新策略尤为重要，因为某些租户可能不太情愿允许对其环境进行更改，或者其要求可能会限制更新其服务的条件。

计划更新解决方案的策略时，需要：

  • 确定租户的要求。
  • 阐明自己的服务运行要求。
  • 找到你和租户都可以接受的平衡点。
  • 向租户和其他利益干系人清楚地传达策略。

本文为技术决策者提供有关可以考虑的租户软件更新方法，以及这些方法的利弊的指导。

客户的要求

考虑以下问题：

  • 期望和要求：客户是否在更新时间方面有期望或要求？ 他们可能会以合同或服务级别协议的形式或者非正式形式向你传达这些期望/要求。
  • 维护时段：客户是否在服务定义的甚至自我定义的维护时段方面有期望？ 他们可能需要与他们自己的客户在任何可能的服务中断方面进行沟通。
  • 法规：客户是否有任何监管方面的忧虑，需要在经得额外批准后才能应用更新？ 例如，如果你提供一款包含 IoT 组件的医疗保健解决方案，可能需要在应用更新之前获得美国食品和药物管理局 (FDA) 的批准。
  • 敏感性：是否有任何客户对应用的更新特别敏感或抗拒？ 请设法了解原因。 例如，如果他们经营实体店或零售网站，他们可能希望避免在黑色星期五前后更新，因为风险高于潜在收益。
  • 历史记录：在不影响客户的情况下成功完成更新的跟踪记录表现如何？ 应该遵循良好的 DevOps、测试、部署和监视做法，以减少服务中断的可能性，并确保快速识别更新造成的任何问题。 如果客户知道你能够顺利更新其环境，则他们就不太可能反对。
  • 回滚：如果发生中断性变更，客户是否想要回滚更新？

你的要求

你还需要从自己的立场考虑以下问题：

  • 愿意提供的控制权限：客户是否合理地控制应用更新的时间？ 如果你正在构建一个由大型企业客户使用的解决方案，答案可能为“是”。 但是，如果你正在构建一个以消费者为中心的解决方案，则你不太可能会让客户来控制解决方案的升级或操作方式。
  • 版本：一次可以合理地维护多少个解决方案版本？ 请记住，如果你发现 bug 并需要对其进行修补，则可能需要将修补程序应用于所有正在使用的版本。
  • 使用旧版本的后果：让客户远远落后于当前版本会有怎样的影响？ 如果你定期发布新功能，旧版本是否会很快过时？ 此外，根据升级策略和更改类型，可能需要为解决方案的每个版本保留独立的基础结构。 因此，在保持对旧版本的支持时，可能会产生运营和财务成本。
  • 回滚：部署策略是否支持回滚到以前的版本？ 这是你想要启用的功能吗？

注意

考虑在更新或维护时是否需要将解决方案脱机。 一般情况下，服务中断时段被视为一种过时的做法，新式 DevOps 做法和云技术使你能够避免在更新和维护期间出现停机。 但是需要针对零停机时间部署进行设计，因此在计划解决方案体系结构时考虑更新过程非常重要。

即使不为更新过程中的中断做好规划，也可以考虑定义常规维护时段。 维护时段有助于向客户告知更改会在特定时段内进行。

有关实现零停机时间部署的详细信息，请参阅通过版本受控的服务更新消除停机时间。

找到平衡点

如果完全由租户自行确定服务更新的步调，他们可能会选择永不更新。 重要的一点是，要允许你自己更新自己的解决方案，同时考虑到客户可能存在的任何合理顾虑或不便之处。 例如，如果客户对星期五进行的更新特别敏感（因为那是他们一周中最忙碌的一天），那么，是否可以方便地将更新推迟到星期一，且不会影响你的解决方案？

一种行之有效的方法是使用下述方法之一逐个地为租户推出更新。 将计划的更新通知客户。 允许客户暂时选择不更新，但不能永久不更新；对何时需要应用更新规定合理的限制。

此外，考虑允许你自己部署安全修补程序或其他关键修补程序，只发出极少量的提前通知甚至不发出通知。

另一种方法是允许租户在他们所选的时间自我启动更新。 同样，应该提供一个截止日期，届时你将代表他们应用更新。

警告

谨慎允许租户自我启动更新。 这种方法很难实现，它需要付出大量的开发和测试工作来交付和维护更新。

无论采用哪种方法，都请确保有一个流程可以监视租户的运行状况，尤其是在应用更新之前和之后。 通常，关键生产事件（也称为现场事件）发生在代码或配置更新之后。 因此，必须主动监视和响应任何问题以保持客户的信心。 有关监视的详细信息，请参阅 DevOps 的监视。

与客户沟通

清晰的沟通是建立客户信心的关键所在。 解释定期更新的好处非常重要，包括新增功能、bug 修复、解决安全漏洞和性能改进。 新式云托管解决方案的优势之一是持续交付功能和更新。

考虑以下问题：

  • 你是否会通知客户即将进行更新？
  • 如果是，你是否会通过提供选择不更新的过程来隐式请求权限，选择不更新的限制又是什么？
  • 是否安排了一个在应用更新时使用的计划性维护时段？
  • 如果有紧急更新（例如关键的安全修补程序），该怎么做？ 在这种情况下是否可以强制更新？
  • 如果无法主动通知客户即将进行的更新，是否可以提供追溯通知？ 例如，是否可以更新网站上的页面并在其中列出已应用的更新？
  • 在生产环境中将维护多少个单独的系统版本？

与客户支持团队沟通

重要的一点是，你自己的支持团队必须完全了解已应用于每个租户的更新。 客户支持代表应该能够轻松回答以下问题：

  • 最近是否已将更新应用于租户的基础结构？
  • 这些更新的性质是什么？
  • 前一版本是什么？
  • 为此租户应用更新的频率如何？

如果某个客户因为更新而遇到问题，你需要确保客户支持团队取得了必要的信息，可以了解哪些方面发生了变化。

支持更新的部署策略

考虑如何将更新部署到基础结构。 这在很大程度上受到所用租户模型的影响。 部署更新的三种常用方式是部署缩放单元、功能标志和部署环。 可以单独使用这些方法，也可以将它们组合在一起以满足更复杂的要求。

在所有情况下，都请确保具有足够的报告和可见数据，以便了解每个租户正在使用哪个基础结构、软件或功能版本，他们可以迁移到哪个版本，以及与这些状态关联的任何时间相关数据。

部署戳模式

许多多租户应用程序非常适合采用部署缩放单元模式，在模式下可以部署应用程序和其他组件的多个副本。 根据隔离要求，可为每个租户部署一个缩放单元，或者部署运行多个租户工作负载的共享缩放单元。

缩放单元是在租户之间提供隔离的极好方式。 它们还为更新过程提供灵活性，因为你可以跨缩放单元逐步推出更新，而不会影响其他租户。

特性标志

使用功能标志可以向解决方案添加功能，同时只向一部分客户或租户公开该功能。

若处于以下任一情况下，请考虑使用功能标志：

  • 定期部署更新，但希望在完全实现新功能之前避免显示新功能。
  • 希望在客户选择加入之前避免应用行为产生更改。

你可以通过自行编写代码或使用 Azure 应用程序配置等服务将功能标志支持嵌入到应用程序中。

部署环

使用部署环可以在一组租户或部署缩放单元中逐步推出更新。 可将一部分租户分配到每个环。

可以确定要创建的通道数，以及每个通道对自己的解决方案的作用。 通常，组织会使用以下通道：

  • Canary：canary 通道包括你自己的测试租户以及希望在更新可用时立即应用更新的客户，他们知道可能会收到更频繁的更新，并且更新可能没有通过像其他地方一样全面的验证过程。
  • 早期采用者：早期采用者通道包含风险厌恶程度略高，但仍已准备好接收定期更新的租户。
  • 用户：大多数租户属于用户通道，该通道接收不太频繁的且经过严格测试的更新。

API 版本

如果你的服务公开外部 API，请考虑应用的任何更新是否影响客户或合作伙伴与平台集成的方式。 具体而言，需要注意 API 的中断性变更。 考虑使用 API 版本控制策略来缓解 API 更新带来的风险。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

  • John Downs | FastTrack for Azure 首席客户工程师

其他参与者：

若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

后续步骤