读《凤凰项目》有感

一个IT运维的传奇故事。

概述

《凤凰项目，一个IT运维的传奇故事》描述了一个IT运维部副总裁比尔上任第一天就面临了工资核算系统崩溃的问题。在之后的两个月内，接连出现安全性审计整改、凤凰项目被迫强制上线导致多系统异常等灾难，用户信任度大幅下降，企业生存状态岌岌可危，甚至面临整个IT部被外包的局面。

在本书“扫地僧”埃瑞克的帮助下，主人公比尔及其部下积极完善变更控制流程，协同开发部、IT运维部和安全部，贯彻落实“三步工作法”。将DevOps与敏捷开发的思想引入到新项目“独角兽”并逐步扩散到整个IT部门，力挽狂澜，大幅提升了企业竞争力。

本书以小说的形式描写IT部门遇到的重大事故、问题解决不顺利、部门间推诿埋怨、新流程制度引入困难到逐渐好转、IT变更流程标准化等历程。情节跌宕，让IT从业者深感共鸣。书中将IT运维与工厂车间制造相类比，强调了生产瓶颈、流程标准化、产品交付周期与预期收益等对IT部门的启示，令人茅塞顿开。

其中总结几个触动比较大的点。

约束点理论

木桶的盛水量并不取决于筒壁上最高的木板，而是取决于最短的那块。约束点（瓶颈）限制了产能，限制了部署效率，本书中首席工程师布伦特便是整个IT部的约束点。很多项目只有他了解，因此绝大多数的项目交付时，或多或少地需要他参与其中。他的不可替代性以及满负荷工作让他无法完成凤凰项目的相关工作，引爆了本书的主要矛盾。

正如创建约束理论的艾利·高德拉特告诉我们，在瓶颈之外的任何地方作出的改进都是假象。在瓶颈之后作出任何改进都是徒劳的，因为只能干等着瓶颈把工作传送过来。而在瓶颈之前作出的任何改进则只会导致瓶颈处堆积更多的库存。因而，正确的决定应围绕对约束点的优化展开。

书中列举出一个流经布伦特的30分钟的工作受约束点限制需等待63小时，并附上等待时间与资源使用率的关系图。对于约束点而言，其使用率接近满负荷，因此新流经约束点的工作势必会等待很长时间，从而拖慢整体效率。

值得庆幸的是，比尔很快地意识到这一点，迅速冻结流经约束点的除凤凰项目之外所有项目，以便让约束点处积压的任务得以纾解。在项目解冻时，对约束点处的项目予以限流，保证其对核心项目（凤凰）的支持程度，并将可以提升约束点性能的监控项目优先级调高，大幅缓解了约束点处的限制，为IT流程的有序进行奠定了基础。

部门协作

造成书中IT部门的混乱的”功臣“无疑是糟糕的部门协作了。开发部、IT运维部、安全部看上去各司其职，但却相互限制，事故出现后相互推诿、相互抱怨，是一场“不协调的婚姻”。以IT运维部的视角举例：比一名开发人员更危险的就是开发人员和信息安全部门的人联手。这样的组合把给我们添乱的动机、手段和机会都弄齐全了。

这种协作的矛盾在我看来核心原因是其职能边界过分独立。开发部将相关开发代码交给运维部；运维部整合开发包、配置、环境进行部署；安全部事后打安全补丁。瀑布模型下分明的流水线并没有提升产品交付效率，反而放大上游的错误，引入下游干预产生的负面影响。书中列举中几个协作失调的案例：

• 安全部一个数据库字段变更导致工资核算系统崩溃，运维部耗费大量时间排查原因。
• 开发部将所有变更申请标为急或者紧急变更，扰乱运维部的处理优先级。
• 开发部版本/制品管理混乱，运维部拿到错误/陈旧/不完整的开发包及配置，导致部署失败。
• 运维部对生产环境引入了某个更改，没有同步到开发、QA环境，导致测试通过的项目在生产环境中部署失败。

过于独立的职能边界导致了庞大的部门间工作流转开销，成为拉长部署周期的元凶。

受生产车间将约束点“烘房”与“喷漆室”两个工作中心合并提升产能的启迪，部门协作的方式也进行相应的调整，部门间不是彼此独立的上下游关系，而是各阶段通力合作，互相渗透。运维部提供一组通用的搭建环境的方案（IaC），开发部在代码提交后便可以自行验证、部署（CI/CD）；安全部也不用再事后对部署安装安全补丁，而在一开始便对开发过程和生产环境提出安全标准（DevSecOps），并在开发、部署等阶段对潜在的漏洞进行攻击检测。各部门不再仅陷于自己部门的目标，而着眼于企业目标，缩短产品发布周期，提升企业核心竞争力。

这正是DevOps诞生的最佳时机。

三步工作法

书中提出的三步工作法正是敏捷开发的原型：

• 第一工作法是关于从开发到IT运维再到客户的整个自左向右的工作流。通过小批量的规模和工作间隔，最大化系统流量。
• 第二工作法是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，更快地发现和修复问题。
• 第三工作法是关于创造公司文化（敏捷无疑是一种公司文化）。要勇于尝试、加强演练，不断给系统施加压力，从而不断强化习惯并加以改进，因为对任何流程或技能来说，训练成习惯， 习惯成精通 。系统里要经常出些故障，长此以往，再遇到困难就没有原来那么痛苦了。

三步工作法需要我们计划发布内容，把控发布节奏，保障代码总是处于可部署的状态的同时，通过CI/CD、自动化测试加速发布与部署效率；此外还需对已发布的系统进行监控，快速获取反馈并进行持续优化改进。

总结

本书阐释了开发部和IT运维部之间长期的核心冲突为何会导致整个IT组织及其所服务企业的失败。如果不加以抑制，冲突会拖延开发部的上线时间，并在功能发布期间导致时间更长、问题更多的部署，增加1级严重级别服务中断的数量，而IT运维部则要做越来越多的计划外工作，难以清偿技术债务。

而扭转乾坤的力量正是敏捷与DevOps。围绕约束点制定计划优先级以最大化生产效率；推进企业的信息化集成以减少线上事故，统一IT资源；实施短平快的产品发布以跟上市场节奏。

在敏捷文化与DevOps盛行的今天，我们很少能知道自己究竟避开了哪些灾难。但就其演进的历程来看，技术早已为首要的价值创造过程，并已成为绝大多数公司获得客户的越来越重要的(而且常常是基础性的)一种手段。