网硕互联帮助中心前两年做一个野外环境监测的项目，设备装在偏远山区的铁塔上，靠太阳能板和蓄电池供电，通过无线链路和网关通信。升级固件是刚需——修bug、调参数、加功能，不可能每次都派人爬塔。我们的方案是网关下发固件包，设备端分片接收、写入外部存储、校验、最后搬运到运行区重启。
问题出在一次批量升级。二十多台设备同时推包，推到一半，天气突变，网关所在机房那边网络抖动，链路断了将近四十秒。恢复之后，有七台设备彻底失联——不是重启失败，是连引导程序都进不去了。派人上去换板子，发现外部存储里写进去的固件包是半截的，引导程序校验失败，又不肯回退到旧固件，就卡死在那了。
那次之后我重新审视了整个升级流程的恢复逻辑。下面这些内容，是踩了坑之后一点点抠出来的，公开资料里很少系统讲这些。
先搞清楚“中断”到底断在哪里
很多人一上来就思考“断点续传”，但连中断发生在哪个阶段都没分清，恢复策略就无从谈起。
固件升级的链路，粗略拆成四段：
第一段，网关到设备的传输链路。这段断了，设备可能只收到半个包。
第二段，设备内部从通信缓冲区到外部存储的写入。这段如果掉电，外部存储里可能写了一半。
第三段，从外部存储搬运到运行区。这段掉电，运行区就是半新半旧。
第四段，搬运完成后的校验和重启。这段掉电，设备可能带着新固件起来，也可能带着坏固件起来。
这四段里，第一段和第二段的中断是可以恢复的——因为旧固件还在运行区完好无损，设备还能正常启动、正常通信，只是升级任务没完成。第三段和第四段的中断才是致命的——运行区被破坏了，设备可能再也起不来。
所以恢复设计的第一个决策点：把“可恢复”和“不可恢复”的边
评论前必须登录！
注册