SaaS 之旅：Dynamics 365

许多独立软件供应商（ISV）考虑从本地软件交付迁移到基于云的软件即服务（SaaS）交付模型。 在 Microsoft，我们许多产品经历了这一旅程，而我们经常被要求分享我们的实际经验和在这个过程中学到的关键教训。

本文的目标是概述我们在构建 Microsoft Dynamics 365 的过程中如何展开这段旅程。 我们描述了我们经历的思维过程，以及我们做出的每个重大决策的关键驱动因素。 我们希望本文档提供产品演变的感觉，因为我们从交付本地软件转移到数千个组织中数百万用户使用的超大规模 SaaS 产品。 我们希望通过阅读本文档，可以从我们的经验中学习，并规划自己的 SaaS 之旅。 虽然 Microsoft 在 Dynamics 365 上的旅程可能是独特的，但我们相信，我们学到的教训和原则仍可以为任何规模的组织在计划过渡到 SaaS 模型时提供有价值的见解。

我们旅程的简短历史

Microsoft Dynamics 作为一组本地产品有着深厚的历史。 我们采用云来获得它提供的所有好处，我们知道，随着我们向 SaaS 提供，我们的技术和业务模型需要适应。

我们面临的第一个决定是选择将新应用程序或将本地应用程序演变为云服务。 对于 Dynamics 365，我们相信有两件事。 首先，我们在与成千上万的客户一起创建和验证的数据模型和业务逻辑中具有足够的价值，以至于值得改进现有的解决方案。 其次，本地产品的分层体系结构和平台框架提供了正确的杠杆，使我们能够比从头开始更快地采用出色的云体系结构。 结合了价值与速度，并理解我们可以采用云原生原则，这使得迁移到基于云的 SaaS 以及在 Dynamics 365 中持续改进成为了正确的选择。 其他组织可能具有不同的优先级，并采用不同的策略。

早些时候，我们决定专注于构建可在 Microsoft Azure 平台上构建的最佳产品。 云平台快速改进，我们希望利用一个平台的丰富性，而不是将资源分散到多个云中。 其他 SaaS 供应商可能会根据自己的情况做出不同的决策。 例如，水平平台提供商可能会生成软件供客户跨多个云使用，因此他们在每个云平台上都有一个存在是有意义的。 但是，SaaS 应用程序开发人员可以选择专注于一个云，并受益于专注于该云提供商及其演变。 对于 Dynamics 365，我们知道，全面投入使用 Microsoft Azure 将使我们获得更集成、更无缝的体验，同时保持可靠的安全性和高性能。

当我们开始深入探索 Azure 平台并规划 SaaS 旅程时，我们了解了如何在云中运营和缩放大规模的企业资源规划（ERP）平台。 同时，Azure 变得更加丰富和更有能力，它引入了我们无法想象的新功能。 我们知道云的不断演变意味着我们的迁移不会是一次性的事情。 相反，我们在旅程的每一步都考虑了持续改进。 持续改进会影响我们所做的一切，在我们的旅程的早期阶段，我们必须做出重大更改-从整体体系结构到如何处理数据库查询。 我们正在不断改进解决方案，充分利用云的功能。 我们接受了微服务体系结构，并将生成 AI 用作持续演变的一部分。 使用功能强大的云平台（如 Microsoft Azure）时，这些方法和技术更易于生成、部署和作。

云中持续改进的基本要素是遥测。 通过有效的遥测技术，可以了解应用程序的使用情况和性能，甚至可以深入到各个功能级别。 遥测提供见解，通过了解所发生的情况，而不是遵循传统的本地方法（例如重现问题和调试）来解决问题。 遥测还允许你根据实际数据做出工程决策，并通过试验和数据确认产品假设。 创建遥测基础设施 及处理保留哪些数据、保留多长时间以及如何管理这些数据的正确策略，是需要尽早完成的任务。

在 SaaS 旅程中，还需要额外关注了解应用程序管理的数据的数据分类和保留策略。 作为 SaaS 提供商，根据当前和新兴的数据隐私法，你的责任不同于你提供客户部署和运行自己的软件时的责任。 了解作为 SaaS 提供商适用的数据隐私法规至关重要。 还需要在云旅程开始时完成数据分类和保留过程。

我们如何为旅程做好准备

界定 MVP 的范围

我们的策略侧重于构建最小可行产品（MVP），以便我们可以尽快为客户提供解决方案，并开始了解 SaaS 的独特挑战和机会。 这一焦点是一个战略选择。 我们相信，快速学习和迭代在云中至关重要，定义 MVP 是一个开始的地方。

术语 最小可行产品 经常被误解。 请务必考虑 MVP 的这两个属性同样重要：

• 最低：找出开始为客户生成价值的最快方法。 客户使用解决方案越早，你越早就开始了解他们如何使用它，以及如何继续改进解决方案。
• 可行：必须使产品的范围足够完整，以便他人从中获取实际价值。 最初，选择预期要生成的整体功能的子集。 选择正确的子集非常重要。如果子集太小，不可行，那么客户就不会使用该产品，你就不会获得改进需要的反馈。

对于 Dynamics 365，我们专注于打造一款产品，使客户能够从发布之初就开始使用。 然后，我们了解了客户如何从中获取价值，并获得了大量的反馈和遥测数据。 我们利用这些数据来指导产品开发路径，在开发过程中不断迭代、逐步改进。

我们的策略是构建一个新客户喜欢的产品。 虽然我们有意简化从现有本地客户的迁移，但与构建出色的现代产品相比，迁移是一个次要重点。 此策略意味着我们的新客户从一开始就在 Dynamics 365 中拥有完整的体验。 他们还给我们提供了宝贵的反馈，他们这样做的好处是用新鲜的视角来审视问题。 他们尚未大量投资于本地 Dynamics 产品，因此它们帮助我们构建真正是云原生产品，并提供了完整的 SaaS 产品。 随着我们继续改进和扩展功能，我们最终达到了功能集是本地产品的超集的程度。 此时，我们可以开始支持现有客户从本地版本过渡到更高级的 Dynamics 365。

我们自觉选择了此策略，因为我们知道它适用于 ERP 系统。 在其他产品中，可以先选取产品的一部分功能以先移动，然后随着时间的推移添加更多功能。 但在 ERP 中，组件紧密相连。 在所有这些组件之间形成一系列功能，并为客户提供有用的端到端体验之前，产品不会真正有用。 MVP 范围是每个组件中的一个水平特征切片。 我们决定选择一组跨领域功能，以支持新客户的用例：

对于其他解决方案，最好改为将 MVP 范围限定为整个组件。 在开始自己的 SaaS 旅程时，请务必就你遵循的策略做出有意识的决定。 关键是，初始可交付结果应该尽可能小，同时仍然足够完整，以获得实际使用。

在我们计划和改进中，我们始终记住客户的期望也在不断发展。 与其直接迁移当前状态的产品，我们更倾向于规划当产品准备好时客户会需要的东西。 与云迁移一起的 SaaS 之旅通常是一项长期工作，需要数月甚至数年的时间。 在此期间，不要忽视客户需求的变化。 否则，您可能会在产品最终到达时花费大量精力去开发无法完全满足客户需求的东西。

使用情况、客户满意度和成本

本地软件收入通常在销售交易发生时得到认可，成功部署和采用的责任取决于客户。 使用云 SaaS 订阅模型，客户通常先许可几个席位，只有在解决方案得到证实后才能扩展其订阅。 他们购买但不使用的任何座位都是有风险的，因为它们可能会在下一个订阅周年纪念日取消。 因此，随着 SaaS 的转换，我们更改了用于推动业务的首要指标。

在本地许可软件世界中，主要重点是收入。 在云中，重点是使用情况和客户满意度。 这些指标成为收入和收入增长的前向指标。 我们花费了大量精力来最大程度地减少成功部署的时间，提供已购买但未使用的许可证的可见性，并在整个用户和业务角色中保持较高的满意度。 从一开始，我们的重点是创建客户喜欢使用的产品。 我们从经验中知道，当客户从使用产品中获得价值时，收入随之而来。 通过优先考虑客户体验和使用情况，我们为成功的业务策略奠定了基础。

构建 SaaS 时，销售的商品成本（COGS）很重要，尤其是在规模和成本增长时。 但最好先确定满意度和使用情况的优先级。 如果提供良好的客户体验，可以通过更高效地利用资源并利用新的平台功能来优化提供服务的成本。 如果体验不够好，使用频率会降低，并且客户数量会减少。 因此，当我们回顾进度时，我们将重点关注三个关键绩效指标，按重要性顺序排列：

• 客户满意度：我们的客户是否喜欢使用该产品的体验？ 他们的反馈是什么？
• 使用情况：我们有多少用户？ 我们有多少个订阅？ 我们的使用情况是否正在加速？ 购买和使用之间的时间是多少？ 如何鼓励客户使用他们购买的所有订阅？
• COGS：为客户提供服务的费用是多少？

考虑任何 SaaS 产品如何产生收入也很重要。 客户需要了解他们如何为服务付费，并且定价模型需要对他们有意义。 在许多企业到企业 SaaS 解决方案中，客户拥有的用户数是用户使用系统时消耗的资源的一大指标。 主动使用系统的用户越多，需要更多的系统资源来为他们提供良好的体验。 客户的成本反映了这一事实。 客户对基于用户的定价结构有直观的了解。

但是，在某些情况下，用户计数不会很好地指示客户使用的资源。 例如，当客户的营销团队为电子邮件市场活动发送大量邮件时，可能只有一个用户发送数百万封电子邮件。 同样，后台进程（而不是用户）导入订单详细信息。 客户必须了解其计费指标，并可以预测其账单。 可以选择使用计量表，例如他们发送电子邮件的联系人数或每月处理的订单行数。

Dynamics 365 的体系结构

标识、身份验证和授权

Dynamics 365 等业务应用程序管理高价值业务数据，并自动执行任务关键型业务流程。 必须确保只有经过授权的用户有权访问数据和系统作。 通过使用 Microsoft Entra ID，企业可以使用已在 IT 资产中使用的相同工具和平台来管理对 Dynamics 365 的访问。 客户可以利用高级安全功能，例如条件访问，而无需在我们的方面进行更多工作。 Microsoft 持续在 Entra 平台进行投资，以不断增强其保护 Dynamics 系统的功能。

Dynamics 365 向用户分配角色，并为这些角色分配特定数据和作的权限。 此方法遵循在 Entra 提供的用户身份验证之外管理授权的常见模式。 此方法还提供 Dynamics 365 强制实施最佳做法业务要求（如职责分离）的功能。

租赁模型

使用 Dynamics 365 的每个组织都希望其数据保持安全，并使其与其他组织的访问隔离。 我们将每个组织建模为 租户，每个租户都有许多用户，每个用户都可以使用产品并处理组织的数据。 共享资源可降低运行服务的成本组件，但必须根据要求平衡共享，以确保租户隔离的预期级别。 幸运的是，Azure 平台提供了丰富的功能，使应用程序提供商能够在提供所需的隔离时平衡成本。

例如，我们认为将每个租户的业务数据保存在单独的 SQL 数据库中非常重要。 这种分离让我们能够在其他能力之中，实现通过客户管理的密钥来启用 Azure SQL 透明数据加密（TDE），这是我们在数据方面作出的企业信任承诺的重要组成部分。 Azure SQL（尤其是弹性池）为我们提供成本效益的解决方案，同时仍允许为每个客户提供单独的数据库。 除了增加基础结构成本外，决定为每个租户保留单独的数据库会增加管理复杂性。 没有足够的数据库管理员（DBA）在 Dynamics 服务的规模上手动管理数据库，这导致对管理任务的自动化进行大量投资。 有关 Dynamics 365 如何大规模处理数据库的详细信息，请参阅 在 Azure SQL 上运行 100 万个大型 SaaS 提供程序的数据库：Microsoft Dynamics 365 和 Power Platform。

对于我们解决方案的每个层级，我们的策略一直是利用 Azure 平台的本机功能来强制实施租户隔离， 提供扩展性和复原能力，并在可能的情况下提升成本效率。 我们一直在研究可以优化系统的位置，同时优先考虑租户安全性并提供出色的客户体验。

部署标记

Dynamics 365 以超大规模方式运行。 有数十万个客户，有数百万用户，每个客户取决于我们的产品。 随着时间推移，这些数字继续增长。 SaaS 解决方案通常需要设计成可扩展的，并且需要支持全球客户。

在云中，必须尽可能从纵向扩展转向横向扩展。 如果可以通过添加更多节点（横向扩展）来满足额外的需求，而不是使现有节点更强大（纵向扩展），并且这种关系接近线性，则基于横向扩展的方法提供了推动更高缩放的潜力。 Dynamics 365 在应用程序层使用横向扩展模型。 集成监视可检测特定租户的负载增加，并添加更多节点来满足需求。

结合租户模型和横向扩展体系结构，可以遵循部署缩放单元模式，每个标记都支持一组客户。 当缩放单元接近其最大容量时，可以预配新缩放单元并开始在那里部署新客户。 通过使用邮票，可以支持持续的客户增长，并且可以将区域影响力扩展到新的地理位置。

通过使用部署标记，还可以获得可靠性优势。 你可以逐步推出我们的更新，安全部署过程可帮助你逐步在整个全球车队中推出更改。 每个邮票独立于其他邮票，因此，如果邮票遇到问题，则只影响分配给该邮票的客户子集。 缩放单元可帮助减少问题或故障的爆炸范围，并有助于制定总体灾难恢复策略。

与所有架构决策一样，应根据业务需求使用部署标记。 部署印章需要部署一组基础结构来支持它。 如果邮票的最小尺寸过大，很难证明将新邮票部署到新市场是合理的，因为你需要首先达到足够数量的客户。 了解客户增长如何影响客户对产品的使用也很重要，因为随着产品的增长，他们会使用更多的缩放单元资源。 这些注意事项对于小型 ISV 来说同样重要，因为它们适用于超大规模平台（如 Dynamics 365）。

控制平面和配置

当 ISV 迁移到基于云的 SaaS 交付模型时，最显著的变化之一是他们负责该服务的运行。 在大多数本地软件中，客户的 IT 部门负责部署、配置和管理系统。 客户自己负责监视系统，并决定何时推出更新。 他们还负责执行所涉及的所有步骤。 专家服务集成合作伙伴通常可帮助客户在其环境中运行复杂的产品。 通过迁移到云和 SaaS 模型，软件提供商负责其所有客户的所有这些活动。 转换到 SaaS 后，必须构建 ISV 的服务，以及 控制平面 来自动完成载入和管理租户的工作。 控制平面和自动化非常重要，即使客户数量相对较小。

设计可复原、可靠且高度可用的控制平面是很好的做法。 控制平面通常被视为在构建 SaaS 产品的过程中的事后考虑。 但是，如果控制平面的设计与产品的其余部分不一样，你会面临它成为单一故障点的风险。 如果不适当注意控制平面的复原能力，控制平面故障可能会影响所有客户。

在 Dynamics 365 中，我们有一个服务级别的控制平面，用于处理载入新租户等操作。 我们还具有租户级控制平面，使客户的管理团队能够启动维护活动并自行更改配置，因为它们可以通过服务执行这些作。

自定义和扩展性

SaaS 模型的核心价值主张是，所有客户都运行服务代码的一个版本。 当客户运行服务代码的一个版本时，问题会识别并修复一次，并且所有客户都可以快速获得这些解决方案的好处。 目标是能够持续改进服务的一个版本，而无需客户计划测试和部署更新。

为了实现此优势，与在本地环境中运行软件相比，需要进行许多更改。 例如，你需要规划流程和过程，以减少回归的可能性。

在 Dynamics 365 转换中，我们投资的一个领域是开发丰富的模型驱动可扩展性。 ERP 应用程序需要扩展性，以支持与其他关键业务系统的集成，并满足特定客户的独特功能需求。 我们引入了通过特定于租户的元数据扩展数据模型的功能，而不是在源代码级别进行自定义，而是基于系统中发生的事件触发扩展逻辑。

我们添加了隔离和治理能力，以保护服务和其他租户免受另一租户扩展的业务逻辑中的问题。 我们的方法为客户提供了所需的扩展性级别，但使它们仍可以使用同一产品版本运行。 此外，更新可以交付给产品，而无需客户合并更改并重新生成其代码，使其扩展适用于较新版本的产品。

自定义可能不是每个产品的要求，但如果某个产品确实需要自定义，则自定义将成为关键设计因素。 必须满足要求，而不会损害 SaaS 模型的核心优势。 此要求是 Dynamics 365 的重要焦点。 模型驱动的扩展性既保留了 SaaS 价值主张，又提高了客户创建和维护扩展的能力。

我们如何设计 Dynamics 365 以增强弹性

在 Azure 上考虑部署模型时，如果依赖服务中出现问题（例如网络问题、电源问题或虚拟机维护），需要考虑的关键组件是复原能力。 在本地环境中，基础结构为单个客户租户提供服务，许多客户依赖于每个基础结构组件的高可用性策略。 但是，在云规模上考虑复原能力时，通常需要高可用性，但还不够。 有了足够的规模，就会出现故障。

Dynamics 365 的核心重点领域是跨 Azure 可用性区域实现冗余，以允许任务关键型 Dynamics 服务无缝继续运行，即使中断影响数据中心或整个可用性区域也是如此。

若要将此思维模式应用于自己的解决方案，需要遵循一些重要的做法。

• 请确保投资监视工具来快速识别问题。 借助 SaaS，你的客户希望了解中断情况，并快速参与还原服务。
• 如果适合你的服务，请使用平台功能，例如可用性区域和区域冗余。
• 设计应用程序以在每一层实现弹性。 例如，考虑其他云最佳做法也很重要，例如使用重试、断路器和散装机，以及采用异步通信做法。 即使依赖的其他服务承受压力，这些做法也能使服务保持正常运行。
• 请考虑控制平面的可用性，尤其是因为在基础结构资产受到影响时，它在解决方案的恢复中发挥作用。
• 实现复原能力的功能后，请运行测试。 在尝试使用计划和功能之前，你永远不知道你的计划和功能是否已完成。 作为正常维护活动的一部分，可以练习故障转移过程，这既能为你提供维护方法，又无需停机，还可以验证故障转移机制。

可靠性原则是 Azure Well-Architected 框架 的一部分，提供了有关这些主题的出色指导。

我们如何适应云环境

Dynamics 365 已演变为复杂的云原生体系结构，但 ISV 通常会从本地环境向云进行更有限的直接迁移。 我们讨论了 定义 MVP 模型，以便快速将 SaaS 服务掌握在客户手中，从而开始学习和持续改进的周期。 但有一个平衡点。 直接迁移应该真正提升、转移和适应。

本文前面介绍了设计可用性区域和其他云最佳做法的复原能力。 还有其他一些领域，常见的本地设计模式也会导致云中的挑战或更高的成本。 例如，在本地应用程序中，通常将二进制大型对象存储在关系数据库中。 例如，可以将与销售订单相关的 PDF 文档存储为 SQL 数据库中销售订单的一部分。 在本地环境中，此方法简化了备份和时间点还原功能之间的一致性。 但是，在云中，存储在数据库中的大型对象的成本可能很高。 此外，Azure 存储 blob 简化了存储大型二进制对象的过程，需要简单的逻辑来保留一致的备份。

请务必考虑在云转换过程中需要执行的操作。 应该执行那些生成更强大的云产品的事情。 但是，你也应该利用这一机会快速进入市场，并开始学习和持续改进的良性循环。

云还可以使全新的解决方案变得实用，这在本地环境中不是一个选项。 ERP 系统中最性能密集的流程之一是制造资源规划，或 MRP II。 MRP II 正在查看库存、预期的传入和传出订单以及制造要求。 然后，它确定企业必须购买或做出什么以满足预期订单。 在本地 Dynamics 中，此功能是在直接针对关系存储运行的应用程序代码中实现的。 规划函数消耗了大量系统容量，并长时间运行。 在第一个云版本中，本地功能被原封不动地引入——虽然它能正常运行，但仍面临同样的规模和性能挑战。 然后，几年前，我们引入了一个新的内存中微服务，该微服务可以在一小部分时间内完成相同的计划运行，而不会造成性能影响。 重要的是，由于微服务是制造系统的关键核心，因此我们引入了它作为客户在沙盒环境中验证其生成正确结果后可以选择加入的功能。 随着更多的客户转向新的微服务，我们触发了让每个客户使用微服务的努力，以便可以弃用旧功能。 随着 MRP II 成为随时可以在几分钟内运行的东西，组织可能会变得灵活。 云使创建和连接内存中微服务变得实用，良好的 SaaS 工程原则甚至允许服务中最关键的部分不断发展，而不会中断客户。

如何将现有客户迁移到云

迁移现有客户群可能是增长云服务规模最快的方法。 但是，当我们将 Dynamics 365 引入云时，我们最初专注于新客户。 有两个关键原因：

• 这种方法给了我们一种方法来衡量我们是否提供了一个 SaaS 解决方案，该解决方案以自身优势获胜，而不仅仅是吸引本地客户寻找简单云迁移的解决方案。
• 我们可以专注于 MVP，并将构建迁移现有客户工具之类的任务延后。

在我们获得了新客户的认可后，我们便可以专注于迁移现有的本地部署客户。

我们发现，客户往往害怕移动的成本和复杂性。 我们务必提供降低成本并消除未知因素的工具。 我们开发了工具来帮助分析将数据迁移到云产品中演变的新架构所涉及的工作，并了解迁移对客户扩展和集成的影响。 我们还发现，构建其他工具和程序有助于围绕迁移的时间和成本建立边界。

仅迁移到云就可帮助客户消除他们与本地产品面临的大部分系统管理负担，但强调云版本的好处也是一个重要的动机。

我们如何学习将 Dynamics 365 作为 SaaS 运营

定义 MVP 并完成提升、转移和调整工程后，需要专注于代表客户运营 SaaS 服务。 这种转变是巨大的。 在本地环境中，软件提供商创建并交付软件、系统集成商部署软件，以及客户的 IT 组织或外包提供商运行它。 借助 SaaS，SaaS 提供商不仅主要负责运营该服务，而且还负责同时为数十至数千个客户运营该服务。

我们通过在云中为大量越来越多的客户运营 Dynamics 365 来了解很多知识。

监视：作为服务提供商，客户希望你比他们先检测到服务运行状况问题，并期望你立即找到解决方案。 健康问题不仅仅是在服务中断时出现。 客户对服务不正常的看法包括服务执行缓慢或行为不正确。 开发足够的监视工具至关重要—此开发是服务的一部分，而不是可选的附件。

沟通：在本地环境中，客户可以看到其 IT 团队正在处理问题。 在云中，他们看不到。 在检测到服务运行状况问题时进行沟通、就解决进度保持沟通以及在问题解决时确认解除警报至关重要。 通信的性质因问题的严重性而异。 通信管道也是 SaaS 服务的核心部分，你需要确保即使 SaaS 服务基础结构的核心部分遭到入侵，通信也能成功。

全堆栈视图：在本地环境中，应用程序提供程序通常负责应用程序组件，客户拥有底层基础结构。 在云中，你负责整个堆栈。 如果服务出现健康状况问题，客户希望你检测、通知并修复问题，无论问题是在应用程序中还是它运行的云平台中。

自动执行：如果人类需要在服务作中执行手动步骤，将不可避免地发生错误。 每个可能的操作都应自动化并记录。 如果在足够多的服务节点上需要某个操作，那么自动化是唯一的选项。 一个很好的示例是 Dynamics 365 的数据库管理。 通过决定将每个租户的数据保存在单独的 Azure SQL 数据库中，我们需要开发自动化来处理 DBA 通常执行的所有任务，例如索引维护和查询优化。 有关如何大规模管理数据库的详细信息，请参阅 针对大型 SaaS 提供程序在 Azure SQL 上运行 1M 数据库。

安全部署：在可能的情况下，更改应遵循安全部署过程。 首先，对低风险环境进行了更改，例如，只有较小的客户或不太重要的工作负荷的云区域。 接下来，他们将发展到一组稍大、更复杂的客户等，直到所有客户都更新为止。 在每个步骤中，都需要进行监视来评估更改是否成功。 如果出现问题，该过程应停止更改推出，并缓解问题，或回滚已部署的更改。 安全部署做法适用于代码和配置更改。 有关详细信息，请参阅 推进安全部署做法。

现场事件管理：对我们来说，现场故障 意味着客户在生产环境中遇到的问题需要工程团队的参与。 这可能是我们检测到的健康问题，或者是客户报告的我们的支持团队无法自行解决的问题。 实时站点卓越对于 SaaS 的成功至关重要。 以下是经验中的一些要点：

• 工程团队应处理现场事件。 过去，许多公司都有单独的运营或支持工程团队。 我们明确选择让核心工程团队涵盖现场事件。 他们拥有顶尖的专业知识，亲身看到问题能激发正确的创造力和精力，从而推动真实、快速的改进和更好的未来设计。 在规划开发计划时，需要考虑这一点，但它会推动出色的结果。
• 现场事件领导是一项技能，也是繁重的工作，要认识到这种技能，训练它，学会聘用拥有这种技能的人选，并给予奖励。
• 优先级应为检测、隔离和缓解。 让客户恢复健康，然后再考虑长期改进。

学习和改进：有人曾经说过，“永远不要浪费好的危机。” 每个现场事件都是改进的机会。 缓解完成后，请确保询问如何更快地检测类似问题、如何更正基础问题以完全治愈问题、如何尽量减少类似问题的影响、服务中的其他类似问题是否可能存在，以及如何防止整个类问题。 优先执行这些纠正措施可提高服务质量，并降低对将来实时站点事件的需求。 服务质量必须随着时间的推移而提高，否则随着你的增长，每个问题的影响也会更高。

左移：需要现场团队参与的问题成本高昂。 问题需要时间才能对他们产生影响，现场团队是一种稀缺的资源，需要用于最严重的服务运行状况问题和管理任务。

只要可能，最佳解决方案就是完全消除问题，然后是自动检测和自动缓解。 如果不可能，左移 有助于使一线支持团队能够检测和更正问题或执行任务，甚至更好的是，让客户能够自助服务并自行执行任务。 下图显示了支持案例如何从客户开始，转到一线支持团队，然后转到工程团队。 箭头指示我们将解决方案作向左移动，以减少事件的影响。

保持标准：通过为一位客户做出特殊安排来缓解问题可能很诱人。 大规模而言，一切特殊安排都会成为极端情况，导致其他事情失败。 旨在确保所有租户使用标准代码、设置和配置。

持续创新

在本文中，我们讨论了需要将产品迁移到云，并启动持续学习和持续改进的良性循环。 持续创新是大多数 SaaS 产品的预期。 但是，当 SaaS 产品是长期本地产品的继任者时，它可能需要进行重大的变更管理，以准备客户进行持续创新。

以下是 Dynamics 365 转换中的三个关键重点领域：

近零停机维护：随着各种企业和地点的客户数的增加，无法找到可接受的普遍维护时段。 你需要构建工程成熟度，以便在系统处于联机状态时进行维护活动。 特别是，部署服务更新需要在尽可能接近零的停机时间内发生。

消除回归：客户信任依赖于具有持续创新策略的任务关键型服务。 信任是在每一天的成功运营和每一次无缝服务更新中一点一滴地积累起来的。 遗憾的是，无论规模多么小，任何回归都会失去这种信任。 请务必尽一切可能消除工程过程中的回归，尤其是通过使用安全部署过程。

功能标志：Dynamics 365 团队已大量投资于功能标志框架。 可以为整个服务、租户子集，甚至单个租户启用或禁用功能标志。 通过使用功能开关，我们可以引入新功能，而不会中断 Dynamics 365 所支持的关键业务流程的运行。

以下是特性标志如何提供帮助：

• 在默认启用标志的情况下，可以引入简单的性能或安全修补程序。 每个人都应该立即获得更改的好处。
• 某些改变用户体验、业务流程或外部可见 API 行为的内容会被引入，并且标志默认处于关闭状态。
• 更改功能标志实际上是更改运行的代码，因此还应通过安全部署管理功能标志更改。 例如，假设你引入了问题的修补程序，并且默认关闭修复的功能标志。 可以为报告原始 bug 的客户启用标志。 然后，可以通过在扩大的客户圈上启用标志来缓慢地取得进度，直到为所有人启用该标志。
• 如果默认打开标志时引了修复程序，并且修复程序出现问题，则可以通过关闭标志来在逻辑上立即回滚。
• 功能标志还可用于选择性地在预览版中披露功能，或选择性地在弃用过程中向新客户隐藏功能。
• 可以向一线支持和现场团队提供新功能标志和特定于租户的功能标志设置的可见性。 此信息可帮助团队在调查问题时快速确定或排除新特性改动。 如有必要，团队还可以调整功能标志的设置来缓解此问题。
• 最后，需要管理功能标志的生命周期，以防止使基本代码不可支持。 建立一个过程，以便在代码完全部署和验证后从代码中删除功能标志。

结论

从本地产品过渡到 SaaS 需要对将软件交付给客户以及业务的每个部分进行重大更改。 文化变化与技术变化一样重要：从偶尔的本地发布节奏迁移到常规发布节奏是一个重大转变，采用现场文化和流程需要努力。 你需要确保你的团队为旅程做好了充分的准备，并将你的人才池扩展到工程师之外，以确保你拥有知道如何大规模运营 SaaS 的人员。

许多组织无法幸存这种规模的过渡，特别是如果新的竞争对手已经存在于云中。 要为成功奠定基础，你应该仔细规划一个 MVP，使其尽快上线，然后快速迭代和改进。 转换过程通常是最困难的时间，因此最好尽快过渡到云。

以下是一些我们希望您从我们的经验中得到的关键考虑事项，以及您在自己的旅程中需要做出的一些决定。

• 决定自己的路径。 如果有一个具有丰富功能和已建立的本地客户群的现有应用程序，则迁移到基于云的 SaaS 模型是有意义的。 每个产品的旅程都是不同的，你需要根据自己的需求单独考虑决策和问题。 从其他旅程中吸取灵感，但造就了自己的道路。
• 确定策略。 拥有具有已建立客户的产品意味着你需要决定如何创建优先级。 你可能专注于立即构建一个适用于新客户的产品。 你可能专注于尽快将现有客户群迁移到新服务。 移动的原因和进行重大更改的能力会影响你采取的方向。
• 决定是使用单云还是多云。 请考虑是在一个云平台上扩展，还是把你的工程工作分散到多个云平台上，哪个更有意义。 如果要构建平台组件，多云策略可能有意义。 如果您正在构建应用程序，单云策略相较于使用一致和集成的平台能够提供更多优势。
• 专门规划云。 直接迁移到云的方法是不够的。 你需要计划如何利用云的弹性，以及如何在云环境中运行服务。 自动化、复原、扩展性、安全性、性能和可观测性都是重要的考虑因素。 无需提前完成所有作，但需要知道目标，以便规划路线图。
• 具体为 SaaS 软件服务制定规划。 与本地软件交付方法相比，SaaS 业务模型看起来有所不同。 客户期望拥有试用帐户、易于理解的计费模型、完全托管的服务，并能够根据其需求实现动态扩展。
• 落地、学习和迭代。 规划 MVP 的范围，确定可以实现的基础性成果，然后迅速达成目标。 到达那里后，致力于持续改进。
• 当你在云中时，请利用它。 云提供了许多本地解决方案没有的功能。 这些功能包括大规模、弹性以及使用云平台组件快速创建和迭代想法的能力。 考虑如何使用生成式 AI、微服务和其他难以在云环境外部使用的技术。
• 成为客户的 IT 部门。 提供端到端服务时，客户预期会发生变化。 规划如何左移。 确保具有全面的监视和自我修复功能。
• 了解客户使用情况。 运行服务时，会收集有关客户如何使用产品的大量有用数据。 采用数据文化。 了解你的客户、他们的工作内容以及工作方式。 当数据指示某些内容不符合预期时，进行试验，并保持足够的灵活性，以便根据需要更改方法。
• 通过更新提供持续的价值。 考虑何时以及如何部署更新。 计划快速修复问题或回退到以前的版本。 决定如何处理中断性变更。 避免对特定客户进行一次性更改，因为每个差异点都是出错的机会。

我们学到的最大教训是，SaaS 之旅永远不会结束。 产品路线图是一个不断发展的活文档。 积压工作中始终有许多项目来改进产品，既要添加新功能，又要改进产品的运行和交付方式。 交付 SaaS 需要不断改进流程、投资质量和警惕，以确保为客户提供可靠、安全、高性能和可信的服务。 技术的进步，如生成 AI，带来了巨大的机会，让你提供以前无法想象的功能。

供稿人

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

• 迈克·埃伦伯格 |CTO、Microsoft Dynamics
• John Downs | 首席软件工程师
• 阿森·弗拉基米尔斯基 |首席客户工程师