第1章 失效现象分类与记录：观察维度、异常类型、时间戳标记

失效分析的起点是对现象本身的准确捕捉与结构化记录。许多排查过程之所以陷入“反复重启—复现—猜测”的死循环，根源在于初始现象描述模糊、信息遗漏或时间基准错乱。本章围绕“现象识别→数据采集→结构化记录”三个环节，建立一套可复用的失效现象分类与记录规范，为后续原因定位和修复提供可靠的原始数据。

1.1 现象识别：三个核心观察维度

任何失效现象都至少可以从时间特性、触发条件、表现特征三个维度进行拆解。在现场排查或测试复现时，应逐项填写下表，避免“系统崩溃”“页面卡死”这类无量化描述。

1.2 异常类型分类：建立统一标签体系

将观察到的现象映射到预定义的异常类型，可以大幅提升后续故障树搜索的效率。建议团队内部遵循以下三级分类树：

• 功能异常（核心业务逻辑不符合预期）
  • 服务端：请求失败、超时、返回错误码
  • 客户端：操作无响应、界面冻结、流程中断
• 性能异常（响应时间/吞吐量/资源使用偏离基线）
  • 响应时间：P99 > 2000ms 或持续劣化
  • 资源：CPU/内存/磁盘/连接池耗尽
  • 抖动：触发毛刺 (spike) 或线性爬坡
• 数据异常（数据完整性、一致性、持久化错误）
  • 丢失：部分字段为空、记录缺失
  • 错误：业务数值计算错误、状态机跳变
  • 延迟：数据库复制延迟超过阈值
• 通信异常（网络/协议/中间件层问题）
  • 连接：TCP重连次数超标、SSL握手失败
  • 协议：消息格式错误、序列化异常
  • 队列：消息堆积、死信、重复消费

1.3 时间戳标记：同步、精度与格式规范

时间戳是纵横多条信息的锚点。一条失效记录若缺失统一基准的时间戳，多系统关联分析将完全失效。以下为强制规范：

{
  "event_id": "a1b2c3d4-5678-90ab-cdef-1234567890ab",
  "timestamp_utc": "2025-03-21T06:32:17.123Z",
  "node": "prod-db-01",
  "dimension": {
    "type": "performance",
    "sub_type": "resource",
    "resource": "memory",
    "value": "92%"
  },
  "trigger": "bulk_insert_SQL_10k_rows",
  "scope": "single_node",
  "description": "heap usage exceeded 90% threshold, GC frequency increased to 12/min",
  "source": "jmx_exporter",
  "timezone_offset": "+08:00"
}

1.4 失效现象分类与记录流程（SVG）

下图总结了从发现失效到完成结构化记录的关键步骤，以及各环节必须留下的数据痕迹。

1.5 排查路径图：现象记录阶段的决策逻辑

当新失效现象出现时，按以下判断规则快速确定需要采集的数据范围，避免遗漏关键字段：

1. 检查时间戳是否可用 → 若日志无毫秒精度或时钟不同步，优先修复时钟或补打高精度时间戳。
2. 确认现象是否可复现 → 若可复现，立即启动触发条件记录（操作步骤+环境参数）；若不可复现，重点记录首次发生时间范围及频率特征。
3. 初步判定异常类型 → 根据异常类型选择后续深入工具：功能异常→添加全链路Trace ID；性能异常→启动Profiler/慢查询日志；数据异常→导出变更事件流；通信异常→抓包并记录TCP状态。
4. 形成结构化事件对象 → 使用第1.3节中的JSON模板写入本地文件或发送至集中事件总线。