你是否经历过这样的时刻：
手机在凌晨3点疯狂震动，你迷迷糊糊抓起手机，发现是Prometheus发来的第50条报警——“某测试环境磁盘使用率超过80%"。你愤怒地关掉报警，心里骂了一句，翻身想继续睡，却怎么也睡不着了。
第二天到了公司，面对邮箱里躺着的几百封"Warning"邮件，你甚至懒得点开，直接全选标记已读。直到下午，客服突然冲进研发区喊：“支付接口挂了半小时了，怎么没人处理？！”
那一刻，背脊发凉。
我也曾深陷这种泥潭。在只有5个后端的初创期，我试图掌控一切，给所有服务器装满了探针，恨不得监控每一行代码的CPU消耗。结果是，由于报警噪音太大，我们集体患上了"狼来了"后的报警麻痹症，反而漏掉了真正致命的故障。
监控不是为了证明我们工作努力，而是为了让我们睡个好觉。今天，我想以过来人的身份，聊聊如何在资源有限的小团队，做一套真正有用的监控体系。
别让"全量监控"毁了你的注意力
很多技术负责人刚搭建监控时，容易陷入一种误区：指标越多越安全。
我曾经的同事阿强就是典型。两年前，他负责搭建我们第一套Grafana面板。他非常负责，把Node Exporter里的几百个指标全配了报警。内存缓存占用高了要报，CPU瞬时抖动要报，就连某个不重要的日志文件变大也要报。
结果呢？那是一个黑色的星期五。
我们的核心业务数据库出现死锁，业务全线卡顿。但当时大家的钉钉群正被"Web服务器CPU使用率 > 60%“的消息刷屏（那是正常的促销流量波动）。真正的数据库连接数报警被淹没在几百条无关痛痒的消息里。
故障复盘时，我们痛定思痛：如果一个报警触发后，不需要人工立刻介入处理，那它就不应该被定义为"报警”，而应该只是"数据展示"或"日报”。
对于小团队而言，资源是宝贵的，注意力更是稀缺资源。
建议你现在就做一个动作：审计你现有的报警规则。 问自己两个问题：
- 这条报警半夜响了，我需要马上起床修吗？
- 如果不修，天亮前公司会破产或流失客户吗？
如果答案是"否"，请果断关掉它的通知，或者将其降级为工作时间的工单。
忘记CPU，聚焦RED方法论
既然不能监控所有东西，那什么才是"核心指标"？
在很长一段时间里，我只盯着机器的基础资源：CPU、内存、磁盘IO。我认为只要机器不挂，服务就是好的。
但这又是一个大坑。
有一次，我们的搜索服务挂了，用户搜不到任何商品。我火急火燎地连上服务器，发现CPU占用率极低，内存也很空闲。看监控面板，一片祥和的绿色。
原因竟然是一个第三方分词服务的API超时了，导致我们的线程全部阻塞在等待响应上。机器资源没跑满，但业务已经死了。
从那以后，我强制团队转型，不再盯着"机器怎么样"，而是关注"服务怎么样"。这里强烈推荐 Google SRE 提倡的 RED 方法论，特别适合微服务或Web应用：
- Rate (请求速率)：每秒有多少请求？流量是否突然归零或暴涨？
- Errors (错误率)：有多少请求失败了？（这是最直观的健康指标）
- Duration (响应时间)：处理请求需要多久？
对于小团队，哪怕你没有复杂的APM工具，哪怕只是在Nginx日志里统计这三个指标，也比盯着CPU图表有用得多。
例如，一个简单的 Prometheus 报警规则，应该直接反映用户体验：
# 报警：过去5分钟内，API错误率超过1%
- alert: HighErrorRate
expr: rate(http_requests_total{status=~"5.."}[5m])
/ rate(http_requests_total[5m]) > 0.01
for: 2m
labels:
severity: critical
annotations:
summary: "服务 错误率过高"
这种报警一旦响了，一定是真出事了，必须立刻处理。
警惕"平均值"的谎言
即使聚焦了核心指标，查看数据的方式也可能欺骗你。
我以前有个习惯，每周五下午会花半小时巡检所有服务的延时情况。我看着仪表盘上显示的"平均响应时间：200ms"，心里美滋滋的，觉得系统性能稳如老狗。
直到有一天，老板转给我一个VIP客户的投诉截图，视频里页面加载转圈转了整整5秒。
我拿着日志去对账，发现那个时间段的平均延时确实是200ms。但是，绝大多数请求是几十毫秒的缓存读取，而包含了复杂计算的请求（就像那位VIP客户的操作）却高达几秒钟。平均值把这些"长尾"的慢请求给由于稀释掉了。
在小团队资源不足，没法做全链路追踪的时候，请务必关注 P95 或 P99 延时（即95%或99%的请求都快于这个数值）。
如果你的 P50（中位数）是 100ms，但 P99 是 3s，说明你有 1% 的用户正在遭受极差的体验。对于一个小团队，这 1% 往往就是最容易流失的高价值用户。
现在的我，在仪表盘上会刻意弱化"平均值"的展示，把 P99 延时放在最显眼的位置。这不仅是技术指标的调整，更是团队对"用户体验底线"的坚守。
总结：给监控做减法，给生活做加法
监控系统的建设，本质上是团队技术价值观的体现。
当我们不再追求大而全的仪表盘，不再以报警数量衡量运维工作量，而是聚焦于"用户是否能正常使用核心功能"时，我们才算真正入门了。
对于正在从0到1搭建运维体系的你，我有这3个可落地的行动建议：
- 大清洗：本周内，将所有非生产环境（测试/开发）的实时电话/短信报警全部关闭，只保留IM群通知。生产环境只保留"服务不可用"和"资源即将耗尽"两类报警。
- 黄金信号板：只搭建一个大盘，上面只放核心业务（如登录、下单、支付）的 RED 指标（速率、错误、延时）。这是给老板和所有人看的"生命线"。
- On-call 轮值：哪怕团队只有3个人，也要建立轮值机制。不要让一个人永远待机。只有轮流背锅，大家才会更有动力去优化那些恼人的误报。
最后，想做一个小调查：
在你的团队里，哪种情况最让你抓狂？ A. 报警响了一晚上，全是误报。 B. 报警一声没响，客户打爆了电话投诉服务挂了。
欢迎在评论区告诉我你的经历，也许你的吐槽，能治愈另一个焦虑的灵魂。