凤凰项目

Homer 2017-01-03 0

虽然书名是IT运维，实际上软件研发公司各个层级的参与者，从董事、CEO到一线研发运维合规人员都能获益匪浅，近年来难得一见的好书，值得从封面读到封底，去理解每句话、每个单词的含义。

Chloé 轩 2017-02-01 0

小说惊心动魄又不失风趣，工作中转瞬即逝的片段被提及并连成一片。给我很多管理上的启示。

银璃 2017-03-30 0

2017.3月底，魏老板推荐看的书，3天余暇看完。 1.以凤凰项目为故事主线，穿插融入开发运维的核心理念，从运维的四类型工作，到三步工作法，到打破团队障碍建立团队信任，形式非常好。预防性工作比救火更重要。这可以对应到重要不紧急的四象限工作法则。 2.毫无意外，这类故事总是有一个上帝视角的导师型角色不断帮助主角成长，升级打怪。 3.书是15年出版的，其中部分内容在国内很多互联网技术支撑型公司已经实际应用了，书籍本身的滞后性显现出来。总结，对于运维管理人员，作为入门书籍是非常好的，一个伪运维人员阴差阳错留。 2017.3.30

sunjiankirk 2016-02-13 1

翻译流畅，表达清晰。特别是对运维工作进行了分类，点出其中的瓶颈，并针对性的改进。

单极子 2016-07-27 1

喜欢作者的叙事方式，引人入胜，让人忍不住想把这本书看完。如果你对你所在的组织在IT方面的运营现状不满，想改变却无从下手，那么此书或许可以帮到你。除了三步工作法以外，主人公的处事方式也是值得学习的。

31337 2016-02-11 0

好的工作方法被证明是万能的

Icarus 2017-01-12 0

团队的成长依赖于团队的约束点，必须要把约束点从繁琐的工作中解放出来，让其他的人也能一些他做的工作，而不是让所有流程事物都卡在约束点上。看的久了，很多忘了，挺不错的书，可以帮助大家找出技术团队中的效率问题所在。推荐

会飞的呆呆猪 2015-12-17 0

高维思考，避免局部优化：不断扩大思考范围，找出约束点并持续优化

wukong 2017-03-05 0

正在读虽然现在工作年限才三年多，但是也算经历过一些事，看的时候感觉有种自己经历的感觉小紧张

stupida 2017-03-25 0

有意思

Exia 2016-06-26 2

作者强行营造紧张感，毕竟作者不是技术出身，虽然尽力模拟出IT项目的里面的场景，但依然是说得很空泛。两小时读完这本书，刷新了我的阅读速度。另

iLRainyday 2016-02-03 2

我不喜欢看外国小说的一个原因就是我实在记不住一堆人名，往往到最后我都不知道这个人是干吗的了... PS. 把code base翻译成"代码基数“这样真的好吗？？？

sunjiankirk 2016-02-13 1

翻译流畅，表达清晰。特别是对运维工作进行了分类，点出其中的瓶颈，并针对性的改进。

单极子 2016-07-27 1

喜欢作者的叙事方式，引人入胜，让人忍不住想把这本书看完。如果你对你所在的组织在IT方面的运营现状不满，想改变却无从下手，那么此书或许可以帮到你。除了三步工作法以外，主人公的处事方式也是值得学习的。

Gavin 2016-05-31 1

#tw#

西顾 2016-11-20 1

非常好的一本书，但是要读懂，要读透彻需要读很多遍

David Kei 2015-12-04 1

今年看过最让我深思的书，关于延伸阅读也让我十分感兴趣，建议更多的人能够读一读这本书，能够让你在工作中的感悟更加确切和透彻

全都是风 2016-05-08 1

一直以来我就有一个问题，为什么战胜拖延症的小组里面堆满了文科老博士，是他们的智力心理的问题，还是他们工作的性质问题。后来灵思风关于真正的魔法是不可分解的理论让我获得了很多自信心。而这本书更告诉我，原来那么大，涉及到那么多用户的产业同样如此困难地（有些人甚至不感到困难）的面对着这个问题；一些些自我厌恶和怀疑我还是能应付的！

liuwill 2016-10-06 1

凤凰项目确实是和《目标》一样的传奇故事。最近两年一直在思考Devops、持续交付、微服务，其实本质的思想，是回归常识的约束理论，虽然康威定律指出了现象，但是要怎么做，还需要高德拉特博士在目标中介绍的思考方式

cyber 2016-04-25 1

把it开发运维比做加工厂，一切还在开发中的未上线的版本，都是积压在车间的半成品，不创造业务价值。这个比喻有种全新的视角。

我想说两句

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

透明 2016-01-18 3赞

它在这里：http://book.douban.com/subject/3871227/

并且它也不叫什么鬼《丰田管理》。它叫Toyota Kata好吗？“Kata”不知道吗？还搞个什么“改进型”，吓死我了好吗？

我们干这行的都管Kata叫“招式”好吗？

这就是个典型例证，折射出整本书翻译中的外行。你找俩会编程的人来翻译行吗？你找个负责点的编辑行嘛？就算你这些都不做，我的天，人家原书引用了几十本书，你能把参考文献列表留住吗？能吗？你把参考文献列表给删了，又把书名一通乱译，我得费多大劲才能找到里面提到的书你知道吗？

你真当我是来看小说的吗？

当然我不会因为这点小毛病就贬低这本书本身。书还是五星。不过我还是这么说：中国绝大多数的翻译作品，译者加上编辑一起，其作用就是让中国读者能花几十元人民币买到本来价值几十美元的书，并且尽他们的最大努力损害书的价值，使中国读者少占一点便宜。

awesome book

Vincent 2015-04-11 0赞

it's for everyone who works in IT Operation Team. not only we can learn the best strategy tackle down minor problem, but also provide a vivid pattern to narrow the gap between infra and Develop.

你可以拥有的IT运维思维

风之子 2015-12-09 1赞

“有些书适合给你的朋友，为了分享阅读的喜悦；有的书适合给你的同事，为了建立理念的共识；有些书适合给你的老板，为了播下伟大的种子。而本书适用于以上三种情况。”这段话是对这本书最好的概括。作为一本融合IT专业性和通读性的书，它既有商业实战模式的真实企业故事，又能将IT运维的解决之道融入其中。

在这个“互联网+”的大时代，不管你是否IT从业者，都能感受到互联网行业越来越融入生活的气息。三个美国的IT从业者，Gene Kim 、Kevin Behr和George Spafford，结合多年的IT相关经验，站在一个管理者的角度讲述了IT运维的四种工作类型和三步工作法。众人拾柴火焰高。在各种说教式理论类丛书漫天飞的同时，三位作者能够耐得住性子，将自己的多年的从业经验，合力共聚为一本书。这本书的含金量自然可想而知。

与其说这是一本传授管理经验和工作秘诀的书，不如说它更是一本通识教育的书，书中讲述的IT运维思维具有普适性。本书通过主人公比尔·帕尔默临危受命被任命为IT运维部的副总裁，经历了4个多月的工作适应，遭遇工作瓶颈、办公室政治斗争，在贵人指点下掌握了IT运维的工作核心和秘诀。最终带领团队走出了困境，挽救了公司。虽然书中是以第一人称 “我”——IT运维部的副总裁，为主要的讲述对象，但故事里讲述的如何理清繁多的工作障碍，确定好工作优先级，将常规工作标准化等工作方法，适用于各行各业不同的从业者。

好书能在故事中寓意大道理。太多刻板枯燥的理论难以勾起阅读和学习的兴趣，但模拟实战的工作情况，对于读者来说更像一场感同身受的经历。不管是从事何种行业，工作效率是我们追求不变的宗旨。

制约工作质量和快慢的因素有很多，仔细想来，不论是一个企业团队的整体工作，还是对于我们个体，合理有序的工作流都是非常重要的。如何协调好自己和工作之间的这个最佳流程，建立起常规工作标准化机制，设置及时反馈响应机制，建立良好而共同的团队文化，突破工作中的制约点，这些都决定了你的工作质量。将书中的三步工作法拆解为与我们工作适用的内容，这是我阅读的最大收获之一。

书中的主人公比尔·帕尔默在工作陷入困境时，遇到了指点迷津的贵人，通过不断摸索、尝试，建立起适合自己团队的工作模式和方法。学会阅读这个故事，思考并总结故事中阐述的工作方法，灵活运用到自己的工作中，此书也就成了你自己工作中的贵人。

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

RexKang 2016-03-10 0赞

阅读本书的过程，让我感觉和阅读《三体》三部曲一样，前面有些平淡无奇，但是随着故事的发展，越看越兴奋，兴奋之后则是陷入深思。

这是一本少有的写到运维的小说，而且不缺技术，相反，涉及到技术的范围还很广。

本书的前一段内容我感同身受，各种各样的紧急工作、混乱的IT变更，而Bill来自的地方，则有着自己建立的IT变更管理，井然有序。或许所有的IT在前期的阶段基本上都面领着这样的问题。

而后来，面临着公司即将被拆分，IT业务被外包的局面，在Eric的指点下，Bill将运维、开发、业务聚集到一起，通力合作。感觉这种方式有着敏捷、DevOps的因子。

每一次变更成功，每一次故障的避免，都让我欣喜若狂，仿佛就是身边的事情。

尤其是看到Bill和Kris开始合作后，其实心中除了兴奋，还有一丝羡慕。

得知DevOps的概念时，大概是13年初（源自于《DevOps的各个阶段》）吧。当时网络上不少人都在高呼运维要下岗了，认识的一些运维攻城狮都人人自危。但是这么多年了，至少在我司中，干运维的还在干运维，基本没啥变化。搞软件开发的倒是自己做了些运维的工作——没办法，现在内部支持也要费用，能省点儿是点儿。
Bill自始自终都是作为一个副总裁，在自上而下的推动整个故事的发展。他为什么没有在原有的部门就将变更管理推广出来呢？自上而下很重要。
虽然没有ITIL工具的管理，仅仅利用看板，就能将如此多的变更管理得井然有序。而现实中，管理员们懒到极点，一个字段都不愿意填写，更别说写纸条了。
这么多年了，开发和运维从来没有通力合作过，往往是交接，而且只有交接，开发只是为用户服务，压根不考虑运维的事情，毕竟，考虑到安全、易运维的问题都会增加成本——又开始吐槽了。

或许本书中，开发、运维同属一个公司，有着共同的目标，而现实中的我们，只有盈利才是共同的目标，其他的——考虑那么多作甚？

一直在寻找的WOW

Nicolas 2017-02-04 0赞

这本书把我一直在寻找的一种工作方法，嵌入到了小说里面写出来。看到是一个字，爽.

但我一直忙于工作的时候。总会有一个想法在脑海里回荡，总觉得这，不是个办法，但又不知道怎么办。看了这本书，他仿佛像一个明灯，点亮了我前进的道路。

他从一个宏观的角度来去看待整个开发测试和部署运维整个流程。一直以来我都觉得，进行更高维度的系统化思维才是正确的，但是没有机会和办法在实践中运用起来获得经验. 看这本书，就像看一本，射雕英雄传。

但是从我的经验来看，一个思想要推广很难，首先你要让整个团队取得共识，还要排除政治上的敌人。

总之，这本书是一个好书。道理要放在故事中才能够让人更容易接受，并且，能把道理成功的放到故事中也是非常厉害的。看这本书是一种享受。

企业IT结构

acAric 2017-04-04 0赞

虽然是讲一本运维的书，但是从整个书中可以看到整个企业的IT架构。

掌握整个企业流程，而非盲人摸象

作为一名技术人员，无论开发和运维，多多少少都会有一些极客思维，沉浸在技术的世界里。随处可见的产品和开发之间的矛盾就可见一斑。一个专业的技术人员应该自变为上帝视角，看到整个企业的流程，从订单到销售，再到生产，采购，财务等等，只有真正理解一个公司是如何运营的，才能真正理解技术是如何为企业服务的，才能真正做出契合用户的软件。如果仅凭个人的臆想，去设计功能，如此做出的软件基本上都是不堪入目。

迅速的从0到1，而非制造很多的0.5

书中反复讲到半成品，对比软件也是如此。相信很多人都在企业中看到，很多软件做到一半不做了，或者是快要推向市场时，总是不稳定，之后就无人问津！这就是一直在忙碌的制造0.5，从没有一个真正的1。半成品是无法推向市场的，无法实现营收，这就产生了极大的资源浪费。对比与一个人的工作也是如此，如果你手中有10件工作，你针对10件工作都完成了50%，这在上级看来，你是没有任何进展。而如果你聪明的完成了5件工作，这才是真正的完成了50%！！所以在任何时候，请专心制造1，而非很多个0.5.

开发到运维的一体化

运维和开发是息息相关的。中国的很多企业，运维基本都是由开发人员兼职去做的。证明运维在很多的企业是依附于开发的，这就导致很多开发人员一个错误的观念，运维相对于开发是不重要的。当然不要认为运维的技术含量小，因为你接触的运维不是真正的运维。运维是可大可小的，真正好的运维，能帮助开发省掉50%以上的工作。从自动化部署Jekins到Docker，再到zookeeper都有运维的影子。

部门间永远有冲突，分清是恶意还是无意

开发是一个需要团队通力合作才能成功的一件事，所以作为开发，基本上见识不到所谓的办公室政治。而一旦需要和别的部门进行合作，无论是较远的销售部，还是较近的运维部，一定会有冲突，这种冲突不一定会上升到办公室政治的地步，但是用冲突来定义是OK的。一旦遇到冲突，我们要首先定义，冲突是不是恶意。多数冲突而言，大家都是站在自己的立场上想做好这件事情，这种大家只要平心静气去解决就好！但是如果是恶意的推诿责任等等，那就需要你用自己的智慧去打赢这场战争，有人的地方就有江湖，不能指望自己在一片和谐的职场里步步高升！自然，很多时候，办公室政治不一定是拔刀相向的冲突，还有可能是冲你微笑的甜言蜜语。

技术储备

这是一个很虚无缥缈的话题，书中也可能根本没有提到。作为技术人员或者运维人员，在如今的时代里，技术储备都是不可或缺的。如果一个运维不能了解技术，就根本不知道如果做出更为人性化的自动化运维，慢慢沦落为一个网管。如果一个技术不了解运维，那么就没办法提前设计架构，做出来的软件就不能自动化处理，这是另一个悲剧。所以，无论作为哪一方面的从业人员，都要慢慢加强自己的技术储备，一旦放弃学习，一定会慢慢被这个时代所抛弃，特别是IT行业。

关于“布伦特”

布伦特是一个技术大咖，各种人员有问题都会找布伦特，布伦特也总能解决问题，所以越来越多的问题积攒在布伦特身上。在管理层的角度而言，布伦特确实不应该存在，因为他是部门效益的短板，太多问题只能依靠他。但对于个人而言，这是在某一阶段的好事，只有当你做到能“挟持”整个部门利益的时候，作为员工，算是半个成功了。当你到达如此地步，就要想想如何更近一步，如何脱离重复性的工作，让自己更近一步了。很多技术性人员到达这一步就止步不前了，很遗憾。更多的技术人员是还没到达这一步，就天天想入非非了，这更悲哀。

何止IT，所有部门都值得一读

小屁孩 2017-05-04 0赞

虽然这是一本运维的书籍，但我认为书中所讲述的道理同样适用于其他部门！接连不断的工作任务，日益缩紧的预算恐怕是大部分公司所有部门都面临的现状，大部分人都疲于应付日常的工作，只有很少人肯花时间思考，如何解决这种混乱，如何改变混乱，而不是迷失于其中。书中给我们指明了方法，相信仔细领悟，一定有所收获！

技术就是业务

Leven 2016-04-17 1赞

如果说一本书在被一套骨架支撑，然后肌肉包裹着骨架，最外面还有一层衣服包裹着肌肉，那这本书对我来说，更像是一个冬天装着羽绒服的大胖子。我从来都不喜欢看小说，根本耐不下心，所以觉得整书非常啰嗦，我想这本书也拉高了我阅读速度的平均水平，这本书的阅读速度是我最快的一本。
扯远了。
“技术就是业务”，公司高管鲁肃说过的一句话，印象很深刻，在这本书里更是有直观的表述。
随着互联网的发展，“IT”技术越来越成为业务发展的基础（IT之所以打引号，因为现阶段IT技术已经不是最核心的技术了，而是类云计算、大数据相关的，但都统称为IT技术吧），如果IT的发展跟不上业务的节奏，那公司也很难持续运转下去。
所以这本书，前面大幅章节在介绍IT有多么的苦逼，以及多么的不被重视，到第二部分，高人出来，通过指引让IT部门老大带领IT部门开始进行变革，变革带来的阵痛非常大，以至于IT老大都辞职了，然后到第三部分，IT老大被召回，变革开始有所成效，打法也更加的有章节，逐步的IT效率越来越高，到最后已经能够支撑起公司业务，并且推动公司业务发展，在行业内处于前列。
突然想起我们公司早期也是不重视技术，好像是11年左右才开始逐步重视起来，到现在跟外界拼的就是技术积淀，互联网技术的日新月异、更新换代，跟业务的发展有着直接的干系。
本书介绍了3步工作法，按我的理解，我认为是这3步：
1、确保互相依赖&协作的部门之间的工作流能够无缝衔接。如开发代码不断的在提交，但运维始终不能把代码部署上去，这就属于衔接出现了断节
2、部门之间出现问题，一定从找出问题源头，并从源头上解决问题。
3、养成习惯或氛围：不断的试错、实践，从实践中学习经验并成长。
这个工作法跟书中提到的约束理论有一定的异曲同工之处，即：在约束之外的任何地方做出的改进都是假象。
书中还提到计划外的工作，而且计划外的工作极具破坏性，破坏你计划内工作的进行。深有感触，如何管理计划外的工作，让他成为计划内的工作，是一门学问，掌握了这门学问，对工作效率必会有较大的提升。文中并没有关于此法的方法论，更多是根据实际情况去做改善，但如果日常工作中我们始终能够带着这个思路去管理自己的工作的话，相信会有所成效。
计划外的工作一定会有，但你必须高效的处理它。
另外感慨一下，文中拿工厂生产的例子来类比IT行业，并从中提出解决思路，都说隔行如隔山，但在高了看，其实解决问题的方法都是相似的。所以，以后持更加开放的心态，去了解身边朋友在不同行业是怎么工作的吧，相信会有所启发。

交付价值的it

liuwill 2016-10-06 1赞

凤凰项目确实是和《目标》一样的传奇故事。最近两年一直在思考Devops、持续交付、微服务，其实本质的思想，是回归常识的约束理论，虽然康威定律指出了现象，但是要怎么做，还需要高德拉特博士的思考方式。

正好在作者写这本书那年，没有任何先入之见时候看到目标和约束理论。之后一直用这种简单自然的思想观察世界、指导实践，看到凤凰项目，确定了正是“胖胖的小男孩贺比”作为主线在推动着从自动化构建到持续集成、容器这些技术和思想的演进。到现在devops已经是不需要争议的竞争优势，各种工具已经成熟，因为这个过程而产生的工具和方法已经像空气一样自然，思想却很少被提及。

正好2009年，还看过尼古拉斯卡尔的IT不再重要，云计算的到来，开发运维成本越来越低，企业可以更专注于业务。IT不再重要，因为每一个公司都在成为科技企业，IT已经是企业价值链的重要一环，不在是鼓励的解决局部的问题，局部改善只能让问题更糟，只有针对瓶颈整体优化，为最终用户交付价值。才是devops的意义。至于怎么做，当然不是工具或者方法的简单应用，只有像大野耐一教我们的那样，现场管理，这个是没有银弹的

不只是DevOps

mftian 2016-01-02 3赞

作为一个程序员，DevOps这个词并不陌生。2011年底我就看了《持续交付》，当时给我的震动很大。在AppAnnie我看到了持续交付是如何变为现实的，我觉得这是个非常棒的过程。

这本书的价值绝对不是在主角们做到了一天部署十次，而是在这之前的n章之中他们的痛苦和煎熬。一个烂摊子，一堆破事儿，没人没钱，怎么办？怎么限制工作量？怎么保护最能干的员工？最重要的是，怎么缩短交付周期，提高交付质量？

Bill在书的前半部分进展很慢，后半部分慢慢加快。他们在前半部分做了很多探索性的工作，很多尝试。每当我在看到Bill和他的两个下属开会讨论某个问题的时候，我都会停下来问问自己，这时候应该怎么办？DevOps虽然是终极的解决方案和目标，但是我们需要一步一步踏踏实实的向这个目标前进，步子迈得太大只会扯着蛋。仔细思考一下故事中的每个问题，每次会议，对自己都是一种锻炼。在真正的日常工作中，没人会像Eric一样给你耐心的提示。这本书就是我们每个人的Eric，而凤凰项目之于我们的日常工作的情况差别，就好像制造业生产线和凤凰项目的差别一样巨大。虽然情况千差万别，但是我们要做的就是从凤凰项目这样的案例之中找到像“三步工作法”或是“四种工作内容”这样的东西，来给自己启发。

小说体讲述IT的浴火重生

Qiao Liang 2013-03-04 4

对于中层管理者来说，的确是不错的小读本。因为书中描述的事情的确是现实生活中中层管理者遇到的具体问题（比如multi-taskng，unplaned work and Changes）。

早知道这本书的主导思想，所以刚开始，我并没有想认真的读下去，只是为了打发碎片时间（比如微博之类的时候）。
然而，这本书的情节的确吸引了我，尽管早就知道它的结局是什么样的，但还是好奇它的故事发展过程，所以就读完了。

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

透明 2016-01-18 3

它在这里：http://book.douban.com/subject/3871227/

并且它也不叫什么鬼《丰田管理》。它叫Toyota Kata好吗？“Kata”不知道吗？还搞个什么“改进型”，吓死我了好吗？

我们干这行的都管Kata叫“招式”好吗？

这就是个典型例证，折射出整本书翻译中的外行。你找俩会编程的人来翻译行吗？你找个负责点的编辑行嘛？就算你这些都不做，我的天，人家原书引用了几十本书，你能把参考文献列表留住吗？能吗？你把参考文献列表给删了，又把书名一通乱译，我得费多大劲才能找到里面提到的书你知道吗？

你真当我是来看小说的吗？

当然我不会因为这点小毛病就贬低这本书本身。书还是五星。不过我还是这么说：中国绝大多数的翻译作品，译者加上编辑一起，其作用就是让中国读者能花几十元人民币买到本来价值几十美元的书，并且尽他们的最大努力损害书的价值，使中国读者少占一点便宜。

不只是DevOps

mftian 2016-01-02 3

作为一个程序员，DevOps这个词并不陌生。2011年底我就看了《持续交付》，当时给我的震动很大。在AppAnnie我看到了持续交付是如何变为现实的，我觉得这是个非常棒的过程。

这本书的价值绝对不是在主角们做到了一天部署十次，而是在这之前的n章之中他们的痛苦和煎熬。一个烂摊子，一堆破事儿，没人没钱，怎么办？怎么限制工作量？怎么保护最能干的员工？最重要的是，怎么缩短交付周期，提高交付质量？

Bill在书的前半部分进展很慢，后半部分慢慢加快。他们在前半部分做了很多探索性的工作，很多尝试。每当我在看到Bill和他的两个下属开会讨论某个问题的时候，我都会停下来问问自己，这时候应该怎么办？DevOps虽然是终极的解决方案和目标，但是我们需要一步一步踏踏实实的向这个目标前进，步子迈得太大只会扯着蛋。仔细思考一下故事中的每个问题，每次会议，对自己都是一种锻炼。在真正的日常工作中，没人会像Eric一样给你耐心的提示。这本书就是我们每个人的Eric，而凤凰项目之于我们的日常工作的情况差别，就好像制造业生产线和凤凰项目的差别一样巨大。虽然情况千差万别，但是我们要做的就是从凤凰项目这样的案例之中找到像“三步工作法”或是“四种工作内容”这样的东西，来给自己启发。

你可以拥有的IT运维思维

风之子 2015-12-09 1

“有些书适合给你的朋友，为了分享阅读的喜悦；有的书适合给你的同事，为了建立理念的共识；有些书适合给你的老板，为了播下伟大的种子。而本书适用于以上三种情况。”这段话是对这本书最好的概括。作为一本融合IT专业性和通读性的书，它既有商业实战模式的真实企业故事，又能将IT运维的解决之道融入其中。

在这个“互联网+”的大时代，不管你是否IT从业者，都能感受到互联网行业越来越融入生活的气息。三个美国的IT从业者，Gene Kim 、Kevin Behr和George Spafford，结合多年的IT相关经验，站在一个管理者的角度讲述了IT运维的四种工作类型和三步工作法。众人拾柴火焰高。在各种说教式理论类丛书漫天飞的同时，三位作者能够耐得住性子，将自己的多年的从业经验，合力共聚为一本书。这本书的含金量自然可想而知。

与其说这是一本传授管理经验和工作秘诀的书，不如说它更是一本通识教育的书，书中讲述的IT运维思维具有普适性。本书通过主人公比尔·帕尔默临危受命被任命为IT运维部的副总裁，经历了4个多月的工作适应，遭遇工作瓶颈、办公室政治斗争，在贵人指点下掌握了IT运维的工作核心和秘诀。最终带领团队走出了困境，挽救了公司。虽然书中是以第一人称 “我”——IT运维部的副总裁，为主要的讲述对象，但故事里讲述的如何理清繁多的工作障碍，确定好工作优先级，将常规工作标准化等工作方法，适用于各行各业不同的从业者。

好书能在故事中寓意大道理。太多刻板枯燥的理论难以勾起阅读和学习的兴趣，但模拟实战的工作情况，对于读者来说更像一场感同身受的经历。不管是从事何种行业，工作效率是我们追求不变的宗旨。

制约工作质量和快慢的因素有很多，仔细想来，不论是一个企业团队的整体工作，还是对于我们个体，合理有序的工作流都是非常重要的。如何协调好自己和工作之间的这个最佳流程，建立起常规工作标准化机制，设置及时反馈响应机制，建立良好而共同的团队文化，突破工作中的制约点，这些都决定了你的工作质量。将书中的三步工作法拆解为与我们工作适用的内容，这是我阅读的最大收获之一。

书中的主人公比尔·帕尔默在工作陷入困境时，遇到了指点迷津的贵人，通过不断摸索、尝试，建立起适合自己团队的工作模式和方法。学会阅读这个故事，思考并总结故事中阐述的工作方法，灵活运用到自己的工作中，此书也就成了你自己工作中的贵人。

技术就是业务

Leven 2016-04-17 1

如果说一本书在被一套骨架支撑，然后肌肉包裹着骨架，最外面还有一层衣服包裹着肌肉，那这本书对我来说，更像是一个冬天装着羽绒服的大胖子。我从来都不喜欢看小说，根本耐不下心，所以觉得整书非常啰嗦，我想这本书也拉高了我阅读速度的平均水平，这本书的阅读速度是我最快的一本。
扯远了。
“技术就是业务”，公司高管鲁肃说过的一句话，印象很深刻，在这本书里更是有直观的表述。
随着互联网的发展，“IT”技术越来越成为业务发展的基础（IT之所以打引号，因为现阶段IT技术已经不是最核心的技术了，而是类云计算、大数据相关的，但都统称为IT技术吧），如果IT的发展跟不上业务的节奏，那公司也很难持续运转下去。
所以这本书，前面大幅章节在介绍IT有多么的苦逼，以及多么的不被重视，到第二部分，高人出来，通过指引让IT部门老大带领IT部门开始进行变革，变革带来的阵痛非常大，以至于IT老大都辞职了，然后到第三部分，IT老大被召回，变革开始有所成效，打法也更加的有章节，逐步的IT效率越来越高，到最后已经能够支撑起公司业务，并且推动公司业务发展，在行业内处于前列。
突然想起我们公司早期也是不重视技术，好像是11年左右才开始逐步重视起来，到现在跟外界拼的就是技术积淀，互联网技术的日新月异、更新换代，跟业务的发展有着直接的干系。
本书介绍了3步工作法，按我的理解，我认为是这3步：
1、确保互相依赖&协作的部门之间的工作流能够无缝衔接。如开发代码不断的在提交，但运维始终不能把代码部署上去，这就属于衔接出现了断节
2、部门之间出现问题，一定从找出问题源头，并从源头上解决问题。
3、养成习惯或氛围：不断的试错、实践，从实践中学习经验并成长。
这个工作法跟书中提到的约束理论有一定的异曲同工之处，即：在约束之外的任何地方做出的改进都是假象。
书中还提到计划外的工作，而且计划外的工作极具破坏性，破坏你计划内工作的进行。深有感触，如何管理计划外的工作，让他成为计划内的工作，是一门学问，掌握了这门学问，对工作效率必会有较大的提升。文中并没有关于此法的方法论，更多是根据实际情况去做改善，但如果日常工作中我们始终能够带着这个思路去管理自己的工作的话，相信会有所成效。
计划外的工作一定会有，但你必须高效的处理它。
另外感慨一下，文中拿工厂生产的例子来类比IT行业，并从中提出解决思路，都说隔行如隔山，但在高了看，其实解决问题的方法都是相似的。所以，以后持更加开放的心态，去了解身边朋友在不同行业是怎么工作的吧，相信会有所启发。

交付价值的it

liuwill 2016-10-06 1

凤凰项目确实是和《目标》一样的传奇故事。最近两年一直在思考Devops、持续交付、微服务，其实本质的思想，是回归常识的约束理论，虽然康威定律指出了现象，但是要怎么做，还需要高德拉特博士的思考方式。

正好在作者写这本书那年，没有任何先入之见时候看到目标和约束理论。之后一直用这种简单自然的思想观察世界、指导实践，看到凤凰项目，确定了正是“胖胖的小男孩贺比”作为主线在推动着从自动化构建到持续集成、容器这些技术和思想的演进。到现在devops已经是不需要争议的竞争优势，各种工具已经成熟，因为这个过程而产生的工具和方法已经像空气一样自然，思想却很少被提及。

正好2009年，还看过尼古拉斯卡尔的IT不再重要，云计算的到来，开发运维成本越来越低，企业可以更专注于业务。IT不再重要，因为每一个公司都在成为科技企业，IT已经是企业价值链的重要一环，不在是鼓励的解决局部的问题，局部改善只能让问题更糟，只有针对瓶颈整体优化，为最终用户交付价值。才是devops的意义。至于怎么做，当然不是工具或者方法的简单应用，只有像大野耐一教我们的那样，现场管理，这个是没有银弹的

awesome book

Vincent 2015-04-11 0

it's for everyone who works in IT Operation Team. not only we can learn the best strategy tackle down minor problem, but also provide a vivid pattern to narrow the gap between infra and Develop.

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

RexKang 2016-03-10 0

阅读本书的过程，让我感觉和阅读《三体》三部曲一样，前面有些平淡无奇，但是随着故事的发展，越看越兴奋，兴奋之后则是陷入深思。

这是一本少有的写到运维的小说，而且不缺技术，相反，涉及到技术的范围还很广。

本书的前一段内容我感同身受，各种各样的紧急工作、混乱的IT变更，而Bill来自的地方，则有着自己建立的IT变更管理，井然有序。或许所有的IT在前期的阶段基本上都面领着这样的问题。

而后来，面临着公司即将被拆分，IT业务被外包的局面，在Eric的指点下，Bill将运维、开发、业务聚集到一起，通力合作。感觉这种方式有着敏捷、DevOps的因子。

每一次变更成功，每一次故障的避免，都让我欣喜若狂，仿佛就是身边的事情。

尤其是看到Bill和Kris开始合作后，其实心中除了兴奋，还有一丝羡慕。

得知DevOps的概念时，大概是13年初（源自于《DevOps的各个阶段》）吧。当时网络上不少人都在高呼运维要下岗了，认识的一些运维攻城狮都人人自危。但是这么多年了，至少在我司中，干运维的还在干运维，基本没啥变化。搞软件开发的倒是自己做了些运维的工作——没办法，现在内部支持也要费用，能省点儿是点儿。
Bill自始自终都是作为一个副总裁，在自上而下的推动整个故事的发展。他为什么没有在原有的部门就将变更管理推广出来呢？自上而下很重要。
虽然没有ITIL工具的管理，仅仅利用看板，就能将如此多的变更管理得井然有序。而现实中，管理员们懒到极点，一个字段都不愿意填写，更别说写纸条了。
这么多年了，开发和运维从来没有通力合作过，往往是交接，而且只有交接，开发只是为用户服务，压根不考虑运维的事情，毕竟，考虑到安全、易运维的问题都会增加成本——又开始吐槽了。

或许本书中，开发、运维同属一个公司，有着共同的目标，而现实中的我们，只有盈利才是共同的目标，其他的——考虑那么多作甚？

一直在寻找的WOW

Nicolas 2017-02-04 0

这本书把我一直在寻找的一种工作方法，嵌入到了小说里面写出来。看到是一个字，爽.

但我一直忙于工作的时候。总会有一个想法在脑海里回荡，总觉得这，不是个办法，但又不知道怎么办。看了这本书，他仿佛像一个明灯，点亮了我前进的道路。

他从一个宏观的角度来去看待整个开发测试和部署运维整个流程。一直以来我都觉得，进行更高维度的系统化思维才是正确的，但是没有机会和办法在实践中运用起来获得经验. 看这本书，就像看一本，射雕英雄传。

但是从我的经验来看，一个思想要推广很难，首先你要让整个团队取得共识，还要排除政治上的敌人。

总之，这本书是一个好书。道理要放在故事中才能够让人更容易接受，并且，能把道理成功的放到故事中也是非常厉害的。看这本书是一种享受。

企业IT结构

acAric 2017-04-04 0

虽然是讲一本运维的书，但是从整个书中可以看到整个企业的IT架构。

掌握整个企业流程，而非盲人摸象

作为一名技术人员，无论开发和运维，多多少少都会有一些极客思维，沉浸在技术的世界里。随处可见的产品和开发之间的矛盾就可见一斑。一个专业的技术人员应该自变为上帝视角，看到整个企业的流程，从订单到销售，再到生产，采购，财务等等，只有真正理解一个公司是如何运营的，才能真正理解技术是如何为企业服务的，才能真正做出契合用户的软件。如果仅凭个人的臆想，去设计功能，如此做出的软件基本上都是不堪入目。

迅速的从0到1，而非制造很多的0.5

书中反复讲到半成品，对比软件也是如此。相信很多人都在企业中看到，很多软件做到一半不做了，或者是快要推向市场时，总是不稳定，之后就无人问津！这就是一直在忙碌的制造0.5，从没有一个真正的1。半成品是无法推向市场的，无法实现营收，这就产生了极大的资源浪费。对比与一个人的工作也是如此，如果你手中有10件工作，你针对10件工作都完成了50%，这在上级看来，你是没有任何进展。而如果你聪明的完成了5件工作，这才是真正的完成了50%！！所以在任何时候，请专心制造1，而非很多个0.5.

开发到运维的一体化

运维和开发是息息相关的。中国的很多企业，运维基本都是由开发人员兼职去做的。证明运维在很多的企业是依附于开发的，这就导致很多开发人员一个错误的观念，运维相对于开发是不重要的。当然不要认为运维的技术含量小，因为你接触的运维不是真正的运维。运维是可大可小的，真正好的运维，能帮助开发省掉50%以上的工作。从自动化部署Jekins到Docker，再到zookeeper都有运维的影子。

部门间永远有冲突，分清是恶意还是无意

开发是一个需要团队通力合作才能成功的一件事，所以作为开发，基本上见识不到所谓的办公室政治。而一旦需要和别的部门进行合作，无论是较远的销售部，还是较近的运维部，一定会有冲突，这种冲突不一定会上升到办公室政治的地步，但是用冲突来定义是OK的。一旦遇到冲突，我们要首先定义，冲突是不是恶意。多数冲突而言，大家都是站在自己的立场上想做好这件事情，这种大家只要平心静气去解决就好！但是如果是恶意的推诿责任等等，那就需要你用自己的智慧去打赢这场战争，有人的地方就有江湖，不能指望自己在一片和谐的职场里步步高升！自然，很多时候，办公室政治不一定是拔刀相向的冲突，还有可能是冲你微笑的甜言蜜语。

技术储备

这是一个很虚无缥缈的话题，书中也可能根本没有提到。作为技术人员或者运维人员，在如今的时代里，技术储备都是不可或缺的。如果一个运维不能了解技术，就根本不知道如果做出更为人性化的自动化运维，慢慢沦落为一个网管。如果一个技术不了解运维，那么就没办法提前设计架构，做出来的软件就不能自动化处理，这是另一个悲剧。所以，无论作为哪一方面的从业人员，都要慢慢加强自己的技术储备，一旦放弃学习，一定会慢慢被这个时代所抛弃，特别是IT行业。

关于“布伦特”

布伦特是一个技术大咖，各种人员有问题都会找布伦特，布伦特也总能解决问题，所以越来越多的问题积攒在布伦特身上。在管理层的角度而言，布伦特确实不应该存在，因为他是部门效益的短板，太多问题只能依靠他。但对于个人而言，这是在某一阶段的好事，只有当你做到能“挟持”整个部门利益的时候，作为员工，算是半个成功了。当你到达如此地步，就要想想如何更近一步，如何脱离重复性的工作，让自己更近一步了。很多技术性人员到达这一步就止步不前了，很遗憾。更多的技术人员是还没到达这一步，就天天想入非非了，这更悲哀。

我要写长评

想读在读读过

标签(多个标签以“，”分开):

保存

凤凰项目

推荐文章

猜你喜欢

附近的人在看

推荐阅读

拓展阅读