4. 数据接入故障排查：数据源连接失败、数据格式不匹配、数据延迟到达的根因分析与修复

在 Should-Cost 智能寻源模型中，数据接入是模型运转的“生命线”。数据源连接失败、格式不匹配或延迟到达，会直接导致模型无法计算基准成本、谈判策略失效。本章聚焦三类典型故障的根因定位与标准化修复流程。

4.1 故障分类与影响矩阵

数据接入故障可按发生阶段与影响范围分为三类。下表总结了每类故障的典型表现、根因范围及业务影响等级。

4.2 数据源连接失败：根因分析与修复

连接失败是最紧急的故障，通常阻断整个数据管道。以下流程图展示了从告警到恢复的标准排查路径。

4.2.1 根因定位清单

• 网络层： 使用 ping <数据源域名/IP> 和 telnet <host> <port> 测试连通性。若不通，检查防火墙规则、VPN 隧道状态、DNS 解析。
• 认证层： 检查 是否过期、数据库密码是否轮换、SSL 证书是否有效。查看日志中的 401 Unauthorized 或 403 Forbidden。
• 服务层： 调用数据源的健康检查端点（如 /health 或 /status）。若返回 5xx，联系上游系统管理员确认服务是否宕机或正在维护。

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

session = requests.Session()
retries = Retry(total=3, backoff_factor=1, status_forcelist=[500, 502, 503, 504])
session.mount('https://', HTTPAdapter(max_retries=retries))

try:
    response = session.get('https://api.supplier.com/v1/prices', timeout=10)
    response.raise_for_status()
except requests.exceptions.ConnectionError:
    print("连接失败：请检查网络或服务状态")
except requests.exceptions.Timeout:
    print("连接超时：请检查网络延迟或增大超时设置")

4.3 数据格式不匹配：根因分析与修复

格式不匹配是 Should-Cost 模型中最隐蔽的故障。上游一个字段类型从 DECIMAL(10,2) 改为 VARCHAR，就可能导致成本计算全部归零。以下结构图展示了格式校验的层级。

4.3.1 常见格式问题与修复

4.4 数据延迟到达：根因分析与修复

数据延迟到达不会立即报错，但会导致 Should-Cost 模型使用过时价格，使谈判建议失去时效性。延迟的根因通常隐藏在调度依赖链中。

4.4.1 延迟根因排查步骤

1. 检查调度日志： 查看 ETL 任务的实际开始时间和结束时间，对比预期时间窗口。
2. 分析上游依赖： 确认上游数据源是否按时产出。例如，供应商价格文件是否在每日 08:00 前到达 FTP。
3. 评估资源争抢： 检查同一时段是否有大量任务并行，导致 CPU/内存/IO 瓶颈。
4. 验证队列积压： 如果使用消息队列（如 Kafka、RabbitMQ），检查消费者 Lag 是否持续增长。

4.4.2 延迟容忍度与降级策略

# prometheus.yml 中定义数据延迟指标
- job_name: 'data_pipeline_lag'
  metrics_path: '/metrics'
  static_configs:
    - targets: ['etl-node:9090']

# alert rule
groups:
  - name: data_lag
    rules:
      - alert: DataArrivalDelay
        expr: data_pipeline_lag_seconds{type="supplier_price"} > 7200
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "供应商价格数据延迟超过2小时"

4.5 故障修复标准化流程

无论哪类数据接入故障，都应遵循统一的“发现-定位-修复-验证-复盘”闭环。以下流程可作为团队 SOP 参考。