一次 OTA 打满出口带宽的车联网平台，问题出在升级批次而不是在线数

十万辆车，夜间发布窗口四小时，OTA 差分包 1.2GB，按 85% 激活率算，这批车的有效目标是 8.5 万台，要推下去的总量是 8.5 万 × 1.2GB ≈ 102TB。把这 102TB 压缩进 14400 秒，平均出网吞吐就是 102000GB × 8 ÷ 14400 ≈ 57Gbps。多数 TSP 平台在采购阶段报的出口带宽是 10Gbps 到 20Gbps 这个量级，两者差了三到五倍。再看瞬时：如果同时下载的车占在线车的 5%，那就是 4250 路并发下载，车机不限速时单连接跑到几十兆，几千路叠加起来峰值轻松破百 G。也正因为这一层算术往往要到第一次大版本推送时才被看见，很多团队把注意力放错了地方——他们盯着"十万辆车长连接能不能撑住"（连接层另算，那是另一套账），却没人填"同时下载比"这一格。

看起来像连接资源不够，实际上是批次参数没设计：真正决定出口压力的是"并发比 × 包体大小 ÷ 发布窗口"，不是在线终端数。

加速升级的性价比排序非常明确：先把包体降下来，再把窗口拉长，最后才谈论加带宽和加服务器。

重试不是收尾工作，是第二次排队高峰：退避没做抖动的批次，重试那一波能把源站打死，很多"莫名其妙"的二次故障都发生在这里。

差分不是免费午餐：服务端省下来的带宽，会以 CPU、存储和随机读的形式重新还回来。

弱网车辆不改变流量总量，但会把并发拖长：隧道、地库和跨境朋友圈越多的车队，长尾占用的资源占比越高。

先把账算出来：峰值带宽 = 车队规模 × 激活率 × 并发比 × 包体 ÷ 窗口

把上面那笔账拆成公式，一共四个乘数和一个除数：峰值出网带宽 ≈ 车队规模 × 激活率 × 并发比 × 包体大小 ÷ 有效下载时长。这里的"有效下载时长"不是窗口长度本身，而是单台车被允许完成下载的时间。平台方真正能改的、且改动成本最低的，是后面三项。

用同一组数演示一下三者怎么互相牵制。目标 8.5 万台、包体 1.2GB、窗口 14400 秒，要按期推完就必须维持 57Gbps 的平均吞吐。如果服务端把单连接限速设成 8Mbps，同时下载上限 4250 路，那么瞬时上限只有 34Gbps，低于 57Gbps 的均值要求——结果是推不完。102TB 除以 34Gbps 需要约 24000 秒，也就是 6.7 个小时，四小时窗口直接被拉长到接近七小时。要么抬高并发比，要么放宽单连接限速，要么延长窗口，这三个旋钮必须同时满足那个总量约束，缺一个就还债。

把包体换成全量包，情况会难看得多。同样 8.5 万台，如果推的是 6GB 的完整镜像，总量变成 510TB，四小时窗口内的均值要求是 283Gbps。这个数字基本说明一件事：单一夜间窗口 + 全量包 + 十万级车队，三者不可能同时成立。工程上的解法就只能回到差分——让绝大多数车只下载变化的那几百兆到 1GB 多。

这笔账的价值不在于算准，而在于它能在立项阶段暴露矛盾。很多平台把"我们带宽不够"当成运维故障事后复盘，其实它在选包体策略、定灰度节奏的那天就已经定下来了。建议的做法是把这个公式做成一个内部小工具：输入车队规模、目标版本、可用窗口，输出所需带宽与所需时长两个值，每次发版前填一遍。填完发现推不动，就把工时花在拆批次上，而不是连夜去加带宽——因为夜间四小时的临时带宽，计费往往比你想的贵得多（具体计费口径和单价按运营商与机房实时报价为准）。

并发比才是那个没人填的参数：它到底由什么决定

连估算都不做的重灾区，就是这个"同时下载百分比"。需求文档里通常会写"十万辆车在线"，但在线和正在下载完全是两件事：一台停在写字楼地下车位的车，可能保持着心跳连接，却一次完整的 1.2GB 都没拉完过。

车辆"在线"不等于车辆"在下载"

在线是连接层的状态，"正在下载"是业务层的状态。一台车的下载行为要同时满足：点火或唤醒、蜂窝网络信号可用、电量或油量在阈值之上、用户没有主动取消、服务端发放了下载许可。这五个条件每一个都会吃掉一批车。经验上，同时处于"正在拉取数据"状态的比例通常远低于在线率，常见的取值区间可以按 3%–8% 作为初始假设，再按实测调整（不同车队差异很大，这个数字只能作为起步值，不能作为承诺值）。

上线节律：车辆不是均匀分布的，是成团成团的

乘用车的联网高峰集中在早晚通勤、午休和夜间充电时段；商用车队更极端，白班收车之后一起上线，凌晨一起熄火。港口、矿区这类封闭场景的作业车辆，上线窗口被班次切得很整齐。也就是说单位时间的到达密度高度不均，"平均并发比"会明显低估短时峰值。做容量规划时应该用 15 分钟粒度甚至 5 分钟粒度的到达曲线去看，而不是拿全天平均值去乘。

网络条件的下限决定了长尾有多长

地库无信号、隧道断连、跨境行驶时的漫游切换，都会让同一批下单的车的完成时间散得很开。尾部那 5% 的车占用的资源时间往往远超它们占的流量比例——它们不断中断、不断补传、不断重试。设计并发比时必须给这批车留出余量，或者在客户端策略上做取舍：低于某个信号门限就干脆不开始下载，而不是开始之后反复失败。规避式比重试式便宜得多。

服务端才是并发比的最终裁判

最后这一点容易被忽略：并发比不是客户端想多少就多少，而是服务端发多少张"下载门票"。真正靠谱的做法是在服务端做许可发放——按当前出口使用率动态调整允许同时下载的车数，超出的车排队等下一轮。这样一来并发比从"观测结果"变成了"可控参数"，高峰期이터也能被压住。跨地区车队在这一层还要注意一点：分区发布需符合当地监管要求，以当地规则为准，某些地区的数据落地要求会影响你能否把包推到本地节点。

全量包和差分包，服务端压力完全不同

差分升级（增量升级）在客户端看起来只是"包更小了"，但服务端的开销结构完全变了。全量包是"一次压缩、长期静态服务"，差分包是"每次发布都要重算、版本维度还会组合膨胀"。

先看生成环节。做差分要把旧版本镜像和新版本镜像同时读进来求差异，常见的开源工具如 bsdiff、xdelta、hdiffpatch 之类都在做同一件事。它的资源消耗有个特点：内存占用通常是包体大小的数倍（经验区间按 3–5 倍准备比较稳，具体随算法与参数变化），而且这是 CPU 密集 + 大内存 + 大量顺序读的组合。一个 6GB 的全量镜像做差分，单任务跑起来就是几十 GB 内存的事情，多任务并行时内存是最先告警的资源，不是 CPU。这一层的部署建议很直接：差分生成单独跑在一批高内存机器或大内存实例上，不要和分发源站混布，避免生成任务抢走热文件的页缓存。

再说存储与 IO。差分是"版本对"，不是"版本"。如果你要支持从任意历史版本跳到最新，需要生成的差分包数量是 当前版本数 × 目标可达版本 的组合。车辆场景更麻烦，因为还有车型、硬件批次、区域变体这些维度，组合数量乘起来非常吓人。工程上普遍的做法是只保留最近 K 个版本的差分结果（K 常见取 3–5），更老的车先跳到一个中间版本、再跳到最新，或者直接对特定低占比的老版本走全量包兜底。这个"兜底比例"要在包体设计阶段就定下来，因为它直接影响你要不要预留一大块全量下载带宽。

随机读是第三个坑。CDN 和边缘节点的对象缓存对"热大文件"很友好，但当你有成百上千个不同版本对的差分包时，请求的分散度会急剧上升，回源随机读的比例抬高。源站磁盘如果是 HDD 机械盘，这一层会先塌：IOPS 打满、平均响应从毫秒级涨到秒级、然后连锁拖慢所有请求。分发源站用 SSD/NVMe 基本是必选项，或者干脆把包体全部托管到对象存储上，让 CDN 从对象存储回源，由对象存储承担随机读。

还有一个取值判断：差分不是永远划算。如果两次版本之间改动面很大（比如底层系统大版本跃迁、文件系统重排），差分包可能只比全量包小一点点，但生成成本高得多。给的建议是每次发版前先算"差分率"，差分包 / 全量包如果超过某个阈值（常见的判断线在 40%–60% 之间，视业务容忍度定），就干脆走全量，不要为了省那点流量把源站 CPU 拖死。

失败重试为什么会变成第二波洪峰：退避与抖动怎么设计

一个典型的夜间批次是这样的：00:00 开始发放下载许可，00:05 有 4000 台车同时开始拉包，平台出口水位平稳爬升；00:35 一部分车因为隧道断网、WiFi 切换、服务端某台缓存节点抖动而失败。如果客户端的失败处理是"等 60 秒重试，最多 3 次"，那么这 4000 台车里的失败者会在 00:36 附近一起重来。第二波就这么出现了，而且它往往比第一波更尖——因为第一批失败的车往往是网络最差的车，它们失败次数最多、重试次数最密。

退避策略的参数其实就四个：首次重试延迟、倍数、抖动幅度、最大上限。给一组可以作为起步值参考的参数（经验区间，需要按实测收敛）：首次延迟随机化到 0–300 秒之间的某个点，倍数取 2，抖动幅度在 ±20%–30%，单次最大退避上限设在 30–60 分钟。抖动的目的是把重试在时间轴上摊开——如果不加抖动，无论退避多久，重试都会是一根针而不是一片低矮的丘陵。

更有价值的做法是让服务端参与节奏控制。HTTP 的 Retry-After 响应头就是为这件事准备的：服务端发现自己压力大、或者某台缓存节点刚重启，就在响应里告诉车机"X 秒以后再来"。这个机制比单纯依赖客户端策略好，因为服务端能看到全局水位，客户端只能看到自己这一台车。另外要给重试设置"跨窗口出口"：重试超过 N 次还没成功的车，不要死磕到天亮，直接放弃本夜批次，登记到次日队列里。车机不是手机，用户在意的从来不是"这一晚必须装完"。

还要区分失败类型，别把它们当成同一种现象处理。HTTP 4xx（令牌过期、签名不通过、包不存在）是逻辑错误，重试一万次也不会成功，应该立即失败并上报；5xx 和服务端限速响应才值得退避重试；网络层超时则要结合信号门限判断——信号低于某个阈值时，退避多久都没意义，应该等信号恢复事件驱动再拉。把这三类拆开，重试的总量通常能砍掉相当一部分。

断点续传与范围请求：弱网车辆把窗口拉长之后发生了什么

Range 请求（HTTP 范围请求）支持断点续传，这是常识。但它对批次设计的影响经常被算漏：它不改变流量总量，却显著改变"每路连接占用资源的时长"。

看一组假设：一台信号良好的车，1.2GB 拉 15 分钟就完事，它占一个连接 15 分钟；一台在省界高速上来回穿隧道的车，可能拉 200MB 就断一次，一个晚上断 8 次，最终耗了 3 个多小时才凑完。后者的总流量和前者完全一样，但它占用的并发槽位时间是前者的十几倍。等比例的后果是：为了让长尾车辆也能在窗口内推完，你必须把并发上限设得比"理想情况估算值"更高，或者接受完成率不达标。

这也是为什么分片粒度（chunk size）值得单独调。常见的起步区间可以取 4MB–16MB，实际取值要在"重传成本"和"元数据/IO 次数"之间权衡：粒度太小，每次中断虽然重传少，但请求数暴涨，源站和 CDN 的请求 QPS 压力、签名计算次数、哈希验证次数同步上升；粒度太大，一次中断就白拉几十兆，弱网车永远追不上。建议从 8MB 附近起步，观察实际中断分布再调，不要一次性调到极端。

比整包续传更好的是分片级校验与补传：把包切成片，每片独立哈希，车机下载完先本地校验，坏片重拉，好片保留。这样一次中断的代价只是一条坏片子不是一个包。代价是服务端要维护一张片级哈希表，包体越大、版本越多，这张表的元数据条目和存储开销就越可观，老版本的元数据要定期归档清理。

断点续传对缓存命中率也有副作用。一个整包下载在 CDN 上是一路 Range 顺序读，而大量 Range 跳跃请求会让缓存把同一个大文件切成很多段分别回源，首次请求的回源压力比整顺序下载更高。解决思路是发布前对热点包做预热处理，让边缘节点在批次正式开始之前就把内容拉到本地，批次一开始的请求全部命中缓存，源站只承担冷启动那部分。

关键参数与资源影响对照

下面这张表把本篇提到的核心参数放在一起，方便发版前逐项核对。所有取值都按"示例 / 经验区间"理解，实际必须结合自己的车队构成、车联网卡运营商和机型实测确认。

分发架构该往边缘推到哪一层：源站、区域缓存与边缘节点的责任划分

十万级车队的 OTA，靠一台源站硬扛是不现实的，但也不是所有东西都能往边缘扔。划分责任的标准其实就一条：能不能在不识别车辆身份的前提下把内容推到离用户最近的地方。

包体本身是可以完全无状态分发的。它就是一个大对象，鉴权可以前置到 URL 签名或短时令牌，之后由 CDN 或自建的边缘缓存节点承担全部字节流量。这一层要解决的是：地理覆盖（车流分布在哪几个省、哪几个国家）、单节点容量（热点季节是否够用）、回源策略（Miss 时的回源是否会打穿源站）。

版本清单（manifest）则不同。它是按车架号、车型、当前版本、区域策略生成的，个性化程度高，缓存命中率天生就低。好消息是它很小，一次几十 KB 到几百 KB；坏消息是它的 QPS 高——8.5 万台车每台每 15 分钟查一次，就是每秒几百次的稳定请求，批次开始时还会翻几倍。这一层必须单独部署、单独扩容，通常是无状态的应用服务 + 缓存数据库，不能和大文件分发挤在同一条链路上。

再往上是区域缓存。它存在的意义是把一个大区的回源收敛到一跳，同时给你一个"中间的、可观测的水位"。自建的话，节点选址要考虑车队密度和骨干落地点：华南、华东、华北这类车流密集区通常需要各自独立的节点，跨境车队多的业务再额外看中国香港等出海节点（具体节点可用性、延迟与线路质量需以运营商与机房实测为准）。

到了比选阶段，源站和节点的带宽端口、内存与 CPU 组合，比"买几台机器"更值得花时间。像一万网络这类服务商，通常会被拿来做大带宽与多节点方案的配置比选对象：华南/华东/华北/中国香港/海外多节点可选，BGP 多线 + CN2 GIA 回国线路作为跨境回源时的备选项，源站侧偏 CPU 与内存的可选裸金属（例如 E5-2698v4×2 双路配置 ¥3999 起），轻量的一万云 ¥25 起，具体报价一律以官网实时报价为准，海外非明示节点的月租通常写需询价。把这类配置和"差分生成需要多大内存""源站需要多少上行端口"绑在一起比，才知道该付哪一份钱。

签名校验、版本台账与回滚：服务端 CPU 与存储的另一笔开销

带宽账算完之后，还有一笔常被漏掉的账：包体之外的数据面开销。

包体签名通常是一次性的——每个版本的每个差分包签一次，证书链和私钥管理走离线流程，这个不贵。贵的是每一份个性化 manifest 的实时签发。如果设计成每台车每次查询都由服务端用私钥签一次，8.5 万台车 × 每晚几十次轮询，就是天文数字的签名运算。常见的做法是给 manifest 加短有效期（比如几分钟到几十分钟），在这段时间内命中缓存或用对称密钥签发，把非对称签名的频率压下来。这个有效期的长短直接影响两件事：包被劫持后的风险窗口，以及签名 CPU 的消耗曲线。安全策略上这是一个需要和安全团队提前对齐的参数，不要由平台擅自定。

版本台账是第二笔。每辆车当前装的是什么版本、上一次成功上报是什么时候、有没有正在进行的下载任务、失败了几次——这些都要写库。一个十万级车队的夜间批次，状态上报的写入量通常比包体字节数更考验数据库：高频小写入、大量热点行更新（同一批次同一车型的状态行会被反复撞）、还要支持运营侧的实时看板聚合查询。典型的解法是把"实时状态"和"历史流水"分开：流水表按时间分区只写不改，实时状态表做行级合并或使用缓存层吸收写放大。

回滚的准备更现实。多数现代车机采用 A/B 分区设计，升级失败自动回退到旧分区，这种情况下服务端几乎不需要下发回滚包，只需要把版本号台账改回旧版本、并把这台车从本批次里摘出去。代价是存储：A/B 分区意味着车端要留一个完整的旧版本空间，某些存储吃紧的老机型做不到，这时就得依赖服务端下发回滚包——那就意味着你要为一个"万一用不上"的场景保留一整套旧包体存储空间。这笔存储要不要留、留多久，是发版制度要定的事，不是运维能临时决定的。还有一个细节：回滚也走同样的分发链路，如果没有独立的带宽配额，真正出问题时你会发现回滚流量和业务流量、回滚批次和下一批次在抢同一条出口。

批次参数里最容易拍脑袋的五个数字

坑一：拿"在线数"当"下载数"做容量规划。为什么坑：在线率是连接层的指标，下载是边缘侧的字节流，两者中间的转化率受限于网络条件、发放许可、车机电量等多个环节，差一个数量级很正常。怎么判断：把历史批次的实际"同时下载连接数"曲线调出来，除以当时的在线数，得到的比值——如果是 3% 上下，那你按 30% 估的设计肯定错。怎么避：以历史比值为基线，按车队构成分层（乘用车 / 商用车 / 工程车辆分开估），再按境内外不同运营商的实际网络条件给不同折扣。

坑二：差分生成和分发源站混布。为什么坑：差分生成是 CPU 密集 + 大内存 + 大量顺序读的任务，它会挤掉源站热对象的页缓存、抢占磁盘带宽，结果是"这边在算包、那边下载变慢"。怎么判断：发布批次开始时如果源站响应时间出现台阶式上升，而 CPU 与内存双双接近饱和，基本就是它。怎么避：生成任务独立部署，并且避开分发高峰期执行——理想状态是白天上班时间把差分包算完、预热到位，夜间窗口只做纯分发。

坑三：重试不设上限、也不区分失败类型。为什么坑：4xx 逻辑错误重试没意义却占了重试额度，网络层断连无限重试会形成不衰减的后台流量，平台的出口在白天同样被这些僵尸请求消耗。怎么判断：看失败原因的分布，如果某一类错误码占比很高且重试成功率长期为零，说明在白重试。怎么避：错误码分类处理，逻辑错误立即失败并上报；网络类退避重试且设次数上限；超次数直接退出本批次进次日队列。

坑四：只看包的静态大小，不算长尾车占用的槽位时间。为什么坑：同样是 1.2GB，一台隧道里的车占用的并发槽位时间可能是正常车的十几倍，长尾车队会让你的窗口结束时的完成率停在 85% 上不去。怎么判断：把批次的完成率曲线按时间画出来，如果最后那条尾巴拖得很平但就是不到 100%，问题就在长尾。怎么避：信号门限以下不发起下载；分片级补传；把 KPI 从"窗口内 100%"改成"72 小时内 99%"，剩下的走次日窗口或门店。

坑五：把 CDN 当万能药，manifest 与鉴权没拆出来。为什么坑：CDN 只能缓存无状态内容，个性化 manifest 和逐车鉴权如果跟着大包一起走 CDN，命中率会低得难看，回源比例居高不下。怎么判断：看 CDN 侧的命中率与回源带宽占比，如果回源流量长期维持在较高水平，说明有不该进 CDN 的东西进去了。怎么避：职责分离——大对象全权交给 CDN 并做发布前预热，manifest、鉴权、台账查询独立部署独立扩容，两者之间只通过一次性令牌衔接。

关于 OTA 批次与带宽的几个高频疑问

Q1：并发比到底按多少估才稳？

没有放之四海而皆准的数，只有自己车队的数。起步时可以按 3%–8% 这个经验区间假设，但第一件事应该是把历史批次的同时下载连接数曲线调出来，除以同期在线数，得到自己的实际比值。这个比值要按车队构成分层：乘用车队的昼夜节律明显，商用车队的上线更集中，工程作业车辆几乎是按班次整整齐齐地上线——它们不能用同一个数。另外一个常被忽略的点是呃 "在线"定义本身：有些平台把 30 分钟内有心跳的都算在线，有些只算当前有长连接的，两个口径算出来的比值差得很远，先统一口径再谈比值。最后留余量：估出来的值乘 1.5 作为采购与设计依据，剩下的 0.5 由服务端动态限流兜底。

Q2：差分包是在服务端怎么生成的，要不要给所有历史版本两两生成？

不建议两两生成，那是组合爆炸。差分的输入是"某辆车的当前版本"到"目标版本"的一对镜像，把版本两两配对之后，再乘以车型、硬件批次、区域变体，组合数会大到机房受不了。普遍做法是给一条"升级路径"：只生成最近 K 个版本到最新版本的差分，K 常见取 3–5；更早的版本先升到一个中间版本作为跳板，再升到最新，中间的差分链路可以临时计算也可以预先算好。占比很低的老版本不要为它单独维护，直接走全量包兜底更省事。生成任务的资源要单独算：内存通常是包体大小的数倍（按 3–5 倍准备），并且要和分发源站物理隔离。

Q3：夜间窗口开多久合适，会不会影响白天用车？

乘用车场景，凌晨 1 点到 5 点是比较常见的窗口，主要考虑是这个时段绝大多数车处于停放熄火状态、用户在睡觉、蜂窝网络也相对空闲。窗口四小时是常见选择，但它不是一个必须守死的数——真正该定义的是"目标完成率 + 容忍时长"，比如"72 小时内完成 99%，剩下的走次日窗口"，比"四小时完成 100%"健康得多。商用车队不建议套用同一套窗口：营运车辆的停放规律和白班密切相关，应该按当地车队的上报数据单独定，跨时区的车队更要按当地时间切分。另外，无论如何要保证一条硬约束：下载过程中收到启动信号立即暂停，绝不能出现用户上车时发现车机正在升级的情况。

Q4：失败重试用什么退避策略，为什么不能简单重试三次？

简单重试三次最大的问题是"同步"。一批车几乎同时失败，它们的三次重试也几乎同时发生，形成一个高度同步的尖峰，而且因为失败的车往往是网络最差的车，这个尖峰会不断被同一批车重复制造。正确的做法是退避加抖动：首次延迟随机化到 0–300 秒之间，倍数取 2，再叠加 ±20%–30% 的随机抖动，让重试在时间轴上散开成矮丘而不是一根针。同时要分辨失败类型：4xx 的逻辑错误重试没意义，应当立刻失败上报；5xx 与限速响应才值得退避；超时类还要结合信号门限判断，信号不达标就等信号事件驱动，而不是硬重试。最后给次数上限，超过就退出本夜批次。

Q5：OTA 分发到底要不要上 CDN，什么情况下源站直出就够了？

判据是"并发规模 × 地理分散度"。如果车队规模在几千台以内、集中在单一区域、发布时间宽松，源站直出配合断点续传通常够用，省掉一层缓存也省掉一层复杂度。但一旦到了十万级、跨多个省份或多个国家，跨运营商、跨骨干的问题就绕不过去，边缘缓存的价值立刻凸显——它不只是扛流量，更重要的是把 RTT 降下来，让每路连接更快跑完，从而缩短它占用并发槽位的时间。要注意的是 CDN 只能承担无状态的大对象，个性化 manifest 和逐车鉴权要拆出来单独部署；发布前对热包做预热，否则批次一开始的首次回源会直接打穿你自己那点源站带宽。

Q6：源站带宽按峰值买还是按窗口均值买？

两种计费口径的成本结构完全不同。按峰值计费时，短时尖峰会被计入账单，代价通常很高；常见的 95 峰值计费允许每月有一定比例的时间超出，对夜间批次这种尖峰形态友好得多，具体口径和单价以运营商与机房实时报价为准。所以更实际的做法不是"买多少"，而是"能把峰值削下去多少"。把包体用边缘缓存吸收掉，源站只承担回源与动态请求的部分，热但控制在很小的比例；同时用服务端限流把瞬时峰值削成平台所需要的形状——宁可拉长一点时间，也不要让尖峰出现在账单上。差分率、预热、分片补传这些手段，本质上都是在为这件事服务。

Q7：跨时区的车队怎么分批发，才能避开当地的夜间？

最省事的思路是"跟随当地时间"，而不是统一时间。给每辆车绑定一个时区或地理区域标签，按当地凌晨窗口分别下发，这样每辆车都在自己最闲的时候升级，全球的出口压力反而自动被摊平到 24 小时上——这是跨境车队少有的好事。前提是车辆的时间与时区来源可靠，GPS 或运营商网络返回的时区信息要校对，别出现同一辆车在两个区域之间反复横跳导致批次切换。另外分区发布要留意当地的监管要求——分区发布需符合当地监管要求、以当地规则为准，某些地区的数据与软件落地限制会决定你能不能把包推到本地节点，这会反过来影响你的节点选址。

Q8：升级下载到一半断网，车机怎么保证不"变砖"？

车端的第一道防线是 A/B 分区：新版本写入备用分区，写完后由引导程序切换，失败就原地回退到旧分区，整个过程不依赖服务端。这要求车端有足够空间保留一份旧系统，存储吃紧的老机型做不到，这种情况就要靠"下载完整性前置校验"——下载完成后必须先做签名验与完整性校验，任何一项不过就绝不进入刷写流程，宁可停在"下载失败"也不要停在"刷到一半"。服务端侧要做的是给每台车维护一个状态台账：下载中、校验通过、刷写中、完成、失败，并且所有状态转换幂等。还有一个细节别忘：禁止在车辆点火或行驶状态下进入刷写阶段，下载可以后台跑，刷写必须在多重安全条件判定通过之后才进行。

批次算完之后，灰度、回滚与失败重试该怎么排顺序

三件事的优先级，我的排序是：失败重试 > 回滚准备 > 灰度放量。理由很实际：规模化发布的第一原则是别把自己搞垮，而搞垮你的往往是重试风暴，不是新版本本身；回滚是唯一能在出问题时让你有退路的东西；灰度则是在前两者都稳妥的前提下，控制影响面的工具。

落到执行顺序上，第一步先把包体大小、并发上限、单连接限速、退避抖动这四个参数定下来，并且先在百分之几的小范围跑一整轮，把实际比值、失败分布、带宽曲线全跑出来——这一步产出的不是通过率，而是参数。第二步确认回滚路径真的通：日志上看一百次成功不如实际拉一台车走一遍失败回退，A/B 分区的机型直接验切换，没有 A/B 的机型验"旧包还在、还能下发"。第三步才是灰度放量，而且批次推进的判据不应该只看成功率，还要看出口水位、源站响应时间、失败原因分布——成功率会滞后，这三个指标是先行指标。

说到底，十万级车队的 OTA 考验的不是谁的服务器多，而是谁能把"批次"这个抽象概念拆成参数、并且有纪律地按参数执行。这中间能力的形成没有捷径：要么自己攒团队慢慢踩坑，要么找有 IDC 底子的服务商一起规划。一万网络在深圳南山有自营机柜，深耕 IDC 19 年（成立于 2007 年），带宽与节点可以按批次峰值来配，具体以官网实时报价为准。。

本篇 OTA 批次测算的参考来源与需要实测确认的部分

本文中关于增量（差分）升级在服务端需要生成差分包、以及该过程消耗 CPU、内存与磁盘 IO 的判断，参考 OTA 差分算法公开项目文档（如 bsdiff、xdelta、HDiffPatch 等开源工具的项目说明）与汽车行业 OTA 技术白皮书中的通用描述。

关于断点续传与范围请求的机制，参考 HTTP 协议相关标准文档（RFC 7233 Range Requests）与主流对象存储厂商关于分片上传/下载、预签名 URL 的官方产品文档。

关于指数退避与抖动的实践，参考云厂商架构文档中的重试模式（Retry Pattern / Exponential Backoff and Jitter）通用建议，具体参数仍需按自身车队实测收敛。

文中所有数值均为示例场景与经验区间的假设值，用于演示计算口径，不代表任何实测结果、跑分数据或真实客户指标。实际并发比、差分率、退避参数、窗口时长等，必须结合自身车队的车型构成、联网卡运营商、车环境条件与机房线路实测确认。

关于节点、线路、配置与报价的信息，参考 IDC 服务商公开产品页与官网明示价格（如部分裸金属与云主机档位的官网明示起售价），具体以签约时最新报价与合同为准。