凤凰项目
出版日期:2015-9-1
ISBN:9787115403651
作者:基恩·金 (Gene Kim),凯文·贝尔 (Kevin Behr),乔治·斯帕福德 (George Spafford)
页数:362页
作者简介
本书讲述了一位IT经理临危受命，在未来董事的帮助和自己“三步工作法”理念的支撑下，最终挽救了一家具有悠久历史的汽车配件制造商的故事。小说揭示了管理现代IT组织与管理传统工厂的共通之处，让读者不仅能对如何管理IT组织心领神会，更重要的是将以完全不同于以往的视角来看待自己的工作环境。
书籍目录
第一部分
第1章 9月2日，星期二 2
第2章 9月2日，星期二 12
第3章 9月2日，星期二 23
第4章 9月3日，星期三 34
第5章 9月4日，星期四 49
第6章 9月5日，星期五 61
第7章 9月5日，星期五 72
第8章 9月8日，星期一 82
第9章 9月9日，星期二 92
第10章 9月11日，星期四 100
第11章 9月11日，星期四 108
第12章 9月12日，星期五 114
第13章 9月15日，星期一 127
第14章 9月16日，星期二 135
第15章 9月17日，星期三 143
第16章 9月18日，星期四 155
第二部分
第17章 9月22日，星期一 164
第18章 9月23日，星期二 169
第19章 9月23日，星期二 175
第20章 9月26日，星期五 190
第21章 9月26日，星期五 203
第22章 9月29日，星期一 211
第23章 10月7日，星期二 221
第24章 10月11日，星期六 226
第25章 10月14日，星期二 234
第26章 10月17日，星期五 243
第27章 10月21日，星期二 252
第28章 10月27日，星期一 261
第29章 11月3日，星期一 270
第三部分
第30章 11月3日，星期一 278
第31章 11月3日，星期一 284
第32章 11月10日，星期一 292
第33章 11月11日，星期二 299
第34章 11月28日，星期五 306
第35章 1月9日，星期五 313
致谢 324
简介 327
为什么需要开发运维 328
开发运维从何而来 333
对三步工作法的解释 335
对开发运维的主要误解 337
四种工作类型 341
延伸阅读 346
注释 359
内容概要
基恩•金
Tripwire有限公司的创始人，他担任公司CTO长达13年之久。在Tripwire公司，他一直热衷于研究如何提高IT组织的效能。
凯文•贝尔
他创建了信息技术流程研究所，他拥有25年的IT管理经验，为CEO和CIO们提供指导和建议。
乔治•斯帕福德
行业分析师，帮助IT组织更好地找到目标，明确必要条件，发现实现目标的方法。
发布书评
精彩书评 (总计5条)
-
“有些书适合给你的朋友，为了分享阅读的喜悦；有的书适合给你的同事，为了建立理念的共识；有些书适合给你的老板，为了播下伟大的种子。而本书适用于以上三种情况。”这段话是对这本书最好的概括。作为一本融合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工具的管理，仅仅利用看板，就能将如此多的变更管理得井然有序。而现实中，管理员们懒到极点，一个字段都不愿意填写，更别说写纸条了。这么多年了，开发和运维从来没有通力合作过，往往是交接，而且只有交接，开发只是为用户服务，压根不考虑运维的事情，毕竟，考虑到安全、易运维的问题都会增加成本——又开始吐槽了。或许本书中，开发、运维同属一个公司，有着共同的目标，而现实中的我们，只有盈利才是共同的目标，其他的——考虑那么多作甚？ -
凤凰项目确实是和《目标》一样的传奇故事。最近两年一直在思考Devops、持续交付、微服务，其实本质的思想，是回归常识的约束理论，虽然康威定律指出了现象，但是要怎么做，还需要高德拉特博士的思考方式。正好在作者写这本书那年，没有任何先入之见时候看到目标和约束理论。之后一直用这种简单自然的思想观察世界、指导实践，看到凤凰项目，确定了正是“胖胖的小男孩贺比”作为主线在推动着从自动化构建到持续集成、容器这些技术和思想的演进。到现在devops已经是不需要争议的竞争优势，各种工具已经成熟，因为这个过程而产生的工具和方法已经像空气一样自然，思想却很少被提及。正好2009年，还看过尼古拉斯卡尔的IT不再重要，云计算的到来，开发运维成本越来越低，企业可以更专注于业务。IT不再重要，因为每一个公司都在成为科技企业，IT已经是企业价值链的重要一环，不在是鼓励的解决局部的问题，局部改善只能让问题更糟，只有针对瓶颈整体优化，为最终用户交付价值。才是devops的意义。至于怎么做，当然不是工具或者方法的简单应用，只有像大野耐一教我们的那样，现场管理，这个是没有银弹的
精彩短评 (总计50条)
-
作者强行营造紧张感，毕竟作者不是技术出身，虽然尽力模拟出IT项目的里面的场景，但依然是说得很空泛。两小时读完这本书，刷新了我的阅读速度。另 -
凤凰项目确实是和《目标》一样的传奇故事。最近两年一直在思考Devops、持续交付、微服务，其实本质的思想，是回归常识的约束理论，虽然康威定律指出了现象，但是要怎么做，还需要高德拉特博士在目标中介绍的思考方式 -
核心是专注，只做真正重要的工作，其余的都扔掉 -
非常好的一本书，但是要读懂，要读透彻需要读很多遍 -
很棒的一本书，至少能把自己从运维的小视角扩展成公司的大视角来看问题。 -
从宏观的角度上去看待开发，运维到销售一体化的过程。现在很多传统企业不能认识到IT的重要性，或者是使用传统的管理办法来管理IT，这肯定导致很多的问题，一再的大力投入却迟迟不见回报，各个部门始终无法协调等等。所有的企业都是以营销为王，因为是企业盈利的入口，作为一个专业的开发团队，肯定要站在营销的立场上去考虑功能的设计，而运维，一定要紧密的契合开发，做到快速响应，这样才能真正贯穿营销，开发，运维，打造一个紧密的企业结构。 -
喜欢作者的叙事方式，引人入胜，让人忍不住想把这本书看完。如果你对你所在的组织在IT方面的运营现状不满，想改变却无从下手，那么此书或许可以帮到你。 除了三步工作法以外，主人公的处事方式也是值得学习的。 -
和《目标》一书的写法情节一模一样，完全没有读下去的欲望，不过是换了一个名字讲TOC -
一直以为在讲敏捷的思路，最后看总结才知道是开发运维。用小说的方式讲述，比较容易接受，印象最深的是四种工作类型 业务，内部，变更，计划外工作。很多时候我们都在花大量时间在最后两个上面，所以尽量将工作的颗粒度切小，降低风险 -
以故事的方式讲述了很多IT相关的实践。 -
2016-04-07 -
非常有带入感的一本书，让我不断思考，如果作为一个领导者遇到这样的困境，怎么跳出固有思维解决问题，摆脱困境。还有，寻求帮助，是工作能力的一个重要体现！2017年，devsecops是工作重点之一。 -
2017.3月底，魏老板推荐看的书，3天余暇看完。
1.以凤凰项目为故事主线，穿插融入开发运维的核心理念，从运维的四类型工作，到三步工作法，到打破团队障碍建立团队信任，形式非常好。
预防性工作比救火更重要。这可以对应到重要不紧急的四象限工作法则。
2.毫无意外，这类故事总是有一个上帝视角的导师型角色不断帮助主角成长，升级打怪。
3.书是15年出版的，其中部分内容在国内很多互联网技术支撑型公司已经实际应用了，书籍本身的滞后性显现出来。
总结，对于运维管理人员，作为入门书籍是非常好的，一个伪运维人员阴差阳错留。
2017.3.30 -
提炼了不少日常的体会 -
第一工作法是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，决不让缺陷流向下游工作中心，并且不断为了整体目标进行优化
第二工作法是关于价值流向各阶段自右向左的快速持续反馈流，放大其效益已确保防止问题再次发生，或者更快的发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量
第三工作法是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提 -
读的第一本it小说，感觉挺新奇，也确实讲明白了一些道理 -
值得每个置身快速交付中的人思考 -
了解 DevOps 产生的背景，通过小说体的描述感受传统公司里“运维”和“开发”以及其他非技术团队的冲突
很多 IT 圈里流行的管理方法论都来自传统行业，例如*精益*就不是什么新的概念
从故事里管理人员的对话中也可以看到不同角色的人对同一个项目的不同理解，例如考虑一个项目的资金回报率，然后评论说这些钱还不如放在余额宝里 …… -
里面的很多场景并不陌生，书中的应对手法很可以借鉴 -
整本书的虽然采用时间的序列为章节的题目，让人很难通过目录了解书的框架。但是作为弥补，目录采用三个部分作为区分，也能把握好框架。书的语言比较简单，没有专业术语，更像是一本小说，读起来并不费力。但是读完却能够对整个IT运维有个更深层次的认识，对如何开展运维的工作有比较大的帮助。是一本不错的书。 -
看了一半，数落在了飞机上了……作为实践过ITIL流程设计和项目实施，以及做过专职项目经理的我，对书中的内容非常熟悉也倍感亲切。只是作者更多的在讲故事，而不是分析故事和提供方法。 -
值得一读 -
干货 -
意犹未尽 -
没法停下来的好书，花了整个周末时间和几个晚上通读一遍，精读一遍。真正让我通俗易懂的了解到运维的工作流，也让我对现有的运维项目有了更深的理解，更神奇的是里面关于约束点，三步工作法，四个工作内容等工作和团队沟通协作的方法让我对本职工作也有很大帮助。 -
有意思 -
很好看的书，收到书以后都不想做别的事，有空就拿出来。前面说的困境感同身受，后面讲的改进方法实施起来太难了。我们这的模式是前人挖坑后人埋，还好我们没有很多业务项目，至于变更完全凭借拍脑门，45度望天。乐观点，至少我们还是有git 和redmine。然后准备去看这本书里面推荐的其他书。 -
过于现实，所以精彩。 -
小说惊心动魄又不失风趣，工作中转瞬即逝的片段被提及并连成一片。给我很多管理上的启示。 -
以前没有读过相关的书，只从一些文章中了解过对持续交付的介绍，这本书的内容也印证了我对devops的期待，希望以后的工作可以从中受益。 -
DevOps、GTD…原来开发部与运维部有那么多矛盾冲突…20160629 -
了解DevOPS以外的事物，更好的反思DevOPS -
正在读 虽然现在工作年限才三年多，但是也算经历过一些事，看的时候感觉有种自己经历的感觉 小紧张 -
估计要读第二遍…… -
难得有这样的小说把IT运维的故事描写的如此生动写实，4类工作3步工作法这些从制造业借鉴的方法也值得我学习和深思。小说最后的转折有点快，实际工作中实施起来真的是困难重重，太多的时间精力耗费在计划外或者救火工作。 -
读到凌晨7点，故事很吸引人。不过有两个感觉：1. 作为一本写给业内的小说，最后关于能够一天做N次交付，是一个值得细谈的东西，可惜结束地相对简单。2. 埃瑞克这样的人，哪儿能轻易碰到？每个故事都得有个扫地僧么？ -
非常不错的一本书，很生动。说到的问题都很真切，解决问题过程描述也很清楚。很多时候其实我们看不到结果，我们只是努力去做而已 -
要再读一遍。 -
很有趣的一个故事，更多的像是一个看板的案例。很多年前，rea的前CEO给我们介绍了one company的理念，我当时的理解只是局限于软件交付过程，为客户实现价值，但是没有意识到IT甚至可以影响公司股票，这点还是挺有启发的。 -
翻译不忍直视，还好亮点总在最后，其实就是ITIL etc...... -
现在觉得，管理比开发难多了.. -
故事很经典，有启发！ -
共鸣的场景 对主人公管理思想蜕变 深深的折服 这就是管理的魅力 不是国人那套厚黑和鸡汤 关注TOC -
虽然书名是IT运维，实际上软件研发公司各个层级的参与者，从董事、CEO到一线研发运维合规人员都能获益匪浅，近年来难得一见的好书，值得从封面读到封底，去理解每句话、每个单词的含义。 -
一本关于非IT公司的IT部门的职场现形记 ，里面的每一个人物的Persona都刻画的非常完整， 以血淋淋的实例告诉我们：IT is Business对非IT公司来说意味着什么。 -
太有意思了，以小说形式呈现传统企业向互联网转型的运维管理，故事引人入胜，各种救火场景无比熟悉 -
借此了解DevOps -
说服你开发运维与管理制造业流水线是一样的 -
可以多读几遍 -
的确可以产生共鸣的一本书，书中故事感觉就像发生在身边，甚至书中人物都能在工作中找到对应的人，很多观点和调侃都不得不拍案赞同。虽然有些场景过于夸张，部分细节脱离现实，不过关于半成品控制和IT价值流的阐述的确让人印象深刻。