亚马逊AWS官方博客

云迁移的21个最佳实践

作者:Sadegh Nadimi                翻译:郝森

在过去的几年里,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直接引发流量。不要忘记通知可能访问该系统的任何第三方。