《凤凰项目》书评

你可以拥有的IT运维思维

“有些书适合给你的朋友，为了分享阅读的喜悦；有的书适合给你的同事，为了建立理念的共识；有些书适合给你的老板，为了播下伟大的种子。而本书适用于以上三种情况。”这段话是对这本书最好的概括。作为一本融合IT专业性和通读性的书，它既有商业实战模式的真实企业故事，又能将IT运维的解决之道融入其中。在这个“互联网+”的大时代，不管你是否IT从业者，都能感受到互联网行业越来越融入生活的气息。三个美国的IT从业者，Gene Kim 、Kevin Behr和George Spafford，结合多年的IT相关经验，站在一个管理者的角度讲述了IT运维的四种工作类型和三步工作法。众人拾柴火焰高。在各种说教式理论类丛书漫天飞的同时，三位作者能够耐得住性子，将自己的多年的从业经验，合力共聚为一本书。这本书的含金量自然可想而知。与其说这是一本传授管理经验和工作秘诀的书，不如说它更是一本通识教育的书，书中讲述的IT运维思维具有普适性。本书通过主人公比尔·帕尔默临危受命被任命为IT运维部的副总裁，经历了4个多月的工作适应，遭遇工作瓶颈、办公室政治斗争，在贵人指点下掌握了IT运维的工作核心和秘诀。最终带领团队走出了困境，挽救了公司。虽然书中是以第一人称 “我”——IT运维部的副总裁，为主要的讲述对象，但故事里讲述的如何理清繁多的工作障碍，确定好工作优先级，将常规工作标准化等工作方法，适用于各行各业不同的从业者。好书能在故事中寓意大道理。太多刻板枯燥的理论难以勾起阅读和学习的兴趣，但模拟实战的工作情况，对于读者来说更像一场感同身受的经历。不管是从事何种行业，工作效率是我们追求不变的宗旨。制约工作质量和快慢的因素有很多，仔细想来，不论是一个企业团队的整体工作，还是对于我们个体，合理有序的工作流都是非常重要的。如何协调好自己和工作之间的这个最佳流程，建立起常规工作标准化机制，设置及时反馈响应机制，建立良好而共同的团队文化，突破工作中的制约点，这些都决定了你的工作质量。将书中的三步工作法拆解为与我们工作适用的内容，这是我阅读的最大收获之一。书中的主人公比尔·帕尔默在工作陷入困境时，遇到了指点迷津的贵人，通过不断摸索、尝试，建立起适合自己团队的工作模式和方法。学会阅读这个故事，思考并总结故事中阐述的工作方法，灵活运用到自己的工作中，此书也就成了你自己工作中的贵人。

运维的蜕变，很有参考意义。

阅读本书的过程，让我感觉和阅读《三体》三部曲一样，前面有些平淡无奇，但是随着故事的发展，越看越兴奋，兴奋之后则是陷入深思。这是一本少有的写到运维的小说，而且不缺技术，相反，涉及到技术的范围还很广。本书的前一段内容我感同身受，各种各样的紧急工作、混乱的IT变更，而Bill来自的地方，则有着自己建立的IT变更管理，井然有序。或许所有的IT在前期的阶段基本上都面领着这样的问题。而后来，面临着公司即将被拆分，IT业务被外包的局面，在Eric的指点下，Bill将运维、开发、业务聚集到一起，通力合作。感觉这种方式有着敏捷、DevOps的因子。每一次变更成功，每一次故障的避免，都让我欣喜若狂，仿佛就是身边的事情。尤其是看到Bill和Kris开始合作后，其实心中除了兴奋，还有一丝羡慕。得知DevOps的概念时，大概是13年初（源自于《DevOps的各个阶段》）吧。当时网络上不少人都在高呼运维要下岗了，认识的一些运维攻城狮都人人自危。但是这么多年了，至少在我司中，干运维的还在干运维，基本没啥变化。搞软件开发的倒是自己做了些运维的工作——没办法，现在内部支持也要费用，能省点儿是点儿。Bill自始自终都是作为一个副总裁，在自上而下的推动整个故事的发展。他为什么没有在原有的部门就将变更管理推广出来呢？自上而下很重要。虽然没有ITIL工具的管理，仅仅利用看板，就能将如此多的变更管理得井然有序。而现实中，管理员们懒到极点，一个字段都不愿意填写，更别说写纸条了。这么多年了，开发和运维从来没有通力合作过，往往是交接，而且只有交接，开发只是为用户服务，压根不考虑运维的事情，毕竟，考虑到安全、易运维的问题都会增加成本——又开始吐槽了。或许本书中，开发、运维同属一个公司，有着共同的目标，而现实中的我们，只有盈利才是共同的目标，其他的——考虑那么多作甚？

交付价值的it

凤凰项目确实是和《目标》一样的传奇故事。最近两年一直在思考Devops、持续交付、微服务，其实本质的思想，是回归常识的约束理论，虽然康威定律指出了现象，但是要怎么做，还需要高德拉特博士的思考方式。正好在作者写这本书那年，没有任何先入之见时候看到目标和约束理论。之后一直用这种简单自然的思想观察世界、指导实践，看到凤凰项目，确定了正是“胖胖的小男孩贺比”作为主线在推动着从自动化构建到持续集成、容器这些技术和思想的演进。到现在devops已经是不需要争议的竞争优势，各种工具已经成熟，因为这个过程而产生的工具和方法已经像空气一样自然，思想却很少被提及。正好2009年，还看过尼古拉斯卡尔的IT不再重要，云计算的到来，开发运维成本越来越低，企业可以更专注于业务。IT不再重要，因为每一个公司都在成为科技企业，IT已经是企业价值链的重要一环，不在是鼓励的解决局部的问题，局部改善只能让问题更糟，只有针对瓶颈整体优化，为最终用户交付价值。才是devops的意义。至于怎么做，当然不是工具或者方法的简单应用，只有像大野耐一教我们的那样，现场管理，这个是没有银弹的

不只是DevOps

作为一个程序员，DevOps这个词并不陌生。2011年底我就看了《持续交付》，当时给我的震动很大。在AppAnnie我看到了持续交付是如何变为现实的，我觉得这是个非常棒的过程。这本书的价值绝对不是在主角们做到了一天部署十次，而是在这之前的n章之中他们的痛苦和煎熬。一个烂摊子，一堆破事儿，没人没钱，怎么办？怎么限制工作量？怎么保护最能干的员工？最重要的是，怎么缩短交付周期，提高交付质量？Bill在书的前半部分进展很慢，后半部分慢慢加快。他们在前半部分做了很多探索性的工作，很多尝试。每当我在看到Bill和他的两个下属开会讨论某个问题的时候，我都会停下来问问自己，这时候应该怎么办？DevOps虽然是终极的解决方案和目标，但是我们需要一步一步踏踏实实的向这个目标前进，步子迈得太大只会扯着蛋。仔细思考一下故事中的每个问题，每次会议，对自己都是一种锻炼。在真正的日常工作中，没人会像Eric一样给你耐心的提示。这本书就是我们每个人的Eric，而凤凰项目之于我们的日常工作的情况差别，就好像制造业生产线和凤凰项目的差别一样巨大。虽然情况千差万别，但是我们要做的就是从凤凰项目这样的案例之中找到像“三步工作法”或是“四种工作内容”这样的东西，来给自己启发。

如果你找不到《丰田管理》这本书……

它在这里：http://book.douban.com/subject/3871227/并且它也不叫什么鬼《丰田管理》。它叫Toyota Kata好吗？“Kata”不知道吗？还搞个什么“改进型”，吓死我了好吗？我们干这行的都管Kata叫“招式”好吗？这就是个典型例证，折射出整本书翻译中的外行。你找俩会编程的人来翻译行吗？你找个负责点的编辑行嘛？就算你这些都不做，我的天，人家原书引用了几十本书，你能把参考文献列表留住吗？能吗？你把参考文献列表给删了，又把书名一通乱译，我得费多大劲才能找到里面提到的书你知道吗？你真当我是来看小说的吗？当然我不会因为这点小毛病就贬低这本书本身。书还是五星。不过我还是这么说：中国绝大多数的翻译作品，译者加上编辑一起，其作用就是让中国读者能花几十元人民币买到本来价值几十美元的书，并且尽他们的最大努力损害书的价值，使中国读者少占一点便宜。