DevOps组织如何利用度量金字塔驱动DevOps转型

陈小宝

+ z% [. G; U1 Q4 P1 Y" @& P  G$ O+ I
! u( e3 E1 }1 ]8 x  W

度量金字塔

Gene Kim、Jez Humble、Patrick Debois与John Willis在《The DevOps Handbook》一书中提出了“三步法（Three Ways）”，系统性地阐述了DevOps的支撑性原则。其中，第二步反馈（Feedback）指出要建立从右到左且贯穿整个价值流的快速、频繁、高质量的反馈信息流，使能我们创造更安全的工作系统。反馈成为敏捷与DevOps倡导的持续改进（Continuous Improvement）的重要机制。

度量作为反馈的首要来源，DevOps组织与团队应收集并分析度量用于理解成功、失败与机会，来持续改进，实现软件交付的商业目标。
, ?: @# J5 k; }

谈到度量，DevOps组织与团队首先面临的问题是如何正确地看待度量。最为重要的是，应将度量视为改进机会的风向标，而不是简单粗暴地作为惩罚式生产力度量。同时，在持续改进时，不是让团队尽量符合行业水准，而是与过去的基线进行对比。为了更恰当地利用度量，要运用审辩式思维（Critical thinking）分析相关数据，识别噪声、错误假设等。DevOps组织与团队可以将度量视为：

2 Y, }- K. k+ Q! f

9 ?. V' K0 V% ~* K2 q# C

• 进度指示器：尽量向不同干系人透明地提供最有价值的信息，例如趋势、上下文信息等；
• 未来预测器：通过建立预测模型帮助进行预测，但需要注意的是“水晶球”也会快速变模糊；
• 方案决策依据：为团队发现问题的根因并确定解决方案提供实验数据。
  
  8 f+ |7 N% n  J% m1 n

, O/ i) z* S" ], J

金字塔是世界七大奇迹之一，最早的埃及金字塔始建于近5000年前。现在人们目睹金字塔真容，得益于金字塔稳固的建筑结构。对于度量，DevOps组织可以建立与金字塔类似的结构，可以称之为DevOps度量金字塔。不得不提的是，在DevOps的测试领域中，人们也提出了测试金字塔。DevOps度量金字塔与测试金字塔类似，如下图所示：

  k* t3 Q1 Y: c$ R. o" N. Y

' O. E! B3 `+ g$ t

DevOps度量金字塔

) E+ @! W, T  u5 H
6 K4 I9 z2 w0 b' S9 Y- I7 h

DevOps度量金字塔主要关注5个领域，从下到上依次为：

  l7 _# x, s; }- {3 T5 I/ j

• 运维效率：本领域主要关注运维管理能力与效率，例如变更或发布成本、人均管理主机数量等等；
• 产品交付质量与速度：本领域主要关注客户可交付产品的质量与速度，例如价值平均交付时间、平均恢复时间、Cycle time等；
• 组织效能：本领域关注行为变化、变更响应力、员工技能成长等，例如员工留存比率、协作程度等；
• 客户价值：本领域主要关注客户价值相关的度量，例如客户满意度、客户成功、Lead time等；
• 商业绩效：本领域主要关注DevOps变革效果，例如TTM（Time To Market）等。
  
    e9 l/ y+ R1 U

对于DevOps度量金字塔的5个领域中的某个度量指标而言，DevOps组织或团队需要体系化地进行描述，建议至少包含以下内容：指标目的、统计对象、统计维度、统计公式、统计频度、数据来源、保留周期、重要等级等。

- E# m) H' l! \! U! X7 [

那么度量指标从哪儿来呢？DevOps组织或者团队可以从以下方面进行分析并收集：

• 商业价值
• 文化
• 流程
• 平台
• 人员
• 架构设计
• 开发与测试等
  
  

“度量”中的风险

  N9 w* e# A. Z

度量对于DevOps的重要性，无论如何强调都不为过，然而DevOps组织或团队常常会遇到以下风险或者陷阱：

• 忘记“持续改进”的初心，将度量作为惩罚性手段；
• 未准确地定义度量；
• 以游戏、规避、或者利己的心态对待度量；
• 不能恰当地分析度量；
• 不能周期性地重建基准
  
  * s( D' ^6 N+ u* ?5 W  f

: r' B' m3 [8 {

If you cannot measure it, you cannot improve it。DevOps组织或团队应本着“持续改进”的宗旨，可以参考DevOps度量金字塔，持续地构建合适的度量体系，促进DevOps能力提升。（华为云DevCloud）
4 P# w  ^  J$ f1 K2 R# n0 q