3. 故障排查体系总览：故障分类、排查流程框架与关键监控指标
在基于 Should-Cost 模型的智能寻源谈判支持系统中，故障可能发生在数据采集、模型计算、业务应用等多个环节。建立清晰的故障分类体系和标准化的排查流程，是保障系统稳定运行的基础。本章从故障分层、排查框架、监控指标三个维度构建完整的故障排查体系。
3.1 故障分类：数据层、模型层、应用层
根据故障发生的系统层级，将故障划分为三类：数据层故障、模型层故障、应用层故障。每类故障的典型表现、根因和排查方向各不相同。
| 故障层级 | 典型表现 | 常见根因 | 排查方向 |
|---|---|---|---|
| 数据层 | Should-Cost 计算结果为空、价格偏离行业均值、历史数据缺失 | 数据源连接中断、字段映射错误、数据质量差（重复/异常值） | 数据源连通性、ETL 日志、数据完整性校验 |
| 模型层 | Should-Cost 结果不合理（如低于原材料成本）、模型训练不收敛、特征重要性异常 | 特征工程错误、超参数配置不当、模型版本回退、训练数据分布偏移 | 模型输入输出校验、特征分布监控、模型版本对比 |
| 应用层 | 谈判界面加载失败、推荐策略不生效、用户权限报错 | API 接口超时、前端缓存失效、权限配置错误 | 接口响应时间、前端日志、权限校验链路 |
故障分类原则： 故障定位时，优先确认数据层是否正常，再检查模型层，最后排查应用层。数据层故障会向上传导，导致模型层和应用层同时出现异常。
3.2 排查流程框架
标准化的排查流程采用“自底向上、分层隔离”的策略，分为四个阶段：故障发现 → 故障定位 → 根因分析 → 修复验证。每个阶段都有明确的输入、输出和关键动作。
排查流程要点： 故障定位阶段建议使用“二分法”快速缩小范围——先判断故障是否影响所有用户（全局性）还是特定用户（局部性），再判断是数据问题还是模型问题。
3.3 关键监控指标
为支撑故障排查体系的有效运转，需要建立覆盖数据层、模型层、应用层的监控指标体系。以下为各层核心监控指标及告警阈值建议。
3.3.1 数据层监控指标
- 数据源连通率：目标 ≥ 99.9%，低于 99% 触发告警。
- ETL 任务成功率：目标 100%，连续 2 次失败触发告警。
- 数据完整性：关键字段（如物料编码、价格）缺失率 ≤ 1%。
- 数据时效性：增量数据延迟 ≤ 30 分钟。
3.3.2 模型层监控指标
- 模型推理成功率：目标 ≥ 99.5%，低于 98% 触发告警。
- Should-Cost 结果置信度：平均置信度 ≥ 0.85，低于 0.7 触发告警。
- 特征分布漂移：PSI（群体稳定性指标）≤ 0.1，超过 0.2 触发告警。
- 模型响应时间：P99 ≤ 500ms，超过 1s 触发告警。
3.3.3 应用层监控指标
- API 接口可用率：目标 ≥ 99.9%，低于 99% 触发告警。
- 页面加载时间：P95 ≤ 3s，超过 5s 触发告警。
- 用户操作成功率：目标 ≥ 99%，低于 95% 触发告警。
- 谈判推荐采纳率：基线值 ± 20% 波动触发关注。
监控指标联动分析： 当模型层“推理成功率”下降时，应同步检查数据层“数据源连通率”和“ETL 任务成功率”。数据层故障往往是模型层异常的根因，避免在模型层过度排查。
3.4 故障排查体系总览图
以下 SVG 图将故障分类、排查流程、监控指标整合为一张体系总览图，便于培训学员建立全局认知。
体系使用建议： 故障发生时，先根据故障现象判断所属层级（数据层/模型层/应用层），再按照排查流程逐步推进，同时参考对应层级的监控指标进行数据验证。三层联动可大幅缩短平均故障恢复时间（MTTR）。