继续浏览精彩内容
慕课网APP
程序员的梦工厂
打开
继续
感谢您的支持,我会继续努力的
赞赏金额会直接到老师账户
将二维码发送给自己后长按识别
微信支付
支付宝支付

DevOps的三步工作法

慕神8447489
关注TA
已关注
手记 1310
粉丝 174
获赞 957

作者介绍

张乐

DevOps时代联合创始人,高效运维社区合伙人,DevOpsDays大会、GOPS全球运维大会金牌讲师。国内首批DevOps Master,前百度资深敏捷教练、架构师。超过十四年敏捷转型、工程效能提升和大型项目管理实践经验,曾主导数百人团队实施DevOps转型,在保证质量的前提下发布频率提高数倍。

本文将介绍《DevOps Handbook》全书的核心:三步工作法。《DevOps Handbook》全书就是从三步工作法的思路出发,进行知识体系的组织和实践的编排。

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

一、DevOps与其他管理运动

webp

image


我们再来看一下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,就是改进的模式。

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

  • 在这里向大家推荐一个测试学习交流群:175317069。

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

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

webp

image


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

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

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

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

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

  • 一个是避免大批量工作从设计、开发价值流传递到测试、运营价值流,如瀑布流程或长分支。

  • 另外一个是,让测试、运营与设计、开发同时进行,确保价值流快速流动和高质量。

webp

image


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

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

下面是两个常见的场景:

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

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

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

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

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

webp



作者:TeacherAilie
链接:https://www.jianshu.com/p/17d38ec275de


打开App,阅读手记
0人推荐
发表评论
随时随地看视频慕课网APP