第1章 我的云之旅

“所谓运气，就是机遇与准备碰撞出的火花。”

——Seneca

早在我（甚至是整个行业）弄清云计算的概念之前，我的云之旅就已经开始了。

云尚不存在之时

我于2001年加入彭博担任开发人员，并在七年的职业生涯中持续构建软件方案，以帮助股市专家们更好地了解上市公司，最终做出明智的投资决策。此外，我还构建（并重构）了彭博公司的大部分消息收发平台——这些交流通道堪称华尔街的“心血管”系统，专业人士们借此彼此沟通并分享信息。

毫无疑问，到2008年市场开始出现一些不利的变化。当时，彭博公司规模最大的多家客户（包括贝尔斯登以及雷曼兄弟）遭遇破产，其他不少企业也开始承受巨大的压力。这是彭博公司建立以来，第一次面临业绩负增长的问题。经历了20多年令人振奋的快速发展之后，彭博也终于迎来了自己的危机。然而，当时的彭博掌门人Dan Doctoroff不愿接受命运的奴役，反而要求在企业之内推出名为“10B”的一项财务激励计划。他设定的目标，是推动彭博公司由当时的60亿美元年收入尽快达到100亿美元大关。

当时，我们没有寄希望或者将命运押在金融服务行业能够快速复苏的假设上。相反，我们充分发挥彭博在数据、分析、软件与客服方面的核心竞争优势，寻找方法将其应用到新的领域，旨在推动公司收入来源的多样化，不再将所有鸡蛋都放在华尔街这只篮子当中。这是我职业生涯中第一次身处正确的时间与正确的位置。作为一位狂热的体育粉丝，我总有一种感觉：我们为资本市场开发出的很多成果都能够在职业体育市场上发挥巨大作用。我与一些志同道合的同事们联合起来，共同将这种假设总结成下面这个具体问题：

如果我们将专业运动员视为单支股票，将专业体育队伍视为投资组合，结果会怎样？

沿着这样的思路，如果我们将专业体育赛事中产生的数据收集起来，并利用华尔街最常见的同类分析方法加以处理，相信我们将能够为各专业运动队伍带来更高效的运营管理建议。大家可能听说过Michael Lewis在《点球成金》一书中提出的理念（主要讲述奥克兰运动家队总教头Billy Beane利用统计学家Bill James提出的棒球统计学理论赢得比赛的故事），我们的思维与其基本一致，只是最终目标设定为面向职业体育运动中的每位参与者，并借此建立起新的业务体系。

在接下来的四年中，我们建立起彭博体育。我们最初开发的分析产品用于帮助各支队伍根据投手／击球手的匹配情况（即“换位”）决定将他们的外野手部署在哪里、投手如何应付特定击球手（反之亦然）以及如何比较不同球员的相对价值。事实证明，很多团队都充分体会到了这些信息中蕴藏的价值——在30支职棒大联盟队伍中，有28支队伍至少订阅了一年分析服务。不过直到我们将分析与自动计数系统加以结合之后，才有一些团队愿意为此支付不菲的服务费用。

除了专业业务之外，我们还为“梦幻棒球（一种以积分定胜负的棒球竞猜游戏）”以及足球运动员构建起多种Web及移动分析产品。虽然这些工具都起到了应有的作用，但事后来看，我们当时的商业模式存在误区。我们试图以虚拟角色收费的方式建立订阅商业模式，但玩家们却不愿为这些只存在于纸面的信息买单。事实上，我们当时应该采用广告赞助（或者至少是免费增值）的业务模式。无论如何，最终的业务表现不尽如人意，而彭博体育最终也被拆分、出售并纳入Stats有限公司。但我个人仍然在期间学到了很多，而且通过了解棒球内幕好好过了把当棒球迷的瘾。

说了半天，很多朋友可能没弄明白，这些经历跟云计算到底有什么关系。在我们于2008——2011年建立彭博体育的过程中，彭博公司为了达成10B目标而在其他外部业务（所谓“终端外业务”）身上进行了投资。彭博法律、彭博政务、彭博财富以及彭博人才等产品相继上线，其指导思路也完全一致——收集与特定垂直行业相关的数据，以此为基础进行分析，并将结果出售给专业人士及管理者，帮助他们做出更好的决策。

但到2011年，我们发现这类企业似乎都无法带来理想的投资回报——这主要是因为我们浪费了大量资金为这些系统构建基础设施。我们使用的是与彭博原有终端相同的IT基础设施技术——这套技术堆栈强大、成熟、对延迟非常敏感，而且已经拥有超过30年的历史。事实证明，为初创业务建立基础设施并不是明智的做法。作为参与过彭博终端与终端外业务的工作人员，我一直以“被志愿者”的身份帮助解决这一难题。

了解云计算

幸运的是，在建立彭博体育业务时，我已经开始逐渐熟悉云技术。那时候，我对AWS非常着迷，而且先后多次参与到他们组织的会议与活动中。其中最吸引我的，当然是能够以按需方式配置服务器——这不仅打破了以往需要等待数个月才能用上基础设施的弊端，更重要的是，我还能够在不使用相关资源时将其关闭。很明显，这将是一种快速高效发布产品并降低运营成本的好办法。彭博当时的运营成本之所以如此夸张，主要原因就是我们在建立基础设施时需要以应用程序可能需要的最高容量为基准进行资源配置（也就是所谓“为峰值做好准备”）。但事实证明，我们的估算总是错的。我们一直在过度配置，这意味着我们将永远受到超支问题的困扰。

当时，我满心欢喜地希望启动首个使用公有云的业务案例。遗憾的是，我并没有足够的毅力或者影响力来说服公司内的决策者们，而且那时候的彭博根本不相信会有其他供应商能够提供超过其自身水平的基础设施服务（直到如今，很多大型以及成熟IT组织也仍然存在这种盲目自信的情绪——如果您也有类似的想法，相信本书能够为您带来一些启示）。

因此，我们选择了建设本地部署的私有云——在数月内利用一定程度的虚拟化功能使我们的终端外业务能够根据需求进行快速部署，当然可供选择的服务器类型仍然非常有限，且配置选项也相当基础。尽管远谈不上完美，但我们的成本管理难度开始快速下降。原本需要数个月周期的机架安装与服务器部署工作，如今几分钟之内即可顺利完成。

至少从特定几个角度来讲，这是一项非常成功的策略。第一，各独立业务的损益情况不再受到基础设施成本的影响，这也使得各项业务能够更公平地证明自身业绩的合理性。第二，服务器配置与业务开展所需要的筹备时间——这也正是我们面临的最大问题——开始沿着正确的轨道得以缩减。但不久之后，我们很快意识到服务器配置仅仅只是庞大的技术功能与业务需求体系中的一小部分。很明显，每项业务都需要向客户发送电子邮件，每项业务都需要自己的内容交付网络以加快响应速度，从而为客户带来更理想的访问体验。此外，每项业务都需要向其移动应用端发送推送通知。每项业务都需要提供API以访问彭博终端的数据，每项业务也都需要对这些API进行计量，以了解哪些数据存在于何处以及应于何时、由谁发送。

任何一位拥有大型IT部门从业经验的朋友，肯定都能明白其中的挑战所在。我们开始向每条业务线“征税”，并利用这笔资金开发“共享服务”以解决上述问题。我的团队也很快被视为资源消费中心，甚至被指责为拖慢业务发展甚至破坏业务目标的“罪魁祸首”。而在不断探索公有云的过程中，我意识到我们完全可以借助云服务供应商之力轻松应对这些挑战。我开始意识到私有云并不是真正的云计算，也无法真正高效地利用企业内部资源。

因此，2012年在道琼斯集团负责业务转型工作时，我提醒自己千万不要犯下同样的错误。

踏上云旅程

道琼斯集团是一家拥有125年历史的老牌企业，多年以来其在创新探索方面做出了不懈的努力。道琼斯负责供应超过200万份《华尔街日报》，每周六天向客户递送实体报纸。虽然很多人认为互联网才是有史以来最重要的发明，但必须承认，道琼斯通过优化出版与物流体系为报刊行业带来的生产效率与交付速度提升，同样值得大书特书。

道琼斯公司还发明了多种技术以压缩新闻报道的时间延迟，特别是作为专业信息业务（道琼斯内部将其简称为PIB）的两大核心支柱——道琼斯通讯社与法克提瓦（Factiva）。

然而与许多其他行业一样，新闻业务也因互联网的出现而受到了永久性的冲击。网络上大量出现的免费内容使得人们越来越难以接受以每月30～40美元的价格订阅《华尔街日报》。此外，报刊行业的广告收入也大量流向谷歌、脸书以及其他原生在线媒体企业的口袋。

与彭博一样，2008年爆发的金融危机对道琼斯及其专业信息业务带来的打击是致命的。与许多其他企业一样，道琼斯被迫采取一系列成本削减措施以将损益水平维持在合理的范围之内。此外，道琼斯还开始将大部分IT运营及产品开发工作外包给印度。

我个人对于IT外包并没有很强烈的支持或者反对意见。但是，如果要在日益数字化的世界中保持效力，每一家企业都必须保持自身快速高效构建、增强并优化面向客户的数字产品的能力。而对道琼斯来说，外包决策使其很难继续维持这种核心竞争力。

除了上述挑战之外，道琼斯的IT部门在维护现有基础设施方面同样感到非常吃力。道琼斯不得不延长折旧周期以降低成本，由此带来的后果就是硬件更新周期被进一步拉长。陈旧系统发生服务中断的频率往往更高，找寻相关技术人才的难度更大，而且运营成本也更为可观——特别是在主体外包模式中进行多次流程切换的情况下。

我在道琼斯公司的第一个职务，是参与一支小型研发团队，负责为公司提出多种多样的产品开发建议。时任道琼斯公司CEO的Lex Fenwick（他此前曾出任彭博公司CEO）要求我们以不同的视角看到公司的技术部署方式，并强调不要受到道琼斯现有架构与流程的限制。在Lex看来，《华尔街日报》的订阅者掌握着全球大量财富，而专业信息业务产品（包括法克提瓦以及道琼斯通讯社）的订阅者则管理着全球大量财富。如果我们能够建立起一套对话平台以供这些用户彼此沟通并开展业务，那么很有可能由此迎来新一轮发展与增长。巧合的是，对于我们这些曾负责彭博消息系统研发工作的人们来说，这个概念早已不是什么新鲜事物。

尽管在彭博构建共享服务的经历令人沮丧，但道琼斯赋予了我们以全新方式思考业务设计的自由，我也终于有机会证明公有云能够交付成果。在短短两个月之内，我们利用几种AWS服务配合一些开源技术整合出一套应用方案，并将成果摆在了高管团队与客户面前。

我们迅猛的推进速度使高管团队与领导层感到无比兴奋，人们渴望看到我们将这些经验应用到更为广阔的业务层面。但在另一方面，虽然一部分现有IT团队成员对新事物感到好奇，但也有不少人相当紧张——因为他们不确定我们的团队、方法以及所使用的技术会对他们的职位带来怎样的影响。

构建云基础

几个月之后，我有幸出任道琼斯公司IT部门CIO。我再一次在正确的时间身处正确的位置，而这一次，我拥有着足够的野心与干劲，希望真正转变IT部门在企业中所扮演的角色，进而真正帮助公司解决一系列突出的现实问题。

为了实现变革，我们提出了一项三管齐下的策略——我们将其称为“人、流程与平台”方针（那时候，我还没听过人、流程与技术的说法）。我们的目标是立足数字产品开发流程提升IT部门的贡献能力，从而彻底改变企业对于IT组织的传统看法。而且在我看来，每一位IT管理者都应该拥有这样的雄心与自我定位。

这里的“人”，是指更多专注对现有人才进行内包与投资。这意味着道琼斯需要雇用更多开发人员，建立校招计划，同时培训现有员工以帮助其获得过渡至不同职能角色所必需的技能。除了由供应商主导的培训课程之外，我们还需要为员工们提供充足的时间与预算，鼓励他们参加会议，引导他们为开源项目做出贡献，组织午餐学习会，并学习我们的榜样性企业。作为其中最重要的主题，我们将为每位员工的能力提供投资，以便他们能够在各自擅长的领域承担更多责任并获得更多主动权，最终对业务产生更为可观的影响。

我用尽了自己在彭博公司学习到的一切校招经验——包括每年招聘100多名应届毕业生出任软件工程师，同时与东北部、伦敦等地的十余所高校建立起合作招聘计划。每一年，高校毕业生们的出色能力和对先进技术的掌握都令我感到赞叹，我也欣赏他们“初生牛犊不怕虎”的闯劲与不受约束的良好思维习惯。随着时间推移，我们得以逐步缩小外包合同的规模，同时减少对第三方外包合作伙伴的依赖性。

整个流程的重点在于让各条业务线都能够更自由地进行实验并更快针对不断变化的客户需求做出反应。为此，我们实施持续性交付实践并简化了现有项目审批流程。相较于原本费时费力的“资本委员会”流程（业务负责人强制要求那些需要持续多年且前景不甚明朗的项目做出高达数百万美元的投资回报承诺，在我看来这完全是痴人说梦），我们建立起新的方法。我们为各个业务部门分配了固定的资源数量，并要求他们为自行设定的关键业绩指标（KPI）负责。每一位技术与业务负责人都需要监督客户需求的变化趋势，每季度审核KPI与资源分配方式，从而根据需要做出必要的调整。

最后，在平台方面，我终于获得了纠正自己在彭博所犯下错误的宝贵机会。我们非常清楚，这一次我们绝对不会奢望能够在自行构建并运营基础设施的情况下，保持与需求相符的快速行动力与竞争力。我们需要将员工的注意力集中在产品构建方面——其他一切可能分散注意力的任务都属于干扰性因素，必须加以排除。

建立专项团队

在彭博任职期间，我经历了一系列变革管理过程（其中有好也有坏），并深刻意识到只有首先建立起一支致力于推动变革并不断学习完善的团队，才能真正降低组织范围内的整体性变革门槛（后来我了解到，亚马逊公司由成千上万个负责不同产品或服务的独立团队所组成。他们将其称为“双披萨团队”，意思是团队规模不大，两块批萨就能搞定一餐。更多相关内容，我们将在后续章节中具体介绍）。

我也逐渐意识到，云规范实际上是将传统意义上彼此割裂的几大技术门类结合了起来。要构建并管理能够通过代码自动实现规模伸缩的应用，我们需要跨越软件开发、系统管理、数据库管理以及网络工程等多种技能范畴。此外，对大规模应用程序进行管理，还要求企业架构师将IT资源视为一种可随时使用、随时释放的元素组合，而非传统意义上具有静态名称、地址以及位置的物理服务器。

虽然企业内还有不少人对我的领导力以及我们制定的发展战略持怀疑态度，但也已经有一些不同部门的同事对我们的方向感到兴奋。我们将这些人聚集起来，收编到专项团队中，并委托他们对提升云端应用程序运行能力所需要的最佳实践、参考架构、治理与控制等素材进行编纂、宣传与推广。

大约就在这一阶段，DevOps运动开始在业界获得广泛关注。虽然我一直坚持认为DevOps理念并没有带来什么真正的新发明，但我仍然很欣赏这轮运动在软件开发最佳实践层面为众多企业带来的语言与认知。有些朋友可能对此还不熟悉，DevOps基本上就是将软件开发（Dev）与生产运营（Ops）最佳实践加以结合的理念。举例来说，2001年还在彭博工作时，我们就一直在推动“谁构建谁运行”以及“了解你的客户”等战略，这也是我职业生涯中唯一的生产性软件环境参与经历。本书后面将要出现的Mark Schwartz在对本章节内容的讨论过程中，对DevOps提出了一些有趣的新颖解读：“开发与运营相结合的理念，实际上是一种倒退——退回到人们分工还没细化，每个人啥都得干的阶段。”

因此，虽然我意识到DevOps所表达的更多是一种文化存在而非具体的群体，但我们仍然会故意通过命名将群体与文化运动结合起来——这就是所谓“DevOps团队”。这是为了强调这类团队在改变自身职能角色时所表现出来的行为文化。DevOps团队的主要职责在于确保所有团队都能运用DevOps理念，并为他们提供所需的工具与功能。

此后，我们提出三项团队原则并加以推广，这些原则的灵感皆来自于DevOps运动。

第一项原则，就是DevOps必须将应用程序团队视为付费客户。根据我的经历，基础设施与应用程序团队之间往往很难融洽相处。基础设施团队认为应用程序团队是一帮自以为是的“牛仔”，他们倾向于牺牲长远利益而满足短期可交付的成果。而另一方面，应用程序团队则认为基础设施部门的行动缓慢，无法理解应用一方需按承诺按时交付开发成果的压力。在经历了几次服务中断与项目交付拖延之后，我发现两方之间已经出现了相互指责的迹象，而我需要尽自己所能消除这种隐患。我需要让双方意识到，大家都从属于同一团队，彼此间是荣辱与共的关系。虽然我们一直没能找到一种理想的成功衡量方法，但我们仍然需要不断重申这一宗旨，并敦促各个团队尽可能将自己的目标用户视为付费客户。

第二项原则，就是DevOps必须以自动化方式处理一切任务。我们当时的观点是，如果要在云环境中部署任何负载，那么首先需要利用一套云原生架构“正确”完成负载构建。我们希望以自动化方式对应用程序进行部署与规模伸缩，从而实现快速迭代并不至于为容量规划工作而分神。在下文中我会提到，我们最终意识到“正确”的方法绝不仅于此，并在一次直接迁移案例当中深切体会到了这一点。关于详情，我将在第7章加以阐述。

第三项原则，是DevOps不会对所在业务线已被部署至云端的相关应用程序负起运营责任。我们的目标在于建立“谁构建，谁运行”文化，而各条业务线虽然会采用由DevOps团队提供的最佳实践、参考架构以及无条件执行的原则，但DevOps团队并不需要对应用程序的持续运营与变革管理负责。一旦各业务体系部署了自己的方案，内部人员就需要自行拥有并维护这些负载。通过这种方式，各应用程序团队将能够持续创新，并避免令DevOps沦为新的命令与控制瓶颈。

我们DevOps团队由小处起步，刚开始大家能力有限也不太清楚该如何运作。但随着经验的持续积累，我们变得愈发明确——特别是在安全性与变革管理层面。我们一直努力在无条件执行中保持适当的平衡，确保各个业务部门为自身项目实施负起责任，同时协助他们有能力运用新的工具、服务与开源技术实现创新。

扩展云能力

随着团队行动速度的加快，我们当然也希望扩大DevOps团队的规模并提高变更的实施效率。我们在每月的员工大会上推广我们引以为傲的进度成果，同时鼓励对此抱有兴趣的同事们拥抱这种变化。在每一季度员工大会的结尾，我都会热情邀请同事们加入DevOps团队。每一次，我们都为找到更多志同道合的新朋友而兴奋，而他们也乐于成为DevOps的一员。一般来讲，我们会故意保留他们加入DevOps后留下的原有岗位空缺。举例来说，如果新加入的朋友是负责支持道琼斯通讯社的系统管理员或者网络工程师，在过渡为DevOps成员之后，我们的DevOps将迎来更强大的运营能力——这将直接抵消职位空缺带来的能力缺失。

这是一种确保应用程序团队高效运用DevOps理念的好办法。其中各类资源都在不断增长，但有时也会带来一些混乱与干扰。因此，我只希望快速实现变更，并乐于为能接受期间所出现错误的朋友们推荐这种方法。虽然在此期间，遇到了几次必须加紧处理的升级以及小规模服务中断，但我们从中学到了很多，而且每一次主观判断都进一步增强了我们实施变革的决心。

我们还没有出台具体的所有遗留系统迁移上云的计划，那时候我们的运营模式正是当前大家常说的“混合型”架构。所有新功能都利用DevOps团队开发出的参考架构被部署在云环境之内，但也会在必要时与内部系统进行通信。

DevOps团队负责制定各项最佳实践并构建功能，从而确保这套混合架构运作良好；这些功能则随着需求的成熟与时间的推移，而变得越来越复杂。虽然我们希望尽可能限制DevOps团队对各业务应用线的运维掌控（这些应用该由应用程序团队自身掌控），但不可否认的是，DevOps团队使用并运营我们提供的混合架构，并管控一系列为了确保成本可管理性与云资源合规性而发布的工具及无条件要求。

Milin Patel作为当时DevOps团队的负责人，做过的最具影响力的大事之一就是建立起一套称为“DevOps日”的课程。在为期两天的课程中，有半天时间都在教授AWS基础知识，另外一天半则主要探讨如何运用DevOps团队提供的参考架构、最佳实践以及治理方针。除了成为团队培训的好素材之外，这套课程还帮助我们从已经掌握相关知识的同事们那里获得大量反馈信息。

虽然当时完全没有想到，但上述举措确实成为发展历程中的重要转折点。随着经过良好培训的道琼斯员工开始向其他员工传播正确的知识与理念，我们原本面临的内部阻力开始快速消退。到这时，真正决定一切的已经不再是置身于事外、并不了解现场情况的高管人士，而是有能力自行构建功能并加以运用的相关团队。这是我们共同的发展目标，我们在这条道路上也一直彼此相伴。要说唯一的遗憾，就是我们没能早点推进这项运动。

在团队进行了第一次迭代并完成一系列改进之后，我们决定把“DevOps日”活动纳入新员工培训计划。每年夏季，我们都会通过校招计划引入几十名应届毕业生。他们将在这里通过“DevOps日”了解我们的工作方式、使用的工具与技术以及关于各条业务线的一点入门知识。通过这样的过程，他们能够更轻松地适应道琼斯的氛围，并了解哪种业务最适合自身的技能储备与发展预期。此外，这也减轻了招聘小组的工作压力，意味着他们能够设定一些能力基准，用于考核将要加入各支团队的新人们的实际水平。

迁移单一数据中心

在经过约一年的探索之后，我们开始面临一个与原本转型思路完全不同的新机遇。当时，我们位于香港的数据中心由于租约到期而需要搬迁。我们有两个月时间处理这项工作，而我很希望能借此机会推动云迁移工作的进程。然而，团队中很快就指明了其中的几个风险点。

首先，大家都觉得两个月时间根本不足以重新设计出一套完整的云原生数据中心（换句话说，这段时间不足以让我们重新编写应用程序，从而充分利用公有云中的自动规模伸缩等重要特性）。这时，我们开始第一次考虑放松“以自动化方式处理一切任务”这项原则，决定接受直接迁移的方法。这引起了不少争论，因为我们假设这种方法将不可避免地带来更高成本。然而，由于数据中心规模不是很大（只包含数百台服务器），加之认定数据中心已经不适合我们的长远发展目标，因此我们最终仍然选择了这一处理思路。

其余的风险主要集中在技术层面。我们当时在运行一套硬件负载均衡器外加一套硬件WAN（广域网）加速器，这些在大家看来都是至关重要的基础设施。此外，我们还依赖于大量当时AWS关系数据库服务，RDS还无法支持的数据库功能，因此我们实在没办法直接将其迁移为托管服务的形式。

在我看来，我们只能拿出基于已有经验和能力的解决方案，尽管我们的团队已经给出了令人印象深刻的表现。

不过很快，我们的一位DevOps工程师就发现我们原本使用的WAN加速器与负载均衡器功能完全可以利用AWS Marketplace上的软件实现。在几天之内，我们就购买、启动并配置了这两套组件——且几乎没有对整体运营流程造成任何显著影响。

接下来，我们开始将数据库服务器迁移至Amazon EC2实例中——注意，我们并没有选择托管Amazon RDS实例。虽然这种作法迫使我们仍然需要自行管理数据库服务器，但这至少要比租用大量数据中心设施要好得多。

我们在大约六周时间内基本完成了迁移工作。虽然结果并不完美，但还是大体达到了预期。我们在从位于新泽西的主数据库进行连续复制时遇到了一些延迟，这主要是由于我那时不愿意付费使用AWS Direct Connect服务（这项服务允许客户在自有设施所在位置与AWS Direct Connect位置节点之间建立专用的网络连接）。我们最终总结出了一套正确的数据库配置方案，从而快速解决了问题（当然，最终我们还是安装了AWS Direct Connect）。而且即便如此，我们遇到的问题大多属于运营负担，而不会对客户造成实际的影响。

接下来，我们又遇到了不少有趣的情况。之前，之所以确立了“以自动化方式处理一切任务”的原则，是因为我们认为如果不面向云端进行优化，那么其运营成本将高于内部方式。然而在此次迁移中，虽然并没有从根本层面调整架构，但直接迁移上云仍然带来了高达30%的成本节约效果！

大规模迁移

大约在同一时间，我们开始关闭位于香港的数据中心，母公司新闻集团也开始考虑将现有投资组合中的7家公司（包括道琼斯）所掌握的IT基础设施集中到统一的运营体系之内。这项工作的目标，当然是为了提供企业整体效率并削减运营开支。时任新闻集团CTO（目前出任21世纪福克斯公司CTO）的Paul Cheesbrough开始在各新闻集团子公司之间进行宣传游说，而我们则着手考量更大规模的数据中心迁移对于所有人究竟意味着什么。

通过面向新闻集团下辖各公司进行的商业案例研究表明，如果能够将遍布全球的50多座数据中心合并为6座三级与四级数据中心，同时将75%的基础设施迁移为云服务（其中包括采用Salesforce、Workday以及Google Apps等软件即服务），那么我们将能够在未来三年之内获得年均超过1亿美元的成本节约额度。这笔巨资，显然可以花在更多有望带来收益的行动上。

不止是IT部门，这一商业案例研究引起了新闻集团全体高管的一致关注，敦促我们从零散方式改进转变成整体技术改变。根据他们的要求，我们将获得一笔数额可观的支持资金，并需要通过一系列不同迁移策略尽快完成传统系统的云迁移（具体内容将在第6章进行详细阐述）。

大约一年之后，当我决定前往AWS任职时，我们已经将大约30%的基础设施迁移为云服务。这一进度比新闻集团定下的75%基础设施迁移比例的计划进度略慢。如今，也就是近四年之后，基础设施的迁移比例刚刚超过60%。但是，道琼斯只用了两年多时间就达成了“获得年均超过1亿美元的成本节约额度”并将之用于有望带来收益的行动的目标。

文化是一切的根基

虽然为上述财务成果感到自豪，但更令我骄傲的，是这项举措彻底改变了我们的企业文化。道琼斯公司的技术部门成为业务发展的有力推手，各级员工也开始意识到技术部门完全有能力在交付给客户的产品中产生非常积极的影响。在过渡期间，我们的正式员工与合同工数量分别由400名与1100名，快速变化至450名与300名。公司减员幅度相当明显，但更重要的是拥有更高积极性的参与者们能够更好地集结起来，真正立足产品领域快速行动，并最终给客户与业务带来收益。

在准备离开道琼斯，出任AWS公司的新职位时，来自MarketWatch.com的工程技术经理Kevin Dotzenrod为我准备了一份送别礼物：一份附有图表的电子邮件，其中展示了我在职最后一个月中所发布的软件数量。通过这次转型，工程技术团队不再固定选择每周二与周四（如果顺利的话）才发布新版本。就在这一个月内，我们完成了数百次发布——全部工作完全以自动化方式进行，且仅需要构建变更的开发人员参与其中。

我很清楚，上述案例有着重大的积极意义，但很多读者朋友可能也意识到我忽略了其中存在的一些严峻挑战。没错，这些变更非常困难，我也遇到过大量解决方案遭受质疑、个人可能被辞退，甚至是打算撂挑子放弃的情况。在做出判断时，我们经常身处于信息不完整且风险不可知的情况之下。总而言之，对于组织中的每位成员，这都是一次宝贵的学习过程——但不太适合保守的“胆小鬼”。我在后续章节中提到的很多观点，实际上正源自这次尝试中出现的挑战（以及无数我曾经接触过的其他企业的真实经历），而用于克服这些难题的策略同样来源于此。

将这种经验带给他人

经历了这一番起起落落，我意识到每一家公司都有必要审视自身，考虑如何演进自身文化以进一步提升技术在其中的重要作用。在这方面，没有哪种推动因素比云计算更具力量。

也正因为如此，我最终选择了AWS公司。目前，我的工作是帮助高管团队从已经完成云转型旅程的企业身上汲取最佳实践，从而利用云资源推动其人员、流程以及技术的全面转型。我觉得自己非常幸运，能够有机会与众多出色的高管人士及企业共同学习。也希望大家能够通过本书了解到我在工作中学习并整理出的一些重要内容，进而指导您自己的云探索道路。