皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

如何衡量持续交付

作者 Ben Linders ,译者 薛命灯

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

持续交付独立咨询师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

转自 http://www.infoq.com/cn/news/2017/09/measure-continuous-delivery