《凤凰项目》：客户的运维团队为什么这么慢

全书开篇，员工没有按时拿到工资。一次未经批准的变更让 Parts Unlimited 的发薪系统宕机。在客户现场经历过生产环境故障当天的人，都会认出这个场景。

《凤凰项目》（The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win）的作者是 Gene Kim、Kevin Behr 和 George Spafford，由 IT Revolution 于 2013 年 1 月 10 日首次出版。它以小说形式写成，讲的却是运维工作的运转方式。

前线部署工程师（FDE）为什么要读它，理由很简单。你在客户现场的大部分时间，都在别人的系统里、和别人的运维团队一起、按别人的变更流程干活。这本书能帮你理解他们为什么慢，以及你能帮上什么忙。

一个好工程师就能卡住整个系统

主人公 Bill 是一名 IT 经理。CEO 给他 90 天收拾烂摊子，否则整个部门都要外包出去。

出版方把这本书定位为学习三步工作法和约束理论的入门读物，这是 DevOps 的两条奠基原则。John Willis 称它是现代版的《目标》，即 Goldratt 讲约束理论的那部小说。

本文只谈第一步和第二步工作法，这是 FDE 在客户现场最常碰到的两条；第三步不在讨论范围内。下面值得记住的三点也不等同于三步工作法：其中两点建立在前两步之上，第三点来自变更控制。

书中最让人印象深刻的角色是 Brent。IT Revolution 的官方简介把他描述为一位才华出众却超负荷的工程师。由于总被拉去救火，Brent 的专业能力成了整个组织的瓶颈。

角色 Erik 给出的建议是：减少在制品（WIP），以提高效率和吞吐量。放到 Brent 身上，这条建议就具体了。如果每项任务都必须经过他，那么每放进来一项新任务，都只是排进他面前的队列，没有任何工作会因此完成得更快。

所以减少 WIP，意味着不再以超过瓶颈处理能力的速度往里塞工作。这也正是 Gene Kim 概括的第一步工作法的精神：看整个系统的表现，而不是各个孤岛的表现。写过这本书读后感的工程师 Sandor Dargo 也重申了这条来自工厂的经验：让在制品的数量保持在低位。

设想这样一个场景：客户的数据团队里只有一个人懂遗留数据管道，有十张工单在等着这个人。

为你的集成再开第十一张工单，只会让队列更长。反过来做：把这个人掌握的知识写成文档，再把不需要他的那部分工作自己做掉。

计划外工作从哪里来？

出版方页面重点介绍了四类工作。据 Dargo 的说法，前两类是业务项目和 IT 内部项目。它们会产生变更，而变更通常在工单系统里跟踪。

第四类是计划外工作，定义为挤占计划内工作、拖慢进度的紧急、被动式工作。

发薪事故说明了计划外工作通常从哪里开始：一次未经授权的变更。随后 Bill 成立了变更咨询委员会（CAB），负责审核和批准对 IT 系统的变更。

值得记住的因果链是：失控的变更会以计划外工作的形式回来，而这些工作会落到 Brent 这样的人身上，也就是那个本已超负荷的瓶颈。

对 FDE 来说，有件事值得早做。到客户现场的第一周，在部署任何东西之前，先问清楚他们的变更审批流程。如果下一次发薪事故是你引起的，客户就不会再信任你。

反馈必须流回写代码的人

第二步工作法讲的是建立从右到左的反馈回路，也就是从运维回到开发。FDE 恰好站在这个交汇点上。你看得到产品在真实环境里怎样出问题，总部的产品团队看不到。

客户现场的事故处理完后，不要停在系统恢复运行那一刻。给核心团队写一份简短说明，分三部分：哪次变更引发了事故，花了多久才发现，以及产品里应该修什么，好让下一次不必再救火。

按什么顺序读，简历上怎么写

Tim O’Reilly 写道，每个经历过失败 IT 项目的人都应该被强制读这本书。这话说得有点过，但如果你亲历过搞砸的项目，书中许多场景会熟悉得让人不舒服。

先读《凤凰项目》，因为小说读起来轻松。Gene Kim 指出，《DevOps 实践指南》（The DevOps Handbook）对三步工作法有更深入的应用，所以它是第二本。如果想了解“流动”的理念如何从制造业中产生，最后再读《目标》（The Goal）。

简历上不要写“具备运维和 DevOps 经验”这类泛泛之词。要写具体的工作，例如：“为一条客户只有一名工程师懂的遗留数据管道编写运维手册（runbook），让对方团队能自行处理常见事故。”

这句话让招聘方看到，你能发现瓶颈并把它消除。如果你手里有前后对比的工单数或等待时长等真实数据，也写上。

Bill 有 90 天拯救 IT 部门。FDE 赢得客户信任的时间通常更短，而最快的办法仍然是：别让自己成为那次未经批准的变更。