《凤凰项目》是一本由基恩·金 (Gene Kim) / 凯文·贝尔 (Kevin B著作，人民邮电出版社出版的平装图书，本书定价：CNY 49.00，页数：362，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。
《凤凰项目》读后感(一)：一直在寻找的WOW
这本书把我一直在寻找的一种工作方法，嵌入到了小说里面写出来。看到是一个字，爽.
但我一直忙于工作的时候。总会有一个想法在脑海里回荡，总觉得这，不是个办法，但又不知道怎么办。看了这本书，他仿佛像一个明灯，点亮了我前进的道路。
他从一个宏观的角度来去看待整个开发测试和部署运维整个流程。一直以来我都觉得，进行更高维度的系统化思维才是正确的，但是没有机会和办法在实践中运用起来获得经验. 看这本书，就像看一本，射雕英雄传。
但是从我的经验来看，一个思想要推广很难，首先你要让整个团队取得共识，还要排除政治上的敌人。
总之，这本书是一个好书。道理要放在故事中才能够让人更容易接受，并且，能把道理成功的放到故事中也是非常厉害的。看这本书是一种享受。
《凤凰项目》读后感(二)：如果你找不到《丰田管理》这本书……
它在这里：http://book.douban.com/subject/3871227/
并且它也不叫什么鬼《丰田管理》。它叫Toyota Kata好吗？“Kata”不知道吗？还搞个什么“改进型”，吓死我了好吗？
我们干这行的都管Kata叫“招式”好吗？
这就是个典型例证，折射出整本书翻译中的外行。你找俩会编程的人来翻译行吗？你找个负责点的编辑行嘛？就算你这些都不做，我的天，人家原书引用了几十本书，你能把参考文献列表留住吗？能吗？你把参考文献列表给删了，又把书名一通乱译，我得费多大劲才能找到里面提到的书你知道吗？
你真当我是来看小说的吗？
当然我不会因为这点小毛病就贬低这本书本身。书还是五星。不过我还是这么说：中国绝大多数的翻译作品，译者加上编辑一起，其作用就是让中国读者能花几十元人民币买到本来价值几十美元的书，并且尽他们的最大努力损害书的价值，使中国读者少占一点便宜。
《凤凰项目》读后感(三)：聚焦最大的瓶颈
烂摊子，没人没钱，怎么办？怎么用有限的人力显著地提高系统的质量？一个物理学家提出了一个简单理论：TOC
TOC（Theory of constraints），我更喜欢称之为瓶颈理论：任何系统至少存在一个制约因素/瓶颈，系统最终的产出受限于系统内部最薄弱的环节。要想显著提高系统的产出，就必须找到系统最大的瓶颈解决掉。所以，持续优化过程就是：
(1) 先找最大的瓶颈。
(2) 最高优先级地解决掉这个瓶颈。
(3) 然后再找新的瓶颈，重复上述步骤。
这个过程渗透着3个问题：应该在什么环节改善？改善应该带来什么成果？怎样推行改善？
我在百度工作的时候，大家都把自己的工作内容用便利贴粘到画板上，每项任务都需要提交申请，通过在画板上的需求栏、执行栏、完成栏之间移动便签纸呈现项目各个环节的状态，不仅让团队成员参与其中，还能清晰地展现出哪个环节最容易成为瓶颈。
书本上提到的三步工作法，按我工作经验理解就是：
(1) 确保工作流水线不要中断。比如，需求、开发、测试、小流量实验以及推全这些环节中有一个中断了，那就降低了整体的效率。
(2) 出现问题，就要找到问题的源头，从根源上解决掉。比如，线上出BUG，根源很可能是系统code混乱到需要重构，不只是测试的问题。
(3) 持续地尝试改进系统，不要把全部人力用在功能开发上，留有20%人力改进非功能性需求。
《凤凰项目》读后感(四)：企业IT结构
虽然是讲一本运维的书，但是从整个书中可以看到整个企业的IT架构。
掌握整个企业流程，而非盲人摸象作为一名技术人员，无论开发和运维，多多少少都会有一些极客思维，沉浸在技术的世界里。随处可见的产品和开发之间的矛盾就可见一斑。一个专业的技术人员应该自变为上帝视角，看到整个企业的流程，从订单到销售，再到生产，采购，财务等等，只有真正理解一个公司是如何运营的，才能真正理解技术是如何为企业服务的，才能真正做出契合用户的软件。如果仅凭个人的臆想，去设计功能，如此做出的软件基本上都是不堪入目。
迅速的从0到1，而非制造很多的0.5书中反复讲到半成品，对比软件也是如此。相信很多人都在企业中看到，很多软件做到一半不做了，或者是快要推向市场时，总是不稳定，之后就无人问津！这就是一直在忙碌的制造0.5，从没有一个真正的1。半成品是无法推向市场的，无法实现营收，这就产生了极大的资源浪费。 对比与一个人的工作也是如此，如果你手中有10件工作，你针对10件工作都完成了50%，这在上级看来，你是没有任何进展。而如果你聪明的完成了5件工作，这才是真正的完成了50%！！所以在任何时候，请专心制造1，而非很多个0.5.
开发到运维的一体化运维和开发是息息相关的。中国的很多企业，运维基本都是由开发人员兼职去做的。证明运维在很多的企业是依附于开发的，这就导致很多开发人员一个错误的观念，运维相对于开发是不重要的。当然不要认为运维的技术含量小，因为你接触的运维不是真正的运维。运维是可大可小的，真正好的运维，能帮助开发省掉50%以上的工作。从自动化部署Jekins到Docker，再到zookeeper都有运维的影子。
部门间永远有冲突，分清是恶意还是无意开发是一个需要团队通力合作才能成功的一件事，所以作为开发，基本上见识不到所谓的办公室政治。而一旦需要和别的部门进行合作，无论是较远的销售部，还是较近的运维部，一定会有冲突，这种冲突不一定会上升到办公室政治的地步，但是用冲突来定义是OK的。一旦遇到冲突，我们要首先定义，冲突是不是恶意。多数冲突而言，大家都是站在自己的立场上想做好这件事情，这种大家只要平心静气去解决就好！但是如果是恶意的推诿责任等等，那就需要你用自己的智慧去打赢这场战争，有人的地方就有江湖，不能指望自己在一片和谐的职场里步步高升！ 自然，很多时候，办公室政治不一定是拔刀相向的冲突，还有可能是冲你微笑的甜言蜜语。
技术储备这是一个很虚无缥缈的话题，书中也可能根本没有提到。作为技术人员或者运维人员，在如今的时代里，技术储备都是不可或缺的。如果一个运维不能了解技术，就根本不知道如果做出更为人性化的自动化运维，慢慢沦落为一个网管。如果一个技术不了解运维，那么就没办法提前设计架构，做出来的软件就不能自动化处理，这是另一个悲剧。 所以，无论作为哪一方面的从业人员，都要慢慢加强自己的技术储备，一旦放弃学习，一定会慢慢被这个时代所抛弃，特别是IT行业。
关于“布伦特”布伦特是一个技术大咖，各种人员有问题都会找布伦特，布伦特也总能解决问题，所以越来越多的问题积攒在布伦特身上。 在管理层的角度而言，布伦特确实不应该存在，因为他是部门效益的短板，太多问题只能依靠他。但对于个人而言，这是在某一阶段的好事，只有当你做到能“挟持”整个部门利益的时候，作为员工，算是半个成功了。当你到达如此地步，就要想想如何更近一步，如何脱离重复性的工作，让自己更近一步了。 很多技术性人员到达这一步就止步不前了，很遗憾。更多的技术人员是还没到达这一步，就天天想入非非了，这更悲哀。
《凤凰项目》读后感(五)：运维的蜕变，很有参考意义。
阅读本书的过程，让我感觉和阅读《三体》三部曲一样，前面有些平淡无奇，但是随着故事的发展，越看越兴奋，兴奋之后则是陷入深思。
这是一本少有的写到运维的小说，而且不缺技术，相反，涉及到技术的范围还很广。
本书的前一段内容我感同身受，各种各样的紧急工作、混乱的IT变更，而Bill来自的地方，则有着自己建立的IT变更管理，井然有序。或许所有的IT在前期的阶段基本上都面领着这样的问题。
而后来，面临着公司即将被拆分，IT业务被外包的局面，在Eric的指点下，Bill将运维、开发、业务聚集到一起，通力合作。感觉这种方式有着敏捷、DevOps的因子。
每一次变更成功，每一次故障的避免，都让我欣喜若狂，仿佛就是身边的事情。
尤其是看到Bill和Kris开始合作后，其实心中除了兴奋，还有一丝羡慕。
得知DevOps的概念时，大概是13年初（源自于《DevOps的各个阶段》）吧。当时网络上不少人都在高呼运维要下岗了，认识的一些运维攻城狮都人人自危。但是这么多年了，至少在我司中，干运维的还在干运维，基本没啥变化。搞软件开发的倒是自己做了些运维的工作——没办法，现在内部支持也要费用，能省点儿是点儿。
ill自始自终都是作为一个副总裁，在自上而下的推动整个故事的发展。他为什么没有在原有的部门就将变更管理推广出来呢？自上而下很重要。
虽然没有ITIL工具的管理，仅仅利用看板，就能将如此多的变更管理得井然有序。而现实中，管理员们懒到极点，一个字段都不愿意填写，更别说写纸条了。
这么多年了，开发和运维从来没有通力合作过，往往是交接，而且只有交接，开发只是为用户服务，压根不考虑运维的事情，毕竟，考虑到安全、易运维的问题都会增加成本——又开始吐槽了。
或许本书中，开发、运维同属一个公司，有着共同的目标，而现实中的我们，只有盈利才是共同的目标，其他的——考虑那么多作甚？
《凤凰项目》读后感(六)：不只是DevOps
作为一个程序员，DevOps这个词并不陌生。2011年底我就看了《持续交付》，当时给我的震动很大。在AppAnnie我看到了持续交付是如何变为现实的，我觉得这是个非常棒的过程。
这本书的价值绝对不是在主角们做到了一天部署十次，而是在这之前的n章之中他们的痛苦和煎熬。一个烂摊子，一堆破事儿，没人没钱，怎么办？怎么限制工作量？怎么保护最能干的员工？最重要的是，怎么缩短交付周期，提高交付质量？
ill在书的前半部分进展很慢，后半部分慢慢加快。他们在前半部分做了很多探索性的工作，很多尝试。每当我在看到Bill和他的两个下属开会讨论某个问题的时候，我都会停下来问问自己，这时候应该怎么办？DevOps虽然是终极的解决方案和目标，但是我们需要一步一步踏踏实实的向这个目标前进，步子迈得太大只会扯着蛋。仔细思考一下故事中的每个问题，每次会议，对自己都是一种锻炼。在真正的日常工作中，没人会像Eric一样给你耐心的提示。这本书就是我们每个人的Eric，而凤凰项目之于我们的日常工作的情况差别，就好像制造业生产线和凤凰项目的差别一样巨大。虽然情况千差万别，但是我们要做的就是从凤凰项目这样的案例之中找到像“三步工作法”或是“四种工作内容”这样的东西，来给自己启发。
《凤凰项目》读后感(七)：做好运维有方法
比尔临危受命，被CEO任命为IT运维部副总裁，并要求一定要完成凤凰项目。刚上任因为历史遗留问题工作上总是出现各种各样严重问题，然后他就想办法改变这种现状。做凤凰项目过程中，CEO不让招人、不花钱买设备，业务部门又步步紧逼，强制让项目时间提前上线，结果损失严重。在比尔迷茫时遇到一位世外高人艾瑞克，艾瑞克给他指导方向，教他三部工作法，四类工作类型等等。功夫不负有心人，经过艰难的改进、创新，最终完成了凤凰项目，创造了奇迹，并受到了CEO的赏识。
这本书作者写的很精彩，看到书中的一些场景，让我想起了往昔的苦逼岁月。刚开始做运维工作时，开发、业务那边很强势，自己很憋屈，比如：制定好的规则和流程形同虚设；新项目上线总是等到最后一刻才告知；生产环境有问题总说是运维问题，因为在他们本机测试是正常的；部署文档及其简单，不知所以然......因此，书中比尔每当遇到抓狂的问题时，我感同身受。里面的解决方法部分是我已经做过的，很认同，同时也学习了很多。
列几点书中的精彩部分。
1、约束点，即瓶颈。
布伦特是个技术牛人，很多问题只能他来解决。当出现计划外意外问题时，救火工作会占用他大量时间，因此计划内的工作常常耽误。
如何解决约束点问题？
第一步，确认约束点。假如约束点找错了，无论做什么都无济于事。对非约束点的任何改进都只是幻觉。
第二步，利用约束点，就是确保不让约束点浪费任何时间。永远不要让约束点迁就别的资源而干等着，而是应该专注于IT运维部对当前所需完成工作中优先级最高的那一项。计划外工作会让你丧失开展计划内工作的能力，因此必须不惜一切代价去消灭计划外工作，墨菲法则确实存在，因此总会有计划外工作，但你必须高效的处理它们。
第三步，把约束点置于次要地位。队伍里最慢的A君决定了整支队伍的行军速度，为了防止队伍拉大距离，要把A君调到队伍的最前面。A君是约束点，要保证其他人的速度和他的速度一致。根据约束点来控制工作节奏。
第四步，相比于向系统中投入更多的工作，将无用的工作剔出系统更为重要。
第五步，增加节点，经过更多的环节流向约束点。
2、三步工作法
第一工作法，从开发部移向IT运维部时该如何建立快速工作流。做法：用持续交付。
第二工作法，如何缩短及放大反馈环路，从而在源头上解决质量问题，避免返工。
做法：在部署管道中失败就停止；日复一日的持续改进日常工作；在开发和运维之间建立共同的目标和共同解决问题的机制；让每个人都知道，代码和环境是否在按照设定的运行，以及是否达到了客户的目标。
第三工作法：如何建立一种文化，既能鼓励探索、从失败中吸取教训，又能理解反复的实践是精通工作的先决条件。
3、四类工作类型：
1 业务项目,开发部所做的公司项目。
2 IT内部项目，为了业务项目而产生的运维内部项目，如部署自动化、监控。
3 变更，经常由上述两种类型引起，会出现问题，交接工作时问题最多。
4 计划外工作或救火工作，包括操作事故和操作问题，通常由上述三种类型的工作导致，而且往往以牺牲其他计划内工作为代价。
4、看板方法
看板方法它是工作任务的可视化管理，每项任务处于何种状态（“待办”、“在办”、“已办”）一目了然。如果在看板图上，就要迅速完成。
半成品（即在办状态）是个隐形杀手，要减少半成品。（半成品是引起长期性交货期限问题、质量问题以及导致督办员每天都得调整优先级的根源之一）
5、资源忙碌百分比
资源忙碌百分比图标显示，等待时间是工作中心中某个资源忙碌程度的函数。艾瑞克用这张图表来说明为什么布伦特的30分钟简单变更要耗费几个星期才能完成。原因很显然，作为所有工作的瓶颈，布伦特的使用率一直是100%甚至超过100%，因此，每次交给他的工作都只能在队列里苦等，如果不进行加速或升级处理，就永远不会完成。不知道这幅图的来历，有人认为这幅图是李特尔法则的简化版本。
书中强调了持续交付的重要性，比尔团队因为实现了它并创造了好几个项目的奇迹。它不是小说里随便写写凭空想象出来的，而是真实情况的体现，的确很有效果。如今在运维的世界里DevOps很流行，它是持续交付的实现并延伸。我们强调重复的操作用机器来实现，每次相同的操作必然得到同一个结果，不出现任何意外。在处理重复无聊的事情上，机器确实比人靠谱多了。
是一本好书，推荐给所有的IT从业者，相信读完它你会有很多收获。
《凤凰项目》读后感(八)：交付价值的it
凤凰项目确实是和《目标》一样的传奇故事。最近两年一直在思考Devops、持续交付、微服务，其实本质的思想，是回归常识的约束理论，虽然康威定律指出了现象，但是要怎么做，还需要高德拉特博士的思考方式。
正好在作者写这本书那年，没有任何先入之见时候看到目标和约束理论。之后一直用这种简单自然的思想观察世界、指导实践，看到凤凰项目，确定了正是“胖胖的小男孩贺比”作为主线在推动着从自动化构建到持续集成、容器这些技术和思想的演进。到现在devops已经是不需要争议的竞争优势，各种工具已经成熟，因为这个过程而产生的工具和方法已经像空气一样自然，思想却很少被提及。
正好2009年，还看过尼古拉斯卡尔的IT不再重要，云计算的到来，开发运维成本越来越低，企业可以更专注于业务。IT不再重要，因为每一个公司都在成为科技企业，IT已经是企业价值链的重要一环，不在是鼓励的解决局部的问题，局部改善只能让问题更糟，只有针对瓶颈整体优化，为最终用户交付价值。才是devops的意义。至于怎么做，当然不是工具或者方法的简单应用，只有像大野耐一教我们的那样，现场管理，这个是没有银弹的
《凤凰项目》读后感(九)：与其说是关于DevOps的书，不如说是关于管理的书
IT很重要
这是此书要传递的一个重要信息。在快速更新和需要提高24*7服务的今天，运维的确变得比以往更重要。但哪个角色又不是呢？设计部门常抱怨自己的想法得不到实现，QA抱怨常常背黑锅......听说过没见过的DevOps提倡的打破Dev和Ops之间的壁垒，在此书中体现的并不多。略翻了下《SRE: Google运维解密》，似乎也是主要讲运维团队。开发团队去哪儿啦？其实小团队中，开发基本把运维的事就包了。把部署作为代码的一部分，尽可能自动化，根据运维状况进行调优，迅速更新和排错，都要求IT人员和开发人员的深度参与。所谓的壁垒，是否就是这些角色不在同一团队引起的？
TOC
这才是本书的重点。以最有价值的目标为导向，找到核心问题和瓶颈问题并解决。其实换一个部门，略微修改下，估计也会把这个故事讲下去。
部门合作
这似乎是这个项目中的最大屏障，包括一些办公室政治。当然在现实中，这也往往是事实。所以很多经理主管不得不花很多精力在这些看起来不直接产生价值的会议，争吵和手段上。
对于生产的方法论很多，继流行日本的理论后，估计来自于中国的实践理论在将来也会推广。关于部门合作方面，华为的执行力就值得学习。
外场会议
书中的CEO在多数时候并没突出表现。然而举行外场会议，承认自己的错误并及时修正，而且知道创建一个相互信任的团队的重要性。就这两点来看，的确是有领导才能。要知道，绝大多数领导是做不到这点的。这个做法，是来自于书中推荐的《团队协作的五大障碍》
布伦特
主角的名字还不如这个印象深。因为被提及的太多。一个IT工程师，扫地僧似的存在，自由电子般的问题终结者，“一个优秀的工程师胜过100个平庸工程师”说的就是这样的人。他们往往也成了瓶颈。
从组织来讲，这就是典型的项目被人绑架。实际中，也有很多类似的优秀工程师，但没达到传奇的地步，因为老是困于一个项目，从而也逐渐平庸起来，离开自己的项目会做的就很少。成了人被项目绑架。
改变这种最后双输的情况，需要魄力和一点冒险精神，因为人们总是倾向保险的做法和安于现状。
另外更重要的是，能识别布伦特和用好这样的人。
《凤凰项目》读后感(十)：这是一本项目管理的书，跟DevOps没什么关系
1 - As titled...
2- 翻译很烂，常常需要根据中文来猜英文，往往联系上下文觉得终于明白了是什么意思的时候有一张“翻译，你出来我们俩聊聊，我保证不打死你”的冲动
3- 故事其实就是记录一个传统的运营团队如何转变成为一个agile的团队，并在struggle中如何琢磨出了一套适合自己的agile的工具，对于参加过这么多次agiletraining的我来说，这些理念实在太小儿科，有时候读着读着会自己笑出来，觉得在浪费时间，
4- 小说其实写的很啰嗦，神一样的Eric在现实生活中不会存在，其实换个角度，他更像一个agile的coach，目前的市场上，agile已经是一个很成熟的体系，市面上各种coach，training， 以及书籍，完全不用像书中描述的那样通过一个又一个的mess来琢磨出一套agile的工具集，所以对于大多说的IT从业者来说，直接去读一本agile的书，或许收获会更大。
5- ‘比一名开发人员更危险的就是开发人员和信息安全部门的人联手。这样的组合把给我们添乱的动机、手段和机会都弄齐全了’ 黑的漂亮
6- 四类工作 ： 业务项目，内部项目，变更，以及计划外工作。我虽然没有完全明白他所谓的变更，但是我同意这种分类方法，我觉得变更这个事情或许会更加针对DevOps一些，而对于一个普通的project team来说，更多的是剩下三种类型的工作