解读神书《凤凰项目》，带你跳出DevOps转型的所有坑

Posted 2020-11-26

提高DevOps工程师软技能，可以了解一下笔者前一篇文章《DevOps工程师必备软技能》

《凤凰项目》是DevOps界神书，虽然内容表现形式是小说，但是依然是敏捷开发及DevOps领域的必读书籍。很多知名的咨询师都是通过此书开启了DevOps及敏捷之旅，书中故事均来源于运维的日常工作，正是体现了艺术源于生活、高于生活的本质。笔者间隔两年时间，阅读此书两次，希望可以讲书中了解到的一些经验分享给大家。
小说主人公比尔，临时接任了IT运维经理的职位，然而此时，公司已经经历了多轮裁员，生产线上故障不断。董事会指望凤凰项目重启拯救公司，然而面对的着层层困难，比尔开始不停的应付突发的线上故障，身心俱疲。为了生存及公司的正常运转，尝试出一套适合该公司的IT转型方案，整个转型过程就像我们从传统开发模式转型DevOps的开发模式一样，踩过很多坑，总结出很多道理，小说的内容我不过多叙述，了解精彩的故事可以直接去购买图书，下面会给大家总结一下书中的一些重要的经验。

1. IT的四种工作形态

在故事中，主人公比尔在接替IT部经理后，通过一系列的故障处理与人际交流的过程中，得出了这个结论。IT的工作无非就是如下四种类型：

• IT部门内部项目
• 业务组项目
• 变更工作
• 救火工作
  其实上述四种工作类型与我们目前运维部门的状态基本一致，我们需要开发自己的运维与监控平台，要参与到业务部门的开发测试中，要进行所有基础设施及应用版本的变更与升级。而这些都是属于正常的工作，我们往往最不愿意处理的就是救火工作，比如线上的突发故障导致的所有用户的功能无法使用，往往运维人员会在技术vp、cto、甚至ceo的注视下一行一行敲着命令，修复问题。大量运维人员应该都有过类似经历，回想起来一定是惨不忍睹，所以我们要减少这种救火工作，并把前三种工作合理分配。

  2. 加强变更管理，减少救火行为

  从IT的四种工作形态中，我们引申出一个问题，如何减少救火行为呢，我们先看运维圈里的两个定律
  著名的二八定律：线上80%的故障来自于20%的变更。
  GoogleSRE理论：大概 70% 的生产事故由某种部署的变更而触发
  我们不去纠结80%与70%的差异是怎么产生的，但是结论是统一的，大量的线上的故障都是由于变更导致的，变更包括对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作。可以看到，这些内容覆盖了大量的运维工作了，为什么运维容易背锅呢，就是因为平时要处理这些高风险的变更操作，才容易引起线上的故障。而外人看来，运维就是在制造麻烦，之后开始救火工作、解决故障。为了避免种情况，该怎么处理呢？文章中给了我们很重要的方法，就是用看板的方法，规范化所有变更的管理，有计划的进行每一次变更，评估每次变更带来的风险点，就算出现故障，也可以快速修复。

  3.加强技术储备，避免个人英雄主义

  在解决所有变更导致的故障的时候，小说中出现了一个重要的人，杜伦特，这是运维团队中的一个英雄角色，没有他解决不了的问题。但是就是这么厉害的一个人，所有开发人员都喜欢找他进行变更，所有的系统故障都需要他去处理，所以这么厉害的人，每天都从事的是救火工作。这个角色就变成了我们运维规范化过程中的一个瓶颈点。只要他的工作无法被其他人员替代，就无法让他去做运维团队更重要的事，比如自动化的建设，比如重要的监控建设。小说里为了解决这个问题，比尔设置了故障处理分级机制，把杜伦特保护起来，不允许开发人员直接与杜伦特沟通，同时安排其他工程师接触杜伦特原来的工作，让杜伦特的工作重心在自动化建设与监控建设上。这样在关键位置上增加了技术储备的同时，也将核心技术人员用在了最重要的位置上。

  4.限制在制品数量，多做从0到1，减少0.5的数量（看板）

  小说的名称叫《凤凰项目》，所以故事核心是围绕着凤凰项目来的，凤凰项目是一个计划了三年，经过了三年的憋大招勉强上线的一个项目，当然，准备了这么久的项目最后以失败告终，这个问题告诉我们什么呢。主人公在工厂车间意识到，如果工厂的人力是固定的，如果半成品积累的过多，就会导致最终成品交付给用户会变慢，这也就是我们在软件开发领域常说的在制品数量影响着交付的速度，如果开发团队同时迭代着过多的需求，那么必然需求交付到用户的手中的时间要延长。所以限制在制品数量是DevOps建设的一个核心内容，我们应该多做从0-1的事，而减少0.5的数量。书中总结的很好，一旦研发资本以半成品的形式锁定超过一年而未向公司返还现金，他就几乎不可能再为公司产生回报。

5.三步工作法

小说的最后作者总结了三步工作法，包含：
1)流动原则
流动原则是DevOps建设的基础，缩短满足客户需求的潜质时间，建立自动化工具链，减少人工干预过程，减小在制品数量，快速迭代，便可以有效地提高工作质量和产量。
2)反馈原则
在源头发现问题，尽早发现问题，测试及安全左移，在生产的源头就要保证质量。
3)持续学习与实验原则
把生产效率、工作流程上升到领导层，推进DevOps文化的落地。

总结：还等什么，买书去看吧，《凤凰项目》。

?更多精彩内容可以专注我们的在线课堂
微信搜索公众号：jfrogchina 获取课程通知