2、核心指标定义：升级成功率、失败率、超时率、平均耗时、设备在线率

各位同学，咱们今天聊聊OTA升级里最实在的东西——核心指标。

说实话，我见过不少团队，一上来就搞升级流程、写代码、搭平台。结果上线第一天，老板问“升级效果怎么样？” 所有人都懵了。为什么？因为没有定义好指标。

我个人习惯，做任何系统之前，先把“怎么衡量好坏”想清楚。OTA升级也一样。你连成功率都不知道，怎么优化？

2.1 升级成功率

这个指标最直观。说白了，就是“升级成功的设备数”除以“发起升级的设备总数”。

公式很简单：

升级成功率 = (成功升级的设备数 / 发起升级的设备总数) × 100%

嗯，这里要注意：什么叫“成功”？我遇到过项目里，设备下载完固件但没重启，也算成功。结果呢？实际运行的全是老版本。所以，我建议把“成功”定义为：设备完成下载、校验、写入、重启，并且在新版本下正常上报心跳。

我在项目中遇到过，有些设备网络差，下载到99%断了，重试几次后总算下完。这种算成功吗？算。但你要单独统计“一次成功”和“重试后成功”。这两个数字能帮你判断网络质量。

2.2 升级失败率

失败率和成功率是硬币的两面。但失败率更有价值——因为它告诉你“哪里出了问题”。

我习惯把失败原因分类统计：

• 下载失败：网络超时、服务器不可达、固件包损坏
• 校验失败：MD5/SHA256不匹配，固件被篡改
• 写入失败：Flash空间不足、分区表错误
• 重启失败：新固件启动崩溃、看门狗复位

举个例子。我曾经遇到一个项目，失败率突然从2%飙升到15%。查了半天，发现是CDN节点挂了，导致部分地区下载失败。如果我只盯着总失败率，可能还在怀疑代码有bug。所以，分类统计失败原因，能帮你快速定位问题。

2.3 超时率

这个指标很多人忽略。但我觉得，它比失败率更能反映系统健康度。

什么是超时？就是设备在规定时间内没完成升级。比如你设定升级窗口是2小时，结果设备3小时还没搞定。这就是超时。

超时率怎么算？

超时率 = (超时未完成的设备数 / 发起升级的设备总数) × 100%

你想想看，超时意味着什么？意味着设备长时间处于“升级中”状态。这时候设备可能无法正常使用，用户会投诉。而且，超时设备多了，你的升级队列会堵死。

我建议设置两个阈值：

• 软超时：超过预期时间1.5倍，触发告警，但不停止升级
• 硬超时：超过预期时间3倍，强制回滚或标记为失败

我在项目中遇到过，有些设备因为电池电量低，升级速度特别慢。软超时告警后，我们主动推送了“请充电”的通知，问题就解决了。

2.4 平均耗时

平均耗时，就是所有成功升级的设备，从开始到完成所花时间的平均值。

这个指标有什么用？我告诉你，太有用了。

• 帮你规划升级窗口。如果平均耗时30分钟，你给2小时窗口就够用。
• 帮你发现异常。如果某天平均耗时突然翻倍，说明网络或服务器有问题。
• 帮你优化策略。比如压缩固件包、用差分升级，都能降低平均耗时。

我习惯把平均耗时拆成三段：

阶段	说明	常见瓶颈
下载阶段	从服务器拉取固件	网络带宽、CDN节点
校验+写入阶段	验证固件并写入Flash	Flash速度、CPU性能
重启+验证阶段	重启设备并确认版本	启动时间、应用初始化

你看，这样一拆，你就知道该优化哪一段了。

2.5 设备在线率

这个指标，其实是OTA升级的前提条件。设备不在线，你升级个啥？

设备在线率 = (在线设备数 / 总设备数) × 100%

为什么我要把它放在核心指标里？因为我吃过亏。

有一次，我们推送了一个紧急安全补丁，结果发现只有60%的设备在线。剩下40%的设备要么断电，要么断网，要么在信号盲区。补丁推了等于没推。从那以后，我要求每次升级前，先看设备在线率。低于80%？推迟升级，先想办法唤醒设备。

在线率还能帮你判断升级时机。比如：

• 凌晨2点在线率最低（设备休眠），不适合全量推送
• 上午10点在线率最高，但业务繁忙，也不适合
• 我一般选在下午2点到4点，在线率高且业务相对空闲

好了，这一章就到这里。下一章咱们聊聊“告警阈值怎么设”，我会分享一些我踩过的坑和调优经验。记得动手实践，光看没用。