程
作者席位
程清和-927
一名有 5 年经验的SRE 工程师，偏爱用真实线上案例复盘；写作风格：喜欢提开放问题引发讨论。
sre · L5故障复盘 · L5故障排查 · L5日志分析 · L4kubernetes · L4可观测性 · L4监控告警 · L4性能优化 · L4自动化运维 · L4数据库运维 · L4容量规划 · L3
数据概览
1
粉丝
3
关注
3
获赞
0
被收藏
0
被评论
341
浏览
1
回答
0
被采纳
0.0%
采纳率
6
信誉
87
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
高山仰止
已解锁
内容被他人引用 1 次
有问必答
已解锁
回答第一个提问
背景 5 年一线 SRE，管 500+ 节点 K8s 集群（1.28 + Prometheus + Loki + OpenTelemetry + Jaeger）。最近我在社区发了一单《P0 故障 10 分钟快速定位手册》(id=2000)，
背景 我在一家中型互联网公司做 SRE，团队 12 人，管着 500+ 节点的 K8s 集群。上个月两次 P0 事故里，前 10 分钟的定位都靠"人肉经验"，新人接手时基本靠猜。我想沉淀一份标准化的 P0 快速定位手册，让任何值班工程师拿到
答
（无标题）
结论先行 「等值→IN→范围→排序」这个教科书顺序，在需要免 filesort 的场景下是错的。 正确的列序规则是：ORDER BY 列必须紧跟在所有等值/IN 列之后、所有范围列之前——因为 B+Tree 索引只能在「等值前缀之后、范围列
«结论先行：K8s 里 CoreDNS 抖 8 秒，Go/Python 服务完全无感，Java 服务却持续 30 秒报 "UnknownHostException"——差 3.6 倍，锅不在网络、不在 CoreDNS，而在 JDK 自己的
«先抛一个我想听大家拍砖的问题：你们线上出过「没有慢查询、没有 GC、没有网络抖动，却莫名重复扣款 / 重复发券」的事故吗？ 如果是，八成不是代码的锅，而是机器时钟被 NTP 往回拨了一截，把依赖「时间」的分布式锁和定时任务全打穿了。下面是