1. 课程导入与运维体系总览

Ryzen Embedded 平台在工业视觉、边缘计算、医疗影像、车载终端等场景中，往往以几十台到上千台的规模部署。单台设备的调试经验无法直接迁移到批量运维：一台机器上手工改 BIOS、装系统、调散热曲线，在 500 台规模下会变成不可承受的人力成本，而且极易产生配置漂移。本课程要解决的核心问题，就是如何把"单机可用的方法"转化为"批量可复现、可观测、可回滚的运维体系"。

运维目标与范围

批量设备运维的目标可以归纳为三条主线：一致性（同批次设备的固件、系统镜像、驱动、应用版本可核对）、可观测性（每台设备的健康状态、温度、负载、异常可远程获取）、可恢复性（故障设备能快速定位、替换或回滚，不依赖现场逐台操作）。

范围上，本课程覆盖从设备出厂接入到退役的全链路，具体包括：

• 接入层：设备上电、网络接入、身份注册（序列号、MAC、TPM/安全芯片标识）。
• 配置层：BIOS/UEFI 参数、CPU 功耗策略（如 15W/25W/35W 档位）、内存与显存分配、看门狗与风扇策略。
• 系统层：操作系统镜像、内核版本、驱动（AMD GPU、NPU、网卡）、只读根文件系统与 A/B 分区。
• 应用层：容器或原生应用的版本发布、配置下发、灰度与回滚。
• 运维层：远程监控、日志采集、批量升级、故障诊断、备件与生命周期管理。

需要明确的是，本课程不讨论单台设备的性能调优细节，而是聚焦"批量"带来的额外约束：并发升级的带宽与失败率、配置基线的版本管理、设备离线后的状态判定、以及不同批次硬件差异（如 Ryzen Embedded V2000 与 R2000 系列）对镜像兼容性的影响。

核心挑战

批量运维的难点并不在"能不能远程连上"，而在以下几个容易被低估的环节：

1. 配置漂移：现场工程师为临时解决问题修改了某台设备的 BIOS 或内核参数，事后未记录，导致该设备与基线不一致，后续升级失败。
2. 升级原子性：批量推送镜像时，若设备在写入过程中断电，可能进入无法启动的状态。因此需要 A/B 分区或双镜像机制，并保证切换失败可自动回退。
3. 状态判定：设备"在线"不等于"健康"。CPU 温度长期 95°C、风扇转速异常、eMMC 剩余寿命不足，这些都需要通过带内或带外通道采集。
4. 网络与带宽：500 台设备同时拉取 4GB 镜像，若不做分片、限速或 P2P 分发，会打满出口带宽并拖垮业务网络。
5. 身份与安全：批量设备使用相同默认密码或相同证书，一旦泄露即全网风险。需要每台设备唯一密钥与安全启动链。

整体架构：从设备接入到生命周期管理

下图给出本课程贯穿始终的全链路视图。左侧是设备侧（Edge Device），右侧是运维平台侧（Ops Platform），中间通过带内管理通道（业务网络）和带外管理通道（如串口、BMC 或独立管理网）连接。设备侧包含固件、系统、应用三层，平台侧包含接入、配置、发布、监控、生命周期五个能力域。

这张图的关键在于：设备侧的每一层都对应平台侧的一个能力域，而两者之间的箭头方向代表了数据流与控制流的分离。设备向平台上报心跳、温度、日志（数据流，蓝色）；平台向设备下发配置、镜像、指令（控制流，绿色/橙色）。理解这一分离，是后续设计升级策略和监控方案的基础。

一个可参考的基线示例

为了让"配置基线"这个概念具体化，下面给出一份示例性的设备基线记录表。字段和取值属于教学示例，实际项目中应根据硬件型号和业务需求调整。

这张表的意义在于：它把"一致性"从口号变成了可逐项核对的清单。批量运维中，任何一台设备只要有一项与基线不符，就应当在平台侧被标记出来，而不是等到业务故障时才被发现。

本课程的组织方式