针对云迁移的 21 个最佳实践

熟能生巧。-Bobby Robson

在过去几个月里，我花了很多时间与各种 AWS 客户和团队合作来打造帮助企业加快云迁移工作的全面计划。此计划包含许多方面，包括 (但不限于) AWS 服务 (例如，AWS Database Migration Service、AWS Snowball、VM Import/Export)、一个由 AWS 专业服务打造的迁移方法、一个即将推出的“迁移到 AWS”培训计划以及与工具提供商和咨询商店建立的合作伙伴关系 (旨在加快各行各业各种规模的企业的云迁移速度)。

今天，我很高兴介绍由本公司的员工 Sadegh Nadimi 编写的一篇客座文章，此人详细说明了我们在执行到 AWS 的大型迁移的企业中观察到的 21 个最佳实践。言归正传 . . .

-Stephen
orbans@amazon.com
@stephen

在过去几年里，AWS 专业服务已引导企业完成数百个迁移项目并提出相关建议。今年，我们组建了一个专家专属团队 (称为 AWS 专业服务大规模迁移团队)，专门帮助客户处理大型 (数百个应用程序) 迁移计划。

客户通常想知道哪些最佳实践可以将应用程序快速可靠地迁移到 AWS。尽管每个企业的组织结构和业务目标各有不同，但大规模迁移团队已学到的模式和实践中有一些对各种公司来说往往都是真实可靠的。以下只是其中一些模式和实践的列表（并未详尽列出）：

预迁移阶段

1. 对于 IT 和业务在将来应该重叠之处有一个清晰的愿景。 

考虑这种愿景将如何影响您组织的策略；广泛宣传这一愿景。能够清晰地说明该策略对于组织的重要性的原因是最主要的。有关更多见解，请参阅“使优秀的领导者成为伟大的领导者的因素”。

2. 概述并分享清晰的云管理模式。 

确定规模较大的团队的角色和责任以及符合您组织的“最小访问特权”和“职责分离”信息安全原则将非常有助于确保实现业务目标。它还允许您加入合适的控制以改善您的安全状况。在为内部用户开放云服务之前，您需要回答许多问题。您应该有多少个 AWS 账户？谁可以访问哪些内容？您将如何授予该访问权限？联系 AWS 以了解最佳实践以及针对云中的管理使用的每个方法的优缺点。

3. 在迁移过程的早期培训员工。 

您的团队拥有的 AWS 相关知识越多，过渡就越顺畅；您拥有的内部推广者越多，消除 FUD 和打破障碍就越容易。此过程需要发生在迁移过程的早期，即您就您的 IT 格局在 AWS 中的未来状况做出组织范围的决策之前。有关培训的更多信息，请参阅“您已经拥有成功实现云迁移所需的人才。”

4. 花时间和精力来概述如何在 AWS 中形成新的运营方式。 

了解可能需要修改或改进的流程、将为您的云之旅提供帮助的运营工具以及将增强您的团队能力的任何级别的运营培训。提前考虑运营问题可让您着眼于大局并确保您的环境符合总体业务战略。

5. 了解您当前拥有的 IT 资产以及您在每次迁移中包含的内容。

这样，您就可以完全量化和度量您的云采用的成功度。投入时间来查找正确的发现工具 (如 Risc Networks 的 CloudScape、ScienceLogic 的 CloudMapper、AWS Application Discovery Service) 和更新您的应用程序库存。这将简化迁移计划工作并最大程度地降低迁移过程中缺少依赖项的风险。

6. 选择合适的合作伙伴以在整个迁移过程中为您提供帮助。 

您应该寻找这样的合作伙伴，他们不仅具有有关迁移到 AWS 的技术专业知识和经验，还具有正确的敏捷方法和项目管理框架。您的内部可能已经有拥有云能力团队的合作伙伴。在选择云合作伙伴之前，为自己腾出时间来审查他们并要求推荐。此外，考虑您计划采用的运营模型以及该合作伙伴是否能帮助推广该模型 (构建 CI/CD 管道和托管服务)。有关更多详细信息，请参阅云中的托管服务的未来。

迁移阶段

7. 从小而简单处着手。 

换言之，在董事会上提出一些速效方案。您的员工对 AWS 服务越满意，您的利益相关者越快看到收益，在内部“推销”该愿景就越容易。为此，您需要一致性和透明度，而且我们看到了许多组织都在使用一系列速效方案来取得成功。

8. 自动化。 

云的敏捷性通过自动化来实现。花时间重新审视流程并建立可在您迁移时利用的新流程。如果并非您的所有方面都能实现自动化，请小心确定哪些方面可以实现自动化并帮助您的团队完成这部分自动化。

9. 将云用作转型手段。 

为此，请调整您的内部流程，使它们能够接纳这种技术转变。利用该转型性质来增强您的优势，让利益相关者与这个新典范相符。此外，始终对那些说“但是我们一直用这种方法. . .”的人抱怀疑态度。

10. 尽可能利用完全托管的服务。 

这包括 Amazon RDS、AWS Directory Service 和 Amazon DynamoDB 等服务。让 AWS 处理日常维护活动并让您的团队腾出手来关注最重要的方面：您的客户。

迁移后阶段

11. 监控一切。 

制定全面的监控策略可确保您将有关应用程序的可靠架构的一切细节包含在内。拥有对您的环境的运行状况的数据驱动型见解将使您能够在权衡性能和成本时做出明智的业务决策。

12. 使用原生云监控工具。 

有大量提供了应用程序级见解和 AWS 上的监控的工具 (例如，New Relic、APPDYNAMICS 和 AWS CloudWatch Logs) 可供使用。使用最适合企业的工具。您的运营人员最终会感谢您，您的企业所有者将获得更清晰的数据点来作为决策依据。

13. 利用 AWS 企业支持。 

AWS 技术客户经理 (TAM) 和账单管理员 (均属于企业支持包) 是极其宝贵的资源。他们开始成为您庞大的虚拟云团队的一部分，并且可以提供针对 AWS 的联系中心点和呈报途径以及技术信息和指南的宝贵来源。

适用于大规模迁移 (即一次迁移数百个应用程序的迁移)

14. 组建一个由围绕迁移活动的所有团队、工具和流程组成的强大迁移工厂。 

在您的第一波迁移之前，记录详细信息并与您的组织分享。您希望以敏捷的方式开展运营以提高应用程序迁移到 AWS 的速度。您还希望采取合适的保护措施来保持迁移势头，甚至在存在势头变缓风险的情况下也是如此，例如，当您的员工休假时或当工具对于特定工作负载没有达到应有的工作状态时。

15. 为迁移工厂提供领导力并设置基准。

考虑建立一个项目团队 (PMO) 来管理整体迁移活动和确保遵循适当的沟通和变更过程。此外，建立一个云卓越中心 (CoE) 来充当您的迁移工作的支持点。CoE 可扮演提供技术指导的顾问的角色，它还可以更具指向性，即让成员亲自参与迁移工作。CoE 的好处将在“如何在您的企业中创建云卓越中心”中更详细地进行讨论。最后，PMO 和 CoE 必须在迁移工厂中通力合作以确保迁移项目成功完成。

16. 在全面开展项目的同时为新的团队成员提供入职培训流程。 

应该将此流程视为另一种形式的培训。您还希望有一个专门团队来评估和审核将在迁移工厂中使用的工具。为了优化迁移的结果，还要考虑在云 CoE 之外组建一个小型团队来寻求效率和对于您的环境来说独一无二的模式。根据您的冲刺的范围和节奏，完成迁移可能需要数月甚至是数年。您需要将迁移工厂视为一个不断演变和改进的生物体。

17. 在您的冲刺团队中明智地分配人才。 

这将确保您对于 AWS 服务和本地应用程序具有足够的广度和深度来应对冲刺过程中的小波折。在冲刺中没有合适的资源可能产生不知情的决策并导致所有后续迁移冲刺混乱。

18. 在为特定应用程序决定迁移策略时考虑很多不同的条件。 

考虑业务目标、路线图、风险状况、成本等。概括来说，您将做出按原样迁移应用程序或以某种方式修改应用程序的决策。无论您选择做出哪一种决策，都应尝试融入最佳实践以尽可能提高弹性和节省成本，并在有条件时转移基础设施。一些常见选项包括自动扩展、负载均衡、多可用区方案和 EC2 实例大小调整。支持您的团队在必要时利用 AWS 最佳实践并尽可能快地开始优化。

19. 寻找模式并为它们创建蓝图。 

随着团队完成计划活动，基于所选策略，将出现特定的迁移模式。为这些模式创建可重复使用的蓝图将提高迁移工作负载的速度。不要忘记与迁移团队分享这些内容。这将使移动比特与字节的人可以真正将注意力放在速度和效率上，而不必围绕如何迁移具有相似特征的应用程序做出决策。

20. 测试您的应用程序。 

迁移工厂的关键环节是将要在云中部署的工作负载的集成和验证。每个应用程序组件都应经历一系列预先确定且记录完整的测试。如果您要求应用程序所有者在项目的早期为您提供测试计划，那么获得企业所有者的签字将顺利得多。在理想情况下，将有一个所有应用程序所有者使用其特定测试要求填充的模板。这有助于简化验证活动并让您的企业所有者确信其应用程序在 AWS 中的运行状况与在本地时相似或者更好。

21. 确保大力宣传的文化逐渐灌输到所有相关团队的头脑中。 

所有迁移决策都需要被清楚记录和签名认可。向组织中的团队 (甚至是未直接参与迁移的团队) 传达“将会出现中断并可能有新的 IP 地址/URL 指引流动方向”这一事实。此外，不要忘记通知可能有权访问您的系统的任何第三方。

您是否有想要分享的其他最佳实践？我们很乐意倾听！

Sadegh Nadimi
运营集成主管 — 大规模迁移全球实践
AWS 专业服务
sadeghn@amazon.com
https://www.linkedin.com/in/snadimi