下载掌阅APP，畅读海量书库
立即打开
为了拥抱云计算并创造出在云计算中规模化构建和运行软件的能力，IT领导者需要先退后一步，围绕云计算重新设计他们的组织。我们必须重新思考整个软件开发的价值流，从想法构思到生产运行。
不存在两个完全相同的云转型，但是成功的模式和失败的反模式是非常常见的。在云计算领域取得成功的公司往往经历了许多失败并从中汲取教训。没有人能在一开始就做好，但如果你在开始转型时就预期会遇到一些困难和挫折，那么可以开始前进了。你的企业必须具有透明和持续学习的文化，而且你应该期望持续地调整和改进。
在AWS re:Invent、Google Cloud Next或DevOps Enterprise Summit等技术大会上，你会听到很多成功的故事。那些没有如此成功的人可能会感到沮丧，因为似乎其他所有的公司都做得很好。不要被愚弄了！大多数成功故事讲述的只是一个庞大组织中的产品线或业务部门，并非整个组织，组织的其他部分可能仍处于非常早期的阶段。请不要灰心，本书将分享一些经验教训，告诉你在踏上云之旅时应该做什么，更重要的是不要做什么。
有什么比一开始做对更重要的吗？有，那就是立即开始。太多的组织过于专注创造完美的低风险战略，不断更换CIO和咨询合作伙伴，以至于他们从未真正开展这项工作。他们只有多年的战略文件和PPT来展示他们的努力，而他们的竞争对手却在云成熟度曲线上一路高歌猛进。
在这一步陷入困境的组织往往不会将云计算视为一种转型，而是视为一种技术类项目。一些公司非常保守，它们给云上所有重大推进的努力都设置了过多的限制。比起迁移上云遇到的可用性和弹性方面的问题，这可能更像是一种失败。至少对于后者来说，你获得了经验并增加了成熟度。
当公司没有认识到需要进行自我转型并以不同的方式构建、运维和思考软件的需求时，它们就会把旧有的业务流程、工具和运营模型带到云上，而这几乎总会导致转型失败。
自2013年以来，我一直从事云转型相关的咨询工作。我见过几乎所有你能想到的客户要求，这些客户来自各种云成熟度的公司。为了捕捉这种变化，我在图1-1中创建了成熟度曲线。该图显示，当大多数组织开始云计算之旅时，它们关注的是迁移到云计算的ROI。在旅程的早期，它们认为云与数据中心是同一上下文：它们考虑的是服务器而不是服务。与通过云计算实现的价值相比，它们从这种心态中获得的价值要低得多。在积累了云中构建和运行应用程序的经验后，它们开始向上移动技术栈，并使用平台即服务（PaaS）解决方案或云服务商的完全托管服务，如数据库即服务。这样它们能够获得更快的产品上市速度和更高的运营效率。随着继续上移技术栈，并开始拥抱云原生和无服务器架构的概念，它们开始高速创造业务价值。在这个成熟度级别上，云的全部承诺都可以兑现。问题是，很少有人能够通过ROI分析和基础设施即服务（IaaS）的思维来接近理想的ROI。
图1-1：云成熟度曲线，你的组织位于何处
在我刚开始的时候，面对的大多数客户要么要求一个整体的云战略，要么希望我对云提案的总拥有成本（TCO）或投资回报（ROI）进行分析。当时，要说服CEO和董事会相信云计算是未来的发展方向，对于IT领导者来说是一件艰难的事情。大约80%的需求集中在私有云上，而只有20%的需求是针对公有云的，而且几乎都是AWS。2013年11月，在一年一度的AWS re:Invent大会上，AWS宣布了一系列新的企业级安全特性。几乎在同一时间，我的电话就开始响个不停，很多客户都在寻求公有云实现方面的建议。一年后，这些客户的工作需求完全反转，超过80%面向公有云，只有20%面向私有云。
随着逐渐采纳公有云，公司迁移到云端或在云端构建新的工作负载的速度要比传统部署软件快得多，这时两种常见的反模式出现了。
开发人员、业务部门和产品团队现在可以访问按需供给的基础设施，利用它们来更加快速地推出产品。他们没有指导方针或最佳实践，开发团队承担着前所未有的责任。相比构建一个体系化方法并在整个组织中实施，许多公司只是简单地将云端决策留给组织的各个部分，以一种无法无天、“狂野西部”的方式。
以下是两家公司的故事。Alpha Enterprises（我这样称呼它）有5个业务部门（BU），每个BU都有自己的开发和运维团队。集中化的IT团队一直为各BU提供基础设施服务，BU对于IT团队漫长的交付时间和不佳的服务体验非常不满。各BU将云计算视为一个与IT脱离并加快交付速度的好机会，它们都能在云上成功地部署一两个应用程序。但不幸的是，当它们增加更多的应用程序时，并没有做好支持这些应用程序的准备。于是客户开始体验到低于过往所习惯的可靠性。
然后有一天，危险的“心脏出血” [1] 漏洞出现了。安全和操作系统团队忙于给整个组织中受影响的系统打补丁，但是它们无法看到BU基于云构建的系统的公开情况。安全团队花了数周时间访问并全面修补这些系统中的漏洞。几个月后，安全部门进行了一次全面评估，发现还有两个系统从未打过补丁。
故事的另一方，BetaCorp有一个中央IT团队，负责构建和管理所有经批准的操作系统。BU使用一个标准构建流程，用于从中央团队的存储库中提取最新批准的操作系统。当发现系统漏洞后，中央团队更新操作系统镜像，并发布新版本。BU方便地使用最新的操作系统补丁版本来重新部署其应用程序，BetaCorp所有云端应用上的这个漏洞在同一天内消除了。
Alpha Enterprises以及类似的公司面临的一部分问题是，每个BU都在重复造轮子：研究、购买并实施自己喜欢的第三方工具，用于日志记录、监控和安全性等方面。它们各自采用不同的方法来设计和保护环境。很多BU还使用差异巨大的流程实施其各自的持续集成/持续交付（CI/CD）工具链，导致整个组织中工具、供应商和工作流的碎片化。
这既有积极的影响，也有消极的影响。像Alpha Enterprises这样的公司向客户交付价值的速度比以往任何时候都快——但也经常比以往更多地暴露在安全和治理风险中，同时交付的产品弹性也更低。这种严格和治理的缺乏使得生产环境不可预测且不可管理。
与放任自由的“狂野西部”反模式相反的是一种军事化、自上而下、命令与控制的方式。在这些公司中，那些高度积极主动去保持秩序的团队（如管理、基础设施、安全和GRC团队）对公有云访问进行约束。它们建立了高度封锁的云服务和流程，使得在云上开发软件变得很麻烦。这些流程通常有几十年的历史，是在每年部署两到三次的时期设计的，且由独立团队负责的物理机组成基础设施。
让我们看另一个例子。一家成熟的医疗保健公司（我将其称为Medical Matters）收购了一家崭露头角的初创公司CloudClaims。CloudClaims已经构建了一个基于云计算的索赔处理应用程序，该应用程序将仍处于行业标准的纸质化索赔流程进行了自动化。相比过往数周的时间耗费，CloudClaims在当天就能完成索赔。当Medical Matters的安全和风险团队评估公司收购的新技术时，它们震惊地发现，代码构建和生产部署竟是同一个团队。它们将这一职责从CloudClaims的工作人员身上拿走，并要求他们遵循Medical Matters已经执行了20年的标准化的、经过验证的流程。
突然间，部署频率从一天三次降到了一月一次。过去完全自动化的流程现在必须分解成各个步骤，以允许架构和安全评审会议、每两周一次的变更控制委员会会议，以及来自两级主管的电子邮件批准。CloudClaims开发人员对这些流程提出了质疑，甚至向高管展示了为什么他们原来的自动化流程比被迫使用的新流程风险更小，但Medical Matters不肯就此让步。最终，CloudClaims团队的核心成员离开了Medical Matters，产品本身也开始失去价值，因为它不再能以曾经拥有的速度对市场需求做出响应。
Medical Matters的方法破坏了云计算的一个关键价值主张：敏捷性。我见过一些公司花了6个月的时间在云上供给一台虚拟机（而实际上只需要5分钟），就因为命令和控制监察强制云开发人员使用与数据中心相同的工单和审批流程。
这种方式创造不了多少价值，即便公司在战略和政策工作上投入了大量资金，打造的内部平台也无法满足开发者的需求。更糟糕的是，这种方式制造了一个反叛的“影子IT”，就如在Alpha Enterprises所做的那样：小组或团队开始运转他们自己的迷你IT组织来完成工作，因为他们的需求没有办法通过官方渠道得到满足。
这些反模式提高了人们对关注云运营和创造新云运营模型的意识。自2018年以来，我的客户一直呼喊着为他们的现代化运营提供帮助，并设计新的运营模型。如今许多客户已经踏上这样的旅程好几年了。
在云转型旅程刚开始时，企业将大量注意力集中在云基础设施上。它们在这个阶段学到了很多东西，提高了在云中构建软件和防护措施的技术能力。它们通常从IaaS层开始，因为多年的物理基础设施工作使其能够适应云端基础设施。随着企业云经验的成熟，它们开始意识到云的真正价值在更高的层次上，这时它们开始研究PaaS和SaaS（软件即服务）。
与此同时，开发团队已经采纳高水准的自动化并使用CI/CD等概念。本书将介绍DevOps、云原生架构、基础设施即代码和云计算等概念是如何改变传统运营的。
[1] Synopsys将“心脏出血”（ https://heartbleed.com ）描述为一个漏洞，它“允许互联网上的任何人读取受OpenSSL脆弱版本保护的系统的内存”。这破坏了用于标识服务提供者和加密流量的密钥、用户名和密码以及实际内容。使得攻击者可以窃听通信，直接从服务和用户那里窃取数据，并假冒服务和用户。