过程视角 - AWS规范性指导
为大规模迁移做准备运行大规模迁移其它注意事项

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

过程视角

流程带来一致性，但也会不断演变并容易发生变化，因为每个项目都是独一无二的。当你反复运行该流程时，你将发现差距和改进余地，这些差距和改进空间在失败、学习、采用和迭代时可以带来巨大的好处。这些变化可以带来新的想法或创新，项目和企业可以在future 利用这些想法或创新，从而为增长提供催化剂，从而带来质量和团队信心。

迁移过程可能很复杂，因为它们跨越了以前可能没有关联的技术和边界。此视角为大型迁移的特定要求提供了流程和指导。

为大规模迁移做准备

以下各节概述了必要的核心原则，这些原则是确保您在开始迁移之旅时有明确的方向和利益相关者的支持，这对成功至关重要。

定义业务驱动因素并沟通时间表、范围和战略

在进行大规模迁移时AWS，您会很快发现有多种方法可以迁移服务器。例如，可以：

要确定正确的迁移路径，重要的是要从业务驱动因素向后推算。如果你的最终目标是提高业务灵活性，你可能会偏爱后两种模式，它们涉及更高级别的转型。如果您的目标是在年底之前腾出数据中心，则可以选择重新托管工作负载，因为重新托管可以提高速度。

大规模迁移通常涉及广泛的利益相关者，包括：

  • 应用程序拥有者

  • 网络团队

  • 数据库管理员

  • 执行赞助商

关键是要确定迁移的业务驱动因素，并将该列表包含在文档中，例如迁移计划成员可以访问的项目章程。此外，创建与您的目标业务成果密切相关的关键绩效指标 (KPI)。

例如，一个客户希望在 12 个月内迁移 2,000 台服务器，以实现撤出数据中心的目标业务成果。但是，他们的安全团队并没有朝着这个目标前进。结果是就是否错过数据中心关闭日期而进一步实现应用程序现代化，还是先重新托管以及时关闭数据中心，然后对应用程序进行现代化改造，进行了数月的技术辩论AWS。

定义清晰的升级路径以帮助移除拦截器

大型云迁移计划通常涉及广泛的利益相关者。毕竟，你有可能改变已经在本地托管了几十年的应用程序。每个利益相关者的优先事项相互矛盾是很常见的。

尽管所有优先事项都可能带来价值，但该计划的预算金额可能有限，目标结果也很明确。管理各种利益相关者并专注于目标业务成果可能具有挑战性。当您将其乘以迁移范围内的数百或数千个应用程序时，这一挑战就会变得更加复杂。此外，利益相关者可能会向不同的领导团队汇报，这些团队还有其他优先事项。考虑到这一点，除了清楚地记录目标业务结果外，定义明确的升级矩阵以帮助消除阻碍因素也很重要。这可以节省大量时间，并有助于协调各个团队朝着共同的目标前进。

证明这一点的一个例子是一家金融服务公司，其目标是在12个月内撤出其主数据中心。没有明确的授权或升级路径，这导致利益相关者不顾时间和预算限制，精心设计了他们想要的迁移路径。在上报首席信息官之后，制定了明确的任务规定，并提供了要求作出必要决定的机制。

尽量减少不必要的更改

变化是好事，但更多的变化意味着更多的风险。当大规模迁移的商业案例获得批准时，很可能有目标业务成果推动了该计划，例如在特定日期之前撤出数据中心。虽然技术人员通常想要重写所有内容以充分利用AWS服务，但这可能不是您的业务目标。

一位客户专注于将公司的整个网络规模基础架构在两年内迁移到AWS。他们制定了为期两周的规则，以防止应用程序团队花费数月的时间重写应用程序。通过使用两周规则，当必须在多年内迁移数百个应用程序时，客户能够以稳定的节奏维持长期迁移。有关更多信息，请参阅博客文章 “两周规则：在 10 天内重构您的云端应用程序”。

我们建议尽量减少任何与业务结果不一致的更改。取而代之的是，建立机制来管理future 项目中的这些额外更改。

尽早记录 end-to-end 流程

记录大型迁移计划早期阶段的完整迁移过程和所有权分配。该文档对于教育所有利益相关者了解迁移将如何进行以及他们的角色和职责非常重要。该文档还将帮助您了解可能在哪里出现问题，并在迁移过程中提供流程的更新和迭代。

在迁移项目的开发过程中，确保了解所有现有流程，并清楚地记录集成点和依赖关系。包括需要与外部流程所有者互动的地方，包括变更请求、服务请求、供应商支持以及网络和防火墙支持。了解流程后，我们建议在负责任、负责、咨询、知情（RACI）矩阵中记录所有权，以跟踪不同的活动。要完成该流程，请确定迁移的每个步骤所涉及的时间表，从而制定倒计时计划。倒计时计划通常从工作负载迁移切换日期和时间向后生效。

这种文档编制方法对于一家跨国家用电器公司来说效果很好，该公司在不到一年的时间内AWS成功迁移到并退出了四个数据中心。他们有六个不同的组织团队和多个第三方参与，这带来了管理开销，导致 back-and-forth 决策和实施延迟。AWS专业服务团队与客户及其第三方一起确定了迁移活动的关键流程，并将其记录在相应的所有者手中。由此产生的 RACI 矩阵已由所有相关团队共享和同意。使用 RACI 矩阵和升级矩阵，客户缓解了造成延迟的阻碍因素和问题。然后，他们得以提前退出数据中心。

在另一个使用 RACI 和升级矩阵的示例中，一家保险公司能够在不到 4 个月的时间内退出数据中心。客户了解并实施了分担责任模型，并遵循了详细的 RACI 矩阵来跟踪整个迁移过程中每个流程和活动的进度。结果，客户能够在实施的前 12 周内迁移了 350 多台服务器。

记录标准迁移模式和构件

可以把这看作是为实现创建千篇一律。可重复使用的参考资料、文档、操作手册和模式是扩大规模的关键。这些记录了future 迁移项目可以重复使用和避免的经验、学习、陷阱、问题和解决方案，从而显著加快迁移速度。这些图案和人工制品也是一项投资，将有助于改善流程并指导future 项目。

例如，一个客户正在进行为期一年的迁移，其中应用程序由三个不同的 SIAWS 合作伙伴迁移。在早期阶段，每个AWS合作伙伴都在使用自己的标准、操作手册和工具。这给客户团队带来了许多压力，因为相同的信息可能以不同的方式呈现给他们。在经历了这些早期难题之后，客户建立了对迁移中使用的所有文档和工件的集中所有权，并制定了提交建议更改的流程。这些资产包括以下内容：

  • 标准迁移流程和清单

  • 网络图样式和格式标准

  • 基于业务关键性的应用程序架构和安全标准

此外，每周都会向所有团队发送对任何文件和标准的更改，并且要求每个合作伙伴确认收到并遵守任何更改。这极大地改善了迁移项目的沟通和一致性，当另一个业务部门开始单独的大规模迁移工作时，该团队得以采用现有的流程和文档，极大地加快了他们的成功速度。

为迁移元数据和状态建立单一事实来源

在规划大规模迁移时，建立事实来源对于保持各个团队的一致性并实现数据驱动的决策非常重要。当您开始此旅程时，您可能会发现许多可以使用的数据源，例如配置管理数据库 (CMDB)、应用程序性能监控工具、清单列表等。

或者，您可能会发现数据源很少，必须创建捕获所需数据的机制。例如，您可能需要使用发现工具来发现技术信息，并调查IT领导者以获取业务信息。

将各种数据源聚合到可用于迁移的单个数据集非常重要。然后，您可以使用单一事实来源来跟踪实施过程中的迁移情况。例如，您可以跟踪哪些服务器已迁移。

一家金融服务客户想要迁移所有工作负载，AWS专注于使用已提供的数据集规划迁移。该数据集存在关键差距，例如业务重要性和依赖性信息，因此该计划开始了发现工作。

再举一个例子，同一行业的一家公司基于对其服务器基础架构库存的 out-of-date 了解而转向了迁移浪潮的实施。由于数据不正确，他们很快开始看到迁移人数减少。在这种情况下，应用程序所有者不被理解，这意味着他们无法及时找到测试人员。此外，这些数据与他们的应用程序团队完成的停用不一致，因此服务器在没有用于业务目的的情况下运行。

运行大规模迁移

在确定了业务成果并将战略传达给利益相关者之后，您可以开始规划如何将大规模迁移的范围划分为可持续的移民事件或浪潮。以下示例为制定波浪计划提供了关键指导。

提前规划移民浪潮以确保稳定的流动

规划迁移是该计划最重要的阶段之一。俗话说：“如果你没有计划，你就计划失败。” 随着团队对迁移情况变得更加主动，提前规划迁移浪潮可以使项目迅速进行。它可以帮助更轻松地扩大项目规模，并且随着项目需求的增加和变得复杂，它可以改善决策和预测。提前计划还可以提高团队适应变化的能力。

例如，一家大型金融服务客户正在制定数据中心退出计划。最初，客户按顺序规划迁移浪潮，先完成一波迁移，然后开始规划下一波迁移。这种方法减少了准备时间。当利益相关者得知他们的应用程序正在迁移到时AWS，在开始迁移之前，他们还有几个步骤要执行。这给该计划增加了很大的延迟。客户意识到这一点后，他们实施了future 全面迁移规划流程，其中迁移浪潮是提前几个月规划的。这为应用程序团队提供了足够的通知，使他们能够执行迁移前的活动，例如通知AWS合作伙伴、许可分析等。然后，他们可以将这些任务从程序的关键路径中删除。

将波浪实施和波浪规划作为独立的流程和团队分开

当波浪规划和波浪实施团队分开时，这两个过程可以parallel 运行。通过沟通和协调，这可以避免由于没有足够的服务器或应用程序准备好达到预期速度而减慢迁移速度。例如，迁移团队可能需要每周迁移 30 台服务器，但在当前浪潮中只有 10 台服务器准备就绪。这种挑战通常是由以下原因引起的：

  • 迁移实施团队没有参与浪潮规划，在波浪规划阶段收集的数据也不完整。在开始迁移之前，迁移实施团队必须收集更多的服务器数据。

  • 迁移实施计划在浪潮规划之后立即开始，两者之间没有缓冲区。

提前规划波浪至关重要，在准备工作和波浪实施开始之间留出缓冲区是至关重要的。同样重要的是要确保波浪规划团队和迁移团队共同努力，收集正确的数据并避免返工。

从小处着手，取得出色成果

计划从小规模开始，并在随后的每波浪潮中提高迁移速度。最初的浪潮应该是一个小于 10 台服务器的单一小型应用程序。在随后的几波中添加其他应用程序和服务器，从而达到您的全部迁移速度。优先考虑不太复杂或风险较小的应用程序，并按计划提高速度，使团队有时间进行调整，以适应合作并学习流程。此外，该团队可以确定并实施每波浪的流程改进，这可以显著提高后续波浪的速度。

一位客户在一年内迁移了 1,300 多台服务器。通过从试点迁移和几次小规模迁移开始，迁移团队得以找到多种方法来改进以后的迁移。例如，他们早些时候发现了新的数据中心网络分段。在流程初期，他们与防火墙团队合作，制定了允许与迁移工具进行通信的防火墙规则。这有助于防止future 浪潮中出现不必要的延迟。此外，该团队还能够开发脚本，帮助他们在每波浪潮中自动执行更多的发现和转换流程。从小处着手帮助团队专注于早期流程改进，并极大地增强了他们的信心。

尽量减少转换窗口的数量

大规模迁移需要有纪律的方法来扩大规模。对于大规模迁移而言，在某些领域过于灵活是一种反模式。通过限制每周转换窗口的数量，花在转换活动上的时间具有更高的价值。

例如，如果转换窗口过于灵活，则最终可能有 20 次切换，每个切换有 5 台服务器。相反，你可以进行两次切换，每次 50 台服务器。由于每次切换的时间和工作量都相似，因此减少切换次数、增加切换次数可以减少日程安排的操作负担，并限制不必要的延迟。

一家大型科技公司正试图在合同到期之前迁移出几个租赁的数据中心。错过到期将导致昂贵的短期续订条款。在迁移的早期，应用程序团队被允许在最后一刻决定迁移时间表，包括在切换前几天出于任何原因选择退出迁移。这导致该项目的早期阶段出现了许多延误。通常，客户必须在最后一刻与其他应用程序团队协商才能填写。客户最终提高了规划纪律，但是这个早期的错误给迁移团队带来了持续的stress。总体时间表的延迟导致某些应用程序无法及时离开数据中心。

快速失败、应用经验并迭代

起初，每次迁移都有陷阱。尽早失败有助于团队学习、理解瓶颈，并将吸取的教训应用到更大的浪潮中。预计迁移的前几波浪潮将缓慢，原因如下：

  • 团队成员正在适应彼此和流程。

  • 大规模迁移通常涉及许多不同的工具和人员。

  • 集成、测试、失败、学习和持续改进 end-to-end 流程需要时间。

在前几波浪潮中，问题很常见，也是预料之中的。了解这一点并将其传达给整个组织很重要，因为有些团队可能不喜欢尝试新事物而失败。失败可能会使团队望而却步，成为future 迁移的障碍。确保每个人都明白最初的问题是工作的一部分，鼓励每个人尝试失败是成功迁移的关键。

一家公司计划在 24—36 个月内迁移 10,000 多台服务器。为了实现这一目标，他们需要每月迁移近 300 台服务器。但是，这并不意味着他们从第一天起就迁移了 300 台服务器。前几波是学习浪潮，这样团队就可以了解事情是如何运作的，以及谁有权做什么。他们还确定了可以改善流程的集成，例如与CMDB和集成 CyberArk。他们利用学习浪潮来失败、改进，然后再次失败，完善流程和自动化。6 个月后，他们每周能够迁移 120 多台服务器。

别忘了回顾展

这是敏捷过程的重要组成部分。这是团队沟通、调整、学习、达成共识和向前迈进的地方。最基本层面的回顾是回顾，讨论发生了什么，确定哪些进展顺利，哪些需要改进。然后可以在这些讨论的基础上进行改进。回顾展围绕吸取经验教训的概念包罗了一些形式或过程。回顾之所以重要，是因为要实现大规模迁移所需的规模和速度，从而取得成功，流程、工具和团队必须不断发展和改进。回顾可以在这方面发挥重要作用。

传统的经验教训要等到项目结束后才会举行，因此这些经验教训通常不会在下一波移民浪潮开始时得到审查。对于大规模迁移，吸取的经验教训应应用于下一波迁移，并应成为浪潮规划过程的关键部分。

对于一位客户，每周举行一次回顾会议，讨论和记录从切换中吸取的经验教训。在这些会议中，他们发现了从流程或自动化的角度来看还有精简余地的领域。这导致实施了包含特定活动、所有者和自动化脚本的倒计时时间表，以最大限度地减少切换期间的手动任务，包括验证第三方工具和亚马逊 CloudWatch 代理安装。

在另一家大型科技公司，定期与团队举行回顾会，以找出以前移民浪潮存在的问题。这带来了流程、脚本和自动化的改进，使项目期间的平均迁移时间缩短了 40%。

其它注意事项

大型移民计划必须将许多领域考虑在内。以下各节提供了对其他必须考虑的问题的看法。

边走边清理

如果迁移的成本是预期的 10 倍，并且在关闭和清理用于迁移的资源之前，项目才算完成，则该迁移不算成功。此项清理应该是迁移后的活动的一部分。它可以确保您不会在环境中留下会增加成本的未使用的资源和服务。迁移后清理也是防止暴露环境的威胁和漏洞的良好安全实践。

迁移到的两个关键结果AWS Cloud是节省了成本和提高了安全性。留下未使用的资源可能会违背迁移到云的业务目的。未清理的最常见资源包括：

  • 测试数据

  • 测试数据库

  • 测试账户，包括防火墙规则、安全组和网络访问控制列表 (网络 ACL) IP 地址

  • 为测试预置的端口

  • AElastic Block Store (Amazon EBS) 卷

  • 快照

  • 复制（例如停止将数据从本地复制到AWS）

  • 消耗空间的文件（例如用于迁移的临时数据库备份）

  • 托管迁移工具的实例

举一个不良清理做法的例子，SI PAWS artners 在成功迁移后没有删除复制代理。AWS审计发现，已经迁移的复制服务器和 EBS 卷每月花费 20,000 美元（美元）。为了缓解这个问题，AWS专业服务创建了一个自动审计流程，当陈旧服务器仍在复制时，该流程会通知 SIAWS 合作伙伴。然后，SIAWS 合作伙伴可以对未使用和过时的实例采取行动。

对于future 迁移，采用了一个流程来定义迁移后的 48 小时超保期，以确保平台的顺利采用。然后，客户的基础设施团队提交了本地服务器的停用请求。有人建议，停用请求获得批准后，相应浪潮的服务器将从应用程序迁移服务控制台中移除。

为任何其他转型实施多个阶段

在进行大规模迁移时，重要的是要将注意力集中在核心目标上，例如关闭数据中心或基础设施转型。在较小的迁移中，范围扩大的影响可能微乎其微。但是，几天的额外工作量乘以可能的数千台服务器可能会为该程序增加大量时间。此外，其他更改可能还需要更新支持团队的文档、流程和培训。

为了克服潜在的范围扩大，您可以实施多阶段迁移方法。例如，如果您的目标是腾出数据中心，则第 1 阶段可能仅包括AWS尽可能快地重新托管工作负载。重新托管工作负载后，第 2 阶段可以在不影响目标业务结果的情况下实施转型活动。

例如，一位客户计划在 12 个月内退出其数据中心。但是，他们的迁移包括其他转型活动，例如推出新的应用程序性能监控工具和升级操作系统。迁移范围内有 1,000 多台服务器，因此这些活动大大延迟了迁移。此外，这种方法需要在使用新工具方面进行培训。客户后来决定实施多阶段方法，最初的重点是重新托管。这提高了他们的迁移速度，降低了无法满足数据中心关闭日期的风险。