云迁移的 21 个最佳实践

在过去的几年里，AWS 专业服务团队已经指导和帮助企业完成数百个迁移项目。今年，我们建立了一个专门的专家团队，称作专业服务大规模迁移团队，专注于协助客户开始大规模迁移（数百个应用）。

客户经常困惑有哪些最佳实践，使应用快速稳健的迁移到 AWS. 虽然每个企业的组织架构和业务目标不同，但是大规模迁移团队已经掌握一些模式和实践，帮助每种类型的企业。以下是一个不完全的清单：

迁移前阶段

**1. 为未来 IT 和业务交集的部分，制定一个清晰的愿景。**想象这个愿景将怎样影响组织的战略；更广泛的宣传，使大家明确的知道战略对组织非常重要。

**2. 规划并分享一个云治理模型。**识别更广泛的团队的角色和职责，满足企业信息安全的最小访问特权和职责分立等原则，保障企业目标的达成将有很长的一段路要走。它同样使增强安全管控纳入到更好的控制。在使内部用户进入使用云服务的洪流之前，需要回答很多问题。我应该有多少 AWS 帐户？谁可以使用什么？你怎么样授予权限？在云治理来临时，AWS 可以告诉你每种方法的最佳实践、优势、限制。

**3. 在此过程中，尽早的培训员工。**团队掌握 AWS 的相关知识越多，迁移就越顺畅；内部的云布道师越多，就更容易的消除障碍。在组织做一个决定，即决定在 AWS 之上的最终 IT 全景视图，这些工作应该尽早展开。

**4. 花时间和精力规划 AWS 之上的运维管理。**研究需要调整的流程，有帮助的云运维工具，以及增强团队力量的各级别运维管理培训。思考那些使你关注更宏观图景的运维管理，确保你的环境与业务战略更好的协同。

**5.了解当前拥有的 IT 资产，以及每批迁移中都包含哪些资产。**这使你完全量化和衡量你的成功入云过程。花时间找到正确的资产发现工具，更新你的应用清单。这些使迁移规划较为顺畅，使迁移过程中忽略关联关系的风险最小化。

**6. 为迁移之旅选择合适的合作伙伴。**应该寻找那些既有技术技能和实施经验，又有灵活方法和项目管理框架的合作伙伴。你可能已经有一个具备云能力的合作伙伴，在选择之前，留出时间对合作伙伴进行审查，要求提供参考案例。思考你计划采用的云运维模型，合作伙伴是否可以帮助协同这个模型（建设持续交付持续集成管道，管理服务）。

迁移阶段

**7. 从较小的和简单的开始。**换句话说，选择一些速赢的方案。你的员工对使用 AWS 服务越舒服，那么干系人就会越快看到收益，那么在内部推动上就越容易。你需要做到持续和透明，我们已经看到很多组织通过一系列速赢方案而实现成功。

**8. 自动化。**云灵活性的实现有赖于自动化。花时间重新审视那些流程，并建立一些新的在迁移过程中有用的流程。如果不是所有的方面都能自动化，仔细决定哪些可以，让团队完成。

**9. 把云当作转型。**通过调整内部流程，使其拥抱技术变化。运用天然的转型优势，与干系人就新的工作模式达成协同。质疑那些总是说“我们一直这样做”的人。

**10. 在可能的情况下，更多的运用全托管服务。**比如包括 Amazon RDS, AWS Directory Service, 和 Amazon DynamoDB。由 AWS 处理日常的维护活动，使你的团队专注于你的客户事务。

迁移后阶段

**11. 全面监控。**当你的应用实现健壮的架构，综合监控战略将确保你得到所有的细节。考虑到效率和成本的相互制约，你的环境运行状况如何，数据驱动的洞察力将使你做出更聪明的业务决策。

**12. 使用云原生的监控工具。**在 AWS 上，有很多工具都可以提供应用级别的洞察和监控能力。运用最适合业务的工具，从长期看，运维人员将会感谢你，业务负责人也会拥有更清晰的数据为决策提供支持。

**13. 采用 AWS 企业支持服务。**AWS 技术客户经理和帐单管家，是企业支持服务包的一部分，是非常有价值的资源。他们可以是你虚拟云团队的一部分，提供一个 AWS 中心接触点，和事件升级路径，同时也是技术信息和指导的宝贵资源。

大规模迁移（一次性迁移数百个应用）

**14. 建立一个以迁移活动为中心，由团队、工具和流程组成的健壮的迁移工厂。**在第一批迁移工作之前，记录并向组织分享相关细节。采用一个灵活的模式，加速应用迁移到 AWS 的过程；采用一个合适的保障措施，保障关键迁移里程碑的执行，防范相关风险，例如员工休假，或为特殊负载设计的工具发生故障。

**15. 提供领导力以及设定迁移工厂的相关标准。**考虑建立项目管理团队，总体管理迁移活动，保障合适的交流和沟通，以及变更过程。建立一个云卓越中心，作为撬动整个迁移工程的支点组织。卓越中心提供技术指导，或者更清晰的规定，它的成员自身也要参加迁移工程。总之，伴随迁移工厂，必须设立项目管理团队和卓越中心，确保迁移项目成功。

**16. 在整体项目开始后，制定一个新团队成员加入流程。**这其实是另外一种形式的培训。需要建立一个专门团队，评估和批准迁移工厂所用的工具。为了优化迁移结果，考虑任命一个更小的团队，在卓越中心之上，寻找对于自我环境中独特的工作效能和模式。鉴于敏捷批次的范围和节奏的不同，迁移可能是数月，甚至是数年才能完成。应该把迁移工厂看作持续发展和进步的一个有机体。

**17. 明智的将有天赋的专家分布于敏捷批次团队。**对于 AWS 服务和数据中心应用，确保有足够宽度上和广度上的能力，处理敏捷批次中遇到的小问题。如果在一个敏捷批次中没有合适的资源，可能导致不统一的决策，进而在后续敏捷迁移批次中产生混乱。

**18. 当为一个特殊应用决定迁移策略时，考虑不同的标准。**如考虑业务目标、路线图、风险情况、成本等。在高阶层次上，你可以决定保持现状平移应用入云，或者在模式上做一些调整。无论是哪种选择，尽可能采纳弹性和节约成本的最佳实践，并对支撑基础架构进行抽象。有一些共同选择是自动扩展、负载均衡、多可用区场景和准确容量估算的 EC2 实例。如果有意义，随时让你的团队采用 AWS 最佳实践，并尽快开始优化。

**19. 找到模式并设计蓝图。**在团队进行规划活动时，基于选定的战略，迁移模式将是确定的。针对这些模式，设计可重用的蓝图，将加快工作负载迁移的速度。不要忘记与迁移团队分享这些蓝图。这可以帮助进行迁移活动的同事，使他们专注于速度和效率，而不用为决定如何迁移有相似特征的应用而担心。

**20. 应用测试。**迁移工厂的一个关键活动是整合和验证部署到云端的工作负载。每一个应用组件将通过一系列预定义的和文档记录的测试。如果要求应用负责人在项目的早期就提供测试计划，将会比较顺利的得到业务负责人的签字通过。理想情况下，应该有一个模板，以供所有应用负责人提出特定的测试需求。这将帮助验证活动顺利执行，使业务负责人放心，他们的应用在 AWS 上运行与在数据中心中运行是类似的，甚至是更好的。

**21. 确保将充分交流的文化灌输给所有相关团队。**所有迁移决定需要清晰的文档记录和签字确认。提醒组织内的团队一个事实，即使是不直接和迁移相关的团队，系统会出现故障，以及潜在的新 IP 地址/URL 直接引发流量。不要忘记通知可能访问该系统的任何第三方。

本文转载自 AWS 技术博客。

原文链接：

https://amazonaws-china.com/cn/blogs/china/21-best-practices-of-migration-to-cloud/