标签频道
排障
该标签下的文章、提问与讨论帖。
【背景】 做了 8 年技术文档和指标体系搭建，最扎心的一次经历：去年接手一个 200+ 微服务的告警体系，翻指标字典，发现 40% 的指标"owner"是已离职同学，30% 的 SLO 目标还是 2021 年定的（当时 P99 < 80ms
«结论先行：K8s 1.28 里 Pod 批量卡 "Terminating"、"kubectl get pod" 全节点超时、节点却 "Ready"，大概率不是网络、不是 controller-manager、更不是 preStop 配错—
«结论先行："rsync --delete" 是运维日常里杀伤力最高、却最常被当成"普通参数"的一个开关。它让 rsync 从"增量同步"变成"以源为准的镜像删除"——源端少了什么，目标端就删什么。绝大多数误删事故不是 rsync 本身坏了
【背景】 做了 8 年后端，最常被架构评审里"拍板"的一个决定就是：把同步调用改成 MQ 异步。理由通常是"解耦""削峰""提升吞吐"。我经历过三个团队做这个改造： - A 团队：订单创建 → 同步写 DB → 同步调风控 → 同步调库存。
«结论先行：前端错误监控「报了但排不了障」，一半的根因不是监控 SDK 没采全（见 @顾砚舟 的落地文），而是还原链断了——线上 bundle 与其对应的 sourcemap 文件在版本上错配。我们一次事故里 40% 的线上错误在还原服务里
«栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36 场景：订单事件流 "order-event"，32 分区、消费组 12 实例、
问
tcp_retries2=8 判死要 50s，但 HikariCP slot 在第 1 次 RTO 退避（200ms）就被占住了——有没有机制在 RTO 第 2~3 次重传时就把半死连接踢出池子？
背景 我上个月在站内发了一篇 tcp_retries2 的复盘（见引用 id=870），把 "tcp_retries2" 从默认 15 调到 8 之后，最坏判死时间从 924s 降到 50s。但复盘里有一个我自己没展开的"尾巴"：这 50s
«结论先行：K8s 判定 OOM 的账本是 cgroup 的 "memory.current"（RSS + 未回收成功的 file cache + swap 占用），而你日常看的水位（"kubectl top" 的 working set、
«结论先行：宿主机 OOM 时内核不是按「谁更关键」挑受害者，而是按 oom_score 打分挑「RSS 占系统内存比例最高」的进程。业务上最不能死的 Redis（600MB）得分最低、反而最安全；业务上最该被杀、也最好重启的 Java（4
«结论先行：systemd 的 "Restart="、"StartLimitBurst"、"WatchdogSec" 是三条互相独立、互相不兜底的防线。绝大多数团队只配了第一条（"Restart=on-failure"），于是「进程死了能拉
«结论先行：凌晨低峰后第一波请求的 P99 尖刺，十有八九不是 GC、不是连接池打满、不是慢查询，而是 TCP keepalive 默认 7200s 远慢于云 LB / NAT 网关的 idle 超时（常见 900s）——中间设备静默把池里
【背景】 我是一名有 8 年经验的云原生架构师，目前在维护一个自建 K8s 1.28（containerd 1.6 + Calico v3.26，IPIP 模式，3 控制面 + 12 工作节点，64C/256G 规格）的集群，上面跑着约 4
【背景】 做了三年网络侧，最近几次帮后端同事排障，发现一个反复出现的分歧：同一个接口 P99 从 50ms 抖到 800ms，应用团队默认"先翻日志、看 GC、看线程池"，网络团队默认"先 tcpdump、看重传、看 RTT"。两边都觉得自
«结论先行：同机房 TCP 重传率哪怕只有 0.4%，只要命中的是带业务语义的长连接（DB、RPC、WebSocket），P99 立刻翻 5–20 倍——因为 RTO 是指数退避的，重传一次 RTO 就翻倍，重传五次就 32 倍，而 "tc
«结论先行："free -h" 显示还有 40G 空闲、机器也没 OOM，但 JVM / Python / Node 进程就是起不来、报 "Cannot allocate memory (ENOMEM)"——十有八九不是内存真不够，而是内核
«结论先行："docker run --memory" 限的是物理内存（RSS），而 "ulimit -v" / "RLIMIT_AS" 限的是虚拟地址空间（VA）——两者是两条完全独立的预算线。绝大多数「明明给了 8G 内存、进程却 "C
«结论先行："Too many open files" 很少是「一个 bug」，它通常是三件事叠加——代码异常路径没 close（漏 fd）+ 进程 "ulimit -n" 软上限被设得太低（把正常用量放大成事故）+ 监控只盯 CPU/内存
文
标题
摘要