DevOps 指标中的常见错误

开发 前端
作为持续改进过程的一部分,指标对于 DevOps 和持续交付至关重要。但是,您必须在收集和显示数据与大量信息之间取得平衡。

作为持续改进过程的一部分,指标对于 DevOps 和持续交付至关重要。但是,您必须在收集和显示数据与大量信息之间取得平衡。

作为持续改进过程的一部分,指标对于 DevOps 和持续交付至关重要。但是,您必须在收集和显示数据与大量信息之间取得平衡。您需要随时决定要收集哪些数据以及关注哪些较小的数据集。

如果你的汽车有一个仪表板,显示它通过发动机管理系统收集的每一个指标,那么就没有挡风玻璃的空间了。

早期汽车的仪表盘上只有一个电流表,用于测量电池和稳压器之间的电流。这很重要,因为它告诉您充电系统正在工作。没有速度表。汽车只能达到每小时 35 英里的最高速度,而悬架不鼓励以这种速度行驶。没有必要测量速度。

在现代汽车中,没有为电流表留出仪表板空间(尽管如果出现问题,电池指示灯会亮起)。但是,你会发现几乎每辆车都有一个速度表。当前的仪表板设计反映了汽车的发展及其运行的更广泛系统。发动机更强大,悬架系统更好,道路总体上更平坦,路上行驶的汽车更多。对安全的态度也发生了变化。

同样,随着您对团队和组织中的差异做出反应,您收集和显示的指标也会随着时间的推移而发生变化。

当您创建和发展您的测量系统时,您应该避免一些常见的错误。

忽略数据

指标的第一个问题是您花费大量精力收集它们,但并不总是使用它们。即使在定期审查数字的组织中也会发生这种情况。

您的数据需要一些产生洞察力的过程。您可以将您从信息中发现的内容转化为用于实验的理论。然后,实验应提供新数据以再次开始循环。

收集 DevOps 指标的唯一好理由是更多地了解你的工作并找到改进它的方法。如果你收集数据只是为了以防万一,它很可能会被滥用或根本不被使用。

活动偏差

有四个测量级别,活动通常是最早和最容易收集的。您通常可以近乎实时地跟踪活动。活动的结果通常不能作为输出或基于结果的度量标准,直到稍后的某个日期。

活动指标通常是您现有工具的内置功能,因此它们已经可用。问题不是所有的活动都代表进步。有些活动甚至可能会减少产出并导致更糟糕的结果。

您可以使用活动指标来预测输出和成果的未来变化。为此,您必须不断测试活动指标与相关输出或结果指标之间的关系。

如果你只测量活动,你会得到很多运动但没有进步。

一次跟踪太多指标

您收集和显示的指标数量可能会增加,而且通常会迅速增加。不久之后,您的仪表板中充满了图表,您不知道什么是重要的,什么不是。

您需要使跟踪的指标保持精简、最新和相关。当图表不再有用时,您应该将其从仪表板中删除。您还应该考虑是否仍需要收集指标并在没有充分理由跟踪它时将其淘汰。

如果您已经有一个仪表板,请打开它,然后针对每个图表询问“如果这个数字上升或下降,我会做些什么不同的事情?”。经常重新审视这个问题,删除您没有答案的任何图表。

您的指标集应侧重于关键的长期输出和成果指标,仪表板显示您当前改进工作中所有类别的短期指标。

使用工具

Microsoft Power BI、Tableau 或 Google Data Studio 等数据可视化工具是您组织中最有用的软件产品。许多业务工具都有基于网格或文本的界面,但数据工具却堆满了彩色动画图表。

创建一个引人入胜的仪表板很容易让人分心。如果您不从度量设计开始,您最终会得到许多对您的日常工作没有影响的令人愉悦的仪表板。您需要仪表板和图表工具来帮助您理解信息,但首先要设计指标。

最好从低保真度开始收集有意义的指标。可以从一个简单的电子表格甚至白板开始。在确定哪些度量对您的团队和组织有帮助后,开始自动化收集并创建流畅的显示。

如果您投入太多时间来创建令人惊叹的仪表板,您会发现在不再需要图表时很难将其删除。

标准化

一些组织试图通过让其他团队遵循相同的流程来复制高绩效团队的成功。这很少能成功,因为每个团队处理不同的问题并且具有不同的技能水平。正如流程和实践需要特定于上下文一样,指标也是如此。

您应该将指标作为持续改进活动的一部分。对于提前期较长的团队,您可以测量批次大小、排队时间以及工作在每个状态下花费的时间。这些指标不适合主要问题是质量的团队。

这需要数据、洞察力、理论和实验周期,你可以在其中查看你所拥有的关于你想要解决的问题的信息,形成一个关于什么可以改善问题的理论,然后运行一个实验来测试你的想法。

您收集的指标还会向团队发出当前重要的信号。您经常会看到改进,因为您的指标表明您关心软件交付的某些方面。

靠眼睛

您应该创建一个简单的仪表板来显示您为实验跟踪的指标。这应该显示在信息辐射器上,以便团队中的每个人都可以看到数据。

但是,如果您仅在有人查看仪表板时才对数据做出反应,那么您会在仪表板上塞满太多信息并错过关键事件。随着时间的推移,您保持跟踪进度的长期指标似乎与用于改进软件交付的短期指标一样重要。

解决保留长期指标而不会使仪表板混乱的问题的关键是为数据实施监控和警报流程。自动警报应该会告诉您指标是否超过阈值,并且您可以使用异常检测来告诉您是否发生了有趣的事情。

通过自动跟踪指标,您可以将它们从仪表板中删除以释放空间。

奖励表现

如果您的团队正在努力提高其部署率,那么如果他们实现每日部署,可能会很想通过奖励来激励他们。这种激励方法会导致不良结果。一个团队可能会为了实现目标而忽略其他关键工作——不是为了欺骗系统,而是因为你让日常部署比其他任何事情都重要。

在具有里程碑意义的《奖励惩罚》一书中,Alfie Kohn 解释说,试图通过激励来管理人员会给您的组织带来长期伤害。数百项研究发现,人们在获得奖励时会做得更差。

使用指标来营造竞争氛围,无论是为了个人表现、不同团队的比较,还是为了游戏化工作场所(在其中引入游戏元素作为“有趣”竞争的一种形式),都会导致麻烦。

竞争与您在组织中真正需要的东西相冲突:协作。如果你的工作假设人们想做好工作,你会发现你不需要使用奖励或惩罚来让他们提高绩效。

结论

5 个 DORA 指标和 SPACE 框架提供了预构建的、平衡的方法来衡量软件交付性能。(过去有 4 个 DORA 指标,但增加了一个额外的可靠性指标。)

一组好的指标将混合领先指标以预测性能与滞后指标以检查预测的准确性。测量应跨越活动、输出、系统输出和结果类别。

无论您衡量什么,您都需要不断完善您的指标,以确保它们对您的团队和组织仍然有用。理想情况下,您收集的指标与您为检验理论而运行的特定实验相关。

如果你很好地使用指标,你就会在寻求成为软件交付领域的精英之一时提高绩效和学习。

责任编辑:华轩 来源: 今日头条
相关推荐

2013-09-02 13:21:35

2020-12-26 15:19:00

DevOps误区开发

2009-06-22 08:39:27

Java常见错误Java类

2020-12-28 07:59:22

DevOps开发工具

2011-03-31 16:05:16

2011-03-31 16:08:35

2012-09-24 09:29:11

云应用部署云计算模式应用性能监控

2009-06-22 15:01:00

java项目常见错误

2018-09-05 09:33:41

DevOps转型指标

2023-10-26 12:01:30

Golang字符串

2023-09-07 11:53:05

2023-01-10 11:18:29

DevOps

2019-10-14 16:39:50

云计算配置错误企业

2020-03-20 15:10:09

Python错误分析代码

2021-06-16 15:04:06

JavaScript内存开发

2021-12-30 21:51:10

JavaScript开发内存

2012-05-23 09:28:14

Titanium错误应对办法

2019-06-21 10:13:26

JavaScript错误开发

2011-01-19 15:52:18

Qmail错误代码

2013-07-04 15:05:14

Android
点赞
收藏

51CTO技术栈公众号