AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

如何衡量持续交付

  • 2017-09-25
  • 本文字数:1930 字

    阅读完需:约 6 分钟

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

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

2017-09-25 19:003056
用户头像

发布了 322 篇内容, 共 151.5 次阅读, 收获喜欢 148 次。

关注

评论

发布
暂无评论
发现更多内容

案例研究之聊聊 QLExpress 源码 (八-1)

小诚信驿站

聊聊架构 28天写作 QLExpress源码 聊聊源码

Java虚拟机内存模型

xcbeyond

Java JVM Java虚拟机 28天写作

做事情的三条边

石云升

28天写作 基线 极限

为什么越南不会成为世界工厂?

JiangX

供应链 工业 28天写作 制造

爱了爱了!阿里爆款Spring进阶宝典,涵盖其所有技术栈(源码+实战彻底玩转Spring框架)

Java架构之路

Java 程序员 架构 面试 编程语言

线上问题排查学习总结

原来不悔

Java Linux

编程语言学习心得 (完全版) -- 不要害怕遗忘和混淆

蔡超

程序员 个人成长 编程语言 Go 语言

python自学 第四章 python语言基础之变量

WEB前端修行日志

Python 编码格式

写在开课前

5x

python自学 第二章 python语言基础之语法特点(注释、代码缩进、编码规范)

WEB前端修行日志

Python 编码格式

week8-conclusion

J

「架构师训练营 4 期」 第三周 - 001

凯迪

有些软件,听着听着就没了...

艾小仙

互联网

突破瓶颈,“iOS开发”,跳槽面试必备题(针对年后面试者)

Geek_24a3d9

面试 简历 ios开发

阿里首推的“SpringBoot+Vue全栈项目”有多牛X?

Java架构之路

Java 程序员 架构 面试 编程语言

Android面试总结(一)

我就感觉到快

2021年-iOS面试进阶资料总结(备战年后)

iOSer

学习 面试 iOS Developer iOS 架构RxSwift

Spring Boot 中的全局异常处理

武哥聊编程

Java springboot SpringBoot 2 异常处理 28天写作

使用 JSX 建立 Markup 组件风格

三钻

大前端 组件化

RocketMQ解析

石刻掌纹

如何实现CentOS服务器的扩容??

冰河

Linux centos 扩容 服务器

python自学 第三章 python语言基础之保留字、标识符与内置函数

WEB前端修行日志

Python 编码格式

网络攻防: 爬虫的钳形攻势

杨东冬

大数据 安全攻防 网络安全 爬虫 安全

不愧是Github上疯传的腾讯Java全栈进阶笔记!总结的太全啥都有!

Java架构之路

Java 程序员 架构 面试 编程语言

是什么可以在Github上标星85.4K,揭秘阿里Springboot项目笔记!

996小迁

Java 架构 面试 springboot

现成矿机挖矿软件系统APP开发案例

系统开发

产品经理训练营笔记-认识产品经理(上)

.nil?

一款dubbo服务可视化调试工具

程序员架构进阶

dubbo 工具 RPC 服务化 28天写作

C2C交易系统APP开发|C2C交易软件开发

系统开发

区块链交易所系统开发|区块链交易所软件APP开发

系统开发

基因编辑食品,能否端上我们的餐桌?

脑极体

如何衡量持续交付_DevOps & 平台工程_Ben Linders_InfoQ精选文章