请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 471|回复: 0

持续交付的4个重要度量指标

[复制链接]
发表于 2022-5-26 12:57:36 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2022-5-26 12:59 编辑 , o* Q# A  V8 i# Z+ c# B3 D& P7 @
6 a- t8 W1 Y, H9 S4 f8 j4 X
如果不能度量,你将无法改进。
——彼得.德鲁克
上述彼得.德鲁克大师的名言,让我们在直觉上产生共鸣,同时也展示了度量在各个领域的重要性。如果没有数据去定量分析我们当前在哪里、目标在哪里,那么我们将如何知道目前是否在向着正确的目标前进?下面这篇博文讲述了在持续交付过程中度量的重要性。
一、度量在持续交付过程中是如何起作用的?
$ g; f: w/ B* f
是什么让你觉得已经达到了一个良好的持续交付状态?为了找到这个问题的答案,GoCD团队采访了很多专家、程序员、运维人员,以及在DevOps链条各节点上的小伙伴。同时他们也采访了业务干系人,因为成功的持续交付能够让技术更好地服务于业务、推进业务收益,进而可以让实现持续集成的潜在工作也被认可有其价值。

- q: @% q0 P9 Y  A
通过综合分析总结,我们识别了4个有价值的度量指标:
  • 可发布的软件包数量
  • 周期时间
  • 故障平均间隔时间
  • 故障平均恢复时间1 |1 P& d3 b, }

    ( q2 V& v, g; {3 t
二、你有多少可发布的软件包?
9 p' r( K# V5 ~6 ^! z% }
为了实现成功的持续交付,你需要持续提交代码,特别是持续提交代码到主干分支(master)。如果总是向个人分支提交代码,那么这样的提交将不会对即将发布生产的代码带来任何价值。
* d; G% I& y8 L0 T5 c
保持较高的可发布包的交付频率,同时依赖于团队已对软件包完成了可信赖的测试。一个我们常见的反面模式就是持续数小时、甚至一整天的测试验证活动。在很多场景下,这些测试是不可信赖,也就意味着当测试结束的时候,你未必比测试初期对交付质量更有信心。这让事情变得成本很高,因为它使每个人对发布都极其小心谨慎。部署软件看上去就像是俄罗斯轮盘赌游戏一样。
; ]" J% V; P+ E2 M$ \! h7 y* o
这个指标也强调产品团队和研发工程团队协作的重要性。跨职能团队必须能够建立一个路线图,使得用户故事能以足够小的粒度去拆分,使得团队可以细粒度的发布故事,真正给用户交付价值。如果产品团队并不配合这种协作模式,那么研发团队则只能一次性开发交付较大规模的功能,也许直到游戏的最后一分钟,大家才知道这个大功能并没有带来任何价值。

" i1 B- M+ I; u) ^
作为严谨的路线图规划的一个补充,研发团队应该利用一些新的技术,如feature toggles(特性切换),通过feature toggles配置实现功能的打开或者关闭(控制展示与否),从而实现把Feature发布到生产环境,同时保持客户的无感知状态(如蓝绿发布等场景)。
$ a" U: S; F+ W) H
三、你的周期时间是多少?
我们从开发人员口中最常听到的痛点是周期太长,这个周期从提交代码开始,经过测试、验证到部署,对开发人员来讲这是一个漫长而焦躁的过程。因为在代码提交等待反馈的过程中,他们经常要被迫中断性的切换工作思路,也是一种时间的浪费。XKCD的关于击剑等待代码编译的漫画,就轻松而又非常真实的反映了这个过程。

  j7 r3 j( D& `
粘贴上传202205261257185098..png
$ U( v" M! o4 H- ]
这段停滞时间不但不能让你加速交付价值给客户,还会造成工作焦点发散。提高团队的周期依赖于高效的测试和快速的反馈闭环。
) ]0 I" u* E5 g( u7 i; G0 M% ]6 H* s
下面有一些实践可以帮助你缩短周期:
  • 尽早执行UT,让UT早于Pipeline和复杂的、需要长时间执行的自动测试,这将会让你提前获得一些基本反馈,节约时间。
  • 让依赖在Pineline stage间传递可以避免不必要的重复构建,这会比较有帮助。
  • 让构建尽可能的并行执行,这也会节约不少时间。
  • 最后,确保你拿到了正确的构建资源,这样不管你需要跑什么构建,都会有充足的Agent去跑各类任务。9 Q# m4 l* ]/ h) i9 {
    7 o" f. S2 P0 l: R9 j4 Z) H

, e- w6 d; H/ o& S) }# h
四、你的故障平均间隔时间和平均恢复时间是多少?
5 |/ |$ l$ d. h, D7 R4 X% m
故障平均间隔时间和恢复时间往往是相关联的,因为二者间的平衡非常重要。故障平均间隔时间让团队总是尽可能的确保版本的稳定,尽力避免失败。但是,仅仅关注平均失败间隔时间、减少失败,会导致团队过度谨慎,不愿发布新版本。而软件研发的核心是不断提供新价值给用户,满足用户需求。因此,平均故障恢复时间将会是一个关键制衡点,该指标展示团队纠正错误的能力。
5 K/ `* p3 R) g9 H2 y" ]
达到理想的平均故障间隔时间,依赖于更早的反馈闭环,以及在测试环境中的缜密验证。这类验证应该在数据和环境与生产完全一样的测试环境中执行。强大的本地构建能力也是必须的,因为失败是在所难免的,因此尽可能缩短故障恢复时间就变得尤为重要。当遇到一个Pipeline失败或者发布失败,你需要多久可以回滚到一个稳定的版本上?对生产环境的持续稳定监控是一项基本能力。团队应该从监控和报警中获知故障发生,而不应该在客户投诉抱怨时才获知故障。
# q: ^& N! X; n# y" h2 z5 r1 c
故障恢复演练,如回滚,可以缩短平均恢复时间。建立一套自动回滚机制,可以让团队节约出时间去深入分析问题根因。快速分析定位问题依赖于信息化的日志系统,通过获取有价值的日志信息,开发人员可以准确定位一个发生在凌晨2点的故障。
- a/ R  }) Z8 H7 y+ x
五、总结
/ \7 t* k3 s, a; y/ D9 C+ Z, S
回到彼得.德鲁克大师的名言,为了改进某些事务,我们首先需要找方法去度量它,让它可视化。这也就是为什么要建立数据仪表盘、让度量可视化的价值,这可以让团队更有责任和关联意识。另一方面,我也不想说度量是万金油。一定存着一些无意义的度量和虚荣的指标。最终,你希望的是激励员工去关注棘手问题,通过解决这些问题,让员工给团队和组织创造价值。(转自Alison Polton-Simon)

2 @1 M  ~) f, R3 F  i  ~: g4 f  |
$ T! a9 F- A- V4 T




上一篇:DevSecOps在大型银行的敏捷实践
下一篇:DevOps度量与改进
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
ITIL(R) is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. The Swirl logo is a trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

QQ|ITIL ( 粤ICP备11099876号 )|appname

GMT+8, 2023-1-28 01:29 , Processed in 0.099734 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表