3. 故障信息收集：日志、错误码、用户报障信息、环境信息的系统化采集方法

故障定位的第一步是什么？不是翻电路图，也不是拿示波器戳。

是收集信息。

我见过太多工程师，拿到故障板子就开始拆、开始量，结果量了半天发现方向错了。为什么？因为连故障现象都没搞清楚。信息收集这一步，看似基础，其实最考验系统化思维。你想想看，信息不全，后面的分析全是瞎猜。

3.1 日志采集：从系统级到芯片级

日志是故障现场的第一手资料。但日志也分层次，不同层次的日志价值不同。

日志层级	典型来源	采集优先级	我的经验
系统日志	dmesg、syslog、Event Viewer	最高	先看时间戳，定位故障发生时刻
驱动日志	驱动调试输出、IO 日志	高	驱动日志常包含寄存器级信息
应用日志	业务软件、中间件日志	中	应用层报错往往只是表象
硬件日志	BMC、IPMI、SEL	最高	硬件日志能直接定位物理故障

我个人习惯，拿到故障设备后第一件事就是拉系统日志。用 dmesg 看内核环缓冲区，用 journalctl 看 systemd 日志。为什么要先看这个？因为系统日志记录了硬件与操作系统交互的原始信息，很多硬件故障在驱动层面就会留下痕迹。

举个例子。有一次客户报修说设备频繁重启。我远程上去一看，dmesg 里全是 EDAC 报错，内存 ECC 错误计数一直在涨。嗯，这就很清楚了——内存颗粒有问题，系统触发了硬件纠错，纠不过去就 panic 重启。如果没有系统日志，你可能还在怀疑电源、怀疑散热，绕一大圈。

3.2 错误码解码：别只看数字

错误码是硬件工程师的「摩斯密码」。每个错误码背后都对应一个具体的故障场景。但很多人拿到错误码，直接去查手册，查到了就完事了。其实不对。

错误码需要「解码」——不仅要看它是什么，还要看它出现的上下文。

// 一个典型的 PCIe 错误码示例
// 错误码：0x72 (Uncorrectable Error)
// 来源：PCIe AER (Advanced Error Reporting)
// 上下文：发生在 EP 设备 00:1d.0，功能号 3

// 解码步骤：
// 1. 确认错误类型：Uncorrectable -> 不可恢复，必须复位
// 2. 确认错误源：00:1d.0 是根端口下的某个端点
// 3. 确认错误传播路径：是否影响了其他设备

我曾经遇到过一个案例，错误码显示是 PCIe Completion Timeout。按手册说是端点设备响应超时。但我查了半天，端点设备没问题。后来才发现，是根端口的一个电源轨纹波过大，导致链路训练失败。你看，错误码本身没错，但根因在电源上。

3.3 用户报障信息：过滤噪音，提取信号

用户报障信息是最容易获取、也最容易误导人的信息源。为什么？因为用户不是工程师，他们描述问题的方式往往是感性的、不准确的。

比如用户说「机器卡死了」。这个描述太模糊了。是系统完全无响应？还是某个应用卡住？还是网络延迟高？不同的「卡死」对应完全不同的故障方向。

我建议用标准化的报障模板来收集信息：

1. 故障现象：具体描述「发生了什么」
2. 触发条件：做了什么操作后出现的
3. 频率：第一次出现还是复现多次
4. 影响范围：单台设备还是多台设备
5. 时间点：精确到分钟

说白了，用户报障信息是「原材料」，需要你加工成「半成品」。加工的方法就是追问。用户说「死机了」，你就追问「屏幕还亮吗？鼠标能动吗？键盘灯能切换吗？」。问得越细，信息越有价值。

3.4 环境信息：被忽视的关键变量

环境信息是故障信息收集中最容易被忽视的一环。但说实话，很多硬件故障的根因就在环境里。

环境维度	采集内容	典型故障关联
供电	电压、电流、纹波、瞬态	电源不稳导致复位、逻辑错误
温度	环境温度、芯片结温、散热状态	过热导致性能降级、关机
湿度	相对湿度、凝露情况	湿度过高导致短路、漏电
振动	振动频率、幅度、持续时间	连接器松动、焊点开裂
电磁	EMI 强度、附近干扰源	信号完整性恶化、误码

我记得有一次，客户反馈某批次设备在北方冬天频繁故障，在南方就没事。我们一开始怀疑是温度问题，但测试发现设备工作温度范围是合格的。后来查了环境数据才发现，北方冬天供暖后室内湿度极低，静电放电频繁，导致芯片 ESD 损伤。这就是环境信息的价值。

3.5 系统化采集流程：把信息串起来

信息收集不是零散的，而是一个流程。我习惯用「五步采集法」：

1. 锁定时间窗口：确定故障发生的时间范围
2. 拉取系统日志：获取该时间窗口内的所有日志
3. 解码错误码：提取关键错误码并解码
4. 补充用户描述：用用户报障信息验证日志结论
5. 采集环境数据：获取供电、温度、湿度等环境参数

这五步做完，你手里就有了一个完整的故障信息包。后面的分析工作，就是在这个信息包的基础上展开的。

下面这张图是我自己总结的信息采集流程，你可以参考：

3.6 信息归档：让数据可追溯

信息收集完了，不是存个文件夹就完事了。我建议建立标准化的信息归档结构：

故障案例_2024-10-15/
├── 01_日志/
│   ├── dmesg_20241015_1430.log
│   ├── syslog_20241015_1400_1500.log
│   └── bmc_sel_20241015.log
├── 02_错误码/
│   ├── error_code_decode.txt
│   └── pcie_aer_dump.txt
├── 03_用户报障/
│   ├── 报障单_20241015_1435.docx
│   └── 电话录音_20241015_1440.mp3
├── 04_环境数据/
│   ├── 电源纹波_通道1.csv
│   ├── 温度曲线_20241015.csv
│   └── 湿度记录_20241015.csv
└── 05_分析笔记/
    └── 初步分析_20241015_1600.md

为什么要这么细致？因为故障复现可能需要几个月甚至几年后。到时候你还能找到原始数据吗？归档做得好，后续分析事半功倍。

好了，信息收集这部分就讲到这里。记住一句话：信息收集的质量，决定了故障定位的上限。信息不全，再厉害的分析工具也白搭。