《凤凰项目, 一个 IT 运维的传奇故事》

《凤凰项目》三位作者，向他们致敬。

• 基恩・金：Tripwire 有限公司的创始人，他担任公司 CTO 长达 13 年之久。在 Tripwire 公司，他一直热衷于研究如何提高 IT 组织的效能。
• 凯文・贝尔：他创建了信息技术流程研究所，他拥有 25 年的 IT 管理经验，为 CEO 和 CIO 们提供指导和建议。
• 乔治・斯帕福德：行业分析师，帮助 IT 组织更好地找到目标，明确必要条件，发现实现目标的方法。

故事内容

讲述了一位 IT 经理临危受命，在未来董事的帮助和自己三步工作法理念的支撑下，最终挽救了一家具有悠久历史的汽车配件制造商的故事。

小说揭示了管理现代 IT 组织与管理传统工厂的共通之处，让读者不仅能对如何管理 IT 组织心领神会，更重要的是将以完全不同于以往的视角来看待自己的工作环境。

核心概念

三步工作法

本书中阐述了一个原理：所有开发运维模式都来自 三步工作法，可以说它是我们平台开发运维的指导思想。

第一工作法

（流程自动化，快速迭代）：关于从开发到技术运营，再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作中心，并且不断为了整体目标（相对于开发功能完成率、测试发现 / 修复比例或运维有效性等局部目标）进行优化。

实践： 持续构建、持续集成、持续部署，按需创建环境、限制半成品，构建起能够顺利变更的安全系统和组织。

第二工作法

（保证上游的质量，避免返工）：是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快地发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量。

实践： 在部署管道中的构建和测试失败时 “停止生产线”、日复一日持续的改进日常工作、创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态、在开发和技术运营之间建立共同的目标和共同的解决问题的机制、建立普遍的产品遥测技术，让每个人都能知道，产品和环境是否在按设定的运行，以及是否达到了客户的目标。

第三工作法

（不断试错，持续改进）：是关于创造公司文化，该文化可带动两中风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训、理解重复和联系是熟练掌握的前提、尝试和承担风险让我们能够不懈地改进工作系统，这经常要求我们去做一些和以往做法大不相同的事。一旦出现问题，不断重复的日常操作赋予我们的技能和经验，令我们可以撤回至安全区域并恢复正常运作。

实践： 营造一种勇于创新、敢于冒险（相对于畏惧和盲目服从命令）以及高度信任（相对于低信任度和命令控制）的文化；把至少 20% 的开发和技术运营周期划拨给非功能性需求，并且不断鼓励进行改进。

四种工作类型

• 业务项目：多数开发项目所包含的业务举措，即业务部门的所有正式项目。

• IT 内部项目：可能由业务项目衍生出的基础架构或 IT 运维项目，以及内部生成的改进项目（如创建新环境和部署自动化）。这些项目经常并非集中跟踪， 而是属于预算所有者（例如数据库经理、 存储管理经理和分布式系统经理） 。

当IT运维成为瓶颈时， 这会导致问题， 因为不能轻易查明已经在内部项目中投放了多少生产能力。

• 变更：由上述两种类型的工作引起，往往在报修系统中被跟踪。在价值流的两个部分，开发和运维中应该统一管理变更。

• 计划外工作或救火工作：包括操作事故和操作问题，通常由以上三种类型工作导致，往往会牺牲其它计划内的工作为代码，成本往往很高。通过采用三步工作法，减少计划外工作，即使发生计划外工作，也能快速解决。

建立 ITSM 系统，并归类知识库，减少重复故障发生。

总结

目标：即拥有一条不断改进，能够自我反馈的自动化流水线。

• 开发运维并不仅仅是简单的自动化工具的集成，虽然自动化是开发运维的很大一部分内容。更重要的是价值流导向，自始至终拥有共同的目标并共同解决问题，需要把视野放得更大一些，而不是局限在运维的主机或服务上。

• 开发运维要提升自己的价值，就需要将自己的工作与最终的业务关系挂钩，了解自己运维的系统是如何影响着业务，所以开发运维需要有同公司一致的目标。

如书中比尔 与 约翰 在了解到公司业务目标后，思维一下子打开了，不再局限在眼前的系统与应用，而是有了更大的视野。他们一起约谈各业务部门负责人，清楚了解到各系统在业务上的位置，从而能够更好地去分配工作的优先级。