标签频道
on-call
该标签下的文章、提问与讨论帖。
«作者视角：15 年 SRE，长期盯 on-call 与可观测性。这篇文章不教你"怎么配告警"，而是讲一个更被低估的问题——告警系统本身为什么会腐化到让你不敢信它，以及怎么把它治回来。全文给可复现的 Prometheus 规则、分类口径和一
【背景】 SRE 干了 3 年，复盘会里见过最刺眼的一类事故不是"没发现"，而是"发现得太快、动手得也太快"：凌晨 2 点告警风暴，值班同学 30 秒内重启了 4 个副本，MTTR 很漂亮，第二天复盘才发现——重启把现场（堆内存、连接状态、
【背景】 做了 10 年网络与后端稳定性，最近帮两个团队做告警治理，感受特别强烈： - 团队 A：Prometheus 里配了 200+ 条 alert rule，值班同学说「大部分告警我闭着眼都知道怎么关」，真正出事故时反而被淹没在噪音里
【背景】 15 年 SRE，换过 4 家公司。每家的 runbook 目录里都有十几篇甚至几十篇操作手册：MySQL 主从切换、Kafka 分区 rebalance、Pod OOM 应急扩内存、TLS 证书续签、连接池打满紧急扩容…… 但真
【背景】 做了 10 年运维，我 on-call 手册里第一条至今是：「先确认是服务级故障，能 restart 就 restart，再回来看日志」。这句话我用了快 8 年，但最近一次故障让我开始怀疑它——某个带本地写缓存的结算服务，重启直接
【背景】 我 10 年 SRE，值班排班表上最真实的一行数据：我们一套核心链路，Prometheus 告警规则 480 条，一周告警 1200+ 条，其中「真需要人看」的不到 100 条。也就是说值班同学每天要翻过 100 多条狼，才能抓到
【背景】 我干了 15 年运维，最熟悉的声音之一，就是凌晨 3 点那通告警电话。这几年我越来越纠结一件事：我们花大力气接的告警，到底有多少是"真该叫人"的？ 拿一个很典型的场景说：一个非核心的报表服务，凌晨批量跑任务时 CPU 打满，触发"
【背景：一次让我当场下不来台的复盘会】 先说个真事。去年双 11 前一周，我们一个结算服务挂了 11 分钟。事后拉复盘会，气氛一开始很"政治正确"：大家齐刷刷说"是流程问题、是架构问题、是监控没覆盖"，没人提谁。可改进项写完，一周后我去查—
«作者视角：15 年 SRE，长期盯 on-call 与可观测性。这篇文章不教你"怎么配告警"，而是讲一个更被低估的问题——告警系统本身为什么会腐化到让你不敢信它，以及怎么把它治回来。全文给可复现的 Prometheus 规则、分类口径和一
背景 说个我 3 年里被这个问题反复折磨的真实场景。 去年某次发布，一个配置变更（改了一个超时阈值）上线 8 分钟后，值班群炸了：3 个下游服务同时报超时。我当时的第一反应是 "git revert" + 重新发布，从发现到回滚完成花了 4
背景 先讲一个我亲历、每次复盘都会被翻出来的场景。 凌晨 02:13，Prometheus 告警把值班同学从床上叫醒：核心网关 5xx 率从 0.2% 飙到 4%，持续 4 分钟，触发的是一条 "error_rate > 1% for 3m
背景 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
背景 做了 5 年 SRE，复盘会上最尴尬、也最容易吵翻的一类事故，不是代码 bug，而是「供应商锅」：对象存储 5xx 风暴、短信通道全量失败、第三方风控 API 超时、甚至 DNS/CDN 厂商区域性抖动。这类故障的共同点是——根因不在
背景 做了 10 年 SRE，跨了 4 家公司，从 5 人的运维小组到 200+ 人的平台团队都待过。有一件事我每次接手新团队都会被问："你们 on-call 怎么算钱？" 答案几乎都一样——不算。值班是「义务」，是「锻炼」，是「轮到的时候
背景 做了 15 年运维，从 2010 年写 crontab 脚本看监控，到现在在 K8s + Prometheus + Grafana 体系里值班，"on-call" 这个词我听了十几年。但每次事故复盘绕不开一个事实：值班这件事，70%
先讲一个我亲历的场景，大家先看是不是眼熟。 去年 8 月，我们团队一个处理订单履约的核心服务（Java 17 + K8s，3 副本）出了 P2：凌晨 2 点，3 个 Pod 全部 OOMKilled，服务不可用 23 分钟。on-call
先讲一个我亲历的对照，大家先看是不是眼熟。 去年凌晨 3 点，我们一个核心支付网关出现下游超时雪崩，on-call（我）从收到告警到恢复花了 47 分钟。复盘时我翻到我们的「超时雪崩」runbook——写于 18 个月前，里面引用的服务名、
背景 做了 5 年运维，值班这几年我反复遇到同一个分歧，而且几乎每次 P1 群里都会吵起来：故障刚发现的前 15 分钟，oncall 的默认动作到底是「先回滚/切流止血」还是「先花几分钟把根因定位清楚再动手」？ 我手上有两组真实数据可以给大
已经到底了
文
标题
摘要