作者  | 银大伟

现如今，适时利用云计算提供的资源弹性伸缩能力以及托管服务已成为行业共识，是否采纳和使用云对于企业而言已不再是选答题而是必答题。能否做到业务上云，即企业能否真正有效地利用云及其生态所提供的新技术和平台来赋能业务、加速数字化转型、提升企业的竞争力，对很多企业来说依然是一个巨大的挑战。

据观察，许多企业的业务上云旅程并不顺利，甚至可以说十分艰难， 特别是在上云的系统规模比较大（系统数量在几百甚至上千）和涉及的业务线比较多的时候。挑战不仅仅来自技术层面，也来自原有的组织结构、团队能力和研发体系。另外，还有一些企业把云迁移作为自身业务上云的目标，这显然是不合理的，因为这很容易导致把业务上云等同于系统从数据中心到云的搬迁，最终很难达成企业期望的业务上云的价值目标，例如降本增效、提升响应力、赋能业务等。

本文将深入探讨企业业务上云的驱动力和挑战，以及如何有效规划符合自身场景的业务上云策略，尽早识别风险并建立跨部门和跨团队的协同机制，加速业务上云。

业务上云之驱动力

驱动企业实施业务上云的因素有很多，例如常见的降本增效、提升业务响应力、通过新技术赋能数字化转型、政策及合规等。还有一些企业在上云的过程中会对其业务架构进行重新设计，这通常伴随着未来数年的业务愿景和目标。

仔细分析这些驱动力可以发现一个隐藏的假设：简单维持现状可能并不会使企业的业务乃至竞争力变的更好，可能不变甚至变糟，这也是为什么在上文中提到如果仅仅是系统搬迁上云并不能帮助企业达成业务上云，因为这样除了基础设施由数据中心变为云，其业务模式和竞争力都没有发生本质的变化。因此，企业在选择上云时，其隐藏的上云驱动力是对其竞争力的重构，是通过业务模式和技术的变革对企业进行再造的过程。

从“The 6R's”看业务上云之挑战

6R通常是企业规划上云的首选策略，鉴于互联网上已经有很多关于6R的解释，本文不作过多阐述，具体可以参考这里：​​6 Strategies for Migrating Applications to the Cloud​​ 。6R虽然可以对应用上云的策略进行分类，但也容易带来一些问题。例如，企业通常为了快而采用lift & shift，即把虚机打包成镜像搬移上云。对云厂商来说，这是最符合其盈利模式的方式，但对企业来说，收益却很有限甚至低于期望。

而且，6R还容易导致在上云过程中出现价值鸿沟问题。价值鸿沟（​​Is Your Cloud Journey Stuck in the Value Gap?​​]）是Thoughtworks前首席咨询师Gregor Hohpe提出的：

如：想要采购一些技术类产品或解决方案，快速产生高价值。然而，由于其组织结构、流程、能力及研发体系还无法与新技术进行很好的匹配（Org Change），导致真正的干系人（例如业务侧）感知到的真实价值远远小于期望价值（Value Gap）。而采用6R时，容易把主要关注点过早的放在技术上，而组织上需要做的变革由于多种原因被延后甚至忽略，从而凸显了价值鸿沟。

另外，规模也是一个不得不关注的挑战。业务上云通常是企业IT部门负责，IT团队要尽可能保证业务的连续性并减少对现有业务的影响。在制定上云计划及迁移策略时，由于应用和系统数量庞大，这就要求IT团队需掌握的业务上下文和管理的干系人数量也是非常大的。

因此，在保障业务的前提下，制定业务上云的策略，除了技术带来的挑战以外，还有来自如何使众多参与方保持一致的目标，如何进行跨团队的有效沟通，以及如何尽早识别和管理风险等多个方面。

业务上云之四大关键问题

为此，我们总结了业务上云需关注的四大关键问题，即：如何建设，如何推广，如何迁移及如何演进。

如何建设？

如何建设的关键点在于如何平衡采购行业产品或解决方案与企业自身的需求。不可否认，行业产品或解决方案能够解决一些通用问题，但每个企业自身的问题都有特殊性，这就要求该产品不但需要依照企业的需求进行定制化，还需要能够与其上下游系统和流程集成。当采购的产品和解决方案较多的时候，如何管理这些定制化和集成，以及如何与自身上云计划和策略匹配就会成为突出的问题，因为，不同产品提供商响应定制化需求的效率、能力甚至是意愿都是不同。

因此，要回答如何建设，企业必须要回到自身的业务愿景、需求和场景，以此作为出发点反向构建对于未来业务和数字化能力的诉求，再评估市场上不同的产品和方案，最终决定哪些需要采购，哪些需要自建。这也是构建未来技术平台甚至业务中台的基础。例如，在选择云厂商及相关技术类产品（如相关DevOps或微服务平台等）时，除了要对比不同选项间功能和价格外，还需要通过梳理高价值需求和场景以及自身能力诉求对备选方案进行验证和评估。

如何推广？

大家可能会疑惑为什么业务上云需要考虑推广？推广什么？推广给谁？这些问题其实是由企业传统IT在数字化转型时代自身定位转换所引起的。以往IT的定位主要依靠数据中心为业务方或研发团队提供资源侧的支持和运维，因此，其团队规模有限且日常大部分时间都是处理大量的ticket。该定位导致IT本身距离业务比较远，在企业的研发体系中也属于偏底层或边缘的位置。所以，通常说IT是企业的成本中心。而企业决定业务上云后，IT本身的定位也发生了很大的转换，不但IT自身要应对非常多新的技术和挑战，还要担负起新技术赋能者的职责，这里的赋能不但要赋能业务，也要赋能研发团队。如果再从研发体系的视角看，IT则是从以往研发体系的边缘向研发体系的核心移动。

既然要赋能，最好的方式就是把新技术封装成适合企业自身需求的能力和服务提供出去，这也是为什么我们看到很多企业内部形成了诸多技术平台和技术服务类产品，甚至还划分了不同的团队（如：基础设施团队、平台团队等）。他们的职责都是通过对新技术进行封装，降低研发团队的学习和使用成本，从而达到赋能的目的。而IT自身的定位也从提供资源、运维和响应ticket，变为了提供内部技术类平台和产品。

推广什么？推广的主体就是企业内部的技术类平台和产品。推广给谁？业务方的研发团队。而推广成功与否的度量方式也变为一些列关键指标，如：有没有用户，好不好用，体验怎么样，是否先进，SLA如何，效果怎么样等。因此，推广背后的根因是IT由服务型团队向产品型团队的转换，这要求IT需具备一定的产品设计思维，不断理解业务，优化开发者体验角度，设计高度定制化的服务。

如何迁移？

如果孤立看迁移，它仅仅是应用的搬迁，但结合上文产品型团队的定位，那么迁移的含义就完全不同了，是一种产品引流的方式，是一种服务，并要做到高效、标准化且可重复。

我们见过一些企业把迁移服务描述为迁移工厂和生产线，通过一系列操作和组装，应用就能完成改头换面。但该方法可行与否是有前提的：生产线意味着我们对原料的加工方式已经明确且可重复。而在企业内部需要迁移的应用大多都是遗留系统，他们可能每个都不同，架构也比较老旧，技术与现代化应用差异很大且经过多年的修修补补，再加上业务上下文的缺失，修改很可能引起对业务不可控的风险。因此，我们常常看到对一些老旧系统的改造非常困难，甚至需要数年的时间才能完成。另外，作为IT团队，由于以前距离业务较远，缺乏对现有业务应用的全面了解，因而无法设计出有针对性的迁移方案，容易导致业务侧与IT的相互拉扯，使得迁移过程更加困难。

因此，如何设计有效的迁移方案，取决于对应用本身知识的了解程度，整个过程很难一蹴而就。但如果我们以引流的方式思考，把迁移服务类比为一个产品，应用类比为用户，那么我们可以采用市场营销的方式来设计整个迁移策略和方案。

首先，由于应用本身的维护和管理大多在IT侧，我们可以对应用建立一系列特征库来进行描述，就像通过数据埋点抓取用户数据一样。这些特征可以是静态的，比如：编程语言、数据库、集成关系、中间件等；也可以是动态的，比如：业务上下游的调用关系、应用间的依赖关系等。通过特征的建立，我们就可以依据一些规则对应用进行分类，分类的目的是快速了解应用并发现应用间的相似性，而相似性则能够一定程度保证对该分类设计的迁移方案能够重用。当应用特征的抓取被自动化后，再结合一些可视化工具和分类算法，就能够极大的帮助IT快速制定适合的迁移方案。

如何演进？

由于业务会因为市场的变化而不断调整，技术迭代的速度也在加快，这就要求企业内部的平台和技术类产品也能随之不断更新和升级。如何演进的关键在于：能否做到以用户（业务方和研发团队）为中心，应用产品思维和设计思维，做到与业务共同演进。

首先，要基于业务愿景制定发展阶段。通过与业务的合作，加深对业务的了解，将业务需求转化为对平台和产品的策略性需求，加入产品的迭代计划。其次，逐步建立起自己的数字化运营体系。指标体系的设计可以分别从IaaS，PaaS以及SaaS的维度展开，以此为目标不断优化。第三，通过团队拓扑优化跨团队协作。建立平台团队和赋能团队，积极参与到研发活动中。从第一线观察和了解研发团队的痛点，并评估当前服务的功能、体验和有效性是否能够满足研发团队的要求，并将开发者体验纳入到产品演进中。

业务上云之云化体系全景图

我们将上述四大问题总结为一套业务上云的体系全景图，并以此来指导和规划企业业务上云的策略和路线图。

该体系从实际应用特征数据出发，通过对应用分类，降低应用迁移的复杂度，使得迁移的流程、工具和方法被标准化，加速企业的数字化进程；与此同时，它也能够帮助IT建立起一套自身的数字化运营体系，应用产品思维和设计思维做到和业务共同演进。

数据驱动的应用特征库

应用特征可以分为应用的静态特征和动态特征。静态特征是来自开发态的数据，例如：业务领域，编程语言，依赖库，数据库，中间件，提交记录，构建频率等；动态特征是来自运行时的数据，如：上下游调用关系，调用链路，调用频率，耦合程度，日志等。同时，由于应用的运维及产生的数据大多由IT团队管理，因此，IT团队便于建立一套自动化的应用特征数据采集系统，做到应用特征的实时采集和更新。应用特征库的建立，能够有效帮助IT团队弥补业务和应用上下文不足的问题，做到有针对性的设计迁移和改造方案。

应用分类驱动迁移策略

有了应用特征库，就可以采用图数据库，如neo4j，通过聚类算法寻找应用间的关联关系并可视化。识别应用的相似性及分类就像对用户特征进行分类一样，特征相似的应用意味着能够采用相似的迁移策略和方法，也就意味着基于该类应用的迁移方法是能够在此类应用中复用的。另外，不同的分类，也代表了不同的迁移难度和风险，就可以快速对应用迁移中成本进行估算，方便制定应对方案。

我们建议在分类中适当选取具备某些特征的应用作为该分类的样板间，例如：选取复杂度最高的或业务中的关键应用等。在迁移初期，IT团队应投入资源保证该样板间的成功迁移，并总结和提炼迁移中的实践和经验。这些实践和经验，一方面可复用到该分类的其他应用，一方面可以最终升级整体迁移策略的实践和工具，并以平台服务的形式提供。

数字化运营指标体系

当越来越多的应用成功迁移上云后，IT团队应逐步考虑建立云平台的数字化运营指标体系。建立数字化运营指标体系的方式是把云平台当作企业内部的产品，以产品的视角定义平台的服务质量和成功标准。具体的指标建立可以考虑多个维度，也可以根据平台不同阶段来制定。如果在迁移初期，可以将服务应用数量，资源利用率等作为指标。如果大部分应用已经迁移成功，就可以考虑对指标做相应的调整，例如：开发人员的满意度，服务的可用性等等。

数字化运营指标体系的建立是思维模式的全面转型，这要求团队从用户价值出发，应用产品化思维，不断改进和提升平台和服务的产品力和竞争力，最终体现自身价值。

总结

大规模业务上云是一个大型系统工程，挑战不仅仅在于技术，还需协调企业内部众多干系人，同时还要考虑自身平台的建设和未来的演进。IT团队可以充分利用以往自身优势，通过采集和分析应用的数据，建立符合企业的业务上云策略和平台，展现企业数字化转型中赋能者的价值。