DevOps 指标的 3 个警告信号

指标。 衡量。 数据。 监控。 警报。 这些都是 DevOps 以及更广泛的云原生基础设施和应用程序开发的重要主题。 事实上，计算机协会 (Association of Computing Machinery) 出版的杂志 acm Queue 最近专门用整期来讨论这个话题。

我之前就说过，我们在“指标”这个术语下混淆了很多东西，从关键绩效指标到关键故障警报，再到可能在未来某天对某些事情有用的数据。 但那是另一天的话题。 我想在这里讨论的是指标如何影响行为。

2008 年，丹·艾瑞里 (Daniel Ariely) 出版了 可预测的非理性，这是一系列在那个时期撰写的书籍之一，向公众介绍了行为心理学和行为经济学。 这本书中一句令人难忘的名言是：“人类会根据他们所承受的指标调整行为。 你衡量的任何东西都会促使一个人优化他在该指标上的得分。 你衡量什么，你就会得到什么。 就这样。”

这不应该令人惊讶。 这是一个已被研究反复证实的发现。 对于几乎所有有商业经验的人来说，这也应该很熟悉。 例如，对于销售管理人员来说，这肯定不是新闻。 完全根据收入来确定销售代表（或他们的经理！）的奖金，他们会不惜一切代价来最大化收入，即使这会损害利润率。 相反，想让销售团队推广一条新的产品线——这可能会花费额外的精力——但却跳过 销售激励？ 可能不会发生。

为了避免您认为我不公平地针对销售，这种行为是普遍存在的，一直到 CEO，正如艾瑞里在 2010 年哈佛商业评论文章 中描述的那样。“CEO 关心股票价值，因为那是我们衡量他们的方式。 如果我们想改变他们关心的东西，我们应该改变我们衡量的东西，”艾瑞里写道。

认为开发人员和运维人员可以免受这种行为的影响？ 再想想。 让我们考虑一些有问题的衡量标准。 它们并非都糟糕或错误，但是，如果您过分依赖它们，就应该发出警告信号。

DevOps 指标的三个警告信号

首先，是数量指标。 代码行数或修复的错误数量或许不言而喻地荒谬。 但是，每周或每月的部署次数也被广泛引用，以说明 DevOps 相对于更传统的开发和部署实践的速度。 速度是好的。 这是您可能正在进行 DevOps 的原因之一——但不要过度奖励人们的速度，相对于质量和其他衡量标准而言。

其次，很明显，您希望奖励那些工作做得又快又好的人。 是的。 但是。 无论是您当地的职业运动队，还是您曾经参与过的某个项目团队，您可能都能说出一个真正有才华的人，但这个人太 токсичный 了，对其他所有人来说都是一种干扰，以至于他们对团队来说是一个净负面因素。 道理：不要提供仅仅鼓励个人行为的激励措施。 您可能还需要实施一些计划，例如同行奖励，明确重视协作。 正如红帽的 Jen Krieger 去年在播客中告诉我的那样：“拥有那些自动化的奖励资金，或者某种为此跟踪的系统，只能帮助团队感觉彼此之间更具合作精神，例如，‘嘿，我们都在一起努力完成某件事。’”

第三个红色警告区域是不实际激励的激励措施，因为个人或团队都没有对结果产生有意义影响的能力。 当 DevOps 指标与业务目标和结果相关联时，这通常是一件好事。 例如，客户工单量与应用程序和基础设施中感知到的缺点有关。 这也是衡量总体客户满意度的合理指标，而客户满意度当然应该是高管层感兴趣的。 推动 DevOps 行为的最佳奖励系统应该与具体的个人和团队行动联系起来，而不是仅仅与公司整体的成功联系起来。

您可能已经注意到一个共同的主题。 这个主题是平衡。 速度是好的，但质量也很重要。 个人成就是好的，但当它损害团队的效率时就不是好事了。 企业的整体成功当然很重要，但最好的奖励系统也会与开发和运维中的行动和行为联系起来。