DevOps实战笔记
石雪峰
京东商城工程效率专家
立即订阅
3436 人已学习
课程目录
已更新 30 讲 / 共 35 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从默默无闻到风靡全球,DevOps究竟有什么魔力?
免费
基础理论篇 (4讲)
01 | DevOps的“定义”:DevOps究竟要解决什么问题?
02 | DevOps的价值:数字化转型时代,DevOps是必选项?
03 | DevOps的实施:到底是工具先行还是文化先行?
04 | DevOps的衡量:你是否找到了DevOps的实施路线图?
落地实践篇 (16讲)
05 | 价值流分析:关于DevOps转型,我们应该从何处入手?
06 | 转型之路:企业实施DevOps的常见路径和问题
07 | 业务敏捷:帮助DevOps快速落地的源动力
08 | 精益看板(上):精益驱动的敏捷开发方法
09 | 精益看板(下):精益驱动的敏捷开发方法
10 | 配置管理:最容易被忽视的DevOps工程实践基础
11 | 分支策略:让研发高效协作的关键要素
12 | 持续集成:你说的CI和我说的CI是一回事吗?
13 | 自动化测试:DevOps的阿克琉斯之踵
14 | 内建质量:丰田和亚马逊给我们的启示
15 | 技术债务:那些不可忽视的潜在问题
16 | 环境管理:一切皆代码是一种什么样的体验?
17 | 部署管理:低风险的部署发布策略
18 | 混沌工程:软件领域的反脆弱
19 | 正向度量:如何建立完整的DevOps度量体系?
20 | 持续改进:PDCA体系和持续改进的意义
平台工具篇 (4讲)
21 | 开源还是自研:企业DevOps平台建设的三个阶段
22 | 产品设计之道:DevOps产品设计的五个层次
23 | 持续交付平台:现代流水线必备的十大特征(上)
24 | 持续交付平台:现代流水线必备的十大特征(下)
特别放送 (4讲)
特别放送:成为DevOps工程师的必备技能(上)
特别放送:成为DevOps工程师的必备技能(下)
特别放送:学习DevOps不得不了解的经典资料
特别放送:Jenkins产品经理是如何设计产品的?
总结答疑 (1讲)
期中总结:3个典型问题答疑及如何高效学习
DevOps实战笔记
登录|注册

05 | 价值流分析:关于DevOps转型,我们应该从何处入手?

石雪峰 2019-10-22
你好,我是石雪峰。
关于“DevOps 如何落地”的问题,向来是关注度很高的,所以,从今天开始,我会用 16 讲的篇幅跟你聊聊这个话题的方方面面。作为“落地实践篇”的第 1 讲,我先跟你聊聊 DevOps 转型的那些事儿。
相信你一定听说过持续交付吧?现在,几乎每家实施 DevOps 的企业都宣称他们已经有了一套持续交付平台,或者是正在建设持续交付平台。但是,如果你认为只需要做好持续交付平台就够了,那就有点 OUT 了。因为现在国外很多搞持续交付产品的公司,都在一门心思地做另外一件事情,这就是 VSM 价值流交付平台。
比如,Jenkins 的主要维护者 CloudBees 公司最新推出的 DevOptics 产品,主打 VSM 功能,而经典的持续交付产品 GoCD 的 VSM 视图也一直为人所称道。那么,这个 VSM 究竟是个啥玩意儿呢?
要说清楚 VSM,首先就要说清楚什么是价值。简单来说,价值就是那些带给企业生存发展的核心资源,比如生产力、盈利能力、市场份额、用户满意度等。
VSM 是 Value Stream Mapping 的缩写,也就是我们常说的价值流图。它起源于传统制造业的精益思想,用于分析和管理一个产品交付给用户所经历的业务流、信息流,以及各个阶段的移交过程。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(18)

  • 桃子-夏勇杰
    需求提出时间的定义是什么?用户提出需求的时间,还是业务部门提出需求的时间,还是产品经理提交PRD的时间,还是提出就绪用户故事的时间?需求如何拆,规模多大?这些问题对前置时间的计算都有很大影响,想听一些这方面的实战经验。

    作者回复: 你好,你把下一讲的问题提前剧透了,以我们公司现有的实践来说,需求提出时间,具体指业务方提出需求的实践,以业务方在系统中录入原始需求为准。需求录入之后,会经过需求承接,产品设计,PRD评审,到准备就绪,这些就是需求管理层面的事情,再往后就进入了开发阶段。
    至于需求拆分的粒度,根据不同业务形态也不尽相同,我们现行的指导原则是,在一个迭代周期内可以上线交付,平均统计下来3-5天居多。另外,除了需求粒度之外,还有一个比较重要的指标,就是配置化需求比例,也就是不需要额外开发代码,仅需要调整配置就可以完成交付的功能。

    2019-10-22
    1
    3
  • manatee
    想请问老师,关于价值流中的三个指标,前置时间我理解就是从需求到上线的时间,这个还好统计,无非就是确定一个个阶段再分段统计时间,那增值时间和完成度又如何在系统上实现呢。我的意思是这两个指标如何具体的去度量。就拿增值时间来说,这个如何定义,有没有什么标准,又如何在系统上自动化的统计呢,感觉完全没有思路,请老师指点

    作者回复: 你好,其实我在文章中也有提到过,稍微展开一下。
    关于增值时间和不增值时间,可以划分为两个层面。首先是从全局的维度统计等待时间,如果你已经用了电子看板工具,那么一个任务从开始到结束的周期内,有多长时间处于等待状态,比如待开发,待测试,待发布,那这些都是典型的不增值时间。
    其次,从微观角度,深入到各个环节内容,比如开发环节,统计那些除了真正写代码之外的活动时长,比如构建打包,比如提测任务,比如没人评审的提交,比如审批活动,这些理论上都是不增值的时间,可以尽量优化掉。
    至于说开发本身的效率高低,这个不方便度量,但我相信,只要外部这些不增值的时间被优化掉,其实就能解决大头的问题。
    关于完成度和准确率,完成度最简单的就是统计迭代周期内的任务,有多少按时完成了,有多少延期了,比如按时提测率,虽然刚开始的时候对于任务的工作估计会有很大偏差,但随着团队磨合以及对于业务的理解,这个估计会被不断的矫正,更加贴近于真实情况。
    准确率方面,可以重点考察被下游打回的流程,比如研发提测后,测试发现自测不达标打回研发,可以统计提测打回率,再比如上线发布后,发现有问题出现回滚,那就是上线失败率,也可以进行统计。
    关键点是,指标贵精不贵多,预期一次性度量10个指标,不如把一个关注点的指标做透,直到改进流程影响行为。

    2019-10-24
    2
  • 阿硕
    石老师,您好,请问价值流图中的指标如何度量出来的呢?

    作者回复: 你好,价值流图反应的是团队客观的软件交付流程,度量价值流实际上就是度量软件交付过程。一般来说,都是以需求作为抓手,统计在各个交付阶段的时长,在针对这个阶段的流转时长度量可改进的方向。所以,关键是把需求纳入统一系统管理,需求状态切换尽量通过自动化手段完成,让需求管理系统和各个环节系统进行打通,那么从需求管理平台就能一目了然的看清楚团队现状。

    2019-10-23
    1
    2
  • johnny
    像我们这种没有devops体系的公司来说,可能关注更多的是如何落地。
    老师以后会多讲一些devops所涉及环节具体实践吗?
    比方说,devops会涉及到一个持续集成/持续交付的环节(会用到jenkins、容器等技术),怎么实现?
    我的意思是老师会不会以Adminset、jenkins或者其它运维平台或工具为主线,讲解devops落地过程的实践操作呢?

    作者回复: 你好,感谢你的留言,我在整理内容的时候,也在纠结工具本身的介绍要占据多大的篇幅,其实如果展开来说,每个工具都可以成为一个独立的专栏,所以权衡下来会采用实践为主,工具和案例为辅的方式,也就是先说明白为什么要做这个实践,实践的正确姿势是怎样的,再结合实践和工具列举一些小的案例帮助理解。至于工具本身,一方面网上有很多资料,另外一方面DevOps本身也不强依赖于某个具体的工具,所以我推荐还是以问题驱动学习的方式。你好,感谢你的留言,我在整理内容的时候,也在纠结工具本身的介绍要占据多大的篇幅,其实如果展开来说,每个工具都可以成为一个独立的专栏,所以权衡下来会采用实践为主,工具和案例为辅的方式,也就是先说明白为什么要做这个实践,实践的正确姿势是怎样的,再结合实践和工具列举一些小的案例帮助理解。至于工具本身,一方面网上有很多资料,另外一方面DevOps本身也不强依赖于某个具体的工具,所以我推荐还是以问题驱动学习的方式。
    顺便说下,你既然提到了Adminset,也给你一些小的福利,关于这个工具的问题,我会收集起来邀请作者来跟大家一起互动哈。

    2019-10-22
    2
  • 陈斯佳
    老师好,好奇的问一下,您所知道的这些企业中,哪个企业的DevOps做的最好?(有时候真想有机会去亲身体验一下什么是好的DevOps流程文化……)

    作者回复: 坦率的说,如果按照理想的DevOps的文化来衡量,这些业界大厂可能都不一定能够完全满足,反而我见过一些小而美的公司,的确是践行DevOps的文化,毕竟DevOps还是从国外流传进来的东西,有这浓浓的工程师文化在里面,而在我们这里,工程师的话语权大多数情况下也就那样了。

    2019-10-29
    1
  • 熊斌
    一边学习,一边思考我们公司现在的项目,如果用VSM的各项指标去衡量的话浪费极为严重。开展VSM活动对于我们而言,难点在于首先要让大家认同,不认同就意味着不会积极配合,也就没有办法通过会议或者走访的形式去挖掘最底层的问题。

    作者回复: 你说的很对,很多时候团队倾向于自我保护,所以刻意的会去隐藏一些真实的情况,这个时候就得让数据说话啦,当然不建议上来就用数据考核,这会导致走向另外一个极端哈。

    2019-10-28
    1
  • 工画师
    我是比较认同VSM中的价值流的。DevOps其实是与敏捷伴生的,但不是说没有使用敏捷的公司就无法开展DevOps,只不过落地实施会走样,当成效率工具罢了。个人认为要想发展DevOps甚至VSM,需要先搞清敏捷与价值流动,从文化和思维模式上进行转变,否则单说DevOps有些跟风了,无法发挥出内在的价值,也就不会有质的飞跃。

    作者回复: 上来就调整文化和思维模式很难,所以大多数企业选择了相对容易的道路,这也是为什么工具决定论实际上影响更大的原因,但就像你说的,如果选择了容易的道路,自然难有质的飞跃,不破不立,还是那句话,如果不改变现有流程的基础上实施DevOps,是很难达到目标的。

    2019-10-28
    2
    1
  • sugar
    目前问题还是比较多,看似上了很多平台、系统、工具提升效率,其实有时反而降低了效率,我觉得主要是文化及意识的问题,没有优先级,没个需求提出都说着急上,需要一个牵头人做整体的推动和沟通交流

    作者回复: 嗯嗯,缺少顶层设计和实施框架,的确容易野蛮生长,这也是现在很多公司部门都在搞DevOps的通病,开发和运维之家的壁垒还没解决,DevOps各家工具之间的壁垒先整出来了。

    2019-10-25
    1
  • delly
    以我所在的大型it服务公司的角度来看,我个人觉得价值流是挺难梳理的。因为照我的认知,基于itil的服务交付体系,大家的执行动力是以sla为驱动,工作模式基本都是等单子,看优先级,然后做单子。手里很多单的时候会按照优先级逐级去做,手里单子很少呢,有可能勤快点来个单子就做,也可能来了单子就等着,到快到deadline了才处理。每个人可能都处于在一个或多个时间区间内来回挪腾的状态,所以我的意思是这种情况下去弄清楚当前到底哪些是有效时间那些是无效时间是很困难的,都没个准,因为目前的工作模式本身就不是为了效率而服务的。而且就像文章提到的,即使使用了效率管理工具,都需要手动计时,太麻烦了根本就没有人愿意搞,数据也根本没有参考性。

    相对这个,可能文章里提到的每个部门只了解自己的内容这个问题还更好解决一些,重点是要有能力把大量的资深员工或领导聚在一起开会讨论。

    目前思路也比较混乱,但我觉得可能传统it服务公司想走上devops的道路,优化流程可能比工具重要很多……

    作者回复: 你好,感谢你的回复,我觉得说的特别好。
    没错,问题的关键就在于组织的运作不是面向效率建设的,换句话说只要符合现有的流程前提之下,效率的高低其实并没那么重要。但是另外一方面,我们又看到ITILv4的指导原则,也体现出一种DevOps的特征,比如关注价值,关注现状,自动化,流程与反馈等等,所以你说的这种现状不会长期存在,迟早也会进行调整。除非IT服务变成了铁饭碗,也没有行业竞争的压力,那么当竞争的重心从服务全面性,到服务质量,再到运作效率的转变时,消除浪费也就在所难免了。
    我还是始终强调一点,如果公司想在不改变流程的前提下推行DevOps,那么大概率是会失败的。所以思想和流程的共同转变,再辅以工具技术的支撑,才有可能改变现状。

    2019-10-22
    1
    1
  • Geek_52c2a9
    老师,您好,在哪里可以下载最新版的《研发运营一体化能力成熟度模型》?
    2019-11-09
    1
  • Jxin
    1.需求状态流转什么好软件或平台推荐?
    2.我们现在状态变更全部靠手动,结果就是不及时不准确。而且同时维护石墨需求文档,tapd需求状态,看板需求状态以及评审邮件,提测邮件,验收邮件。重复工作很多。

    作者回复: 你好,为什么不把提测流程和需求状态流转关联起来呢,我理解TAPD一定是有需求状态流转的API的,如果没有的话,我去替你“鄙视”他们。其实说白了就是把原本手动流转的动作给自动化了,所以流转的前提和触发条件并没有什么区别哈。

    2019-11-08
  • 雷霹雳的爸爸
    我看老师文章里有用到质量门禁这个词,很形象传神,但感觉其实也是一个内涵外延都很丰富的概念,有没有什么出处来源参考之类的?还是老师自己的发明?

    作者回复: 你好,这个并非我发明的哈,甚至这个概念都不是软件行业发明的,质量门禁是内建质量的一种实践,内建质量来源于管理学大师戴明的质量14条,也是很多精益理论的核心思想,在SonarQube中就存在质量门禁的功能,也就是将规则内建在平台中,并自动检查校验给出反馈哈

    2019-11-08
  • Ios王子
    价值流图那三个因素有联系吗?是通过公式计算出来的吗?

    作者回复: 你好,价值流图的三个因素是比较典型的三个核心指标,用于体现价值流动的客观情况的,计算方法在文稿中也有提到,前置时间和等待时间可以通过需求管理平台来计算,而完成度和准确率可以根据实际情况,度量下游打回的情况,比如缺陷数量,提测不达标数量,需求打回的数量等等。

    2019-11-02
  • iiiqueena
    梳理价值流最大的障碍可能是大部分团队以及团队成员都关注于当前自己做的事情,对于与其他团队有交互的地方通常是不太关注的,对于这种边界模糊的地方,常见的现象就是“甩锅”。
    所以老师你提到的六个关键问题中,自身的职责和上下游是谁尤为关键,如果大家对这两个问题的认知是一样的,可能就能减少"甩锅“造成的等待。
    这些内容可能是流程改进可以确认的,而平台工具是实现流程的载体,同时工具也能有效记录时长,一举两得。打通了之后,再回过头审视团队/队员的能力,做到有效/针对性地提升,从而形成持续改进。
    听起来都挺不错的,只是实施起来就没那么简单了。因为大多数人还是会像一开始讲的那种只看树木,所以一个好的引导和文化非常重要呢。

    作者回复: 我觉得咱们平台用户的留言都非常高质量,有见地,赞一个。甩锅这事吧,说到底还是职责不清,要么就是你并没有做到无懈可击,比如一个线上版本问题,开发说代码没变,然后甩锅运维,运维自身有嘴说不清,原因还是自己有值得提升的点,所以反过来看这个问题,其实是一个挺好的反馈和改进的契机。回到工具,的确通过工具平台联通不同角色,相当于多了一个裁判,或者是多了一个新的背锅团队,所以做得好坏,就看平台上的业务路径,当然核心咱们还是希望自动化能替代一部分人工的事情,这样多出来的精力就可以解决开始提到的甩锅问题了。

    2019-10-28
  • leslie
    VSM中“价值”:应当是最难的,现在的公司现有系统经常就在这个模块里的“识别问题”和“促进沟通”以及“价值展现”中一堆的问题;故而做了一系列关于现状的沟通,然后明白自己要想实现一些的梦想应当去哪里😀

    作者回复: 期待你的梦想成真😄

    2019-10-22
  • 牧野静风
    看老师的专栏,对于企业技术管理,转型很有参考意义,除了软件交付上的流程更加通畅,高效,人员的水平提高也很有帮助,不仅仅在技术方面,很多软实力也是需要的。

    作者回复: 你好,我今天跟团队还在学习谷歌的代码评审文档,不知道你看了没?其中感受特别深的一点就是国外这些所谓的优秀公司,在总结规范和实践的时候,对人的关注非常高。比如举个例子,在谷歌的代码评审实践中,特别提到了要如何给出评审建议,怎么样的话术比较容易让人接受,如果两方争执不下,要怎么处理的好,甚至要关注评审双方的情绪,等等。
    但是我们在做类似的事情的时候,很多时候都是指标先行,通过定义指标,来考核团队的落实情况,至于指标是否合理,人员的情绪是否有照顾到,说实话,并不太关心。这也是值得反思的一点吧。

    2019-10-22
  • 蜗牛
    可能对于较大的,已有交付流程较为规整的企业来讲,价值流的整理会相对简单些……但是对于某些初创企业来说,本身的交付流程就相对混乱,这个时候就需要梳理人本身有一个已有的价值流模型来做作为参考,结合公司的流程现状来梳理,规划调整。不知道我的理解石老师会怎么看? 对于初创企业的价值流整理有什么好的建议?

    作者回复: 你好,我非常认同你的观点,价值流梳理听起来很炫,但归根结底梳理的还是软件交付流程,这个流程并不是说梳理价值流才出现的,而是只要公司在开发交付软件,这个流程就一直存在,只不过没有人全局的来看,或者把他提到一个比较高的维度而已。
    对于初创企业来说,压力大,人手紧张,再加上业务范围不确定,本身就是需要灵活变化的能力,这样看来,容错率更低的初创公司,对于DevOps的协作,自动化,全局优化更为适用。
    作为价值流梳理的副产品,公司内部的持续交付流水线就是很多初创公司都在加强建设的方向,无论是基于云服务商提供的平台,还是内部自己搭建的平台,把这个事情说清楚了,价值流也就出来啦。

    2019-10-22
    1
  • Robert小七
    目前金融行业中大部分的研发人员来自isv,而企业自有人员的研发能力不足,可能对价值交付流程不熟,对于不同的项目可能来自不同的isv,价值交付流程图也有很大区别,那么老师是如何对这类企业进行走访调查的?

    作者回复: 你好,根据我这一两年的经历,我可以很确定的说,金融企业对于软件的自我意识和把控诉求与日俱增,一方面自身软件交付团队和平台的建立有目共睹,另外一方面对于外包的质量,流程,交付节奏,甚至DevOps能力都再越来越严。
    所以,即便每个项目合作方都不相同,软件开发流程也不相同,但是殊途同归,毕竟你总要有一种有效的衡量手段。而价值流中的几个核心指标,对于这一点来说很是很有帮助的。

    2019-10-22
收起评论
18
返回
顶部