如何衡量持续交付

在实施持续交付时，稳定性和吞吐量是两个可衡量的度量指标。这些度量指标有助于降低不确定性，帮助你做出更好的决策，让整个持续交付过程不偏离正确的方向。

持续交付独立咨询师 Steve Smith 将在精益敏捷苏格兰2017 大会上呈现一个关于如何衡量持续交付的演讲。大会将于10 月4 号至6 号在爱丁堡召开。

InfoQ 采访了 Smith，并从他那里了解到了一些信息，比如实施持续交付为什么会如此困难、为什么说度量指标有助于实施持续交付以及该用到哪些度量指标、他从英国政府部门使用度量指标这一实践当中学到了什么、Google 的 SRE 概念“错误预算（error budget）”与他的持续交付度量指标有什么联系。

InfoQ：实施持续交付为什么会如此困难？

Steve Smith：有两部分人在实施持续交付——一部分人知道它很难，另一部分人则否认这一点。持续交付的难点在于，你试图在组织中引入大量的技术和组织变革。

实现变更的自动化并不难，比如自动化数据库迁移或事后故障检测。工具的选择也不难——很多工具都很强大，只要你不去选择最糟糕的那个就好。难就难在如何在组织的约束当中应用这些变更。每个组织的持续交付都不一样，在一开始就要意识到这一点。

InfoQ：度量指标对实施持续交付有什么帮助？

Smith：度量指标有助于降低不确定性，帮助你做出更好的决策。你因此可以了解到你的实施过程是否偏离了正确的方向。

我一般会建议我的客户先从 Improvement Kata 开始，创建可迭代的周期，逐步改进当前的工作方式。但在你畅想愿景时，你怎么知道愿景离现实有多远？当你想要建立下一个改进里程碑的时候，你怎么知道该怎样设定目标？当你完成自动化数据库迁移的时候，你怎么知道它是否给当前的状态带来了改进？

度量指标无法回答这些问题，不过它们可以作为指引，告诉你应该去哪里去寻求答案。我在英国政府的一个重要部门工作了两年半，我们有 60 个团队在实施持续交付。如果没有度量指标，我们就不知道哪些团队表现出色，不知道哪些团队需要我们的帮助，不知道该发扬光大哪些实践或避免哪些不好的实践。有了这些度量指标，我们就知道需要与哪些团队展开沟通以及该沟通些什么。

InfoQ：你建议应该衡量哪些度量指标？

Smith：持续交付就是要改进稳定性，加快发布速度，所以毫无疑问，你需要衡量稳定性和速度。这两项指标虽然不是很直观，但要衡量它们并不难。在“ How To Measure Anything ”这本书中，Douglas Hubbard 描述了如何使用澄清链（clarification chain）来衡量无形的东西——创建有形的资产并将其与相应的度量指标联系在一起。

对于我们来说，我们已经知道该衡量哪些指标了。 DevOps 年度报告中，Nicole Forsgren、Jez Humble 等人陈述了组织在实施持续交付过程中是如何改进稳定性和吞吐量这两项指标的。他们通过失败率（Failure Rate）和失败恢复时间（Failure Recovery Time）来衡量稳定性，通过交付时间（Lead Time）和频率（Frequency）来衡量吞吐量。从 2013 年开始，我就很看好 Nicole 喝 Jez 在这方面所做的工作，而且我也深入研究过这些指标与持续交付之间的关系。所以我建议衡量这两项指标。

InfoQ：在英国政府部门实施持续交付的过程中，你学到了什么？

Smith：我从中总结了一个经验，不借助度量指标实施持续交付就好比在生产环境中没有监控措施。没有度量指标的指引就好像无头苍蝇到处乱撞。你无法知道哪些变更被成功实施，需要将其发扬光大，哪些是失败的，需要尽快回退。

在这个政府部门里，我们创建了一个内部网站用于展示每个团队和服务的稳定性和吞吐量度量指标。借助这些，我们就知道该与哪些团队展开沟通，也了解到了一些不寻常的问题。例如，有一个团队在短时间内大幅改进了部署的稳定性，但他们却不知道自己做了哪些事情让稳定性获得提升的。而实际上是因为他们构建了自己的日志和监控仪表盘。我们后来把他们仪表盘的 JSON 文件抽取出来，并开发了一个 DSL 用于生成相同的 JSON，把它推广到所有的团队。几周之后，很多团队向我们反应生产环境的服务运维变得更加容易了。

InfoQ：你是如何理解 Google SRE 概念“错误预算”的？它与你的持续交付度量指标有什么关系吗？

Smith：“ Site Reliability Engineering ”这本书写的非常好。Betsy Beyer 等人将可靠性定义成 MTBF 和 MTTR 的功能之一，这个与将持续交付定义成失败率和失败恢复时间的功能之一有着异曲同工之妙。

错误预算是一个很好的概念。我总是建议产品经理定义好自己的运营需求，包括产品的可靠性。如果他们衡量严格的发布稳定性和吞吐量，并在稳定性低于某个阈值的时候阻止自动部署到生产环境，那一定会很有意思。我见过一些公司对构建过程中的静态分析、OWASP 测试进行打分。不过我没有见过对部署稳定性进行打分，但我希望能够看到这样的事情发生。

查看英文原文： How to Measure Continuous Delivery