难道安全问题不重要么？显然重要。但关键在于，你从什么维度，从什么视角来看待它、解决它。你需要把 IT 的价值流与其他部门的价值流连通起来，这样，顺畅的 IT “管道”才能更高效、更安全、更稳定地向整体战略输送养料。正如文中比尔、约翰他们在评估工作的优先级时，正是从准确理解业务目标开始，分离出核心任务，再进一步通过优化工作流来提升 IT 的价值流的。也就是说你需要从全局视角，来理解 IT 工作的的价值。同时，理解如何从工作流角度而非业务功能角度看 IT 工作，超脱角色限制。
此外，书中还有三个不错的知识点。
首先是关于等待时间的讨论，它告诉我们
等待时间 = 忙碌时间百分比 / 空闲时间百分比
所以有下面这张图（也是书中唯一一张图表）：
可以看到，当忙碌时间百分比超过 80% 时，等待时间将呈几何级上升。
其次，是“四种工作内容”：业务项目、IT 内部项目、变更和计划外工作（救火）。这四种工作构成了 IT 运维（或者也可以说就是 IT）的最主要工作。其中计划外工作往往是由于其他工作或流程上的疏忽带来的额外工作，是有负向影响的。例如你正按计划在开发报表系统，这时候突然数据库发生故障，这就是一个计划外的工作。而重点就是尽量去避免计划外的工作，从源头上遏制住它。
此外，书中提到了三步工作法：
第一工作法是关于从开发到 IT 运维再到客户的整个自左向右的工作流。我们希望流量最大化，减小批量规模和工作间隔。
《凤凰项目：一个 IT 运维的传奇故事》里其实借鉴了很多“生产运作管理”和“精益生产”的思想与知识。鉴于我也修过“生产运作管理”这门课，所以读起来也有些亲切。书中艾瑞克反问比尔：“你以为 IT 运维管理会比管理一个生产车间更复杂、更高深么？”我不知到究竟哪个更加高深，但我相信，从其他的先行领域中借鉴思想，寻找解决方案是一个聪明的做法，从来如此。
《凤凰项目：一个 IT 运维的传奇故事》虽然是一本和 DevOps 相关的“技术书”，但主体内容其实是使用小说的形式呈现的。
故事的主人公比尔原本只是一个中型机管理部的技术经理，但公司面临 IT 项目危机，他临危受命，出任 IT 运维副总裁。别以为这是个美差，对于他来说，走出舒适圈，在经验不足的同时，面临的是几近崩溃的 IT 状况 💢：
面对这些问题，本书从主人公比尔的第一视角展开，带我们看了他如何从迷茫、出入门道、找到方向到最后解决问题，最终帮助公司扭亏为盈的传奇“历险故事”。文中没有大段的说教、公式、定律，抛开这些教科书式的内容形态，这本技术书以小说的形式来阐述，引人入胜，完全不无聊。如果不是想规范自己的作息，很多次我都想通宵刷完。
通过故事的方式来阐述有一个非常突出的有优点，所有的理论和方法不再是冷冰冰的文字，你可以从主人公面临的问题开始，一步步推演出解决方案与最佳实践。更好的是，很多章节都以问题结束，这时候你可以自然地停下来，思考如果是你，你会怎么办，然后再来揭开“答案”。文中有很多方法论，可能需要你在实践中体会才能更深入地理解。所以我不准备罗列所有这些，只是简单谈谈一些印象比较深刻的地方。
书中其实有一个非常内核的问题：IT 的价值流到底是什么样的？这既需要你回答，IT 工作是如何流动的，同时，还需要你认识到，IT 也是业务价值的生产部门，这就意味着，你需要让这个价值流/工作流更好地与上下游部分对接。文中一个典型案例就是信息安全部门的负责人约翰。他一直强调安全的重要性，并一直抱怨着大家对他们的安全工作重视太低，这似乎也符合我们技术人的直觉。但直到有一次，一个关乎公司存亡的安全审计在没有他的安全部门的帮助下，而是通过业务部门的努力被成功化解了，他才开始反思。正如书中的大师艾瑞克告诫他的那样：如果他（约翰）搞不清楚业务部门是如何在没有安全部门的帮助下渡过安全危机的，那他就不可能做出“好事”。
难道安全问题不重要么？显然重要。但关键在于，你从什么维度，从什么视角来看待它、解决它。你需要把 IT 的价值流与其他部门的价值流连通起来，这样，顺畅的 IT “管道”才能更高效、更安全、更稳定地向整体战略输送养料。正如文中比尔、约翰他们在评估工作的优先级时，正是从准确理解业务目标开始，分离出核心任务，再进一步通过优化工作流来提升 IT 的价值流的。也就是说你需要从全局视角，来理解 IT 工作的的价值。同时，理解如何从工作流角度而非业务功能角度看 IT 工作，超脱角色限制。
此外，书中还有三个不错的知识点。
首先是关于等待时间的讨论，它告诉我们
所以有下面这张图（也是书中唯一一张图表）：
可以看到，当忙碌时间百分比超过 80% 时，等待时间将呈几何级上升。
其次，是“四种工作内容”：业务项目、IT 内部项目、变更和计划外工作（救火）。这四种工作构成了 IT 运维（或者也可以说就是 IT）的最主要工作。其中计划外工作往往是由于其他工作或流程上的疏忽带来的额外工作，是有负向影响的。例如你正按计划在开发报表系统，这时候突然数据库发生故障，这就是一个计划外的工作。而重点就是尽量去避免计划外的工作，从源头上遏制住它。
此外，书中提到了三步工作法：
文中的三步工作法给我很大启发，虽然它具体落地是在 DevOps 上，但其思想内核在在或大或小地方都是可以用到的。它表述了的三部分是：
就拿推行单元测试这个技术例子来说，你需要思考的不光是什么单测框架好用、怎样给一个私有方法写测试，而是要去分析从业务需求到产生单测再到最后输出的整个流程，清楚它是如何从业务价值里流向来的，并通过“约束理论”等方法来优化它。那建立反馈机制呢？例如一个可能的方式是通过单测经验或报告来对反哺开发团队，提高其效率与系统的稳定性。而最后一步工作文化呢？千万不要小看它，技术只是一种解决手段，在很多 DevOps 的分享中也会在开篇章节就强调：DevOps 更重要的是一种文化，是一系列价值观，你只有认同它，技术工具才有发挥的空间。试想，如果每个开发人员、测试人员都不认同单元测试的价值，那么即使强制推行了，写出来的测试代码也不过是为了通过测试覆盖率的累赘，既不能提升软件的可靠性，也不能提高研发效率，久而久之，反而会带来副作用，影响产研团队，阻碍业务发展。
最后，提一下书里留给我影响很深的一个理论 —— 约束理论。它表明，在约束点之外的任何地方做的任何改进都是徒劳无功的。因此，我们需要去解决约束点的问题，解决的步骤一般是：
不过本书只是引用了一些约束理论的方法论，如果想深入理解我可能得再去读一读高德拉特的《目标》这本书了。
《凤凰项目：一个 IT 运维的传奇故事》里其实借鉴了很多“生产运作管理”和“精益生产”的思想与知识。鉴于我也修过“生产运作管理”这门课，所以读起来也有些亲切。书中艾瑞克反问比尔：“你以为 IT 运维管理会比管理一个生产车间更复杂、更高深么？”我不知到究竟哪个更加高深，但我相信，从其他的先行领域中借鉴思想，寻找解决方案是一个聪明的做法，从来如此。