返回首页
当前位置: 主页 > 精通Office > 其他教程 >

什么是 DevOps 三步工作法?

时间:2017-11-06 20:59来源:知行网www.zhixing123.cn 编辑:麦田守望者

三步工作法是什么?如何通过三步工作法来指导DevOps的整体实施?以及它的核心思路和基础原则?

一、DevOps与其他管理运动

我们再来看一下DevOps与精益、敏捷和其他的管理运动的关系。

  • 精益首先是精益,它是源自1980年代的丰田管理系统(TPS),关键实践包括价值流、看板和统一生产率维护方法等,目标是提升效率、减少浪费,通过小批量的工作缩短整个Lead Time。精益的原则聚焦在如何通过系统思考为用户创造价值。
  • 敏捷再来看下敏捷,2001年提出了《敏捷宣言》,敏捷里强调轻量级软件开发,小批量、增量式的发布,小的团队提升组织的效率。然后是2009年Velocity大会,这个会上Flickr公司提出Dev和Ops如何做更好的协作,实现每天10次线上发布。很多人包括Gene Kim、Patrick、John Willis都参加了这次大会,然后组建起来DevOps阵营。
  • 持续交付持续交付是2009年由Jez Humble和David Farley共同提出的,把持续集成做逻辑上的延展,形成持续交付的新方法。持续交付的核心概念是部署流水线,就是我们经常讲的Pipeline,Pipeline可以让我们确保代码和基础设施一直处于可部署的状态,所有签入到Trunk的代码都可以在安全的环境里部署。
  • 持续改进还有一个运动大家提得比较少,是2009年的TOYOTA KATA运动,这里面提出一个困惑,这么多公司去学习丰田,但是没有一个学习丰田精益实践的组织能够复制丰田工厂观察到的高效。大家都在学丰田,为什么我们回来用他们的方法实践,却达不到丰田的高度呢?实际上我们遗漏了一个最重要的实践:improvement kata,就是改进的模式。

    丰田之所以成功,因为他把改进作为日常工作的一部分,我们如果只是静态学习,别人有什么实践,我学习什么实践,这样不能达到卓越,我们需要保持持续改进。

DevOps本身的方法以及它的技术、架构、文化实践都参考了这些优秀的管理方法、管理运动、管理哲学,DevOps是以上这些方法的集大成者。

二、IT价值流与三步工作法

IT

下面我们来具体看看如何提升效率,在说具体方法之前先解释一个概念,什么叫做价值流。图中左边是生产价值流,指的是生产制造领域中设计、开发和交付产品所需要的活动,包括信息和材料的双重流动。聚焦在创造平顺和流式的工作,关注小批量,避免返工,减少在制品等。

右边是技术的价值流,也就是IT的交付过程,从需求提出到开发、测试、部署、发布、运营整个的过程。我们认为技术的价值流同样可以采用在生产制造价值流中经过验证有用的技术。技术价值流关注从商业的假设提出,到把它转化成技术辅助服务,最终交付价值给用户。

技术价值流的重点在于如何聚焦和缩短部署的前置时间,这里面有两个部分。首先是上游,设计、开发的部分。其次是下游,测试、运营的部分。

我们认为在设计、开发部分是精益产品开发过程,特点是高度的易变性和不确定性,需要有深度创新的工作。下游的测试和运营,我们希望它有更好的预测性和机械性,以最小的易变性完成工作。

怎么达到这个目标?有两个核心方法:

  • 一个是避免大批量工作从设计、开发价值流传递到测试、运营价值流,如瀑布流程或长分支。
  • 另外一个是,让测试、运营与设计、开发同时进行,确保价值流快速流动和高质量。

Lead Time

如何加快速度,我们要关注Lead Time和Process Time。

Lead Time是前置时间,从需求提出到需求被满足的整个周期。Process Time是从开始工作到工作结束,不包含在队列里等待的时间。Lead Time和Process Time之间的比率是非常重要的衡量效率指标,快速流动和缩短前置时间最重要的一个抓手就是要缩短队列中的等待时间,这可能是我们日常工作中非常容易忽略的。

下面是两个常见的场景:

  • 一个是传统的项目管理场景,大型复杂组织,紧耦合、单体应用,很稀有的集成测试环境,很长的测试和生产环境Lead Time,高度依赖手工测试,有特别多的审批流程。

    类似这种的大型项目基本结果都是一样的,整个周期时间很长,普遍数周甚至数月。

  • 另外一个场景,被认为是DevOps的典范,就像很多互联网公司做到的一样,在分钟级就可以完成从代码提交到上线的整个过程,包括从提交到自动化构建、自动化测试、手工探索性测试以及生产部署,所有这些事情可以很快完成。

    如何做到?需要开发提交代码之后快速收到验证反馈,可以让这个反馈更快的指出什么地方被破坏了、什么地方存在问题,可以持续将小批量代码签入代码库,执行自动化测试,可以自动化做发布、自动化部署。

    又因为整个系统模块都充分解耦,所以小团队可以高度自治,可以快速完成端到端流程。今天谈的是比较高阶的思路,如何从更宏观的角度去解决问题,我刚才提到的每个部分,包括如何做技术架构解耦,如何做自组织的适配,如何做到开发的自服务,这些内容在后面的分享里都会有详细的展开。

DevOps

下面我们进入到三步工作法最核心的部分。整个DevOps实施可以分解为三步:

  • 第一步是从左到右快速流动
  • 第二步是从右到左快速反馈
  • 第三步是在整个过程中持续学习。

每个部分我都做了一张总图,把核心思路做了梳理。

三、三步工作法的核心思路

3.1、三步工作法核心思路-Flow

Flow

第一部分是Flow,让价值快速流动,其中有六个实践,分别是:可视化、限制在制品、减少规模、减少交接数量、持续识别和拓展约束,以及在价值流中消除浪费

3.1.1 让工作可视化

可视化

让工作可视化。技术价值流和生产制造价值流的区别是工作不可视,工厂里面有物料的流动和堆积,如果发现大量堆积,说明这里有瓶颈、有排队。而IT交付价值流里看不到显而易见的堆积,很多问题被隐藏掉,直到最后爆出更大的问题。

在DevOps领域里,包括敏捷、精益的理念,都在提可视化,通过可视化去管理价值流动。

图中左下角是一个典型的看板,看板里把整个软件的生命周期分成需求调研、需求就绪,开发进行中、开发完成,测试过程中、测试完成,以及UAT测试、准生产、发布等不同的列。通过这些列的划分,管理工作单元的流动,快速发现问题和解决问题。

通过看板可以让工作可视化、管理流动,并度量整个交付周期,看板一定要跨越整个价值流。

在这里推荐一本书,何勉老师最近编写的《精益产品开发》,前一个月刚上市,我认为是在国内做看板比较权威和完整的理论与实践相结合的书,强烈推荐大家阅读,里面会讲很多看板的方法和原则,如何建立、如何实践。

这里还要强调,做工作的可视化要考虑全局而不是局部,如果仅仅度量开发的完成率、度量测试发现了多少缺陷、度量系统的可用性,这些都是局部的目标。

我们更关注全局、端到端的价值流动,如何整体加快从需求提出到生产部署的时间,去增加服务的可靠性和质量。精益里讲全局的改进大于局部的优化。这是可视化的概述,看板也有很多方法和实践,后面的分享里再逐步分解。

3.1.2 限制在制品

限制在制品。刚才讲了很多Handbook里面的内容,下面讲两个小的故事,来理解在制品的概念。

  • 第一个故事是“束水攻沙”,黄河千年以来都是由上游流下来很多泥沙,因为上游主要是在黄土高原,植被稀疏,泥沙不断流入黄河,导致黄河的河床不断抬高,所以我们叫黄河地上河,经常会有洪灾。

    明朝时一个很有名的水利专家叫潘季驯,提出“束水攻沙”的治黄方针,通过收紧河道,利用水的冲击力去冲击河底的泥沙,从而达到清淤防洪的目的。更科学的理解,如果我们把河道的横截面收窄,水流的量是固定的,河流的河道收窄,河流的速度会加快,会提升水流携带沙的能力,解决泥沙淤积的问题。

    “束水攻沙”,约束河道宽窄,把泥沙冲走,加快流速。在看板里很关键一个实践就是限制在制品,通过限制并行的任务数量,可以加速价值流动速度,并且帮助我们快速发现和解决问题。

  • 第二个故事是“水落石出”,这个词最早出现在苏轼的一首诗里,另外我们也可以把它演绎成湖水岩石效应。当一个湖里有很多水,水面很高,湖中的石块都被这些水覆盖,这时即使有大的暗礁人也看不到。当水量逐步减小,一些大的石块暴露出来,如果水量进一步减少,中等石块、小石块也逐步被发现。

    举一个亲身的例子,几年前我去一个银行参加他们新一代核心系统建设的工作,当时要求所有人996工作制,全银行包括外包都是怎么做的。但在具体执行的时候,虽然工作确实是早9点到晚9点,有些员工中午吃饭后去散散步,晚上去游游泳,保证时间跨度是在12个小时,但实际产出是不一样的。

    从领导的角度来讲,要求所有的员工996,可能很难看到哪块有瓶颈、哪块有问题,因为从表面上看所有人都很忙。

顶一下
(1)
100%
踩一下
(0)
0%
标签(Tag):DevOps 三步工作法
------分隔线----------------------------
------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
验证码:点击我更换图片
猜你感兴趣