这本书是以小说形式讲解DevOps工作方式，讲的是主人公比尔临危受命，突然升职为公司分管IT运维的副总裁，升职并没有带来他和家人喜悦只有惊吓，他面临着处理公司业务系统时而发生的一级故障，面临着一周之内处理完安全部门内部审计提出的几百页问题，面临着一周后决定公司生死存亡的凤凰项目部署发布，面临着100多个业务项目，面临着每天新增加的几百个变更，还有公司高层的政治斗争。（感觉这人真是太惨了！）
幸运的是，主人公思路清晰、沉着冷静，遇到高人指点“三步工作法”，又有给力的下属。他建立了可视化变更流程，改变了大家（尤其开发人员）对于变更流程的厌恶，避免了因为不受控的变更而导致的业务系统故障。他找到了部门的约束点或者称为瓶颈，一个叫布伦特的工程师，凤凰项目、其他重要项目、业务系统故障、很多变更都依赖于布伦特，比尔采取了一系列措施，包括建立三级工程师库、改变工作到达布伦特的流程，保护布伦特，避免很多工作卡在布伦特这里无法流转到下一个工作中心。他建立了一套工作流，运用自动化工具提高部署效率，使公司更快响应市场需求。最终扭转自己的困局和公司的困局。
对于之前没有接触过DevOps的我来说，感觉看完这本书对于DevOps还没有一个整体的、清晰的认识，只有一个模糊的概念，以及对于一些细节方面的感受。
书中提到了一个等待时间的计算公式。
等待时间取决于资源使用率。等待时间是忙碌时间百分比除以空闲时间百分比。如果一个资源的忙碌时间是50%，那么它的空闲时间也是50%。等待时间就是50%除以50%，即一个时间单位。如果一个资源的忙碌时间是90%，那么它的空闲时间也是10%。等待时间就是90%除以10%，即9个时间单位。将是资源有50%空闲时的9倍。因此，每个人都需要空闲时间，否则半成品会卡在队列里干等着。
在工作中，虽然没有去计算过忙碌时间和空闲时间，但是回忆起来，在比较空闲的阶段，一件工作任务过来，我可以很快交付，目前比较忙碌，在我的待办清单里有些工作任务已经卡在那里两到三周了。
我应该怎么办？
我尝试过规定自己每周至少处理一项积压的工作任务，但是这个计划却很难执行。
一方面，我的确承担了太多的工作任务，很少有空闲时间；其实我并没有充分利用资源，有些流程化的工作，我应该整理好并移交出去，可是一直拖延，把这件事的优先级永远的排在了后面。整理后不能移交的部分，我也可以为以后节省自己重复思考的时间。
一方面，我经常会有计划外任务。
在计划外工作面前，所有计划内工作都被炽热的怒火点燃，烧毁周围的一切。
主人公比尔采取的很多措施，都成功避免了很多计划外任务。事实上，我也深受计划外任务之害，很多计划内任务不能按时完成。
那么我的计划外任务都来源于什么呢？首先是领导安排的，其次是应付检查，最后是不可控的反反复复的文档审核。
领导安排的事情不可避免，不过我可能需要改进我的归档系统，例如写方案时能够快速找到相关的参考资料。感觉又要开一个大坑，接下来要看关于整理术的书。
对于检查，我需要思考如何将检查内容落实在平时的工作中，并且把相关资料归集整理，不再需要临时抱佛脚，每次面对检查，不再需要各种加班补材料。
最后，是不可控的文档审核。我需要思考如何减少项目组对我的依赖，如何确保文档到我这里时，质量较高，不再需要反反复复的修改和复审。
参考书籍：
《凤凰项目：一个IT运维的传奇故事》Gene kim, kevin behr, george spafford 人民邮电出版社
