基本信息
推荐指数：
作者：凯文.⻉尔
内容简介：讲述一个凌乱无序的运维项目组，通过一步步改进，达成高效、舒心的工作状态。这本书是以故事线来进行讲述，仿佛让自己也置身在项目组中，面对各种各样的问题，
和主人公一起经历、解决。相比工具书更有代入感，对devops的启蒙及应对工作中繁琐的事情，如何找到破解之法都比较有帮助。
书摘
一、背景
公司是一家汽⻋零部件公司，无极限公司，凤凰项目是公司的战略项目。通过凤凰项目要实现新零售，通过互联网、零售⻔店都可以买到产品。但项目已经进行三年未完成，而且还在延期，竞争对手在这方面已经超过自己，CEO史蒂夫希望尽快完成凤凰项目的上线，临危任命主人公比尔为运维副总裁。
二、人物关系
CEO史蒂夫:有感染力，领导力，但会被董事会、业务线裹挟。对IT价值前期有怀疑，后面逐步磨合认同。
比尔：运维部工作十多年，管理的项目井井有条。升任运维副总裁后，在艾瑞克指点及团队内部的努力下，一步一步解决当前的混沌状态，为凤凰项目的完成，起到关键性作用，从被动完成系统，到以业务目标驱动，通过it系统的建设实现业务目标。
⻙斯：分布式技术运维部总监。大嗓⻔，粗放，好斗。在比尔的引导下，成为主动解决问题的人。
帕蒂：服务支持部总监。细心，结构化，善于分析，善于流程管理。
布伦特：运维专家，也是运维工作的约束点。前期很多问题都会流入他这里，因为他能准确解决，团队中其他人员无法承担重要责任。陷入能者多劳误区，但安排给他的重要事情又因为插队不断延迟。后面在比尔的帮助下，发挥优势，为自动化部署工作起到关键作用。
克里斯：应用开发副总裁，负责开发团队，完成凤凰项目的开发工作是头等大事。后期与比尔一起探索快速部署，上线，实现独⻆兽项目的成功。
约翰：信息安全部负责人。以安全为使命，却只关注系统补丁，做了很多无用功。后来从业务视⻆出发，端到端关注，把安全工作做的更高效，有意义。
莎拉：零售运营副总裁。只考虑业务目标，不计较系统⻛险。
艾瑞克：灵魂级人物，通过他的指导比尔和团队探索出了一条开发+运维的有序化路径。
三、升级打怪之路
挑战1：工资核算系统故障
工资核算系统故障影响：部分员工的工资核算出现问题。如果解决不了，当天下午也必须把工资结算出去（可能有错），因为延迟工会会介入。工资数据不准确，需在下个周期调整回来，还会涉及到财务报表错误，会有审计麻烦。
问题核查过程：
出现问题的真正原因没有找到，布伦特根据自己的经验，判断是san故障导致的工资核算系统问题，因为前一天晚上帮san工程师升级，升级完重启出现问题，这个时候就收到工资核算故障的通知。
从业务方获得的问题信息：有一个信息字段为空或者乱码。从表现看，不像SAN故障。
除了昨天SAN升级，还有哪些操作可能导致故障？
有人反馈，昨天有个开发计人员调整工厂计时应用程序，约翰让安装安全应用程序，涉及到字段调整。
约翰上线前没有测试环境，未进行测试。
故障恢复，但已经超过工资结算时间。
总结：
生产变更记录不全。不清楚对生产做了哪些调整。无法第一时间定位问题。
问题核查靠个人主义，没有分析清楚表象，可能的原因。
挑战2：凤凰项目上线问题
凤凰项目的当前进展：没有上测试环境，没有压力测试，希望9天内完成上线。比尔反馈了部署的困难，但ceo坚持上线时间。
上线后结果：
凤凰项目如期上线失败。造成⻔店pos系统宕机。凤凰上线的系统会丢失交易，多扣用户钱等严重问题。
为了维持凤凰项目的运作，运维每小时都要重启一次前端服务器。
财务、客服组成临时问题处理室，对出现问题的订单一笔笔核实、操作。
史蒂夫与大家一起反思，讨论解决问题的办法，2周内先暂停其他项目，全力解决凤凰项目的遗留问题。
总结：
环境混乱，前置准备工作不足。
在ceo提出的要求不可能实现的情况下，团队却没有及时提出来。因为大家对整体情况没有全盘了解，或者觉得注定有问题。
挑战3：it合规性审计
背景：为应对外部审计（证监），先提前进行了内部审计，审计提出1000多项问题，一周时间，IT需要给出问题答复。
内部审计问题：访问权限，变更会议记录等等
与外部审计沟通结果：外部审计人员与无极限公司对审计的安全问题进行确认。业务部⻔、财务部⻔从业务管控等方面回答了it安全⻛险不会造成业务问题。
约翰一直觉得这些都需要在it系统解决，但是开发、运维却不支持自己的工作。审计的结果让约翰改变，对公司有了新认识。
约翰从未了解系统以外从业务的视⻆看安全防控的问题。艾瑞克提醒他，可以不对it系统做过多无用功就保护公司，才是约翰的胜利。
总结：
怎么能少做无用功，达成目标，是资源的合理利用，是效率问题。资源永远是不充足的，从全局视⻆，做到最优方案。
改变1：工作盘点
以前对工作需求、优先级、工作进度、可用资源都一无所知，怎么可能管理好生产工作？
列出部⻔的工作职责清单。列出关键人力资源承担的所有工作任务，显示他们正在做什么。
初步梳理，150名员工，超过了105个项目，还有被低估的可能。
工作内容分布，故障及修复工作，占用了员工75%的工作时间。
向史蒂夫申请资源：经过具体数据盘点，人手不足，无法完成并交付所有许诺工作。如果凤凰项目是最重要的事情，审计问题能否先不考虑？史蒂夫：如果去董事会去让销售和市场营销二选一，应该做那个，会被嘲笑死，虽然凤凰项目很重要，并不意味着其他不用做。凤凰项目已经投入过多成本，所以加人是不可能的，除非你能从别的部⻔的预算里面协调一部分。
总结：对资源有整体的分析、盘点，有助于找到问题的关键点。
从不同视⻆看问题，是不同的结果，所以和史蒂夫的谈判没有预想结果，因为大家视⻆不一样，就像公司申请资源，如果提加人，都会让先从自己流程优化考虑，应该是一个道理，怎么平衡？
改变2：变更管理
组织系统变更会议，进行变更管理，前期的系统流程不方便，大家没有遵守。当前先用白纸填写系统变更操作，列三条信息，制定者，变更系统，概述。先实现管理，收到400百多个变更。
根据2/8原则，百分之80的⻛险由百分之20的变更导致，关注最有⻛险的变更。定义高⻛险目录，制定高⻛险变更要求，不光关键人物关注变更而且要随时待命，防止出现问题。对于复杂的中等变更，变更提交者有责任向可能受到影响的人员咨询并得到认可。
已经申请审核通过的变更，有60%的都没有执行。因为变更前因为各种原因准备工作没有做好，还包括因为需要布伦特，但他当前没有时间。是否应该在变更申请单上标识出需要布伦特？
总结：
全局及分级，识别关键问题。
改变3：帮助约束点布伦特
布伦特的工作会被各种突如其来的事情打乱，约定的工作无法按时交付。
建立一个3级工程师人力资源库，流转过来的工作，把布伦特屏蔽在资源库外。不准布伦特反复解决同一个问题，第一次需要布伦特解决的问题，加入知识库，第二次三级工程师要可以解决。
改变4：去了解业务
约翰和比尔去找coo迪克，了解迪克真正关键的业务目标。远期、近期指标和评估指标，评估指标由哪几位经理负责落地。
对业务流程负责人访谈，理解客户的需求与期望。
访谈负责销售指标，销售准确率的负责人。公司定的销售指标过高，导致一直达不成，团队士气低落，业绩好的人大批辞职。当前完全不知道客户想要什么，滞销产品太多，畅销产品总是缺货。
销售渠道流程及困难：经理们想从crm系统中拿到需要的报告很困难。
糟糕的一天：因为物料系统和电话系统崩溃，导致客户订单延误，用户大喊要求取消订单。月末电话系统不能用，客户没法给我们下订单或临时变更，十个客户重新评估了他们的合同。
访谈结束，针对销售负责人提到的关键指标相关系统，进行梳理，通过防御性工作支持公司最重要的指标。
访谈发起凤凰项目的业务负责人玛姬。她对了解客户的需求和期望的衡量标准是，客户是否会向朋友推荐公司产品，但这个指标不太好。
因为大多数情况下，我们都是盲目行动的，理想的销售数据会告诉我们客户想要什么，但是订单系统和库存系统的数据总出错，无法做到这一点。当前用于预测的数据还来自两月一次的线下⻔店收集。
希望从⻔店和在线渠道得到准确及时的订单信息。运用这些数据设计市场推广活动，提升市场份额。
产品的上市时间要快，不然6个月后就会出现在竞争对手的货架上。另外开发周期越⻓，公司资本锁定的时间就越⻓，锁定期是没有回报的。
访谈后，比尔整理了一个表格，第一列达成期望结果所需要的的业务能力、流程，第二列为流程依赖的it系统，第三列为it系统或数据可能会发生的故障，第四列为防范故障的措施。
与迪克就阶段性成果谈话。希望用三个星期逐一会⻅电子表格中每一位业务流程负责人，定义由it引发的业务⻛险，达成共识。然后提出把这个⻛险纳入主要业务指标的办法。
凤凰项目现在发布周期太⻓，进展太慢。我们需要把发布变小变短，更快回笼资金。
独⻆兽项目启动，通过自动化构建，提升效率，解决实际业务问题。
改变5：防御体系
每两周组织一次排查故障的实战演练。让每个人养成运用合理的方式解决问题的习惯。
监控项目的实施，让系统的所有变化都透明。
独⻆兽项目的尝试，自动化的开发、部署、上线。提升效率及中间因为人为等问题导致的失败。
团队效率提高；不断增强的基础架构和应用程序产品监控，比业务部⻔提前发现问题；减少了项目的积压；变更管理比以往更顺利；成员更加乐观向上。
机遇：艾瑞克
初⻅：比尔，你觉得怎么让自己的团队不再手忙脚乱？从救火模式中解脱。
it运维部承担的工作类型？业务项目工作，公司内部项目，变更，计划外工作（反工作）。
带比尔去MRP⻋间，讲工厂工作流原理。在日常生活中也会遇到这类情景，流程分20个环节。第一个环节的负责人接到什么任务就处理什么任务，忙个不停，没有考虑后面其他环节瓶颈问题，导致⻋间很多半成品，堆积在工厂里，效率低，给用户不能按时交付。——个人最优与集体最优不是一个概念。
工作站和工人联系，如果25%的工作站都需要布伦特操作，工作站之间的工作流会受到影响，无法按时完成工作，因为布伦特同一时间只能呆在一个工作中心。适当提高防御性项目是全面生产维护等计划的关键。改进日常工作比开展日常工作更重要。
凤凰项目部署升级的又一次问题，因为开发、测试、生产环境不一致，导致提前未发现的问题。与控制发布同等重要的是管理好工作交接。一个给定资源的等待时间，是那个资源忙碌时间的百分比除以空闲时间的百分比。因此，如果一个资源使用了50%，等待时间就是50/50，如果一个资源使用了90%，等待时间就是90/10，或者说9倍⻓，第二工作法的一个关键部分是，让等待时间可视化，这样就知道工作何时在某人那里排了几天。目标是使流量最大化。
四、金句
一半的邮件都是紧急邮件，所有的事情都那么重要，这可能吗？
一个五分钟就能搞定的简单变更，得花20分钟才能填完全部字段。
搞死你的不是前期的投入，而是后台的运行和维护。
了解大家当前工作的情况，一定要告诉大家，这样做是为了申请更多的资源，而不是要外包服务或者解聘谁。
在大多数工厂里，总有那么一小部分资源，不论是人、机器还是原材料，决定了整个系统的产出。我们称之为约束点或者瓶颈。建立起一个可信赖的系统用以管理通向约束点的工作流之前，约束点经常是被闲置的，约束点未被充分利用。
计划外工作会让你丧失开展计划内工作的能力，必须不惜一切代价消灭计划外工作。
我们要提高整个系统的生产能力，不只是提高任务的完成数量。
半成品的增加，交付性能会下降。
你必须跳出it领域，才能弄清楚公司依靠IT的那些工作达成目标。
约束理论：在瓶颈之外的任何地方做出的改进都是假象，难以置信，但千真万确。在瓶颈之后做出任何改进都是徒劳的，因为只能干等瓶颈把工作传过来。在瓶颈之前做出的任何改进则只会导致瓶颈处堆积更多的库存。
在任何一个工作台系统里，最理想的状态是单一工作流，这样能让生产能力最大化，同时让变化幅度最小化，通过持续不断降低批量规模，达到这种状态。工作流应该只朝着一个方向，向前，如果向后就意味着返工，开展修复工作。
部署管道，从代码签入到投产的整个价值流，不是一种技术，而是生产。对所有东⻄进行版本控制，不只是代码，创建环境所需的每一样东⻄，把这个穿件过程自动化，缩短准备和排除故障的时间。
三部工作法：第一步帮助我们理解在工作从开发部移向IT运维部时，该如何建立快速工作流。第二部如何缩短及放大反馈环路，从而在源头上解决质量问题，避免返工。第三如何建立一种文化，即鼓励探索，又能理解反复实践的精通工作的先决条件。
五、总结 & 收获
1、以积极的心态面对问题，从全局视⻆考虑解决办法。
2、约束点理论，找到约束点，解决约束点的效率。在约束点之外做出的改进并不能达到目标，只是徒劳。
3、正向工作流，降低返工，提升效率。
4、怎么减少计划外工作？计划外工作会让你丧失计划内工作的能力。