DevOps 实战笔记
石雪峰
京东商城工程效率专家
36602 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 41 讲
DevOps 实战笔记
15
15
1.0x
00:00/00:00
登录|注册

19 | 正向度量:如何建立完整的DevOps度量体系?

你好,我是石雪峰。到今天为止,我用 14 讲的篇幅给你通盘梳理了 DevOps 的工程实践,基本涵盖了工程实践的方方面面。但是,就像那句经典的“不仅要低头看路,还要抬头看天”说的一样,我们花了这么大的力气投入工程实践的建设,结果是不是符合我们的预期呢?
所以,在工程实践的最后两讲,我想跟你聊聊度量和持续改进的话题,今天先来看看 DevOps 的度量体系。
我相信,对于每个公司来说,度量都是必不可少的实践,也是管理层最重视的实践。在实施度量的时候,很多人都把管理学大师爱德华·戴明博士的“If you can’t measure it, you can’t manage it”奉为实践圭臬。
但是,回过头来想想,有多少度量指标是为了度量而度量的?花了好大力气度量出来的数据会有人看吗?度量想要解决的,到底是什么问题呢?
所以,度量不是目的,而是手段,也就是说度量的目标是“做正确的事”,而度量的手段是“正确地做事”
那么,什么才是度量领域正确的事情呢?如果想要弄清楚 DevOps 中的度量长什么样子,关键就是要回到 DevOps 对于软件交付的核心诉求上。
简而言之,对于 IT 交付来说,DevOps 希望做到的就是持续、快速和高质量的价值交付。价值可以是一个功能特性,可以是用户体验的提升,也可以是修复阻塞用户的缺陷。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《DevOps 实战笔记》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(9)

  • 最新
  • 精选
  • leslie
    正向管理:觉得老师今天的课程就是在讲项目管理。<落地实践篇>开始就明显的感觉到了,故而在老师开始的其实就去补充了其相关的课程强化自身。 老师的今天的课程中这块其实完全体现了DevOps其实就是一个项目一个产品:想有效发挥DevOps就必须让其贯穿整个过程,早期的进销存去替换全手工记账同样如此。做好一个DevOps可以大幅提升软件内部的效率,就像上次DevOps大会时网易的于旭东曾经做的分享更让我感受到这点。 软件是一把双刃剑,诸多的关键环节同样如此:用好了大幅提升效率,过于刻板的为了规范而规范,可能受伤害的不只是软件本身,而是整个企业。谢谢老师今天的分享,期待后续的课程。

    作者回复: 每次看到你的留言都让我感慨颇深,可能是在大公司时间长了,有太多这种一言难尽的故事,比如集成代码需要VP审批这个事情,就已经不知道掰扯过多少次了,试问哪个VP能够知道代码改了什么呢,所以我始终认为,效率提升就是要打破现有流程,如果不改变流程想实现效率提升,能做的也只有表面一层了吧。

    6
  • manatee
    老师您好,在统计指标的时候我们一般会以人的纬度或者以部门的纬度来进行统计,比如会统计一个部门的前置时间,一个小组的前置时间,一个人的前置时间。那我们在做系统设计时这些数据是如何与组织架构关联呢,特别是这个人在组织机构中产生了变化又如何保证数据的准确呢?

    作者回复: 你好,虽然已经线下回复过了,为了其他同学参考,我再汇总下要点。第一、不是每个指标都能对应到人的,也没有这个必要,比如个人前置时间,我觉得意义不大,现在企业做度量体系普遍还没有细化到度量个人效率的程度。第二、指标需要分类分级,区分不同的维度,满足不同受众的视角,比如领导者视图,里面肯定只有最大的指标结果,然后可以拆分为部门级的数据,指标是层层拆解的,底层数据可以支撑上层结果,这个指标的层次关联很重要。第三、抓住核心坐标,比如需求就是其中之一,度量需求的时候可以站在需求提出方和需求受理方两个角度来度量,至于具体研发是否调整部门,其实并不重要哈。其实,没有度量个人指标,主要是不希望指标跟个人绩效挂钩,影响个人的行为,这一点也是设计度量的初衷哈。

    2
    5
  • 陈斯佳
    关于数据的准确性这段时间很有感触。公司今年新上了一个缺陷管理系统,用来替换原先的老系统。新系统功能和使用习惯和老系统差异很大,大家都很不习惯,经常出现代码已经部署到生产环境了,但是对应的ticket还是显示正在开发的状态。我的应对方式是,一看到错误就追踪落实到个人,确保他意识到问题出在哪里,我们制定的新规则是什么,还有也要解释为什么我们制定这样的规则(我觉得规则的制定还是要以效率为准,没缘由的规则自己都说服不了自己,更不要想着让别人遵守)。然后总结一些常见的问题,以checklist的形式附加给所有程序员,作为提醒。感觉现在的自己就像个老母亲,一遍又一遍教导纠错,心累…

    作者回复: 如果流程依赖于人的自觉性来保障,那么这个流程本身可能就有问题哦,流程和规范都有一定的强制性,最好的方式还是在某些节点进行卡点,比如状态不对不允许发布,提测等等,通过这些卡点来培养人的意识,再辅助以自动化的方式来简化流程执行的成本才是正道吧。

    1
  • 霍格沃兹小学徒
    老师您好,当前业界有比较流行好用的度量平台的开源工具或者开源框架吗?

    作者回复: 你好,坦率的说:没有,不过业界有一些开源方案,你可以拿来参考,但我确实没见过有公司直接使用的,比如Hygieia, MirrorGate等,像商业工具那就相当的贵啦,比如tableau,土豪公司可以考虑哈,还集成了AI的能力。

    1
  • 小谢同学
    请问老师“交付吞吐量”是否可以辅助团队敏捷开发时设置每个冲刺的任务点数?避免出现工作量闲置或者产生过多挤压?

    作者回复: 你好,你说的特别正确!可以参见精益看板的章节,对于WIP的合理值就可以使用吞吐量作为参考的主要依据哈。

    1
  • 工画师
    感谢老师的分享,对于我们正在建设DevOps度量指标阶段受益匪浅,还是应该回归本质,宜少不宜多,宜精不宜烂,达成共识,构建多维度视角的可视化,才能使度量变得真正有效。

    作者回复: 恩恩,道理很简单,还需要不断实践呀,有问题欢迎继续留言,我们一起探讨,谢谢!

    1
  • 倪倪
    有的需求很大,有的需求很小,那开发前置时间是否就没有意义了

    作者回复: 没错,你发现了一个关键的问题,就是需求的颗粒度,如果颗粒度不平均,那么统计数据就没啥意义。所以在我们的实际经验中,会将需求颗粒度(开发交付时长)作为交付周期的重要参考依据,甚至对于需求颗粒度,配置化需求比例都会有明确的KPI要求。

  • 张瑞霞
    这些指标需要区分阶段嘛? 如开发阶段是在开发环境,测试阶段是在测试环境

    作者回复: 这个好像没有必要哈,测试环境是要度量什么呢?

    2
  • Pyel
    “度量不是目的,而是手段,也就是说度量的目标是“做正确的事”,而度量的手段是“正确地做事”。”
收起评论
显示
设置
留言
9
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部