《凤凰项目》| 王木头解读

关于作者

吉恩·金(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更进了一步,不只是告诉了我们应该做什么,还告诉了我们应该怎么做。那就是三步工作法:第一步建立工作流,完成系统视角的转换;第二步,建立反馈机制,对上游反馈对下游改善;第三步,建立起持续学习的文化,让所有的改善都可以落实到系统上。

撰稿、讲述:王木头
脑图:摩西脑图工作室

划重点

1. DevOps,其实就是用系统的思维,去解决不同部门之间的系统问题。 2. 三步工作法:第一步建立工作流,完成系统视角的转换;第二步,建立反馈机制,对上游反馈对下游改善;第三步,建立起持续学习的文化,让所有的改善都可以落实到系统上。
(0)

相关推荐