一、发散诊断概述
各位工程师朋友，大家好。我是老张，在硬件系统这个行当里摸爬滚打了十几年。今天咱们开始聊《发散诊断与排除实战》这门课。第一讲，我想先聊聊什么是发散诊断，以及它到底能帮我们解决什么问题。
说实话，我刚入行那会儿，遇到故障第一反应就是翻手册、查代码、看波形。一条路走到黑，经常折腾半天才发现方向错了。后来慢慢悟出一个道理：故障排除，很多时候不是技术问题，而是思路问题。
什么是发散诊断
发散诊断，说白了就是不在一棵树上吊死。它是一种从多个角度、多个维度去分析故障根源的方法。
我习惯把它比作侦探破案。一个案子，线索可能藏在现场、证人口供、监控录像、甚至嫌疑人的社交账号里。你只盯着一个方向，大概率会漏掉关键信息。故障诊断也一样——
- 横向发散：从不同模块、不同子系统找关联
- 纵向发散：从底层硬件到上层软件，逐层排查
- 逆向发散：从故障现象反推可能的原因
- 类比发散：借鉴类似问题的解决经验
举个例子。有一次我遇到一个嵌入式系统偶尔死机的问题。常规思路是查电源、查时钟、查内存。但我当时多问了自己一句：「死机前系统在做什么？」结果发现，每次死机都发生在网络数据包到达的瞬间。顺着这个线索，最终定位到是网卡中断处理函数里有一个临界区没保护好。你看，如果我只盯着电源纹波测，可能到现在还在加班。
发散思维在故障排除中的作用
为什么发散思维这么重要？我总结了三点：
- 打破思维定势——我们做硬件久了，容易形成「经验主义」。比如一看到系统重启就怀疑看门狗，一看到数据错乱就怀疑内存。发散思维逼着你跳出舒适区。
- 提高排查效率——你想想看，如果同时列出5个可能原因，并行验证，是不是比一个一个试快得多？
- 发现隐藏关联——很多故障不是单一原因导致的。比如温度升高导致时钟漂移，时钟漂移导致通信超时，通信超时触发软件复位。这种链条，线性思维很难抓到。
核心观点：发散诊断不是让你瞎猜，而是让你有章法地扩大搜索范围。就像雷达扫描，先粗扫再精扫。
诊断流程总览
好，理论说完了，咱们看看实际操作。我一般把发散诊断分成五个步骤：
| 步骤 | 名称 | 做什么 | 我的经验 |
|---|---|---|---|
| 1 | 现象描述 | 准确记录故障现象，包括频率、条件、环境 | 我曾经让实习生写故障报告，他写「系统偶尔卡顿」——这等于没写。要具体到「每30秒卡顿2秒，CPU占用率从10%飙到95%」 |
| 2 | 假设生成 | 列出所有可能的原因，不设限 | 这个阶段我鼓励团队「脑暴」，哪怕听起来离谱的也先记下来 |
| 3 | 优先级排序 | 按概率和验证成本排序 | 先测最容易验证的，比如电源电压、日志文件 |
| 4 | 验证执行 | 逐个验证假设，记录结果 | 注意：一次只改一个变量，否则你分不清是哪个改动起了作用 |
| 5 | 根因确认 | 确认根本原因，并验证修复方案 | 修复后要跑压力测试，确保问题不再复现 |
嗯，这里要注意：流程不是死的。有时候你验证到第三步，突然发现一个新线索，那就跳回第二步重新生成假设。诊断本身就是一个迭代的过程。
小技巧：我习惯在工位白板上画一个「故障树」。把故障现象写在最上面，下面分叉列出所有可能原因。每验证一个，就划掉一个。视觉化之后，思路会清晰很多。
知识体系总览
为了让大家对本章内容有个整体印象，我画了一张图：
避坑指南：我曾经犯过一个低级错误——在假设生成阶段就急着否定某些可能性。「这不可能，肯定是别的问题」——这种想法会让你错过真正的根因。记住：在验证之前，所有假设都是平等的。
好了，这一讲就到这里。发散诊断不是玄学，它是一套可以训练的方法论。下一讲我们会深入聊聊如何建立自己的「故障假设库」，以及一些实用的思维工具。咱们下次见。