专访华为 20 年架构老兵何代义：DevOps 并非对所有公司都适用

DevOps一词来自于 Development 和 Operations 的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。DevOps 概念最早兴起于 2009 年的欧洲，是为解决传统软件开发模式中运维工程师的痛点而生，但它其实包含了三个部分：开发、测试、运维。DevOps 并不是一个单纯的技术概念，虽然诞生至今已有十年，但现阶段国内关于DevOps如何落地的讨论依然很多。DevOps 对于企业来说到底意味着什么？企业的软件系统向 DevOps 转变的过程中需要考虑哪些因素？当前 DevOps 落地实践还面临哪些困难？

InfoQ 记者有幸在 ArchSummit 全球架构师峰会（深圳站）2019
现场采访到了华为云 DevCloud 高级架构师，听他分享软件架构和开发模式的演进历程、企业和团队如何判断自身是否应该实践 DevOps，并总结了华为在实践 DevOps过程中沉淀下来的宝贵经验。
以下是视频采访的全部内容，为方便读者查看，视频下方也附上了文字内容。

InfoQ：您好，非常感谢您参加 ArchSummit 全球架构师峰会 2019（深圳站）的视频采访，首先请您做一下简单的自我介绍，包括您的工作经历。

何代义：大家好，我叫何代义，我是 97 年大学毕业，毕业后一直在华为工作，做架构相关的工作应该有 10 几年了。我们公司有 SE 岗位，也有架构师岗位，后面两个有些混为一体了，但是内容还是有些差别。我是 03 年左右开始做 SE，也做过很多架构，同时做过一段时间的架构方法等。因为华为内部的软件架构还有系统级的方案种类非常多，并不是只有一种架构，所以在这个过程中经历了很多种不同需求，包括如何设计好架构以适应业务需要，一直是在做这个方面的工作，将近有快 20 年了。

InfoQ：您在华为从事软件及架构工作 20 多年，在软件架构领域想必亲身经历了很多次架构模式、软件开发模式的变革，能否请您梳理一下这 20 多年来，软件架构领域比较重要的几次变革？

何代义：我们九几年刚从学校毕业的时候，软件架构刚刚从 C/S 模式往浏览器服务端 B/S 模式演变，那时候 Java 才刚出来，CGI 正好大行其道。当时应用开发以客户端服务器模式为主，在速度、客户端的耦合性等方面都做得不好。刚开始转向浏览器服务器模式时，主要讲的是如何实现一个系统的软件栈，比如分层，如何把服务器列表拆成不同的层次，再后来出现 EJB（企业级 JavaBean），再往后 J2EE。这个时候包括 CGI 到 Servlet 到 JSP 一系列的发展，以及后面才出来的 Spring Boot 等，其实它们都是从一个脉络发展过来的。这个脉络讲的是如何做好一个软件，这是软件实现的架构。
第二个架构，指的是软件如何组成的架构，这和前面是两个不同的东西。一开始是单体架构，我们公司最擅长做这种东西，因为我们的盒子类软件，它要求极致的性能，资源又是有限的，无论是处理器的能力，还是内存的容量都是有限的，如何有效利用空间，又要将性能做到极致，那时候就是单体架构，通过指针、内存共享这些方式。从产出有效代码生产率的角度来看，其实并不高，如果是一个很大的项目，存在几百万上千万行代码的时候，出一个版本一般开火车要开一年左右。后来就是从单体软件到服务化到 SOA 化，再到后面拆成可 DevOps 服务化这样的一路严谨。这一套方式就是讲如何通过 API 协同的方式拆分，核心目的是减少团队之间的沟通成本。因为过去要走正步的时候，你可以直接使用别人的数据，但是别人数据一动，大家都要动，需要做非常多的协调工作。而 SOA 化也好，后面的服务化也好，微服务也好，其实就是要拆，拆成单元，围绕自己的数据把逻辑做完整，接口开放好，其他人只是面向接口使用。这样一来减少了很多会议，也提高了运作的效率，而且交付的速度也快了。因为拆的小，后面容易快速验证。然后交付模式也从过去的瀑布模式到敏捷，到持续集成持续交付，再到 DevOps，而这里面都是需要软件的架构做适应性的变化和支撑的。
这些过程其实我在华为都经历过。我们一开始是做单体软件，追求极致的性能，把成本做到最低。性能好、成本低，这是过去盒子类软件的必杀利器，功能可能同质化速度比较快，因此要想办法在相同成本下把性能做到更优。后来开始面向 IT 类软件，内部要做很大的系统，就必须分而治之，先拆，拆了再协同起来，再做服务化、微服务化这一系列东西。

InfoQ：您刚刚提到 DevOps 是现在比较流行的软件开发模式，它是因为什么需求而诞生的？

何代义：我一直强调，这些软件变化的本质都是为了提升效率。过去单体软件开一个版本火车，要开至少九个月，甚至十二个月。因为那个时候还是瀑布模式，需要层层验证，协作团队多而且相互有依赖，每个团队都有自己的版本节奏，最后出来东西就会比较慢。后来我们对单体架构做了优化，通过组件来协同、拆分、集成，这是我们为了适应云化场景做出的改变。DevOps 除了能够快速反馈，还因为我们在面向云化场景交付的时候，DevOps 很关键的一点是责任团队都是自己，从需求到开发到交互到运维，都是靠一个团队来解决问题。过去我们可能敝帚自珍，下游组织诟病上游组织输出的东西，因而带来很多争论。但是引入 DevOps 之后我们只考核结果，比如是不是有客户投诉，业务量是不是上去了，是不是出现业务的中断，而在 DevOps 组织中，这些结果是由整个团队共同负责的。
DevOps 改变了过去整个交付模式的运作，但是它还是不适合我们设备类的业务线。因为设备类业务还是会有下游厂商，必须要有合同，必须要有客户组织，我们不能总是去动客户的东西。原先我们有一些合同里会写明，一年只允许升级一次或者一个季度只允许改动一次，改动代码的时候都有很严谨的一套流程，如果中间不小心出了故障，都是要罚款的。就算我们现在说用 DevOps 不怕出问题，只要快速解决问题就行，对客户来说那也是不可以的，原来的要求都还在。
所以 DevOps 在我们公司内部也只是一部分组织在实践，比如华为云、手机的云端服务，还有内部组织能力相关服务采用的是 DevOps。华为的软开云会给外部客户提供软件开发的云服务，同时我们内部研发的作业也是在这个云上运行，它采用的就是 DevOps 的开发方式，能够快速获得反馈，快速形成特性，快速解决问题。

InfoQ：您刚刚提到，华为内部也不是所有的场景业务都适合实践 DevOps，那么什么样的公司或团队适合采用 DevOps？可以从哪些维度来判断？

何代义：首先，一个单体软件是做不了 DevOps 的，因为敏捷不起来。DevOps 的前提是要做到敏捷，就是到了后面运维段、运营段，需要能够基于结果或数据反馈快速反应，再反过来优化前面的工作，而做单体软件的企业是做不到这一点的。比如一些领军级的 ERP 软件公司和 CRM 公司，其实它们现在都还做不了 DevOps。因为他们过去有很重的历史包袱，软件架构还没有拆开，但要做到 DevOps，就需要解耦，从而做到可持续交付。像某 CRM 公司已经是 SaaS 化服务领域比较领先的企业，但它现在的版本节奏还是很长，很难实现真正的 DevOps。
不一定是因为商业模式，而是必须要有技术架构支撑，包括组织能力也要准备到一定程度之后才能做 DevOps。但是，一些初创企业，比如想做一些互联网业务的探索，它的初衷是要验证自己的商业思想的正确性，这种验证就要敏捷，而且是商业敏捷。

为什么我总说， DevOps 不是业界提的只包括运维，而是还要包括运营
。我在公司内部强推的是，将来就是看所支撑的客户，在规划组件特性的时候，不同组件到底存在的价值有多大，是砍掉还是收缩还是扩张，主要是基于经营数据，不只是看运行情况是否健康。一些小的初创公司通过云为用户提供服务，这种模式就比较适合一开始就用 DevOps。当然，如果有追求的企业，尤其是以软件的形式提供服务的企业，也要把自己过去的单体架构拆成可以 DevOps 的架构，然后再做转型。 企业转型到可以 DevOps 是一个漫长的过程
。因为过去厚重的历史包袱拆起来有一定难度，像很多领军级的 B2B 软件公司目前都还在转向 DevOps 的渐进发展过程中，做了好多年都还没做到位。

InfoQ：传统的软件开发模式向 DevOps 转变的过程中，可能会面临哪些困难和挑战？有没有什么好的应对方法？

何代义：首先是思想上的转变，然后架构方面需要将原来比较重的服务全部拆开，包括开发、交付、运维、运营，这是一项很大的工作。为了适应拆开的架构，组织可能也需要做调整。华为内部有这么一个说法：架构决定组织。在我的逻辑里面，架构清晰就不存在太多的重叠和交叉，“治众如治寡，分数是也”，先把它拆成很小的块之后分别完成各自的职责，再协同起来实现一个大的任务，拆分过后就需要组织调整。这是第一个变化。第二，流程要做调整。第三，需要有工具和环境来支撑。
架构其实有一点很关键，就是要抽象，要平台化，要聚类，让业务专注业务。我们过去有中间件，到了云上其实就是 Paas 服务或 IaaS 服务，总之需要有公共的服务，术业有专攻。组织也要做相应的变化，要水平化、垂直化，按照架构拆分和协同好。除了要有工具环境的支持，流程也要支撑，公司的考评体系也要改变。

InfoQ：华为云实践 DevOps 经历了哪几个阶段？

何代义：一开始也是松土，然后需要建立适应 DevOps 的组织模式。为了适应不同的业务模式，华为内部有很多种不同的组织。最早十年前的时候，公司内部组织可能都是一样的，做终端软件也好、做盒子类软件也好、IT 类软件也好，都是一样的。华为公司是 IPT 流程，IPT 流程适合做盒子类软件，它会涉及很多组织协同一起做一个很大的项目，但是到了云上服务，肯定会变得不一样，终端软件也不一样。不同的时候，企业有不同的问题，组织要适应问题来做改变。我刚到公司的时候参加培训，当时会说弱矩阵、强矩阵，这是当时的一种阵形，后来到了敏捷，会有阵形的改变，主要是有不同的角色结合到一起。到了 DevOps 之后，我们的组织要有更多的改变。现在公司内部对编码、架构、软件工程各工段的能力要求都有一些新的追求。我们过去是把盒子的质量和性能做到最优，那我就是最优的。现在我们还说，我们是优雅的最优，就是说我们的软件代码是非常精炼和优雅的，甚至可以给人家欣赏。这对组织内部端到端的过程就提出了更多要求，我们又新增了很多角色或者组织来把这个工作做好，这些都是适应需要而做的调整。

InfoQ：华为 DevOps 团队中内部包括哪些角色？不同角色之间是怎么分工的？

何代义：以我们这边的团队为例，简单地说就是 CTO Office 下面加上具体的业务单元。CTO Office 的职责是建设公共能力，比如说运维工作涉及的监控、拨测、部署等需要的能力，还有中间件等。CTO Office 需要帮他们做一些公共的事情，包括抽象软件框架再提供给大家用。大家只需要做自己业务属性范畴内的工作。CTO Office 相当于是一个公共组织，为大家服务，反过来也会驱动大家往前走。然后就是各个业务团队。在我们公司内部有“全功能团队”这样一个说法，指的是在一个组织里面，从设计到开发到验证再到运维，都要由自己的团队来负责。CTO Office 团队的运维只是从整体角度出发，具体业务本身的运维还是由各个业务团队自己的运维来做。工程师交付出来的 DevOps 单元，要由自己来负责。DevOps 单元是全功能的，其中包含多种角色，有 SA、针对过程的 QA、针对结果的测试等一系列能力，这些都是由各个业务团队自己负责的。我们公司内部很强调赛马，大家会在方方面面做比拼。一个团队在组织中存在的价值，靠的就是做出来的业务结果。

InfoQ：DevOps 组织或团队中不同的角色，比如架构师、QA、运营、运维这些角色，不同的角色之间协作应该是什么样的？

何代义：首先每个角色要有自己应该承担的职责。但是在华为内部有一种文化，就是圆圈。如果都是以圆为边界的话，那相邻的圆中间肯定有缝。这时候圆就要画大一些，你要侵入到别的领域去，你也可以接触别人的东西。大家在公司、团队内部是要闻过则喜的，不能像刺猬一样，那在组织中间生存不下去了。像我现在的角色是架构师，我就会去到端到端的任何地方，看到问题就会伸手过去，努力帮大家一起想办法。比如如何拆服务、如何设计模型、如何做运维的监控、如何快速发现问题，这其中某个技术或方法如果我有相应的经验，或者是见到过优秀的实践，都会跟大家分享。只要是为了结果好，大家的胸怀还是比较宽广的，至少在一个组织里面是这样。当然方式方法还是需要注意。

InfoQ：所以在华为内部的 DevOps 组织中，架构师会主动推着这个模式往下走？

何代义：我们内部对架构师的要求很高，当一个项目失败的时候，架构师一般是要担责任的，整个组织的失败，架构师也要担责。无论这个架构师过去有多高的成就都没有用，我们要对结果负责，结果没做好就要担责，包括带业务团队的 CTO、业务领导也要担责。

InfoQ：您认为有所谓的“DevOps 工程师”这样一个职位吗？它是一个被滥用的词语吗？

何代义：我认为是。DevOps 是一种思想，就是商业角度要敏捷，所以它其实是贯穿始终的。从开发的角度，要想到后面的运维，在开发中间，就要想到哪些指标是要拿来做监控的，要为后面的工作做优化。不能像过去那样只关注架构，在开发的时候，既要考虑编译部署，可能也要关注测试和部署，而不是什么都交给 SRE 团队，现在整个端到端的流程都要做。这也有好处。过去因为我们的架构师团队很强悍，即使是上千人协同的非常大的系统都能很好地分解和协同，这其中架构设计的工作量非常大。但是架构师以外的工程师，可能就只懂自己负责的一小块工作。转向 DevOps 之后，工程师就变成全功能了，技能也会提升很多，包括端到端思考的能力等。这对于员工是一个机会，也是好事情，各有优劣。

InfoQ：所以如果企业或组织实践 DevOps 思想，就意味着内部不管是什么岗位的工程师都应该尝试涉及更多的工作内容？

何代义：这样一来个人成长会更快。如果工程师只聚焦于自己的编码能力的话，眼界就可能很窄，写出来的代码不一定会好。知识只聚焦于一点的时候，你做东西就不会想到，这可能会影响到别的点。同理，其实在职场里面，本来就是要不断学习新的能力。

InfoQ：那么华为并没有所谓 DevOps 这个岗位？

何代义：没有这个岗位。

InfoQ：有观点认为“DevOps 将成为主流，它的流行程度将在 2019 年达到顶峰”，您是否赞同这个观点？为什么？

何代义：这要从不同视角看。在华为内部，盒子类的东西永远不可能用 DevOps，包括我们的终端类软件，因为这些软件至少包含上亿行代码，一旦出现问题影响面非常大。我的观点是，如果是 Software Provider，也就是软件提供商，就可以做持续集成，持续交付可能也可以做，但是 DevOps 是不行的；但如果是 Software as a Service，就可以做 DevOps，还是要看自己的商业模式。
我们公司内部做过一个实践，通过签合同的模式来做商业敏捷，这需要跟客户达成一致，如果新特性增加就要新增一个签单，才能够回款，包括客户的数据如何跟我们这边的数据打通、快速返回进行联合开发和联合创新。我们跟部分客户做了这样的实践，也有价值，但这种客户就属于战略性客户，他们愿意做这样的尝试并提供相应的预算，不是所有的客户都愿意这么做，这是 On premise 模式。
而 On demand 模式是适合 DevOps 的，如果是 On demand 模式，软件依然采用传统的开发模式，而不是 DevOps 模式，那么交付速度就会很慢。现在一些顶级 CRM 和数据库公司都在转向 DevOps，他们的产品是以服务的形式提供给客户，所以可以采用 DevOps 进行快速迭代。但是如果是卖给客户的服务就不一样了，你必须要对质量负责，而且客户买单到底该怎么掏钱，他掏的是这部分特性的钱，还是掏的使用时间的钱是不一样的。如果客户买的是原先的特性，而没有为新特性掏钱，那公司自然不可能白白提供新的特性。但是像办公软件套件转成云服务之后，采用 DevOps 就是合理的，因为快速迭代新特性才能吸引更多用户持续使用，才能挣到钱。像一些顶级手机公司，大家都认为是创新能力很强的企业，但它的软件开发过程其实并没有采用 DevOps。说到底还是得看公司的业务模式。

采访嘉宾介绍：

何代义，华为云 DevCloud 高级架构师，在华为从事软件及架构工作 20 多年。在系统设计、架构设计方法等领域有系统的理解和实践经验。从初始起步构建支持云化（含服务化 / 微服务化）、构建 DevOps 的软件系统；以及将旧有软件系统迁移到支持云化（含服务化 / 微服务化）、构建 DevOps 的软件系统等方面，积累了较为丰富的经验和知识。