3. 升级回滚需求分析
在 rootfs 升级回滚的工程落地中，需求分析不是“写几条功能点”，而是把业务目标翻译成可验证的系统约束。升级与回滚本质上是一次对设备根文件系统的“在线替换”，它同时触碰存储布局、启动链路、业务进程、网络通道和运维体系。若需求边界不清，后续设计就会出现“能升级但不敢升、能回滚但回不去、能回滚但业务已中断”的典型问题。本节围绕六个核心维度展开：业务连续性、原子性、可靠性、可测试性、可观测性与失败恢复目标，并给出可落地的需求条目与验收口径。
一、核心原理：六个维度构成一个约束闭环
这六个维度并非并列清单，而是相互制约的闭环。业务连续性决定“允许中断多久”，原子性决定“切换是否可逆”，可靠性决定“异常掉电后是否仍可启动”，可测试性决定“能否在实验室复现现场故障”，可观测性决定“失败时能否定位到具体阶段”，失败恢复目标则把上述约束量化为可验收的指标。它们共同约束 rootfs 的分区布局、启动选择机制和升级代理行为。
二、方法流程：把需求翻译成可验收条目
需求分析应遵循“场景—约束—指标—验证”的路径。首先枚举升级场景：正常升级、升级中断电、升级后业务异常、回滚中断电、回滚后版本不一致。然后为每个场景定义约束与指标，最后落到测试用例和监控项。以下清单可直接作为需求评审的检查表。
| 维度 | 需求条目 | 量化指标 | 验证方式 |
|---|---|---|---|
| 业务连续性 | 升级期间关键服务不中断或短暂中断 | 中断 ≤ 30s，数据不丢 | 业务探针 + 压测 |
| 原子性 | 切换要么成功要么保持原版本 | 无中间态可启动 | 掉电注入 + 启动验证 |
| 可靠性 | 镜像校验、签名验证、坏块处理 | 校验失败拒绝切换 | 篡改镜像测试 |
| 可测试性 | 支持故障注入与自动化回归 | 用例覆盖 ≥ 90% 分支 | CI 流水线 |
| 可观测性 | 记录阶段、版本、槽位、错误码 | 日志可追溯至具体阶段 | 日志审计 |
| 失败恢复 | 自动回滚与人工回滚双通道 | 回滚成功率 ≥ 99.9% | 故障演练 |
三、案例/场景：一次“升级成功但业务失败”的复盘
某网关设备升级后，rootfs 切换成功，但业务进程因新版本依赖库缺失而反复重启。由于升级代理只校验了镜像完整性，没有校验业务健康状态，系统停留在新版本，导致服务不可用。复盘发现三个需求缺失：一是缺少“升级后健康检查”条目；二是缺少“自动回滚触发条件”；三是缺少“回滚后版本一致性校验”。修正后的需求增加了如下约束：升级完成后必须在 60 秒内通过业务探针，否则自动回滚；回滚后必须校验旧版本槽位可启动且业务探针通过。
# 升级后健康检查与自动回滚伪代码
upgrade_agent --slot B --image rootfs_v2.img
if ! verify_signature rootfs_v2.img; then
log "signature failed"; exit 1
fi
set_boot_slot B
reboot
# 启动后由 health-check 服务执行
if ! check_business_probe --timeout 60; then
log "business probe failed, rollback"
set_boot_slot A
reboot
fi
常见误区：把“升级成功”等同于“业务可用”。rootfs 切换成功只代表文件系统可启动，不代表应用依赖、配置、数据迁移全部正确。需求分析必须把业务健康检查纳入升级闭环，否则回滚机制形同虚设。
四、误区/复盘：失败恢复目标必须可量化
失败恢复目标常被写成“尽快恢复”，这是不可验收的。应明确 RTO（恢复时间目标）和 RPO（恢复点目标）。对于 rootfs 升级，RTO 指从检测到失败到业务恢复的时间，RPO 指允许丢失的数据量。若业务数据在独立分区，RPO 可接近 0；若配置随 rootfs 一起切换，则需定义配置回滚策略。建议在需求阶段就确定：自动回滚触发条件、回滚超时时间、回滚失败后的降级路径（如进入维护模式并上报云端）。
落地建议：将六维需求映射为升级代理的状态机与日志字段。例如状态包括 IDLE、DOWNLOADING、VERIFYING、SWITCHING、HEALTH_CHECK、ROLLBACK、FAILED；日志字段包括 slot、version、stage、error_code、timestamp。这样可观测性与可测试性自然落地，失败恢复目标也能通过日志统计回滚成功率。
综上，rootfs 升级回滚的需求分析应围绕业务连续性、原子性、可靠性、可测试性、可观测性与失败恢复目标形成闭环。只有把每条需求量化到指标、验证到用例、观测到日志，后续的分区设计、启动选择与升级代理实现才有稳定的验收基线。