devops涵盖的三个阶段

指标。 测量。 数据。 监控。 警报。 这些都是DevOps以及更广泛的云原生基础架构和应用程序开发的重要主题。 实际上，由计算机器协会发行的acm Queue杂志最近将专门用于该主题。

我之前曾争论过，我们将“指标”一词中的许多内容混为一谈，从关键性能指标到关键故障警报，再到有一天可能对某事有用的数据。 但这是另一天的话题。 我要在这里讨论的是指标如何影响行为。

这并不奇怪。 这一发现已被研究反复证实。 任何有业务经验的人都应该熟悉它。 例如，对于销售管理人员而言，这绝对不是新闻。 基本销售代表（或他们的经理！）的奖金完全是基于收入的，即使他们在厕所上留有利润，他们也会打折使收入最大化所需的一切。 相反，是否希望销售人员推销新产品线（这可能会花费更多的精力），但要 ？ 可能不会发生。

而且，以免您认为我不公平地推销产品，这种行为无处不在，一直到CEO为止，正如Ariely在所描述的那样。 “ CEO关心股票价值，因为这就是我们衡量股票的方式。如果我们想改变他们关心的东西，就应该改变我们衡量的东西，” Ariely写道。

认为开发人员和操作人员不受这种行为的影响吗？ 再想一想。 让我们考虑一些有问题的测量。 它们并不都是坏事或错误，但是，如果您过多地依赖它们，警告标志应该会上升。

DevOps指标的三个警告信号

首先，有数量指标。 修正的代码行或错误可能是不言而喻的。 但是，每周或每月的部署也被广泛引用以说明相对于更传统的开发和部署实践的DevOps速度。 速度不错。 这是您可能进行DevOps的原因之一-但相对于质量和其他指标，不要对它进行过多的奖励。

其次，很明显，您想奖励快速而出色地工作的人。 是。 但。 无论是您当地的职业运动队还是您所参与过的项目团队，您都可以任命一个确实才华横溢的人，但他是如此有毒，对其他所有人都如此分散注意力，以至于对他们来说都是负面的。 道德：请勿提供仅鼓励个人行为的激励措施。 您可能还需要建立明确重视协作的计划，例如对等奖励。 去年在播客中那样：“拥有这些自动奖励或某种跟踪到的系统，只能帮助团队彼此之间更加合作，例如，'嘿，我们“所有人都在共同努力，以完成工作。””

第三个危险信号区域是实际上没有激励的激励措施，因为个人和团队都没有有意义的能力来影响结果。 当DevOps指标与业务目标和成果相关联时，这通常是一件好事。 例如，客户票务数量与应用程序和基础结构中的缺陷有关。 而且，它还是整体客户满意度的合理代表，这当然对于高级管理人员来说应该是有意义的。 最好的激励DevOps行为的奖励系统应该与特定的个人和团队行为联系在一起，而不是仅仅与公司的成功相对应。

您可能已经注意到一个共同的主题。 这个主题是平衡。 速度好，但质量也好。 个人成就是好的，但是当损害团队的效能时却不是。 企业的整体成功当然很重要，但是最佳的奖励制度也与开发和运营中的行为和行为息息相关。

翻译自:

devops涵盖的三个阶段