大象的身， HP LaserJet 打印机固件研发团队的 DevOps 转型记

导读

时至今日，属于纯互联网行业的时代已经步入尾声，伴随移动互联网诞生的增长红利和国内人口红利也已基本结束。曾经各行各业都沉浸在因市场快速增长带来的移动互联网用户的激增中，那时企业即使发展方式粗糙一些、成本高一些都可以忽略不计。但现在情况正在改变，大众创业、万众创新的风口已经过去，同时在中美贸易战和国家去杠杆的大趋势下，传统行业更是处于内忧外患中，这时企业的研发管理效率和成本问题开始逐步凸现，必须修炼内功进入精耕细作的时代。

CODING CEO 张海龙认为在这样的背景下，所有的企业都需要转型。现在已经有如 DevOps 这样高效的研发管理方式，以及更好的版本控制流程；同时很多新兴互联网公司在这方面的转型动作很快，如果企业还墨守成规，使用之前瀑布流的管理方式，未来差距会变得越来越大。

作为一种已经被接纳和理解的一组文化价值和实践的集合，DevOps 已经被证明能够帮助各种规模的企业改善研发管理流程，加快版本的迭代和发布以及保障研发质量和安全，同时能为产品的开发提供快速、有效的反馈。从 Puppet 过去六年收到的总计 27000 份 DevOps 调查反馈中，有足够的证据证明 DevOps 实践推动了研发管理的升级，带来了更高的效能，从而改善了生产性、利润和市场份额(1)。

今天带来的案例是 Gary Gruver, HP LaserJet 打印机固件研发总监在他的 A Practical Approach To Large-Scale Agile Development 一书中讲述的整个固件研发团队的 DevOps 转型过程。分享这个案例不仅仅是因为整个研发团队在成功转型之后获得了 2~3 倍的效率提升，同时还因为该研发团队的定位是为 HP LaserJet 全产品线提供固件研发，而不是常见的 App 或者网站的研发团队。

这个案例向我们展示了 DevOps 不是专属于像 Google、Amazon、Netflix 等互联网巨头的工具，它可以为所有需要研发、测试、运维紧密相连的企业提高效率，更好地实现企业目标。再者像 HP LaserJet 打印机的固件研发团队这样的大象都可以转身，相信你也可以为自己的企业进行转型。

Enjoy ！

发现问题 (固件研发变成了业务的瓶颈）

Gary 的研发团队主要负责编写在 HP LaserJet 全系列产品(打印机、复印机、扫描仪等等）上运行的固件代码。在当时，消费级打印机市场已经完全是红海市场，巨头林立，几乎每月都有新功能或者新产品上市。

尽管 Gary 的固件研发团队在全球已经有超过 600 名工程师的规模，维护着超过 10,000,000 行代码，但是整个团队在尝试实现这些新功能时还是面临着巨大的挑战。

凭借当时的条件，整个固件研发团队每年只能完成 2 次版本迭代，大量的时间都用在将开发出来的代码移植到新的打印机产品上。Gary 估计最多只有 5% 的研发时间是用在开发或者维护新的具有创意性的功能上。

这就导致 Gary 的固件研发团队成为了整个 LaserJet 事业部的瓶颈，按照他们当时的研发管理模式，几乎不可能为 LaserJet 的固件添加新功能去适应市场竞争。

"市场部的同事每隔一段时间就会带着很多有创意的想法来找我们，并跟我们强调对于客户来说这些功能有多重要。但是我们只能告诉他们，在你们的列表里挑两个功能吧，大概 6~12 个月后就能实现了。"

久而久之，市场部基本放弃向固件团队提新的功能需求，这对于处于竞争日益白热化的打印机市场的 HP 来说无疑是严重的打击。更有甚者，当年的研发成本增长了将近 2.5 倍，而 80%~90% 的资源其实是投入在新产品的固件移植和修缮中。

交付周期变成了大问题

Gary 在书中提到了一些关于交付周期的数据，这些情况在我们熟悉的软件研发项目中应该也很常见：

• 只有 5% 的研发时间花在新功能的研发上
• 15 ~ 20% 的研发时间主要花在将代码合并到主干
• 当时共有八个组，每个组都配有组长负责每天提交代码
  • 当一个组长提交代码之后需要 1 周的时间才能确定是否成功合并到主干中
  • 之后需要等一天才能到 "集成阶段"，之后还需要再花一天时间去跑兼容性测试
  • 最后需要进行 6 周的手动集成测试

也就是说，每个工程师都需要等待 8 周以上的时间才能知道代码运行结果！

落后的反馈机制

"如果我们的反馈机制能够更高效及时一些，研发效率就能提高很多。当时的研发流程经常被 8 周之前提交的代码问题困住，而且要花很久的时间去定位问题究竟出在哪儿。"

在这样的反馈机制下，也不利于工程师自我学习和总结如何预防未来相同的问题不再发生。唯一会发生的情况就是工程师会因为一个 8 周前犯的错误而受到管理层的指责，再花大量的时间去定位问题和修复 Bug。

这是一个很重要的问题，如果工程师们不能获得及时高效的反馈，就会导致他们需要花大量时间去修改很久以前提交的代码，这将非常影响研发效率。

引入持续集成和架构变革

架构变革

在之前的研发管理模式中，每一款不同的 LaserJet 产品都需要创立一个独立的代码分支，用 C 语言中的 #ifdef's 预编译指令来开启或者禁用不同产品类型上的特定功能（如纸张大小等）。

这种模式会引发很多问题，比如随着产品线的不断增加，越来越多的独立代码分支需要被实时维护，同时每次维护又会产生相对独立的固件版本，这些固件版本又双需要独立的测试，大量的资源会浪费在这些重复劳动中。

所以第一个目标就是用 Trunk 搭建了一个能让所有工程师在统一的代码仓库中进行工作的平台，通过 Trunk 的架构来消除各个独立代码分支，将打印机功能判断从之前通过编译时的 C 语言中#ifdef's 预编译指令改成在运行时用 XML 配置文件进行判断。

现在，HP LaserJet 的 Trunk 架构已经支持超过 24 款打印机产品。

"建立 Trunk，对代码进行统一，不再对各个产品的代码分散管理，这将为企业带来极大的效率提升。" --- Gary 评价架构变革的效果，"下一步，我们需要自动化测试，如果没有自动测试的环节，那持续集成只会快速产生大量无效结果。"

自动测试

为了开发自动测试，整个研发团队搭建了一系列自动化组件，包括代码审查和代码集成测试，这些自动化流程会在后台不间断地对主干代码进行测试。

打印机的固件测试是一件很具有挑战性的工作，最可靠的测试方法肯定是在实体打印机上进行实际的打印操作，但问题是整个固件研发团队在新的架构下每天需要超过 150000 小时的测试量。

"整个地球上没有足够多的树来支持我们进行这样量级的实机测试。"

因为测试环境越接近实机测试环境，测试成本就会相应提高，所以当时研发的主要目标是希望通过尽可能多的线上测试，以模拟器的形式来降低成本。为了保证测试同事尽快获得结果反馈，Gary 的团队花了整整 6 周时间搭建测试环境的基础架构以支持测试：4 组服务器，在印度还有 2 组服务器，每组服务器包括 500 台服务器，每台服务器上运行着 4 个虚拟机。总共 240000 个虚拟打印机不间断地运行新的固件并反馈运行结果。

通过自动化测试环境的搭建，整个固件研发团队实现了高效反馈机制，现在工程师提交代码后可以很快地获得提交结果，整个回归测试的时间只需要 24 小时。

代码审核

在成功引入持续集成和自动化测试后，另外一个问题浮现了出来整个研发团队需要适应新的习惯。当不时有工程师提交的代码导致整个 Trunk 或者测试环境崩溃，大家必须全部停下手上的工作，开始查看哪里有问题，修复 Bug。甚至有一次崩溃时间整整持续了 5 天，导致所有成员都无法提交新的代码，为整个团队造成巨大了的困扰。后来发现原来是在给测试环境升级的时候不小心提高了某项测试的门槛，导致所有的测试结果都得到负反馈。

Gary 的对策是引入代码审核环节，保证只有正确、高质量的代码能够通过审核并合并到主干中，确保受到代码质量影响的人数降到最低，并最大幅地提升研发效率。

DevOps 转型结果

Gary 的团队转型成果如下：

• 每天 75000 ~ 100000 行代码修改
• 每天 100 - 150 次代码提交

"在过去的研发管理模式下，我们不可能每天修改 100000 行代码，带有持续集成和持续交付的 DevOps 敏捷开发模式让研发管理变得更加灵活。"

更重要的是，Gary 的固件研发团队取得了下面这项进步:

• 在新功能的研发时间上从之前的 5% 提高到了 40%! (8 倍的增长）

在现在这个时代，软件对每个公司都变得越发地重要；通过 DevOps 实践，更好地协调工具，自动化以及持续学习也变得越来越重要。即使像 HP LaserJet 事业部中的固件研发团队这样大型的、分散式的、相对保守的团队都可进行 DevOps 的转型，有理由认为所有的组织，不管他们的使命是什么，通过实践 DevOps 都能更高效的完成目标。

Reference

1. Puppet Labs 2017 State of DevOps Report
2. A Practical Approach To Large-Scale Agile Development
3. http://www.slideshare.net/gbgruver/spark-2013-presentation-of-making-the-enterprise-agile