📚 课程目录第4章故障分类与模型

4. 故障分类与模型：网络故障、存储故障、校验失败、版本冲突

做OTA升级这么多年，我最大的体会就是：故障不可怕，可怕的是你不知道故障长什么样。很多团队上线前拍胸脯说没问题，结果一升级就翻车，说白了就是没把故障模型搞清楚。

这一章，咱们就把OTA升级里最常见的四类故障掰开揉碎了讲。你想想看，一个升级包从云端下发到设备，中间要经过网络传输、本地存储、完整性校验、版本比对——这四个环节，哪个都可能出幺蛾子。

网络故障是OTA升级里出现频率最高的。我统计过自己经手的项目，大约60%的升级失败都跟网络有关。这不是设备不行，是网络环境本身就不可靠。

关键指标：我建议你在设计阶段就明确三个阈值——连接超时（默认10秒）、下载超时（按包大小动态计算）、重试次数（建议3次）。这三个参数调不好，后面全是坑。

我习惯把网络故障分成两类：瞬时故障和持续故障。瞬时故障比如网络抖动，重试一次就好了；持续故障比如设备离线了，那就得等下次升级窗口。

避坑指南：我曾经遇到过一个项目，设备在弱网环境下反复重试，结果把流量套餐跑光了。后来我加了一个累计重试时间上限——比如30分钟内重试总时间超过5分钟，就直接放弃，等下次升级。

网络下载完了，你以为就安全了？存储故障才是真正的隐形杀手。我记得有一次，升级包下载校验都通过了，结果写入Flash的时候突然断电，设备直接变砖。

我一般把存储故障分为可预测和不可预测两类。空间不足是可预测的，升级前检查一下就行；坏块和写入中断是不可预测的，得靠机制兜底。

警告：千万不要在升级前只检查一次剩余空间。我见过一个案例，设备升级前空间够，但升级过程中其他进程写入了日志，导致空间不够——写入过程中也要做空间检查。

校验失败，说白了就是数据在传输或存储过程中被篡改了。我刚开始做OTA时觉得校验就是个形式，直到有一次生产环境出了严重事故——升级包在CDN节点被污染，几千台设备刷了错误固件。

我建议至少做三层校验：

核心原则：校验失败必须立即停止升级，并回滚到上一个可用版本。不要尝试重试，因为校验失败说明数据已经不可信了。

个人经验：我曾经遇到一个奇葩问题——哈希校验偶尔失败，但重新下载就好了。查了很久才发现是内存校验和硬件校验冲突。后来我加了一个校验缓存，同一个文件只校验一次，问题就解决了。

版本冲突，嗯，这个坑我踩过不止一次。你以为设备当前版本是V2.0，结果它其实是V1.8，然后你给它推送了V2.0到V3.0的差分包——直接刷成砖。

我习惯用版本依赖图来管理版本关系。每个版本都记录它允许升级的来源版本列表和允许回滚的目标版本列表。

关键设计：升级前必须做版本兼容性矩阵检查。我见过最惨的案例是，设备从V1.0直接升级到V5.0，中间跳了4个大版本，结果新版本的Flash布局跟旧版本完全不兼容——分区表都变了。

下面这张图是我自己总结的故障分类模型，每次做OTA方案设计我都会拿出来对照一遍。

实际排查的时候，我建议按这个顺序来：

注意：不要一上来就怀疑版本冲突。我见过有人排查了三天版本问题，最后发现是网线松了——从最简单的开始排查。