从开发到现场RK3588 边缘设备的冷部署与 OTA 升级实战上一篇我们分享了越微自研事件融合引擎与证据链把 AI 视觉误报率从 75% 降到了 10-15%。但系统做得再好部署不上去、升级出问题一切都是白搭。边缘设备分散在各个客户现场网络不稳定运维人员技术水平不一怎么把系统可靠地部署上去怎么在不中断业务的情况下安全升级本文分享我们的冷部署与 OTA 升级方案以及踩过的那些坑。一、背景边缘设备的部署运维挑战做边缘计算产品部署和运维是绕不开的难题。和云端服务不同边缘设备有几个特殊的挑战挑战一设备分散现场环境复杂边缘设备不是集中在数据中心而是分散在各个客户现场——工厂车间、园区角落、仓库、楼道、电线杆上。设备可能接的是不稳定的 WiFi可能经常断电可能温度很高夏天车间 40 度以上可能灰尘很大。在这种环境下部署和升级不能假设「网络稳定、电源稳定、环境可控」必须考虑各种异常情况。挑战二运维人员技术水平不一云端服务的部署运维由专业的运维工程师操作但边缘设备的现场操作可能是客户的保安、电工、行政人员——他们可能不懂 Linux不会敲命令甚至不会用 SSH。部署和升级流程必须足够简单最好是「下一步、下一步、完成」的图形化操作或者一键脚本不能要求运维人员懂技术细节。挑战三升级不能中断业务边缘设备通常在 7×24 小时运行升级的时候不能长时间中断业务——客户的安防系统不能因为升级就停半小时工厂的质检系统不能因为升级就停一条线。升级必须快速、可靠、可回滚——升级出了问题能立即回滚到旧版本不能让设备变砖。挑战四配置和数据不能丢升级的时候设备上的配置摄像头地址、任务参数、ROI 设置、历史数据告警记录、证据图、日志都不能丢。如果升级把配置搞丢了客户要重新配置一遍体验非常差。我们早期的版本就踩过这个坑——升级脚本直接覆盖了整个目录把客户的配置和数据都覆盖了客户非常生气。后来我们才把「生产数据」和「编译制品」严格分开。二、我们的部署架构热插拔扁平布局 [Yuewell Inside]针对这些挑战我们设计了一套「热插拔扁平布局」的部署架构。核心思想是目录结构简单清晰生产数据和编译制品严格分离升级只替换编译制品不碰生产数据。核心原则生产数据 vs 编译制品可覆盖编译制品bin/、lib/、models/、scripts/、systemd/、run.sh、VERSION这些是编译生成的文件每次升级都用新版本替换丢了也没关系重新部署一份就行严禁覆盖生产数据configs/、data/、logs/这些是客户的配置、历史数据、日志升级时绝对不能碰丢了可能导致客户要重新配置、历史告警记录丢失是严重事故这个分离原则是部署架构的基石。升级脚本只替换编译制品目录生产数据目录原封不动。这样不管怎么升级客户的配置和数据都安全。为什么叫「热插拔扁平布局」扁平目录结构不深所有关键目录都在部署根目录下运维人员一眼就能看懂找文件方便热插拔整个部署目录可以整体打包、传输、解压、替换像插 U 盘一样简单。不需要复杂的安装器不需要解决依赖解压就能用后端和客户端分树backend/和client/分开可以只升级后端不升级客户端或者反过来灵活方便三、冷部署新机器怎么装系统冷部署是指全新的 RK3588 设备第一次安装我们的系统。这时候设备上什么都没有需要从零开始部署。冷部署的流程我们把冷部署流程设计成「传两个文件跑一条命令」准备两个文件冷部署包tar.gz 格式包含完整的编译制品 初始配置模板 部署脚本引导脚本bootstrap_deploy.sh负责解压、校验、安装把两个文件传到新机器上用 U 盘拷贝或 scp 传输跑一条命令sudo ./bootstrap_deploy.sh --archive 部署包.tar.gz --dest /部署目录 --install-systemd等待完成——引导脚本自动完成所有操作完成后系统已经在运行了引导脚本做了什么引导脚本bootstrap内部做了这些事情SHA256 清单校验——部署包里带了一个清单文件manifest记录了每个文件的 SHA256 哈希。引导脚本解压后逐一校验每个文件的哈希确保部署包在传输过程中没有损坏、没有被篡改。校验失败就中止不继续安装。权限自愈——解压后的文件可能权限不对比如从 Windows 传过来的文件丢了执行权限。引导脚本自动修复所有文件和目录的权限——可执行文件加x配置文件设为合适的权限目录设为合适的权限。确保不会因为权限问题导致服务起不来。白名单合并——如果设备上已经有旧版本的配置比如之前装过 demo 版引导脚本会把旧配置和新配置模板合并保留客户的自定义配置而不是直接覆盖。保留生产数据——如果设备上已经有 data/ 和 logs/比如重装系统引导脚本不会删除它们而是保留下来。安装 systemd 服务——把 systemd unit 文件安装到系统目录enable 并 start 服务。安装完成后系统会自动启动并且开机自启。整个过程不需要运维人员懂 Linux只需要会传文件、会敲一条命令就行。而且每一步都有校验和保护不容易出问题。为什么严禁用 Xftp 散文件覆盖有些运维人员图省事用 Xftp 之类的工具把文件一个个传到设备上覆盖整个目录。我们严禁这种做法原因是丢执行权限Xftp 传输可能丢失文件的执行权限x导致服务起不来无法校验完整性散文件传输没有 SHA256 校验传坏了也不知道可能覆盖生产数据散文件覆盖可能不小心覆盖了 configs/、data/、logs/导致配置和数据丢失版本混乱散文件覆盖可能新旧文件混杂不知道哪个版本是哪个正确的做法永远是用打包好的部署包 引导脚本不要散文件覆盖。四、OTA 升级已有设备怎么安全更新 [Yuewell Inside]冷部署只做一次新机器装系统之后所有的更新都走OTAOver-The-Air升级。OTA 升级是边缘设备运维中最频繁、也最容易出问题的环节。OTA 升级的设计目标我们设计 OTA 升级机制时定了几个目标不中断业务——升级过程尽量短最好几秒内完成可回滚——升级出了问题能立即回滚到旧版本不能变砖不丢数据——升级不碰配置和数据操作简单——运维人员在客户端界面点几下就能完成不需要敲命令可校验——升级包完整性校验、依赖检查确保升级后能正常运行OTA 升级包和冷部署包的区别很多人会问OTA 升级包和冷部署包有什么区别为什么不直接用冷部署包升级对比项冷部署包OTA 升级包包含配置是初始配置模板否保留现场配置包含数据否空数据目录否绝对不碰数据适用场景新机器第一次安装已有设备的日常更新应用方式bootstrap 脚本引导安装客户端 UI 触发后端自动应用回滚机制不需要全新安装必须有Watchdog 自动回滚核心区别OTA 升级包不含配置和数据只包含编译制品bin/lib/models/scripts。因为升级的时候客户的配置和数据必须原封不动地保留。OTA 升级的流程OTA 升级通过客户端UI/交互层进程的图形界面操作运维人员不需要敲命令运维人员在客户端打开「系统设置 → 设备基础运维 → 升级软件」选择 OTA 升级包tar.gz 格式客户端把升级包流式上传给后端边缘核心服务后端做升级前检查preflight磁盘余量检查确保有足够空间解压升级包数据库 schema 版本检查确保新版本兼容当前数据库systemd 检查确保服务管理方式正确升级包 SHA256 校验确保包完整无损检查通过后后端应用升级停止后端服务备份当前版本的 bin/ 到 backup 目录用于回滚用升级包的新 bin/lib/models/scripts 替换旧版本启动后端服务Watchdog 开始监控Watchdog 监控期约 10 秒如果服务正常启动、健康检查通过 → 升级成功清理备份如果服务启动失败、健康检查不通过 →自动回滚从 backup 恢复旧版本重启服务确保设备恢复正常客户端显示升级结果成功或失败失败时显示回滚成功整个升级过程通常只需要 10-30 秒取决于升级包大小业务中断时间就是服务重启的那几秒。如果升级失败Watchdog 自动回滚设备恢复到升级前的状态不会变砖。客户端热切换如果升级包包含客户端更新--with-client客户端的升级更讲究——因为升级过程中客户端正在运行不能直接覆盖正在运行的可执行文件。我们的做法是客户端热切换新版本客户端解压到client/bin_staging/临时目录后端升级完成、Watchdog 确认后端正常后触发客户端重启客户端重启时用原子操作rename把bin_staging/替换成bin/新版本客户端启动升级完成原子 rename 保证了切换的瞬间性——要么还是旧版本要么已经是新版本不会出现「半新半旧」的中间状态。即使切换过程中断电重启后也能恢复到一致的状态。依赖检查dependency_check升级不仅仅是替换文件还要确保新版本的依赖在当前设备上都满足。我们做了依赖检查glibc 版本检查新版本编译时用的 glibc 版本设备上的 glibc 不能太旧否则运行会报错系统库检查新版本依赖的系统库如 libstdc、libssl 等是否存在bundled 库校验我们打包的依赖库gRPC、FFmpeg、MPP、RKNN、RGA 等的 SHA256 是否和预期一致确保没有损坏BSP 版本检查RK3588 的板级支持包BSP版本是否兼容MPP、RGA、RKNN 驱动版本要和 BSP 匹配任何一项检查不通过升级就中止不会继续。这样可以避免「升级完了才发现依赖不满足服务起不来」的尴尬。五、部署免疫层让部署更健壮的保护层 [Yuewell Inside]冷部署和 OTA 升级的流程中我们嵌入了一层「部署免疫层」——一组自动执行的保护机制确保部署和升级过程中不会因为权限、完整性、依赖等问题导致服务起不来。免疫层的组成1. 权限自愈heal_deploy_permissions在启动、安装、OTA、冷部署等各个环节自动执行修复所有文件和目录的权限——可执行文件加x配置文件设为 644目录设为 755单个文件的权限修复失败不中断主流程Tier-2 容错记录日志继续解决了「从 Windows 传文件丢执行权限」「解压后权限不对」等常见问题2. SHA256 清单校验冷部署包和 OTA 升级包都带 manifest 文件记录每个文件的 SHA256部署/升级时逐一校验确保文件完整、未被篡改校验失败立即中止不继续安装3. preflight 检查升级前做全面检查磁盘余量、数据库 schema、systemd 状态、依赖库版本、BSP 版本任何一项不通过就中止升级给出明确的错误提示避免「升级到一半发现条件不满足进退两难」4. Watchdog 回滚OTA 升级后自动监控服务启动状态10 秒内服务未就绪 → 自动回滚到旧版本回滚后再次启动服务确保设备恢复正常回滚过程也有日志记录方便排查5. 生产数据保护所有部署/升级脚本都明确排除 configs/、data/、logs/ 目录这些目录不会被替换、删除、覆盖即使升级脚本出 bug也不会碰生产数据代码层面的硬保护部署免疫层的核心思想是假设运维人员会犯错、假设网络会出问题、假设文件会损坏然后在每个环节都加上自动保护机制让系统自己「免疫」这些常见问题。六、四类部署场景什么时候用哪种方式我们把部署场景分成四类每类用不同的方式不要混用场景何时使用核心方式A. 开发机直接同步开发阶段本机就是运行环境日常改代码最快验证编译 → 同步到部署目录 → 重启服务B. 开发机 OTA 验证开发阶段验证和现场一致的 OTA 升级链路打 OTA 包 → 客户端升级 UI 触发C. 新机器冷部署全新设备第一次安装系统打冷部署包 → 传两个文件 → bootstrap 引导D. 已有基础版 OTA新机器装完基础版后的所有日常更新现场设备升级打 OTA 包 → 客户端升级 UI 触发使用原则日常开发优先用场景 A最快需要验证 OTA 流程时用场景 B新机器只做一次场景 C冷部署之后一律用场景 DOTA不要再用冷部署包做日常更新严禁用 Xftp 散文件覆盖整个部署目录七、实战案例50 台设备的批量 OTA 升级我们有一个客户现场部署了 50 台 RK3588 边缘设备分布在园区的各个角落。有一次我们发布了一个重要版本算法模型升级 后端性能优化需要给 50 台设备全部升级。升级前的准备在测试环境充分验证——先在实验室的 3 台测试设备上跑 OTA 升级验证升级流程、Watchdog 回滚、升级后功能正常小范围灰度——先给客户现场的 2 台设备升级观察 24 小时确认稳定准备回滚方案——确认升级包有问题时运维人员知道怎么手动回滚虽然 Watchdog 会自动回滚但要有手动方案兜底选择升级时间窗口——和客户确认在业务低峰期如凌晨 2-4 点升级减少对业务的影响批量升级过程因为设备分散在园区各处运维人员不可能一台一台地接显示器操作。我们的做法是运维人员带着笔记本电脑连接到园区内网用客户端的「批量升级」功能我们后来加的功能一次性选择所有 50 台设备上传 OTA 升级包客户端自动并行推送给所有设备每台设备独立执行 OTA 升级流程preflight 检查 → 替换文件 → 重启 → Watchdog 监控客户端实时显示每台设备的升级进度和结果升级结果50 台设备中48 台升级成功耗时约 5 分钟并行升级不是一台一台串行2 台升级失败——一台是磁盘余量不足preflight 检查拦截没有开始升级一台是升级后服务启动异常Watchdog 自动回滚恢复到旧版本运维人员对失败的 2 台做了处理清理磁盘、检查日志然后重新升级全部成功整个批量升级过程不到 1 小时没有一台设备变砖没有一台设备丢失配置和数据。客户对这个结果很满意。一次 Watchdog 回滚救场的真实案例还有一次印象深刻的升级我们发布了一个版本在测试环境验证没问题但到了客户现场有一台设备升级后服务起不来——原因是那台设备的 BSP 版本比较老新版本依赖的 RGA 驱动接口在老 BSP 上不兼容。幸运的是Watchdog 在 10 秒内检测到服务未就绪自动回滚到了旧版本设备恢复正常。运维人员收到回滚通知后联系我们排查发现是 BSP 版本问题给那台设备单独升级了 BSP然后重新升级应用成功完成。如果没有 Watchdog 自动回滚那台设备就变砖了——运维人员要跑到现场接显示器手动恢复非常麻烦。Watchdog 回滚机制在关键时刻救了场。八、踩坑实录部署和升级的过程中我们踩了很多坑分享几个印象深刻的。坑一升级覆盖了客户配置客户暴怒我们早期的升级脚本很简单——直接 tar 解压覆盖整个部署目录。有一次升级把客户的 configs/ 目录覆盖了客户花了半天配置的 20 多路摄像头参数、ROI 区域、任务设置全部丢失恢复成了默认配置。客户发现后非常生气「你们升级怎么把我的配置搞没了我要重新配一遍你们知道要花多久吗」教训从那以后我们把生产数据configs/data/logs和编译制品bin/lib/models/scripts严格分离升级脚本只替换编译制品绝对不碰生产数据。并且在代码层面做了硬保护——升级脚本里明确排除生产数据目录即使想覆盖也覆盖不了。坑二散文件传输丢执行权限服务起不来有一次运维人员用 Xftp 把编译后的可执行文件传到设备上覆盖了旧版本。结果服务起不来排查了半天才发现——Xftp 传输把文件的执行权限x弄丢了文件变成了 644没有执行权限systemd 启动时报「Permission denied」。教训严禁用 Xftp 散文件覆盖必须用打包好的部署包 引导脚本/OTA 升级。引导脚本里有权限自愈机制自动修复所有文件的执行权限。坑三升级后 systemd 无法启动日志权限不对有一次 OTA 升级后服务起不来查日志发现是 logs/ 目录的属主不对——升级脚本是以 root 身份运行的创建的 logs/ 目录属主是 root但服务是以普通用户linaro身份运行的没有权限写 logs/导致启动失败。教训升级脚本中增加了运行时权限修复fix_runtime_permissions——升级完成后把 data/ 和 logs/ 目录的属主改回服务运行用户。并且在部署免疫层的权限自愈中也加入了属主检查和修复。坑四OTA 升级包和冷部署包搞混配置被重置有一次运维人员给已经部署了的设备做日常更新误用了冷部署包而不是 OTA 升级包。冷部署包包含初始配置模板引导脚本在「白名单合并」时把客户的一些自定义配置重置成了默认值。虽然没有完全丢失配置白名单合并保留了大部分但有几个扩展字段被重置了客户需要重新设置。教训在冷部署包和 OTA 升级包的文件名、包内清单、客户端 UI 上都做了明确区分——文件名前缀不同yw_avis_deploy_vsyw_avis_upgrade_包内 manifest 里有package_type字段客户端 UI 会检查包类型用错了会提示并拒绝。运维人员很难再搞混。⚠️ 工程坑点与技术壁垒警告提示部署与升级看起来是「传文件、解压、重启」这么简单但工程落地中有极高的技术壁垒生产数据与编译制品的严格分离说起来简单但要在所有脚本、所有流程、所有异常情况下都保证生产数据不被碰需要在代码层面做硬保护并且经过大量故障注入验证。一个疏忽就可能导致客户配置丢失是严重事故。Watchdog 回滚的可靠性升级失败自动回滚说起来简单但要保证回滚过程本身不失败、回滚后服务一定能起来、回滚过程中不会丢数据需要大量的工程细节和异常处理。如果回滚机制本身有 bug升级失败就可能导致设备变砖。跨 BSP 版本的兼容性不同客户的 RK3588 设备可能用不同版本的 BSPMPP、RGA、RKNN 驱动接口可能有差异。升级包要兼容多种 BSP 版本或者在 preflight 检查中精确识别并拒绝不兼容的版本。这些兼容性细节需要大量的真机测试。这些工程细节不是看几篇博客就能搞定的需要在真实设备上反复调试、压测、故障注入。越微团队在这上面投入了大量时间才打磨出稳定的部署与升级体系。九、几点经验总结回头看冷部署和 OTA 升级的设计和落地过程总结几点1. 生产数据和编译制品分离是部署架构的第一原则这是我们用客户暴怒换来的教训。配置、数据、日志是客户的资产绝对不能在升级中丢失或覆盖。目录结构、升级脚本、代码层面都要做硬保护确保生产数据万无一失。2. 冷部署和 OTA 升级是两回事不要混用冷部署面向全新设备包含初始配置OTA 面向已有设备不含配置。两者的包格式、应用方式、回滚机制都不同。要在文件名、manifest、UI 上做明确区分避免运维人员用错。3. Watchdog 自动回滚是 OTA 升级的「安全带」没有任何升级能保证 100% 成功——测试环境没问题不代表客户现场没问题BSP 版本、硬件差异、网络状况都可能导致问题。Watchdog 自动回滚能在升级失败时自动恢复旧版本确保设备不变砖。这是 OTA 升级必须有的机制不能省。4. 部署免疫层不是「锦上添花」是「必需品」权限自愈、SHA256 校验、preflight 检查、生产数据保护——这些机制看起来琐碎但每一个都是踩坑踩出来的。边缘设备的现场环境复杂运维人员水平不一没有这些免疫层部署和升级会频繁出问题。免疫层让系统对常见问题有「自愈能力」大大降低了运维成本。5. 升级操作要图形化不要要求运维人员敲命令边缘设备的现场运维人员可能不懂 Linux不会敲命令。把升级操作做成客户端图形界面的「选择文件 → 点升级 → 看进度」运维人员零学习成本就能操作。而且图形界面可以做更多校验和提示包类型检查、preflight 结果展示、进度条、失败原因比命令行更友好、更安全。6. 批量升级要并行不要串行几十台上百台设备如果一台一台串行升级耗时太长。要支持并行升级——客户端同时给多台设备推送升级包每台设备独立执行升级流程客户端统一监控进度和结果。50 台设备并行升级 5 分钟完成串行可能要几个小时。写在最后部署和升级是边缘计算产品「最后一公里」的问题。算法再准、系统再快如果部署不上去、升级出问题客户就用不起来。我们在这上面花了很多时间踩了很多坑才搭起一套「冷部署简单可靠、OTA 升级安全可回滚、部署免疫层自动保护」的完整方案。这些经验都是我们越微智能在实际项目中踩坑踩出来的。我们团队一直在做工业 AI 视觉、边缘计算部署、机器人二次开发这些落地工作边缘 AI 视频分析系统是我们的核心产品之一。下一篇是这个系列的收官篇我们会回顾整个边缘 AI 视觉系统的架构演进聊聊未来的发展方向。如果你也在做边缘设备部署、OTA 升级、嵌入式系统运维相关的工作欢迎交流我们一起踩坑、一起进步。关于作者与团队越微智能Yuewell是一支专注具身智能与工业 AI 视觉落地的技术团队提供工业级视觉算法定制30 算法、RK3588 边缘一体机、具身机器人调度管理平台、全品牌机器人二次开发适配宇树/优必选/智元/傅利叶等、ROS2 系统开发等产品和服务支持从算法、硬件到产线实机部署的全栈交付。我们将这套经过大量现场验证的部署与升级体系封装为了**工业级边缘 AI 视觉基座Yuewell Edge Framework**的核心模块支持硬件/算法快速二次开发帮助客户跳过最痛苦的部署运维阶段。下一篇预告系列收官《边缘 AI 视觉系统的架构演进与未来方向》我们将回顾整个系列的核心内容三进程架构、MPPRGA 硬加速、同源多任务调度、零拷贝通信、多模型推理、事件融合、部署运维聊聊边缘 AI 的行业趋势大模型边缘化、VLA 与视觉融合、边缘-云协同以及越微智能在这个领域的实践和思考敬请关注。