《凤凰项目》是DevOps界神书，虽然内容表现形式是小说，但是依然是敏捷开发及DevOps领域的必读书籍。很多知名的咨询师都是通过此书开启了DevOps及敏捷之旅，书中故事均来源于运维的日常工作，正是体现了艺术源于生活、高于生活的本质。笔者间隔两年时间，阅读此书两次，希望可以讲书中了解到的一些经验分享给大家。
小说主人公比尔，临时接任了IT运维经理的职位，然而此时，公司已经经历了多轮裁员，生产线上故障不断。董事会指望凤凰项目重启拯救公司，然而面对的着层层困难，比尔开始不停的应付突发的线上故障，身心俱疲。为了生存及公司的正常运转，尝试出一套适合该公司的IT转型方案，整个转型过程就像我们从传统开发模式转型DevOps的开发模式一样，踩过很多坑，总结出很多道理，小说的内容我不过多叙述，了解精彩的故事可以直接去购买图书，下面会给大家总结一下书中的一些重要的经验。
在故事中，主人公比尔在接替IT部经理后，通过一系列的故障处理与人际交流的过程中，得出了这个结论。IT的工作无非就是如下四种类型：
l IT部门内部项目
l 业务组项目
l 变更工作
l 救火工作
其实上述四种工作类型与我们目前运维部门的状态基本一致，我们需要开发自己的运维与监控平台，要参与到业务部门的开发测试中，要进行所有基础设施及应用版本的变更与升级。而这些都是属于正常的工作，我们往往最不愿意处理的就是救火工作，比如线上的突发故障导致的所有用户的功能无法使用，往往运维人员会在技术vp、cto、甚至ceo的注视下一行一行敲着命令，修复问题。大量运维人员应该都有过类似经历，回想起来一定是惨不忍睹，所以我们要减少这种救火工作，并把前三种工作合理分配。
从IT的四种工作形态中，我们引申出一个问题，如何减少救火行为呢，我们先看运维圈里的两个定律
l 著名的二八定律：线上 80% 的故障来自于2 0% 的变更。
l GoogleSRE理论： 大概 70% 的生产事故由某种部署的变更而触发
我们不去纠结8 0% 与7 0% 的差异是怎么产生的，但是结论是统一的，大量的线上的故障都是由于变更导致的，变更包括对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作。可以看到，这些内容覆盖了大量的运维工作了，为什么运维容易背锅呢，就是因为平时要处理这些高风险的变更操作，才容易引起线上的故障。而外人看来，运维就是在制造麻烦，之后开始救火工作、解决故障。为了避免种情况，该怎么处理呢？文章中给了我们很重要的方法，就是用看板的方法，规范化所有变更的管理，有计划的进行每一次变更，评估每次变更带来的风险点，就算出现故障，也可以快速修复。
在解决所有变更导致的故障的时候，小说中出现了一个重要的人，杜伦特，这是运维团队中的一个英雄角色，没有他解决不了的问题。但是就是这么厉害的一个人，所有开发人员都喜欢找他进行变更，所有的系统故障都需要他去处理，所以这么厉害的人，每天都从事的是救火工作。这个角色就变成了我们运维规范化过程中的一个瓶颈点。只要他的工作无法被其他人员替代，就无法让他去做运维团队更重要的事，比如自动化的建设，比如重要的监控建设。小说里为了解决这个问题，比尔设置了故障处理分级机制，把杜伦特保护起来，不允许开发人员直接与杜伦特沟通，同时安排其他工程师接触杜伦特原来的工作，让杜伦特的工作重心在自动化建设与监控建设上。这样在关键位置上增加了技术储备的同时，也将核心技术人员用在了最重要的位置上。
小说的名称叫《凤凰项目》，所以故事核心是围绕着凤凰项目来的，凤凰项目是一个计划了三年，经过了三年的憋大招勉强上线的一个项目，当然，准备了这么久的项目最后以失败告终，这个问题告诉我们什么呢。主人公在工厂车间意识到，如果工厂的人力是固定的，如果半成品积累的过多，就会导致最终成品交付给用户会变慢，这也就是我们在软件开发领域常说的在制品数量影响着交付的速度，如果开发团队同时迭代着过多的需求，那么必然需求交付到用户的手中的时间要延长。所以限制在制品数量是DevOps建设的一个核心内容，我们应该多做从0 -1 的事，而减少0 .5 的数量。书中总结的很好，一旦研发资本以半成品的形式锁定超过一年而未向公司返还现金，他就几乎不可能再为公司产生回报。
小说的最后作者总结了三步工作法，包含：
1) 流动原则
流动原则是DevOps 建设的基础，缩短满足客户需求的潜质时间，建立自动化工具链，减少人工干预过程，减小在制品数量，快速迭代，便可以有效地提高工作质量和产量。
2) 反馈原则
在源头发现问题，尽早发现问题，测试及安全左移，在生产的源头就要保证质量。
3) 持续学习与实验原则
把生产效率、工作流程上升到领导层，推进DevOps文化的落地。
总结：还等什么，买书去看吧，《凤凰项目》。
更多精彩内容可以专注我们的在线课堂
微信搜索公众号：jfrogchina 获取课程通知
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
