导读：推进企业上云已经是中国的国家战略。然而，中国的企业领导们对什么是上云、怎样上云的认知到啥程度了呢?

　　一位目前在中国最领先的云公司工作，在IT行业里摸爬滚打了二十多年的老同事跟我倾诉说：上云的概念太模糊了，企业IT转型需要的业务应用的数字化和智能化，技术平台的互联网化和云原生化，以及基础设施的云化和服务化，本身是系统性的工程，不单是技术性概念能覆盖的。

　　给企业领导讲技术概念，是很难被听懂的，需要有体系化的业务转型方法和业务价值呈现。互联网公司以“中台”通过技术敏捷实现业务敏捷，达到持续迭代和唯快不破，不是光靠技术转型就能实现的，然而互联网公司的这些思想应用到传统企业的数字化转型上，往往被各种砖家曲解了，对企业领导也多有误导。

　　这位朋友在过去这些年负责了国内很多金融机构的上云项目，大多也就只能做到把原来的系统搬上云而已，还是私有的云。各种数字化也只是做做尝试，几乎没有哪家能做全面的转型。反观很多全球性保险公司、银行等同行，已经习惯了基于公有云的大规模敏捷，并开始各种业务创新了。

　　我对他说，也许是中国市场上缺乏好的云转型咨询顾问，没能给企业领导把上云这事儿说清楚了。

　　朋友说他感觉还是企业没有准备好，大多数企业的现状是：业务领导不重视IT，重视IT的又不懂IT，懂IT的又不懂云和互联网。勉强有少数领导，都懂一点，又不想找国内互联网大厂出来的云公司们帮忙转型，觉得是竞争对手。而作为旁观者的咨询顾问，想做到业务、技术都通也太难了。

　　不过，这位朋友觉得前途还是光明的，上云没有捷径可走，走的人多了，摔跤的多了，自然道路和走法都出来了。咨询顾问在市场上还有大量的空白可以去填补。

　　于是，我下文尝试一下用企业领导能听懂的语言，跟他们聊聊上云的策略。

　　什么叫“上云”?通俗地说，就是企业把部署在本地数据中心的应用系统以及相应的数据，搬到云上去。今天，上云规划是企业IT战略规划中的重要组成部分。企业使用云技术的模式分为公有云和私有云，私有云只能说是企业利用云技术建立的自有平台，不算真正的“上云”;只有部分(混合云)或全部(多云)使用公有云，才是我下面说的“上云”的主要目的。

　　上云就上公有云。对企业来说，上云的收益有四方面：

　　一、智慧企业运营：今天，数字化转型使得传统企业的IT应用系统必须利用大数据、人工智能、流程机器人等技术进行改造，更具智慧和人性化，此外，企业还要构建平台，持续创新，波士顿咨询将企业的数字化愿景称为“仿生型企业”(下图)，而在今天的技术环境下，大数据、人工智能、流程机器人等都是以云服务方式提供的，所以要实现智慧企业/仿生型企业，拥抱云、上云是企业IT应用系统的必选变革;

　　

 

　　二、工作负载的弹性优化：企业可以根据透明的、自动可控的业务量参数，来调整信息系统的工作负载在一个云或者多个云上的部署，提升性能，降低成本;

　　三、可灵活控制的成本开支：云使得企业数字化所需的技术资源变得像水电气等公用事业一样，按用量付费，这使得企业的IT投入从资本性开支(CAPEX)变成运营费用性开支(OPEX)，改变了财务模型;

　　四、信息安全及合规：全面上云更有利于企业建立整合的信息安全策略，从云访问着陆区到开发平台到数据平台到运维管理，全面规划和实施信息安全及合规机制。

　　上云具体应该如何操作呢?早在2011年Gartner就提出了云迁移的“5R策略”，后续各家云服务商、咨询公司等在此基础上都提出了自己的方法，概念上大同小异，以亚马逊AWS在2016年提出“6R策略”最具代表性：

　　

 

　　来源：AWS的应用上云路线图

　　一、重新托管(Re-host)：也称为“lift-and-shift”，这是一种最简单粗暴的方式，即企业租用云上的“虚拟机”环境，将现有应用系统直接搬进去(“物理机到虚拟机”或者“虚拟机到虚拟机”)，这种方式过程简单、快速，对业务影响最小，缺点是无法应用云上的原生服务，长远来看成本效益未达最优化。

　　二、重构(Re-factor)：也称为“re-achitecting”，即所谓的“云原生应用(cloud native application)”改造，这是一种连老应用系统的“底座”也彻底换掉的做法，根据云应用的全新技术环境，重新构建应用程序，企业可以部分利用过去应用程序的代码和框架，基于自建的或者公有云服务商提供的应用开发平台(PaaS)，来进行彻底的改造性开发和部署，例如传统单体应用解耦，API赋能、微服务化就是“重构”的典型;这种方式能显著提升传统IT应用的性能、规模和灵活性，改造彻底，但是成本高、风险大、时间长。

　　三、修改平台(Re-Platform)：也称为“修补后迁移”，这是一种介于上述两种策略之间的方式，不改变现有应用的核心架构，有针对性地利用云平台上的技术服务组件，例如数据库、消息中间件等，进行相应部分的改造。这种方式既能利用云原生服务，又能保护既有投资、缩短迁移时间，其潜在风险是迁移过程的项目管理以及迁移后的运维管理都较为麻烦。“容器”是将应用程序打包的方法，便于在云上部署、跨云迁移，上述两种方式普遍使用容器技术来管理上云的应用;主流云平台厂商大多提供了应用代码扫描工具和容器化工具，自动分析、评估应用程序可迁移性，以及将应用程序容器化并将其部署在容器平台上。

　　四、重新购买(Re-purchase)：即购买现成SaaS来替换掉传统应用系统，例如传统企业OA换成钉钉、企业微信，或者自建采购平台换成云采购平台等等，这种方式优点是可以尽量利用SaaS的成熟功能，维护更简单，缺点是灵活性相对较低。

　　五、重建(Re-built)：在云平台上采用原生的服务，从零开发新应用，这种方式更适用于快速创新，利用云平台上的大数据、AI、物联网等服务来搭建创新应用，例如最近很火的Snowflake数仓、C3.AI物联网AI等，都在主流公有云上提供服务。云时代，企业使用数据平台、人工智能等应该是利用云服务，而不是自己去建这些东西，这是很多中国企业在考虑数字化转型策略时普遍存在的误区。现在主流公有云还提供“无服务器”(Serverless)方式，开发者不用关心底层的基础设施架构的配置，只需专注于开发跟业务逻辑和用户前端相关的代码，基础设施由云服务商自动供给，根据实际用量计费。这种方式优点是开发真正的自有云应用，更先进、时尚，缺点是绑定在特定云服务供应商的平台服务上，较难跨云迁移。

　　六、保留和淘汰(Retain & Retire)：企业内有些应用系统出于网络安全、访问性能、合规要求等原因，不适合上云或者更适合本地部署，则应保留现状;在进行上云评估时，通常还能识别到过时、无用的应用，进行必要的数据备份归档后淘汰。

　　我将六种方式在实施难度、风险和成本、业务创新支持等方面比较如下：

　　

 

　　企业IT系统的工作负载(Workload)哪些适合在云上，哪些适合保留在本地，现有本地的应用采用上述何种方式上云，跟企业业务战略和数字化转型战略相匹配。云迁移过程本身也存在一定的风险，例如：

　　混合云、多云为企业IT架构带来的复杂性，为企业IT管理增加了难度

　　应用跟基础设施、数据平台以及其他应用即服务之间的依赖关系，使得必须考虑演进中的过渡方案

　　上云后的系统性能和可用性，有些企业系统要求低时延，例如自动驾驶系统、工厂的工业自动化系统或者医院的护理监测系统，必须考虑上云的风险

　　安全风险，尽管我认为大型云服务商本身的安全机制肯定高于企业自有的安全机制，就像你把钞票放到银行金库，肯定比放在你家保险柜里更安全，不过，企业应用上云后，服务调用和数据传输全部在互联网上，在这些环节上存在更多的受攻击暴露。

　　因而，企业上云，究竟是定位到什么样的深度，必须根据自身业务特性、业务战略以及行业趋势，找准定位，我们分为三个层级：

　　

 

　　咨询顾问帮助企业进行上云的规划的方法如下图所示：

　　

 

　　第一步是结合企业的业务战略，建立企业上云的愿景、分析商业案例，有些云服务商提供了在线的开支计算器，来帮助企业建立上云的投入产出经济模型：

　　

 

　　第二步是基于上云愿景，具体落地到哪些业务场景可以上云。根据我们的经验，以下四种类型的企业IT应用通常作为上云的优先候选：

　　对外的数字化渠道平台或工具：无论是企业网站、社交平台，还是电商平台、经销商和供应商协作平台等，由于用户访问突发事件多、用量峰值高，是上云的首选，能显著避免性能瓶颈、降低成本;

　　数据分析平台：大数据平台以及相应的数据分析应用，对基础设施的软硬件资源要求高，访问人数和频度低，将数据平台和分析工具上云是较为经济的做法，云存储备份服务的成本节降比较显著，而数仓和BI上云都是目前云应用的主流(参见“数字化转型的误区| “数据中台”概念的局限性”);

　　全新新建数字化应用：企业不可能跟专业的云服务公司抢饭碗来自研物联网、人工智能的平台，因而采用这些新技术的数字化应用，都适合在公有云上直接开发，因而我认为不到一定规模的企业，在数字化转型中自建“技术中台”是个很荒谬的想法(参见“IT战略 | 企业软件，自研还是外购”);

　　最近几年新建的应用系统：IT技术代际替换大约10年左右一次，而很多企业应用系统的技术稳定使用了几十年了，这类企业系统也没有必要马上上云，例如ERP、核心银行系统等，例如SAP将其ERP称为“数字化核心(digital core)”，就是承认其当前本地化部署的定位(参见“企业如何走向下一代ERP(Next Gen ERP)”)，而最近几年用新技术开发的、相对较新的应用系统，较为容易进行架构改造，采用前述的重构或修改平台的方式，实现上云。

　　企业可以采用应用场景、业务流程、业务能力分析等各种方法，来对现有的应用系统(application，业务系统视角)或者工作负载(workload，技术实例视角)进行检视，并按技术特性归类，例如操作系统/编程语言/应用服务器类型等，从而分为“上云就绪”、“改造后上云候选”、“不适合上云的遗留系统”等。

　　企业对候选系统进行上云的测试以及试点后，总结形成经验，云服务商提供了自动化上云工具，企业可以基于经验，利用这些工具建立“云迁移工厂”，批量化提升上云速度。

　　第三步和第二步是交叉的，企业要根据上云应用的特性选择合适的供应商，相应搭建架构，确定企业的架构设计范式。不同云平台的服务各有特色，例如通常认为Google云平台的大数据分析能力强，亚马逊AWS的云原生组件、无服务器服务的技术更成熟，微软云平台更适合桌面应用、统一身份管理，提供完善的Devops工具，阿里云更适合高流量的电商应用，微信支持社交工具和游戏更好等等，企业根据实际情况选择，“多云”应该是大方向，企业也应该利用第三方云管平台来管理多云服务。

　　企业上云的效率取决于架构设计范式的标准化、代码封装及测试的自动化等能力。

　　第四步是建立云环境下新的数字化工作方式(way of work)以及对于IT和云服务的治理模式。云转型为企业IT部门带来一系列组织角色、工作流程、开发技术和管理工具的变化。例如敏捷方式以及云迁移过程控制，可能要求实施新的IT服务管理平台，还需要实施访问控制、资源调配、计费控制、安全监控、事件管理等云管工具，通常云服务平台上也提供这些工具的原生服务。

　　有些企业在云转型中建立了云能力中心(Cloud competency center)，来统一制定和协调云战略、合作伙伴选择、架构规范、解决方案设计、开发和部署、运维服务、网络安全、云开支成本管理等：

　　

 

　　最后，总结一下企业上云的关键成功因素：