1. 线上问题现象分类与影响评估
线上问题排查的第一步，是快速、准确地对现象进行分类和影响评估。只有当异常类型、监控指标与紧急度被清晰定义，后续的采集与定位才能具备优先级与方向性。本章围绕“现象识别→数据采集”前序环节，建立一套可直接落地的分类框架与判断规则。
1.1 异常类型：三域分类模型
根据线上实际故障场景，将异常划分为三大域：业务域、系统域、网络域。每个域对应不同的监控维度和排查入口。
| 异常域 | 典型现象 | 直接指标 | 排查切入点 |
|---|---|---|---|
| 业务域 | 订单失败、支付超时、数据不一致 | 错误率、成功率、p99延迟 | 业务日志、RPC trace、DB 慢查询 |
| 系统域 | CPU 满载、内存溢出、Full GC、频繁 OOM | CPU 使用率、内存占用、GC 频率、系统负载 | jstack、jmap、vmstat、dmesg |
| 网络域 | 连接超时、丢包、重传率异常、DNS 解析失败 | TCP 重传率、连接数、RTT、丢包率 | tcpdump、ping、ss、nslookup |
优先判断业务域异常，因为其对用户体验的影响最直接；但是系统域和网络域往往是业务域异常的根本原因。
1.2 监控指标优先级：红绿灯判断规则
面对大量监控数据，可按“红绿灯”规则快速筛选出高关注指标：
- 红灯（P0级）：直接导致用户无法使用或数据丢失的指标。例如：业务错误率突破阈值、数据库不可写、所有 Pod 健康检查失败。
- 黄灯（P1级）：服务质量显著下降但尚可使用的指标。例如：p99 响应时间超过基线 3 倍、部分节点 CPU 使用率持续 80% 以上。
- 绿灯（P2/P3级）：次要指标或预警指标。例如：磁盘使用率超过 70%、GC 频率轻微上升。
红灯指标一旦触发，应无条件中断当前任务，立即进入数据采集流程。黄灯指标应列入快速排查队列，不做深度发版修复，优先查明影响范围。
1.3 紧急度判断矩阵
结合“影响用户数”与“影响功能完整性”两个维度，将问题划分为四个紧急度等级，指导故障处置顺序。
| 影响用户数 | 功能完全不可用 | 功能部分可用 | 功能正常但体验下降 |
|---|---|---|---|
| 大量用户 (≥10%) | P0 紧急 | P1 高 | P2 中 |
| 部分用户 (1%~9%) | P1 高 | P2 中 | P3 低 |
| 少量用户 (≤1%) | P2 中 | P3 低 | P3 低（可延迟处理） |
判断紧急度时，应参考以下信息源：
# 业务监控平台示例查询语句（用于获取当前错误率与用户影响范围）
# 假设使用 Prometheus PromQL
rate(error_count_total[5m]) / rate(request_count_total[5m]) > 0.05
--> 触发 P1 以上级别判断紧急度判断必须实时获取，不能依赖历史静态数据。对于 P0 级问题，必须有跨团队快速进入“现场快照”采集的通道。
1.4 故障树：异常现象 → 紧急度 → 采集动作
下面以故障树的形式，将三类异常域与紧急度判断、采集动作的关系可视化，方便一线运维与开发人员快速对照。
实际排查时，可将该故障树打印为 A4 速查表或挂在云文档中，团队在接到报警后按树状结构逐级判断，避免因人员经验差异导致紧急度误判。
1.5 关键判断规则速查（排查表）
以下规则用于快速判定是否需要立即启动“现场快照”采集流程：
# 规则1：凡涉及核心交易链路的异常，无论错误率高低，至少按P1处理
if 链路包含 [支付/下单/登录/数据库写入]:
if 错误率 > 0:
-> 紧急度 >= P1
# 规则2：系统资源耗尽类异常（如OOM、CPU 100%）自动升级为P1
if 系统指标命中 任何一项：
[OOM, 内存使用率>=95%, CPU 使用率>=90%, 磁盘写不进去]
-> 紧急度 >= P1
# 规则3：网络丢包率超过0.1%且影响跨机房/跨云调用
if 丢包率 > 0.1% AND 调用链路涉及跨区域:
-> 紧急度 >= P1以上规则可作为告警处理平台的“前置判断逻辑”，系统自动为告警打上紧急度标签，减少人工分析耗时。