市面上以DevOps为主题的书，以及和项目攻关的影视作品有不少了，但这本小说读起来依然紧张刺激。除了揭示管理现代IT组织与管理传统工厂的共通之处，书里更强调了以一种全局的视角来重新看待自己的工作环境，和自己在工作中扮演的角色，并且，其包含的问题分析方法、实践方法也或多或少可用于个人效能的优化。
下面是一些书摘和简评。
面对压力和现实
比尔，我知道你没有申请这个职位，但公司已命悬一线，我需要你来帮助我拯救这家伟大的公司。我能指望你吗？还没来得及再次礼貌谢绝，我突然听到自己说“可以，你可以指望我。”我慌了，强迫自己住嘴，以免做出更多愚蠢的承诺。……“我会尽力的，还有，能不能请你至少解释一下，为什么在这个位子上的人都干不长？你最希望我做什么，最不希望我做什么？”
临危受命时，一定要弄清楚领导的意图和前任失败的原因。
我还来不及回应，莎拉就大声说：这恰恰表明，比尔及其团队缺乏对于紧迫性的必要认知。追求完美是成事的大敌，比尔，我们可没有闲工夫为了迎合你的黄金标准而精雕细琢……难道这不是有点太轻率、太不公平了吗？但莎拉不屑一顾的说：我相信决定已经做出了。……接下来的9天里，我们所有人都要熬夜加班了。这种全员出动的工作状态是IT人生活的一部分，但是想到我们又得因为其他人疏于计划 而不得不奋力拼搏，我还是有些恼火。
在市场负责人莎拉拿出一切为了项目这个尚方宝剑时，由于没有实际数据支撑，只因为道理而不去做是不够的，所以只能先忍下来。反倒是不顾实际情况强行推进项目发布的莎拉，得到了CEO史蒂夫的支持。因为CEO更关心股价、以及董事会对他的看法！
我设法复述那些缜密理性、条理分明的论点，他们是我花了整个周末的事件排练的……我一边说一边不断观察史蒂夫，到目前为止，他一直面无表情。……史蒂夫愤怒的回答：什么优先级高不高的狗屁问题？……我在心里默数三下才开口：当然，我表达的不够清楚，……我们的基础架构太过脆弱……好吧，我们会尽最大努力，但我要郑重声明，我们的人手严重不足，无法高质量完成其中任何一项工作，更别说全部了。……比尔，
凤凰项目已经超支1000万美元，我们必须马上得到正向现金流。增加任何预算都是不可能的，如果会有什么调整，我们可能还得在你的部门减掉几个人。……离开的时候，我把花费整个周末时间准备的演示稿扔进了垃圾桶。
CEO有他的计算方式和危机视角，所以主角上来摆事实说道理不会得到支持。
公司高管强迫我的工程师优先执行他们的命令，这完全是胡闹。我（对布伦特）补充道：如果有人为了凤凰项目之外的事和你联系，就把他们推给韦斯（直接上级），让他去对付那帮笨蛋。无论如何都要想办法改正大家直接来找你帮忙的坏习惯。我允许你把电话设成静音，把状态设置成你没空。随便怎么样都行。
布伦特是一名对系统了解最多的明星员工，所有重要的系统变更都需要他帮忙，但他就像一个黑盒，是系统的约束点。首要任务是发现并保护系统的约束点。
我惊讶的目瞪口呆：史蒂夫，情况得有多糟糕你才肯推迟这次发布？我告诉你这次是运行将是非常鲁莽的冒险！……虽然很不情愿，但我还是觉得自己欠公司最后一搏，去阻止这次疯狂的行动。……（强行发布后）……史蒂夫停下脚步，用手指着我的前额说：我对责任的理解，比你一辈子学的还要多！我受够了你整天嚷嚷着天要塌了，时候在高高兴兴地说‘我早就告诉过你了’。你得带着实际的解决方案来找我。……我需要业务部门告诉我，他们不再受部门IT部门的钳制。我担任CEO依赖，一直都听到这样的投诉，IT拖累了每一项重要举措。
原来是这种发酵很久的情绪带来了偏见，导致史蒂夫讨厌比尔的稳扎稳打，偏爱莎拉的冒进。
（史蒂夫讲述自己的个人经历和弱点，并鼓励会上的每一个人都这么做）展现自己脆弱的一面有助于建立起信任的基础。
约翰气急败坏的说：你以为你是谁？我在努力保持这家公司的安全，让那些审计师离得远远的！我……得了吧，只会帮倒忙的CISO先生。埃瑞克打断他说，正如你刚才看到的，不用你出手，这家公司就能让审计师离得远远的。你就像个管道工，不知道自己在为一架飞机服务，更别说了解飞行路线，或者航空公司的营业状况了。……你真的不明白，是不是？无极限零部件公司最大的风险是停业破产，而你似乎一心想用你那些不周全的考虑和无关紧要的技术细节，让他加速倒闭。怪不得你会被边缘化！……
约翰身上有几个问题：
- 没有理解总目标。数据安全是重要，但公司和业务都要黄了，保证数据安全只是空谈而已。
- 没有理解业务全流程。事后他才知道即使前序的IT系统中有各种安全隐患，但后续每一笔交易都有人工审核，所以审计师并不会来找麻烦。
- 没有真正理解自己的职责和能力如何助力于总体目标。所以他倡导的数据安全在其他人看来只有妨碍作用。他在该阶段真正的作用在于用经验和能力减少其他部门在安全上的无效努力。
克里斯首先回答：我之前就说过，就连次要的漏洞修复都问题重重，我们不能承受每月一次的发布……史蒂夫回答：成败就看这个季度。我们向世人许诺过，会在上个月把凤凰弄出来。……我们没有时间了。我对克里斯说，如果你说凤凰团队应该放缓速度，我不会有异议。但是，我们仍然要想办法满足史蒂夫的要求，如果我们不能再凤凰的框架内做成这件事，也许可以在凤凰之外做到。我提议可以从凤凰主团队分出一小队人，组建特别行动队。
老项目老流程积重难返，这里提供了一种减少掣肘的思路。后文能看到，特别行动队奏效了，而且其优秀的工作流还被原凤凰团队逐步借鉴，形成反哺。
建立认知
半成品是个隐形杀手。因此，管理任何一家工厂最关键的机制之一，就是工作任务和原材料的发布。没有这个机制就无法控制半成品。为了停止半成品在工作流中堆积，即使其他人闲得无聊，也不应该在瓶颈已经达到饱和的情况下，继续制造半成品。
在瓶颈之外的任何地方做出的改进都是假象。作为IT运维部的副总裁，你的工作时确保形成一条迅速、可预测、持续不断的计划内工作流，从而向业务部门交付工作价值，同时尽可能降低计划外工作的影响和破坏。我不管每个人觉得自己的项目有多重要，我们要知道的是，该项目能否提高我们在约束点上的工作能力。
实际上有四种类型的工作：来自业务方的、自身基础架构的、操作变更、计划外工作。计划外工作是恢复性工作（比如屎山代码出BUG后的救火），占用你的时间并阻碍完成前三种正向产出的工作。如果不加控制，技术债务将导致公司里能够唯一完成的工作就是计划外工作。
流程是用来保护人的。根据韦斯讲的故事，我们甚至都不该让布伦特碰到键盘，他可以告诉大家应该输入什么，但在任何情况下，都不准他做哪些我们无法在时候记录的事……每解决一个问题，我们的知识库里就会多一篇关于如何解决某个疑难杂症的文章，而且能够实施修复的人会越来越多。
这里提到的解决疑难杂症的文章，类似我在微软工作时组内特别重视的
postmortem，也类似达利欧在桥水特别推行的错误日志。目的是同样的错误绝不犯两次，而且下次其他人也可以处理。一旦通清楚最常出现的任务是什么，就需要建立起工作中心和工作路径。
你必须跳出原来的专有领域，才能弄清楚
整体的成功需要你的哪些工作来达成。IT是一种技能，就像能读会算一样。理解技术能够做什么，不能做什么，已经成为一家公司每个部门必须具备的核心竞争力之一。
创建一个让人感觉无能为力的系统，使我们能对人类同胞做的最具破坏性的一件事——我们剥夺了他人控制自己成果的能力，甚至营造了一种文化，让人们因为害怕遭受惩罚、失败而不敢做正确的事。这制造了“习得性无助”的环境，人们变得不愿或无法采取行动来避免未来遇到同样的问题。
三步建立高效的工作流
目标：流量最大化；可灵活应对调整。
第一工作法
- 明确价值链。从最终的绩效指标反推，其实现依赖什么，以及不满足时有什么风险。
- 最大优化正向工作流。
让等待时间可视化。在工厂的流水线上在哪里出现拥堵或空转显而易见，但IT或日常生活中很容易忽略（又叫暗时间）。Kanban是一种比较好的方式，注意只有在生产环境里成功运行起来、或开始产生价值的时候，才能算“完成”。减少中断。生产中断在制造业里显眼且代价极高，所有的半成品都将报废。但技术工作者很容易被打断，因为后果不可见。通过严格限制多任务的数量、新任务的插入减少打断的次数。杜绝缺陷向下游传递。发现难题，群策群力，建立机制而不是以后再说。减小交付的内容大小和等待间隔。持续识别、改善约束点。约束点可以是一个人，或者大家都倚赖的同一种资源、前置步骤。以DevOps为例，通常要依次优化以下约束点：1、环境搭建；2、代码部署；3、准备和执行测试；4、架构耦合。消除浪费。例如：1、半成品（文档、变更单等）；2、多余工序（对后续流程无价值）；3、任务切换；4、资源竞争和等待；5、非标准或手动操作。
第二工作法
快速、持续的获得反馈。否则没人敢在一个复杂系统中放心的工作（不用担心自己的某一个操作在将来搞坏系统中另一个本不相关的功能）。 仍以微软为例，Substrate仓库里有多个M365相关的产品，约5000+工程师维护着上百GB的源码文件，即使穷尽一生也没有人能充分了解这样一个已经存活几十年的庞然巨物。然而这样一个系统的迭代速度却非常惊人，保障这个工作流的其中一个方式是：
- 每一次代码提交都会触发多种自动化测试和模拟部署，在几分钟到几十分钟内告诉你是否可以将代码合入主干。
- 同时会自动@所有相关模块的负责人在DevOps系统中进行Review，直到所有利益相关者同意合入。
第三工作法
建立具有创意和高可信度的文化。它强调每个人都是持续学习者，必须勇于承担风险，通过科学的方式改进。彼此分享经验，经验积累沉淀。
- 将日常工作的改进制度化
- 将局部的优秀经验全局化
- 领导层为团队创造学习条件，领导力并不体现在做出的所有决定都是对的。