title: 度量DevOps四个关键指标
author: Gamehu
tags:

  - DevOps
categories:
  - 工作
date: 2021-03-01 10:48:00

---

{% asset_img a.jpg %}

### 交代

最近看了篇Google出的关于DevOps的文章[《度量DevOps四个关键指标》](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance)，在这儿做个记录。google翻译+蹩脚的自我理解，莫吐槽，将就看。

### 开始

通过六年的研究，[DevOps研究与评估（DORA）](https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling)团队确定了四个关键指标，这些指标指示了软件开发团队的绩效： 

- **部署频率** - 成功发布产品的频率。
- **变更前置时间** - 变更从提交到发布所需要的时间
- **变更失败率** - 发布失败次数在部署中的占比
- **恢复服务的时间** - 从生产故障中恢复需要多长时间

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



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

{% asset_img q.png by 我 %}



### 指标计算

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

{% asset_img 12.jpg by cloud.google.com/devops %}



### 部署频率

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

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

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

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

### 变更前置时间

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

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

### 变更失败率

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

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

### 恢复服务的时间

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

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

### 仪表板

这个就不多说了。

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