第2章 迈出上云第一步？

最初发布于2016年9月26日：http://amzn.to/getting-started-with-cloud

“千里之行，始于足下。”

——老子

在第1章中，我们介绍了“采用阶段”（简称SofA）这一心智模型，用于描述企业在走向云优先的旅程。我发现，这一过程所涉及的更多是领导与变革管理实践，而非技术性运动。而且虽然不存在百试百灵的答案，但我希望采用阶段这一定义能够帮助更多高管朋友在自己的云迁移旅程中获得指导。

本章我们专注于采用阶段中的第一阶段，我将其称为“项目”。第一阶段将详细阐述我在众多企业中观察到的云转型起点与特征。

大多数企业都会以一部分项目为开端，借此探索如何利用云技术满足业务需求。

我的第一个企业云项目（如第1章所述）

2012年，我在道琼斯公司出任CIO职务。当时，我的老板（CEO）提出了一个得到广泛认同的重要商机：如果《华尔街日报》（道琼斯公司的旗舰级B2C产品）的订阅者掌握着世界上大部分财富，而法克提瓦与道琼斯通讯社（道琼斯的B2B产品）的订阅者管理着世界上大部分财富，那么我们应该可以通过为其提供对接与沟通的体系以构建起一套极具价值的交互平台。

道琼斯公司此前从未尝试过类似的项目，而我们希望尽快行动起来。我们建立了一支小型工程师与设计师团队，负责建立原型以验证相关概念。领导也特别关照，为我们提供完全的自由发挥空间，允许我们选择任何能够完成任务的工具。

六周之后，利用几种AWS服务、自动化、开源方案以及大量的辛勤工作，我们打造出一款可用性出众且不易受失败影响的应用程序。该应用顺利上线并成功运行使之成为模范项目。由此获得的能力使我们学会如何快速为业务部门提供所需的技术方案。这不仅让我们的团队变得信心满满（很多成员在参加培训之前都相当焦虑），企业决策层也更积极地参与到我们的探索旅程中来。

应该选择怎样的项目作为起点？

一般来讲，我认为组织最好选择那些能够在数星期之内看到成果的项目作为起点。那种需要延续多年的IT项目已经不再适应时代的要求，我接触过的大部分企业高管之所以对云计算抱有兴趣，主要是看重云给企业带来的卓越敏捷性。

大家应该为团队提供具备可行性且有时间限制的机会，用以探索真正有意义的目标。根据个人经验，我比较推荐从零开发，这也是很多企业的共同选择。现代Web与移动应用比较适合这类需求，因为其中的使用案例与参考架构已经具有良好的广泛性与共识性。此外，我也观察到有部分企业选择Amazon Workspaces部署、开发测试环境迁移或者对现有应用程序进行更新或迁移。

对现有应用程序进行迁移时往往比较复杂多样，具体取决于实际架构以及现有许可机制。在考量待迁移应用程序的复杂性范围时，我通常会将虚拟化、面向服务的架构作为低复杂性的一端，而将整体式大型机视为高复杂性的一端。我建议大家先从低复杂性一端入手。关于迁移场景与模式的更多细节信息，我将在“迁移”阶段中作出更多具体说明。

我们发现，最重要的就是选择的项目既能为企业带来真正的业务价值，又没有重要到不允许学习探索。因此，大家应避免过度烦琐分析陷入瘫痪，而将早期云项目作为一种开始实验的机会。

除非有非常充分的理由，否则我个人强烈反对大家将一个全面的业务转型作为第一个试水性项目。每个企业只具备有限的处理变化的能力，不同企业的这种处理变化的能力存在巨大差异。另外，我还发现过分追求速度超过那种能力就可能带来负面效应。我曾经乐于被同事们称为“牛仔”，但我意识到这并不总是什么好事。曾有人告诉我“成功的荣耀不应该是一个人独自到达了终点”，这让我意识到自己怎样一步步“沦落”为独行侠。我学会了在探索过程中不断自我反思，从而尽可能保持平衡。

如何选择早期云项目的参与人员？（提示：态度很重要）

无论你的组织选择从哪里开始征程，你都要做好心理准备：你的早期云项目除了让一些人兴奋不已，也会让另一些人满心忧虑。

因此，请首先培养那些对新项目感到兴奋的员工，并考虑如何将他们转化为云的宣传者和布道者。我发现，在这类工作中，态度的重要性等同于能力。早期推动者往往具有好奇心强、敢于尝试等特质。因此，请在项目推进的过程中随时关注成员们的表现，您的云卓越中心（第25章）的首批骨干很可能会从中产生。关于更多细节内容，我们将在下一个采用阶段（即“基础”）部分详加说明。

要理解那些对新项目不太适应的员工，同时尽可能为其提供工具以引导他们加入云迁移之旅。尽管计算机科学的基本原理仍然适用，但要充分利用云环境提供的优势，我们需要以不同于传统的方式审视这些功能并考量如何借此实现目标。要敏锐察觉并妥善处理他们的忧虑和关切，请参阅本书的第15章以及第16章。

早期项目的驱动因素有哪些？

大概两三年之前，大多数云项目仍然由独个业务部门驱动。通常当企业中央IT部门无法及时实现业务部门所需的功能，这些项目就会以影子IT的形式引入。从传统角度来看，影子IT往往会引发企业内部的紧张氛围。为了解决这个问题，云卓越中心团队（第14～31章）将负责为业务部门提供得到IT认可的云参考架构，以帮助业务团队以安全、透明且有序的方式进行创新。这种方法既能够帮助不同业务部门释放创新能力，同时又能够立足大规模IT体系为中央IT部门提供必要的安全性、合规性与一致性保障。AWS Service Catalog正是为帮助企业以规模化方式实现这一目标所建立的。

随着云计算成为新的常态，我发现中央IT部门开始越来越多地成为早期云计算项目的主导者。例如，已经有不少金融服务组织专注于削减成本开支，并希望在更新周期之内利用云计算对自身开发／测试环境进行规模调整。作为典型实例，强生公司就将Amazon Workspaces作为其早期云实验项目之一。