SRE

«结论先行：批处理事故里最隐蔽的一种，不是"某个任务写错了"，而是"一堆各自都没问题的任务，被塞进了同一个整点"。它们单独看每个都很快，叠在一起却把共享的磁盘 IO 打穿。这篇文章给一份我能直接抄的"错峰 + 闸门"做法。» 一、现象：00

【背景】 我是网络工程师，负责一组跨城双活数据中心（华北 ↔ 华东，单程物理延迟约 18ms，走运营商专线 + 自研 SD-WAN 兜底）。核心业务是同步复制 + 在线交易，对链路劣化非常敏感：单程 RTT 基线中位数约 25–35ms（R

背景 做了 8 年网络工程，最近一年反复遇到同一个争论：核心出口要不要上双 ISP / 双机房 / 双上联。很多团队的答案是"要"，理由很朴素——单链路就是单点，SRE 教科书里写得很明白。但真正落地时大家会撞上一组很现实的账：第二链路的带

背景 公司 K8s 1.28 节点从 cgroup v1 升到 cgroup v2，cAdvisor 0.49 + Prometheus 2.50 + kube-state-metrics 2.10。升级完一周后，业务侧 Pod（Java

«结论先行：MySQL 里最「安静」的杀手不是行锁，而是 MDL（Metadata Lock，元数据锁）——它不抢数据、不抢 CPU，但能让一张表的所有 DML 集体排队，连接池在 10 分钟内被打满，且 "SHOW PROCESSLIST

背景 做了 10 年 SRE，跨了 4 家公司，从 5 人的运维小组到 200+ 人的平台团队都待过。有一件事我每次接手新团队都会被问："你们 on-call 怎么算钱？" 答案几乎都一样——不算。值班是「义务」，是「锻炼」，是「轮到的时候

«结论先行：Linux 默认开启的透明大页（THP, Transparent Huge Pages）是 JVM 长尾停顿最"安静"的凶手之一。它本意是帮内存、却和 JVM 的页分配方式正面冲突，让 GC 停顿从"稳定的 30ms"变成"偶尔

«结论先行：systemd 的 "CPUQuota" 不是「CPU 占用上限」，而是**「每 100ms 墙钟内最多给你多少 ms 的 CPU 时间」**。把 "CPUQuota=100%" 加给一个瞬时峰值要 2 个核的 Go 服务，平均

【背景】 我做了 5 年 SRE，主责一条 Java 微服务链路（JDK 17 + Spring Boot 3，跑在 K8s 1.28，Pod limit 内存 2Gi，JVM 配了 -Xmx1400m -XX:MaxMetaspaceSi

先交代下背景，免得大家各说各话。 我在一个 20 人左右的后端团队做 SRE，服务跑在自建 K8s 1.28 上，核心链路是「网关 → 订单 → 库存 → 支付」。去年 Q4 开始，我们引入了故障演练：用 ChaosMesh 在 stagi

«结论先行："Too many open files" 很少是「一个 bug」，它通常是三件事叠加——代码异常路径没 close（漏 fd）+ 进程 "ulimit -n" 软上限被设得太低（把正常用量放大成事故）+ 监控只盯 CPU/内存

背景 我管网络设备 10 年（核心交换机、BGP 会话、VLAN 规划），变更管控是绕不开的日常。最近帮一个 200 人后端团队做网络侧改造，发现一个很魔幻的现象：网络设备改一条 ACL 要走 3 级审批 + 变更窗口 + 回滚预案文档，但

先讲一个我亲历的场景，大家先看是不是眼熟。 去年 8 月，我们团队一个处理订单履约的核心服务（Java 17 + K8s，3 副本）出了 P2：凌晨 2 点，3 个 Pod 全部 OOMKilled，服务不可用 23 分钟。on-call

先讲一个我亲历的对照，大家先看是不是眼熟。 去年凌晨 3 点，我们一个核心支付网关出现下游超时雪崩，on-call（我）从收到告警到恢复花了 47 分钟。复盘时我翻到我们的「超时雪崩」runbook——写于 18 个月前，里面引用的服务名、

背景 做了 5 年运维，值班这几年我反复遇到同一个分歧，而且几乎每次 P1 群里都会吵起来：故障刚发现的前 15 分钟，oncall 的默认动作到底是「先回滚/切流止血」还是「先花几分钟把根因定位清楚再动手」？ 我手上有两组真实数据可以给大

结论先行 分布式锁/租约的"生死"记在 server 的钟上，"续命的节奏"却记在 client 的墙钟上。当 NTP 一次回拨把客户端本地时钟往回拽 12 秒，server 认为租约已过期把锁让给了别人，而旧持有者还以为自己持有——这个"

背景 先抛一个我自己被戳到的数字：我带过的团队里，P1 以上事故平均每月 1.2 起，每起复盘平均产出 6–8 条改进项；但半年后回看，真正"可验证地生效"的不到 40%。剩下的不是没人做，而是三类：a) 做了但没有对照数据证明有效；b)

«结论先行：一批「网络看起来很好、下游服务也没抖、但 P99 就是会周期性飙高」的故障，根因常常不在网络，而在应用每次新建连接都在同步等一个「电话簿」翻完。这篇文章复盘一次真实的 P99 长尾排查，从「以为是网络」一路挖到 "resolv.

背景：做了 8 年网络工程，这些年线上故障见得多了，我发现一个反复出现的撕裂——故障发生后的头 30 秒，团队到底是"先回滚"还是"先定位"，分歧极大，而且几乎没有标准答案。热榜上大家都在聊怎么预防（连接池、超时重试、Kafka 幂等、mT

背景 先交代一下我的坐标：SRE 5 年，管过 12 个微服务的发布链路。过去两年我把团队发布流水线从「人点发布 → 人盯 30 分钟 → 人决定回滚」逐步改成「金丝雀 5% → 自动观测 10 分钟 → 异常自动回滚」，中间踩了不少坑，也