排障是用最小成本的证据，把“用户看到的现象”逐步收敛到“系统里可修复的机制”。
现象是用户或监控能观察到的事实：5xx、延迟升高、CPU 饱和、Pod 未就绪。根因是导致现象的系统机制，例如连接池耗尽、DNS 超时、磁盘只读或锁等待。同一个现象可能有多个根因，同一个根因也可能表现为多种现象。排查的目标不是解释现象，而是找到可验证、可修复的那一层。
每次只提出一个可证伪的假设：“如果是数据库连接耗尽，那么 pg_stat_activity 的连接数应接近上限。”然后选择成本最低、区分度最高的命令验证。记录预测和结果，假设被推翻也是有效进展。同时改多个变量会让你无法判断哪个动作生效，也会破坏现场。先取证，再变更。
USE 面向资源：Utilization（使用率）、Saturation（饱和度）、Errors（错误），适合 CPU、内存、磁盘、网络和连接池。RED 面向服务：Rate（请求速率）、Errors（错误率）、Duration（延迟），适合接口和依赖。两套方法互补：RED 发现用户体验变差，USE 帮你找到承载资源的瓶颈。指标要结合基线看，绝对值本身很少说明问题。
系统是分层的：客户端 → DNS → 负载均衡 → 网关 → 应用 → 依赖 → 数据库 → 磁盘。网络又分 L2/L3/L4/L7，Kubernetes 又分 Pod、节点、控制面。每一层都有独立的证据来源，例如 dig、ss、curl、tcpdump、kubectl describe。分层不是从上到下机械走一遍，而是用证据决定下一层往哪走。
大多数故障发生在变更之后：发布、配置、证书、权限、网络策略、容量和流量。先建立时间线，把故障开始时间与部署、扩缩容、云事件和依赖变更对齐。变更关联不等于因果，但能显著缩小假设空间。证书到期、配额用尽和连接数增长属于“没有变更的变更”，也要纳入检查。
复盘要还原时间线、影响范围、检测方式、响应过程、直接原因和贡献因素，并产出有负责人和截止时间的行动项。复盘的目的不是追责，而是改进系统：补监控、加护栏、简化回滚、消除同类隐患。行动项必须可验证，否则下一次故障会以同样的方式发生。
| 维度 | 要回答的问题 | 典型证据 |
|---|---|---|
| 现象 | 谁受影响、影响多大、从何时开始 | 告警、SLO、用户反馈 |
| 范围 | 单实例、单可用区还是全局 | 分维度指标、日志分布 |
| 层次 | 请求停在哪一跳 | dig、ss、curl、追踪 |
| 资源 | 哪类资源饱和或报错 | USE 指标、cgroup、dmesg |
| 变更 | 最近改了什么 | 发布记录、配置 diff、证书 |
| 结论 | 哪个机制可复现 | 最小复现、修复验证 |
现象 → 界定范围 → 建立时间线 → 分层定位 → 假设验证 → 止损/修复 → 验证 → 复盘
止损和根因分析可以并行：先控制影响，再继续取证。不要在用户仍在受损时坚持“找到根因再处理”。
合上页面，先回答，再展开对照。