Preface 前言

人不自由时感到不满，自由时感到惶恐。

——马丁·海德格尔

DevOps在各大互联网公司已经成为技术团队开展数字化转型和研发效能提升的可行实践框架和指导方法。同时，研发效能顺势成为近些年被频繁提起的热点。如今，各大互联网公司都在招聘研发效能工程师和DevOps工程师。对于就业者来说，这何尝不是机会呢？

不过，什么是DevOps呢？一千家公司可能有一千个定义，当然也有不少于一千个实现方案，这就是DevOps落地形式上的差异性和模糊性。读者在实践DevOps前，一定要找到最小可行性方案，并且该方案中的框架和方法等要能够容易地应用到实际的产品研发场景中。

如何开展和实施DevOps？其实，我们理解的DevOps就像敏捷一样，它是一种理念，关键是如何利用这种理念帮助团队解决当前问题。至于我们实施的DevOps是不是对的，这就要看我们解决的问题是不是你们当前面临的难题或阻碍点了。

先别急着在本书中寻找“答案”，且读如下几个片段，了解笔者实践DevOps的背景和写作本书的初衷和目的。

实践背景

近几年，我曾就职于两家创业期的互联网公司，团队业务形态变化较快，并且不断追求软件交付效率。随着人员规模的不断扩大，CTO发现技术团队的管理越来越不受控，主要表现如下。

1）集中交付的研发模式导致大部分上线工作持续到深夜，团队内部因频繁加班不断抱怨。

2）PMO和技术部门频繁爆发冲突，双方在目标管理上经常产生分歧。

3）业务团队和技术团队间开始出现不对等对话。大量项目延期交付导致业务团队不断抱怨技术团队影响业务计划的正常实施。

上述问题在中小型互联网公司内部基本都会存在。技术团队如何改善这一现状？经过一个月的全方位参与，我发现如下几个重要问题。

1）各职能部门间出现沟通障碍，70%的项目在验收阶段因业务、产品和研发人员对需求理解不一致而延期。

2）技术团队的改进往往是头痛医头、脚痛医脚，陷入局部优化的困境。

3）技术团队缺乏有效的研发协作管理平台的支撑，并且平台间没有形成一定的价值关联性。技术团队尚未掌握通过平台度量驱动业务团队改进的方法，并且研发管理模式比较粗放。

针对如上这些问题，你所在团队是否也深陷其中而无法自拔，并且也有强烈的欲望去改变这一切？且继续往下看我们的效能团队当时给CTO的解决方案吧！

有一天，我主动找CTO汇报这些问题，CTO对我提出来的问题很有感触。于是，我在白板上画了一幅蓝图，主要想说明结合人、流程、工具来实践DevOps的理念，提供一套一站式研发协作交付新模式，如下图所示。

聊完后，CTO问：“需要多少人？多久能实现？需要哪些资源支持？”我粗略构思后回复：“需要10人左右，明天就可以开始。我可以先在线下将流程运行起来，半年内可见效果。”

自此，效能团队成立，技术团队开启了研发效能提升之旅。

上述实践背景的介绍，主要是想让读者了解我们推行DevOps时所处的环境。DevOps的落地实施过程千人千面，我们面临的问题可能不是你所在团队当前的痛点，但解决问题的思路可供参考。了解这些背景有利于读者融入场景去思考我们的解决方案。

后续章节中会频繁提到下页图中涉及的平台，篇幅所限不会介绍各平台的实现及其提供的功能，但读者可以通过各平台中的真实图例来了解DevOps平台的全貌。当然，我在这里假设读者具备基础的产品研发协作管理能力，因此不再大篇幅介绍简单的技术语言和基础知识，比如：编写单测用例，编写测试用例，编程实现接口自动化测试，进行需求拆分，敏捷的含义，瀑布模型的含义，等等。

为什么写这本书

在DevOps领域工作这些年，我曾帮助多家互联网公司从0到1组建DevOps团队，搭建DevOps平台，实践DevOps理念，解决了技术团队软件交付效率方面的一些难题，为业务数字化转型做出了一些微薄贡献。

其间，自己不断扩展知识边界。每年我差不多都会精读5本以上的书，而读完这些书后，更坚定了我写书的决心。我萌生了分享带领团队从0开始做DevOps所积累的经验的想法，希望能帮你解决实践DevOps过程中遇到的问题。

首先看一下我读过的书的一些共性。

1）内容上大多介绍理论或者结合实践抽象出来的理念和方法。这类书籍让没有经历过DevOps实践的读者很难理解，文字读起来比较晦涩难懂，而且没有可见的实物，没有实际产品研发过程中解决过的场景案例做支撑。对于IT领域的一线管理者、从事精益敏捷的教练、致力于数字化转型以及软件价值交付模式转变的变革者来说，他们无法将这些理论或方法快速结合日常工作场景开展和实践DevOps，更无法将DevOps快速融入长期规划。

2）形式上主要围绕软件研发生命周期中的主要活动进行模式框架和方法论的总结。因此，具体到一个实际场景问题，比如如何提升技术中心团队的代码质量，相信绝大多数读者很难结合这些方法论“拼凑”出解决方案。此外，书中有很多难以理解的内容，往往会导致读者在读懂的路上半途而废。

3）趣味性上缺乏故事剧情。很多书没有真实的故事主线和上下文剧情，比如读者不知道为什么需要做元数据管理，缺乏让读者身临其境的场景。

当然，这类书对我们的实践还是有很强的指导意义的。但是，刚涉猎DevOps领域或者没有实战经验的读者，更需要一本能够结合日常工作场景快速融入实践的书。这也是我写作本书的动力之一。

如何阅读本书

本书将参考畅销书《走出硝烟的精益敏捷》的结构，以实际工作场景为主线，通过丰富有趣的故事情节带领读者理解和掌握切实可行的实践方法。书中根据日常产研过程中的真实场景，结合经验证有效的工程实践方法与全链路协作管理平台，重点阐述DevOps的运作落地模式，进而提炼出DevOps转型的最小可行性方案。希望本书能给读者带来沉浸式的阅读体验。

本书分为3篇，共8章。

第一篇为工程能力实践，包括第1章和第2章，重点分析了技术团队需要具备哪些基础的工程实践能力以及如何驱动团队改进。若你所在团队正在为基础技术工程实践能力的提升而努力，可以阅读第一篇。

第二篇为平台体系搭建实践，包括第3～5章，重点阐述了如何利用DevOps全链路平台间的联动性，通过度量、监控、预警等消息触达手段反馈团队的问题，通过事件管理驱动团队问题的解决。若你所在团队正在为技术团队问题的发现、反馈和及时解决而发愁，可以阅读第二篇。

若你所在团队正在计划根据自身的业务形态快速搭建DevOps全链路平台，进而提升团队的自运维能力、在线协作能力、可视化管理能力、自动化能力以及工程实践能力，可以阅读第一篇和第二篇。

第三篇为管理模式实践，包括第6～8章，重点阐述了如何通过不断提升团队影响力，结合不同的管理模式和平台管理功能，让具有共同目标的部门联合开展有效的项目管理，并在最后为读者勾勒出一幅DevOps转型和研发效能提升的全景图。若你所在团队正处于转型阶段，无论从研发转向管理，或者从传统管理转向敏捷管理，还是从瀑布式研发模式转向更敏捷的研发模式，或者希望改善技术团队与业务团队间的关系，都可以阅读第三篇。

若你是技术管理者，想让团队提高软件交付效率或研发效能，想结合工程实践方法、平台、DevOps文化理念等，全方位地促进团队DevOps转型和敏捷转型，你最好通读全书。

读者对象

❑ 想通过DevOps转型提高技术团队交付效率，进而改进团队研发模式、管理方法和协作方式的管理者，一般是一线管理者或者技术骨干，当然也可以是处于高速发展期的技术高管。一线互联网公司大多数推崇团队自治，通过小组自管理提升使用工具的能力，减少纯职能团队，培养全栈工程师，因此掌握书中的方法和实践，可以在技术管理、团队管理上更上一层。

❑ 想了解DevOps运作模式的研发效能经理、项目经理和敏捷教练。敏捷意味着业务团队管理的快、准、狠，也意味着价值交付的效率，消除团队间的职能壁垒，一手抓业务价值，一手抓价值快速验证。在这个过程中，工程实践能力和全链路平台建设能力将是此类工作者重点关注的内容。

❑ 一线产品、开发、测试和运维人员。不要只埋头使用工具，应站在更高点思考如何利用工具和理念拓宽自己的知识边界。只有知道为什么，才能知道如何做，进而思考如何更进一步。

❑ 布道者。DevOps不像敏捷开发那样，结合一定的管理框架和理念，通过“看板”就能线下组织运作起来，它需要结合工程实践方法、平台、文化理念等多维度去推广和宣传。

声明

本书讲述的内容是我所在效能团队在两年内实施DevOps时不断修正、调整的成果，只代表着一种实现方式，不是唯一的实现方式。本书旨在抛砖引玉。

本书中所讲的一切观点仅为笔者个人观点，不代表我过往公司以及现在公司的任何意见。在谈到公司组织结构的时候，本书将以公司集团、企业组织、技术中心、业务团队、技术团队、技术部门、团队、小组、一线产研人员等名称进行阐述。其中，技术中心包含技术团队下各技术部门、技术支撑部门、项目管理部门等。在谈到公司DevOps相关平台名称的时候，本书将以大众化的名称去命名和说明。

书中涉及相关领域专家的书籍内容、课程分享内容、名人名言的引用均有特殊说明和备注。若出现“共同理念”而让你误以为未特殊标注之处，你可以主动与我进行讨论，说不定就是“英雄所见略同”之处。

资源与勘误

本书将通过链接提供大量日常产研协作过程中遇到的场景案例和实践方法供读者参考。这些共性问题的解决和实践方法，可让读者更容易理解各章提出的观点和DevOps落地实践思路。

链接：https://pan.baidu.com/s/1b5SYkzL20qE7onWf9kY-9g?pwd=l0k0。提取码：l0k0。

读者若有疑问或者想进一步沟通，可以添加我的微信jxcxiada或通过邮箱jxcxiada@126.com进行交流、学习。

致谢

至厦十年有余，其间游闯于南京和杭州。从一线研发到致力于软件价值交付领域的实践与研究，一路走来需要感谢的人太多，因为在每个职位上都有并肩作战、齐力共进的伙伴。

首先，感谢我的家人。他们的额外付出让我拥有大量可独立享用的时间和空间，能够心无旁骛地去思考、实践、体验，同时升级自己的思维和认知。在杭州工作的前半年，太太在异地撑起一个家，我深知她的不易与坚强，对她的感激无以言表。我能够安稳地在外工作，特别要感谢一直在老家照顾爸爸和奶奶的妹妹，她将是我一世的牵挂。

其次，感谢一路走来给我指导和促使我改变的老师们。从开始改变我对知识更高层次认识的韩越和孙伟老师，到引领我对精益、敏捷、管理理论更深层次实践的姚冬、乔梁和刘建国老师，再到进一步拓宽我对研发效能领域更广范围实践的何勉、石雪峰、张磊和赵成老师，他们的分享让我更容易地将这些可信的原则映射到IT价值流中。特别感谢本书出版过程中提供支持的编辑董惠芝和杨福川，是他们的努力让这本书描述得更准确、更有说服力。

最后，感谢DevOps实践联盟的战友们。感谢我的老领导李青原、张钧和黄强元，有了他们的指导和认可，我才更有信心带领团队去实践DevOps。特别要感谢一群能够互相理解、主动分享、自主创新、热衷于研发效能提升、致力于DevOps文化传播的战友们，是他们的一次次“打怪升级”成就了效能团队。

没有最后，只有数不尽、畅谈不止的努力瞬间。让“曼巴”精神继续充斥着我们的灵魂吧！