简介
这本书是我读过唯一本关于计算机技术的小说，读起来没有无趣的编程语法和晦涩难懂技术词汇，而是跟随主人公一路过五关斩六将解决IT运维管理中的问题。书中讲述了无极限零部件公司为了重新占有市场份额彻底击败对手，而启动凤凰项目，然而该项目上线一再延迟。我们的主人公”比尔“在这样情况下临危受命，由中型机技术总监提拔为IT运营部副总裁，负责整个公司IT运营管理。主人公在高人指点下，加之主人公光环参透了IT运维工作的四大内容和”三步工作法“，用这些理论使公司IT部门更好的服务于业务，最终帮助公司摆脱危机并占领市场，当然也再次升职加薪。
感同身受
下面我们就一起起看看这本书中暴露的IT运维的问题，想必都是搞运维的痛处：
1.IT预算和人员资源总是倾向于开发，不给运维资源，而只是派活。
2.运维人员培养一致是一个问题，工程师不会记录故障处理方式，缺乏知识共享。
3.运维关键资源一直是瓶颈，一个运维大牛包揽一切。
4.变更管理流程形同虚设，运维工作处于失控状态，经常由于变更产生生产问题，运维人员忙着救火。
5.运维人员超负荷工作，关键资源一直处于饱和状态，而运营总监对运维人员工作内容与状态不能掌控。
6.遇到故障，运维团队缺乏信任，相互推卸责任，并且也没有故障处理机制与预案。处理故障往往依靠一个人或某几个人。
7.CEO或者整个IT团队领导，直接干涉运维人员的工作，工程师被迫瞎忙。
8.运维团队不参与项目架构评审和计划会议，没有团队共享精神。
。。。。
以上是我在书中看到IT运维问题（可能你比我看到更多），这也都是都是我亲身经历过的，感同身受。想知道主人公如何破解这些问题还是认真读读这本书。
摘抄
摘抄几条书中我印象深刻的语句：
1.”变更“就是对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作，并且这样的操作可能对相关服务产生影响。
2.流程是用来保护人的。我们得想出保护布伦特的办法。
3.程序员们，乃至像我这样的经理，每隔几年要学的东西都几近疯狂。有时候完全是全新的数据库技术，全新的编程或项目管理方法，或者全新的技术交付模型，比如云计算。
4.你们需要把一些人称为’非功能性需求’的东西设计到产品当中。(比如质量、可扩展性、可管理性、安全性、可操作性等)
5.想要在团队中达成相互信任你需要展现出自己脆弱的一面。
6.你刚才描述的是未偿还的技术债务。它来自于走捷径，那在短时间也许行的通。但是就像金融债务一样，久而久之，利息成本会越来越高。如果一个部门没有付清它的技术债务，公司的每一努力都将以计划外工作的形式来偿还那些技术债务的利息。
7.我们给你们付工资，是为了让你们思考，而不只是执行。
8.你们应该对所有东西都进行版本控制。所有东西，不只是代码。。。。
。。。。。。。。
书中”约束点“这个概念也让我记忆犹新，可以说本书主线也是一个主人公不断突破”约束点“的过程，第一约束点是技术大牛”布伦特“，所有问题都绕不开他；第二约束点运维与开发的壁垒；第三约束点外包的系统。
书中重点概念
下面是书中核心内容四种工作类型和三步工作法（基本摘自原文）：
四种工作类型：
业务项目:业务部门发起的项目，由项目管理办公室管理。IT内部项目：包括可能由于业务项目衍生出的基础架构或IT运维项目，以及内部生成的改进项目（例如部署自动化）。这些项目经常非集中跟踪，属于预算所有者（例如数据库经理、分布式经理）。变更：经常由上述两种类型的工作引起。计划外工作或者救火工作：操作事故和操作问题，由上述三种类型的工作导致，而且往往以牺牲其他计划内工作为代价。
三步工作法：
第一工作法是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作中心，并且不断为了整体目标（相对于开发功能完成率、测试发现/修复比率或运维有效性指标等局部目标）进行优化。必要的做法包括持续构建、集成以及部署，按需创建环境，严控半成品，以及构建起能够顺利变更的安全系统和组织。第二工作法是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快地发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量。必要的做法包括：在部署管道中的构建和测试失败时“停止生产线”；日复一日地持续改进日常工作；创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态；在开发和IT运维之间建立共同的目标和共同解决问题的机制；建立普遍的产品遥测技术，让每个人都能知道，代码和环境是否在按照设定的运行，以及是否达到了客户的目标。第三工作法是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。尝试和承担风险让我们能够不懈地改进工作系统，这经常要求我们去做一些与几十年来的做法大不相同的事。一旦出了问题，不断重复的日常操练赋予我们的技能和经验，令我们可以撤回至安全区域并恢复正常运作。必要的做法包括营造一种勇于创新、敢于冒险（相对于畏惧或盲目服从命令）以及高信任度（相对于低信任度和命令控制）的文化，把至少20%的开发和IT运维周期划拨给非功能性需求，并且不断鼓励进行改进。
夜深了😪！
