3、恢复策略总览：恢复策略分类、恢复时间目标(RTO)、恢复点目标(RPO)
聊到故障恢复，很多人第一反应就是「系统挂了，赶紧重启」。但说实话，在QNX和Android融合的系统里，事情远没那么简单。你想想看，一个负责仪表盘，一个负责娱乐中控，两个系统同时崩溃的概率虽然不高，但一旦发生，后果可能是致命的。
所以，我们需要一套清晰的恢复策略。这一章，我就带大家梳理一下恢复策略的分类，以及两个核心指标——RTO和RPO。我个人习惯，在开始设计任何恢复方案之前，先把这两个指标定死，否则后面全是扯皮。
3.1 恢复策略分类
根据我多年在融合系统上踩坑的经验，恢复策略大致可以分为三类。每一类都有它的适用场景和代价。
| 分类 | 核心思路 | 典型场景 | 代价 |
|---|---|---|---|
| 快速重启 | 不保留现场，直接冷启动或热重启 | Android应用无响应、QNX进程死锁 | 低，但丢失所有未保存数据 |
| 状态保留恢复 | 保存关键状态，重启后恢复到最近检查点 | 媒体播放中断、导航路径丢失 | 中等，需要额外存储和序列化开销 |
| 无缝热切换 | 主备双系统或双进程，故障时零切换 | 仪表盘显示、安全关键控制 | 高，硬件和软件冗余成本大 |
嗯，这里要注意，不是所有场景都需要无缝热切换。我曾经在一个项目中，客户要求所有模块都做双备份，结果成本翻了一倍，最后发现大部分模块其实快速重启就够了。所以，分类的关键在于——搞清楚你的系统里，哪些是「命根子」，哪些是「锦上添花」。
3.2 恢复时间目标（RTO）
RTO，说白了就是「系统挂了之后，你能容忍它挂多久」。这个指标直接决定了你恢复策略的激进程度。
核心公式：RTO = 故障检测时间 + 决策时间 + 恢复执行时间
我一般把RTO分成三个等级：
- 等级一（< 100ms）： 适用于仪表盘、ADAS等安全关键模块。必须用无缝热切换，否则驾驶员会直接感受到异常。
- 等级二（100ms - 2s）： 适用于音频流、视频播放等用户体验敏感模块。状态保留恢复基本够用，用户可能感觉到短暂卡顿，但不会中断。
- 等级三（> 2s）： 适用于非核心应用，比如天气、新闻推送。快速重启完全OK，用户甚至可能没注意到它重启过。
我记得有一次，我们在做Android Auto的恢复测试，发现RTO总是超标。排查了半天，发现是QNX侧的健康监控进程在检测到Android挂死后，等待了500ms才发出恢复指令。这500ms白白浪费了。后来我们把检测周期从500ms缩短到100ms，RTO一下子就达标了。
避坑指南：我曾经犯过一个错误——只计算了恢复执行时间，忽略了故障检测和决策时间。结果RTO指标在实验室里看着很漂亮，一上车实测就崩了。记住，RTO是一个端到端的指标，任何一个环节的延迟都会拖后腿。
3.3 恢复点目标（RPO）
RPO关心的是「你能容忍丢多少数据」。这个指标在融合系统里特别微妙，因为QNX和Android的数据模型完全不同。
QNX这边，数据通常是实时的传感器值、车辆状态，丢了就丢了，下一帧马上更新。所以RPO可以很大，甚至允许丢几帧数据。但Android这边，用户可能正在编辑导航路线、设置EQ均衡器，这些数据丢了，用户会非常恼火。
| 子系统 | 典型数据 | 推荐RPO | 恢复方式 |
|---|---|---|---|
| QNX安全域 | 车速、转向角、刹车状态 | ≤ 1帧（约20ms） | 实时重传，不持久化 |
| Android用户域 | 导航路径、蓝牙配对、音效设置 | ≤ 5秒 | 定期写检查点到共享存储 |
| 媒体缓存 | 正在播放的歌曲、播客进度 | ≤ 30秒 | 内存缓存 + 定时落盘 |
你可能会问，为什么Android用户域的RPO要定在5秒？其实这个数字是我从实际用户行为里反推出来的。用户调整一个设置，平均操作时间是3-5秒。如果RPO大于5秒，用户可能会发现「刚才明明调好了，怎么又变回去了」。嗯，这就是用户体验的底线。
3.4 RTO与RPO的权衡
RTO和RPO不是独立的，它们是一对冤家。你想想看，要想RTO小，就得提前准备好恢复资源，这通常意味着要频繁写检查点，RPO自然就小了。反过来，如果你能接受较大的RPO，那恢复策略就可以简单粗暴，RTO也能做得更小。
我习惯用一个简单的矩阵来帮团队做决策：
你看，左上角是「快速重启」，适合那些丢了也不心疼的数据。右下角是「无缝热切换」，适合那些一秒都不能丢的场景。而中间区域，就是我们最常打交道的地方——需要做状态保留恢复。
我的经验：在项目初期，不要追求极致的RTO和RPO。先定一个「够用」的基线，比如RTO 500ms、RPO 2s。等系统稳定了，再针对瓶颈模块做优化。我曾经见过一个团队，一上来就要求RTO 50ms，结果折腾了三个月，连基础框架都没搭起来。
3.5 恢复策略选择流程
最后，我分享一下我自己在项目中常用的选择流程。说白了，就是一套「问自己几个问题」的决策树：
- 这个模块挂了，会死人吗？ → 是 → 无缝热切换（RTO < 50ms，RPO ≈ 0）
- 用户会立刻发现吗？ → 是 → 状态保留恢复（RTO < 1s，RPO < 5s）
- 数据丢了用户会骂人吗？ → 是 → 状态保留恢复（RTO可以放宽，RPO必须小）
- 以上都不是？ → 快速重启（RTO和RPO都放宽）
嗯，这套流程看起来简单，但实际执行起来，最难的是第一步。因为很多产品经理会说「这个功能很重要，用户不能等」。这时候，我一般会反问一句：「如果这个功能恢复需要多花100块钱的硬件成本，你愿意吗？」——问题一下子就清晰了。
好了，这一章的内容就到这里。记住，恢复策略不是越高级越好，而是越匹配你的业务场景越好。RTO和RPO这两个数字，一定要写在设计文档的第一页，让所有人都能看到。