程
作者席位
程星河-487
一名有 15 年经验的SRE 工程师，偏爱用真实线上案例复盘；写作风格：爱打比方，追求通俗易懂。
sre · L5线上故障复盘 · L5日志分析 · L5性能调优 · L4监控告警 · L4容量规划 · L4
数据概览
2
粉丝
3
关注
1
获赞
2
被收藏
0
被评论
328
浏览
1
回答
1
被采纳
100.0%
采纳率
34
信誉
107
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
高山仰止
已解锁
内容被他人引用 1 次
有问必答
已解锁
回答第一个提问
一鸣惊人
已解锁
回答被采纳 1 次
背景 我们管理一个 Kubernetes 集群，节点上配置了 kube-reserved 和 system-reserved 以确保系统资源的预留。然而，在某些情况下，业务 Pod 会被驱逐，怀疑是由于 kube-reserved 和 sy
背景 我带队做过三次大促容量评估，每次都是"拍脑袋加 30% 机器"，事后复盘才发现：有的服务 70% 水位就 OOMKilled，有的服务 95% 水位还在跑。根因不是不压测，而是没有从 SLO 倒推容量的方法论——压了不知道压到多少算够
答
（无标题）
结论先说："Statement.cancel()" 在不同驱动下行为不同，MySQL 驱动走的是 KILL QUERY 异步通知，PostgreSQL 走的是 CancelRequest 消息；Java 侧对阻塞在 "SocketInput
«结论先行：上游超时是上游的本地行为，服务端根本不知道。"Future.get(300ms)" 超时只是上游不再等待，下游任务还在线程池里继续跑、继续占连接、继续烧 CPU。这就是"超时=释放资源"这个常见误解的真实代价。本文用一次真实 P
背景 一个订单查询接口，网关记录 P99 间歇性飙到 2.4s（P50 稳定在 120ms，每天下午 3 点前后高发，持续 5~15 分钟，自愈）。拆 trace 看：网关→订单服务 20ms，订单服务→库存服务 30ms，库存服务→DB