你是精英DevOps的执行者吗? 通过“四个关键”项目找到答案

最新推荐文章于 2024-09-17 16:39:34 发布

信念随梦

最新推荐文章于 2024-09-17 16:39:34 发布

阅读量520

点赞数

分类专栏：效能度量文章标签：研发效能

原文链接：https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance

版权

效能度量专栏收录该内容

1 篇文章 0 订阅

订阅专栏

通过6年的研究，DevOps研究和评估 DevOps Research and Assessment (DORA)(DORA)团队已经确定了4个关键指标，用于指示软件开发团队的性能:

部署频率——成功发布产品的频率
变更交付时长——提交到生产中所需要的时间
变更失败率——在生产中导致失败的部署的百分比
服务恢复时间——从生产中的故障中恢复所需的时间

在高水平上，部署频率、变更交付时长用来度量速度，而变更故障率和服务恢复的时间用来度量稳定性。通过度量，并不断迭代，团队可以显著地获得更好的业务结果。例如，DORA使用这些指标来识别精英、高、中和低绩效团队，并发现精英团队达到或超过其目标绩效的可能性是其他团队的两倍

SELECT
  ...
  CASE WHEN source = "cloud_build" then JSON_EXTRACT_SCALAR(metadata, '$.substitutions.COMMIT_SHA')
       WHEN source like "github%" then JSON_EXTRACT_SCALAR(metadata, '$.deployment.sha')
       WHEN source like "gitlab%" then JSON_EXTRACT_SCALAR(metadata, '$.commit.id') end as main_commit
FROM four_keys.events_raw
WHERE ((source = "cloud_build"
    AND JSON_EXTRACT_SCALAR(metadata, '$.status') = "SUCCESS")
    OR (source LIKE "github%" and event_type = "deployment")
    OR (source LIKE "gitlab%" and event_type = "pipeline" and JSON_EXTRACT_SCALAR(metadata, '$.object_attributes.status') = "success")

根据这些度量标准为组织的绩效设定基线，是提高自身运营的效率和有效性的好方法。但是如何开始呢? 旅程从收集数据开始。为了帮助您为您的团队生成这些指标，我们创建了 Four Keys 开源项目，它自动设置一个从Github或Gitlab repo通过谷歌云服务和到谷歌DataStudio的数据吸收管道。然后，它会聚集您的数据，并将其编译到带有这些关键指标的仪表板中，您可以使用这些指标来跟踪您的进度。

为了使用Four Keys项目，我们在repo中包含了一个设置脚本（ setup script），从而使得从默认源收集数据和查看您的DORA指标变得很简单。对于任何对项目贡献感兴趣或对其自定义为其团队用例感兴趣的人，我们列出了以下三个关键组件:管道、指标和仪表板。

四个关键管道

四个关键管道是收集DevOps数据并将其转换为DORA指标的ETL管道。

然而，收集这些DORA指标的挑战之一是，对于任何一个团队(更不用说组织中的所有团队)，部署、更改和事件数据通常位于不同的系统中。我们如何开发一个开源工具，可以从这些不同的来源获取数据——以及从你将来可能想要使用的来源?

通过Four Keys，我们的解决方案是创建一个通用的管道，该管道可以扩展到处理来自各种来源的输入。任何可以输出HTTP请求的工具或系统都可以集成到Four Keys管道中，该管道通过webhook接收事件，并将其输入BigQuery。

在Four Keys管道中，已知的数据源被正确地解析为更改、事件和部署。例如，GitHub提交被更改脚本捡起，Cloud Build部署被归入部署，GitHub带有“事件”标签的问题被归类为事件。如果添加了新的数据源，而现有的查询没有正确地对其进行分类，开发人员可以通过编辑SQL脚本对其重新分类。

数据提取与转换

一旦原始数据进入数据仓库，就会面临两个挑战:提取和转换。为了优化业务灵活性，这两个流程都使用SQL处理。Four key使用BigQuery调度查询从原始事件表创建下游表。

Four Keys使用' WHERE '语句将事件分类为Changes、deployment和Incidents，并使用' SELECT '语句对数据进行规范化和转换。更改、部署或事件的精确定义取决于团队的业务需求，因此采用灵活的方式包括或排除其他事件就变得更加重要。

虽然每个团队的定义可能不同，但脚本确实提供了缺省值以帮助您开始。作为示例，下面是部署脚本:

Four Keys使用WHERE过滤器只从events_raw表中提取相关行，并使用SELECT语句将JSON中的相应字段映射到提交id。在BigQuery中进行数据转换的好处之一是，您不需要重新运行管道来编辑或重新分类数据。JSON_EXTRACT_SCALAR函数允许您在SQL本身中解析和操作JSON数据。BigQuery甚至允许您在SQL中编写自定义javascript函数!

计算指标

本节讨论如何将DORA度量转换为系统级计算。最初由DORA团队所做的研究调查了真实的人，而不是收集系统数据并将指标放入性能级别中，如下所示:

然而，询问一个人的部署频率要比询问一台计算机容易得多!当被问及他们是否每天、每周、每月等等进行部署时，DevOps经理通常有一种直觉，他们的组织属于哪一种类型。然而，当你向计算机要求同样的信息时，你必须非常明确自己的定义并做出价值判断。

让我们看看指标定义和计算中的一些细微差别。

部署频率（Deployment frequency）

一个组织成功发布产品的频率

部署频率是最容易收集的指标，因为它只需要一个表。然而，频率的波动也是比较棘手的计算元素之一。显示每日部署量或获取每周平均部署数量是简单而直接的，但度量的是部署频率，而不是数量。

在Four Keys脚本中，当每周至少有一次成功部署的天数的中位数等于或大于3天时，部署频率就被归入“每日”一栏。更简单地说，为了符合“每日部署”的要求，您必须在大多数工作日进行部署。类似地，如果您每周部署一次，那么将是每周部署一次，然后是每月部署一次，以此类推。

接下来，您必须考虑成功部署到生产环境的要素。你是否包括只有5%流量的部署?80% ?最终，这取决于您的团队的个人业务需求。默认情况下，仪表板包含任何级别流量的任何成功部署，但是可以通过编辑项目中的SQL脚本来调整这个阈值。

变更的前置时间（Lead Time for Changes）

“提交到生产所需要的时间”

变更的前置时间指标需要两个重要的数据:提交发生的时间，以及部署发生的时间。这意味着对于每个部署，您都需要维护部署中包含的所有更改的列表。这很容易通过使用带SHA映射回提交的触发器实现。有了部署表中的更改列表，您可以连接回更改表以获得时间戳，然后计算中间交货时间。

变更失败率（Change Failure Rate）

“导致生产失败的部署百分比”

变更失败率取决于两件事:尝试了多少部署，以及在生产中导致了多少失败? 为了获得这个数字，Four Keys需要部署的总数——很容易从部署表中获取——然后将其与事件联系起来。事件可能来自github上的bug或标签事件、表单到电子表格管道、问题管理系统等。唯一的要求是它包含部署的ID，这样我们就可以将两个表连接在一起。

服务恢复时间（Time to Restore Services）

从生产故障中恢复需要多长时间

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

看板

现在在BigQuery中聚合和处理了所有数据，您可以在Four Keys仪表板中可视化它。Four Keys设置脚本使用一个DataStudio连接器，它允许您将数据连接到Four Keys仪表板模板。仪表板旨在根据四个关键指标的DORA研究为您提供高级分类，并向您显示最近性能的运行日志。这使得开发团队能够及早察觉到性能的下降，从而减轻其影响。另外，如果性能较低，团队将在更新桶之前看到进展的早期迹象。

翻译： https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance