面试 · 场景排查型

用户反馈"下单很慢"
  │
  ├─ Step 1: 确认影响范围（对照组破案）
  │   ├─ 是所有用户还是部分用户？（部分 → 可能是特定区域/客户端）
  │   ├─ 是所有接口还是只有下单？（只有下单 → 下单链路特有问题）
  │   ├─ 是持续性的还是偶发的？（偶发 → 可能是容量/抖动）
  │   └─ 对照组：找一个"正常"的服务对比，差异处就是根因方向
  │
  ├─ Step 2: 看 Dashboard（黄金信号）
  │   ├─ P99 延迟是否确实上升？→ 是，看是哪段时间开始的
  │   ├─ 错误率是否也上升？→ 判断是"慢"还是"错"
  │   ├─ 流量是否有变化？→ 流量突增也会导致延迟上升
  │   └─ 饱和度如何？→ CPU throttle？连接池满？
  │
  ├─ Step 3: Trace 分析（定位哪一跳慢）
  │   ├─ 打开 Tempo/Jaeger 看下单请求的完整链路
  │   ├─ 找到耗时最长的 span（是数据库查询？下游 RPC？）
  │   └─ 用 exemplar 从指标跳到具体慢请求的 trace
  │
  ├─ Step 4: 定位到具体 Span
  │   ├─ 如果是 DB 慢 → 查 slow query log + 连接池 + 索引
  │   ├─ 如果是下游慢 → 查下游服务的 Dashboard
  │   ├─ 如果是网络 → 查丢包/重传/跨区延迟
  │   └─ 如果是自身处理慢 → 查 GC/log/CPU throttle
  │
  ├─ Step 5: 关联最近变更
  │   ├─ 最近有没有发布？（查部署记录）
  │   ├─ 有没有配置变更？（ConfigMap/Secret/HPA）
  │   ├─ 有没有流量突增？（营销活动/上游重试）
  │   └─ 有没有基础设施变更？（节点轮换/DB 迁移）
  │
  └─ Step 6: 修复 + 治理
      ├─ 止损：回滚/切流/扩容
      ├─ 根因：写 Postmortem
      └─ 治理：加告警、加 runbook、加压测

T+0   Acknowledge 告警（表示"我看到了"）
T+1   打开 Grafana Dashboard，确认:
      - 是真的延迟升高还是监控数据抖动？
      - 只影响 order-api 还是多个服务？
      - 错误率是否也在上升？
      - 流量是否有突增？
T+3   如果是真实故障:
      - 判断 SEV 级别（影响用户比例 → SEV-2 还是 SEV-3）
      - SEV-2 以上 → 拉事故群，任命 IC
T+5   初步诊断:
      - 最近有没有发布？（查部署记录）
      - 流量有没有突增？
      - 先看 Tempo trace 找 slowest span
      - 检查下游服务健康度
T+8   如果有明确嫌疑（如新发布的版本）:
      - 优先回滚而非修复
      - IC 确认回滚命令 → 执行 → 观察指标是否回落
T+15  确认恢复 → 进入监控阶段
T+45  指标稳定 30 分钟 → Resolve → 排 Postmortem 时间

kubectl describe pod <pending-pod> | grep -A5 Events

Events 可能显示:
  ├─ "FailedScheduling: 0/5 nodes are available: 5 Insufficient cpu"
  │   → 节点资源不足
  │   → 检查节点容量 + HPA + Cluster Autoscaler
  │   → 验证 Pod 的 resources.requests 是否合理
  │
  ├─ "FailedScheduling: node(s) had untolerated taint"
  │   → Pod 缺 toleration
  │   → 检查节点 taint + Pod toleration 配置
  │   → ★ 排查所有同 nodeSelector 的组件（一个缺陷往往是一类）
  │
  ├─ "FailedScheduling: node(s) didn't match Pod's node affinity"
  │   → nodeSelector/affinity 不匹配
  │   → 检查是否有可用节点
  │   → 检查节点标签是否正确
  │
  ├─ "FailedScheduling: didn't trigger scale-up due to missing matching nodepool"
  │   → 自动扩缩器找不到匹配的节点池
  │   → 检查 Karpenter/CA 的 Provisioner 配置
  │   → 检查节点池是否支持所需的 instance type
  │
  ├─ "FailedMount" 或 PVC 相关
  │   → PV/PVC 绑定问题
  │   → kubectl describe pvc
  │   → 检查 StorageClass 是否有可用 PV
  │
  └─ ImagePullBackOff
      → 镜像拉不下来
      → 检查 image name 拼写
      → 检查 registry 可达性（跨境源？换 mirror）
      → 检查 imagePullSecrets

新 Pod CrashLoopBackOff
  │
  ├─ kubectl logs <pod> --previous
  │   ├─ 有日志 → 读日志定位错误
  │   │   ├─ "connection refused" → DB/Redis/下游连不上
  │   │   │   → 检查 Service 名是否正确（不同集群可能不同）
  │   │   ├─ "permission denied" → RBAC/安全上下文问题
  │   │   ├─ "config error" → ConfigMap/Secret 字段缺失或格式错误
  │   │   ├─ "OOMKilled" → 内存超限，调 limits 或查内存泄漏
  │   │   └─ "class not found" → 镜像版本不对
  │   └─ 无日志 → 容器在启动早期就挂了
  │       → 检查镜像是否正确
  │       → 检查 entrypoint/command
  │
  ├─ kubectl describe pod <pod>
  │   ├─ "Liveness probe failed" → 健康检查配置与新版不兼容
  │   ├─ "Readiness probe failed" → 依赖未就绪
  │   └─ "Back-off restarting failed container"
  │
  ├─ kubectl get events -n <ns> --sort-by='.lastTimestamp'
  │   └─ 看最近事件找线索
  │
  └─ 确认回滚完成后，分析新版与旧版的差异

1. 如果 Redis 有 replica → 手动 failover 到 replica
2. 如果有读/写分离 → 先把读流量切到 replica
3. 如果没有 HA → 重启 Redis（接受短暂不可用）

redis-cli 连上：
  ├─ INFO commandstats → 看哪种命令最多（可能是 KEYS * 或大 HGETALL）
  ├─ SLOWLOG GET 20 → 看最近的慢命令
  ├─ CLIENT LIST → 看连接数是否异常
  ├─ INFO memory → 看是否在 evict key
  └─ INFO persistence → 看是否在 RDB/AOF 写盘（也会拉高 CPU）

根因可能：
  ├─ 某服务上线引入了 KEYS *（生产禁用！）
  ├─ 大 key 被频繁访问（HGETALL 一个 10MB 的 hash）
  ├─ 连接风暴（某服务快速重连）
  ├─ 内存满触发 eviction 导致 CPU 飙高
  └─ 持久化触发（RDB bgsave 时 fork 大内存进程）

Step 1: 确认 Prometheus 是否活着
  kubectl -n monitoring get pod -l app=prometheus
  kubectl -n monitoring logs prometheus-0 | tail -20
  → 看是否有 OOM / WAL corruption / disk full

Step 2: 检查查询是否有高基数
  └─ 最近有没有新增高基数 label？
     如 user_id、request_id 被放进了 label
     → 序列数爆炸 → Prometheus 内存 OOM
  → 查 Prometheus TSDB 状态: curl localhost:9090/api/v1/status/tsdb

Step 3: 检查存储
  └─ Prometheus TSDB 保留时间 + 当前 PVC 使用量
     磁盘满了 → Write-Ahead Log 写失败 → 整体卡住

Step 4: 检查 Recording Rules
  └─ 如果有长时间窗口的 Recording Rule（如 30d）在实时计算
     → 评估太慢 → 阻塞其他查询
  → 看 Prometheus Rules 页面的 evaluation time

Step 5: 紧急止血
  └─ 如果确认是查询卡死 → 重启 Prometheus
     （丢 2h 内存数据但恢复服务）
  └─ 如果是高基数 → 删除违规的指标序列

Step 1: 区分 A 和 B 的调用链差异
  ├─ B 服务有没有自己的独立后端？
  ├─ B 服务是否依赖某个 A 不依赖的下游/数据库？
  └─ B 服务是否有独立的 Ingress/Gateway 配置？

Step 2: 定位 502 来源
  ├─ 是 NLB/ALB 返回的 502 → 查 target group health
  ├─ 是 Ingress/Gateway 返回的 502 → 查 upstream service endpoints
  └─ 是应用本身返回的 502 → 查应用日志

Step 3: 常见根因
  ├─ B 服务的 Pod 全挂了（OOM/deployment 误删）
  ├─ B 服务的 Service endpoints 为空（selector 不匹配）
  ├─ B 服务的网络策略阻断了流量
  └─ B 服务的 NLB target group health check 失败

Step 4: 对照检查
  kubectl get endpoints <B-service>  → 是否为空？
  kubectl get pod -l app=<B>         → Pod 是否 Running？
  kubectl describe svc <B-service>   → selector 是否正确？

判断逻辑：
  ├─ 1. 看告警时间分布
  │    ├─ 同一秒同时触发 → 更像是监控链路问题
  │    └─ 逐步蔓延（先 1 个、30s 后 5 个、1min 后 50 个） → 像真实故障传播
  │
  ├─ 2. 看 Dashboard 数据
  │    ├─ 指标是否真的异常？（错误率/延迟真的在升高）
  │    └─ 还是只有告警在响但指标正常？ → Alertmanager 自身问题
  │
  ├─ 3. 看是否有相关发布
  │    ├─ 查部署记录 → 最近 30min 有没有发布？
  │    └─ 如果有 → 优先怀疑是发布导致 → 准备回滚
  │
  ├─ 4. 看影响面
  │    ├─ 能否在 staging/qa 复现？ → 如果能 → 是代码问题
  │    └─ 只有 prod 有？ → 可能是容量/特定流量模式
  │
  └─ 5. 看告警是否有 Grouping 异常
       └─ Alertmanager 的 group_by 配置是否合理？
          一次发布挂 50 个 pod → 应该合并成 1 条告警

Step 1: 检查 ArgoCD Application 状态
  argocd app get <app-name>
  → 看 Sync Status: OutOfSync 还是 Synced？
  → 看 Health Status: Healthy / Degraded？

Step 2: 如果是 OutOfSync 但没自动同步
  → 检查 syncPolicy.automated 是否开启
  → 主力 ArgoCD 常设手动 sync → merge 后需手动触发
  → kubectl patch application -n argocd <app> --type=merge --patch '{"operation":{"sync":{"revision":"HEAD"}}}'

Step 3: 如果是 Synced 但实际路由无效
  → kubectl get httproute -n <ns> <name> -o yaml
  → 检查 field 是否正确（Gateway API vs Istio VS 是两套路由！）
  → HTTPRoute 管南北流量，VirtualService 管东西流量

Step 4: 验证路由是否生效
  → curl -H "Host: xxx" <gateway-ip>
  → 看实际路由到哪个 backend

Step 5: 如果是 ArgoCD AutoSync 卡住
  → 看 Application 的 Conditions
  → ComparisonError / SyncError
  → 可能是 CRD 太大超过 256KB annotation 上限 → 加 ServerSideApply

CPU/内存正常 + 5xx 高 → 排除自身过载 → 往下游或网络方向查

排查路径:
  ├─ 1. 看 5xx 的具体类型
  │    ├─ 502 Bad Gateway → 上游从下游收到的响应无效
  │    ├─ 503 Service Unavailable → 服务临时过载或维护
  │    └─ 504 Gateway Timeout → 下游响应超时
  │
  ├─ 2. 如果是 502/504 → 大概率是下游问题
  │    ├─ 查下游服务的 Dashboard
  │    ├─ 查 Tempo trace 看失败在哪个 span
  │    └─ 查下游的连接池是否耗尽（连接数 vs max）
  │
  ├─ 3. 如果是 503 → 可能是自己过载
  │    ├─ 检查线程池队列长度（CPU 正常但队列满 → 阻塞等待而非计算）
  │    └─ 检查 Rate Limiting 是否触发
  │
  ├─ 4. 关联变更
  │    ├─ 有没有 DNS 变更？
  │    ├─ 证书过期？
  │    ├─ NetworkPolicy 变更？
  │    └─ 下游服务发布？
  │
  └─ 5. 隐式错误检查
       ├─ 服务返回 200 但业务结果错？
       └─ 检查业务层埋点

kubectl describe node <node-name>

看 Conditions:
  ├─ MemoryPressure=True → 节点内存不足
  ├─ DiskPressure=True → 节点磁盘空间不足
  ├─ PIDPressure=True → 进程数超限
  └─ NetworkUnavailable=True → CNI 插件问题

看具体根因:
  ├─ kubectl get node <node> -o json | jq '.status.conditions'
  ├─ 登录节点: journalctl -u kubelet --since "10 min ago"
  └─ 检查: kubelet 是否活着？CNI 是否正常？磁盘是否满了？

常见根因:
  ├─ /var/lib/kubelet 磁盘写满（日志/image layers）
  ├─ CNI 插件 CrashLoop（VPC CNI / Calico / Cilium）
  ├─ kubelet 证书过期
  ├─ containerd/docker 挂了
  └─ 内核 oom killer 影响了 kubelet

1. 连接数超限 → 调大 max_connections（临时，快速止血）
2. Kill 长时间 idle 的连接
3. 如果确认是新版本的问题 → 回滚

1. 新版本是否有连接泄漏？
   → 在代码里检查：连接是否在 finally 中正确归还

2. 是否有 N+1 查询？
   → Tempo trace 看单次请求发了多少次 DB 查询
   
3. 连接池配置是否合理？
   → maxPoolSize = ?
   → 等待队列满了之后的行为（fail-fast 还是无限排队？）

4. 新版是否导致更多并发请求打过来？
   → 看 QPS 变化

1. 主动触发一条测试告警
   → 写一条 expr: vector(1) 的规则
   → 看能否在 Alertmanager 和钉钉看到

2. 如果看不到：
   ├─ 规则是否加载？→ Prometheus Rules API
   ├─ ruleSelector 是否匹配？→ staging 的 rule label 是否和 selector 一致
   ├─ Alertmanager 是否可达？→ Prometheus targets 页面
   └─ 钉钉 webhook 是否有效？→ token 过期？关键词白名单？

3. 常见根因：
   ├─ staging 的 ruleSelector 用 release: kube-prometheus → 但规则没打这个 label
   ├─ staging 的 Alertmanager 整体挂了 → 没死机开关发现
   └─ 钉钉群 token 已失效

4. 修复后验证：
   └─ 主动制造一次 firing → 确认全链路推送到群

Step 1: 确认用户报告是否真实
  ├─ 查 Grafana 看凌晨 2 点的指标
  │   ├─ 错误率有上升？→ 真实故障
  │   └─ 指标正常？→ 可能是用户侧问题或监控盲区
  └─ 查日志看有没有 ERROR

Step 2: 如果是真故障但没告警
  ├─ 告警规则是否正确？
  │   ├─ ruleSelector 是否匹配？→ 75 天没生效的坑
  │   ├─ for 时间太长？→ 故障短于 for 时间
  │   └─ 阈值设太高？
  ├─ 告警链路是否正常？
  │   ├─ Prometheus 当时在运行吗？
  │   ├─ Alertmanager 当时在运行吗？
  │   └─ 钉钉 webhook 当时通吗？
  └─ 告警是否被 silence 了？
      └─ 查 silence 历史

Step 3: 如果是监控盲区
  ├─ 凌晨 2 点是否有真实流量？
  │   ├─ 有流量 → 真实用户受影响
  │   └─ 无流量 → 可能是合成监控盲区
  ├─ 是否有黑盒监控覆盖？
  │   └─ 没有黑盒 → 凌晨无流量时无信号
  └─ 死机开关是否在工作？

Step 4: 修复 + 治理
  ├─ 补告警规则
  ├─ 加黑盒监控（cuj-prober 7×24 拨测）
  ├─ 加死机开关
  └─ Postmortem：为什么监控盲区存在

Step 1: 确认重启原因
  kubectl describe pod <pod> | grep -A5 "Last State"
  ├─ OOMKilled → 内存 limit 太低或内存泄漏
  ├─ Liveness probe failed → 健康检查配错或应用卡顿
  ├─ Error → 应用代码异常退出
  └─ Evicted → 节点资源不足

Step 2: 评估业务影响
  ├─ 重启时 in-flight 请求会失败吗？
  │   └─ 没有 preStop hook → SIGTERM 立即断连
  ├─ 重启时新请求会路由到这个 Pod 吗？
  │   └─ readiness probe 没及时摘除 → 流量丢失
  └─ 重启频率高会导致连接池抖动

Step 3: 修复
  ├─ OOMKilled → 调内存 limit 或查内存泄漏
  ├─ Liveness probe → 调整超时/间隔
  ├─ 加 preStop hook → 优雅终止
  └─ 加 PDB → 防止同时重启多个

Step 1: 止损——隔离影响
  ├─ 识别是哪个 namespace
  ├─ 如果有 NetworkPolicy → 临时限制其网络
  ├─ 如果有 ResourceQuota → 检查是否生效
  └─ 必要时 scale down 该 namespace 的 Pod

Step 2: 定位根因
  ├─ kubectl top pod -n <ns> → 找出最耗资源的 Pod
  ├─ 看是否有异常流量（DDoS？循环调用？）
  ├─ 看是否有新发布引入 bug
  └─ 看是否有 OOM 导致频繁重启

Step 3: 长期治理
  ├─ ResourceQuota：每个 namespace 设 CPU/内存上限
  ├─ LimitRange：每个 Pod 设默认 requests/limits
  ├─ NetworkPolicy：限制 namespace 间流量
  ├─ PriorityClass：核心服务高优先级
  └─ 节点池隔离：核心服务用专用节点池

Step 1: 确认影响
  ├─ 从库是否在提供读服务？→ 是 → 用户可能读到旧数据
  ├─ 从库是否用于故障切换？→ 是 → HA 可能失败
  └─ lag 持续增大还是稳定？

Step 2: 定位根因
  ├─ 主库写入量突增？
  │   ├─ 看主库 QPS
  │   └─ 看是否有批量写入/DDL
  ├─ 从库性能问题？
  │   ├─ 从库 CPU/IO 是否满
  │   ├─ 从库是否有慢查询阻塞复制
  │   └─ 从库规格是否低于主库
  ├─ 网络问题？
  │   └─ 主从间网络延迟
  └─ 复制配置问题？
      ├─ 单线程复制 → 大事务会阻塞
      └─ 并行复制配置不当

Step 3: 止损
  ├─ 如果从库用于读 → 临时把读流量切回主库
  ├─ 如果 lag 持续增大 → 暂停从库的非必要查询
  └─ 如果是 DDL 导致 → 等待 DDL 完成

Step 4: 修复
  ├─ 启用并行复制（MySQL: slave_parallel_workers）
  ├─ 从库规格升级
  ├─ 长事务优化
  └─ 主库写入分批

Step 1: 确认告警是否真的没发
  ├─ Alertmanager UI 看是否有 firing 告警
  │   → 有 firing 但钉钉没收到 → 通知链路问题
  │   → 没有 firing → 告警规则问题
  └─ Prometheus UI 看告警状态

Step 2: 通知链路排查
  ├─ webhook-dingtalk 是否活着？
  │   kubectl -n monitoring get pod -l app=webhook-dingtalk
  ├─ 钉钉 webhook URL 是否有效？
  │   → token 被管理员删/重建 → 静默失效
  │   → curl 测试 webhook
  ├─ 钉钉群关键词白名单？
  │   → firing 含"告警"过关
  │   → resolved 只含"恢复"被拒（常见坑！）
  └─ Alertmanager 路由配置是否正确？

Step 3: 主动测试
  ├─ curl webhook-dingtalk 发测试消息
  ├─ 看钉钉群是否收到
  └─ 如果收不到 → 钉钉 API 返回什么错误码

Step 4: 常见根因
  ├─ 钉钉 token 静默失效（管理员操作）
  ├─ resolved 通知被关键词拦截
  ├─ webhook-dingtalk pod 挂了
  ├─ Alertmanager 配置被覆盖
  └─ 钉钉群被解散/机器人被移除

Step 1: 数据分析
  ├─ MTTR 上升是突然的还是渐进的？
  ├─ 是所有事故的 MTTR 都上升，还是某几次长事故拉高均值？
  └─ 哪类事故的 MTTR 上升最明显？

Step 2: 分解 MTTR
  MTTR = TTD（检测时间）+ TTA（响应时间）+ TTM（修复时间）
  ├─ TTD 上升 → 告警滞后或缺失
  ├─ TTA 上升 → on-call 响应慢
  └─ TTM 上升 → 修复难度增加

Step 3: TTA 上升的原因
  ├─ on-call 人员不熟悉系统（新人？）
  ├─ 告警 Runbook 过时或缺失
  ├─ 升级链不畅（找不到能处理的人）
  └─ 告警太多导致疲劳（先观察 5 分钟看是不是误报）

Step 4: TTM 上升的原因
  ├─ 事故复杂度增加（新架构？新依赖？）
  ├─ 回滚路径不通畅（镜像被清？配置丢失？）
  ├─ 排障工具不熟悉（trace 看不懂？日志找不到？）
  └─ 跨团队协调耗时

Step 5: 治理
  ├─ 补 Runbook
  ├─ 培训 on-call 人员
  ├─ 简化回滚流程
  ├─ 混沌工程演练（提升修复熟练度）
  └─ Postmortem 分析每次长事故的瓶颈

紧急上线请求
  │
  ├─ 1. 判定是否属于豁免类别
  │    ├─ 安全漏洞正被利用 / 数据正在损坏 / 合规硬要求 / 事故缓解 → 属于，继续
  │    └─ "很重要的新功能" → 不属于，冻结照旧（这是 Q16 的场景，不是本题）
  │
  ├─ 2. 走紧急变更审批（比常规更严，不是更松）
  │    ├─ 记录：为什么必须现在上、不上的风险、变更范围
  │    ├─ 审批人：SRE Lead + 安全/业务 owner 签字背书
  │    └─ 最小化变更面：只带这个修复，绝不夹带其他功能（"搭便车"是大忌）
  │
  ├─ 3. 更严的灰度 + 回滚预案（预算已耗尽，容错为零）
  │    ├─ 灰度更慢更细：1% → 观察更久 → 逐级放
  │    ├─ 回滚路径预先验证过（不能事故时才发现回滚也挂）
  │    ├─ 专人盯 burn rate，任何异常立即回滚
  │    └─ Feature flag 兜底：能秒级关闭最好
  │
  └─ 4. 事后
       ├─ 这次紧急消耗计入 Budget，但单独标记（区分"功能挥霍"和"安全必需"）
       ├─ Postmortem：为什么预算会耗尽到"连安全修复都要挣扎"的地步
       └─ 复盘豁免流程本身是否顺畅