DEC培训Day-3 度量和改进

度量（石雪峰）

度量体系

• 度量目标和原则
• 度量指标
• 度量模型
• 度量平台
• 度量驱动改进

度量目标和原则

目标：提高部署效率、缩短开发周期、更可靠发布……

多快好省

• 更高产能
• 更快的相应速度
• 适当的质量
• 合理的成本

If you can't measure it, you can't manage it.
如果不能度量，就不能管理
如何度量，就会如何改变行为

度量的原则就是帮助组织达成目标。

核心原则1：通过度量来洞察过程和问题（反馈）

核心原则2：通过度量来激发行为的产生（持续改进）

image.png

度量的成本超乎想想：

• 指标达成共识的沟通成本
• 度量数据采集的成本
• 度量报告发送的成本
• 度量带来改造的成本
• 不好的度量不仅没有帮助，反而会带来伤害

需要注意的是：

1. 不要为了度量而度量，度量只是手段，而非目标
2. 不要只在看得见的地方进行度量
3. 不要盲目引入“大量”指标进行度量
4. 不要单纯的追求数字本身而忽视能力本身
5. 最重要的是，不要忽视人的价值

经典的GQM模型
Goal、Question、Metrics
我要解决的现实问题是什么
为了解决这个问题，我需要获取哪些相关信息，这些信息如何帮助解决上述问题
使用哪些指标，能最好的反映上述问题信息
Google的GSM+QUANTS体系
Goal、Signals、Metrics
Quants核心要素指导Goal

度量指标

度量指标是有效率差异的
为了达成一个目标，选取该指标的有效性，以及衡量指标的成本。
举例：平均响应时长 vs TP99（TOP 99），应该考虑TP99指标，不仅可以展示出现状，还能指导应该改进的地方

DEVOPS状态报告的调查方法：4大指标：部署频率、变更前置时间、服务恢复时间、变更失败率

定量指标应该和定性指标保持一致，如果不是的话，是定量指标还是定性指标出的问题。（往往是定量指标出的问题）

指标的三大原则
1. 关注结果优于过程
对于大指标，需要拆细。案例：一五原则：1分钟内发现问题，5分钟内修复问题。

2. 关注效果优于产出

3. 关注全局优于局部
全局即适用于结果指标，也适用于团队指标。某个领域的指标可能反应另一个领域的问题。

指标的几大特征
1. 指标要有明确的受众（用户角色）
2. 直指问题（牵引行为）
举例：
代码行数：太多（复杂性、可维护性）；太少（可读性）；有时候能够不写代码解决问题，甚至删除荣誉代码也是好事。
度量指标的好坏要在上下文内来把握，比如使用代码行数来控制提交颗粒度从而有效达成评审也是有意义的。
3. 量化趋势（变动方向）
数据尽量量化，而且有相对标准的衡量口径
4. 可拆解描述（可解释可证明）
结果客观，可解释可分解，非玄学
指标关联和影响关系，可以层层下钻到可改善的点
结果指标拆解成过程指标
指标的路径分析，指标不仅仅是一个点，而是需要变成一个网。

度量数据分析
从事故和问题出发，从目标出发，建立指标关系
三种方式

1. 从结果到过程：结果指标对应的过程指标
2. 从实践出发分析（比如持续集成）
3. 从局部经验出发分析
   发现前置环境问题，倒推规则和标准化落地

人工的指标如何才能推动落地

好的度量指标：多快好省

度量模型

指标的构成要素

• 指标名称
• 描述
• 级别（组织级、项目级）
• 类型（过程、结果、预测）
• 数据来源（自动、手动）
• 计算公式
• 参考值
• 适用场景（问题场景）
• 目标受众
• 负责团队（跟进团队）

• 数据时效（T+0，T+1，实时）

  
  
  image.png

度量指标不等于度量体系

左手指标，右手实践，平台支撑，改进驱动
度量只能发现问题，不能解决问题，解决问题依赖于“最佳”实践
GQMP

如何识别项目的问题来制定指标？

结合效能报告来向上传递价值

找到自己的北极星指标：

1. 代码质量管理：代码评审覆盖率
2. 事件管理：事件解决率
3. 缺陷：缺陷逃逸率
   每个领域都会有核心指标，适合长期关注

image.png

度量平台

1. 指标采集器

image.png

2. 数据库选型

image.png

3. 面板展示

widget自定义

未来潜在场景：

1. 代码大数据分析
2. 研发辅助和诊断
3. 工程师画像
4. 智能研发

转型与持续改进

转型方法

研发能力是企业的核心竞争力。聚焦业务价值、透视研发能力、深挖研发红利。
持续改进是没有终点的，转型工作无处不在，转型带来深刻的改变，变化比计划来的更快，没有一条通用的路径
转型策略：

1. 自底向上
2. 自顶向下
3. 两者结合：顶层支持+底层参与
   要素：
   合适的时机（学会造势和借势）

• 内部造势（发声，向上沟通，黑马），外部借势（大会，行业标准，友商）
  DevOps人才（培训体系）
• 人才能力模型、技能模型
  关键能力（技术实践）
• 持续交付、架构设计、产品和过程、精益管理和监控、协同文化
  更多的盟友，更少的敌人（实现共赢）

转型路径

三步工作法
TOYOTA KATA（丰田方法）

• 团队获得新技能的步骤
• 每日刻意练习
• 按照KATA实践
• 教练辅导反馈
• 自我掌握新技能
  通过度量来认清现状，明确方向，设定下一个目标，不断尝试达成目标
  敏捷团队的病与药——阿里健康医药B2B团队敏捷转型手记

转型阶段

个体级：关注人才培养和能力提升
devops是一个服务型团队
将效能纳入到晋升体系中
团队级：团队试点，沉淀体系
精力一定要聚焦

• 收敛范围，以试点成功为目标，给与管理层和员工信息
• 建立团队连接，识别核心人员，长期合作共赢

• 摸索内部“最佳”实践可行性，沉淀经验和案例
  选择：核心业务、全功能团队、改进意愿、上下认可度、组织级能力支持

  
  
  image.png

组织级转型
挑战：如何快速复制成功
转型要点：打造能力模型，识别撬动指标；组织级能力建设（平台化建设）；培养内部DevOps教练；沉淀面向场景的落地实践；“可感知”的效率提升
实践积累沉淀成模型
平台化的最大意义是承载企业内部的标准化流程
企业平台化建设路径：

• 从无到有：独立工具（开源/商业化） - 工具化
• 从繁到简：半自研+封装工具（开源/商业） - 平台化
• 从小到大：自研平台+整合工具（开源/商业/自研）- 生态化
  组织级平台化需要考虑：
• 可被扩展（可通过插件的方式扩展）
• 可被集成（可被其他平台集成）
• 可被信赖（作为可信赖的工具平台：可用性，安全性，数据准确性）

场景化的落地实践手册：百度，阿里

常见模型：
工信部devops模型