作者:基恩·金(GeneKim)/凯文·贝尔(KevinBehr)/乔治·斯帕福德(GeorgeSpafford)
格式: PDF, TXT, EPUB, MOBI, AZW3, DOCX
网友评价：
- a ha moment
- 三步工作法，实际上是一个不断改进，不断迭代，将这种思考由表及里的过程。当你感觉自己忙的不可开交，焦头烂额的时候，不防试一试三步工作法的方式。先了解整体的情况，清楚自己的约束点，工作类型等问题，之后快速的建立回馈，与第一步形成环路，当这套流程稳定之后，要将这个流程养成习惯，做到良性循环。
- 这本书是我最近读过还小做了下笔记的书，值得纪念。
- 前半部分看的冷汗淋漓，但是后半部分也太理想了
- 作为项目管理人员，约束点的理论对我启发很大。同时，包括安全审计在内所有企业工作都应该追溯回企业最核心的业务价值。另外，很认同最后关于所有未来的企业管理者都必须了解IT的观点。
- 用故事的细节让你体会到没有运维哲学devops的情况下，IT基本就是一锅粥，故事情节有落俗的一面，但是作为技术闲书来看还是不错的，可以边看边思考，结合自己公司研发运维的实际情况分析一下，从逻辑的角度出发，我们做事慢甚至事与愿违，根源或许是方法论有问题
- 相信很多公司都遇到了类似甚至更严重的问题，这个时代企业没有IT/数据/智能 就无法立足
- 好看，但过于理想，也过于直白的为it人争取利益。
- 故事性高出预期，引人入胜。许多理念与场景虽不适用或有过时之嫌，整体而言仍受益匪浅
- 说实话没有在这种传统大型IT公司转型期呆过，没有特别深的体会。 不过赞同瓶颈论和管理一个大型IT项目（非探索性）和大型传统制造业有相似的地方。
- 让我从另一个角度思考现在的工作
- 内容值得五颗星，让我对项目管理，乃至于更广义的管理有了一些基本概念。只是翻译实在问题颇多，最好还是看英文版吧。
- 六星好书! 虽然有些翻译腔, 但并不影响理解!
- 真实写照，值得一看
- 运维工作实践，好书值得读
- 《凤凰项目》是一本知名的敏捷开发趣味入门书。前半部分比较贴近实际，领导既要又要，还不加资源，结果项目失败了。后半部分有些散乱，想要学习DevOps系统的方法论还得看其他的书。本书最大的作用就是告诉读者，软件工程与工厂制造的相似之处，要采用「精益生产」，其核心就是全流程运转零库存，把产品项目在流水线上转起来，无论是开发、测试还是部署都按一定节拍在运转，源源不断。
- 一周目; 没有太仔细看, 我不太喜欢这种通过 讲故事 的方式, 来顺带讲知识的套路; 不过书中还是给了我一些启示; 书中提到的一些书籍和理论, 我觉得值得借鉴和学习;
- 花2天时间，一口气读完了，很赞。虽然有些翻译上的细节有问题，但也不用在意。
- 通过故事深入理解DevOps。DevOps经典，所谓凤凰涅槃，浴火重生。英文版和周边阅读团队的五个障碍还有其他这款英文书都可以在Queue找到
- 当你要接手一家ITOM公司，而你并无法感知什么是DevOps的时候…书还是比较浅的，更像给完全不知道IT部门在干嘛的人（比如我）在bar里吹水，但的确是很直观的感受。看完之后回想起之前order mgmt项目想要改industry mall和订单系统，就觉得真是任重而道远呀，果然还是需要一把手的支持
- 30章讲项目，变更管理；3章讲devops，明显是想蹭热度.
- 过于真实，引起不适。
- 我怎么感觉他们面对的情况只要上了云就迎刃而解了。
- DevOps布道书，故事还挺不错的。不过对比国内，企业不会给你那么多时间试错吧。往往只能做锦上添花做不了雪中送炭。
- 读过后，可以了解2010年左右的运维状态
- 也许是因为我并不是IT从业者，所以读这本书的时候有一些概念和工作方法没办法领悟得很透彻。不过主人公的诚恳而又有态度的性格我还是很喜欢的。
- 对于IT从业者而言是一部不可多得的好书。不光聚焦于IT本身的工作，也把视角拔高到公司总经理的全盘考虑的层级。使人意识到现如今IT是如何深刻影响一家公司，并且如何使它“拨乱反正”，越来越好。同时其中特别提到的开发运维思想，也十分受益。此书还有19年版的修订版，可以兼顾一起读完，加深理解。
- 很棒的故事。可惜的是，最后那段介绍的持续交付，需要相当高的技术能力。所以，雇不起优秀的技术人才、玩不转docker的企业，就只能眼睁睁看着比自己强且敏捷的对手屠杀自己，毫无反抗可能性。
- 当一个资源使用了99%，那么等待时间就是该资源使用50%时的99倍。
- 断断续续看了一年时间，才几近看完。某些段子真的深刻戳中了从业者的笑点，每次看，每次都要笑死了，笑着笑着就哭了出来，太难了。。。
- 实现“开发运维”的极简理想版。看过后，对照身边现实，想到领导口中的当热点使用的名词，笑而不语。可以顺着推荐书目走下去。 我看不动《扫地出门》才用这本替代的。我已没情感。
- 知道了很久，今天才细细读完，惭愧惭愧……每个IT人必读
- 读过了第二本 IT 相关的小说，上一本是经典的《目标》 一直有人来找我交流 DevOps 的经验，才发现我们是顺其自然达到了别人想到的终点。现在回想起来我们更多还是 Infra 和 Product 相关工程团队的思路一致，力出一孔。很多事情就做成了。 最近在思考 DevOps 2.0 的事情，前后延展更长的 Pipeline，处处及时反馈，可视化，指标化，准备把《DevOps实践指南》找来读读。
- 限制正在处理任务的数量，这条真得作为现代企业人人遵守的准则，无限制的添加任务，最终会造成所有任务都无法办结。这本写于12年书，讲的很多原则现在非常流行，像微服务、自动运维、一键发布等都是这些理念的具体实现，书中用具体的故事将IT开发运维流程中的问题展现出来，很有现实指导意义。
- 不拍成剧可惜了
- 专业吐槽啊哈哈哈
- 自动化，尽量屏蔽计划外工作。向前，反馈，持续学习
- 作者强行营造紧张感，毕竟作者不是技术出身，虽然尽力模拟出IT项目的里面的场景，但依然是说得很空泛。两小时读完这本书，刷新了我的阅读速度。另
- it 职场小说，册子有点厚；人物背景设定基本可信，男主这差点。从侧面也感受到直觉到理论的差距。像流一样，减少阻碍、加固环节、单向前进、增大流量、降低负荷，前后反馈及时到位。
- 书的内容不错,不过翻译的有点怪,读完老觉得哪里不对
- 又一本IT小说，自从约束理论(TOC)创始人高德拉特自1992年出了《目标》一书之后，国内外很多IT人都开始以讲故事的方式讲解IT知识，这类的小说很多，但是都有一个类似的套路，就是在旅途中被伯乐识到，委以重任(当然，只能是CIO)，新官上任不是三把火，而是当头一喝，先蒙圈，秉承着两个不会(这也不会，那也不会)的原则，然后遇到高人，经过高人指点，功力大增，所向披靡，问题解决，解决问题过程中必有一得力干将，然后自己升了CEO,干将接自己班，以大团圆结尾。可参考以下书目，排名不分先后:讲约束理论的以色列的高德拉特的六本书;法国的伯乐兄弟讲精益生产理论的《金矿1,2》;刘宗昌的《精益的传说》;供应链理论方面的有程晓华的《决战库存》，杨臻的《蜘蛛-物流战略高管手记》，奥英德五人联名的《首席采购官》等。
- 真是神书啊，简直就是我们部门。
- 第一步从左到右按部就班，第二步从右到左反馈试错，最后树立品牌
- （1）四种工作类型：业务项目；IT内部项目；变更；计划外工作或救火工作。（2）约束点（3）IT工作可视化并控制半成品
- 这本书的优秀之处就是无比真实且充满细节地还原了IT一片混乱的日常，让读者完美代入，仅仅这一点就完爆那些只讲理论的书籍。但是，暴露问题看起来爽，后面主角的问题解决也太顺利了，简直开挂+主角光环，书中实际的解决方法我认为有点模糊，套不到我们的项目中。最后为另一本书devops打广告…难道真正答案在那里？我去研读一下。
- 除了对其中介绍的三步工作法和四种IT工作感到赞同外，还有被这种to C公司的工作热情和紧迫度感震撼到！法国这边银行內部IT的常态就是，即使production down了，也不能耽误按时下班的！想要周六加班？经理要求人求半天才能来半个人的。如果关键的组件出问题了，给内部全体发一个邮件说我们正在investigate就行啦^^
- 作者写了一本30万字的小说，描述中古时代（10年前）的it人是怎么做运维的。 作者近乎布道的方式推广“开发运维”模式。一些当时的先进方法，经历了发展，成熟，淘汰，一些基础的概念，至今适用，书中令人困扰的环境和部署问题，现在基本被容器技术解决了，书中每一个故障，会议，变更，都能让人会心一笑[微笑] 时隔三年又看了一遍这本书，体验完全不一样了。#知道怎么来的，才能探索未来的方向#
- 我不喜欢看外国小说的一个原因就是我实在记不住一堆人名，往往到最后我都不知道这个人是干吗的了... PS. 把code base翻译成"代码基数“这样真的好吗？？？
- 里面很多真实案例可以借鉴到工作当中，以幽默的语气娓娓道来！
- 想起上上周四彻夜电话会议上的引爆点，上周一整周处于各种救火状态，在这个时间看凤凰项目有特别的感触。有那么多最近或几年前踩过的坑，会心苦笑，有那么多有幸引入敏捷看板新型生产力工具绕过的坑，看完更知道当时的方法论是怎么来的。devops之外，作者对于业务与it的关系，不就是现在流行的企业数字化转型。一星扣给威廉出场太少了，这是来自QA的执念
- 小说写的不错，技术名词翻译的头大。很好看。
- DevOps培训推荐教程，配合凤凰沙盘效果更好！全部自动化流水线目前落地难度偏大，当做一本运维小说看还是不错的
- 与其说是一本关于DevOps的书，不如说是一本关于管理的书
- 先抑后扬的节奏，问题在于抑的部分过于真实不忍卒睹，扬的部分太过戏剧化又不够真实，但是作者把管理书籍小说化的思路和笔力值得4星。
- 10年+运维，醍醐灌顶。确实和工厂流水线有着异曲同工，发现并改善约束点，加之DevOPs&Automation提高了IT的工作流，大幅提升IT在业务中的价值。
- 不习惯这种故事类的专业文章，特别是外国人名字都很长。。 但却是是一个回顾自己工作的机会，重新评价自己的工作习惯
- 想打十颗星。干货太多，不止于IT运维、个人管理、项目管理。
- 一直以来我就有一个问题，为什么战胜拖延症的小组里面堆满了文科老博士，是他们的智力心理的问题，还是他们工作的性质问题。后来灵思风关于真正的魔法是不可分解的理论让我获得了很多自信心。而这本书更告诉我，原来那么大，涉及到那么多用户的产业同样如此困难地（有些人甚至不感到困难）的面对着这个问题；一些些自我厌恶和怀疑我还是能应付的！
- 用故事形式把一个复杂的管理流程说的通俗易懂而且很富有实践性。
- 从救火到喝着咖啡变更的过程
- 用一个故事讲述Dev与Ops之间的矛盾以及如何解决，扣人心弦又发人深思，非常棒。
- “马桶读物”
- 我没想到 IT 运维管理也能写成一部小说，还兼具项目管理这个让无数人倒下过的坑的描绘。
- 刚开始觉得小说化还不错，看到 60% 就觉得冗长。 技术观并没有学到什么知识，倒是书中的政治斗争很有趣。
- 2000年左右，制造业自己在IT基础架构设计运维开发过程中的思考。以前总是i觉得制造业，作为传统企业，对于现代科技企业没有太多的借鉴意义。殊不知，早发展了数十年的企业，同样给了我们很多启发，尤其是在IT技术发展到拐角，需要变革的时候更是给了决定性的启发。很震惊，也很合理。 在里面，看到很多我们2020年企业依然存在的问题，却也能看到解决的方向，太多需要我们去探索和实践的东西。
- 实体书；家中；
- 很不错的小说，公司it管理的科普读物
- 姊妹篇《独角兽项目》都出版了：https://book.douban.com/subject/35424121/。同样的公司，有点大女主故事的赶脚。
- 通过一个商业故事讲述技术话题，引人入胜，结局竟然是IT人的爽文
- 软件项目管理教学+IT职场爽文...
- 如何让IT融入管理，成为真正的生产力，看看这本书，你就知道了。满分！
- 实践DevOps的第一步，就是先让你的工作可以看得见。在瓶颈之外的任何改进都是无效的。可以把整个工作流程想象成是一个水管里的水流，最后决定流量的不是最粗的部分，而是最细的部分。任何有效的改善都是对瓶颈的改善。遇到问题自己先来解决，这样做不是在追责，而是为了让任务可以更快地交给下游，减少库存。避免首席工程师总是解决相同的问题。这是在减少任务对瓶颈点的依赖，通过初级工程师来进行分流。这件事不只是初级工程师的责任。第二步其实有两方面，反馈和改善，反馈是对上游的反馈，改善是对下游的改善。第三步，建立起持续学习的文化。当每个部门都在努力对自己的目标负责时，就可能会出现困境。不应该对造成故障的人进行责备和羞辱，而是应该把错误当作重要信号，最大限度地抓住学习的机会，持续交流日常工作中的问题。
- 真的很不错，不过里面描述的太原始了
- IT很重要，IT不是一个可以轻易委托外包的部门。公司的每一项重大活动都有IT的参与，而且IT对日常运作的方方面面都起到关键作用。
- 今年看过最让我深思的书，关于延伸阅读也让我十分感兴趣，建议更多的人能够读一读这本书，能够让你在工作中的感悟更加确切和透彻
- 好奇多少devops给这本书打了五星
- 虽然不是IT行业的但光从项目管理角度读下来也收获颇丰。
- 一般，运维devops，和之前高德拉的书内容很像，IT部门还是挺重要的，开发需要紧密合作
- 第一本跟项目管理 devops有关的书 真不错 一下子就可以带入情景 不过里面的知识跟使用技巧还得再学习学习。研究研究
- 最后结尾的时候屌丝yy了一把。devops实践参考书籍，入门合适。
- IT与业务相辅相成，读完这本书我才意识到IT对于业务的影响如此之大，IT的生产力显然应该列入当代公司的议程之上。 在IT开发运维过程中，最重要的是如何寻找关键约束点以提高生产力，降低发布风险以保证业务安全，把知识很好地在留存在团队之中。总而言之，需要一套合理的制度和流程来达到我们的目标，这需要不断地实践以及团队无间的合作。
- 流动原则 反馈原则 持续学习与实验原则 半年读过的优质图书 下一本继续DevOps主题 《DevOps实践指南》
- 十一期间手机上读完，可以不敬业的说这是最近几年唯一一本让我在工作之余还这么被吸引读完的工作相关的书。以小说的形式引出各种形式和状况下如何一点点引入技巧和策略，能get到几个点：待办任务和来源的可视化，看板管理，输出价值，正向工作流和快速部署快速反馈，识别瓶颈，从源头开始IT参与战略规划，工作的四种类型，拿数据来说服人。
- 除了翻译的有点烂之外，这本书还是写的非常好的！前期的慢节奏的矛盾塑造，非常生动，让我对开发运维和it架构有了一些理解，是个每一个技术人员品读！
- 工作需要，了解下。很喜欢这本书，以及这本书的行文风格 。里面有些细节还有待反复读，有些行为造成的问题也被过度夸大 ，但整体的书是把什么是devops概念传递给了读者 ，整体看来还是一本很不错的书，不过要想用好大夫相信还需要读更多，并进行尽可能多的实践
- 当工具书看，只看附录就够了。 当小说看，就从头看起吧。
- 一口气读完的神奇故事。这是一部关于devops的神话，但不止于此。我从中看到的更多的是我们如何一步一步逼近团队工作的核心目标，并如何协同达成，而第一工作法 第二工作法 devops这只是通往目标的手段。关键的是思考的过程和协同合作的方式。这是最近读过最好的“不专业”的专业书了。本年度书单又增加了一本：《目标》
- devops比想象中的重要，对于个人来说，工作法与看板非常值得学习。对于部门来说，政治斗争不可避免，但是小说中莎拉这么笨的人应该不存在吧……
- DevOps、GTD…原来开发部与运维部有那么多矛盾冲突…20160629
- 虽然有很多IT大佬推荐，但作为小说来说故事没什么趣味，作为工作指导书来说前面的小说部分又过于啰嗦，不做这行的人可能很难读下去吧。
- 毕竟想把事情做好的人占大多数。
- 非常能引起共鸣的一本书，计划外工作，约束点，任务看板，频繁新需求等方面的问题识别或处理都非常重要，三步工作法包括工作流 反馈以及持续学习与实验原则都与自己所从事的项目工作息息相关。该书主要是围绕敏捷和devops的思路，具体迭代，集成工具没有过多涉及，传统瀑布项目其实很多观点也适用，因为文中出现的问题任何项目都可能会有，只是敏捷和集成持续的交付会帮助解决其中更快速更有效的部署和运维。
- 凤凰项目确实是和《目标》一样的传奇故事。最近两年一直在思考Devops、持续交付、微服务，其实本质的思想，是回归常识的约束理论，虽然康威定律指出了现象，但是要怎么做，还需要高德拉特博士在目标中介绍的思考方式
- 超赞，任何有项目管理经验的人都会深有感触吧，不过现实我觉得就是第一部分结束以后主角离职来到新公司开始新的轮回。第二部分简直就像是魔幻般的假象。让人不寒而栗。
- 作者制造紧张气氛…可名字看完都混着…紧张不起来啊…一本用精益生产的思想来进行IT 运维管理，IT 项目管理。确实角度不一样。很多方向可以去研究。毕竟工业时代的运营管理已经达到了一定的高度，很多可以借鉴的东西。看板，节拍，半成品库存，供应链，质检。很多生产线上的名词直接拿过来用了。项目管理提了一下高度，感觉不一样了。做IT 管理不能站在IT 里。整体从管理角度考虑，还是不错的书。就是独角兽…有什么问题？原来不也是凤凰嘛？
- 很有启发，准备试验下个人看板方法
- 囫囵吞枣，虎头蛇尾。
- 以小说形式，基于一个虚拟的凤凰项目，充分描述了传统IT运维的困境，包括：IT内部团队之间的理解和目标差异造成立场不同、方向迥异；技术团队疲于应付技术债务；IT、业务与企业战略脱节，在企业生死存亡的关键时刻拖后腿。通过创新和持续完善DevOps，最终让企业度过难关取得成功。
- full of aHA moments
- 提炼了不少日常的体会
- 我很早就意识到，我从英语文章中获取信息的速率太慢了导致我对英语没耐心，今天发现翻译腔也是。。。
- 其实每一个企业都面临这项目管理上的同类型的问题，要相信这些是可以克服可以解决的
- 把it开发运维比做加工厂，一切还在开发中的未上线的版本，都是积压在车间的半成品，不创造业务价值。这个比喻有种全新的视角。
- Devops背后的故事，精彩，每个IT人都应该看看。翻译减1星。
- 不只是在讲运维，而是在讲一种工作思维。
- IT运维/管理 （外行看觉得叙述稍微啰嗦了一点，人手不够项目太多这个问题跟老板argue了好几章...
- 爱不释手，里面的坑我都踩过，最近换了环境开始用devops 真的很不错的方法
- 后半段有点太理想，但其中有一些和常识相左的理念可以
- 避免首席工程师总是解决相同的问题，减少任务对瓶颈点的依赖，通过初级工程师来进行分流。建立工作流，反馈机制，持续学习文化。用系统的思维，去解决不同部门之间的系统问题，让进展中的项目可以被看见，对管理者会有启发
- 十一期间在等飞机、坐飞机、各种排队的时间看完了这本书。故事很有趣，收获也稍微有一点。
- 这本是听的得到听书，没感觉有什么特别的，可能是得到听书的问题，看书还是得亲自看，不能听人讲述，会漏掉细节不够完整
- 第一本it小说，让我知道了在制造业里it的作用。中国企业信息化任重而道远啊。
- 以讲故事的方式告诉了我们，如何控制变更评审，如何安排约束点的工作，如何安排工作优先级，为什么要做持续交付……对管理人员或者运维人员来说，是本好书呀！
- 2020年第一本书 从没有头绪到渐渐清晰 明白了"什么是运维管理"这件事情 希望我离开罗氏的那天 也能像书里这样 临危受命 坚持不懈 最终带着一群好伙伴的祝福与完满的回忆离开 还有一身本领
- 对一个商科生来说，看完以后对运维有了感性全面的认识
- 每一个运维开发及管理都来读好嘛！
- 管理的意义就在于使得每个人都可以被替换
- 一本不错的关于运维管理的书，主要的核心是借鉴高德拉特的TOC理论，然后加上看板开发、敏捷、快速交付和自动化测试等方面的案例，真心不错的一个好故事。
- 部门各自有目标的时候，应该注重工作流，先让那个步骤运行下去，之后完善反馈和复盘机制。
- 一开始以为是运维的书，后来发现不止运维，到最后果然还有敏捷和devops。 要讲的东西不多，但是通过故事讲出来，让人能够共情。
- 非常棒的作品，完全理解了DevOps的产生背景和核心内容，看完这个再去读DevOps实践指南才会有共鸣。特别是对三步工作法的解释应用：第一工作法帮助我们理解在工作从开发部移向it运维部时该如何建立快速工作流，把it 目标和运营目标联系到一起；第二工作法告诉我们增强回收成本的能力，任何半成品都是冻结资本无法带来收益的行为；第三工作法是建立一种文化，使用监控项目，罗列所有资源，提升约束点，给系统施压，从而不断强化习惯并加以改进。 这才是敏捷中漂亮的最后一环。悲哀的是大多时候我们总是还没完全理解就去套用一个流程。
- 很有趣的故事。
- 说服你开发运维与管理制造业流水线是一样的
- DevOps不仅仅是工具的升级，更多的是管理思路和方法升级
- 看了一半，数落在了飞机上了……作为实践过ITIL流程设计和项目实施，以及做过专职项目经理的我，对书中的内容非常熟悉也倍感亲切。只是作者更多的在讲故事，而不是分析故事和提供方法。
- 好多个“回忆杀“时刻。 当年的DevOps实践，从一开始的充满激情，到最后的心力交瘁，中间隔着的，其实是领导层的文化认同和适应。 ”I don’t care about processes, I only care about the features you deliver”. “We have a new feature today. I want it to deliver yesterday”. 如果那些年能读到这本书，我大概会更强硬地去influence所谓的VP们吧。 现在呢，DevOps如空气一样，虽察觉不到，但处处不在。
- 哈哈哈，简直是对这个职业最形象的描述了。读完了，大概不懂这个行当的人也能明白什么是devops。
- 介绍了整个流程推进变化的过程，可能在现在的开发来看这一切都是已经存在的，但是这个过程觉得让人受益匪浅
- 故事性不错，现实中第一部分就是整个故事了。
- 当年读完高德拉特的管理著作《目标》时就曾想过，将精益生产的管理方式运用到IT项目管理将会是什么样子？《凤凰项目》前半部分就完美地诠释了这个问题，证明在追求精益这个同一目标上，两者的管理方式是互通的，通过借鉴生产管理模式来解决IT管理中的问题，改善效率。而生产管理方式已经具有一定成熟性，势必也会对未来IT管理产生重要的引领作用。而书中后半部分则根据目前IT行业快速应对的需求，引发出DevOps和敏捷理论。相信在未来很长的时间里，敏捷乃至精益会是IT项目管理的主流趋势，无论是产品、开发还是运维，只有在对这种管理方式具有一定理解力的基础上共同协作才能在竞争激烈的环境中胜出。
- 故事很经典，有启发！
- 核心几个收获（1）生动的了解了运维部门的工作职责以及ku bi的工作日常，所以预算来自运维部门的项目可真得谨慎（2）IT开发这种技术工种，或者进一步上升到general的智力型工作，都是可以参考传统制造业的管理思想来进行优化的。其中，“减少在制品”这一条思想在我的日常工作中的体现就是多做从0到1的事、减少0到0.5的事，对我而言绝对价值千金，算得上工作以来最重要的几项认知之一了（迟来总比不来强）（3）DevOps本质上师从工业的“精益制造”“目标&约束”生产理论，过程中可能会产生对DevOps工具的需求，但更重要的是对组织和文化的一种革新，妄图通过上一套工具就实现DevOps、解决IT产品更新迭代速度慢的问题是不现实的
- 2019-03-15开始
- 竟然能把一个无聊的故事写这么长…
- 凤凰涅槃，IT世界的英雄拯救人类的故事，内容很不错。从反面一步步推演运维体系的建设和作用，找到关键工作，留有余量使之可以顺畅无等待运转。
- 软件工程和其他生产项目其实并没有太大的区别，细节上肯定是不同的，但是宏观上都是为了赚钱！
- 头重脚轻，不知道最后效果怎么实现的那么快。领导推荐的书，但领导在公司的实践似乎很不上道。但本书是值得运维研发管理一看的，后来的推荐书也不错，但这些舶来品所谓方法论似乎在中国水土不服。因为中国的节奏更快，或者it从业者都不擅长表达，以至于沟通总是成问题。
- 第一工作法是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，决不让缺陷流向下游工作中心，并且不断为了整体目标进行优化 第二工作法是关于价值流向各阶段自右向左的快速持续反馈流，放大其效益已确保防止问题再次发生，或者更快的发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量 第三工作法是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提
- 驚心動魄的IT災難，在即將毀滅一個公司的時候，被拯救，很激動能讀到這樣的書，有對《目標》的致敬，有對‘精益生產’的借鑑，原來好的生產管理控制方法都是一致的，不論是工業生產時代還是軟件開發運維時代，吃透精髓，無往不利。最後部分的推薦讀物有時間也要找來讀讀。
- 不管你是不是IT从业人员，都可以看看这本书。
- 我以为本书的重点是放在介绍如何解决问题上 ，实际上前面工作铺垫写的挺精彩，节奏扣人心弦，反而到最后解决的过程一笔带过，有点头重脚轻的感觉。