云计算转型：超越基础设施思维的云迁移方法

从过去的错误中吸取教训，重新理解公有云采用

在云计算发展到今天这个阶段，再来谈“如何采用云计算”，似乎有些奇怪。毕竟，许多人认为公有云已经是一个成熟领域，既有成熟实践，也有大量成功案例。对于刚刚起步的组织而言，市面上似乎已经有足够多的建议，足以帮助它们规划并执行云转型。

然而，尽管相关信息已经十分丰富，我仍然看到许多组织在上云过程中举步维艰。许多初衷良好的云迁移项目，在试图把“按需、弹性计算”的承诺转化为切实、可衡量的业务收益时，往往遭遇挫折，甚至陷入停滞。

诚然，关于如何“构建”优秀的云系统架构、如何安全地设计复杂的计算环境和网络拓扑，业界已经积累了大量文献。但关于如何设计组织架构、如何采用能够充分释放高度虚拟化潜力的运营模式，相关讨论仍然非常不足。

最终，我看到许多企业在急于上云的过程中，忙于重复过去的错误，创造出大量难以持续维护的资产：轻则维护成本高昂，重则根本无法维护。企业积累技术债务的速度，远远快于偿还技术债务的速度。它们创建出一次性的、难以复制的环境，甚至连最基本的质量检查都未能落实。从长远来看，这些资产的维护成本，很可能远远超过从本地数据中心迁移到公有云所节省的成本。

本文将尝试指出企业在云迁移和公有云采用过程中常犯的一些错误，并提出一种替代思路。我希望推动一种不止关注基础设施的云采用方法。我坚信，向公有云转型的影响极其深远，以至于企业必须重塑自身的业务模式与组织能力，才能真正与之适配。

我们不能再沿用过去那些曾经有效——或者本就无效——的企业文化、组织结构、角色分工、工程实践和供应商选择方式。所有这些都需要与时俱进，超越那个由独立基础设施专家团队在物理设施中构建和维护软件托管环境的时代。虽然专业分工依然存在，但如今，我们只需几行代码就能重新配置一个虚拟数据中心。这种能力本身，就要求我们采用完全不同的方法。

为什么企业云迁移的成功如此难以实现？

在我的职业生涯中，我多次看到同样的模式反复上演：一项新技术出现，被誉为未来趋势；行业分析师绘制象限图，评出赢家；企业则理所当然地认为，只要选中了“赢家”，就能避免学习一门新学科所必需的艰辛。

它们以为，只要选对 IT 外包伙伴，并严格控制成本，商业收益就会自然出现。然而，事实并非如此。真正能在新技术领域取得成功的企业，往往会主动调整自身的组织架构、运营模式和工程能力，以适应新的范式。在许多情况下，它们甚至还需要调整自身的商业模式。

就公有云而言，这种误解的一种典型表现，是把云仅仅视为另一种形式的基础设施。于是，云的管理职责被交给过去负责数据中心和物理网络的基础设施团队或运维团队。通常，这些团队以服务形式为组织其他部门管理固定资产。当基础设施团队成为企业云资源的保管者时，云实际上就变成了既有基础设施的延伸。这种做法非常常见，并且常常催生所谓的“混合云”部署：公有云计算资源在理论上可以无缝扩展本地资产。

这种做法看似合情合理，在一定程度上也确实行得通。但它并没有充分认识到，云计算专家和行业分析师所承诺的那场技术革命，对企业而言究竟蕴含着多大潜力。

在由基础设施团队管理云资源的组织中，云环境往往像稀缺的资本资源一样被分配。数字化交付团队通常必须提交支持工单来申请云环境，然后等待人工或半自动化配置完成。而在云原生世界中，这种做法显得毫无意义：资源本应充裕，配置也本应通过代码快速完成。即使企业担心安全或合规风险，也完全可以在不牺牲按需自助访问能力的前提下加以控制。

这种做法背后存在一个根本性误解：人们认为云计算只是硬件基础设施的虚拟化形态。但云计算并不是硬件；它本质上是软件。

那些把云部署交给基础设施团队或运维团队的企业，绝不会想到把一个耗时多年的大型软件开发项目交给同一批人。但云部署的本质恰恰如此：它是一项大型的、跨学科的软件交付工作。

如今，即便是中等规模的软件开发项目，也离不开产品负责人、体验设计师、经验丰富的软件技术负责人、自动化测试和质量保证等关键能力。但我见过许多云迁移项目，却完全缺乏这些专业的软件开发能力。有时项目中会出现一个所谓的 DevOps 团队——这本身就有些自相矛盾——但它仍然被视为“云专家团队”，而不是一个完整的软件交付团队。

企业在急于上云时还常常陷入另一个陷阱，而这个陷阱也会限制它们的长期成功：与单一云供应商建立起难以割裂的深度依赖。

这并不是一个新问题。行业在管理 IT 外包方面早已积累了丰富经验，大多数专家也都认同，企业必须对外包服务安排保持控制力和灵活性。

几年前，我曾与一家大型金融服务企业合作，帮助它们摆脱原先选定的数据库供应商。当时，开源数据库已经发展成熟，性能足以媲美甚至超越该供应商的产品；开源平台也开始提供商业支持。与此同时，那家商业数据库供应商对客户需求的响应却越来越迟缓。听起来事情应该很简单，对吧？毕竟 SQL 是标准语言。

然而，整个项目耗时漫长、成本高昂，最终也未能真正帮助客户彻底淘汰该数据库供应商的产品。

任何在这个领域工作过的人，都不会对原因感到陌生。多年来，供应商在其基础产品中不断引入各种“节省时间”的专有功能。数据库管理员们经不住诱惑，纷纷使用这些功能，并在缺乏常规软件工程保障措施的情况下，直接在数据库平台上实现大量业务逻辑。他们还使用了专有 SQL 扩展，以便更轻松地存储和检索时间序列、图像等数据。

但真正扼杀可移植性的，是供应商庞大产品套件中那些隐蔽的集成关系。集成适配器采用专有的点击式配置，严重依赖供应商优化过的存储设备，并与供应商的身份和访问管理平台自动集成。所有这些错综复杂的关联，使得解耦工作缓慢而繁琐。当然，那些在引入新功能时提供大量帮助的供应商顾问，在客户试图放弃这些产品时，往往无能为力。最终，客户只能无奈接受现实：有些系统只能勉强维持，直到不再有终端用户使用为止。

尽管这并不是什么新鲜事，今天的许多组织似乎并未真正吸取教训，反而急于押注某一家云服务商。部分原因在于，长期以来，某家海外云服务商占据市场主导地位，几乎一手塑造了云计算这一概念，其产品和服务也曾显著领先于竞争对手。

但如今，寻求公有云服务的企业已经拥有更多选择。几家主要海外云服务商在基础服务方面日益同质化，并且正在激烈竞争，以争夺更大的市场份额。它们的定价、服务组合和商业模式，都在鼓励云客户使用更多服务，并充分利用各家供应商独有的差异化能力。问题在于，这些专有能力往往很难从一家供应商迁移到另一家。

有时，这对客户确实有利。云服务商争相提供无缝、低摩擦的开发者体验。但单一供应商锁定也带来了风险，其中最主要的风险在于：IT 决策权会从企业手中转移到供应商手中。

我看到越来越多企业日益依赖它们选定的云供应商，而它们实际上并没有真正有意识地做出过这一选择。如今，许多企业事实上已经与云服务商建立了深度业务伙伴关系。它们的业务成功在很大程度上取决于云服务商的成功。然而，这种依赖关系很少是对等的。

你或许会认为，现有云服务商规模庞大，几乎不可能倒闭；这种失败风险微乎其微，不值得因此放弃与供应商深度合作所带来的巨大生产力提升。然而，商业伙伴关系破裂的原因有很多。性格冲突、利益冲突、账单纠纷、安全问题等，都可能迫使企业更换云服务商。

如果那一天真的到来，而你发现将核心业务资产从原供应商或合作伙伴那里迁移出去的成本高得难以承受，又该怎么办？

当然，这种情况并非云业务独有。我曾参与过许多 IT 平台重构项目。在这些项目中，退出平台所需付出的巨大且不可避免的成本，既未被预见，也从未被纳入商业计划。只是面对云计算这样意义深远、潜在收益巨大的技术变革时，过去的经验教训似乎尤其容易被遗忘。

企业全面采用云计算的四个维度

我注意到，最成功的云采用策略，并不仅仅是平台重构，而是采取了全方位的变革方法。只关注基础设施，也许能够降低成本；但若想真正提升营收、扩大市场份额或增强创新能力，企业的应对必须更加全面。

从本地基础设施迁移到云托管，只是第一步。要最大限度释放云迁移带来的业务价值，需要重点关注以下四个方面。

技术卓越：提升云原生工程能力

云本质上是软件。要有效利用云，企业必须投资于软件工程能力。云原生工程并不只是使用供应商提供的服务，它还要求我们重新思考关于韧性、弹性和应用设计的一些常见假设。基础设施即代码的质量要求，应当与面向客户的系统一样高。成功的软件交付应当尽早、频繁地创造业务价值。云实施同样不应例外。

自主性与协同性：让交付团队真正拥有云资源

从由专家维护、托管在远程数据中心的物理资源模式，转向软件定义的网络、计算、存储和支持模式，对组织而言是一场重大变革。交付团队现在需要负责定义和维护自身的托管环境。安全、合规、战略协同和支持等职责，也都需要向前移动，嵌入到交付流程之中。

自助式平台：释放云计算的开发者生产力

云供应商通过 API 和广泛的教育推广，让用户能够更便捷地访问托管环境。如果企业希望获得云计算所承诺的生产力跃升，就必须把这种便捷的访问能力传递给企业内部开发人员。企业内部的自助式云平台，应当围绕更快推出以客户为中心的数字化产品而优化。

供应商选择：建立有意识的多云战略

每一家企业都需要多云战略。所谓多云战略，并不一定意味着所有系统都必须部署在多个云上。它可能意味着企业经过权衡后，愿意接受对单一供应商的依赖风险，以换取开发人员生产力和更优惠的价格。但这必须是经过深思熟虑的选择，而不是一系列无意识行为的结果。

了解每家供应商所提供的独特服务同样至关重要。只有这样，企业才能在多种选项中做出主动选择，而不是被单一供应商绑定，最终只能被动接受它所能提供的一切。

技术卓越：把基础设施当作软件来管理

能够完全通过 API 配置资源并管理其运行，是公有云最显著的特征之一。这不仅为我们提供了一个接口，使我们能够定义最复杂托管环境中的几乎任何内容，而且还让我们能够以统一且一致的方式完成这些操作。

这深刻改变了我们对这些资源的思考方式。最终，当然仍然会有人在某个地方、某个时间架设服务器、铺设线缆、配置交换机、构建内核等等。但对大多数人来说，为应用程序创建托管环境，已经完全成为一项可以在办公桌前完成的软件开发活动。

诚然，要把这件事做好，除了普通编程知识之外，还需要掌握大量额外知识。但如今，大多数基础设施的创建，本质上已经是一种软件开发活动。

既然是一项软件开发活动，它就要求我们在代码模块化、耦合度、意图清晰度和可测试性等方面遵循相应规范。这些实践至关重要，因为企业真正宝贵的资产，不再是基础设施本身，而是定义基础设施的代码。如果这些代码的编写和演进没有遵循成熟的工程实践，其维护成本将高得难以承受。

自主性与协同：云治理不能只靠审批流程

影响组织成功迁移到公有云的因素有很多，其中包括：

• 托管决策权从基础设施专家转移到普通软件开发人员手中所带来的影响；
• 云计算技能短缺，或这些技能集中在少数专家手中，对云成功造成的阻碍；
• 缺乏透明度可能导致云成本意外飙升；
• 如何核算云使用量：按量计费的云使用量本质上并不是资本支出，公有云成本核算与固定部署的本地基础设施截然不同，也必须将淘汰传统基础设施所节省的成本纳入考量；
• 如何正确衡量影响：实用工具和富有吸引力的开发者体验，往往比设置关卡和审查委员会更能实现有效治理。

公有云管理高度软件化的特征，以及开发人员能够定义和配置自身托管环境的能力，使得更多托管决策权从传统运维团队或基础设施团队转移到软件交付团队手中。企业只有能够围绕自主团队组织数字化交付，才能最大限度释放公有云的价值。这些团队必须被赋予自主决策权，同时也必须对其决策的实施和支持负责。

当然，赋予团队构建、拥有和运营自身资产的权力，并不意味着它们可以完全脱离治理，也不意味着它们可以与整体业务目标脱节。成本管理、人员配置灵活性、可预测性、安全性和合规性，都是企业需要制定总体愿景和架构决策框架来管理公有云使用的重要原因。

这种组织层面的架构方向，应当为一线团队提供必要的工具和知识，使其能够达到卓越的技术标准，并对应该使用哪些云服务、哪些云服务不应使用，做出明智决策。此外，组织还应提供充分的指导原则和标准，使团队能够构建本质上安全且合规的托管环境。这可能包括自动化基础设施扫描工具、经批准的构件、预配置的网络拓扑，以及软件供应链验证机制等。

在这一过程中，组织还需要让团队协作、任务推进、文档沉淀和审批流程保持透明。对于需要统一管理项目、任务、目标、文档、日历、甘特图、工时和审批的团队来说，Worktile 这类通用项目协作系统可以作为协同层工具，帮助不同团队在云迁移过程中保持节奏一致，减少因信息分散而带来的执行成本。

自助式平台：避免削弱云原生的核心优势

早在企业开始认真考虑将公有云作为托管关键业务应用的可行方案之前，公有云就已经点燃了全球软件开发者的想象力和热情。开源社区为应对一项在当时堪称革命性的能力——完全通过 API 操控任意复杂的架构——发明了许多将公有云基础设施定义为代码的实践和工具。

这种能力以前所未有的方式，将权力和生产力直接交到了开发者手中。反过来，这种新获得的生产力又催生了许多数字化创业企业，并在过去十到十五年间推动了全新商业模式的出现。

按需自助式基础设施，是公有云定义中的关键前提之一。因此，颇具讽刺意味的是，许多企业在采用公有云之后，做的第一件事却是剥夺开发者的这种自助服务能力。

当然，这些限制并非出于恶意。企业需要某种机制来确保一致性与合规性，并防止云环境成本失控。但问题在于，如果治理方式回到了传统工单、审批和人工配置的模式，云计算最核心的生产力优势也就被大幅削弱了。

真正有效的自助式平台，不应只是给开发者一个云控制台账号，也不应只是把基础设施团队的审批流程搬到云上。它应当在安全、合规和成本可控的前提下，为团队提供低摩擦、可重复、可审计的交付路径。换言之，平台的目标不是替团队做所有决定，而是让团队能够更快、更安全地做出正确决定。

对于研发团队而言，自助式平台还应与研发管理体系打通，让目标制定、需求收集、需求评审、排期、开发、测试、发布和知识沉淀形成连续的数据链路。PingCode 这类智能化研发管理工具，能够覆盖研发全生命周期管理，并与研发过程中常用的其他工具连接，帮助企业在云转型中同步提升研发管理的自动化、数据化和智能化水平。

供应商选择：警惕云供应商锁定风险

如今，业界可供选择的主流公有云供应商屈指可数，它们提供的基础服务也大同小异。这给云供应商带来了一个难题：它们的核心产品本质上已经日益商品化，而商品化产品往往只能通过价格加以区分。基础云基础设施即服务，即 IaaS 模型本身，并没有太多专有技术壁垒。

为应对这一困境，供应商们不断推出种类繁多的专有差异化服务。许多服务确实极具吸引力，能够显著降低成本，并大幅提高开发人员效率。但使用这些服务，也会让企业对单一供应商产生强依赖。

如果这是理性且有意识的选择，那么它未必不可接受。然而，根据我的观察，企业与单一云供应商之间的深度纠缠，往往是在不知不觉中逐渐形成的。

当客户意识到自己已经不再拥有云服务商选择权时，把最关键资产迁移到另一家供应商的成本和时间，往往已经高得令人望而却步。

企业在处理每一个云工作负载时，首先都必须回答一个问题：我们与云的集成应该有多深？

一方面，有些应用生命周期很短，需要快速部署和快速验证。这些可能只是小型实验，并不需要太多前期投入。对于这类资产，充分利用供应商提供的各种省时、省成本的专有功能，是明智之举。因为这些应用很可能会在企业需要更换供应商之前就已经退役，因此并不存在显著的隐藏迁移成本。

另一方面，支持关键业务流程的核心系统，尤其是记录系统，通常拥有很长的生命周期。这些系统可能需要维护十年，甚至更久。对于这类系统，在其生命周期内更换云供应商的风险要大得多。因此，在决定使用哪些供应商服务时，企业必须把这一风险纳入考量。

如果没有把可移植性成本计入解决方案的全生命周期成本，那么在未来平台迁移时，企业就可能面临一笔意料之外的巨额支出。有海外技术专家曾将可移植性的前期成本比作购买期权。如果你认为自己极不可能需要退出某一家云服务商，那么这份“期权”的价值自然很低。但如果你的资产寿命较长，风险就会随之增加；降低未来迁移成本的这份“期权”，价值也会相应上升。

换句话说，有时，避免使用那些虽然节省时间、但高度专有且难以从一家云服务商迁移到另一家的服务，反而能够降低总体拥有成本。无论如何，这都应当是在大规模云迁移之前，经过充分思考后做出的选择。

结语：以更清醒的方式推进云计算转型

云计算在企业中已无处不在，这并非偶然。如果运用得当，云计算可以成为现代数字化业务的强大推动力。但正如我们所看到的，挑战依然存在。

通过对云采用进行全方位评估，企业能够更深入地理解这些挑战，也能以更成熟的方式拥抱云计算。这并不意味着你的云战略将毫无风险；它真正意味着的是，你将更清楚地知道，自己的方案所伴随的风险，是否仍在可接受范围之内。