《凤凰项目》| 王木头解读
关于作者
吉恩·金（Gene Kim），信息技术流程研究所联合创始人、研究总监，Tripwire公司创始人，担任公司CTO长达13年之久，一直热衷于研究如何提高IT组织的效能。
凯文·贝尔（Kevin Behr），PraxisFlow咨询公司首席科学官，信息技术流程研究所联合创始人，拥有25年以上的IT管理经验，常为CEO、CIO、CTO等提供指导和建议。
乔治·斯帕福德（George Spafford），高德纳公司高级研究总监，行业分析师，在IT运维方面拥有丰富经验，曾在多个国家提供过信息技术治理和流程改进等方面的咨询和培训。
关于本书
本书讲述了一位IT经理临危受命，在未来董事的帮助和自己“三步工作法”理念的支撑下，最终挽救了一家具有悠久历史的汽车配件制造商的故事。小说揭示了管理现代IT组织与管理传统工厂的共通之处，让读者不仅能对如何管理IT组织心领神会，更重要的是将以完全不同于以往的视角来看待自己的工作环境。
核心内容
DevOps，其实就是用系统的思维，去解决不同部门之间的系统问题。用系统的思维去解决公司和团队的问题。DevOps更进了一步，不只是告诉了我们应该做什么，还告诉了我们应该怎么做。
你好，欢迎每天听本书，我是王木头。今天为你解读的这本书是《凤凰项目》。
这本书是一部小说，不过，它却是一部非常特别的小说。为什么说它特别呢？那是因为这部小说并不是要给读者们讲一个特别的故事，而是在介绍一个技术团队的管理思想。
这本书的作者也不是专业的小说作家，而是在IT行业有着丰富经验的行业大牛。作者一共有3位。基恩·金，担任CTO 13年。凯文·贝尔，拥有25年以上的IT管理经验。乔治·斯帕福德，高德纳公司高级研究总监。他们在IT管理行业里工作了这么多年，发现了几乎所有技术团队，都会面临同一个管理上的困境，那就是，项目里的每个成员，明明都很努力，都在各司其职。但是，整个项目呢，偏偏就是做不成。
这本小说，就是他们根据自己的真实经历，把这个困境用小说的方式呈现了出来。当然，更重要的是他们还给出了这个困境的解决方案。
这个解决方案的名字叫DevOps，D-E-V-O-P-S，其中D和O大写。DevOps名字里的Dev表示的是开发者Developers，Ops表示的是IT运维Operations。两个单词的组合，其实就代表了开发部门和IT运维部门。这套解决方案的核心，就是让开发和运维，两拨人顺畅协作。别看这个名字对很多人来说挺陌生的，在程序员领域，几乎是所有互联网团队都在使用这个管理方案。
很多人都觉得，开发和IT运维，不都是程序员吗？为什么要分成两个部门？他们之间的协作，又为什么会出问题呢？他们的确都是程序员，不过，开发者是把软件做出来，IT运维是要把软件成功地部署到服务器上，这是两种不同的技能。
开发和运维两种技能虽然不同，但是又相互依赖，如果开发部门做得不好，运维团队就很难把开发出来的系统部署上线，如果是运维团队做得不好，开发团队做得再好，系统无法上线，无法完成临门一脚，最后也是白搭。
你想啊，现在互联网公司，比的不就是一个快吗？大家都知道，先把精益求精放一放，先把用户的需求实现，先做出一个可迭代的最小化产品再说。这个原则，在程序员界有个专门的说法，叫敏捷开发。但是，一旦开发和运维，任何一个环节慢下来，或者在协作中出现纰漏，根本不可能敏捷得起来。从这个角度看，DevOps对程序员团队来说，就像大楼的地基。
当然了，DevOps最后能成为现在互联网公司里技术团队的主流，可不是只靠了这一本小说。2013年在完成了这本小说之后，本书的第一作者，基恩·金就结合另外3位行业大牛写了一本《DevOps实践手册》把自己的方法论总结了出来。我解读的是2018年出版的修订版，在小说后面就有一部分《DevOps实践手册》的内容，它能帮助读者更好地掌握DevOps的核心思想。
接下来，我将会通过三部分来帮你了解DevOps的思想。在第一部分，我们会先来看一下，小说的主角是如何找到问题关键的。
小说里描述了这样一个困境。主角是公司IT部门的总负责人，他们的公司正在受到竞争对手的打压。他们投入了非常多的时间和资源去开发一个项目，希望通过这个项目抢回市场。如果这个项目失败了，那么公司的股东们就会考虑把公司拆分出售。这个项目的名字就叫作凤凰项目。
但是，当主角接手了IT部门之后才发现，这个项目就是一个巨大的坑。看起来目标单一，只需要加班加点，干就完了。但是在具体做的时候，却发现根本不是这样。
项目的开发部门，只顾着自己的KPI，为了能让项目早日上线，只想着把功能实现，完全不管部署上线的事情。结果真到了部署的时候总出问题，需要开发部门返工。这个时候就会互相扯皮，你觉得是开发部门不负责，开发部门却说你不靠谱。
项目上线已经火急火燎了，但是审计安全部门还必须让主角遵守安全规范，否则宁愿不上线。主角去找领导希望给定个明确优先级，领导却说保证上线日期和保证安全一样重要。更要命的是，还时不时地有一些突发情况必须马上处理，就比如工资系统出问题了，不马上解决全公司都没办法发工资，第二天这个事故就会上报纸。
主角的这个处境，最难处理的，还不是因为有坏人在搞破坏，也不是有人笨、能力不行。而是，拖你后腿的那些人，他们和你一样有相同的目标，一样也在拼命。
面对这样的情况，一般人都会束手无策。在小说里面，主角是幸运的，当他正在为自己的困境焦头烂额的时候，他遇到了一位导师。在导师的帮助下，主角发现了解决问题的关键。
具体怎么做的呢？这位导师先问了主角一个问题，“你知道你的工作是什么吗？”主角当时就被问懵了，这怎么能不知道呢，老板给自己安排的工作就是赶快把凤凰项目做出来。
当听到这个答案后，这位导师就意味深长地看了主角一眼，告诉他，如果他是这么理解的话，那出现这样焦头烂额的情况就很正常了，因为主角可能根本不知道，一项工作到底是怎么从头到尾完成的。
听到这句话主角的心里是不同意的，自己工作的第一天，就在梳理工作内容，已经有了一个长长的清单，上面就是完成一项任务所需要的所有步骤。
这位导师也没有多说话，而是把主角带到了一家汽车配件的生产车间，带他在厂房的高处俯瞰整个车间。导师指着车间的两处装卸区说，“原材料从一边送进来，加工成成品后从另一边送出去，如果你在这里站的时间够长的话，就可以看到这项工作里的每个任务。”
其实，导师想说的重点不是去看每个步骤都是怎么完成的，而是应该关注每个生产环节积压了多少半成品，或者说库存。这其实就借鉴了丰田精益生产的思想，库存是效率的死敌。生产车间有个天然的优势，就是每个生产环节的库存都是显而易见的，如果没有及时处理的话，库存就可能堆满整个空间。
但是，技术开发就不是这样了，技术开发的半成品不会这么显而易见地被看到。其实不只是技术开发，任何一项智力工作都是一样的，不论是拍一部电影，还是写一篇公众号文章，还是在得到App里做一门课程，都有这样的劣势。在你电脑里的半成品素材，编辑一半的文章，可能只有你知道，其他人根本不清楚。而这些都是半成品，都是库存，它们的存在就会影响整个团队的效率。
就比如说，主角在推进凤凰项目的时候为什么总是焦头烂额，其中一个原因就是他没有意识到，他的部门里面有一位首席工程师积累了过多“库存”。这些积压的任务，让他根本没有精力处理凤凰项目。
所以，实践DevOps的第一步，就是先让你的工作可以看得见。当然，这个看得见，可不是主角一开始那样，把要做的事情列一个清单，做一个标准流程，也就是SOP，完成一个打一个勾，而是要能体现出半成品的堆积情况。怎么做呢？有一个方法，那就是使用看板。
看板技术，其实是从丰田的精益生产方法里借鉴的。看板，就是在一面墙上画出好几列，每一列代表一个部门，比如开发部门是一列，IT运维部门是一列。然后用即时贴写上每一项的任务名字，贴在了哪个部门下面，就代表着这个部门正在做这项任务。每一列还可以分成两个区域，一个区域表示正在做的任务，另一个区域表示已经做完了，还没有交付给下一个环节的任务。上游已经完成，下游还没有开始，这就是库存了。
我在文稿里面也贴了一张书里的看板图，感兴趣的话你可以点击文稿查看。
书里的主角就是通过看板才开始了解了自己工作的全貌，为以后解决整个困境打下了基础。
当然了，看见还是最基本的一步。用看板可不是看见了就完了，看见的目的是为了改善。
关于改善，那位导师讲出了一句最重要的话，“在瓶颈之外的任何改进都是无效的”。你可以把整个工作流程想象成是一个水管里的水流，最后决定流量的不是最粗的部分，而是最细的部分。
在工作流程中如果有一个瓶颈点，在这个点之前的改善没有用，到了瓶颈点这里只会增加库存，在瓶颈点之后的改善也没有用，因为上游的瓶颈点没办法供应充足的原材料。
其实，这句话的另外一个表达形式对于改善的帮助更大，那就是“任何有效的改善都是对瓶颈的改善”。通过这句话，就能让我们在改善时明确目标，那就是找到瓶颈点，然后改善它。
有了看板之后，找到瓶颈点就比较容易了，库存最多的地方就是瓶颈点。在小说里面主角就找到了一个瓶颈点。这瓶颈点是一个人，就是前面举例子提到的那个首席工程师。他与我们对瓶颈点的印象不太一样，这个瓶颈点不是因为个人的能力太差，反而是这个人能力太强了。
如果是因为能力不够才成为瓶颈点的，反而就好办了，这样的瓶颈最容易优化，换一个能力强的人，或是增加更多人手就能搞定。优化瓶颈点最难的，就是书里的这个情况，瓶颈点因为能力太强，很多工作都依赖他，在他这里就变成了大型交通拥堵现场。
在书里是这么描述这位首席工程师的，说他可能是个技术界的爱因斯坦，任何运维的工作只要交给他，他都能顺利搞定。他也非常努力，或者说享受这种忙碌的状态，在显示器上贴满了即时贴，都是需要由他解决的问题。虽然他非常忙，特别需要有人能帮他减轻工作量，但是根本找不到和他同等水平的员工。
这样的人，你是不是也能在自己的身边找到。他们甚至还会给人留下这样的印象，他们这么做，是因为他们把自己的知识看作是一种权力，故意让自己显得无可或缺，以免其他人抢了他的工作。
不论具体动机是什么，事实就是他们太能干了，所有的工作都依赖他们，而且还无法替代。这样的瓶颈点才最难优化。那应该怎么办呢？
在书里，主角用的方法，不是继续提升这位首席工程师的能力，而是把他保护了起来，减少他的工作。你可能会有疑问了，减少工作？他会成为瓶颈，就是因为很多的工作都需要他，没有他无法完成。如果减少他的工作，那库存不就越积越多。
希望所有工作都能尽快完成的愿望是好的，但是有愿望不代表就能实现。这就像是在交通路口发生了拥堵，如果让这里继续拥堵下去的话，可能所有的车辆都无法通过。所以，不如对这个路口先进行限流，让最紧急、最重要的车辆能够先顺利通过。那么在这位首席工程师这里，应该对哪些工作限流，让哪些工作通过呢？凤凰项目肯定是最关键的那个任务，除它之外都可以限流。
这是不是就搞定了呢?事情还没有那么简单。在小说里，主角明明已经和首席工程师确认了，凤凰项目是最紧要的工作，优先级最高。可是为什么他还是会去做其他方面的工作呢？经过沟通主角发现了，因为总是有一些大人物会对首席工程师“大吼大叫”，说他们手上的任务必须优先完成，否则公司就完蛋了。这些大人物，可能是市场部的负责人，也可能是开发部门的负责人，甚至可能是公司的CEO。
这些大人物手上的任务确实非常重要，但是他们都是从自己部门的角度出发的。而且这些大人物非常清楚怎么找关键人物，他们知道如果想要推进自己的项目，找别人都没用，这位首席工程师才是关键。
这些大人物很能干，但是也正是他们的能干造成了在瓶颈点的拥堵。面对这样的情况，主角作为负责人需要持续沟通，和每一个人明确各自任务的优先级。任务的优先级都是最高级，那就等于没有优先级，没有优先级那最后就是谁的声音最大谁的优先级最高，或者谁先来谁的优先级最高。
其实，像前面这种情况只要沟通好，明确好优先级，问题还比较容易解决。比较难解决的是那些必须要抢险的任务。就比如，公司的工资系统出错了，如果不赶快搞定那就是重大事故。这肯定是最紧急的事情，优先级一定最高。这个时候应该怎样保护瓶颈点呢？
在书里，主角的解决方法是，给首席工程师分配了几个初级工程师。正常来说，遇到突发情况，这几个初级工程师是不起作用的，诊断问题，解决问题都需要首席工程师的经验。
不过，这几个初级工程师的工作，不是帮首席工程师解决问题，而是去记录。主角是这么要求的：“他们要负责记录学到的东西，永远不准首席工程师反复解决同一个问题。我每周都会逐项检查这些问题，如果我发现他在同一个问题上出手了两次，不论是初级工程师还是首席工程师都要受罚。”就是靠这样的要求，避免了很多首席工程师的重复劳动，需要重复劳动的事情交给初级工程师就可以了。
不知道你发现了没有，主角给出的这个解决方案，包含了两个关键点。第一点，遇到问题，主角并没有关注是不是上游开发部门的责任，就算真的是开发部门的责任，那也应该在自己的环节先把问题解决掉。
你想啊，就算是开发部门遗留的问题，按道理应该由他们来解决。那能直接打回给上游部门吗？不行的，如果真的把工作打回给上游部门，虽然可以减少瓶颈点的工作量，但是这就相当于无法将这个任务快速送到下游部门，这就是在增加整个工作流程的库存啊。所以，遇到问题自己先来解决，这样做不是在追责，而是为了让任务可以更快地交给下游，减少库存。
这是第一个点，还有第二点，就是要避免首席工程师总是解决相同的问题。这其实是在减少任务对瓶颈点的依赖，通过初级工程师来进行分流。而且，这件事不只是初级工程师的责任，同样也是首席工程师的责任。如果没有做到，双方都要做到惩罚。同时保证了这两点，才是解决瓶颈问题的关键。
把首席工程师的瓶颈问题解决掉之后，小说里面最主要的难题也就解决了。听到这里，你可能会觉得，这好像只是一些见招拆招的方法，只是这样就能让所有互联网公司都在实践吗？
如果只是靠前面这些见招拆招的方法，肯定是不行的。作者们在小说里面借着那位导师，把他们是如何能够发现问题，如何可以见着拆招的心法总结了出来。也就是DevOps的核心思想，三步工作法。
我在最开始介绍了，在《凤凰项目》这本书之后，作者把他的方法论都总结在《DevOps实践手册》这本书里了。如果你去看这本手册的话，就会发现，这本手册就是按照三步工作法来组织的。
三步工作法的第一步是建立起工作流。这里说的工作流，你就可以理解成主角为了让工作可以被看见，建立起来的看板。部门之间的协作关系就是管道，任务一项一项地在管道中流动的过程就是工作流。因为每个任务流动的过程，也是一个产品价值增长的过程，所以它也被称作是价值流。
你可别觉得，建立工作流，就是让本来看不见的工作变得可以被看见了。其实，建立工作流最重要的一点，是看待工作的视角发生了变化。那种明明每个人都很努力，但是却总有人在拖后腿的困境是怎么出现的，就是因为各个部门都有自己的目标和KPI。当每个部门都在努力对自己的目标负责时，就可能会出现这样的困境。
面对这种情况，我们其实都知道，各个部门不应该只盯着自己的目标，公司是一个整体，是一个系统，每个部门都应该对系统负责。可问题是，怎么才算对系统负责？什么可以代表系统？DevOps提出的工作流，就是这个可以代表整个系统的东西。所有部门的目标都是让工作流流动得更快，也就是让价值产生的速度变得更快。
在你把工作流当作自己负责的对象后，你所有努力的方向，自然而然地就变成了改善工作流上的瓶颈，就像是小说里的主角一样。
所以，建立起工作流，建立起看板，不只是让原来不可见的工作变得可见，更重要的是，它让每个部门负责的对象发生了变化。从他们各自独立的目标，变成了改善整个工作流。
这是第一步，建立起工作流。还有第二步，建立起反馈机制。这一步其实就在回答，改善工作流具体应该怎么做。
前面我们也讲到了，发现瓶颈，然后针对瓶颈进行改善。比如，小说里的主角发现了首席工程师是瓶颈，为了改善这个瓶颈点，用各种方法保护他不受其他工作打扰。
但是这样的改善，只是对整个工作流中一个节点的改善。工作流代表着的是整个公司、整个系统，如果遇到问题都只是在单个节点上进行改善，那还是远远不够的。
就比如，假如主角一直是遇到了问题都自己部门内部解决，那么难免会出现这样的情况，开发部门下次还会继续犯同样的错。甚至主角还可能把开发部门给惯坏了，本来是他们的责任他们也不承担，有什么问题都交给下游的IT运维部门。这就让IT运维部门的工作越来越多，忙不完。本来是自己更负责，更顾全大局，结果却总是自己在吃亏。
所以，只是一味地自己改善还是不够的，也需要在自己改善的同时，将问题进行反馈。反馈给谁呢？反馈给上游部门，让上游部门也做出改善。所以第二步其实有两方面，反馈和改善，反馈是对上游的反馈，改善是对下游的改善。如果问题发生了，那么针对这一次的问题，应该自己能解决就解决，让下游可以尽快开展工作。同时也需要对上游反馈问题，不过这个反馈是针对下一次任务的，让上游不要总是犯同样的错误。
这是第二步，还有第三步，建立起持续学习的文化。这一步，其实就是把前面提到的所有方法都内化到整个团队里，成为整个团队的财富。
在这一步DevOps是在强调从系统的角度去看，而不是从个人的角度去看。从系统视角去看，是怎么看呢？在面对整个系统出现的问题时，直接原因可能是某个人失误或是粗心，但是人为错误并不是问题的根本原因，恰恰相反，人为错误是系统存在设计问题，给了个人犯错的机会。
所以，一个具有学习文化的团队，就不应该对造成故障的人进行点名、责备和羞辱，而是应该把错误当作重要信号，最大限度地抓住学习的机会，持续地揭示和交流日常工作中的问题。
这段话可能有点抽象啊，我可以给你举个例子。我们都知道，如果遇到了某个事故，都需要复个盘，避免下次犯同样的错。具有学习文化的团队怎么复盘呢？在复盘会上批评犯错的员工？肯定不是。那么不批评具体的人是不是就可以了呢？不一定。
虽然不批评犯错的员工，但是只是要求他们去总结自己到底哪里错了，下次应该更负责更认真，这样的做法仍然不是学习型组织。因为这样的改进，还是依赖个人，没有把解决方案落实在系统上。比如说，有人犯错了，是因为产品上线的时间太紧导致了疏忽，如果是依赖个人的话，就是让这个人下一次更认真些，如果是落实到系统上呢？就应该是想办法避免上线太紧的情况持续出现。
也就是说如果出现了问题，针对问题的改善，个人的认真和努力肯定是需要的，但是更重要的是从系统进行解决。
讲到这里，这本书的核心内容就为你介绍完了。
总结一下的话，到底什么是DevOps，其实它就是用系统的思维，去解决不同部门之间的系统问题。用系统的思维去解决公司和团队的问题，这一点其实并没有什么特别的，但是DevOps更进了一步，不只是告诉了我们应该做什么，还告诉了我们应该怎么做。那就是三步工作法：第一步建立工作流，完成系统视角的转换；第二步，建立反馈机制，对上游反馈对下游改善；第三步，建立起持续学习的文化，让所有的改善都可以落实到系统上。
撰稿、讲述：王木头
脑图：摩西脑图工作室