DevOps和SRE Manager必须衡量的指标

DevOps和SRE具有用于监视服务和产品性能的仪表板，现在我们该了解如何衡量这些团队的性能了。

每家公司如今面临的一项重大挑战是衡量。 有必要了解公司和产品内部各个层面的情况，从客户如何使用应用程序到代码的质量和效率，再到团队的绩效。

在评估DevOps和SRE团队时，我们面临着一个全新的挑战。 他们负责交付渠道，衡量和确保其正常工作是他们的工作。 从编写代码的开发人员到测试和部署代码的工具，再到产品在现实世界中的行为方式。

尽管DevOps和SRE会衡量性能，但要确保应用程序生命周期中的每个步骤都正常运行，但我们需要了解如何衡量它们。 我们告诉您这是一个挑战，但是我们也有一些好消息–只要您专注于重要的事情，就有可能。

我们应该测量什么？

DevOps和SRE必须掌握应用程序内部发生的所有事情。 他们需要有一个实时监控系统，这将帮助他们查看应用程序的正常运行时间，加载时间，API调用的次数和成功，CPU进程线程，内存使用率和其他指标。

确保他们一切正常并运行是他们的工作，但我们要确保他们按预期进行。 为此，我们还需要查看整个应用程序和工作流程，以找到有关我们感兴趣的每个参数的答案和数据。

这些通常包括：

• 通过查看周期时间，我们希望确保开发团队的交付速度比以前快 。
• 我们需要知道， 快速部署不会损害代码的质量，而质量可以用产品的可用性来衡量。
• 我们希望通过查看回滚百分比来监视产品的质量 。
• 当然，我们希望确保我们的用户和客户满意 ，这可以通过查看回滚百分比或发送的投诉来实现。

这些参数中的每个参数都包含一个指标和计算的世界，试图监视所有参数和计算就像尝试在7月4日拍摄整个烟花表演：可以做到，但是却没有重点。

为了帮助我们自助，我们需要缩小范围。 而且由于我们的目标是衡量自己的团队和运营，因此退后一步并更全面地了解所有内容会变得更加容易。 现在，让我们将这些类比转化为实践。

借用Google的联络点

DevOps和SRE必须监视应用程序的许多不同方面，但这并不意味着我们也需要监视它们中的每一个。 此外，这并不意味着我们需要大量的仪表板只是为了了解团队是否在做自己的工作。

为了缩小范围，我们可以采用Google的方法来衡量其SRE团队。 该公司将监视DevOps和SRE所需的所有元素封装为三个基本度量，每个度量都有自己的基准：

服务水平目标（SLO）

在Google中，服务水平目标（SLO）是表示系统可用性的数字或百分比。 这表明系统是否按预期运行，以及产品是否稳定。

此数字将帮助我们了解产品的状态和质量，并在我们加快部署速度时确保代码质量。 DevOps和SRE团队的部分职责是维护应用程序的可靠性和功能。 该指标清楚地表明了团队在实现该目标方面的成功程度。

服务水平指标（SLI）

此度量标准通过计算请求延迟，每秒请求的吞吐量或随时间测量的每个请求的失败来衡量每个请求的失败。 它连接到确定的SLO编号，并帮助评估团队是否在其SLO范围内。

通过查看诸如系统可用性之类的指标，可以更轻松地了解何时发生错误和故障。 合理的下一步是查看导致错误和失败的原因。 这将使我们能够监视我们的服务的可靠性，并且我们可以通过查看DevOps和SRE团队正在测量的相同统计信息来做到这一点。

服务水平协议（SLA）

服务级别协议（SLA）是您与您的用户/客户之间的协议，指示服务和产品的可用性。 与SLO和SLI不同，这是一个松散的指标，可以根据您提供的服务或要为其提供服务的客户而变化。

SLA应该源自SLO，因为在与客户签订合同和作出承诺之前，您要确保对系统可用性有自己的定义和理解。 从度量角度来看，监视SLA将有助于我们了解DevOps和SRE是否与自己设置的数量保持一致。

最后的想法

您希望您的产品好，客户满意，公司成功。 但是，如何在没有附加正确的数字和指标的情况下知道自己是否处在正确的轨道上呢？

了解如何监控DevOps和SRE是一个挑战，但是您需要能够衡量产品中的所有内容–这些团队是其中很大的一部分。

尽管每个公司都有自己的一套要求，方法和团队结构，但专注于监视SLO，SLI和SLA可以帮助您了解要关注的指标以及团队的绩效。

如果您想了解有关DevOps，SRE，它们之间的差异以及适合您公司的位置的更多信息， 请查看此文章 。

翻译自: https://www.javacodegeeks.com/2018/09/metrics-devops-sre-manager-measure.html