慢是新的低调

我们从客户那里听说“慢就是新的低迷”。 对于大多数现代应用所有者和运营商来说，应用性能不佳是同样糟糕的事情。 FAANG公司已经让消费者习惯了持续出色的性能，而其他软件的客户也开始抱有同样的期望，尤其是当拥挤市场中的竞争对手提供良好的用户体验时。

一些客户甚至告诉我们，性能缓慢往往比完全瘫痪更糟糕。 当某件事情看起来几乎可以起作用时，一遍又一遍地重新尝试，这比仅仅缺乏功能更令人恼火。 例如，IP 语音质量很差，双方不得不一遍又一遍地重复，相比之下，IP 语音不可用，这导致人们转而使用手机或座机。

满足客户体验期望的重要性得到各行业的高度认可。 2020 年零售业的一项调查发现，对于近三分之一 (32%) 的受访者来说，改善客户体验是首要的数字重点。 超过 71% 的受访者表示，改善客户体验是他们希望通过数字化转型取得的最重要的短期业务成果。

现在，运营商和商业利益相关者确实同样关心他们的用户。 性能不佳的问题得不到解决的原因之一是缺乏对导致“缓慢”的原因的了解，或者对像他们这样的应用来说“缓慢”意味着什么。 有时，缺乏可见性是未能进行任何测量的直接结果。

Turbonomic 的一项调查揭示了这一现象（重点补充）： “当我们询问受访者他们的组织如何衡量应用性能时，令人欣慰的是，超过 60% 的受访者以某种形式对其进行了衡量。 但最常见的方法是测量可用性，而不是管理服务水平目标 (SLO)，后者通常采用响应时间或事务吞吐量的形式。 13％根本不测量应用性能。 ”

但在我们赞扬那些进行测量的人之前，先看看他们测量的是什么。 衡量性能的最常见方法是衡量可用性。 可用性是上升或下降的衡量标准。 它并不是衡量慢或快的标准，尽管我们可以花一整篇博客（或更多）来争论它应该如何衡量。

但事实并非如此，其中一个原因在于业务成本的可测性。 停机造成的财务影响是有据可查的。 我们可以找到提供整个组织成本详细分类的多个来源。 但为了表现呢？ 我们进行了一些调查，重点关注用户以放弃或负面社交媒体形式表现出的反应。 但企业的实际成本是多少？ 几乎不存在。

总的来说，我们可以将当今衡量性能的问题总结为“我们没有衡量缓慢的成本。 我们衡量停机成本。” 人类倾向于按照自己所衡量的标准去努力。 这不是一个新概念，事实上，它是 DevOps 的原则之一，也是该方法论包括将测量转向最重要的事物的原因。 在 F5，我们不仅计划帮助您以绝对尺度进行测量，而且还计划根据其他人的应用数据进行测量，以了解您的最终用户对您的应用的体验与他们体验其他类似应用的体验相比如何。

最重要的是满足最终用户的期望，而今天这不仅仅意味着可用；它还意味着快速和可靠。 我们计划不仅通过最终用户体验的数据和可视化来帮助应用所有者，而且还通过自然语言表达见解，例如“您在周末推动生产的更改改善了最终用户周一早上的典型体验，做得很好！”或“预计四天内您为纽约 Chrome 用户的体验将比同类银行应用的平均水平更差。 以下是我们建议您对 AWS 美国东部的 NGINX 负载均衡器进行的负载均衡策略更改。 您可以自行进行更改，也可以单击此处让我们为您进行更改。”

如果你想知道以下问题的答案：

• “我的最终用户总体体验是否良好？ 
• 与我的类似应用相比，他们的体验如何？ 
• 我是否可以为我的应用公开一个简单的健康指标，其中包含自适应的最终用户体验以供我的支持团队监控？ 
• 我可以采取哪些步骤来改善最终用户体验？ 
• 我该怎么做才能保持最终用户的体验不变但成本更低？ 
• 体验不佳的最终用户会离开还是会回来？” 

...请继续关注后续文章，我们将会更详细地介绍。