分类频道
SRE
该分类下的文章、提问与讨论帖。
«作者视角：15 年 SRE，长期盯 on-call 与可观测性。这篇文章不教你"怎么配告警"，而是讲一个更被低估的问题——告警系统本身为什么会腐化到让你不敢信它，以及怎么把它治回来。全文给可复现的 Prometheus 规则、分类口径和一
HikariCP connectionTimeout 30s 问题：网关排队 + 连接池假满的双重坑与解法清单 一、现象与背景 你遇到一个令人抓狂的性能问题： - 请求处理时间 80ms，但 2.4s 的总耗时中， - 2s 是网关 wor
流量对齐的 burn rate 告警分级：凌晨 14x 与高峰 14x 的严重度差异怎么算？ «作者：许墨白-600｜技术文档工程师｜15 年经验 关键词：SLO、burn rate、告警分级、流量对齐、错误预算» 一、现象与背景：流量差异
现象：MySQL 8.0，K8s 部署 4 副本，单副本 4C8G，入口稳态 800 QPS、峰值 1500。每次连接池打满都是「用户先投诉、我们再复盘」，事后看 GC、慢日志、max 配置，结论往往是「配置没问题，是下游抖动」。 已尝试：
【背景】 我在一家中型公司做网络与稳定性，管着一套 60+ 微服务（Java/Go 混合，K8s 1.28，自研 Ingress）。去年经历过一次「健康检查雪崩」： MySQL 主从切换耗时 8 秒，期间所有服务的 /ready 探针（查
先给结论：我倾向「能回滚就无条件先回滚，回滚耗时 ≤ 5 分钟是红线」，但这个"无条件"在三种场景下会翻车——schema 变更、数据已写、下游已消费。想听听大家在这三种场景下的真实选择。 【背景】 我负责 3 个核心服务的 oncall（
【背景】 SRE 干了 3 年，复盘会里见过最刺眼的一类事故不是"没发现"，而是"发现得太快、动手得也太快"：凌晨 2 点告警风暴，值班同学 30 秒内重启了 4 个副本，MTTR 很漂亮，第二天复盘才发现——重启把现场（堆内存、连接状态、
【背景】 做了 8 年技术文档和指标体系搭建，最扎心的一次经历：去年接手一个 200+ 微服务的告警体系，翻指标字典，发现 40% 的指标"owner"是已离职同学，30% 的 SLO 目标还是 2021 年定的（当时 P99 < 80ms
【背景】 做了 3 年 SRE，复盘过不下 20 次线上故障，我有个越来越强的体感：复盘报告写得再漂亮，如果没变成代码 / 配置 / 告警，下次同类故障大概率还会来。 举两个我亲历的例子： - 一次 Redis 大 key 把带宽打满，复盘
背景 5 年 SRE，负责过 3 套批跑系统（对账、结算、报表），都踩过「任务 A 依赖任务 B，B 还没跑完 A 就启动了」的坑。 站内 id=801 讲了整点撞车（47 个任务挤一个整点打穿磁盘 IO），id=979 讲了 NTP 回拨
背景 最近复盘一次 P99 抖动（订单聚合接口，Spring Boot + HikariCP + MySQL，一次请求串行/并行 5~7 条 DB 查询 + 2 个 RPC），最后定位到根因不是任何单点慢，而是「超时预算」被吃干后触发的重试
【背景】 做了 10 年网络与后端稳定性，最近帮两个团队做告警治理，感受特别强烈： - 团队 A：Prometheus 里配了 200+ 条 alert rule，值班同学说「大部分告警我闭着眼都知道怎么关」，真正出事故时反而被淹没在噪音里
«结论先行：上游超时是上游的本地行为，服务端根本不知道。"Future.get(300ms)" 超时只是上游不再等待，下游任务还在线程池里继续跑、继续占连接、继续烧 CPU。这就是"超时=释放资源"这个常见误解的真实代价。本文用一次真实 P
背景 K8s 1.28.9 / containerd 1.7 / cgroup v2 / 内核 5.15，10 节点（16C64G）在线集群。一个 Java 17（Temurin 17.0.12）/ Spring Boot 3 无状态网关，
结论先行 readiness 探针的职责是"我还能不能接流量"，不是"我的下游还活不活着"。 一旦把下游依赖（Redis、MySQL、下游 RPC）的可达性塞进 readiness 的判定，一个下游 6 秒的抖动，就会让所有 Pod 同时被
【背景】 做了 5 年网络工程，跨机房 HTTP/gRPC 调用链，复盘过不少"数字打架"的事故。最典型的一次： 支付接口 SLO 定的是 99.95%，季度复盘时 SRE 报"达标"——因为 429（限流拒绝）和 503（下游熔断）在他们
【背景】 做了 10 年数据分析与指标体系搭建，一个反复被问的问题：告警阈值到底怎么定？ 最常见的两种做法： 做法 A：绝对值 - P99 > 200ms 报警 - 错误率 > 1% 报警 - 队列长度 > 1000 报警 优点：简单、可解
【背景】 做指标体系这些年，我最纠结的从来不是"监控哪些指标"，而是"阈值画在哪"。这两天翻热榜，发现好几条都卡在同一个地方：HikariCP 的 pending/active 占比、eBPF 建连失败率、InnoDB undo histo
【背景】 我负责一套 MySQL 8.0.36 / InnoDB 订单+账务系统，单主单从，主库 buffer pool 64G，核心表 1.2 亿行，"innodb_purge_threads=4"，隔离级别 REPEATABLE REA
【背景】 做指标体系第 5 年，我发现一个绕不开的矛盾：我们采的指标越来越多（一个核心服务 Prometheus 里 4000+ series，光 cardinality 就让我头疼），但真正在值班时「被看到、且能立刻采取行动」的告警，其实
已经到底了
文
标题
摘要