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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 77|回复: 0

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

[复制链接]
发表于 2022-5-26 12:57:36 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2022-5-26 12:59 编辑
" U4 f1 Q' c& m
/ X8 m; S6 j# D' {/ `# u
如果不能度量,你将无法改进。
——彼得.德鲁克
上述彼得.德鲁克大师的名言,让我们在直觉上产生共鸣,同时也展示了度量在各个领域的重要性。如果没有数据去定量分析我们当前在哪里、目标在哪里,那么我们将如何知道目前是否在向着正确的目标前进?下面这篇博文讲述了在持续交付过程中度量的重要性。
一、度量在持续交付过程中是如何起作用的?

4 i/ m1 X. N2 e6 p
是什么让你觉得已经达到了一个良好的持续交付状态?为了找到这个问题的答案,GoCD团队采访了很多专家、程序员、运维人员,以及在ITILxf.com" target="_blank" class="relatedlink">DevOps链条各节点上的小伙伴。同时他们也采访了业务干系人,因为成功的持续交付能够让技术更好地服务于业务、推进业务收益,进而可以让实现持续集成的潜在工作也被认可有其价值。

9 E8 v% |; w) R% g/ o
通过综合分析总结,我们识别了4个有价值的度量指标:
  • 可发布的软件包数量
  • 周期时间
  • 故障平均间隔时间
  • 故障平均恢复时间( e: d6 S/ B3 Q7 D& j
    / s7 ^2 K) R, X1 ?7 s' G  N9 N
二、你有多少可发布的软件包?

# X/ m' `% i" g
为了实现成功的持续交付,你需要持续提交代码,特别是持续提交代码到主干分支(master)。如果总是向个人分支提交代码,那么这样的提交将不会对即将发布生产的代码带来任何价值。

$ K: S9 X1 j2 b* F
保持较高的可发布包的交付频率,同时依赖于团队已对软件包完成了可信赖的测试。一个我们常见的反面模式就是持续数小时、甚至一整天的测试验证活动。在很多场景下,这些测试是不可信赖,也就意味着当测试结束的时候,你未必比测试初期对交付质量更有信心。这让事情变得成本很高,因为它使每个人对发布都极其小心谨慎。部署软件看上去就像是俄罗斯轮盘赌游戏一样。

  S% t8 P! q( A+ C
这个指标也强调产品团队和研发工程团队协作的重要性。跨职能团队必须能够建立一个路线图,使得用户故事能以足够小的粒度去拆分,使得团队可以细粒度的发布故事,真正给用户交付价值。如果产品团队并不配合这种协作模式,那么研发团队则只能一次性开发交付较大规模的功能,也许直到游戏的最后一分钟,大家才知道这个大功能并没有带来任何价值。

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

" N  S( d- f; l( P& N
粘贴上传202205261257185098..png

/ w  x% _0 V8 t! ~2 {/ L% m, k, s
这段停滞时间不但不能让你加速交付价值给客户,还会造成工作焦点发散。提高团队的周期依赖于高效的测试和快速的反馈闭环。

! a/ J# k, ]9 G- ^; K- r0 I' c
下面有一些实践可以帮助你缩短周期:
  • 尽早执行UT,让UT早于Pipeline和复杂的、需要长时间执行的自动测试,这将会让你提前获得一些基本反馈,节约时间。
  • 让依赖在Pineline stage间传递可以避免不必要的重复构建,这会比较有帮助。
  • 让构建尽可能的并行执行,这也会节约不少时间。
  • 最后,确保你拿到了正确的构建资源,这样不管你需要跑什么构建,都会有充足的Agent去跑各类任务。
    * b0 U1 Q; N4 U& l
    : _4 \/ Z) i- U( _  V

$ ~+ J/ v) g# Z. v) b7 Q
四、你的故障平均间隔时间和平均恢复时间是多少?
: t9 Z& @- s. ?* o! V
故障平均间隔时间和恢复时间往往是相关联的,因为二者间的平衡非常重要。故障平均间隔时间让团队总是尽可能的确保版本的稳定,尽力避免失败。但是,仅仅关注平均失败间隔时间、减少失败,会导致团队过度谨慎,不愿发布新版本。而软件研发的核心是不断提供新价值给用户,满足用户需求。因此,平均故障恢复时间将会是一个关键制衡点,该指标展示团队纠正错误的能力。

+ O  l: B( c& L; m* t* q5 C* {8 r
达到理想的平均故障间隔时间,依赖于更早的反馈闭环,以及在测试环境中的缜密验证。这类验证应该在数据和环境与生产完全一样的测试环境中执行。强大的本地构建能力也是必须的,因为失败是在所难免的,因此尽可能缩短故障恢复时间就变得尤为重要。当遇到一个Pipeline失败或者发布失败,你需要多久可以回滚到一个稳定的版本上?对生产环境的持续稳定监控是一项基本能力。团队应该从监控和报警中获知故障发生,而不应该在客户投诉抱怨时才获知故障。
# ~- S( \( J3 B5 V" E+ |. y
故障恢复演练,如回滚,可以缩短平均恢复时间。建立一套自动回滚机制,可以让团队节约出时间去深入分析问题根因。快速分析定位问题依赖于信息化的日志系统,通过获取有价值的日志信息,开发人员可以准确定位一个发生在凌晨2点的故障。
1 z5 I1 ~; e0 Y+ K/ \$ S/ i. }
五、总结

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

2 H) u* `+ I* l! a, d& R8 R7 o" _+ o& p$ j$ Y6 |' _% f

+ |0 Q( g5 \5 Y- p: ^




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

本版积分规则

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

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-6-28 10:48 , Processed in 0.115933 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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