吸引企业迁移到公共云有很多好处，例如降低运营复杂性和降低成本的潜力。但云服务不一定是每个工作负载的最佳场所。有时，云最终的成本高于预期或提供较低的性能水平。并且，合规性要求可能会使在云端操作比预期的更困难。

不管是什么原因，你不必呆在云端。你可以通过开发和执行云退出策略将工作负载“遣返”回本地。

退出云可能和最开始迁移到云一样复杂。但是，如果你以系统的方式计划该过程，并预测你可能遇到的挑战，则有可能在不中断用户或丢失数据的情况下将应用程序从云移动回本地。

如果你的企业对云托管应用程序是否符合预期有疑问，则可以考虑云退出策略。请继续阅读下文，以了解如何执行反向迁移，将基于云的应用程序恢复到本地。

什么是云退出策略？

云退出策略是将基于云的工作负载迁移到本地环境的计划。可以说，这是反向的云迁移。

云退出策略应解决将工作负载从云端移出的几个关键考虑因素：

• 哪些数据、应用程序和其他资源将退出云，以及一些工作负载在其他工作负载离开后是否会留在云端。
• 支持你从云中遣返的工作负载所必需的本地基础设施资源。
• 执行云退出所需的员工资源。
• 企业为完成云退出而将采取的流程和程序。

退出云的过程有时被称为云遣返。该术语背后的类比是，云遣返类似于遣返离开原籍国的人。

为什么云退出策略很重要？

制定云退出策略很重要，因为将工作负载从云迁回至少与迁移到云端一样复杂。如果没有系统的云退出策略，企业将很难确保迁移顺利进行且不破坏业务连续性。企业可能会遇到一些问题，例如忘记遣返某些工作负载，或者在退出云时未能获得足够的本地资源来支持工作负载。而且，尽管云供应商提供工具来帮助将工作负载迁移到云端，但他们几乎没有提供工具来简化退出云的过程。

云退出策略也很有价值，因为云服务并不总是能提供企业在将工作负载转移到其中时所期望的价值。理论上，云可以通过提供对几乎无限的基础设施资源的按需访问，以使工作负载更具可扩展性并提高性能。此外，云通常被吹捧为降低运营复杂性的一种方式，通过消除管理物理基础设施的需要。

然而，在实践中，企业希望通过迁移到云端实现的好处，并不总是能够实现。在某些情况下，由于配置不佳或在本地数据中心中利用裸机硬件的能力等问题，云工作负载性能实际上会更差。由于复杂的云定价规则和避免很多“隐藏”费用（例如数据出口费用和数据请求成本）的挑战，云的成本效益也会降低，这些费用可能会增加云账单。合规性要求也会使云的使用复杂化。例如，新的合规规则可能要求企业确保其数据位于某个地缘政治管辖区，这在使用云时并不总是可实现。

当企业发现自己处于这样的情况时，他们可能会认为迁移回本地是实现其目标的最佳方式。在这种情况下，拥有云退出策略至关重要。

创建云退出策略的8个步骤

制定云退出策略是一个多步骤的过程，包括计划将哪些工作负载从云迁移回本地、执行迁移，然后验证你的工作负载在返回本地后是否能够正常工作。

以下是创建云退出策略的关键步骤。

1. 准备预算

对于将工作负载移回本地，可能需要你目前没有的本地托管基础设施。你需要投资于网络升级和新的监控、可观察性和安全工具，以帮助支持本地工作负载。在某些情况下，你可能需要增加员工。

当工作负载回到本地，请确保你可以分配足够的预算来支持工作量。如果没有适当的财务准备，一旦工作负载离开云，你就有可能遣返工作负载，而无法支持它。

2. 让你的团队做好准备

如果需要，请对你的团队进行组织更改。指定工程师负责迁移项目。当应用程序恢复到本地，请务必指派某些团队成员来支持该应用程序，特别是当此前作为迁移到云的一部分，你取消或减少了本地基础设施支持。作为云遣返过程的一部分，你必须确保可以恢复或扩展应用程序。

3. 备份数据

如果你的云托管应用程序创建或管理持续性数据，你将需要备份该数据。这样做的方法将因数据的存储方式而异。如果数据存储在数据库中，你可以拍摄数据库的快照。对象存储数据可以复制到外部存储以创建备份。

当该应用程序恢复到本地，确保数据备份与你计划用于支持应用程序的数据技术兼容。有些专有的基于云的数据库和数据存储服务没有等效的数据库和数据存储服务，你可以在本地自行运行。你可能需要转换数据才能将其恢复到本地。

4. 备份应用程序

备份过程将因应用程序的部署方式而异。如果是容器化应用程序，你可以在本地移动容器图像，而无需经历复杂的快照过程。要备份直接托管在虚拟机上的应用程序，请拍摄虚拟机的快照。然后将快照转换为你可以在本地托管的格式。

你还可以选择在本地重新部署应用程序的新实例，而不是尝试将基于云的实例迁移回你的环境。如果基于云的应用程序太难进行快照，或者如果你想更新应用程序的最新版本，而不是在云端运行的的版本，这种方法更有意义。

5. 为紧急情况做好准备

在开始实际迁移过程之前，请为可能中断迁移过程的紧急情况做好准备，例如停电或网络故障。这些意外事件很少见，但有可能发生。创建备份计划，以防迁移失败或时间比预期长。

备份计划可以等于保持基于云的应用程序实例运行，直到你可以成功完成迁移到本地环境。尽管如此，你还要制定正式的计划，这样如果迁移没有预期的那么顺利，你就不会惊慌。

6. 执行迁移

利用这些数据和应用程序备份，你可以开始迁移。在大多数情况下，你将能够通过网络将数据和应用程序映像迁移到本地环境。如果你有大量数据，你可能需要考虑替代数据传输服务，例如AWS Snowball。

7. 验证新应用程序实例

当你的数据和应用程序重新上线时，在上线之前，请运行检查以确保它们按要求执行。确保没有数据损坏，并且你的本地数据状态与基于云的实例的状态一致。

如果你的应用程序在迁移过程中保持运行，这可能会很棘手。你可以使用Rsync等工具执行快速同步，以对准两个版本的数据。

负载测试可以确保你的本地应用程序能够处理你期望向它提交的流量。安全扫描对于捕捉你在迁移期间可能错过的漏洞或配置风险很有价值。

可选步骤：向金丝雀用户公开新应用程序

与其一次性将所有应用程序请求重定向到本地应用程序，不如考虑金丝雀策略。这将把部分应用程序用户的流量重定向到新应用程序，同时依靠基于云的实例来处理其他请求。

当采用这种方法，问题不会影响所有用户。如果遇到严重问题，你将能够快速返回到基于云的应用程序实例。

仅将部分用户重定向到某个应用程序实例可能很复杂，因此，金丝雀策略不一定适用于所有情况。

8. 完全上线该应用程序

如果你的本地应用程序已通过所有验证检查（如果适用，为你的金丝雀用户充分执行），你可以将所有应用程序请求重定向到本地实例。然后你可以关闭云实例。

此过程通常涉及更新DNS记录，以便它们指向你应用程序的正确实例。你可能还需要配置负载平衡器和防火墙，以正确地将流量引导到本地应用程序实例。