你应该约人喝杯咖啡。如果他们迟到3分钟,没问题,但是如果他们迟到30分钟,那就很无礼了。从“没问题”到“粗鲁”的转变是一条直线吗?还是粗鲁程度在不断增加?我们关心为什么吗?一个好的理由肯定会增加我们的容忍度。总是迟到的人减少了它。
网络性能遵循许多相同的动态。我们过去常常谈论停电,但现在已经不那么频繁了。“慢”是新的“过时”。“但是多慢才算慢呢?”我们是否试图理解用户体验并调整性能监控以反映它?还是等待别人抱怨是唯一实际的答案?
有一个最近的研究企业管理协会询问了250名网络专业人士。其中一个问题是,“有多少百分比的网络性能问题是由终端用户首先报告的,而不是由网络操作专业人员发现的。”平均答案是39%,中位数答案是35%。所以,有三分之一的时间(在一些组织中更高)我们直到用户投诉才知道问题的存在?我们必须做得更好!
问题不在于我们没有得到足够的报告。网络运营团队充斥着信息,但过多的信息比噪音好不了多少。我们需要能够从数据的蒸汽中浓缩洞察力尼尔。斯蒂芬森)。但是,我们怎么做呢?
首先从对最终用户重要的术语定义网络性能开始。对最终用户体验的关注沿袭了“森林中倒下的树”的说法:如果有一个问题对最终用户体验完全没有影响,现在或以后,它仍然是一个问题吗?除非我们在讨论物联网或专业系统,否则答案是否定的。
一旦我们知道了什么是重要的,我们就可以开始过滤掉那些不重要的。谷歌的站点可靠性工程(SRE)团队是一个很好的决定因素。这个团体写了一本(免费的)书,叫做“网站可靠性工程这本书对我们的一些传统观念提出了质疑。当涉及到监控时,它描述的一个关键概念是团队所称的“四个黄金信号”——即延迟、流量、错误和饱和。(其他著名的方法包括布伦丹格雷格的使用方法,或汤姆·威尔基的红色方法)。
为什么这些“黄金”信号对网络性能很重要?而且,如何使用这些信息来指导网络性能监视策略?让我们单独来研究一下。
延迟
“延迟”,即满足请求时的延迟,可能是最有用的信号,如果不是因为其他原因,而是因为终端用户经常体验到它。用户向远程应用程序发出请求。什么也不会发生。当他们准备再次尝试他们的请求时,他们会得到一个响应。他们每次都要经历几分钟的延迟,但是之后它就消失了,应用程序就正常响应了。然后它又回来了。和消失。在他们决定制造麻烦之前,他们能容忍多少轻微的痛苦经历呢?
如果网络操作团队可以监视延迟,他们可以在用户第一次遇到问题时看到问题。但是仅仅看到延迟的发生是不够的。它们必须确定出现延迟是因为网络引入了延迟,还是因为应用服务器响应缓慢。还是两者同时发生?(这种情况并不少见。)一旦确定了,问题到底在哪里?知道了这个问题的答案就足以解决问题了。
交通
下一个金色信号是“通信量”,由谷歌SRE团队定义,用于监视发生了多少请求。监视通信量的一个好方法是查看网络会话的数量。
我知道有一家大型企业在网络段上出现周期性问题。但奇怪的是,它与他们监控的任何指标都没有关联。有一些一致,但令人沮丧的是,还不足以确定根本原因。网络通信量(以Gbps为单位)会增加,问题会更频繁地出现,但并不总是如此。每天的时间。什么类型的流量。最活跃的服务器。所有这些都与这个问题无关。最后,他们开始测量网络对话的数量,发现在一个10G的链接上,一旦达到75万次,他们的一部分基础设施就会遇到瓶颈,无论流量的类型或数量。知道了这一点,问题很快就解决了。
错误
然后是“错误”信号。错误不仅仅是失败的请求。把它看作是用户体验质量的代表。如果您曾经使用过响应非常快的VoIP电话,但您仍然不能很容易地理解所讲的内容,那么您显然经历过低质量的体验。但是质量不仅仅是RTP(实时传输协议)问题,即使这是最明显的问题。尽管我们很少看到持久的数据损坏,比如有效负载中的一些数据翻转,糟糕的TCP(传输控制协议)质量可能会导致大量问题。重新传输,丢失帧,甚至延迟。也许最重要的是,错误往往是一个警告信号,预示着一个更大的问题即将来临。
饱和
最后一个金色信号是“饱和”,即通信量(与事务数量相对)。显然,我们希望利用我们的网络容量,但我们也需要考虑到利用率的峰值。一个饱和的网络可以级联成非常奇怪的故障模式,其中错误和重试消息增加流量,使情况更糟。这个循环会不断升级,直到出现足够多的事务失败,这些段会重新开始工作,直到重复这种模式。
正如您所看到的,在评估如何管理网络性能时——既要支持正在进行的操作,又要为未来的数字转型做准备——这四个“黄金信号”可以发挥重要作用。它们允许我们提前进入等待故障罚单的周期,并开始主动地管理网络。
您和您的组织在制定绩效标准时面临哪些挑战?你是否依赖其他“信号”?如果是的话,请在评论区分享,这样我们就可以有一个开放的对话。