为什么一定要从 DevOps 走向 BizDevOps？

数字经济时代，数字化转型成为社会的普遍共识和行动。越来越多的业务运行在数字化基座之上，软件系统正成为业务创新的价值核心和创新引擎。在这一趋势下，软件产业面临着许多新挑战和新机遇：一方面，万物互联下软件系统规模和复杂度持续增长；而另一方面，业务的快速变化对软件交付效能的要求却不断提升；软件构建和交付方式亟待变革。

要解决问题，先直面问题。为更好地厘清波涛汹涌的数字化转型浪潮下软件产业所面对的机遇与挑战，6 月 29 日，阿里云云效与阿里云开发者评测局栏目，联合特邀了 InfoQ 极客帮副总裁付晓岩、南京大学软件工程学院教授张贺、Thoughtworks 全球数字化转型负责人肖然、国内精益产品开发最早实践者何勉（阿里云云效解决方案负责人），阿里云资深技术专家陈鑫（云效平台负责人）以及阿里云高级产品专家张裕（云效平台产品架构师）共 6 位领军人物，一起围绕数字化转型浪潮下的技术变局进行了深度的研讨。

数字环境下，各界如何看待科技发展与业技融合？

当前，央行侧重提升产业的整体数字化，同时还提出了更高的要求：希望业务系统或者业务创新能够实现跨角色、跨流程的自由编排和组合。这个要求即便对互联网企业来说都非常高，银行业等传统企业如果想通过企业级的工程，来整体提升业务和技术能力、实现业务和技术的融合，更是一件困难的事情。所以，需要一些新的方法论或工具来支撑。

今年年初，中国银保监会与人民银行发布的《关于银行业保险业数字化转型的指导意见》已经明确指出，在数字化时代要做到“业技融合”，同时 BizDevOps 这个词也已经被写入央行《金融科技发展规划（2022-2025 年）》中。这两份文件已经为银行的数字化转型提出了具体的要求和方法，变成了行业转型的参照。

金融行业天然走在数字化的前沿，已经享受到了数字化的红利。但是，还有很多产业和行业仍面临挑战。比如，生产线的出现可以让企业既得到质量又得到了效率，但一定程度上牺牲了体验，而数字化天然可以解决这个问题。如果用户需求的获取、还原、设计、生产、交付和服务等环节有数字化的支撑，就有可能在整个环节里满足用户的个性化体验。

我们已经看到，很多企业通过数字化技术打造独特的体验，创造差异化价值。实体经济正在逐渐向信息化的世界迁移。未来，所有的实体经济都要做数字化，甚至未来所有的企业都会成为软件企业。未来任何业务想要有竞争力，都必须运行在数字化基座之上。

那么，数字化的引擎是什么？是软件。软件的燃料是什么？是数据。

因此，整个数字化转型浪潮对软件开发提出了非常高的要求。如何端到端、全链路地去看而不是只看单个阶段或者单个产品？如何建立最本质的模型，从物理世界过度到数字世界，并反过来影响物理世界？如何构建顺畅高效精准的交付模式？这些问题都变得非常重要。

作为一个大的数字经济体，阿里巴巴在业务与技术融合的发展过程中也经历了三个阶段。

• 第一阶段，向技术要效能。那时候，企业面对的是如何将技术自动化，实现技术本身的提效；

• 第二阶段，不仅向技术要效能，还要考虑技术如何更加高效地去支撑业务。于是，中台的概念被提了出来；

• 第三阶段，也就是这两年，阿里希望顶层战略可以顺利传达到业务和技术团队，特别在意业务和技术的协同，开始讨论如何通过方法和工具，将技术和业务的协同形成标准化的实践。

开发工具本身是为了帮助一线同学提升幸福感和效率。作为开发者，关心的是如何能够专注而高效地工作、高效开发和测试，但更重要的是，保证自己做的是正确的事。

现在有一个趋势：做底层研发的越来越少，软件研发的方式和习惯在发生变化。

现在，开发做的不再是一个通用工具，而是要随着业务不断演化。

为什么一定要从 DevOps 走向 BizDevOps？

如上文所述，作为加快金融服务智慧再造的重要组成部分，BizDevOps 成为重塑智能高效的服务流程的核心能力组成。但 BizDevOps 也不是另起炉灶，而是 DevOps 的自然扩展，从打破 IT 内部的墙，到打破 IT 与业务的墙。

DevOps 于 2009 年被提出，主要是为了打破 Dev 与 Ops 的墙。当时的墙还是比较明显的。Dev 关注的是快，对象是代码，Ops 关注的是稳，对象是机器。两者目标天然有矛盾，部门墙由此建立起来，这当然不利于 IT 价值的最大化。

2009 年，在美国举行的第二届 Velocity 大会上，来自 Flickr 公司的 John Allspaw 和 Pauk Hammond 发表了一个演讲《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》。在这个演讲中，Allspaw 和 Hammond 以角色扮演的方式，生动地表现了开发与运维之间的各种冲突。演讲中出现很多金句，如“It's not my code, it's your machines!”，这深刻反映了 Dev 和 Ops 关系的现状。接着，他们又展示了开发团队（Dev 和运维团队（Ops 如何通力合作，借助工具消除双方间的壁垒。

这次演讲是 DevOps 发展历程中的标志性事件。它提出了正确的问题：为了更快交付和实现价值，必须弥合开发和运维之间的鸿沟，并给出了解决方案：为了弥合开发和运维之间的鸿沟，需要在文化、工具和实践方面的系列变革。

而在今天的大环境下，我们面临着一个新的问题：如何打通业务（Biz）与开发运维（DevOps）之间的墙，以更好地应对数字经济下的挑战。

仍以阿里为例，今天阿里的中台也面临两个问题。第一个是协同问题，阿里中台本身是一个大部门，大的业务线和小的业务线从前台传递到中台有优先级，但大家都觉得自己很重要，这就是一个典型的大型企业协同问题。第二个问题就是如何不让技术、中台本身成为瓶颈。阿里希望业务可以自己去做技术，这样有价值的想法和创新可以得到最快的响应。

“你们团队是业务主导还是产品主导？”技术人都不希望被当作资源去做事，而是希望可以和业务合作以达到业务成功。其实，业务和技术应该是共生合作的关系。

在零售和金融行业，这种关系比较明显。比如银行的业务占绝大多数，大概有 90%，如果有业务研发一体化的系统，技术可以满足更多的业务诉求，那么业务就能更快地完成工作。

如何落地 BizDevOps？

DevOps 运动还没结束，仍在继续发展。DevOps 运动有很多可以给 BizDevOps 借鉴的地方。

首先，是在目标上进行统一。DevOps 为了统一目标，借鉴了精益管理、敏捷管理、看板等工作方法，打通了整个 DevOps 流程，产生了非常好的对于管理方法的驱动。其次，DevOps 在开发和运维之间找到了共同点。大家关注的是应用，以应用为中心去做开发，演变成了阿里和微软的 OAM 模型。因此，既要有理念和方法上的改变，还要用技术手段来解决问题，这是我们需要从 DevOps 运动中学习和借鉴的。

那么，业务和技术的共同目标是什么？在流程中有什么共同关注的东西？共同的目标、共同的关注点，有效的技术或者工程实践，是 BizDevOps 落地的关键。

首先，要把业务、DevOps 统一起来，统一语言非常重要。业务和技术有墙是正常的，因为业务间本身可能就有割裂。以银行为例，每个部门画图的标准不一，统一业务的语言就有难度。业务之间先统一语言，然后和 IT 用统一的语言沟通，然后统一数据和业务。从基础语法到长期熟练地使用语法，制定业务标准、数据标准，行业上下游企业定义好标准，这个过程的整合需要时间。

对于软件行业来说，DevOps 代表第一生产力，数据代表软件下的生产资料。DevOps 发展多年，相对来说已经很成熟，因此成为快速迭代、试错的实验系统。在已经有这套系统的情况下，Biz 就更应该好好利用这个系统。

现在，可以把 Biz 放在 DevOps 前面，后续也可以把 Biz 放在 DevOps 后面。这意味着业务不是拍脑袋做的，而是有数据验证的。Biz、Dev、Ops 这三个单词不应该是在一条线上，而应该是一个环，加入数据这个生产要素之后，我们可以用实验精神来创造一些商业机会。

当前能做的是，借鉴 DevOps 的经验，有一定的工具来承载最佳实践和方法，固化到流水线上帮助落地。

有的企业搭了一下就觉得自己在做 DevOps 实践了，其实我们还是要有更高的追求。从文化上解决和改变工作方式，短期内是无法做到的，更加合理的方式是去培养复合型人才。DevOps 让开发要懂测试，DevSecOps 让开发要懂安全，Biz 加进来以后，开发人员也要懂业务。事情没办法一步到位，也许在过渡期中，一个比较好的方式就是产学研联合去培养复合型的人才。

最后仍然要强调一下，BizDevOps 最大的机会点还是在需求本身，在构建数字化的生态本身。

BizDevOps 的产品应该如何打造？

特斯拉的 Elon Musk 曾说 ，“比起造汽车来说，设计这条流水线的难度是它的 100 倍。”那么，如何做才能把 BizDevOps 的流水线做出来？

阿里云云效平台负责人陈鑫提到，在服务众多云效客户的过程中发现，科技部门对于 DevOps 比较有共识，同时也欣然接受。例如大家都会理解一体化研发运维平台、走向云原生这样的一些概念和说法，DevOps 的标准和方法实践都在逐步收敛以适配开发者需求。

但是，业务部门还完全没有达成这种共识。现状是只解决技术部门的效率问题，很难改变业务的创新效率问题。如果有一个工具可以让业务看到工程活动和业务之间的关系，那么业务部门就可以作出判断和行动。很多企业有非常多的工具可以用，但没有可以实现数字化目标的工具。

打造 BizDevOps 工具有很多难点。比如目前市面上有很多 DevOps 工具，但企业还是会再造一个工具，为什么？因为各个工具的数据模型并不一致。因此要想打造一个 BizDevOps 平台，首先要保证数据一致。大家对一些最基础概念的认知要拉齐。当前不同的人对于“应用”的定义和理解都是不一样的，如何能形成通用规范？

另外，DevOps 需要不同的人协作，BizDevOps 作为一个工具或者平台，如何让多个角色有统一的视角，避免互相传递各自视角的信息导致低效，也是非常关键的。此外，工具不是为了改变而改变，工具是用来解决问题的，工具本身不能对用户的状态进行假设，必须适配用户在各种条件下的状态。而研发自身也需要做数字化转型。研发过程中也会产生数据，产品研发本身实现数字化转型，才能更好地支撑更大的数字化转型。

整体来说，BizDevOps 在概念、流程、方法上如何标准化，需要业内一起努力，共同推动在产品上的落地。

如果 BizDevOps 真得发生，未来会如何？

BizDevOps 对业务的创新速度和有效性会产生很大的作用，数据会变成基本常识，业务和开发之间的分别也会模糊起来。一定会有部分业务人员愿意往开发上靠近。开发人员抽象分析问题的优势也会给业务人员带来很多的价值。

将来的业务更多是从用户的视角去打通链路，建立本质的认知和数字化模型。一切业务数据化，一切数据业务化。业务能够以更自然的方式向研发过渡。一个人的职业发展方向也可以有比较大的选择，人才培养上也会有一些变化和创新。

如果 BizDevOps 真的发生了，可能业务之外的组织上的各个 function 会成为最大瓶颈，其他 BU 的决策过程可能都要做相应的调整。未来，企业肯定要跟着 BizDevOps 做转型。

下一步，我们怎么做？

经过深度研讨，产学研 6 位专家在时代挑战与机遇、BizDevOps 重要性与必要性、落地方法与方式上达成了共识。他们希望围绕 BizDevOps 的探讨不仅仅停留在这个层面，而是可以继续从产学研界的共同努力着手，推动 BizDevOps 真正发生，为软件产业的变革贡献力量。

因此圆桌会后，6 位老师共同起草了一份《BizDevOps 行动倡议书》并联名签署，这意味着接下来，产业、学术、研究等各方将进行长期的协作和努力，共同推动软件构建与交付方式的变革。

《BizDevOps 行动倡议书》扫描件尾页

如果这篇文章对您或者团队有启发，欢迎转发给更多人，点击链接观看《BizDevOps：数字化转型浪潮下技术破局之路》直播回放，也欢迎加入 BizDevOps 交流钉钉群，群号：44686237。