SRE

«结论先行："terminationGracePeriodSeconds" 的计时器从 Kubelet 开始执行停机（含 preStop）那一刻就启动了，preStop sleep 不是"额外加"的缓冲，而是从总窗口里"扣"掉的。当你 pr

做运维 3 年，"混沌工程"这个词大概是我在团队周会上被提得最多、但真正落地次数为零的话题。每次有人拍桌子说"我们得搞混沌工程"，另一头就有人回一句"你先把告警误报治干净再来谈这个"。今天想把这个争论摊开，听听大家怎么算这笔账。 【背景：混

«结论先行：偶发拒连、CPU 不高、连接池没满、GC 日志看着也"正常"——这时候第一嫌疑往往是第三队，也就是 accept 队列（listen backlog）溢了。三次握手已经完成的连接，得等应用主动 "accept()" 才真正"进店

背景 做了 15 年运维，从 2012 年写 crontab 脚本自动拉起进程，到今天在 K8s 里配 liveness 探针 + 自动驱逐重启，"自愈"这个词我们喊了十几年。但每次事故复盘，绕不开一个问题：这条自愈链路，到底是救了我们，还

先抛一个我亲历的场景，大家先看是不是眼熟。 去年 Q3 我们一个核心服务出了 P1：一个缓存击穿导致下游 DB 被打满，恢复花了 42 分钟。复盘做得很「标准」：时间线、根因、影响面、改进项，四样齐全。改进项一共 6 条，其中 3 条是「加

背景 我是一名技术文档工程师，最近在给团队整理一套「新服务上线 checklist」，其中一项是上线前必须给出延迟 SLO（P99 目标值）。这件事看起来一句话就能写进文档，但真去调研各团队的实际做法，发现完全没共识，卡在这里。 现象 调研

【背景】 5 年网络工程经验，最近接手一个 K8s 集群（v1.26，80 节点、约 1200 Pod）的网络质量监控。痛点很明确：应用侧反复报"接口偶发超时"（P99 从 200ms 跳到 1.2s，持续 3~5s 后自愈），但现有被动监

背景 做了 3 年网络工程，日常和稳定性、可观测性打交道。最近一次经历让我很触动：一个核心链路的告警群，高峰期一天能刷出 200+ 条消息，真正需要人动手处理的不到 5 条。结果有一天凌晨一条真实的链路抖动告警被埋在一波资源类告警里，等了

【背景】 我们是一套 K8s 集群（ACK，1.27）+ Java 17 + Spring Boot 3 的服务，约 12 个副本，P99 目标 < 300ms，监控走 Prometheus + Grafana，链路用 SkyWalking

背景 先讲一个我亲历、且至今还会被翻出来的场景。 凌晨 2:47，一条 P0 告警把 on-call 的值班同学（一位入职 9 个月的后端）从床上叫醒：支付接口 5xx 率从 0.3% 飙到 12%，持续了 4 分钟。按团队 SOP，回滚需

«结论先行：这次 P99 毛刺的根因不是代码、不是 GC、不是连接池打满，而是中间那台 NAT/负载均衡在空闲 10 分钟后悄悄把连接表项丢了，两端却都以为连接还活着——下一次从池里取出这条"半开连接"发数据，首包被回 RST 或直接丢包，

【背景】 我们是 8 年线上经验团队，核心交易链路 Spring Boot 3 + JDK 17（ZGC，-Xmx8g）+ MySQL 8 + Redis 7，部署在 K8s（cgroup v2，cpu limit=4）。今年开始把 P99

背景 我们团队给核心交易链路定了 SLO：月度成功率 99.95%、P99 延迟 < 300ms。前两周一切正常，第三周开始错误预算肉眼可见地往下掉——到第 18 天已经烧掉 60%。按 Google SRE 那套「错误预算耗尽 → 冻结变

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