简要记录

• 1-3 比尔被迫接受IT运维副总裁职位，立即面临工资核算系统故障。尝试解决问题，发现团队缺乏协作和沟通，项目进展缓慢。终于找到了可能是一个SSN字段引起的问题，但为时已晚，只能被迫实施B方案，导致工资发放出错。
• 4 比尔又接到紧急任务，要在几天内计划和实施部署凤凰项目。比尔首先组织变更管理会议，但几乎没人出席。随后他再次发邮件，组织下一次会议，声明要坚决执行变更管理流程。
• 5 公司审计部门又来火上浇油，要求短时间内整改审计问题
• 6 变更管理会议终于召开了，大家得出“变更”的共识：对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作，并且这样的操作可能对相关服务产生影响。会议后大家确认了用白板卡片的方式来提交变更，并一口气提交了数百个变更，事情终于有了眉目。
• 7-8 比尔向老板史蒂夫汇报窘迫现状，但史蒂夫并不关心细节，只要求比尔“搞定它”。另外，比尔又发现了新提交上来400多个变更卡片，开始着手处理。
• 9 又发生了信用卡处理系统故障，成功处理后，团队也变得更有经验，并在下一次的会议上继续对变更进行讨论，尽量把变更提前，避开凤凰部署日。
• 10 发现部门大牛布伦特一直忙于解决公司其他问题，导致耽误了凤凰项目，比尔出手帮忙。
• 11 比尔发现60%的变更都没有按期完成，然后调查得知许多变更都依靠布伦特解决。比尔决定找出3级工程师来分担布伦特的工作。
• 12-13 凤凰项目强行上线，导致POS系统瘫痪、客户数据泄露、公司声誉受损。比尔焦头烂额，试图挽回局面。
• 14-15 凤凰失败后史蒂夫考虑外包IT，比尔与克里斯开始合作，试图挽救项目。比尔意识到了四类工作：项目工作、内部运营工作、变化引入工作（变更）和计划外工作。比尔找埃瑞克聊天，继续了解三步工作法、约束点等概念。
• 16 再次发生系统故障，比尔按照自己的全新方法已经开始有条不紊地带领团队解决问题。但是史蒂夫再次发难，要求比尔按照老样子迅速救火解决问题，但比尔毫不退让并提交辞呈。
• 17 离开后，IT部门迅速变得一团糟。史蒂夫恳请比尔回来上任。
• 18-20 比尔回归后，继续推动变更管理和三步工作法。团队逐渐适应新方法，凤凰项目也逐渐走上正轨。
• 21-22 比尔开始引入资源管理，并着手将布伦特的知识逐步文档化与传递。
• 23-24 解决约翰的问题。
• 25-27 开会开会。比尔提出两个提议：更好地定义由IT引发的业务风险；应该把发布变小变短。
• 28 项目步入正轨，凤凰项目修复后重新上线，稳定运行。但是，莎拉的项目仍然存在问题，比尔着手进行解决。
• 29 清算莎拉。第一工作法的内容：控制从开发部到运维部的工作流；第二工作法：建立从运维部返回至开发部的不间断的反馈回路。
• 30-31 比尔领会了快速部署的方式
• 32-34 依照新的团队运运作部署方式，独角兽项目大获成功。
• 35 完结撒花。

正文

笔者作为一位软件工程专业的学生，眼力有限，见识浅薄，读完《凤凰项目》后，觉得书中有些观点和篇章充满趣味，在此斗胆写下一些个人的看法和见解。与这学期之前读的其他书不同，《凤凰项目》这本书是一个小说，而且是笔者平常很少阅读的职场小说类型，读下来还是充满趣味的，是很新鲜的体验，也让我对 IT 运维职场有了更直观的认识（间接劝退了我投递运维岗的想法哈哈哈）。

故事始于一场职场噩梦：主角比尔在毫无准备的情况下被推上IT运维副总裁的位置，迎接他的是工资核算系统崩溃的烂摊子。他很快发现，团队如同一盘散沙：开发与运维互相指责，变更随心所欲，安全与审计部门各自为政，而业务高管（如莎拉）只知施加压力、索取结果。比尔又临危受命，被要求在短时间内计划和实施凤凰项目的部署。随着故事推进，比尔逐渐领悟到IT运维的核心挑战：如何在快速变化的业务需求与稳定可靠的系统运行之间找到平衡。他引入了变更管理流程，认识到了“约束点”“四类工作”等重要的概念，并推动团队采用三步工作法，强调跨部门协作与沟通。期间一波三折，比尔历经老板史蒂夫的发难和同行莎拉的阻碍，又克服了项目中的种种困难，通过这些努力，团队逐渐走出混乱，凤凰项目也最终成功上线。比尔按照新的运维理念，推动了独角兽项目的成功部署，彻底改变了公司的IT运维文化。

这本小说塑造了一个比较典型的“反派”:莎拉。莎拉作为业务部门的领导，代表了典型的“只求结果、不顾过程”的管理风格。她不断向IT部门施加压力，要求他们在不切实际的时间框架内交付复杂的项目，而忽视了系统稳定性和团队能力的限制。深入思考一下，莎拉的行为一定是错误的吗？笔者觉得也不尽然。莎拉的出发点其实是好的：她想通过推动业务创新来提升公司的市场竞争力。在高度竞争的商业环境中，快速响应市场需求确实至关重要。莎拉的挑战在于，她缺乏对IT运维复杂性的理解，导致她的要求往往脱离实际。这个角色提醒我们，业务领导者与技术团队之间需要建立更好的沟通和理解，才能实现真正的协同合作。刚读完书的时候，笔者也对莎拉没什么好感，但是仔细想想，其实自己可能也曾经是那个“莎拉”，或者周围生活中也充满了“莎拉”。而笔者认为，与其责怪“莎拉”，不如思考如何更好地桥接业务与技术之间的鸿沟。

书中的布伦特也是个很有意思的人物：他是团队里的技术大牛，几乎所有的复杂问题都要靠他来解决。但是，这也导致了一个严重的问题：布伦特成了瓶颈，团队的整体效率受到了限制。比尔意识到，依赖单一专家来解决问题是不可持续的，因此他开始推动知识共享和技能传递。笔者觉得，这个情节反映了现实职场中的一个普遍现象：技术专家往往成为团队的关键资源，但过度依赖他们会导致风险和效率低下。通过文档化知识、培训其他成员以及建立协作文化，可以有效地分散风险，提高团队的整体能力。这也是三步工作法的内容，带给笔者重要的启示：我们需要识别并解决瓶颈，并把工作流文档化，建立多级的支持体系，而不是把所有的工作都压在一个人身上。

关于书中的一些 devops 的启示，笔者就不多说了，懂的都懂。接下来，笔者主要还想来谈谈关于文中提到的四种工作类型：项目工作、内部运营工作、变化引入工作（变更）和计划外工作。笔者觉得这是一个非常有用的分类框架，帮助我们理解IT运维的多重职责。项目工作通常是指那些有明确目标和时间框架的任务，如部署新系统或升级现有应用，在书中对应的应该是凤凰项目、独角兽项目等等。内部运营工作则涵盖了日常维护和支持活动，确保系统稳定运行。变化引入工作主要涉及变更管理，确保任何对系统的修改都经过审慎评估和测试，以最小化风险。计划外工作则是那些突发事件，如系统故障或安全漏洞，需要即时响应和解决。主角比尔刚开始接手时，没有意识到计划外工作的重要性，后来才逐渐明白，计划外工作往往占据了大量时间和资源，必须通过更好的流程和工具来管理。笔者觉得，这四种工作类型的划分不仅适用于IT运维，也可以推广到其他领域的工作管理中，帮助我们更好地组织和优先处理任务。书中说得也很好：计划外工作并非偶然产生，而是由前三类工作中的不当行为产生的。这也解释了比尔为什么要坚持推动变更管理和三步工作法，来减少计划外工作的发生。

我还想谈谈一些书中并没有侧重描写的，但是隐晦之中透露出来的内容。首先是关于职场政治。比尔接手工作后，他的上司看似是会为他提供支持和帮助的史蒂夫，但史蒂夫也是被董事会管理层层层施压的无奈的个体。史蒂夫迫于自身的部分盲目认知和董事会的压力，常常向比尔疯狂施加不切实际的要求。这种职场政治的复杂性，笔者觉得是很多职场新人容易忽视的。理解和应对职场政治，是每个职场人必须掌握的技能。其次是关于会议。随着笔者逐渐深入的了解，发现对于那些大厂、大公司而言，开发人员往往用大量的会议来协调各方工作，而编码时间往往是比较少的。会议是双刃剑，好的会议可以促进沟通和协作，但过多或过低效的会议则会浪费时间和精力。在书中，比尔尽力推动有效的变更管理会议，确保每次会议都有明确的目标和产出。笔者觉得，这提醒我们在职场中要学会高效地组织和参与会议，避免无谓的时间浪费，这也可以让我们的编码效率更高。

《凤凰项目》告诉我们，无论是运营一个系统和项目，还是经营我们的学习生活，都需要系统化的思维和方法论。通过识别不同类型的工作，优化工作流程，推动协作与沟通，我们可以更有效地应对复杂的挑战。希望未来笔者能将这些理念应用到自己的学习和生活中，提升自己的效率和能力。