交付说明

交付物为《P0 故障 10 分钟快速定位手册》全文，Markdown 格式，UTF-8 编码，覆盖 5 类高频故障场景，每类含决策树 + 可复现 bash 命令 + 期望/异常输出判定标准，末尾附 5 分钟升级路径表。全文约 3200 字，代码块均 bash 高亮，无模糊表述，无真实公司名/IP/域名。以下为完整交付内容——

P0 故障 10 分钟快速定位手册

适用环境：K8s 1.28+ / Prometheus / Grafana / Loki / OpenTelemetry / bash 4+ 目标：值班工程师按本手册操作，10 分钟内完成 P0 故障根因定位 使用方式：先做「0 号动作」锁定症状分类，再进入对应场景按决策树逐步执行

0 号动作：60 秒锁定症状分类

# 0-1: 全局健康概览（一条命令看集群是否有大面积异常）
kubectl get nodes -o wide | awk '{print $1, $2, $4, $5}'
# 期望输出：所有节点 STATUS=Ready，RESTARTS 字段为 0 或个位数
# 异常判定：≥3 个节点 NotReady → 跳场景五（疑似宿主机级故障）；
#           单节点 NotReady → 跳场景三/四（宿主机资源或网络）

# 0-2: 最近 5 分钟全局错误率（Prometheus，需 promtool 或 curl）
curl -s 'http://prometheus:9090/api/v1/query' \
  -d 'query=sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))' \
  | jq '.data.result[0].value[1]'
# 期望输出：< 0.01（错误率 < 1%）
# 异常判定：≥ 0.05 → 跳场景二（API 延迟/错误）；≥ 0.5 → 跳场景五（OOM 级联）

# 0-3: 最近 5 分钟集群级 CPU / 内存 / 网络快速扫描
curl -s 'http://prometheus:9090/api/v1/query' \
  -d 'query=avg(rate(container_cpu_usage_seconds_total[5m])) by (pod)' \
  | jq '.data.result[0]'
curl -s 'http://prometheus:9090/api/v1/query' \
  -d 'query=avg(container_memory_working_set_bytes) by (node)' \
  | jq '.data.result[0]'
# 期望输出：单 Pod CPU < 0.8 核（4C 实例 < 20%）；单节点内存 < 85% limit
# 异常判定：任一 Pod CPU > 0.95 × limit → 场景二；任一节点内存 > 95% → 场景五

决策树：

• 大面积 Node NotReady → 场景五
• 错误率 ≥ 5% 且延迟未飙 → 场景二
• 单节点/单 Pod 资源打满 → 场景三/四/五（按资源类型）
• 网络重传率 > 1% → 场景四
• Pod 状态 CrashLoopBackOff / ImagePullBackOff → 场景一

场景一：Pod 反复 CrashLoopBackOff

典型症状：kubectl get pods 显示 CrashLoopBackOff，RESTARTS 计数持续增长（> 5 次/10 min）

1-1 查看崩溃日志（最后 200 行 + 上一次崩溃前 50 行）

POD=<pod-name>
NS=<namespace>
kubectl logs $POD -n $NS --tail=200 --previous 2>&1 | tail -250
# 期望输出：正常日志，无 FATAL / panic / OOMKilled 关键字
# 异常判定：
#   - 出现 "OOMKilled" 或 "Killed" → 跳场景五
#   - 出现 "connection refused" / "dial tcp" → 跳场景四
#   - 出现 "panic:" + goroutine dump → 应用代码异常，查最近 commit

1-2 查看 K8s 事件（最近 30 分钟）

kubectl get events -n $NS --sort-by=.lastTimestamp \
  --field-selector involvedObject.name=$POD,type=Warning \
  -o custom-columns=TIME:.lastTimestamp,REASON:.reason,MSG:.message \
  | head -10
# 期望输出：无 Warning 事件，或仅 "Back-off" 重复
# 异常判定：
#   - "FailedScheduling" → 节点资源不足，查节点 allocatable
#   - "FailedMount" → 存储卷异常，跳场景三
#   - "Liveness probe failed" → 应用未就绪或资源不足

1-3 检查容器资源限制是否被 OOM 杀死

kubectl get pod $POD -n $NS -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}'
echo ""
kubectl get pod $POD -n $NS -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'
echo ""
# 期望输出：reason=Completed 或不存在（非异常退出）；exitCode=0
# 异常判定：reason=OOMKilled → 确认内存 limit 不足，查 1-4；exitCode=137 → 被 SIGKILL

1-4 核对内存 limit 与实际用量

# 当前 limit
kubectl get pod $POD -n $NS -o jsonpath='{.spec.containers[0].resources.limits.memory}'
echo ""
# 崩溃前峰值（需 Prometheus 有 container_memory_working_set_bytes）
curl -s 'http://prometheus:9090/api/v1/query_range' \
  -d "query=max(container_memory_working_set_bytes{pod=\"$POD\"})" \
  -d "start=$(date -d '30 min ago' +%s)" \
  -d "end=$(date +%s)" \
  -d "step=15s" \
  | jq '[.data.result[0].values[][1] | tonumber] | max'
# 期望输出：峰值 < limit × 0.85
# 异常判定：峰值 ≥ limit × 0.95 → 内存 limit 设置过低，需调大或排查内存泄漏

1-5 检查镜像拉取与启动命令

kubectl get pod $POD -n $NS -o jsonpath='{.spec.containers[0].image}'
echo ""
kubectl describe pod $POD -n $NS | grep -A5 "State:" | head -10
# 期望输出：image 为有效 tag（非 :latest 漂移）；State=Running 或 Waiting reason=PodInitializing
# 异常判定：reason=ErrImagePull → 镜像仓库不可达；reason=CrashLoopBackOff → 应用启动即崩溃

场景二：API P99 延迟突增

典型症状：Grafana 面板 P99 从 < 100ms 飙到 > 500ms，持续 > 2 min，错误率可能同步上升

2-1 定位慢请求集中在哪个服务/接口

# 按服务 + 接口维度取 P99（OpenTelemetry / Prometheus）
curl -s 'http://prometheus:9090/api/v1/query' \
  -d 'query=topk(5, histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service, endpoint)))' \
  | jq '.data.result[] | {service: .metric.service, endpoint: .metric.endpoint, p99: .value[1]}'
# 期望输出：所有 service p99 < 200ms
# 异常判定：某 service p99 > 500ms → 锁定该 service，继续 2-2；
#           多 service 同时飙 → 疑似共享依赖（DB/Redis）问题，跳场景三/四

2-2 检查下游依赖延迟（DB / Redis / 外部 HTTP）

# MySQL 慢查询（最近 5 min）
curl -s 'http://prometheus:9090/api/v1/query' \
  -d 'query=sum(rate(mysql_slow_queries_total[5m]))' | jq '.data.result[0].value[1]'
# Redis 延迟
curl -s 'http://prometheus:9090/api/v1/query' \
  -d 'query=histogram_quantile(0.99, sum(rate(redis_command_duration_seconds_bucket[5m])) by (le, command))' \
  | jq '.data.result[0].value[1]'
# 期望输出：MySQL 慢查询率 < 0.01/s；Redis P99 < 5ms
# 异常判定：MySQL 慢查询率 > 0.1/s → DB 瓶颈，查 2-3；Redis P99 > 20ms → Redis 大 key 或网络

2-3 检查线程池/连接池饱和度

# HikariCP 活跃连接占比
curl -s 'http://prometheus:9090/api/v1/query' \
  -d 'query=hikaricp_active_connections / hikaricp_max_pool_size' \
  | jq '.data.result[] | {pod: .metric.pod, ratio: .value[1]}'
# 期望输出：ratio < 0.7
# 异常判定：ratio > 0.9 → 连接池打满，请求排队 → 根因在下游 RT 变高或并发突增
# Tomcat 工作线程
curl -s 'http://prometheus:9090/api/v1/query' \
  -d 'query=tomcat_threads_busy / tomcat_threads_max' \
  | jq '.data.result[] | {pod: .metric.pod, ratio: .value[1]}'
# 期望输出：ratio < 0.8
# 异常判定：ratio > 0.95 → 线程池耗尽，新请求直接排队

2-4 检查 GC 停顿（Java 服务）

# GC 停顿频率与时长
curl -s 'http://prometheus:9090/api/v1/query' \
  -d 'query=sum(rate(jvm_gc_pause_seconds_sum[5m])) by (pod) / sum(rate(jvm_gc_pause_seconds_count[5m])) by (pod)' \
  | jq '.data.result[] | {pod: .metric.pod, avg_pause_ms: (.value[1] | tonumber * 1000 | floor)}'
# 期望输出：avg_pause_ms < 50（即单次 GC 平均 < 50ms）
# 异常判定：avg_pause_ms > 200 → Full GC 频繁，查堆内存与 GC 日志
# 辅助：kubectl exec $POD -- jcmd $(pgrep java) GC.heap_info 2>/dev/null | head -20

2-5 用 trace 看慢请求链路瓶颈

# 从 OpenTelemetry / Jaeger 取最近 1 min P99 以上的 trace
curl -s 'http://jaeger:16686/api/traces?service=<service>&operation=<endpoint>&lookback=5m&limit=3' \
  | jq '.data[0].spans[] | {operation: .operationName, duration_us: .duration, tags: (.tags | map(select(.key=="span.kind")) | .[0].value)}'
# 期望输出：各 span duration 之和 ≈ 总 duration，无单 span 占比 > 50%
# 异常判定：某下游 span 占比 > 70% → 瓶颈在该下游；网络 span 占比高 → 跳场景四

场景三：磁盘 IO 打满

典型症状：节点 iostat 显示 util% 接近 100%，await > 20ms，Pod 内应用响应变慢

3-1 确认是节点级还是 Pod 级 IO 瓶颈

# 节点级 iostat（需 ssh 到节点或 kubectl debug）
kubectl debug node/<node-name> -it --image=busybox -- sh -c 'iostat -x 1 3' 2>/dev/null \
  || echo "需 root：ssh <node> iostat -x 1 3"
# 期望输出：%util < 70，await < 10ms
# 异常判定：%util > 90 且 await > 20ms → 磁盘 IO 打满；
#           %util 高但 await 低 → 小 IO 密集（正常高 IOPS 场景）

3-2 定位是哪个 Pod / 容器在打 IO

# cgroup 维度 IO 统计（需节点 root）
kubectl debug node/<node-name> -it --image=busybox -- sh -c '
  for d in /sys/fs/cgroup/io/blkio.throttle.io_service_bytes; do
    echo "=== $d ==="
    cat $d 2>/dev/null | head -5
  done
  cat /sys/fs/cgroup/io/blkio.throttle.io_service_bytes 2>/dev/null | sort -k2 -rn | head -10
'
# 期望输出：各 Pod io_service_bytes 分布均匀，无单 Pod 占比 > 50%
# 异常判定：某 Pod 占比 > 60% → 该 Pod 为 IO 大户，查其日志写入量

3-3 检查磁盘空间与 inode

kubectl debug node/<node-name> -it --image=busybox -- sh -c '
  df -h | grep -v tmpfs
  echo "---"
  df -i | grep -v tmpfs
'
# 期望输出：Use% < 80，IUse% < 80
# 异常判定：Use% > 90 → 磁盘将满，需清理或扩容；IUse% > 85 → inode 耗尽（大量小文件）

3-4 检查慢盘 / SMART 状态

kubectl debug node/<node-name> -it --image=busybox -- sh -c '
  smartctl -H /dev/sda 2>/dev/null || echo "需 smartmontools 镜像"
  dmesg | grep -i "error\|reset\|timeout" | tail -10
'
# 期望输出：SMART overall PASSES；dmesg 无 I/O error / reset 关键字
# 异常判定：SMART FAILED → 磁盘硬件故障，立即迁移 Pod；dmesg 有 "reset" → 磁盘控制器异常

场景四：网络丢包 / 延迟抖动

典型症状：跨节点/跨 Pod 调用超时增多，tcpdump 看到大量重传，ping 延迟抖动 > 5ms

4-1 确认丢包位置（节点间 vs Pod 内 vs 外部）

# 节点间 ping + 丢包
kubectl debug node/<node-a> -it --image=busybox -- sh -c '
  ping -c 10 -W 1 <node-b-ip> 2>&1 | tail -3
'
# 期望输出：0% packet loss，rtt < 1ms（同机房）
# 异常判定：loss > 0% → 节点间网络问题；rtt > 5ms → 链路拥塞
# Pod 间
kubectl debug node/<node-a> -it --image=busybox -- sh -c '
  ping -c 10 -W 1 <pod-b-ip> 2>&1 | tail -3
'
# 期望输出：0% loss，rtt < 2ms
# 异常判定：loss > 0% → CNI 插件或 veth 问题

4-2 抓包确认重传与延迟分布

kubectl debug node/<node-a> -it --image=nicolaka/netshoot -- sh -c '
  tcpdump -i eth0 -nn -c 100 "tcp[tcpflags] & (tcp-syn|tcp-ack) != 0 and port <server-port>" -w /tmp/capture.pcap
  # 分析重传比例
  tcpdump -r /tmp/capture.pcap -nn 2>/dev/null | grep -c "retransmit\|TCP.*[Ss]eg" 
  echo "total: $(tcpdump -r /tmp/capture.pcap -nn 2>/dev/null | wc -l)"
'
# 期望输出：retransmit 比例 < 1%
# 异常判定：retransmit > 5% → 网络层丢包严重；> 20% → 链路故障

4-3 检查 CNI 网络策略与 conntrack 表

# conntrack 表使用率
kubectl debug node/<node-a> -it --image=busybox -- sh -c '
  conntrack -L 2>/dev/null | wc -l
  cat /proc/sys/net/netfilter/nf_conntrack_max 2>/dev/null
'
# 期望输出：当前条目 < max × 0.7
# 异常判定：当前条目 > max × 0.9 → conntrack 表满，新连接被 DROP
# 网络策略
kubectl get networkpolicy -n $NS -o wide | wc -l
kubectl get networkpolicy -n $NS | grep -c "DENY\|drop"
# 期望输出：无意外 DENY 规则拦截正常流量

4-4 检查网卡错误计数

kubectl debug node/<node-a> -it --image=busybox -- sh -c '
  ethtool -S eth0 2>/dev/null | grep -i "error\|drop\|discard\|miss" | head -10
  ip -s link show eth0 | grep -A2 "RX:\|TX:"
'
# 期望输出：errors = 0，drop = 0
# 异常判定：rx_errors > 0 且持续增长 → 网卡硬件或驱动问题；
#           rx_dropped > 0 → 内核 ring buffer 不足或 CPU 软中断跟不上

场景五：内存 OOM 级联

典型症状：单节点内存打满 → Pod 被 OOMKill → 业务流量转移到其他节点 → 连锁 OOM

5-1 确认 OOM 事件范围

# 最近 30 min 集群级 OOM 事件
kubectl get events -A --sort-by=.lastTimestamp \
  --field-selector type=Warning \
  -o custom-columns=TIME:.lastTimestamp,NS:.namespace,POD:.involvedObject.name,REASON:.reason,MSG:.message \
  | grep -i "OOM\|Killed\|Evict" | head -20
# 期望输出：无 OOM / Evict 事件
# 异常判定：单节点 ≥ 3 个 Pod OOMKill → 节点内存不足；跨 ≥ 2 节点 → 集群级内存压力

5-2 节点内存分布（谁在吃内存）

kubectl debug node/<node-name> -it --image=busybox -- sh -c '
  free -h
  echo "---"
  ps aux --sort=-%mem | head -15
  echo "---"
  cat /proc/meminfo | grep -E "MemTotal|MemAvailable|SwapTotal|SwapFree"
'
# 期望输出：MemAvailable > 10% of MemTotal；无进程内存占比 > 30%
# 异常判定：MemAvailable < 5% → 内存耗尽；某进程（非容器）内存 > 20% → 宿主机进程泄漏

5-3 确认是 limit 不足还是内存泄漏

# 查看 OOM 被杀 Pod 的内存曲线（Prometheus）
curl -s 'http://prometheus:9090/api/v1/query_range' \
  -d "query=container_memory_working_set_bytes{pod=\"$POD\",namespace=\"$NS\"}" \
  -d "start=$(date -d '1 hour ago' +%s)&end=$(date +%s)&step=30s" \
  | jq '[.data.result[0].values[][1] | tonumber] as $v | {min: ($v|min), max: ($v|max), last: $v[-1], limit_mb: 512}'
# 期望输出：max < limit × 0.85，曲线平稳
# 异常判定：曲线持续上升（锯齿或单调）→ 内存泄漏；突跳后 OOM → 瞬时大对象分配

5-4 检查 K8s 内存驱逐阈值

kubectl get node <node-name> -o jsonpath='{.status.allocatable.memory}'
echo ""
kubectl get node <node-name> -o jsonpath='{.spec}' | jq .
# 检查 kubelet 驱逐配置
kubectl debug node/<node-name> -it --image=busybox -- sh -c '
  cat /var/lib/kubelet/config.yaml 2>/dev/null | grep -A5 "eviction"
  # 或
  journalctl -u kubelet --since "10 min ago" 2>/dev/null | grep -i "evict\|oom" | tail -10
'
# 期望输出：eviction 阈值 memory.available < 100Mi（默认）
# 异常判定：memory.available 已低于阈值 → kubelet 正在驱逐，需立即扩容或减载

5-5 紧急止血：降低内存压力

# 非核心 Pod 降配或驱逐（按优先级）
kubectl get pods -n $NS --sort-by=.spec.priority \
  -o custom-columns=POD:.metadata.name,PRIORITY:.spec.priority,STATUS:.status.phase
# 操作：kubectl delete pod <non-critical-pod> -n $NS --grace-period=5
# 期望输出：非核心 Pod 被驱逐后，核心 Pod 内存 headroom > 20%
# 异常判定：驱逐后仍 OOM → 内存总量不足，需加节点或降并发

5 分钟升级路径表

| 触发指标 | 阈值 | 升级动作 | 责任人角色 | 时限 | |---------|------|---------|-----------|------| | 单 Pod P99 延迟 | > 1000ms 持续 3 min | 拉对应服务 Owner + SRE 值班 | 服务 Owner（一线） | 2 min 内响应 | | 节点内存 OOMKill | ≥ 3 Pod / 10 min | 升级至 SRE 团队 Leader，启动节点迁移 | SRE Leader（二线） | 5 min 内介入 | | 集群错误率 | > 5% 持续 5 min | 拉全链路值班（前端+后端+DBA+网络），启动 P0 作战室 | 技术总监（三线） | 5 min 内到齐 | | 磁盘 IO util% | > 95% 持续 5 min 且待处理 I/O 队列 > 50 | 联系存储/基础设施团队，准备数据迁移 | 基础设施 Owner | 10 min 内响应 | | 网络丢包率 | > 5% 持续 3 min 或 conntrack 表 > 95% | 拉网络团队 + CNI 插件 Owner，准备 CNI 回滚 | 网络 Owner | 5 min 内介入 | | 全集群 ≥ 50% Pod 不可用 | 任意时刻 | 启动公司级 P0，CTO 线知会，客户公告 | CTO / CMO | 立即 |

附录：常用命令速查

# 一键体检（复制粘贴即用）
echo "=== Node 状态 ===" && kubectl get nodes -o wide
echo "=== 近 5 min 错误率 ===" && curl -s 'http://prometheus:9090/api/v1/query' -d 'query=sum(rate(http_requests_total{status=~"5.."}[5m]))/sum(rate(http_requests_total[5m]))' | jq '.data.result[0].value[1]'
echo "=== 近 5 min Top5 慢接口 ===" && curl -s 'http://prometheus:9090/api/v1/query' -d 'query=topk(5,histogram_quantile(0.99,sum(rate(http_request_duration_seconds_bucket[5m]))by(le,service)))' | jq '.data.result[].value[1]'
echo "=== OOM 事件 ===" && kubectl get events -A --sort-by=.lastTimestamp -o custom-columns=NS:.namespace,POD:.involvedObject.name,REASON:.reason | grep -i oom | head -5
echo "=== 完成 ==="

使用说明：本手册为操作型手册，所有命令均可在 bash 4+ 环境直接执行。标注"需 root"的命令需通过 kubectl debug node/... 或 ssh 到节点执行。所有 IP 均为示例（10.0.x.x），域名均为 example.com。