为什么“99.9% uptime”并不意味着你的用户没问题

Source: Dev.to

多年来，正常运行时间（uptime）一直被视为可靠性的终极信号。

如果仪表盘显示 99.9% 正常运行时间，一切就应该没问题。
服务器有响应。检查显示为绿色。警报保持沉默。

然而，用户仍在抱怨。

• 页面可以加载，但渲染不正确。
• 关键操作失败。
• 性能不稳定，取决于用户所在的地区。

从监控的角度来看，一切都显示“正常”。
从用户的角度来看，产品感觉已经坏掉。

这种脱节比大多数团队意识到的更常见。

正常运行时间是基础设施指标

正常运行时间回答了一个非常具体的问题：

服务器是否对请求作出响应？

仅此而已。

它并不能告诉你：

• 页面是否真的渲染成功
• 关键用户流程是否可用
• 体验是否可用
• 不同地区的用户是否看到相同的内容

正常运行时间是必要的，但它仅是一个 基线。
把它当作用户体验的代理指标，就是问题的起点。

当一切“正常”但实际上没有任何工作时

许多真实的事故并不会表现为停机：

• 前端部署引入了 JavaScript 错误
• API 有响应，但返回了错误的数据
• 结账页面加载成功，却静默失败
• CSS 问题导致特定设备布局错乱
• 功能标记（feature‑flag）配置错误，仅影响部分受众

从外部看，站点是可访问的。
从内部看，仪表盘保持绿色。
从用户的视角，产品不可用。

区域盲点

另一个常见的失效模式是 区域可用性。

一个站点可能：

• 在某个国家完全可访问
• 在另一个国家则慢或根本不可达

CDN、DNS 解析、路由路径以及 ISP 都在这里发挥作用。
集中式监控往往只从有限的地点进行检查。
如果这些地点都健康，问题就会保持不可见。

“我复现不出来。”

而用户仍在遭遇问题。

为什么团队在沟通事故时会遇到困难

当可用性问题不明确时，沟通也会崩溃。团队往往退回到：

• 回复单个支持工单
• 在聊天工具中发布更新
• 发送临时邮件
• 一遍遍回答 “它挂了吗？”

没有单一的真相来源。用户不知道该去哪里查。
支持负载正好在团队已经压力山大的时候增加。

问题不仅仅是技术层面的，而是 共享认知 的缺失。

真正有帮助的做法

处理事故得当的团队往往遵循以下原则：

• 从 可用性 而非仅仅是正常运行时间的角度思考
• 从 用户的视角 看待系统
• 验证从外部环境的可达性
• 检测面向用户的故障，而不仅是服务器响应
• 清晰且一致地进行沟通

监控不再是单纯收集指标，而是 降低不确定性。

快速检查仍然重要

有时，团队并不需要完整的仪表盘或历史数据。
他们只需要对一个简单问题得到快速答案：

站点现在对用户是否可达？

一次快速的外部检查可以帮助：

• 确认或排除可用性问题
• 验证用户报告
• 决定是否需要更深入的调查

能够从外部检查可达性的工具之所以有价值，正是因为它们跳出了内部网络、缓存 DNS 和已有会话的限制。

可用性才是最终目标

正常运行时间应被视为 基线，而不是成功指标。
用户关心的是他们是否能够：

• 访问产品
• 按预期使用它
• 完成他们来此的目的

当团队把思维从正常运行时间转向可用性时，他们会更早发现问题、沟通更顺畅，并且能够更有信心地做出决策。

绿色的仪表盘固然让人安心，但真正了解用户的实际体验价值更大。