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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 230|回复: 0

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

[复制链接]
发表于 2022-5-26 12:57:36 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2022-5-26 12:59 编辑
# c6 f4 S1 a$ T% U  ]$ k& F" j& s3 D3 S* M  }8 t) }) b  v( z
如果不能度量,你将无法改进。
——彼得.德鲁克
上述彼得.德鲁克大师的名言,让我们在直觉上产生共鸣,同时也展示了度量在各个领域的重要性。如果没有数据去定量分析我们当前在哪里、目标在哪里,那么我们将如何知道目前是否在向着正确的目标前进?下面这篇博文讲述了在持续交付过程中度量的重要性。
一、度量在持续交付过程中是如何起作用的?

# j' ?9 P- N7 D' `& x6 S+ W
是什么让你觉得已经达到了一个良好的持续交付状态?为了找到这个问题的答案,GoCD团队采访了很多专家、程序员、运维人员,以及在DevOps链条各节点上的小伙伴。同时他们也采访了业务干系人,因为成功的持续交付能够让技术更好地服务于业务、推进业务收益,进而可以让实现持续集成的潜在工作也被认可有其价值。

& x. Z9 o* J( J1 U
通过综合分析总结,我们识别了4个有价值的度量指标:
  • 可发布的软件包数量
  • 周期时间
  • 故障平均间隔时间
  • 故障平均恢复时间
    " T8 p. q) t6 v, L5 |/ p0 \1 e
      b# f% d9 H' i5 B
二、你有多少可发布的软件包?

2 _9 u. N8 S6 n% r8 R
为了实现成功的持续交付,你需要持续提交代码,特别是持续提交代码到主干分支(master)。如果总是向个人分支提交代码,那么这样的提交将不会对即将发布生产的代码带来任何价值。
8 \) u6 O% y4 r3 k0 Y  ~( ]
保持较高的可发布包的交付频率,同时依赖于团队已对软件包完成了可信赖的测试。一个我们常见的反面模式就是持续数小时、甚至一整天的测试验证活动。在很多场景下,这些测试是不可信赖,也就意味着当测试结束的时候,你未必比测试初期对交付质量更有信心。这让事情变得成本很高,因为它使每个人对发布都极其小心谨慎。部署软件看上去就像是俄罗斯轮盘赌游戏一样。

7 H  V( h( E9 j( ^
这个指标也强调产品团队和研发工程团队协作的重要性。跨职能团队必须能够建立一个路线图,使得用户故事能以足够小的粒度去拆分,使得团队可以细粒度的发布故事,真正给用户交付价值。如果产品团队并不配合这种协作模式,那么研发团队则只能一次性开发交付较大规模的功能,也许直到游戏的最后一分钟,大家才知道这个大功能并没有带来任何价值。
4 ?& Y) s( D7 C9 R  P; E
作为严谨的路线图规划的一个补充,研发团队应该利用一些新的技术,如feature toggles(特性切换),通过feature toggles配置实现功能的打开或者关闭(控制展示与否),从而实现把Feature发布到生产环境,同时保持客户的无感知状态(如蓝绿发布等场景)。

+ i0 H" ^8 z' T) J9 u* B
三、你的周期时间是多少?
我们从开发人员口中最常听到的痛点是周期太长,这个周期从提交代码开始,经过测试、验证到部署,对开发人员来讲这是一个漫长而焦躁的过程。因为在代码提交等待反馈的过程中,他们经常要被迫中断性的切换工作思路,也是一种时间的浪费。XKCD的关于击剑等待代码编译的漫画,就轻松而又非常真实的反映了这个过程。

5 ^" p; o5 M- ~3 o$ r' }( U
粘贴上传202205261257185098..png
7 b" y7 g4 q( h$ S" j9 @$ [
这段停滞时间不但不能让你加速交付价值给客户,还会造成工作焦点发散。提高团队的周期依赖于高效的测试和快速的反馈闭环。
" E' D+ w, o, w& p9 k
下面有一些实践可以帮助你缩短周期:
  • 尽早执行UT,让UT早于Pipeline和复杂的、需要长时间执行的自动测试,这将会让你提前获得一些基本反馈,节约时间。
  • 让依赖在Pineline stage间传递可以避免不必要的重复构建,这会比较有帮助。
  • 让构建尽可能的并行执行,这也会节约不少时间。
  • 最后,确保你拿到了正确的构建资源,这样不管你需要跑什么构建,都会有充足的Agent去跑各类任务。
      c: |  U3 G2 ?# O! G3 W

    : K9 {7 t3 a8 U
1 O5 X0 G' B8 s0 R4 l4 y
四、你的故障平均间隔时间和平均恢复时间是多少?
, x2 w2 \. \6 L3 b; U" _
故障平均间隔时间和恢复时间往往是相关联的,因为二者间的平衡非常重要。故障平均间隔时间让团队总是尽可能的确保版本的稳定,尽力避免失败。但是,仅仅关注平均失败间隔时间、减少失败,会导致团队过度谨慎,不愿发布新版本。而软件研发的核心是不断提供新价值给用户,满足用户需求。因此,平均故障恢复时间将会是一个关键制衡点,该指标展示团队纠正错误的能力。

. K. {# }  p8 A3 n5 N# e3 `- w3 f
达到理想的平均故障间隔时间,依赖于更早的反馈闭环,以及在测试环境中的缜密验证。这类验证应该在数据和环境与生产完全一样的测试环境中执行。强大的本地构建能力也是必须的,因为失败是在所难免的,因此尽可能缩短故障恢复时间就变得尤为重要。当遇到一个Pipeline失败或者发布失败,你需要多久可以回滚到一个稳定的版本上?对生产环境的持续稳定监控是一项基本能力。团队应该从监控和报警中获知故障发生,而不应该在客户投诉抱怨时才获知故障。

& z5 Z" r! i. o- K' e5 H
故障恢复演练,如回滚,可以缩短平均恢复时间。建立一套自动回滚机制,可以让团队节约出时间去深入分析问题根因。快速分析定位问题依赖于信息化的日志系统,通过获取有价值的日志信息,开发人员可以准确定位一个发生在凌晨2点的故障。

( Y5 n, M$ |5 v) b! ]1 ]: P
五、总结

& \9 V  t5 x( R- G  L
回到彼得.德鲁克大师的名言,为了改进某些事务,我们首先需要找方法去度量它,让它可视化。这也就是为什么要建立数据仪表盘、让度量可视化的价值,这可以让团队更有责任和关联意识。另一方面,我也不想说度量是万金油。一定存着一些无意义的度量和虚荣的指标。最终,你希望的是激励员工去关注棘手问题,通过解决这些问题,让员工给团队和组织创造价值。(转自Alison Polton-Simon)
- z& k# v3 R  t& h1 N# H
: N6 d9 m. a8 s0 @. T2 h

* b; p% f, D0 V3 T# A




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

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名

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

GMT+8, 2022-9-26 20:21 , Processed in 0.098203 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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