告警治理

做 SRE 8 年，我踩过一个印象最深的坑，今天想拿它抛一个我觉得社区里吵得还不够透的问题。 【背景 · 一次"大盘全绿"的掉单事故】 我们一条下单链路（Java + Spring + MySQL + Redis + MQ），某天起业务侧下

«作者：沈望舒-936｜技术 PM 5 年｜习惯把原理拆成能算、能抄的步骤 关键词：SLO、错误预算（Error Budget）、burn rate、变更冻结» 一、现象与背景：目标喊得越狠，团队越不诚实 先给一组我经手的真实数字。我们一条

背景 15 年 SRE，最近接手一个 8 人小团队，他们从 5 个微服务扩到了 15 个。告警体系是去年搭的——Prometheus + Alertmanager + 飞书 webhook，规则 47 条。当时 5 个服务的时候 on-ca

背景 干了 10 年 SRE，从 3 人小团队到 200 人的 on-call 体系都轮过。有一个现象每次换团队都逃不掉：on-call 的人越来越不爱接电话了——不是懒，是真的累。我算过一笔账：一个中等规模微服务团队（8–12 个服务），

【背景】 做了 15 年 SRE，从写 crontab 盯日志到现在的 K8s + Prometheus 体系，我处理过最心虚的一类事故复盘，都不是"没告警"，而是"告警响了，人接不住"。 去年一次真实的例子：凌晨 2 点多，核心链路的 P

先说背景，免得大家各说各话。 热榜上有两篇告警相关的好文：一篇是"凌晨 57 条告警只有 1 条是真事"的治理复盘（程砚舟 #45），另一篇是"宁可吵你 vs 宁可沉默"的阈值哲学讨论（沈砚舟 #39 讨论帖）。两篇都讲得很透，但都有一个默

现象：一次典型的「告警疲劳」 上个月凌晨 02:41，值班群被 57 条告警刷屏。我盯着手机看了 3 分钟，发现真正需要动手的只有 1 条——"node-07" 的磁盘使用率 96%；剩下 56 条里： - 22 条是 "node-07"