这本小说的主人公是一位 IT 部门经理，他面对 IT 公司所特有的全部典型问题：项目预算超支，进度一再拖延，为了公司的存亡不得不上线。他经历了灾难般的部署，也面对过可用性、安全性、合规性等方面的问题。最终，他和他的团队采用 DevOps 的原则和实践战胜了以上困难，帮助公司赢得了市场。此外，该小说展示了 DevOps 实践如何改善团队工作环境，让员工参与整个过程，进而减轻了压力并提高了满意度。

总结一下的话，到底什么是 DevOps，其实它就是用系统的思维，去解决不同部门之间的系统问题。用系统的思维去解决公司和团队的问题，这一点其实并没有什么特别的，但是 DevOps 更进了一步，不只是告诉了我们应该做什么，还告诉了我们应该怎么做。那就是三步工作法：第一步建立工作流，完成系统视角的转换；第二步，建立反馈机制，对上游反馈对下游改善；第三步，建立起持续学习的文化，让所有的改善都可以落实到系统上。

本书讲述了一位 IT 经理临危受命，在未来董事的帮助和自己 “三步工作法” 理念的支撑下，最终挽救了一家具有悠久历史的汽车配件制造商的故事。小说揭示了管理现代 IT 组织与管理传统工厂的共通之处，让读者不仅能对如何管理 IT 组织心领神会，更重要的是将以完全不同于以往的视角来看待自己的工作环境。本书核心内容：一、小说的主角是如何找到问题关键的？二、如何改善任务？三、DevOps 的核心思想：三步工作法。DevOps，其实就是用系统的思维，去解决不同部门之间的系统问题。用系统的思维去解决公司和团队的问题。DevOps 更进了一步，不只是告诉了我们应该做什么，还告诉了我们应该怎么做。第一，书里的主角就是通过看板才开始了解了自己工作的全貌，为以后解决整个困境打下了基础。第二，减少任务对瓶颈点的依赖，通过初级工程师来进行分流。而且，这件事不只是初级工程师的责任，同样也是首席工程师的责任。如果没有做到，双方都要做到惩罚。同时保证了这两点，才是解决瓶颈问题的关键。第三，DevOps 三步工作法：1. 建立起工作流；2. 建立起反馈机制；3. 建立起持续学习的文化。到底什么是 DevOps？就是用系统的思维，去解决不同部门之间的系统问题。用系统的思维去解决公司和团队的问题，这一点其实并没有什么特别的，但是 DevOps 更进了一步，不只是告诉了我们应该做什么，还告诉了我们应该怎么做。那就是三步工作法：第一步，建立工作流，完成系统视角的转换；第二步，建立反馈机制，对上游反馈对下游改善；第三步，建立起持续学习的文化，让所有的改善都可以落实到系统上。

如果要用四个字总结这本书，我会说 "身临其境"。作者在本书中描绘的场景，问题，挑战等的每个细节，都在曾经的工作经历中似曾相识。相信每一个 IT 从业者，都能在本书中找到属于自己的角色。更妙的是，作者通过其第一人称的视角，近乎真实的描绘了一个职场人 "打怪升级" 的点点滴滴，并且结合了老外的独有的幽默，使得这本书并没有太多壁垒，即使是非 IT 从业者也无需望而怯步。本书的核心思想：三步工作法。1) 建立工作流程，2) 建立反馈机制，3) 持续学习文化。实际上适合各行各业学习，树立系统及流程思维，打造透明的共创文化，通过机制化的沟通和反馈，持续改进和优化，建立学习型的组织。相信这本书同样适合企业的管理者，在摸索适合自身组织数字化转型突破点的过程中，找到灵感。

本书的几位作者都有 IT 从业背景，想必其中不少情节和细节都来自他们的亲身经历。在一次接受采访时，作者之一的吉恩・金表示，他们写作此书的灵感来自于 Flickr 公司的约翰・阿尔斯帕瓦和保罗・哈蒙德在 2009 年关于开发速率的一场演讲。

生动形象的 Devops 之旅，原来 IT 管理可以借鉴生产制造的流程，有趣😄

很多事情实在是太有画面了，哈哈哈，笑死了

连小说都选择工作领域相关，功利性明显到着实有些好笑。这本书对于我这种处于专业技术之外边角料人员，确是一个很好的案例展现，书里的情节和人物，现实中经历和道听途说，总能找到完美的映射：紧急需要上线的项目，预算超支进度延后，时而英明时而 “霸道总裁” 不顾可行性硬拍板的领导，过度依赖 “超级个人”，跨团队协作推诿搪塞，办公室政治等等。主角通过自己的光环，一路打怪升级，把 “三步工作法” 通过合理情节展现给读者：第一步建立可视化工作流，第二步建立反馈机制减少返工，第三步建立持续改进文化，实现持续交付。诚然，非技术人员的我仍然不懂 Dev 到 Ops 的专业技术部分，但本书仍然给了我很好去理解瀑布开发模型、V 模型、敏捷开发模型概念的区别，同时在数字化转型的必然趋势里，补充对业务如何与 IT 结合，何为需求、何为痛点的理解。fine，如果能练好文笔，说不定退休后累积到足够经验的我也能找到个新的谋生。

阅读体验极佳，电影剧本一样的画面感。

各种运维过程中的名场面，很贴近工作实践。让人一看就有特别的熟悉感

作为 it 从业者的必读书籍

《凤凰项目：一个 IT 运维的传奇故事》的 3 位作者是在 IT 行业有着丰富经验的行业大牛。基恩・金，担任 CTO 13 年。凯文・贝尔，拥有 25 年以上的 IT 管理经验。乔治・斯帕福德，是高德纳公司高级研究总监。这是一本用小说的形式来介绍管理思想的书。虽然是小说，情节都是虚构的，但是主角所面临的困境让很多人都会感同身受。书中主角解决困境的方法，就是作者们自己管理思想的体现。作者们根据自己在 IT 管理行业里的多年经验，发现了几乎所有技术团队，都会面临同一个管理上的困境 —— 项目里的每个成员，明明都很努力，都在各司其职。但是整个项目的推进却总是阻碍重重。这本书就是在帮助读者解决这个问题。本书讲述了一位 IT 经理临危受命，在缺乏跨团队协作、过度依赖关键个人、办公室政治斗争严重、部门地位尴尬，又遇到并未科学规划又严重消耗资源的 “凤凰” 项目时上马，在未来董事的帮助和自己 “三步工作法” 理念的支撑下，挽救了一家具有悠久历史的汽车配件制造商的故事。小说揭示了管理现代 IT 组织与管理传统工厂的共通之处，让读者不仅能对如何管理 IT 组织心领神会，更重要的是将以完全不同于以往的视角来看待自己的工作环境。本书的核心方法论 DevOps，其实就是用系统的思维，去解决不同部门之间的系统问题。用系统的思维去解决公司和团队的问题。DevOps 不只是告诉了我们应该做什么，还告诉了我们应该怎么做。D-E-V-O-P-S，其中 D 和 O 大写。DevOps 名字里的 Dev 表示的是开发者 Developers，Ops 表示的是 IT 运维 Operations。两个单词的组合，其实就代表了开发部门和 IT 运维部门。这套解决方案的核心，就是让开发和运维，两拨人顺畅协作。开发者是把软件做出来，IT 运维是要把软件成功地部署到服务器上，这是两种不同的技能。几乎是所有互联网团队都在使用这个管理方案。开发和运维两种技能虽然不同，但是又相互依赖，如果开发部门做得不好，运维团队就很难把开发出来的系统部署上线，如果是运维团队做得不好，开发团队做得再好，系统无法上线，无法完成临门一脚，最后也是白搭。2013 年在完成了这本小说之后，本书的第一作者，基恩・金就结合另外 3 位行业大牛写了一本《DevOps 实践手册》把自己的方法论总结了出来。在小说后面就有一部分《DevOps 实践手册》的内容，它能帮助我们更好地掌握 DevOps 的核心思想。

本书生动有趣的讲解一些 it 项目中遇到的 “事故”，以及如果找到根源及一步步解决。因为问题的普遍性，总能让读者产生共鸣，并且恍然大悟，终于知道自己工作中疲于奔命的原因。本书对于一个 it 从业者或管理者都是有启发意义的。推荐！

还行吧，对我来说只是知道这可行

devops 必读书，及时你不是计算机行业，也可当一本不错的小说来读。