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

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

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

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

  • IT的四种工作形态

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

  • IT部门内部项目
  • 业务组项目
  • 变更工作
  • 救火工作

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

  • 加强变更管理,减少救火行为

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

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

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

  • 加强技术储备,避免个人英雄主义

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

  • 限制在制品数量,多做从0到1,减少0.5的数量(看板)

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

 

  • 三步工作法

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

  • 流动原则

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

  • 反馈原则

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

  • 持续学习与实验原则

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

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

 

​更多精彩内容可以专注我们的在线课堂

微信搜索公众号:jfrogchina 获取课程通知

 

K8S中文社区微信公众号

评论 抢沙发

登录后评论

立即登录