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

提高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 获取课程通知

原文地址:https://blog.51cto.com/jfrogchina/2480154

时间: 2024-10-22 09:48:32

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

带你玩转Visual Studio——带你跳出坑爹的Runtime Library坑

在Windows下进行C++的开发,不可避免的要与Windows的底层库进行交互,然而VS下的一项设置MT.MTd.MD和MDd却经常让人搞迷糊,相信不少人都被他坑过,特别是你工程使用了很多第三库的时候,及容易出现各种链接问题.看一下下面这个错误提示: LIBCMT.lib(_file.obj) : error LNK2005: ___initstdio already defined in libc.lib(_file.obj) LIBCMT.lib(_file.obj) : error LN

凤凰项目读后感---DevOps运维思想

序:最近,在大神的推荐下,读了这本 <凤凰项目-一个IT运维的传奇故事>,让我感觉很兴奋,自己的眼界突然大了起来,感觉 有种打通任督二脉的感觉,尤其是 提到 三种工作法时,更是让我 联想到之前自己读过的书籍<用户上瘾模式>,<这就是OKR>,发现虽然内容不同,但是 其中的 精华是相通的. 内容回顾:本书通过讲解 一个新上任 的 运维副总裁-比尔 接手运维团队,从开始就 处理 工资系统瘫痪这个 一级事故,到接受高人指点 进行事故处理的反思,优化,重构,继续处理新故障,到部

ListView添加项目带序列

function AddSelItems(listview1:TListView;ListView2:TListView):Boolean;var  s: string;  I,j: Integer;begin  Result:=False;  if listview1.Selected =nil then  exit;   for i := 0 to listview1.items.count - 1 do  begin     j:=ListView2.Items.Count;    if

解读(五):分析KeyboardFragment, 带文字和表情的评论发表面板

解读(五):分析KeyboardFragment, 带文字和表情的评论发表面板 其实就是这个常见的功能 这个功能涉及到很多类, 我一个一个分析 KeyboardFragment类 /** * 底部带emotion面板的文字和表情的评论功能的Fragment **/ public class KeyboardFragment extends BaseTabNavFragment { @Bind(R.id.et_input) EditText mInput; //输入框 @Bind(R.id.emo

《凤凰项目》读书笔记

最近把<凤凰项目>刷了一遍,感觉都像发生在我们身边每一天的故事,把一些重点和自己的思考记录了下来: *四类工作: 1.业务项目 2.内部IT项目 3.变更 4.计划外工作 业务项目, 内部IT项目, 以及变更. 还有一种类型的工作,也许是最重要的一类,因为它的破坏性实在很强. 第四类工作是计划外工作. 与其他种类的工作不同,计划外工作是恢复性工作,几乎总是让你远离目标.因此,知道你计划外工作从何而来就显得尤为重要 *三步工作法: 第一工作法是关于从开发到IT运维再到客户的整个自左向右的工作流.

web.xml详细解读(flex项目,框架:cairngorm--blazeDS--spring--ibatis)(正在编写中)

<listener> <listener-class>flex.messaging.HttpFlexSession</listener-class> </listener> HttpFlexSession 是 BlazeDS 提供的一个 Listener,负责监听 Flex 远程调用请求,并进行一些初始化设置 <listener> <listener-class> org.springframework.web.util.Log4jC

杰蛙&博云 强强联手带你走进【企业级DevOps转型之旅】

杰蛙&博云 强强联手带你走进[企业级DevOps转型之旅] 原文地址:https://blog.51cto.com/jfrogchina/2479799

108天南京银行完成不可能完成的新金融DevOps转型

在2018云栖大会南京峰会企业研发云专场,由南京银行研发管理负责人吴攀带来了"云效助力新金融DevOps转型--南京银行实践之路"的主题分享.首先对南京银行的研发规模与成长做了介绍,对"鑫云+"的诞生和其架构应用做了详细的讲解. (云效公有云周年折扣活动进行中红,包年55折优惠中!) 以下为精彩视频内容整理: 南京银行研发规模概况 简单给大家介绍一下南京银行现在的规模,南京银行的科技现在有运维中心.研发中心和科技管理部,我是在科技管理部负责配置管理和研发过程管理.我

DevOps 转型之 Pipeline 实践

DevOps 转型之 Pipeline 实践 由于技术更新速度越来越快,业务需求变化频度激增,DevOps 如何落地,寻找合适切入点很关键,充分利用 Jenkins Pipeline 在 DevOps 和持续集成中的的核心作用,本主题将在 DevOps 工具链的选型以及如何落地实践做介绍. Pipeline 流水线是指软件从版本控制库到用户手中这一过程的自动化实现是持续交付与 DevOps 的核心工程实践. 本次分享主要内容: DevOps 工具链与 Pipeline Jenkins Pipel