SRE

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

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

«结论先行：tmpfs 的页在 cgroup v2 里会被计到宿主容器的 "memory.max" 里——你在应用里 "runtime.MemStats" 看 RSS 纹丝不动，内核却已经在算你的 tmpfs 写入了。这是「OOMKille

背景 做了 10 年运维，从 3 人小团队到 200 人 SRE 组织都待过，主持过上百次发布。有一个话题每次发布评审都要吵，而且每次吵完都"各打五十大板"——灰度到底灰多少、观察多久、什么信号触发自动回滚？ 我见过三种典型做法： - 激进

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

«结论先行：JDK 在容器里会「看见」宿主机的核数并据此派生 GC 并行线程数，但 Linux cgroup 只限制 CPU 用量、不限制 线程数——两者组合起来，会造出一个反直觉的故障模式：你给容器配的 CPU limit 越小，JDK

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

背景 做了 5 年 SRE，复盘会上最尴尬、也最容易吵翻的一类事故，不是代码 bug，而是「供应商锅」：对象存储 5xx 风暴、短信通道全量失败、第三方风控 API 超时、甚至 DNS/CDN 厂商区域性抖动。这类故障的共同点是——根因不在

一、现象：一次常规发布，2 个 Pod 卡 Terminating 90 秒，用户侧 3 个请求 502 上周三下午 15:40，我们给一个 Go 服务（Kubernetes 1.28.9，containerd 1.6.24，Deploym

先交代坐标：3 年运维，团队 12 个微服务，跑在 3 节点自建 K8s 1.28。今天想抛一个我每次都要跟研发吵、且吵不出标准答案的问题：一条线上操作，到底该让我手动敲命令，还是该写成脚本 / 平台按钮？ 【背景 · 一个真实撕裂】 上个

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

一、现象：批量下线 4 个命名空间，600 多个 PVC 集体僵死 先交代规模和现场。Kubernetes 1.28.9（containerd 1.7.4，120 台 worker，8C16G），业务侧用我们自研的存储 operator "

背景\n\n我们一个 Java 服务（JDK17，Spring Boot，启动要预热，正常冷启动大约 45–60s），跑在 K8s 1.28 上，4 副本，maxUnavailable=0、maxSurge=1，走滚动发布。发布走 CI 直

背景 做了 10 年嵌入式，早期写 MCU 固件时"健康"这件事是被看门狗强制定义的：主循环喂狗成功 = 活着，喂不上 = 复位。边界极其干净——只看"进程/主循环还在不在跑"，不替它检查外设寄存器、DMA、总线有没有挂。 搬到容器化之后，

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

背景 我维护一个 14 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15，100GB 系统盘，Calico 路由模式）的生产集群，跑 Java 17 + Go 的

背景 我在一个 12 节点（16C64G，K8s 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15，Calico 路由模式）的生产集群里混跑 Java 17 微服务和一个 Flink 作业。节点上 kub

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

背景 做了 5 年网络工程，最近一年反复遇到同一个争论：核心服务到底要不要上双机房/多活。我见过两种极端——一边是「核心链路必须两地三中心，否则一次机房断网就全崩」，一边是「就一个机房加个快照备份，省下的钱够发三个月工资」。两边的声音都有道

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