凌晨的告警
凌晨，客户投诉涌入：页面加载极慢，部分功能无响应。
你打开监控看板：CPU 正常、内存正常、磁盘正常、接口成功率 99.9%。
监控没问题，但业务明显不对。
为什么会出现这种情况
传统监控关注的是基础设施健康，而不是用户体验。以下这些问题，在传统监控里往往看不到：
- 线程池积压：慢请求占满线程，新请求排队，但成功率还是 99.9%
- 下游 API 超时：第三方服务变慢，但没有监控这个依赖
- 数据库连接池耗尽：连接数满了，但数据库 CPU 还是正常的
- GC 频繁但未超阈值：每次 GC 暂停 200ms，累积下来用户体验很差
- 特定功能响应退化：某个接口从 100ms 变成 2 秒，整体成功率不受影响
这些问题的共同特征：非致命、不报错、但持续损害用户体验。
小团队为什么更容易中招
- 监控设计跟着方便走，而不是跟着业务需求走
- 缺乏趋势分析，只看当前值，不看变化趋势
- 没有 7×24 响应机制，非工作时间出问题发现晚
有效监控需要回答的三个问题
1. 用户是否在经历慢？
监控 P95/P99 响应时间，而不只是平均值和成功率。
2. 关键路径是否在退化？
对核心业务流程（登录、下单、支付）单独监控，设置独立告警。
3. 出了问题有人能立即响应吗？
监控工具再好，没有响应机制也是摆设。
结论
稳定性不只是监控工具的问题，而是需要完整的机制和闭环反馈。
有效的监控体系应该能在用户感知到问题之前就发出告警——这需要从「资源视角」转向「用户体验视角」。