如果不能度量，你将无法改进。

——彼得.德鲁克

上述彼得.德鲁克大师的名言，让我们在直觉上产生共鸣，同时也展示了度量在各个领域的重要性。如果没有数据去定量分析我们当前在哪里、目标在哪里，那么我们将如何知道目前是否在向着正确的目标前进？下面这篇博文讲述了在持续交付过程中度量的重要性。

一、度量在持续交付过程中是如何起作用的？

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

通过综合分析总结，我们识别了4个有价值的度量指标:

• 可发布的软件包数量
• 周期时间
• 故障平均间隔时间
• 故障平均恢复时间
  
  

二、你有多少可发布的软件包？

为了实现成功的持续交付，你需要持续提交代码，特别是持续提交代码到主干分支（master）。如果总是向个人分支提交代码，那么这样的提交将不会对即将发布生产的代码带来任何价值。

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

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

作为严谨的路线图规划的一个补充，研发团队应该利用一些新的技术，如feature toggles（特性切换），通过feature toggles配置实现功能的打开或者关闭（控制展示与否），从而实现把Feature发布到生产环境，同时保持客户的无感知状态（如蓝绿发布等场景）。

三、你的周期时间是多少？

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

这段停滞时间不但不能让你加速交付价值给客户，还会造成工作焦点发散。提高团队的周期依赖于高效的测试和快速的反馈闭环。

下面有一些实践可以帮助你缩短周期：

• 尽早执行UT，让UT早于Pipeline和复杂的、需要长时间执行的自动测试，这将会让你提前获得一些基本反馈，节约时间。
• 让依赖在Pineline stage间传递可以避免不必要的重复构建，这会比较有帮助。
• 让构建尽可能的并行执行，这也会节约不少时间。
• 最后，确保你拿到了正确的构建资源，这样不管你需要跑什么构建，都会有充足的Agent去跑各类任务。
  
  

四、你的故障平均间隔时间和平均恢复时间是多少？

故障平均间隔时间和恢复时间往往是相关联的，因为二者间的平衡非常重要。故障平均间隔时间让团队总是尽可能的确保版本的稳定，尽力避免失败。但是，仅仅关注平均失败间隔时间、减少失败，会导致团队过度谨慎，不愿发布新版本。而软件研发的核心是不断提供新价值给用户，满足用户需求。因此，平均故障恢复时间将会是一个关键制衡点，该指标展示团队纠正错误的能力。

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

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

五、总结

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

如果不能度量，你将无法改进。

——彼得.德鲁克

上述彼得.德鲁克大师的名言，让我们在直觉上产生共鸣，同时也展示了度量在各个领域的重要性。如果没有数据去定量分析我们当前在哪里、目标在哪里，那么我们将如何知道目前是否在向着正确的目标前进？下面这篇博文讲述了在持续交付过程中度量的重要性。

一、度量在持续交付过程中是如何起作用的？

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

通过综合分析总结，我们识别了4个有价值的度量指标:

• 可发布的软件包数量
• 周期时间
• 故障平均间隔时间
• 故障平均恢复时间
  
  

二、你有多少可发布的软件包？

为了实现成功的持续交付，你需要持续提交代码，特别是持续提交代码到主干分支（master）。如果总是向个人分支提交代码，那么这样的提交将不会对即将发布生产的代码带来任何价值。

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

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

作为严谨的路线图规划的一个补充，研发团队应该利用一些新的技术，如feature toggles（特性切换），通过feature toggles配置实现功能的打开或者关闭（控制展示与否），从而实现把Feature发布到生产环境，同时保持客户的无感知状态（如蓝绿发布等场景）。

三、你的周期时间是多少？

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

这段停滞时间不但不能让你加速交付价值给客户，还会造成工作焦点发散。提高团队的周期依赖于高效的测试和快速的反馈闭环。

下面有一些实践可以帮助你缩短周期：

• 尽早执行UT，让UT早于Pipeline和复杂的、需要长时间执行的自动测试，这将会让你提前获得一些基本反馈，节约时间。
• 让依赖在Pineline stage间传递可以避免不必要的重复构建，这会比较有帮助。
• 让构建尽可能的并行执行，这也会节约不少时间。
• 最后，确保你拿到了正确的构建资源，这样不管你需要跑什么构建，都会有充足的Agent去跑各类任务。
  
  

四、你的故障平均间隔时间和平均恢复时间是多少？

故障平均间隔时间和恢复时间往往是相关联的，因为二者间的平衡非常重要。故障平均间隔时间让团队总是尽可能的确保版本的稳定，尽力避免失败。但是，仅仅关注平均失败间隔时间、减少失败，会导致团队过度谨慎，不愿发布新版本。而软件研发的核心是不断提供新价值给用户，满足用户需求。因此，平均故障恢复时间将会是一个关键制衡点，该指标展示团队纠正错误的能力。

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

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

五、总结

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