度量DevOps四个关键指标

发表于 2021-03-01 更新于 2021-03-30 分类于工作

最近看了篇Google出的关于DevOps的文章《度量DevOps四个关键指标》，在这儿做个记录。google翻译+蹩脚的自我理解，莫吐槽，将就看。

通过六年的研究，DevOps研究与评估（DORA）团队确定了四个关键指标，这些指标指示了软件开发团队的绩效：

变更的部署频率和变更前置时间可以衡量速度，变更失败率和恢复服务的时间可以衡量稳定性。通过衡量这些价值，并不断进行迭代来改进它们，团队可以取得更好的业务成果。

然后说了一下google cloud的做法。后面跟google cloud提供的服务有关的就不翻译文字了。

本节讨论如何将DORA度量标准转换为系统级计算。DORA团队所做的原始研究是对真实的人进行调查，而不是收集系统数据并将指标存储到性能级别中，如下所示：

1	一个组织成功地部署到生产环境的百分比。

部署频率是最容易收集的指标，因为它只需要一个表。但是，频率存储也是要计算的棘手元素之一。显示每日部署数量或每周获取平均部署数量将很简单明了，但指标是部署频率，而不是数量。

在“Four Keys”脚本中，当每周至少进行一次成功部署的中位数天数等于或大于三时，“部署频率”将落入“每日”时段。简而言之，要想部署频率值为“每日一次”，则必须在大多数工作日进行部署。同样，如果大多数部署都是一星期一次，则将是每周一次，然后是每月一次，依此类推。

接下来，则需要考虑是基于哪些原因及资源构成了成功的生产部署。您是否包括仅占5％流量的部署？80％？默认情况下，仪表板包括任何成功部署到任何级别的流量。

1	一次提交进入生产环境所花费的时间。

“变更前置时间”度量标准需要两个重要的数据：何时发生提交和何时进行部署。这意味着对于每个部署，需要维护对应的更改的列表。使用部署表中的更改列表，每次数据的重新加入时同时获取相应的时间戳，用于计算中位数。

1	用于生产环境部署失败的百分比

变更失败率取决于两件事：尝试了多少次部署，多少次导致生产部署失败？

“组织从生产故障中恢复需要多长时间”

要测量恢复服务的时间，您需要知道事件的创建时间和解决时间。还需要知道何时发生故障以及何时部署解决了该故障。与上一个指标类似，此数据可以来自任何故障管理系统。

这个就不多说了。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。