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

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

《凤凰项目》是DevOps界神书，虽然内容表现形式是小说，但是依然是敏捷开发及DevOps领域的必读书籍。很多知名的咨询师都是通过此书开启了DevOps及敏捷之旅，书中故事均来源于运维的日常工作，正是体现了艺术源于生活、高于生活的本质。笔者间隔两年时间，阅读此书两次，希望可以讲书中了解到的一些经验分享给大家。

小说主人公比尔，临时接任了IT运维经理的职位，然而此时，公司已经经历了多轮裁员，生产线上故障不断。董事会指望凤凰项目重启拯救公司，然而面对的着层层困难，比尔开始不停的应付突发的线上故障，身心俱疲。为了生存及公司的正常运转，尝试出一套适合该公司的IT转型方案，整个转型过程就像我们从传统开发模式转型DevOps的开发模式一样，踩过很多坑，总结出很多道理，小说的内容我不过多叙述，了解精彩的故事可以直接去购买图书，下面会给大家总结一下书中的一些重要的经验。

1.IT的四种工作形态

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

1. IT部门内部项目
2. 业务组项目
3. 变更工作
4. 救火工作

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

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

从IT的四种工作形态中，我们引申出一个问题，如何减少救火行为呢，我们先看运维圈里的两个定律

1. 著名的二八定律：线上80%的故障来自于20%的变更。
2. GoogleSRE理论：大概 70% 的生产事故由某种部署的变更而触发

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

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

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

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

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

 

5. 三步工作法

小说的最后作者总结了三步工作法，包含：

(1)流动原则

流动原则是DevOps建设的基础，缩短满足客户需求的潜质时间，建立自动化工具链，减少人工干预过程，减小在制品数量，快速迭代，便可以有效地提高工作质量和产量。

(2)反馈原则

在源头发现问题，尽早发现问题，测试及安全左移，在生产的源头就要保证质量。

(3)持续学习与实验原则

把生产效率、工作流程上升到领导层，推进DevOps文化的落地。

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

 

更多精彩内容可以关注我们的在线课系列课程

系列课程背景

在过去的一年中，微服务，持续交付和 Kubernetes等概念关注度持续提升，而互联网，大型企业里对于持续交付的培训并不专业，导致团队成员上手慢，对流程不清晰，沟通成本高。

基于此痛点，我们推出了基于 Sping Cloud 微服务，Kubernetes 的持续交付系列课程，并且以一个 GuestBook 的实战项目进行持续发布，让学员从理论，到代码实战，深入的理解基于容器，微服务的持续交付过程。

系列课程收益

此课程是首个专注于微服务的持续交付课程，通过学习课程，学员能够理解 Spring Cloud 的基础知识，以及如何进行打包，自动化测试，Jenkins持续集成，以及基于 Kubernetes 部署，让学员能够端到端的提升职业技能，是学员升职加薪，走向全栈架构师的必备课程。

本期课程日程

1. 深入介绍 Spring Cloud 核心组件 Eureka
2. 网关 Zuul
3. 服务追踪 Zipkin
4. 配置管理 Spring Cloud Config

本期课程收益

-学员能够深入了解 Spring Cloud 组件的实现原理
-通过样例代码快速体验 Spring Cloud

报名链接：https://www.bagevent.com/event/6423668