百科.dev
登录
> 返回资讯列表
news_article.exe
📰

我们的平均水平 隐藏在我们身边

What our averages were hiding from us

2026年9月3日1 次浏览来源:Dev.to 阅读原文

我们的潜伏仪表板 显示一个舒适的120米平均反应时间。 领导很喜欢这个数字。 同时,支持不断转发客户投诉,称该应用程序令人难以忍受地缓慢. 两者都说出真相,他们之间的差距在于教育他们如何平均说谎。 平均是一个单数,假想描述整个人口,它以多数为主. 如果95%的要求是快速的,5%需要8秒,那么平均几乎动不了——但5%是成千上万真正的人有一个悲惨的时间,他们往往是你价值最高的用户,是数据最多和查询最重的用户. 从字面上说,平均他们平均离开。 它是为了隐藏你最需要听到的人 我用百分位数代替平均数...

Our latency dashboard showed a comfortable 120ms average response time. Leadership loved that number. Support, meanwhile, kept forwarding complaints from customers saying the app was unbearably slow. Both were telling the truth, and the gap between them was an education in how averages lie. An average is a single number pretending to describe a whole population, and it's dominated by the majority. If 95% of requests are fast and 5% take eight seconds, the average barely moves — but that 5% is thousands of real people having a miserable time, and they're often your highest-value users, the ones with the most data and the heaviest queries. The average literally averages them away. It's designed to hide exactly the people you most need to hear about. I replaced the average with percentiles everywhere it mattered. The 50th tells you the typical experience. The 99th tells you the worst experience a meaningful number of people are actually having. When our p50 was 90ms and our p99 was 6 seconds, the shape of the problem finally became visible: most requests were fine, and a specific tail was catastrophic. The average had smeared those two facts into one meaningless middle. But percentiles alone weren't enough, because a p99 across all traffic is still an average of your worst cases. The real breakthrough was slicing. Latency by endpoint, by customer tier, by region, by whether the request hit a cold cache. The slow tail wasn't random — it was concentrated in one query pattern for customers above a certain data volume. You cannot see that in any aggregate. You have to be able to cut the data along the dimension that happens to matter, and you rarely know that dimension in advance. That's the difference between monitoring and observability, and it took me years to feel it in my gut. Monitoring is the dashboards you built for questions you already knew to ask. Observability is being able to ask a new question — "is it slow specifically for large customers in Europe on cold cache?" — after the incident starts, without shipping new code to find out. Stop reporting averages. Somewhere inside that comfortable number, your most important users are having your worst experience, and the average is designed to keep you from noticing. – Sergey Shinder

> 分享: