透明思考

数字化转型与平台战略

数字化浪潮对传统行业的冲击已经被越来越多的企业领导者所感知。据《哈佛商业评论》的调查，半数以上的企业高管认为自己的业务将在12个月内受到数字化浪潮较大程度的冲击，其中媒体、通信、消费者金融服务、零售、科技、保险、消费者产品、专业服务和教育等10个行业受到的影响最大。

数字化对企业的要求

数字化到底对企业提出了什么要求？可以从一个真实的案例中看出端倪。一家全球知名的快消品企业，在京东618购物节之前花了大量的成本和精力设计促销计划，细到优惠力度、广告Banner等每个具体环节都经过多次论证。市场部从领导到一线员工都如临大敌，力求方案精益求精。对待一次重要的促销机会，当然需要重视，但是从上到下如此关注、投入如此多的精力，这是为什么？原来这家企业对市场数据的处理能力还停留在相当初级的阶段，电商平台提供的数据还在用Excel归集处理。在这种数据处理能力的支撑下，市场部的促销举措至少需要两周时间才能看到数据反馈。也就是说，一旦促销举措设计失误，在购物节的时间窗口内就没有再次调整的机会。

这家公司的情况让我联想起几年前看过的一组数据：Etsy在2012年平均每天能往生产系统部署超过30次；Amazon在工作日平均每11.6秒就有一次生产系统部署发生，峰值时一小时内部署超过1000次。当这家快消品企业响应一次变化、进行一次实验的周期需要以两周计，领先的互联网企业几年前就已经能够以小时、分钟为单位响应变化和开展实验。这种快速响应变化的能力，是数字化企业的核心竞争力。

为了打造快速响应的能力，海尔把传统的层级管理体制改造成了三级的自主经营体机制。海尔将7万名员工自我组织成了2000多个自主经营体，最大的自主经营体数百人，最小的只有7人，如果一个员工在海尔内部找不到一个自营体能够接受他，海尔就会和他解除劳动合同。海尔的首席执行官张瑞敏说：“每个小微（团队）都要变成一个个的小团体，所有相关人员都在这里头，负责开发某一个地方的市场，或某一个地区的市场。”直接来自顾客和市场的信息，就像鲶鱼一样激活了小团队的响应能力。

芬兰的游戏公司Supercell也倡导以小团队模式进行游戏开发，一般来说两个员工、或者5个员工、最多不超过7个员工组成独立的开发团队，称之为Cell（细胞），这也是公司名字Supercell（超级细胞）的由来。团队自己决定做什么样的产品，然后最快的时间推出产品的公测版，看看游戏是否受用户欢迎。如果用户不欢迎，迅速放弃这个产品，再进行新的尝试，期间几乎没有管理角色的介入。这家公司在2015年手机游戏排行Top10中曾占据榜单大半江山，2016年腾讯以86亿美元收购了员工数不到200人的Supercell公司84.3%的股份。

从海尔、Supercell以及其他很多小团队的成功经验中，我们看到直面市场与顾客的具有四大优势，使得他们能很好地应对数字化浪潮带来的对响应力的要求：

1. 协作高效。小团队协同效率最高，能全力提供顾客所需，避免组织内耗。
2. 目标清晰。小团队对战机（商机）的把握更加敏锐。
3. 调整快捷。当情况发生变化或获得新信息，小团队能更快调整。
4. 迅速扩展。一旦找准目标，小团队能全力投入，迅速扩大战果。

小团队需要大平台

然而，并非所有小团队都能天生地具备这四大优势。实际上，我们看到很多创业小团队并没有很强的感知和响应变化的能力。成都的一支小团队在2016年创办了“翘翘动感沙拉”品牌，针对有轻餐食及塑形需求的白领人士，一方面能够作为一道主食满足都市白领的午餐需求，另一方面为有塑形减脂需求的人士提供热量较低且健康的食物。翘翘沙拉斥资30多万装修厨房，邀请了国际五星级酒店主厨加盟，筹备用了近半年时间。上市后才发现产品定位与市场不符，4个月后就停止了经营。这支小团队规模虽小，却没能发挥出预期的响应力。

再次放眼站在数字化潮流前端的企业，我们会发现：原来他们不止是倡导小团队模式，而且为小团队建立了一整套的支撑平台。在海尔的自主经营体结构中，有三个层次的自主经营体。其中一线经营体经营体直接面对顾客，为所负责的顾客群创造价值；二级经营体（或称平台经营体）则为一线经营体提供资源和专业的服务支持，包括人力资源管理、供应链、市场营销、质量体系、战略管理等，所以，平台经营体是一级经营体的资源平台、流程平台、专业化服务平台。平台的存在让一线经营体获得了响应力。

阿里巴巴则是用共享服务体系支撑前端业务。今天的阿里巴巴已经将集团20多个核心业务中公共的、通用的业务以服务的形式沉淀到了共享业务事业部，整个集团的核心业务能力均建立在这样一套共享服务体系之上。共享服务体系从会员、商品、交易、支付四大中心开始建设，支撑1688、淘宝、聚划算、闲鱼及全集团超过2000个应用。共享服务体系强调的能力包括：服务分布的能力；数据分布的能力；数字化运营的能力；平台稳定的能力；平台开放的能力等。

华为也在强调用大平台炮火支撑前线指战员。任正非在华为质量与流程IT管理部员工座谈会上说，华为内部IT要做到“能力模块化和微服务化，使能公司实现数字化转型和大平台下的精兵作战，在研发、销服、供应等业务领域要率先实现ROADS体验（实时、按需服务、在线、自助、社交化连接）”。

透过对各种小团队的观察我们发现，独立自主、直面顾客的小团队，在具备组织灵活性的同时，也必定面对基础能力的局限。那些走在数字化潮流前端的企业，都是以平台形式为小团队提供了四大能力的支撑，才能发挥出小团队精准、灵活、高效的优势：

1. 洞察顾客的能力。小团队需要透过多种数字化渠道获得对顾客的全面了解。
2. 服务供给的能力。小团队需要迅速整合企业内部的资源和能力为顾客提供服务。
3. 数据决策的能力。小团队需要随时捕获市场反馈，根据真实数据做决策。
4. 实验创新的能力。小团队需要开展受控实验，通过实验检验创新假设。

数字平台战略

企业数字平台，是基于云计算“基础设施即服务”（IaaS）能力之上，为企业数字化战略提供能力支撑的一系列平台服务（PaaS），涵盖IT系统研发与运营全生命周期。企业数字平台为直面市场与顾客的精益团队提供顾客洞察、服务供给、数据决策、实验创新四大能力支撑，赋能团队快速创新和响应变化。而这四大能力的基础，是IT组织的精益研发能力和相应的基础设施。

对众多成功的数字化企业的调研显示，这些企业有着一些引人注目的共性。他们逐步构建自己的数字平台，以此为基础激活企业核心资产。数字平台支撑小团队迅速响应市场和顾客的变化、高效地实验创新，给这些企业带来了显著的改变：

• 提升IT效能，为产品和技术团队赋能，更快更好地为客户交付产品。
• 构建行业生态，使得新业务、新产品、新服务能充分利用服务化后的企业核心能力和资源。
• 促进业务创新，充分利用核心资产进行高效、快速的创新实验，保持企业竞争力。

特别针对数字化小团队需要的四大能力，ThoughtWorks的数字平台战略提出了一个基础设施、四个平台的框架结构：

1. 精益研发需要的交付基础设施。
2. 顾客触点平台全方位洞察顾客所需。
3. 资源服务化平台快速供给数字化服务。
4. 数据自服务平台支持基于数据的决策。
5. 实验测量平台赋能受控创新实验。

基于数字平台战略提出的框架，企业可以结合自身情况，逐步建设当前数字化进程所需的支撑平台，用平台助推企业的数字化战略。

（更多关于数字平台战略的信息，请下载我们的《数字平台战略》白皮书）

企业IT的经营模式及其与企业架构师的关系

企业IT的经营模式可以由两个维度来定义。第一个维度是标准化，第二个维度是整合。这两个维度划分出的四个象限，定义了四种不同的经营模式。不同的经营模式，有各自不同的聚焦重心，对企业架构师的关注点也有不同的要求。

经营模式的第一个维度是标准化（standardization），即企业的各个业务单元之间在多大程度上复用业务流程与系统。高标准化程度能带来业务的效率与可预测性，但同时高标准化程度需要投入成本来达到，包括建设可复用的IT系统、替代业务上可以运作但不够标准的系统等。并且高标准化程度有可能局限各个业务单元的本地创新能力。

经营模式的第二个维度是整合（integration），即各个业务单元之间在多大程度上复用数据。高整合度也能提高业务的效率，更重要的是能促成业务单元之间更有效的协作，增加整个组织的透明度与敏捷度。另一方面，提高整合度也需要成本，这种成本主要来自于对数据的语法（格式）和语义（术语含义、领域模型）在全组织范围达成一致。

标准化和整合两个维度定义出了四种不同的经营模式。

第一种经营模式是低标准度、低整合度的差异（Diversification）模式。在这种模式下，各个业务单元根据自己的需要各自建设IT系统，既不特别在意使用统一的、连贯的技术（例如有些系统用Java开发、另一些用PHP开发，而且没有明确的原则判断应该如何选择），也不特别在意数据的共享（例如不同的保险品牌和种类各自保存各自的顾客、保单等信息，彼此之间不共享）。

在业务早期试错和快速扩张的阶段，差异模式使IT与业务诉求高度对齐，从而带来很好的响应能力：业务有什么需求，直接告诉IT；IT采用自己最擅长的技术手段快速实现。并且差异模式对于系统外包也是最简单的，外包商只要按时交付预先要求的功能，项目内部的运作不需要多操心。差异模式的缺点也很明显：它造成业务筒仓（silo），使技术能力和业务能力无法积累和复用。

如果差异模式是企业有意识的选择，此时就不要过早地引入过多标准化的要求，以免拖慢业务试错的节奏。这时企业架构师应该关注项目运作方法论的标准化，例如推行一套轻量级、非侵入的项目流程和度量方法，对几个项目关键节点进行监控和治理。至于业务筒仓造成的重复开发、信息不整合等问题，暂时只需保持警惕即可。

第二种经营模式是高标准度、低整合度的复制（Replication）模式。在这种模式下，降低IT成本成为IT治理的一个关键点，各业务单元在建设IT系统时需要共享技术平台、基础设施、技术架构等技术组件。例如澳洲某保险集团在2012年时建立了一套基于Maven和Spring Flow的前端应用模板，当时启动的大量在线渠道系统全部要求采用这套模板，并不断提取各个项目的技术经验回到这套模板中。

复制模式最大的优势是系统建设成本的快速降低。仍然以这家保险集团为例，它的第一个在线渠道系统（房屋险）用了6个月时间开发上线，第二个在线渠道系统（车险）只用3个月。越到后来，新建一个在线渠道和将一个在线渠道复制到不同品牌所需的工作量就越少。而且对于运维团队而言，当所有在线渠道系统都采用同样的技术模板以后，运维的难度和工作量大大降低了。不过为了从技术与工具的标准化中受益，初期的架构选型与规范成本必不可少，并且需要持续不断地抽取项目中的最佳实践反哺到共享标准中。实际上，该保险集团的第一个在线渠道系统之所以需要较长的时间建设，其中一部分原因就是需要在该项目过程中建立起最初的技术模板。

在复制模式下，企业架构师的主要关注点是标准和共享服务/工具的建设，包括初期的标准化努力和持续的抽取/重构过程。企业架构师需要建立起一个横跨各个系统、各个项目的技术社区网络，确保技术标准能在各个系统中落地，并且能了解各个系统的反馈与创新。

第三种经营模式是低标准度、高整合度的协作（Coordination）模式。这种模式聚焦的目标是商业运营的成本和质量，IT的成本则不是最优先的考量。为了向顾客提供更高效、更优质的服务（以及创造潜在的交叉销售和向上销售机会），各业务单元之间有共享标准的业务流程与数据的要求，这是协作模式的原动力。

协作模式的优势是不同业务单元之间的协同效应，给顾客提供更完善的服务。这家澳洲的保险集团从2011年启动了数据整合的行动，将原来的十多个后台核心保险系统整合成两个，并建立“顾客数据总线”来汇集顾客在若干保险品牌、种类、渠道、乃至银行等其他金融服务中留下的数据，建立对顾客的全面认知。当在线渠道领域以复制模式发展的同时，该保险集团的线下电销领域以协作模式优化其服务。

协作模式的最大挑战是对齐各个系统对于数据的语法和语义，这背后涉及的不仅是IT，还有业务单元的权力之争。企业架构师在这种模式下应该关注的重心是企业核心应用和/或中台系统的建设：用什么样的中台功能承载各业务单元目前的业务需求、并为各业务单元创造价值，可能是促使业务数据整合的重要推手。例如阿里中台的建设过程中，淘宝和天猫之所以有动力把用户、商品、交易、店铺等核心数据归拢到共享中台，起初的契机是因为中台提供的团购能力能够立即为它们所用。

第四种经营模式是高标准度、高整合度的统一（Unification）模式。在这种模式下，新系统会采用标准的技术模板、工具、方法，基于已有的数据和业务流程来构建，企业所追求的目标将是新业务的上市速度和战略敏捷度。

当技术的标准化和业务的整合都达到很高水平，IT组织就有能力把现有的业务功能包装成即插即用的业务流程和能力模块，以微服务的形式提供给前端系统的使用者（包括企业外的第三方开发者）。此时企业IT已经成为行业领域的平台，前端应用的开发者能够快速开发新的应用、借助平台数据迅速触达用户、并立即获知顾客反馈。不过这种模式也并非没有风险：规划与建设这样一个平台需要的成本非常高，并且高度统一化的IT系统建设与运营流程潜在地有可能限制技术与业务创新的涌现，甚至使企业错失颠覆性创新的机遇。

在统一模式下，企业架构师需要关注几个方面的问题。首先，他需要关注建设可复用的业务流程与能力组件；同时，他也需要关注建设覆盖软件全生命周期的开发-运维支撑体系；最后，他还要时刻留意技术与业务趋势的动向，考虑是否需要主动引入创新要素。

从海尔模式看数字化平台

关于数字化、网络化转型的目标，海尔的定义是：企业无边界、管理无领导、供应链无尺度。企业无边界，意味着要让全球第一流的资源进入海尔，并能够持续动态优化。管理无领导，即打破科层制组织，让员工与用户零距离连接，拥有自主权，快速响应市场，最终实现“无为而治”的最高境界。供应链无尺度，要探索按需设计、按需制造和按需配送的体系，实现从大规模制造向大规模定制的转变。

与这个定义相对应的运营体系是人单合一管理模式，其中包括了顾客价值、自主经营体、日清体系和人单酬四个基本要素，分别体现了业务经营的目标、组织形态、工作方式、度量方法。对顾客价值负责的自主经营体，抢单进人、按单获酬，日常工作讲究日清日高，那么自主经营体必然就会进化为与顾客、与市场、与业务价值高度对齐的“双创小微”。

双创小微具有驱动力强、响应灵活的优势，潜在的劣势则有两个方面：第一是小微目标与公司目标缺乏对齐、彼此之间形不成协作效应；第二是基础能力缺失或重复建设，不能保障服务交付的高效与高质量。经过多年的探索，海尔发现三层结构既能体现足够的控制，又能够维持各个系统自身的活力。所以，在海尔的自主经营体结构中，有三个层次的自主经营体，分别是一级经营体、二级经营体和三级经营体。

• 一级经营体，又称为一线经营体，这些经营体直接面对顾客，为所负责的顾客群创造价值。
• 二级经营体，又称为平台经营体，它们为一线经营体提供资源和专业的服务支持，包括人力资源管理、供应链、市场营销、质量体系、战略管理等，所以，平台经营体是一级经营体的资源平台、流程平台、专业化服务平台。
• 三级经营体，又称为战略经营体，主要负责制定战略方向，解决内部的协同和发现新的市场机会，同时为经营体配置资源，帮助一级经营体和平台经营体达成目标。

这个结构与1960年代英国控制论学家斯塔福·比尔提出的“可生存系统模型”有异曲同工之处。如果将可生存系统模型简化为“肌肉（系统1）-神经（系统2/3）-脑（系统4/5）”的三级，它的落地形态就会类似于海尔的三级自主经营体。

双创小微有三个基础：制度之基是用户体验交互制，人才之基是创业者，平台之基是云平台。云平台可以看作是二级经营体的IT替身：为了面向大量、变化频繁的小微（海尔8万多员工分为2千多个自主经营体），为了跨越企业边界支持企业内外的创业者，平台经营体不可能再靠人工提供服务，必须以云平台的形式提供小微需要的资源和服务。

于是人单合一管理模式就演变为一个创业平台模式，它包括一个主题和两个功能。海尔人单合一创业平台模式的主题是“人和机会的匹配”，即创业者和创业机会的匹配。为了服务这个主题，它有两个主要功能：创业机会的识别和创造（Opportunity Creation）和创业机会的转化和实现（Opportunity Capture）。前者聚焦于创业者如何把市场上的潜在需求转化和升级为消费者的实际需求，从而识别、发现或者创造出新的商业机会；后者则强调通过一系列机制设计、制度安排、创新策略等将战略机会进行转化，从而为消费者创造价值。

基于机会创造和机会捕捉这两个功能，海尔交互与协同平台是人单合一管理模式最为重要的信息支持平台。海尔交互与协同平台包括6大系统：以顾客为主的虚实交互平台、开放式创新平台、供应链信息平台；以员工为主的电子损益表、电子人单酬表、信息化日清平台。

用《智慧转型》的框架来分析，这些系统帮助一线经营体获得4种能力，从而更好地为顾客创造价值：

1. 准确掌握顾客和市场需要的能力
2. 快速、高质量、低成本地交付顾客所需价值的能力
3. 基于数据了解并改进工作状态的能力
4. 通过受控实验快速验证创新的能力

在创业平台模式下，顾客、企业和员工都被重新定义。顾客被重新定义为“资源”，员工被重新定义为“创客”，企业则被重新定义为数字平台。在海尔组织中只有平台主、小微主和小微成员三类角色，小微成为为用户负责的独立运营主体，只有为用户创造价值才能获得报酬，充分享有决策权、用人权和分配权。小微和平台之间是市场结算关系，平台的报酬源自小微。从这个角度，海尔的组织变革不是简单的扁平化、跨部门和跨层级通道的建立，或者新设部门。海尔组织变革核心是在一流资源和用户之间架构起快速配置资源的平台，释放平台的同边和跨边网络价值。

毕业设计中使用敏捷方法的尝试

从CNKI收录的共计超过1000篇与敏捷软件开发相关的论文中，我找到了5篇关于在毕业设计中使用敏捷方法的文章，从一个侧面勾勒出高校教育工作者看待敏捷的一种视角。

最早谈这个话题的是广东工业大学计算机学院的刘竹松、李振坤、王文彦三位作者。他们于2007年发表的《极限编程在计算机本科毕业设计中的应用》一文中认为，“将极限编程应用到计算机专业本科毕业设计中”的主要目的是“有助于学生形成团队合作的精神”，从而“促进学生学习的兴趣，加强学生综合应用各方面知识的能力，增强学生之间的相互交流、相互学习，提高毕业设计的整体效果”。从这个出发点，作者们认为“极限编程的核心是结对编程”，具体实施时谈的也是“合理设计结对”和“合理分配任务”。

（这篇文章先后发表在《电脑知识与技术》和《计算机教育》两个期刊，可能是作者一稿多投。所以讨论“在毕业设计中使用敏捷方法”这一主题的文章其实只有4篇。）

稍后，2007年10月，大理学院数学与计算机学院的杨健、张晓玲、周少云三位作者在《计算机时代》发表了《软件开发类毕业设计中敏捷软件技术的应用》一文。在这篇文章中，作者尝试解决“毕业设计质量低下，学生得不到真正锻炼”的问题，具体表现形式包括“软件各个功能模块无法有效整合”、“需求因为各种原因不断改变”、“软件的错误和缺陷不断涌现”等。与此前的刘文不同，杨文尝试回答的问题更为全面，包含了沟通、需求、质量等多个角度。因此在看待敏捷方法时，三位作者关注到了更为全面的多个敏捷原则，包括“增量式开发、可持续的开发速度、简单、结对编程、适应改变、个体激励和交流、反省”等。值得注意的是，这些概念在敏捷软件开发的理论框架中并不都是“原则”，有一些是具体的实践。并且杨文完全没有提及测试驱动开发、持续集成等技术性的实践，也没有提及用户故事、看板等需求管理和迭代管理的实践。似乎三位作者的关注点主要还是在团队内部的交流和协作，对于团队对外的呈现（需求的获取和管理、项目进度、软件质量）的考虑较少。

第三篇文章是石家庄外经贸职业学院的马静媛和河北交通职业技术学院的薛惠于2009年发表于《电脑知识与技术》的《极限编程在高职计算机专业毕业设计中的应用》。与刘文相似，这篇文章想要达到的目标也是“加强学生综合应用各方面知识的能力，挖掘学生的学习潜力，并且培养学生之间的合作意识，提高毕业设计的整体水平”，重心仍然是在团队的内部与沟通协作上。与刘文和杨文相比，马文明确指出了极限编程的12个最佳实践，并着重讨论其中的简单设计、结对编程和集体代码所有制三个实践。另外，马文提出了对测试驱动开发实践的要求：“编码之前必须先写好单元测试代码”、“代码完成后用编码前编写的测试用例进行单元测试”、“代码和测试用例一起存入代码库”。马文没有提及如何划分用户故事和开发任务，也没有提及持续集成，从文中无法判断，学生在实际开展测试驱动开发时是否遇到任务过大、失败的测试被荒废等问题。

第四篇文章是湖南工业大学计算机与通信学院的曾志浩和肖小克于2012年发表于《计算机教育》的《以敏捷开发和极限编程为指导的软件工程毕业设计》。曾文与前三篇文章有一个显著的区别：这篇文章的关注重心不在内部的沟通、协作和学生能力培养，更多地关注毕业设计的进度和质量这两个对外指标。以此为出发点，曾文提出了一套“以AD和XP为指导的毕业设计过程”，包括项目的组织方式、管理方式和考核方式，并给出了具体的“典型过程及相关支撑工具”。在管理侧，曾文提出“贯穿整个毕业设计过程，以各个阶段时间点为标志，要求学生以增量的方式来完善项目开发”，并在考核时注重代码功能而非文档、交叉检查结对学生的编码工作量、要求学生就系统的多个可运行版本进行演示等，把敏捷实践与毕业设计考核方式相结合。在工具侧，曾文仅推荐了测试管理工具Mercury Quality Center和持续集成工具Jenkins，并未推荐具体的测试工具。这可能是为了顾及建议的通用性，但也给具体项目开展时自动化测试和测试驱动开发的落地留下了一个问号。

综观这四篇文章，我们可以勾勒出敏捷方法在中国高校计算机教育领域的历程。从早期的刘文以偏概全地看到一个特立独行的实践（结对编程）、杨文对敏捷理论的解读不清晰不准确，到马文能够准确描述极限编程的实践、并有意识地选择自己需要的实践，再到曾文从组织、管理、考核等角度全方位运用并辅以工具支撑，我们能看到中国高校计算机专业指导老师逐步深化对敏捷理解的过程。另一方面，从刘文直到曾文，对于测试驱动开发和重构的描述是语焉不详的，关于持续集成的具体实践和具体挑战的论述是缺位的，由此不难想象，在实际的毕业设计项目中，这些技术性的实践很可能并没有得到有效实施，于是敏捷会更多地退化为一种鼓励沟通、鼓励协作的团队运作方式——这与前三篇文章的诉求相一致，而曾文也没能提供技术性支撑工具（尤其是Jenkins）在实施中的真实情况。这种“重沟通轻技术”的敏捷采纳方式，恰是敏捷在整个中国IT业的境遇缩影。

敏捷在中文期刊中的投影

在中国推广敏捷软件开发方法十五年之后，我很想回头去看这段历史的全景。今天我用知网做了一些检索，看到了一些有趣的数据。

我在所有期刊中检索主题中包含“敏捷”和“软件”的文章。其他的关键词检索会得出略有不同的结果。如果只用“敏捷”作为关键词，会得到13258条结果，但其中绝大多数与我想要谈论的软件开发方法无关。这是“敏捷”这个译名词的宿命：它是一个普遍被认可的、带有褒义的形容词，使用这个词让听众更容易接纳这些新千年以后发展起来的新方法学。但与此同时，这个译名也让听众产生更多的误解：很多人会以自己的想法去期望这些新方法学，而不去深究它们的内涵。

我尝试的另一个检索条件是把文献类别限定在“计算机软件及计算机应用”，并检索主题中包含“敏捷”、且不包含“制造”的文章。排除“制造”的原因是“敏捷制造”也是一个相当热门、且与计算机技术很有关系的领域。这个检索的结果从统计上看与前一个相去不远。以下我主要讨论第一个检索的结果。从相关关键词来看，这个结果是比较准确的。

首先，令我略有些惊讶且失望：检索到的文章只有972篇。作为对比，“云计算”检索到的文章有10880篇，“软件工程”有9890篇，“SOA”也有3992篇。回顾这十五年，不论在IT技术领域还是软件工程领域，敏捷仍然是一个非常小众的话题。

从时间趋势来看，2001年及以前有一些涉及“敏捷”和“软件”主题的文章，虽然并不与现在意义上的“敏捷软件开发”直接关联，但在理念上有一定相通之处。除了敏捷制造、敏捷物流等领域的文章之外，向华和邹平的文章、赵捧未和窦永香的文章、段永强、张申生、高国军的文章都提及了“基于对象的软件代理”概念，这可能是“前敏捷时代”一个值得探寻的线索。

“敏捷软件开发”这个名词的出现是在2001年，并于2002年正式进入了中文期刊的话语空间，从时间轴上可以清晰地看出这个趋势。从统计数据上看，敏捷的潮流在2007年达到高峰，从2011年开始有一次显著的下滑，随后又逐渐回暖。这里面有一个异常因素：《程序员》杂志2010年以后的数据没有被知网收录。但即使排除这个因素，大趋势估计相去不远。某种程度上，这个曲线和Gartner的“技术成熟度曲线”（或者叫吹牛逼曲线）有某种暗合之处。

然后——我不知道该高兴还是悲伤——《程序员》杂志无疑地在这场潮流中扮演了领袖角色。在所有检索到的文章中，《程序员》发表的超过20%，与其他任何报刊杂志都不在同一个数量级上。排名第二的《电脑知识与技术》在十五年中发表了共计23篇相关文章，我觉得这就基本上可以解读为“毫不关心”。《程序员》在2002年3月的《极限编程》专题，经确认，的确是中国期刊中最早介绍敏捷方法的一组文章。（实际上，《程序员》2001年12期的《代码重构》专题还略早于此，但由于刊号变迁的缘故，知网没有正确收录《程序员》2001年的内容，而是收录了之前使用该刊号的《Internet信息世界》的内容。）最早引介敏捷方法，并在之后的几年中贡献了整个期刊领域最多的篇幅。我们可以无疑地确认，《程序员》是敏捷方法在中国期刊领域最重要的——并且也是唯一的——支持者。这一数据，从一个侧面映射出敏捷在中国传奇而又尴尬的境遇。

云原生软件开发九要素

随着云计算逐渐成为主流的计算环境，我们提出这样一个问题：在云原生（Cloud Native）的环境下，软件开发应该是怎样的？在其他领域，我们看到云计算带来了弹性、标准化和更高的效率。当云成为软件开发团队的缺省环境，哪些实践能帮助他们兑现云计算的价值？各个组织、各个团队采用的软件开发方法论和流程各有不同，我们尝试找出一个最佳实践的最小集合：如果缺少其中的任一实践，就会在一定程度上妨碍团队享受云计算能带来的价值。从这个角度出发，我们识别出了下面这个列表：

脚手架

开发一个应用，采用什么基础框架、代码目录结构怎么安排、引入哪些测试工具、使用什么构建工具、遵循什么构建流程，这些问题在典型的应用类型（例如“Java微服务”或者“React前端应用”）下都有成熟的答案。大多数情况下，新的项目不应该从头新建这一套结构：一来是为了节省工作量，二来更重要的是应该尽量复用已有的最佳实践。建议的做法是使用标准的脚手架，例如JHipster或者其他基于Yeoman的生成器可以提供较为通用的脚手架，IT组织也可以设计自己的标准脚手架。

自包含应用

应用程序应该尽可能少依赖周边环境。对周边环境依赖越少，因为环境差异而带来的工作量和错误就会越少。以Java应用为例，基于Spring Boot的独立应用，就比依赖Tomcat甚至WebSphere应用服务器的应用更具自包含性，环境的配置和管理都会容易得多。其他例如npm、rvm等工具都意图让应用程序更具自包含性。

统一构建

每一次构建，不论是由开发者自行发起的，还是在持续集成环境执行的构建，都应该尽量、最好是完全一致。为了达到这种效果，不仅构建工具和构建流程本身统一，执行构建的外部环境也应该统一。最好的方式是把构建放在虚拟机或容器里进行，而不是在彼此不同的计算机上执行。为了避免个人电脑计算资源的局限，构建最好是在云上进行。

镜像化

为了保证构建的外部环境完全统一，执行构建的不应该是各自不同的计算机，而应该是虚拟机或容器。因此运行应用程序的机器应该被镜像化。Vagrant之类的工具提供了很好的版本化管理虚拟机镜像的能力，但VMWare和VirtualBox等虚拟机在性能上和资源占用上都并不鼓励频繁启停的使用方式，Docker等容器技术可能是更好的选择。构建产物也应该是可执行的容器镜像。

基础设施即代码

为了保证构建的外部环境完全统一，获得运行环境的过程应该完全自动化，不应该允许任何手动修改运行环境的情况。如果运行环境是不可变的，那么就可以随时抛弃并重建。因此环境的配置应该以代码形式记录并自动化，并且还能顺便得到环境可以版本管理、可以自动化测试等好处。

构建产物仓库

构建成功的产物应该被放入统一的仓库，并分版本管理。这样做的目的是按照《持续交付》的理念，整个构建发布流程中使用用同一个构建产物；并且统一且分版本管理的构建产物可以在组织内复用。Nexus可以用于管理各种构建产物，包括容器镜像。

弹性运行环境

运行应用程序的环境，不论是用于执行测试、还是用于试用、培训、用户验收测试、乃至生产，都应该是弹性的：需要时可以立即开通，不需要时可以理解销毁。对于生产系统，运行环境的弹性使系统可以随负载水平扩展，使各种路由技术成为可能；对于开发、测试、预发布等场景，运行环境的弹性使环境开通和使用变得简单且不会出错。

服务质量透明

诸如高吞吐量、高可用性、高安全性、双机热备等服务质量，由运维或数据库的专家配置好，在生产环境提供给应用程序使用时，只暴露IP地址和端口（甚至只有端口）。对于应用开发者而言，服务质量是透明的，不会感觉到生产环境与开发环境依赖的外部服务有任何差别。

诊断信息服务

当构建和运行都在容器中乃至云上发生，并且容器是为应用程序专门定制的，调试诊断必然不能像在本地开发机器一样直接。需要借助完善的日志、监控等方式（例如基于Splunk或ELK的方案）的来提供应用程序的诊断信息。诊断信息服务不仅作用于生产环境，测试、开发、构建等各个环境也使用同样的方式获得诊断信息。

人生赢家弗洛雷斯

费尔南多·弗洛雷斯有着传奇的一生。他作为理工科的好学生留校，在智利社会主义的浪潮中涉足政坛，因为科技背景步步高升，陪着萨尔瓦多·阿连德总统走完政权和人生的最后一段路，作为政治犯坐了三年牢，然后摇身一变成为世界级学霸，顺便在硅谷搞了两家创业公司挣了一大把钱，终于衣锦还乡再次投身政治，支持的却是与阿连德政纲截然不同的总统。

（本文绝大部分内容出自《控制论革命者》一书。）

工科背景

弗洛雷斯于1943年出生于塔尔卡市，位于智利首都圣地亚哥以南200多公里的一个城市。他的父亲是铁路工程师，母亲经营着一家小型的木材公司。在学校里，他是一个思维敏捷、尤其擅长数学的好学生。尽管还不知道未来的人生要干什么，弗洛雷斯已经意识到成为工程师是“一件大事”，所以他申请了天主教大学的工程学院，并被这所声名远播的大学接纳。在2003年的一次访谈中，他猜测自己可能是家族里第一个接受了大学教育的人。在正式的大学教育之外，一系列的人际关系、工作经历和政治变迁让弗洛雷斯发现了控制论和比尔。在大学里，弗洛雷斯跟随阿诺尔多·海克斯学习运筹学，后者在1963年至1964年间任天主教大学工程学院院长，后来接受了MIT斯隆管理学院的教授职位。

因为弗洛雷斯受过运筹学训练，[斯塔福·比尔的公司]SIGMA雇佣他在智利铁路的项目上[作为实习学生]工作。在这个项目上，他接触到了《控制论与管理》，一本在他看来“脑洞大开”的书。弗洛雷斯于1968年毕业，获得工业工程学位。……1968年至1970年间，弗洛雷斯在天主教大学工程学院任教务主任，随后他的职责范围逐渐扩展到了大学的各项事务。

初涉政坛

这一时期大学正在进行改革，弗洛雷斯监督开展了很多工程课程的改革，包括增加课堂与社会的联系。和很多同时代人一样，弗洛雷斯在学术圈和政治圈都很活跃。1969年，弗洛雷斯等一群天主教大学的年轻知识分子脱离基督教民主党，成立了“统一人民行动运动”（简称“MAPU”）。这个由年轻知识分子组成的小型政党批评基督教民主党和总统爱德华多·弗雷·蒙塔尔瓦（1964年至1970年在位）采取的中间路线，与左翼的人民阵线中的共产主义者和社会主义者政见一致。MAPU加入人民阵线，再加上右翼和基督教民主党组成的获胜联盟内部的不稳定因素，最终促成社会主义者阿连德在1970年大选中以微弱优势获胜。

作为对弗洛雷斯政治忠诚和技术能力的认可，阿连德政府将他任命为国家开发公司（简称“CORFO”）的技术总监，这家公司的使命是国有化智利的工业。弗洛雷斯成为了国家开发公司的三号人物，也是MAPU成员占据的最高位置。他最重要的职责就是管理已经国有化的工厂的日常调控。

步步高升

[Cybersyn]项目的资金部分来自国家科技学院，该学院的预算一直在增加；另一部分资金来自CORFO，这是全国资金最充裕的政府机关之一，毕竟它的使命是指导国家经济。弗洛雷斯在这两个机构都担任高管，既是发展机构CORFO的三号人物，也是国家科技学院的理事长。他动用了各种社会和组织关系来保障这个项目需要的财政、物资和人力资源，其中大部分是通过非正式渠道获得的。“我有很大的权力。”弗洛雷斯承认。不过CORFO实在太庞大了，弗洛雷斯与比尔提议的这个项目仅需要其整个预算中的一小部分。

……比尔见到了阿连德，获得了总统的许可继续开展他的项目。但比尔相信这次会见还有别的意义。他猜测弗洛雷斯想在智利政府中更广泛地应用控制论原理，而不仅是用于管理国有经济，这次会见则会帮弗洛雷斯未来的项目铺平道路。团队中最了解政治的施温伯提供了另一种解读。弗洛雷斯“有着更高级的大脑，”施温伯这样说道，“非常复杂，老于世故，精明能干，有时甚至是狡诈，但绝对精明。”弗洛雷斯很早就认识到了这个系统的科技价值和政治价值。照施温伯的看法，比尔与阿连德的会见一方面是为了解释正在开发的控制论管理系统，另一方面也是为了“让阿连德意识到有这么一个人，弗洛雷斯，掌管着这种力量”。弗洛雷斯希望给总统留下这样的印象：他是科技专家，并且他正在为政府做着有趣、大胆而且可能很有价值的工作。最重要的是，这次会见确认了弗洛雷斯与比尔之间的工作同盟，把阿连德也拉进了项目中。这次会见再次强调了在智利社会主义道路上正在发生的科技创新与政治创新之间的相互依赖关系。

[1972年]10月初，弗洛雷斯升任经济部副部长。[发生于1972年的]十月罢工后，这位29岁的年轻人被总统任命为经济部长。……弗洛雷斯相信是他对科技的使用帮他赢得了这个内阁级别的位置，他认为继续发展自己作为科技专家的形象或许能给他带来政治上的优势。

大厦将倾

弗洛雷斯仍然是阿连德内阁的成员，但他在[1973年]新年当天离开了刚上任两个月的经济部长职位，转任财政部长。这个新的任命使弗洛雷斯离Cybersyn项目更远了。

在[发生于1973年8月的]第二次卡车主罢工期间……阿连德任命弗洛雷斯担任政府的秘书长，负责政府对内对外的沟通。在风雨飘摇的智利政府中，弗洛雷斯已经占据了一个最高的位置，此时他才刚刚30岁。

[1973年9月11日武装政变发生时]弗洛雷斯……已经是阿连德身边最贴近的助手之一，轰炸发生时他正与总统在一起，一直与军方保持着电话联系。他告知阿连德，军方要求总统立即、无条件投降。总统拒绝了这个要求，并派弗洛雷斯去和军方谈判。弗洛雷斯刚走出建筑即被逮捕，从此没有再见到总统。

费尔南多·弗洛雷斯作为政治犯在监狱里呆了3年。……1976年，大赦国际的旧金山分部成功地通过谈判促成弗洛雷斯获释，并在斯坦福大学计算机科学系给他安排了为期一年的研究职位。

变身学霸

在斯坦福，他遇到了计算机科学家特里·维诺格拉德，两人在1970年代后期和1980年代紧密合作。

弗洛雷斯在加州大学伯克利分校获得了博士学位，师从哲学家约翰·赛尔、休伯特·德莱弗斯和经济学家安·马库森。他于1982年完成的毕业论文讨论了如何在“未来的办公室”里用计算机改进管理和交流。……比尔在早年间对弗洛雷斯的想法有所影响，但在完成毕业论文的时候，弗洛雷斯的关注点已经从管理控制论转移到言语行为理论和海德格尔哲学，因为这些是他的博士委员会成员专擅的领域。

1986年，弗洛雷斯发表了他的第一本书，与维诺格拉德合著的《理解计算机和认知》（Understanding Computers and Cognition）。这本书结合了计算机领域的问题与“生物本质、语言、人类行为本质等方面的理论”，着重讨论计算机能和不能从事哪些人类实践。……美国信息科学学会把《理解计算机和认知》评为1987年“最佳信息科学书籍”，这本书现在被认为是人机交互领域的关键文本之一。

[注：约翰·赛尔和休伯特·德莱弗斯是人工智能哲学领域的大师；特里·维诺格拉德是人机交互领域的大师，1995年至1998年间指导了谷歌创始人拉里·佩奇的博士研究。]

名利双收

1980年代，弗洛雷斯还转型成了一名硅谷企业家。他创立了教育咨询公司Logonet，向商业社会传授本体论设计思想。他还跟维诺格拉德一起创立了Action科技公司，开发了名为“协调者工作组生产力系统”的软件包，他们自称是第一款用于计算机网络的工作组系统。……后来一位记者称“协调者”是“全世界第一款社交网络软件”。

1989年，弗洛雷斯又成立了一家咨询公司，名叫“商业设计合伙人”，或者简称BDA。BDA向困境中的企业传授言语行为理论的原则，例如提出明确的请求、做出明确的承诺等，试图以这种方式改变这些企业。……在其巅峰时，BDA有150名员工，在3个大陆上开展工作，年收入5千万美元。……到2007年，弗洛雷斯的财富净值据估算达到了4千万美元。他的名气也随着财富一道蒸蒸日上。有人认为他唐突、脾气暴躁、说话直接甚至是粗鲁、惹人讨厌；但他对外传递的讯息，以及他在学界和商界的成功，让不少人把他视为偶像。

2002年，弗洛雷斯以百万富商的身份回到智利，并作为国家最北端地区的代表被选为参议员，由此开启了他作为政治家的人生新篇章。2008年，他脱离支持他当选参议员的中左联盟，成立了自己的政党“智利第一党”。2009年，他又完全转变立场，公开支持右翼总统候选人、亿万富商塞巴斯蒂安·皮涅拉。最终皮涅拉赢得了大选。

[2010年3月，弗洛雷斯被皮涅拉总统任命为智利国家竞争力创新委员会主席。]

技术领导者即服务

八年前我写了一篇文章《Tech Lead的三重人格》。迄今为止为数众多的敏捷交付团队中，Tech Lead（技术领导者）对于交付的效能和质量起着至关重要的作用。我在那篇文章中指出，Tech Lead需要扮演三种重要的角色：技术决策者、流程监督人、干扰过滤器。一支团队能否有效采用架构最佳实践、交付流程最佳实践和项目运作最佳实践，很大程度上取决于Tech Lead把自己的工作完成得多好。

如果更进一步把这篇文章中Tech Lead承担的责任做一个拆解，我们可以看到，一个称职的Tech Lead是这样去为项目的顺利交付做出贡献的：

• 首先，他要制订适合该项目要求的技术方案。他要参与架构设计，了解平台和编程语言、主要的框架和库、集成点、部署策略、数据迁移策略，确认总体技术方案能够支撑系统的业务要求。
• 随后，他要保障交付顺利开展。他要确保环境的一致性，搭建和管理持续集成流水线，指导并监督团队遵循持续集成的流程和实践。
• 最后但绝非最不重要的，他还要管理和提升团队的能力。他需要确认团队是否熟悉用到的技术栈和工具，而且——虽然这一点在我写文章时的ThoughtWorks还不那么凸显——要帮助团队成员组织刻意练习来提升能力。

正如当时那篇文章的一位读者非常正确地指出的，要一个人做这三方面的贡献很多时候是不切实际的。在很多组织里，这三件事是在三个环节中分别进行的，这三个环节的彼此割裂造成了很多问题：

• 在方案环节，架构师根据客户的要求和痛点，基于自己的知识储备设计技术解决方案。他是如何分析客户的要求和痛点，他的知识储备是什么，组织里的其他人不一定知道，于是不同架构师提出的解决方案就很可能不一样。
• 在交付环节，交付团队基于自己的知识储备来交付技术解决方案。方案背后隐含的知识储备，交付团队未必具备，所以屡屡会出现交付质量不佳的问题。不是他们没有能力，只是能力与方案的需要不符。
• 组织感到团队的能力有不足，于是找来教练提升能力。然而教练基于的是一个标准的能力集来训练团队，这个能力集与项目实际需要的能力又不一定匹配。于是出现能力发展计划不对症、能力建设效果不明显的问题。

由此可见，只有当方案、交付、能力三者有很好的协同，项目和团队才能健康成长。而这个协同之所以尤其困难，是因为它跨了三个非常不同的问题域（在很多组织是三个不同的功能部门），需要三种非常不同的能力，对这个居中协调者的要求非常高。

所以，如果我们能用一个云上的平台来承载这个居中协调者的能力，对整个组织的交付质量和能力成长都会有帮助。这个平台的核心实际上就是技术栈管理：针对典型的应用场景（例如企业资源服务化、移动数字化渠道），制订组织统一的技术栈，并从技术栈推导出对应的能力评估模型和刻意练习课程。于是我们就得到了以技术栈为核心的IT能力三环联动模型：

当提供技术方案的架构师选择一个技术栈，用这个技术栈交付软件的能力要求就被明确地传达到交付团队。交付团队不用自己去设置开发环境和持续交付流水线，用云原生的持续交付环境即可启动开发，并复用在技术栈上积累的交付最佳实践。通过云上的能力测评系统，能力教练可以清晰地知道哪些成员已经具备需要的能力、哪些成员能力还有差距，然后为有差距的成员提供针对性的刻意练习和指导。

云计算已经成功地模糊了硬件与软件的界限，使IT的一大挑战——管理设备——极大简化。现在，对于IT的另一个大挑战：人才短缺，云计算的“XXX as a service”模式是否可以继续发挥作用？IT组织是否可能借助云计算获得优质IT人才的弹性和伸缩性？这是一个值得去探索的课题。在这个方向上，将对交付质量与效能起着重要影响的Tech Lead的能力以云平台服务的形式提供，有可能是触手可及的一个目标。

言说信息时代的奴隶制

[本文系《再见i奴》（Goodbye iSlave）的书评，以《信息时代的三角贸易》为题同步发表于土逗公社。]

毫不意外地，柯洁在三番棋中完败软硬件全面升级的AlphaGo。这场“人机大战”再次让人工智能成了街谈巷议的热点。在感叹科技进步一日千里的同时，大众也表达出了对人工智能飞速发展的担忧。不过，据笔者的观察，这种担忧大多数时候仍然是一种“终结者”式的想象，即担心机器拥有智能以后全面取代甚至统治、消灭人类。2015年6月，德国斯图加特的一家汽车工厂里发生致人死亡的工业事故，媒体在报道时竞相使用“机器人杀人”、“机器人把技术员按倒打死”这样耸人听闻的标题。类似这样的大众舆论反映出人们对智能技术的双重恐惧：不仅隐然感到科技的发展值得担心，而且隐然感到自己不知究竟应该担心什么。

诚如维特根斯坦所说，“凡不可言说者必保持沉默”。在众多学者的话语中，对科技、尤其是信息技术的担忧具有两个明显的特征：它们通常具有强烈的未来主义色彩，多在谈论十余年、数十年后的“近未来”图景；而且它们多在强调“机器vs.人类”的关系。不论凯文·凯利还是博斯特罗姆，他们引人瞩目的作品都在谈论“超级智能”如何在不远的将来取代人类。然而这两个特征却有一种微妙而深远的影响：它们让读者觉得科技对人的威胁尽管存在，但毕竟尚未发生、而且对所有人的威胁是均等的。

从这个意义上，邱林川的这本《再见i奴》（Goodbye iSlave，伊利诺伊大学出版社2016年）提出了一种新的言说方式，使“信息技术可能带来什么危害”这个问题呈现出一个全新的面向：信息技术的发展对人造成伤害，这件事无需等到未来，它早已在发生；而且这种伤害绝非均质的“机器伤害（所有）人类”，科技作为一种工具，再现与强化了人类社会古而有之的权力关系，使一些人受损、另一些人受益。在信息时代被高新科技再现与强化的关系究竟是什么？作者极富洞察力地指出：那就是奴隶制。

尽管玫瑰的芬芳并不依赖于它的名字，但对于社会权力关系这种抽象事物，用什么语言谈论它，会直接影响受众的观感。当富士康、苹果和优步不约而同地声称为他们打工的劳动者是“自由的”，作者一针见血地指出了现代信息技术产业与十七世纪的奴隶制经济之间的共性：一方面，它们都建立在对劳动者的全面控制、甚至是对人身自由的控制基础上，富士康在连续跳楼事件之后安装的“防跳网”偶然而又必然地重现了十七世纪大西洋上运奴船上的设置，因为只有剥夺劳动者的人身自由乃至“自杀权”才能从他们身上榨取最大的剩余价值；另一方面，它们都着力生产“成瘾性消费品”，iPhone和微信就像白糖和咖啡一样让消费者深陷其中不能自拔，这才保障了廉价奴工生产出来的产品源源不断地被消费。在这一产业体系中，不仅在富士康生产iPhone的工人如同奴隶一般被控制，使用iPhone的消费者同样如同奴隶一般被规训——邱林川将前者称为“制造的奴隶”，后者则被称为“被制造的奴隶”。

信息技术产业与奴隶制，这个或许令人吃惊、但绝非无中生有的类比，就像“玫瑰的名字”一样，让我们突然获得了一种能力，可以去谈论一些司空见惯、却又难以捕捉的问题。例如“低头族”：我们身边的年轻人（以及我们自己）随时随地都在低头玩手机，竟然到了城市专门开设“手机人行道”的地步，对此我们本能地感到不满，却不知该如何批评这一现象。直到邱林川说，这些人是“i奴”——信息时代的奴隶。于是我们恍然大悟：双手被无形的镣铐捆绑举在胸前，双脚只能沿着画好的路线前行，这可不就是奴隶的形象吗？为了让这个类比更加贴切，作者专门研究了与奴隶制相关的大量文献。当我们看到奴隶制的若干特征与当代信息产业的现状竟然高度吻合，这个类比给我们带来的冲击绝非仅仅是比喻意义上的。

有了一个可以被谈论的问题，我们就能更有效地去发现潜在的解决办法。针对奴隶制对奴工的人身控制和成瘾性消费两大特征，作者将视野投向全球，并发现了一些可能的替代方案，例如劳动者共同拥有、民主治理的“平台合作主义”，例如重视供应链社会效应、以耐用性（而非消耗性）为卖点的“公平手机”等。尽管这些替代方案尚显稚嫩，但毕竟让我们看到了“另一种方案”的可能性；而为了去发现“另一种方案”，首先就必须有一套批判的话语来指出现状中的缺陷。从这个意义上，邱林川这本《再见i奴》可能是在看似牢不可破的资本与科技共同铸就的铁板上划开了第一道裂痕。

博斯特罗姆在《超级智能》中的一个观点我个人非常赞同：信息技术的发展如此迅猛，我们很可能正处在一个决定人类命运的拐点上。然而当大众——在科技与资本精英的引导下——担心着几十年后人工智能是否会统治世界的时候，邱林川给我们指出了一幅更加现实也可能更加危险的图景：这个科技拐点将要决定的，可能是科技究竟让大多数人从此过上幸福的生活、还是把大多数人变成奴隶。这两者之中较为美好的那种前景，不会无缘无故自动发生的。拥有合适的语汇去谈论和批评，乃是我们能够对这次选择产生影响的第一步。

云原生平台：市场现状分析

对于期望获得云原生能力的企业，在IaaS提供的云计算弹性与开发云原生应用之间，还有一个很大的空白地带：如何用云计算为软件交付的过程服务。Docker和Kubernetes等工具提供了容器化和容器编排的能力，但是企业需要解决“为了承载我（期望）的开发流程，我需要怎样的容器和编排”的问题。这就给云原生平台（Cloud Native Platforms）创造了市场空间。

总体介绍

为分布式云应用提供支撑的平台从2015年开始受到广泛的关注，围绕着Docker、容器编排等技术，开始出现各种商业模式。云原生平台可以视为下一代中间件，其用途是交付企业级分布式应用所需的各种支撑能力。以容器和容器编排为基础，云原生平台提供了日志、审计、安全、合规、权限管理、容器镜像仓、基础设施抽象、团队成员启动等支撑功能。

测试和开发环境的随需可得不仅仅有助于优化基础设施资源，而且有助于统一实践和流程，能促进团队采用敏捷和DevOps的最佳实践。把抽象层次提高一点，云原生平台要支撑云原生应用所需的5项能力：

1. 云平台自动化。不仅提供基础设施开通与配置的自动化，而且内嵌测试、版本控制、文档、软件生命周期管理等方面的最佳实践，使整个开发-测试-部署的过程工作量最小化。
2. 无状态函数。将软件以小型、目的单一的函数形式部署，通过事件驱动服务，从而避免维护运行时环境。
3. 微服务架构模式。每个服务提供单一的业务能力，能够独立开发、测试和部署。
4. DevOps流程和文化。自动化整个软件交付流水线，打破开发与运维的间隔，以全功能团队形式工作。
5. 云可靠性工程。提高运维工作的自动化程度，把运维重心放在平台工程，从而提高系统可靠性。

云原生平台可以大致分为“非结构化的/不带意见的”（unstructured/unopinionated）和“结构化的/带意见的”（structured/opinionated）两类。Pivotal声称Cloud Foundry作为一个“结构化的/带意见的”云原生平台，提供了下列能力：

• 服务作为比基础设施更高层级的抽象。Cloud Foundry提供按需部署应用的机制。
• 容器。所有应用程序都以容器形式运行。
• 敏捷和自动化。Cloud Foundry可以作为CI/CD的一部分，用于随需开通环境和服务。
• 微服务支撑。为松散耦合的服务架构提供集成和协作机制。
• 云原生应用支撑。对应用程序的约束使其效率更高、更易管理、更可靠。

从技术角度，云原生平台有5个重要的考量因素：

1. 如何加速应用开发的速度？
2. 如何推动新技术趋势（移动、社交、实时、数据核心、IoT）的应用？
3. 如何充分利用开源技术和社区？
4. 如何提升运维响应变化的能力？
5. 如何在平台中嵌入安全性？

部分产品分析

Apcera的定位是“支持云原生应用和遗留应用的容器管理平台”。主要的解决方案是“遗留应用现代化”，号称能在7天内把遗留系统迁移上云。

Apprenda是基于Kubernetes的面向开发团队的云平台，既能支持云原生应用、也能支持传统应用的开发。通过集中的云政策和监管、共享的应用服务、基于微服务的架构标准化，Apprenda把开发组织变成成熟的软件工厂。

HashiCorp Atlas在Vagrant的基础上规定了一个“开发-构建-产物管理-部署-上线”的标准流程。适用于以技术为核心、重视DevOps流程与文化的组织。

Cloud Foundry是重视部署与运维的云原生平台。强调的卖点是（1）部署的速度；（2）云应用的伸缩能力；（3）缺省的安全性。

OpenShift是基于Docker和Kubernetes的容器应用平台，支撑容器的开发、部署和管理。主要功能有（1）容器编排；（2）容器存储；（3）支持多种编程语言和框架；（4）自动化应用程序构建、部署、伸缩和健康管理；（5）基于项目的管理界面；（6）自服务平台。

CodeEnvy在Docker基础上为开发团队提供云上的工作区。CodeEnvy提供.NET、Android、C++、Java、Go等技术栈，用Eclipse Che作为开发环境。主要卖点有（1）一键式Docker环境；（2）团队成员启动和协作；（3）DevOps工作区平台。

Wercker是基于Docker的CI/CD自动化平台（类似于SnapCI），用Kubernetes提供容器编排，支持微服务部署，缺省支持GoLang、NodeJS、Ruby、Python。支持自定义的CI/CD流水线，通过流水线的级联和触发配置出复杂的工作流，支持并行测试。

DaoCloud基于容器技术从交付件、运行环境、环境配置、权限协作等多个方面定义企业交付流程标准，通过标准化提升跨部门协作的沟通效率，推动软件在不同阶段的自动化高效流转。高度灵活的交付流程定义引擎，支持可视化定义企业完整的端到端交付流程。通过云平台的弹性，支撑企业交付流程中不同阶段对环境运行时的需求。

数人云基于Mesos和docker，提供企业级持续集成和持续交付解决方案，从快速搭建持续集成环境，到改进和融合企业的开发、测试及持续发布流程，助力企业提升产品发布效率，规范产品开发流程。可以继承企业现有的版本控制工具，通过Jenkins实现自动构建和测试。