29、车载系统OTA的监控与告警

OTA升级搞完了，车也推送了，是不是就万事大吉了？

说实话，我最怕听到的一句话就是：“升级都推送了，等着吧。” 等着？等着出问题吗？

车载OTA可不是“发出去就完事”的活。你得盯着它，看着它，一旦不对劲，马上得知道。这就是我们今天要聊的——监控与告警。

升级成功率监控：你的车到底升没升上去？

成功率，这是最核心的指标。我习惯把它拆成两个维度来看：

• 推送成功率：包有没有下发到车端？网络断了？存储满了？
• 安装成功率：车端下载完，安装过程有没有挂掉？

我在项目里遇到过这么个事：推送成功率99.9%，但安装成功率只有85%。你想想看，这意味着什么？每1000台车，有100台卡在安装环节，用户第二天开车发现系统坏了，那投诉电话不得打爆？

嗯，这里要注意：成功率不能只看平均值。平均值会骗人。你得按车型、按版本、按地域去拆。我见过一个项目，整体成功率98%，但某个低配车型只有60%，就是因为那个车型的存储空间刚好卡在临界点。

升级耗时分布：用户等得起吗？

升级耗时，说白了就是用户体验。用户把车停好，点了个“升级”，然后呢？等5分钟？等半小时？

我个人习惯把耗时分成几个区间来统计：

耗时区间	含义	告警阈值
< 5分钟	小补丁，体验极佳	无
5-15分钟	常规升级，可接受	无
15-30分钟	大版本，用户可能不耐烦	关注
> 30分钟	异常，大概率出问题了	立即告警

为什么会有人升级超过30分钟？我排查过几次，发现原因五花八门：

• 车机后台有高负载任务（比如导航在算路）
• 存储碎片化严重，写入速度慢得像蜗牛
• 某个分区挂载异常，重试了好几次

所以，耗时分布图一定要做。我建议用P50、P95、P99三个分位值来看。P50是大多数用户的体验，P99是那1%倒霉蛋的体验——这1%往往就是投诉的来源。

失败原因分类：别只告诉我“失败了”

“升级失败”——这四个字是最没用的信息。你得告诉我为什么失败。

我整理过一套失败原因分类，基本上覆盖了90%的场景：

• 网络类：下载超时、断连、DNS解析失败、证书校验失败
• 存储类：空间不足、分区挂载失败、文件系统损坏
• 校验类：签名校验失败、哈希不匹配、版本号冲突
• 安装类：脚本执行异常、依赖包缺失、回滚失败
• 系统类：内存不足、进程被kill、内核panic
• 用户类：用户取消、用户强制断电、用户操作不当

失败原因分类做好了，你就能快速定位问题。比如某天突然“存储空间不足”的失败暴增，那八成是某个车型的预装应用把空间吃光了。

告警规则与通知：别等用户骂你才知道

监控数据有了，但你不能天天盯着看。你得让系统替你盯着，出事了通知你。

我常用的告警规则：

• 成功率断崖式下跌：比如成功率从98%突然掉到80%，持续5分钟以上
• 某个失败原因暴增：比如“存储空间不足”的失败数突然翻倍
• 升级耗时异常：P99耗时超过30分钟
• 特定车型/版本异常：某个车型的成功率低于90%
• 无数据上报：超过1小时没有任何升级状态上报

通知方式嘛，我建议分级：

级别	触发条件	通知方式
P0（紧急）	成功率<80%，或大量车辆变砖	电话+短信+钉钉@所有人
P1（严重）	成功率<90%，或某个失败原因暴增	短信+钉钉群
P2（警告）	耗时异常，或小范围失败	钉钉群+邮件
P3（通知）	升级完成，或常规统计	邮件日报

具体怎么实现通知？我一般用Webhook。钉钉有群机器人，发个POST请求就行。短信和邮件可以用云服务，比如阿里云的短信服务、SendGrid的邮件API。代码大概长这样：

// 伪代码：发送钉钉告警
function sendDingTalkAlert(message, level) {
  const webhookUrl = "https://oapi.dingtalk.com/robot/send?access_token=xxx";
  const payload = {
    msgtype: "text",
    text: {
      content: `[${level}] OTA告警: ${message}`
    }
  };
  http.post(webhookUrl, payload);
}

// 伪代码：发送短信告警
function sendSmsAlert(phone, message) {
  // 调用阿里云短信API
  aliyun.sms.send({
    phoneNumbers: phone,
    signName: "车载OTA",
    templateCode: "SMS_123456",
    templateParam: { message: message }
  });
}

嗯，这里有个细节：告警消息里一定要带上关键信息。比如“XX车型升级成功率降至85%”，而不是“升级失败”。你想想看，半夜收到一条“升级失败”的短信，你爬起来也不知道该干嘛。

知识体系总览

我把整个监控告警的体系画了张图，方便你理解各个模块之间的关系：

这张图把整个流程串起来了：从车端上报数据，到云端计算指标，再到规则引擎判断要不要告警，最后通过不同渠道通知到人。每个环节都缺一不可。

最后说一句：监控告警系统不是搭完就完事的。你得持续调优。哪些告警是噪音？哪些阈值太敏感？哪些失败原因需要新增分类？这些都是迭代出来的。我自己的习惯是每周复盘一次告警记录，把没用的规则干掉，把漏掉的规则补上。

好了，这一章的内容就到这。监控告警做好了，你就能睡个安稳觉了。

---