您应该遇到某人喝咖啡。如果他们迟到三分钟，没问题，但是如果他们迟到了三十分钟，那就粗鲁了。从“无问题”变成“粗鲁”的变化是直线的，还是有提高粗鲁的步骤？我们在乎为什么吗？一个充分的理由肯定会增加我们的容忍度。一个总是很晚的人会减少它。
网络性能遵循许多相同的动态。我们曾经谈论中断，但是它们的频率较低。“慢”是新的“外出”。但是慢慢？我们是否尝试了解用户体验并调整我们的性能监控以反映它？还是只等到有人抱怨的唯一实际答案？
有一个最近的研究由企业管理协会询问了250个网络专业人员。其中一个问题问：“最终用户首先报告了网络性能问题的百分比，而不是由网络运营专业人员发现。”平均答案为39％，中位答案为35％。因此，在用户抱怨之前，我们不知道问题的三分之一（在某些组织中更高）？我们必须做得更好！
问题不是我们没有得到足够的报告。网络操作团队充斥着信息，但是太多的信息比噪音好。我们需要能够从数据蒸气中凝结见解（释义尼尔·斯蒂芬森）。但是，我们该怎么做？
起点的地方是通过对最终用户重要的术语来定义网络性能。对最终用户体验的关注是遵循旧的“落入森林中的树”的论点：如果存在绝对不会影响最终用户体验的问题，现在或以后，它仍然是一个问题吗？除非我们谈论的是物联网或专业系统，否则答案是否定的。
一旦我们知道重要的事情，我们就可以开始考虑过滤什么。确定重要的重要资源是Google的网站可靠性工程（SRE）团队。该小组写了一本名为“站点可靠性工程，”由Betsy Beyer等编辑。al。这本书质疑我们的一些传统思维。在监视方面，它描述的关键概念之一是团队所说的“四个金信号”或延迟，流量，错误和饱和度。（其他知名方法包括布伦丹·格雷格（Brendan Gregg）的使用方法， 或者汤姆·威尔基（Tom Wilkie）的红色方法）
为什么这些“黄金”信号对网络性能很重要？而且，如何使用此信息来指导您的网络性能监视策略？让我们单独研究。
潜伏
“延迟”延迟会议请求，可能是最有用的信号，如果出于最终用户经常经历的原因，没有其他原因。用户提出远程应用程序的请求。什么都没发生。就在他们要再次尝试请求时，他们会得到回应。他们一次不断地经历这种延迟时间，但随后它消失了，应用程序正常响应。然后回来。并走开。在决定制作麻烦票之前，他们会容忍多少这种轻度痛苦的经历？
如果网络操作团队可以监视延迟，则可以在用户首先体验它的同时看到该问题。但是，仅仅看到延迟正在发生是不够的。他们必须确定延迟是否发生，因为网络引入延迟或应用程序服务器的响应缓慢。还是同时发生？（并非很少发生。）一旦确定了，问题到底在哪里？知道答案通常足以解决问题。
交通
下一个黄金信号是“流量”，该信号由Google SRE团队定义为监视发生了多少请求。监视流量的一种好方法是查看网络对话的数量。
我知道一个大型企业在网络细分市场上有周期性问题。不过，奇怪的是，它与他们监视的任何指标都没有相关。有一些结盟，但令人沮丧的是，不足以建立根本原因。网络流量的数量（In Gbps）将增加，问题将更频繁，但并非总是如此。一天中的时间。哪种流量。最活跃的服务器。所有这些仅与此问题相对应。最后，他们开始衡量网络对话的数量，并发现一旦在10克链接上达到750,000次，他们的基础设施的一部分就会撞到墙壁，无论交通类型或数量如何。知道这一点，问题得到了迅速解决。
错误
然后是“错误”信号。错误不仅仅是失败的请求。可以将其视为用户体验的质量。如果您曾经打过一个反应迅速的VoIP电话，但是您仍然无法轻易理解所说的单词，那么您显然经历了低质量。但是，质量不仅是RTP（实时传输协议）问题，即使这是最明显的地方。即使我们很少看到持续的数据损坏，例如，有效载荷中有些损坏，例如，TCP（传输控制协议）质量差也可能导致许多问题。重传，掉落的帧甚至延迟。也许最重要的是，错误通常是即将发生的更大问题的警告信号。
饱和
最后一个黄金信号是“饱和度”，即交通量（与交易数量相反）。显然，我们要利用我们的网络容量，但是我们还需要允许利用中的尖峰。饱和的网络可以级联成为非常奇怪的故障模式，其中错误和重试消息会增加流量，从而使情况恶化。这个周期升级为止，直到如此糟糕以至于足够的交易失败为止，这些段又恢复了功能，直到模式重复为止。
如您所见，在评估如何管理网络性能时 - 既支持正在进行的操作又为将来的数字转型做准备 - 四个“黄金信号”可以发挥重要作用。它们使我们能够进入等待麻烦票的周期，并开始主动管理网络。
设定绩效标准时，您和组织面临哪些挑战？您是否依靠其他“信号”？如果是这样，请在评论部分中分享它们，以便我们可以进行打开的对话框。