【示例】CoreDNS 解析超时导致下游服务 5xx

这是一篇示例文章，用来展示复盘的写法和页面排版。请替换成你亲身经历的事故，面试时才讲得出细节。

摘要

订单服务在流量高峰期出现约 3% 的 5xx，持续 47 分钟。根因是 Pod 内并发 A / AAAA 查询触发 conntrack 插入竞争，部分 UDP 包被丢弃，DNS 查询要等满 5 秒超时后重试。

影响

时间线

• 20:03 Grafana 告警：order-api 错误率燃烧率超过 14.4×（1h 窗口）
• 20:09 值班人确认，查看链路追踪，发现慢请求都卡在 DNS 解析
• 20:21 临时措施：在 Pod 中设置 options single-request-reopen，错误率下降
• 20:50 错误率恢复到基线以下，事故关闭

根因

$ conntrack -S | grep insert_failed
cpu=0   found=0 invalid=412 insert_failed=1873 drop=1873

glibc 在同一个 socket 上并发发送 A 和 AAAA 查询，两个包在 DNAT 时竞争同一条 conntrack 记录，后到的包被丢弃。

改进项

1. 部署 NodeLocal DNSCache，Pod 走节点本地缓存，绕开 DNAT
2. 为 insert_failed 增加 Prometheus 告警
3. 在 Helm chart 里统一 dnsConfig

学到了什么

监控不仅要看应用层的错误率，内核层面的丢包计数同样关键。