DevOps 这一开发理念在2009年被提出后，经过十几年的发展，已经非常成熟了，特别是在微服务架构被提出并流行开来，进一步推动 DevOps 实践深入发展。DevOps 既然已经这么成熟了，我们为啥还要写这个话题？笔者认为理念是成熟的，但应用的业务场景是日新月异的，怎么把这一成熟的理念应用到各种业务场景，还是有不少挑战的；再者这也是参与各种职位后做的经验，结合ChatGPT的解答，总结的笔记。由于没有涉猎所有的环节对应的职位，如有不当之处请指正。开篇之前，先对齐一下基本概念。
DevOps 是什么
DevOps 是软件开发与信息技术运维的整合及自动化实践[a]。这一方法论涵盖了软件开发的关键环节，能有效缩短开发周期并优化全生命周期管理[1]。Neal Ford指出，DevOps（尤其是通过持续交付实现时）遵循"痛点前置"原则——通过尽早处理复杂任务、推动自动化建设及快速发现问题来提升效率[2]。软件工程师与架构师应当运用适应性函数（fitness functions）来确保系统健康度[3]。
尽管存在学术争议[b][c][d][e]，DevOps仍以三大核心原则为特征：责任共担、工作流自动化及快速反馈机制。来自澳大利亚联邦科学与工业研究组织（CSIRO）和软件工程研究所的三位计算机科学家Len Bass、Ingo Weber与Liming Zhu从学术角度提出定义：“DevOps是一套旨在保证高质量的前提下，显著缩短系统变更提交到正式生产环境所用时间的实践集合”[7]。不过该术语在实际应用中存在多重解读。最成功的DevOps实施往往需要特定实践、文化转型与工具链三者的有机结合[8]。
智能驾驶是什么
智能驾驶（Intelligent Driving） 是指利用人工智能、传感器技术、通信技术和自动控制技术，使车辆具备 感知环境、理解交通、做出决策并执行驾驶操作 的能力。它是自动驾驶、智能辅助驾驶（ADAS）等系统的统称。
通俗的讲，智能驾驶就是让“车自己能看、能想、能动”，像一个具备初级智慧的司机那样安全行驶。
国际汽车工程师学会发布的自动驾驶分级 L0 - L5，大家更为熟知，从人工驾驶到完全自动驾驶
智能驾驶 DevOps 是什么
智能驾驶 DevOps 是将 DevOps 理念和工具链应用于智能驾驶系统的开发、测试、部署和运营全过程，目标是：
- 提高研发效率（CI/CD 自动化）
- 加速版本迭代（高频交付）
- 保证系统质量（自动测试、回归）
- 支撑多车型、多平台、大量数据的复杂工程体系
数据是智能驾驶的基础、支撑、引擎和保障，贯穿了从模型训练、功能开发、仿真测试到问题定位的全生命周期，数据闭环是我们常听到的智能驾驶常提的一个概念，数据闭环的实现离不开智能驾驶 DevOps 的三驾马车。
- Cloud Service DevOps (云服务 DevOps): 数据平台是云服务 DevOps 的实践体现，以数据为中心构建的云服务平台，承载基础设施资源运维、数据管理、云服务以及工具链的开发运维；
- Vehicle Soc DevOps (车端嵌入式系统 DevOps): 不同于云服务，嵌入式系统有另一套开发流程，依托于效能云服务，承载了车端版本规划、开发、构建、测试、发布的整个流程，同时量产车云服务承载了车端版本的运维、运营和监控；
- AI Model DevOps (模型 DevOps): 数据采集上云、标注、模型训练、模型发布等AI服务则构建了模型 DevOps 的整体链路，同时通过车端版本测试和运营。
前面 DevOps 概念提到，DevOps 是软件开发与信息技术运维的整合及自动化实践。自动化的前提是什么，是策略（或者说是规则），有策略才能实现自动化。这是很重要的一点，是我们整个实现的基石。在开始探讨DevOps的8个核心环节之前，我们先来探讨一下各个环节相关的策略。
策略
配置策略
配置管理的目标是确保系统配置的自动化、标准化和版本控制，确保环境的一致性和可重复性。核心原则如下：
| 原则 | 解释 |
|---|---|
| 配置即代码（Configuration as Code） | 配置应写入代码仓库、版本可控（如 YAML / JSON / HCL） |
| 环境一致性 | 不同环境（开发、测试、生产，仿真、实车）配置同步，消除"在我机器上能运行"问题 |
| 环境解耦 | 不同环境（开发、测试、生产）配置分离，不嵌入代码 |
| 集中管理 | 配置统一管理，防止散乱分布，单一配置源，防止多份配置不归一 |
| 可审计 | 配置改动可追溯、有记录，有变更审查流程规范 |
| 安全隔离 | 敏感信息（如 Token、密钥）通过安全机制管理 |
这些原则在智能驾驶的三个 DevOps 中都适用，针对不同的场景，有不同的工具可供选择。
- 版本控制工具，根据操作类型可以选择Git、SVN，我们通常用Git管理代码，用SVN管理文档，代码管理用Git、Git LFS、repo以及相应的管理平台Gitlab、Gerrit等。模型训练数据、模型本身则通过自研的数据平台做版本控制。
- 环境基础设施，根据隔离强弱及性能效率可以选择KVM、Docker以及相关的管理平台OpenStack、Kubernetes等，我们通常选择用Docker保证环境的一致性、部署微服务，用KVM部署跨平台虚拟机。
- 配置管理工具，在云服务 DevOps 中，通常使用Ansible、Chef、Puppet等做系统层配置，用Kubernetes模板等做应用层配置；在车端Soc DevOps中，通常使用车辆配置参数和远程配置等；，在AI Model DevOps中，通常依赖训练平台的配置管理。
- 数据管理工具，通常采用大数据存储，如对象存储OBS等
代码管理策略
根据团队规模、模块耦合度、权限管理等多方面综合考虑，对于Git来讲，主要是权限管理方面的需求，其他维度可以通过流程规范来约束，当然用工具更好。有两种代码管理策略。
| 模式 | 描述 |
|---|---|
| 多仓（每个模块一个仓） | 每个模块独立 Git 仓库，每个模块设置独立的权限 |
| 单仓（一个仓多个目录） | 所有模块在一个 Git 仓中，以目录区分模块，所有模块共享一个权限 |
这两种方式各有利弊，从以下各个方面来对比分析。总体来讲单仓对于开发人员更友好，对于CI/CD更简单，但对架构和控制更不友好。在这里我们基于强权限管理的需求，使用多仓模式。
| 维度 | 多仓（每个模块一个仓） | 单仓（一个仓多个目录） |
|---|---|---|
| 模块解耦 | 非常强，模块独立，便于复用 | 弱，模块间容易产生隐式依赖 |
| 版本控制 | 每个模块单独 tag/version | 所有模块同一个版本 |
| CI/CD 分布式 | 构建需关心依赖的接口仓、公共组件仓，模块可单独构建测试 | 构建需关心模块的划分，有相应的构建配置规则 |
| 开发效率 | 大团队开发、并行推进更方便 | 小团队集中开发更方便 |
| 权限控制 | 每个模块可设置不同权限 | 所有人对整个仓都有权限 |
| 子模块管理 | 需要用 Git Submodule / Repo / manifest 工具 | 无需多仓管理工具 |
| 适合场景 | 微服务架构 / 多团队 / DevOps 场景 | 单一团队 / 内部高耦合项目 |
分支策略
分支的划分主要受模块耦合度、团队划分、集成方式、测试效率等方面的影响，集成方式和测试效率决定了分支的层级。
在云服务开发中，微服务通常是独立集成、独立部署、独立演进的，微服务的代码分支通常和环境相匹配。
| 环境 | 推荐 Git 分支名 | 说明 |
|---|---|---|
| 开发环境 | develop / feature/* |
开发功能、单元测试、多人协作 |
| 测试/集成环境 | release/* |
联调测试，功能冻结，准备上线 |
| 预生产环境 | pre-release / staging |
灰度验证、稳定性测试，接近线上 |
| 生产环境 | main / master |
最终上线代码，只接受从 pre 分支 promote 的改动 |
注：对于内部云服务来讲，可以适当减少分支来达成快速验证快速上线的目的，在质量和效率平衡下，尽量保证每个环境的可追溯性
智能驾驶软件系统是一个很庞大的系统，有MCU软件，也有SoC软件。
- MCU通常是基于AUTOSAR CP开发的一个单片机系统，通过工具建模和配置生成BSW和RTE模块， 实现业务应用SWC模块代码，SWC模块按领域划分，比如平台、规控等
- SoC软件系统从下往上分为底软、平台、业务层，业务层按传统分层架构分为感知融合、构图定位、规控预测等，在端到端大模型下，这种功能分层的界线可能比较模糊、变成了模型的一部分。
无论MCU和SoC，都涉及不同的团队、多个子系统或者模块，考虑到多团队、多子系统/模块的解耦、协作开发，我们更倾向于按子系统并行开发逐级集成的方式。分支设计如下：
| 系统层级 | Git 分支 | 说明 |
|---|---|---|
| 模块 | 个人分支 | 开发功能、单元测试、多人协作 |
| 子系统 | 子系统(项目团队)分支 | 子系统联调测试，功能冻结，准备对系统发布 |
| 系统 | 系统分支(SoC全量/MCU全量) | 整系统联调,稳定性测试，准备对解决方案发布 |
| 解决方案 | NA | 全域集成，功能测试，最终对用户发布 |
同样的，分支命名可以根据制定的规范来，举例如下：
| 类型 | 推荐 Git 分支名 | 说明 |
|---|---|---|
| 个人分支 | br_<name>* |
用于开发人员开发特性、解决问题、优化等 |
| 子系统(项目团队)分支 | br_develop* |
用于子系统集成、子系统测试 |
| 系统分支 | master / develop |
用于系统级集成、系统级测试 |
| 特性分支 | br_feature* |
用于多模块特性开发联调 |
| 发布分支 | br_release* / br_bugfix* |
用于版本发布或者版本bugfix |
模型相关的代码有两部分，一部分是训练代码，跟随云服务的方式，一部分是车端部署及模型后处理，跟随智能驾驶软件。
集成策略
软件架构决定了集成策略，比如我们采用微服务软件架构和单体架构使用的集成策略是不同的。对于智能驾驶这样的庞大的系统，通常都是多种集成方式的组合策略。常见的集成方式如下：
| 集成方式 | 描述 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 源码集成 | 模块源码放到同一项目一起编译 | 跨模块调试方便，接口一致性强 | 耦合度高、编译慢、分支管理复杂 | 单团队开发、快速迭代 |
| 二进制集成 | 模块提供 .so/.dll/.a 等产物，通过 ABI 连接 | 保护 IP、编译快、跨平台交付 | 接口变化需要适配，排查问题难 | 第三方 SDK、供应商模型 |
| 协议集成 | 模块通过网络、IPC、消息中间件通信 | 分布式、松耦合、支持跨进程或多机 | 实时性差于本地调用，接口管理复杂 | 多 ECU、多进程、云边交互 |
| 服务化集成 | 模块封装为服务，用 REST/gRPC/RPC/Kafka 接入 | 独立部署、弹性伸缩、支持 DevOps 流水线 | 部署复杂、服务治理成本高 | 云端、微服务架构 |
| 容器化集成 | 模块打包到 Docker 等容器中运行 | 环境隔离、易部署、可结合 CI/CD | 对硬件资源敏感、需要容器编排 | 跨环境部署、DevOps、云原生 |
| 插件化集成 | 模块打包成插件，主程序运行时动态加载 | 热插拔灵活、可选功能 | 接口兼容性难维护，出错时易崩溃 | 桌面软件、游戏引擎、IDE 等插件系统 |
在云服务开发中，微服务模块通过源码集成，微服务间通过服务化集成(REST/gRPC/RPC/Kafka)，微服务通过容器化集成。
在车端系统中，在同一ECU内，模块内通过源码集成自研部分 + 通过二进制集成第三方交付；模块间通过接口协议集成(ROS2 DDS)；多ECU通过接口协议集成(比如底盘域通过CAN) + 服务化集成(比如地图服务)
常见的集成策略如下：
| 策略类型 | 描述 | 适用场景 |
|---|---|---|
| 大爆炸集成 | 所有模块一起完成后一次性集成 | 模块依赖少、小项目 |
| 增量集成 | 每次集成部分模块，并对每次集成结果做验证 | 大型系统开发、敏捷交付 |
| 自顶向下 | 先搭建系统主干/框架，逐步集成底层子模块 | 系统架构不确定，需早期原型 |
| 自底向上 | 先将底层组件集成好，再逐步组合成高层功能 | 底层成熟度高、上层依赖底层 |
| 沙盒集成 | 各模块在独立环境（沙盒）先单独验证，再合入主分支/主系统 | 大团队并行开发，避免集成冲突 |
| 持续集成（CI） | 通过自动化流水线在每次代码提交后自动拉起编译、单元测试和部分集成测试 | 敏捷开发、快速反馈 |
在车端系统中，整体上我们采用自底向上的集成策略，底层软件、软件平台、上层应用逐级集成。各个子系统采用沙盒集成策略，在独立环境或者最新的发布版本环境中单独验证子系统，验证通过后再合入主分支集成。对于每个模块，通过持续集成的方式在每次代码合并前拉起编译、测试、静态检查等检查项。
验证策略
验证策略的目标是在各个阶段及早的发现并修正问题，确保功能符合需求预期，保证系统鲁棒性。同时能够支撑相关认证(如ISO 26262、ASIL、ASPICE)等。常见的策略如下：
| 验证环节 | 验证内容 | 适用阶段 |
|---|---|---|
| 单元测试（Unit Test） | 针对最小可测单元（函数/类）做验证 | 开发阶段 |
| 模块测试（Module Test） | 验证单一模块功能、边界、接口符合预期 | 模块完成后 |
| 集成测试（Integration Test） | 验证模块之间交互、接口兼容、数据传递正确 | 模块集成阶段 |
| 系统测试（System Test） | 验证整个系统的功能、性能、稳定性、用户场景覆盖 | 系统集成后 |
| 回归测试（Regression Test） | 每次修改后验证旧功能依然可用 | 持续集成/迭代交付中 |
| 静态分析（Static Analysis） | 工具化扫描代码风格、内存安全、MISRA、CERT、复杂度等 | 开发/持续集成 |
| 动态分析（Dynamic Analysis） | 运行时监测内存、CPU、线程、性能热点、死锁 | 调试/性能验证 |
| 模拟/仿真（Simulation） | 用 HIL/SIL/MIL 等模拟环境验证系统在真实条件下的表现 | 嵌入式/车载开发 |
| 场景回放验证（Replay Test） | 在感知/智能驾驶中用实车或数据集回放传感器、车辆轨迹验证算法 | 感知/决策/规划模块 |
| 实车验证（On-vehicle Test） | 将系统部署到真实车辆进行道路环境下的综合验证 | 验证阶段末期 |
对于模型来说，验证项差不多，验证内容变成模型相关的指标；
| 验证环节 | 验证内容 | 说明 |
|---|---|---|
| 单元验证 | 训练、推理是否能正常完成 | 含边界值、异常值等 |
| 功能验证 | 模型是否符合任务目标 | 如检测召回率、分割 IoU、分类准确率 |
| 性能验证 | 速度、内存、延迟、吞吐量是否达标 | 特别是在目标硬件上如Orin、MCU |
| 回归验证 | 新模型对比基线模型无性能退化 | 指标下降要阻止合入 |
| 场景验证 | 典型/极端场景中模型表现 | 智能驾驶中常用离线回放场景集 |
| 鲁棒性验证 | 输入噪声、分辨率变化、光照等干扰下表现 | 真实场景不可避免波动 |
| 泛化验证 | 新场景/未见环境数据上的泛化能力 | 避免过拟合 |
| 偏差验证 | 数据分布、预测结果中的潜在偏差 | 符合公平性、合规性需求 |
注：每个验证阶段都应该定义相应的准入准出条件，这里暂做遗留，后续单独展开。
版本策略
版本策略的核心目标是保证软件版本的可追溯性和可管理性，支持并行开发、快速修复和稳定发布，明确版本计划和版本管理方式。
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 语义化版本（SemVer） | 使用 MAJOR.MINOR.PATCH 表示破坏性、兼容性、新功能 | 公共 API、对外 SDK/软件包 |
| 时间戳版本 | 使用日期（2024.06.27）表示版本 | 内部快速迭代、敏捷开发 |
| 分支管理 | master/dev + feature/hotfix 分支模型 | 团队规模化开发、版本并行维护 |
| 标签管理 | 每次集成成功后在主分支打 tag | 交付节点、回溯调试 |
基于以上策略，制定合适的版本号规范和版本流转流程，前面的各种策略按照版本管理流程制定可量化的规则条件并应用于版本管理中。
核心环节
DevOps 有 8 个核心环节：
| 阶段 | 英文术语 | 主要工作内容 |
|---|---|---|
| 1️⃣ 规划 | Plan | 需求分析、任务规划、需求拆分（如 Jira、Confluence） |
| 2️⃣ 开发 | Develop | 编码、代码提交、版本控制（如 Git、IDE） |
| 3️⃣ 构建 | Build | 编译、构建镜像、依赖分析（如 Make, CMake, Docker） |
| 4️⃣ 测试 | Test | 单元测试、集成测试、接口测试（如 gtest, pytest, sonar） |
| 5️⃣ 发布 | Release/Integrate | 持续集成、代码合并、版本打包（如 GitLab CI, Jenkins） |
| 6️⃣ 部署 | Deploy | 自动部署、灰度发布、回滚机制（如 K8s, Ansible, Helm） |
| 7️⃣ 运营 | Operate | 系统运维、资源管理、容器调度（如 Prometheus, Kubernetes） |
| 8️⃣ 监控 | Monitor | 性能指标、日志分析、告警系统（如 Grafana, ELK） |
各环节涉及的角色及职责：
| 阶段 | 主要角色 | 职责说明 |
|---|---|---|
| 1️⃣ 规划 | - 产品经理（PM） - 系统架构师（SA） - 项目经理/版本经理/EO（Engineering Owner） - QA |
- 定义系统目标与需求 - 规划功能拆解、技术路径 - 制定版本迭代节奏 - 评估规划和设计质量，回溯，流程优化 |
| 2️⃣ 开发 | - 模型训练/部署工程师 - 算法/开发工程师 - 嵌入式工程师 - 仿真平台开发 - 测试开发工程师 - QA |
- 编写训练框架、部署框架，模型训练、校准、部署 - 编写核心模块代码、实现算法功能 - 集成传感器 SDK、芯片 SDK - 实现仿真功能 - 编写测试框架、测试用例 - 评估开发质量，回溯，流程优化 |
| 3️⃣ 构建 | - CI/CD 工程师 - DevOps 工程师 - 基础平台工程师 - QA |
- 配置 CMake 等构建系统 - 实现编译流水线（如 Jenkins + Docker） - 管理依赖和构建缓存 - 评估构建质量 |
| 4️⃣ 测试 | - 测试工程师（TE） - 仿真测试工程师 - QA |
- 单元测试/功能测试/回归测试 - 基于仿真平台仿真 - 评估测试质量（覆盖率、漏测率等），回溯，流程优化 |
| 5️⃣ 发布 | - 版本管理员 - 集成工程师 - 配置管理工程师 |
- 打包发布软件版本 - 管理 OTA 策略 - 跟踪依赖变更、回滚机制 |
| 6️⃣ 部署 | - 车端软件集成工程师 - 平台运维 - 验证工程师 |
- 将系统部署至 HIL/SIL/实车环境 - 管理版本升级与兼容性测试 |
| 7️⃣ 运营 | - 运维工程师 - 数据平台工程师 - 市场运营 - QA |
- 实时监控系统状态 - 数据采集/清洗/闭环回流 - 市场调研、市场反馈、产品推广、客户运营 - 评估产品质量，回溯，流程优化 |
| 8️⃣ 监控 | - 监控平台开发 - 观测器（Observer）系统开发者 - 数据分析师 |
- 建立观测系统（Log/指标/异常追踪） - 实现 KPI 报警、自动化 root cause 定位 - 监控模型漂移（Model Drift） |
规划 - Plan
Plan 阶段是 DevOps 生命周期的起点，其核心目标是收集并确认业务需求、技术需求，制定可执行的开发 & 运维计划；定义交付里程碑、验收标准；规划资源：人力、硬件、预算；明确沟通、审批、变更管理流程。Plan 阶段做得好，后续的 DevOps 流程才能高效无阻。
Plan 阶段的关键活动：
| 活动 | 说明 |
|---|---|
| 需求收集 | 与产品/客户确认功能、性能、合规等需求 |
| 优先级排序 | 确定 backlog，排定迭代计划 |
| 工作拆解 | 将需求拆分为智能驾驶、模型、云服务工具链三部分的可执行的任务、Story、Bug |
| 制定时间表 | 明确交付周期、里程碑、关键节点 |
| 风险识别 | 识别潜在技术/资源/依赖风险并制定应对措施 |
| 资源分配 | 明确开发、测试、运维、DevOps 平台等所需资源 |
| 环境规划 | 设计开发、测试、台架、测试车、采集车等各环境的搭建和管理方案 |
| 验收标准制定 | 定义功能完成标准、回归指标、上线门槛 |
Plan 阶段的核心产出：
- 产品/功能需求文档，设计文档，编程规范等
- 迭代计划（Sprint Plan、Release Plan）
- WBS（工作分解结构）
- 关键里程碑定义
- 风险清单及应对策略
- 版本计划与发布排期
- 环境和资源申请清单
开发 - Develop
软件代码
Develop 阶段的核心目标是根据 Plan 阶段的需求，将功能、问题或改进转化为高质量、可维护的代码；通过代码审查和静态分析保障代码质量；保证开发过程中的版本一致性与可追溯性；为后续持续集成（CI）奠定基础。
Develop 阶段的关键活动：
| 活动 | 说明 |
|---|---|
| 环境准备 | 确保开发环境与集成环境一致（依赖版本、操作系统、编译器等），如使用Docker镜像 |
| 代码编写 | 按照规范、需求编写可维护、可扩展的代码 |
| 单元测试开发 | 编写单元测试、mock，保证代码功能符合预期 |
| 静态代码分析 | 在本地或 CI 里集成 clang-tidy、cppcheck、SonarQube、coverity、blackduck 等工具 |
| 代码审查（Code Review） | 使用 Gerrit、GitLab MR 等做评审，提高代码质量 |
| 版本管理 | 按照分支策略提交、合并，并关联到对应的需求、任务、Bug，保证可回溯 |
| 编码规范执行 | 使用 clang-format、pylint 及人工审查等做代码风格统一 |
| 本地验证 | 在本地运行构建、测试、lint，保证代码可通过基本检查 |
Develop 阶段最佳实践：
- 小步提交：每次提交都应具备可编译、可通过单测的质量
- 分支管理：遵循 Git Flow 或 trunk-based，避免长期分支积压
- 提交信息规范：使用语义化提交，概述提交的内容
- 测试驱动开发（TDD），或者至少同时写单测
- 自动化检查：在提交前 hook 或合并前执行 lint、格式化、单测
Develop 阶段常见挑战：
- Q: 不同开发人员使用不同环境，可能导致“works on my machine”问题
- A: 使用 Docker 容器或 dev container 保证一致性
- Q: 代码合并时引入冲突或回归
- A: 频繁拉取主干、CI 自动回归测试
- Q: 代码质量参差不齐
- A: 强制代码审查、静态分析、统一风格检查
模型
模型 Develop 阶段核心目标是基于采集数据理解问题，完成模型设计；快速实现新模型架构或改进现有模型；在样本或小数据集上做初步训练和验证；反复调优模型结构、损失函数、后处理等；输出第一个能在仿真/离线评测中具备初步可用性的模型。
模型 Develop 阶段的关键活动：
| 活动 | 说明 |
|---|---|
| 问题定义 | 确定模型任务（如目标检测、语义分割、轨迹预测等），明确输入输出 |
| 数据探索 | 对样本做可视化、统计分析、分布验证，发现样本问题或模型盲区 |
| 特征工程 | 设计输入特征、归一化方案、数据增强策略 |
| 模型设计 | 设计神经网络架构，如 YOLO/CenterPoint/Transformer 等 |
| 模型实现 | 基于 PyTorch、TensorFlow、MindSpore 等框架实现 |
| 训练流程 | 构建初步训练脚本，配置损失函数、优化器、学习率策略等 |
| 验证脚本 | 编写指标计算脚本，如准确率、mAP、IoU、RMSE 等 |
| 性能初步评估 | 在验证集或特定场景数据上测试模型的可行性 |
| 代码规范 | 遵循团队代码标准，并完成基础单元测试 |
Develop 阶段最佳实践：
- 设计输入输出接口对接感知/规划模块，提前考虑端到端部署可用性
- 使用小规模先行验证模型有效性，避免大规模训练资源浪费
- 模型初版实现也要写测试样例，防止 early bugs 进入后期集成
- 通过 Notebook + Dashboard 定期展示模型结果和场景样例，方便团队协作
- 保留模型 checkpoint，并配合元数据记录用于后续对比和追溯
Develop 阶段常见问题：
- Q: 过拟合小场景，线上泛化差
- A: 数据增强、多场景样本混合训练、交叉验证
- Q: 模型指标看起来好，但特定场景失效
- A: 设计场景覆盖度评测脚本、分场景指标统计
- Q: 训练数据和线上环境不一致
- A: 使用仿真或插入端到端处理链做验证，确保一致性
构建 - Build
软件代码
Build 阶段核心目标是把源代码转换成可执行文件、库、镜像或其他交付物；生成可用于部署、测试的工件，并保证可重现性；及时发现编译错误、依赖冲突等问题；提供一致、自动化、标准化的构建流程。
Build 阶段关键活动：
| 活动 | 说明 |
|---|---|
| 依赖管理 | 下载、验证依赖版本，防止不兼容 |
| 编译/打包 | 编译源代码，链接生成目标文件，打包为安装包、容器镜像等 |
| 构建缓存 | 利用缓存减少重复构建时间 |
| 版本信息注入 | 在构建产物中写入 commit ID、时间、分支等元信息 |
| 单元测试执行 | 构建后立即跑单测验证构建有效性 |
| 工件签名/哈希 | 保证交付物完整性、防止篡改 |
| 构建产物存储 | 上传到 Artifactory、Nexus、Harbor、OBS 等仓库统一管理 |
Build 阶段最佳实践：
- 自动化构建：通过 CI 平台在提交合并时触发自动构建
- 幂等性：同样输入（代码、配置、依赖）生成的工件要一致
- 隔离环境：构建过程应在干净环境中运行（如 CI runner 或 Docker），避免「我机器上能编译」的问题
- 版本元数据：在构建产物中注入 commit ID、分支、编译时间，如可执行文件输出：
- 构建缓存：加速 CI，避免每次全量下载代码，全量编译
Build 阶段常见挑战：
- Q: 编译环境不一致，导致 CI 通过但生产环境失败
- A: 在 CI 里用 Docker 统一环境
- Q: 构建时间过长，降低迭代效率
- A: 使用分布式构建、增量构建
- Q: 工件缺乏管理，无法回滚
- A: 构建产物集中上传到工件仓库，并在版本管理系统里记录可追溯信息
- Q: 开发、测试、版本等不同人员对工件诉求不一样
- A: CI 工程师熟悉整个开发调测流程，提升流程各个环节的使用体验
Build 阶段产物：
- 可执行文件、动态/静态库
- 容器镜像
- 软件包（.deb/.rpm/.zip）
- 文档、API 说明
- 元信息文件（含版本、编译环境等）
- 单元测试报告，静态扫描报告等
- 冒烟测试报告
模型
Build 阶段核心目标是将模型转换为高效的部署格式（如 TensorRT、ONNX、TFLite、或自研二进制格式）；将前处理、模型、后处理链打包成一致的 pipeline；静态编译或交叉编译所需的 C++/CUDA 算子（跟随软件代码开发）；校验模型在目标硬件上的推理正确性与性能；为 OTA、工厂烧录、仿真环境提供标准化可部署模型产物。
Build 阶段关键活动：
| 活动 | 说明 |
|---|---|
| 模型导出 | 将 PyTorch/TensorFlow 模型导出为 ONNX 或其他中间格式 |
| 模型优化 | 使用 TensorRT、ONNX Graph Optimization 等做量化、合并、融合算子 |
| 平台适配 | 针对 Orin/Thor 或其他 ECU 平台进行硬件兼容验证 |
| 算子编译 | 针对自定义 CUDA/C++ 算子进行交叉编译，确保车端可用 |
| Pipeline 封装 | 前处理、主模型、后处理组成整体 pipeline，方便调用和集成 |
| 功能一致性验证 | 确保模型优化后在输出精度上与训练时基本一致 |
| 性能基准测试 | 在目标硬件上测试推理耗时、资源占用，并输出性能报告 |
| 产物打包 | 产出模型文件、版本元信息、必要脚本及依赖库清单 |
Build 阶段最佳实践：
- 在 CI 流水线中自动化完成模型转换、优化、打包、验证
- 模型输出在优化前后必须做 diff，确认数值精度在可接受范围
- 为每个模型产物生成唯一 hash 与元数据，方便后续追溯
- 在不同硬件环境（Orin/Thor/PC）上都要做基准性能验证
- 对可执行文件、库、模型产物进行签名，保证交付安全性
Build 阶段常见挑战：
- Q: 优化后模型数值漂移
- A: 加入基线输出比对脚本，自动检测误差是否超标
- Q: 目标硬件兼容性问题
- A: 使用车端交叉编译环境+硬件 in the loop（HIL）测试
- Q: 算子不支持优化工具
- A: 开发自定义 Plugin，并集成到 TensorRT/ONNX Runtime
- Q: 模型推理延迟高
- A: 优化模型结构，选择合适的精度，使用高效的推理引擎，结合批处理和异步处理
测试 - Test
软件
Test 阶段核心目标是验证构建产物满足功能、性能和非功能性需求；及时发现并反馈问题，阻止缺陷进入生产；提供可量化、可追溯的测试结果；将测试自动化，提高覆盖率、降低回归成本。
Test 阶段关键活动：
| 活动 | 说明 |
|---|---|
| 单元测试 | 验证每个函数/类在隔离环境下的正确性 |
| 集成测试 | 验证多个模块/组件组合后的接口和协作 |
| 功能测试 | 验证系统满足业务需求的功能完整性 |
| 回归测试 | 确保修改/新增功能不会破坏已有功能 |
| 性能测试 | 评估系统在负载下的响应时间、吞吐量 |
| 安全测试 | 检查常见漏洞（XSS、SQL注入、身份验证缺陷等） |
| UI/端到端测试 | 以用户视角验证整个流程的正确性 |
| 静态代码扫描 | 分析代码缺陷、潜在漏洞 |
注：其中单元测试、静态代码扫描、部分集成测试一般在开发构建阶段实施。根据测试策略，构建阶段自动触发冒烟回归测试等。
Test 阶段最佳实践：
- 左移测试：越早发现问题，修复成本越低；单元测试应在开发期间完成
- 测试自动化：让 CI 触发后能自动跑单元、集成、功能测试
- 覆盖率监控：量化单元测试覆盖率，如行覆盖 80%+ 为合入门槛
- 分层测试：优先覆盖核心逻辑的单元和集成测试，再补充端到端测试
- 测试数据管理：保证测试数据可控、可重复、脱敏（防泄漏）
- 并行化执行：用并行任务执行，加速测试过程
- 结果报告：CI 自动生成可读的测试报告，并能上传到平台供查阅
Test 阶段常见挑战：
- Q: 单测覆盖率不足 → 遗漏回归问题
- A: 强制覆盖率检查，并纳入合并门槛
- Q: 测试执行太慢 → 拉低迭代效率
- A: 将测试拆分到并行任务执行
- Q: 依赖外部服务导致测试不稳定
- A: 使用 mock 或 stub 隔离外部依赖
- Q: 仅功能测试缺乏性能/安全保障
- A: 为每次发布集成性能测试和安全扫描
Test 阶段核心产物
- 自动化测试报告（HTML/JUnit 格式）
- 测试覆盖率报告
- 性能测试结果
- 安全扫描结果
- 测试日志 & 回归追踪记录
模型
Test 阶段核心目标是验证模型是否在全量数据集和重点场景中表现稳定；验证模型在目标硬件（如 NVIDIA Orin/Thor）上性能是否达标；评估 Corner Case、长尾场景、失效场景中的表现；保证新版本与旧版本之间的性能一致性（回归测试）；支撑自动化 CI 流水线闭环，形成上线前“质量关卡”。
Test 阶段关键活动：
| 活动 | 说明 |
|---|---|
| 功能测试 | 检查模型输出是否合理，是否符合输入输出协议、shape、值域等要求 |
| 精度评估 | 使用标注数据计算 mAP、IoU、RMSE、ADE/FDE 等指标 |
| 场景覆盖测试 | 分城市、天气、光照、道路类型等统计模型表现 |
| 失效检测 | 检查模型是否在特定异常输入下崩溃或输出异常（NaN、Inf、空） |
| 性能测试 | 推理耗时、帧率、CPU/GPU 使用率、功耗测试等 |
| 资源一致性测试 | 验证内存泄露、线程数异常等运行时资源问题 |
| 回归测试 | 对比旧模型版本，验证新模型没有引入性能或功能退化 |
| 模拟测试 | 在仿真环境中运行模型，验证整体驾驶行为是否安全可控 |
Test 阶段最佳实践：
- 构建 CI 自动评测流水线：每次提交后跑全套验证流程
- 设计分场景评测报告：比如在“隧道”、“大雨”、“夜晚”等重点场景下单独出报表
- 与感知/规划/控制等模块联测：测试模型是否影响上下游模块的正确性和鲁棒性
- 添加安全回归用例：保证模型不会在 Corner Case 中反复失效
- 性能与精度共同评估：性能未达标即使精度高也不能上线
Test 阶段常见挑战：
- Q: 模型指标提升但上线表现变差
- A: 需要加场景评估和联测闭环，不仅看数字
- Q: 模型对输入分布偏移敏感
- A: 加入数据增强和鲁棒性评测
- Q: 新模型部署性能下降
- A: 优化后处理、BatchSize、绑定CPU亲和性
发布 - Release
云服务
Release 阶段核心目标是确保经过验证的工件被安全、稳定、可控地发布到生产或目标环境；管理发布节奏，减少变更对生产的风险；提供回滚和补丁机制应对线上问题；沟通协调各角色（开发、测试、运维、产品）做好上线准备。
Release 阶段关键活动：
| 活动 | 说明 |
|---|---|
| 版本归档 | 标记稳定版本（Tag）、记录元数据（commit ID、分支、时间等） |
| 产物签名 | 对发布包、容器镜像等做哈希校验或数字签名 |
| 发布文档编写 | 包含变更记录、升级指南、已知问题、兼容性说明 |
| 发布批准 | 由研发/产品/运维等负责人共同审核并签字/审批 |
| 灰度/蓝绿发布 | 先向部分用户发布观察表现，再逐步全量上线 |
| 回滚方案准备 | 明确发布失败或回归问题时的撤销、回滚步骤 |
| 发布通知 | 向利益相关方同步版本变更、上线计划和状态 |
Release 阶段最佳实践：
- 自动化发布流程：Release 流程应尽可能在 CI/CD 中自动化，减少人工操作
- 稳定窗口发布：选择低峰时段或运维窗口发布，便于快速定位问题
- 小步快跑：避免大规模改动同时上线，控制每次变更范围
- 发布可追溯：每个发布记录需包含版本号、提交信息、执行人、时间等元数据
- 回滚机制：生产环境出现严重问题时可快速回滚到上一个稳定版本
- 多环境验证：在预生产环境完成和生产环境一致的验证，保证无环境差异
Release 阶段常见挑战：
- Q: 生产环境不一致导致发布后表现异常
- A: 用基础设施即代码（IaC）保持各环境一致
- Q: 发布步骤复杂、手动操作易出错
- A: 用脚本或 CD 平台标准化并自动化发布过程
- Q: 无回滚方案或回滚困难
- A: 每次发布前都明确回滚步骤并在预生产环境验证
- Q: 变更对客户或依赖系统影响不可控
- A: 采用灰度、蓝绿等渐进式发布，并加强监控
Release 阶段核心产物：
- 发布包（可执行文件、Docker 镜像、安装包等）
- 发布记录（Tag、Release Notes、审批记录）
- 回滚方案及验证记录
- 发布计划/排期表
- 已知问题 & 解决方案
智驾系统
Release 阶段核心目标是确认交付的软件/模型版本稳定且符合质量标准；完成版本封装与元数据管理，确保可追溯；通过安全、法规合规性审核；制定灰度发布、回滚和风险应对方案。
Release 阶段关键活动：
| 活动 | 说明 |
|---|---|
| 版本冻结与打包 | 冻结版本代码、模型，制作产物包（包含元数据、文档） |
| 版本管理 | 确保版本号唯一且有详细变更日志 |
| 合规审查 | 符合ISO 26262、ASPICE、安全合规及法规要求 |
| 发布计划制定 | 制定灰度策略、分批次上线、监控预案 |
| 测试验证复核 | 对照测试报告复核关键性能与安全指标 |
| 部署准备 | OTA推送准备、工厂烧录流程确认 |
| 回滚预案 | 制定异常情况下的快速回退方案 |
Release 阶段最佳实践：
- 版本管理规范：版本号需严格遵循语义化，记录完整变更历史
- 多级审批流程：发布前必须经过技术、安全、法规多部门审批
- 灰度发布：先在小范围车队或特定区域部署，监控效果后再全量推广
- 应急回滚：版本上线前必须准备快速回滚方案，保证安全
- 数据追踪：上线后实时收集运行数据，监控异常和模型性能退化
- 文档齐备：包含详细的版本说明、安全风险提示、已知问题列表
Release 阶段常见挑战：
- Q: 上线版本不稳定
- A: 制定严格的灰度和回滚机制
- Q: 合规审核不过关
- A: 提前介入法规专家参与，确保文档齐全
- Q: 版本管理混乱
- A: 强制使用自动化工具和流程，避免人工错误
- Q: 部署失败或不兼容
- A: 完善硬件兼容性测试，提前做全链路集成测试
部署 - Deploy
云服务
Deploy 阶段核心目标是将验证合格的版本平稳、安全地部署到生产或目标环境；保证部署过程可重复、自动化、可追溯；降低对用户的影响，并具备快速回滚能力；与监控、告警联动，及时发现上线问题。
Deploy 阶段关键活动：
| 活动 | 说明 |
|---|---|
| 部署前准备 | 检查环境、依赖、配额、健康状态 |
| 自动化部署 | 脚本或 CD 平台自动化将工件部署到服务器或容器 |
| 配置管理 | 使用统一配置中心或环境变量管理不同环境下的参数 |
| 数据迁移 | 执行数据库 schema、数据填充等迁移操作 |
| 变更验证 | 部署完成后做 smoke test，确认核心功能可用 |
| 部署监控 | 启动后持续监控日志、资源使用、核心指标 |
| 回滚策略 | 明确部署失败时撤销的步骤 |
| 部署后通知 | 向研发、运维、产品等相关方同步上线状态 |
Deploy 阶段最佳实践：
- 部署自动化：避免人工操作，减少风险并提升效率
- 环境幂等性：重复部署同一个版本不应引入额外问题
- 渐进式部署：灰度发布、蓝绿部署或 canary，先验证小批流量，再扩大范围
- 配置分离：代码和配置分离，通过环境变量、配置中心切换环境
- 部署自检：部署完立即运行自动化 smoke test 验证基本功能
- 联动监控：部署后自动检测 CPU/内存/请求错误率等异常波动
- 回滚机制：部署流程应支持快速回退，并验证回退有效性
Deploy 阶段常见挑战：
- Q: 部署时间过长，导致服务中断
- A: 使用容器或分布式架构，逐步替换实例减少影响
- Q: 配置错误导致部署完成后异常
- A: 在 CI/CD 中加入配置校验或 lint
- Q: 数据库 schema 变更不兼容
- A: 数据库迁移需要向后兼容或支持双写期
- Q: 环境不一致导致部署后问题
- A: 用 IaC（Terraform、Ansible）保持环境一致
Deploy 阶段核心产物：
- 部署日志
- 成功/失败状态报告
- 配置变更记录
- smoke test 结果
- 部署后的监控数据快照
智驾系统
Deploy 阶段核心目标是将模型和软件安全、高效地部署到目标硬件（车载ECU、边缘设备、仿真平台）；保证部署过程自动化、标准化，降低人工干预和出错风险；配置必要的运行环境和依赖，确保软件稳定运行；支持远程部署（OTA）和本地刷写，满足不同场景需求；实施部署验证，确保模型正常加载、推理和响应。
Deploy 阶段关键活动：
| 活动 | 说明 |
|---|---|
| 部署包下发 | 将Release产物推送到目标设备或刷写到存储介质 |
| 运行环境配置 | 配置操作系统、驱动、中间件、依赖库版本 |
| OTA部署支持 | 实现空中下载更新，支持增量升级和安全回滚 |
| 部署自动化 | 编写自动化脚本/流水线，支持批量设备快速部署 |
| 启动验证 | 启动模型推理服务，检查初始化成功、无异常 |
| 资源监控 | 监控CPU、GPU使用率、内存占用及温度等指标 |
| 日志采集 | 配置日志上传和远程诊断接口，便于后续排查 |
| 部署文档 | 制定详细部署手册和应急恢复方案 |
Deploy 阶段最佳实践：
- 自动化部署流水线，减少手动错误，提升效率和一致性
- 多环境适配，针对不同硬件平台做差异化配置和验证
- 灰度发布与监控，逐步扩大部署范围，实时监控关键指标
- 安全保障，通过签名校验、防篡改和安全启动保证部署安全
- 日志与诊断，部署时即配置好日志采集，方便后续运维支持
Deploy 阶段常见挑战：
- Q: 不同硬件兼容性
- A: 维护硬件配置清单，自动适配部署包
- Q: 部署失败难排查
- A: 详细日志，远程诊断能力，自动回滚机制
- Q: OTA升级失败风险
- A: 增量升级、校验机制、灰度发布策略
- Q: 环境依赖复杂
- A: 按车型统一解决方案，复杂环境依赖配套版本化
运营 - Operate
云服务
Operate 阶段核心目标是确保生产环境系统长期稳定、性能达标、高可用；主动监控系统健康状况，快速检测并修复故障；收集运行指标，为后续优化、扩容、回归分析提供依据；持续进行安全加固和资源管理，保障服务安全、成本可控。
Operate 阶段关键活动：
| 活动 | 说明 |
|---|---|
| 系统监控 | 收集 CPU、内存、IO、QPS、延迟、错误率等指标 |
| 日志采集与分析 | 集中收集应用、系统、审计日志，支持问题排查 |
| 资源管理 | 动态管理 CPU、内存、带宽、存储等资源，避免资源瓶颈 |
| 异常检测与告警 | 配置阈值、告警规则，实现自动化告警 |
| 自动化运维脚本 | 常用任务（扩容、备份、修复）的脚本化，降低人工操作风险 |
| 安全管理 | 及时更新补丁、管理凭据、检测入侵 |
| SLA/SLO 监控 | 监控并评估服务可用性和性能是否符合对用户承诺的 SLA/SLO |
| 成本优化 | 根据指标分析，释放或调整资源，降低运营成本 |
Operate 阶段最佳实践：
- 可观测性建设：三大支柱：日志（Logging）、指标（Metrics）、追踪（Tracing）
- 自动化修复：故障自动恢复脚本，如 pod 宕机自动重启
- 最小权限原则：生产环境账号、API token 等权限最小化
- 灾备演练：定期在预生产环境做灾难恢复演练
- SLA/SLO 持续监控：将业务指标转化为 SLO，并与告警系统联动
- 容量规划：根据趋势预估未来资源需求，提前扩容或优化架构
Operate 阶段常见挑战：
- Q: 指标/日志收集不全 → 无法准确定位线上问题
- A: 完善可观测性体系，并定期验证覆盖率
- Q: 告警风暴 → 太多无效告警掩盖真正问题
- A: 优化告警规则、设置合理阈值、引入告警合并
- Q: 缺乏自动化 → 故障处理依赖人工，响应慢
- A: 用自动化运维脚本和自愈系统替代重复人工操作
- Q: 安全漏洞暴露 → 长期未更新依赖或系统补丁
- A: 定期扫描并自动化补丁更新
Operate 阶段核心产物：
- 系统运行指标大盘（如 Grafana Dashboards）
- 日志归档与检索接口
- 告警记录与处理报告
- 安全审计日志
- 资源使用和成本分析报告
智驾软件
Operate 阶段核心目标是保证智能驾驶功能在生产车辆上的长期稳定性、安全性、可靠性；实时监控车辆状态、模块健康、环境变化，及时发现并处理异常；持续收集数据，支持模型迭代和功能优化；通过 OTA（Over-The-Air）维护和更新软件。
Operate 阶段关键活动：
| 活动 | 说明 |
|---|---|
| 车辆在线监控 | 实时上报各 ECU、传感器、智能驾驶域控（DCU）健康状态 |
| 关键指标采集 | 如感知延迟、规划频率、车辆控制误差、定位漂移等 |
| 安全状态管理 | 定时做自检，包括传感器自诊断、功能安全机制（ASIL）检测 |
| OTA 管理 | 远程更新软件版本、参数配置，并记录更新状态 |
| 异常日志采集 | 发生故障时抓取系统快照（sensor dump、core dump）用于排查 |
| 数据回传 | 收集特定路况、Corner Case 等数据，用于模型再训练 |
| 远程协助和诊断 | 当出现疑难问题，可远程接管或辅助分析 |
| 安全保障机制 | 如 L3/L4 车辆在模块异常时平稳退出自动驾驶模式 |
Operate 阶段最佳实践：
- 多层监控体系：ECU 级、域控级、整车级，三级监控保证全链路健康
- 模块健康自检测：周期性对感知、定位、规划模块做自检
- 闭环数据流：从车辆到云端的数据自动回传、自动分析、自动触发改进
- 分级告警机制：严重告警（如感知失效）直接触发紧急停车，中低级告警通知后台
- 自动 OTA 回滚：OTA 更新失败时可自动回退到上一个稳定版本
- 法规合规性：保证符合 ISO 26262、ISO/PAS 21448（SOTIF）、UN-R155/156 等标准
Operate 阶段常见挑战：
- Q: 大规模车队中车辆分布广，运维成本高
- A: 采用集中云管平台 + OTA + 远程诊断
- Q: Corner Case 触发概率低，难以主动发现
- A: 通过智能数据标注和云端聚类，识别潜在问题
- Q: 实车环境变化大（天气、光线、道路）导致系统不稳定
- A: 持续回传多样化数据，更新模型并灰度部署验证
智驾模型
Operate 阶段核心目标是部署在车端或边缘端后，需保持稳定、低延迟、资源占用受控；实时监控推理耗时、准确率变化、置信度分布、Corner Case 出现频率等；模型输出不合理（如大面积漏检）时触发告警并记录上下文数据；将失败样本、低置信样本、特定环境数据回传到云端用于持续迭代；模型支持 OTA、灰度发布，确保新模型上线不会带来大面积回归。
Operate 阶段核心活动：
| 类别 | 活动 | 说明 |
|---|---|---|
| 模型监控 | 模型推理耗时监控 | CPU/GPU/DLA 端推理时间稳定性 |
| 模型结果监控 | 漏检率、误检率、置信度漂移，输出结果一致性 | |
| 资源占用 | 推理进程内存占用、显存、温度等 | |
| 异常处理 | 动态 Fallback | 如感知模型失效可切入规则逻辑或简化模型 |
| 自动日志&数据打包 | 出现异常结果时自动上传模型输入、输出、上下文 | |
| 数据闭环 | 场景触发回传 | 特定天气/光照/路况等场景自动采集上传 |
| 标注与训练联动 | 标注团队对反馈数据快速处理并触发新一轮训练 | |
| OTA 支持 | 模型热更新 | 模型支持动态加载或重启加载（如 TensorRT、ONNX） |
| 模型版本管理 | 支持 hash 校验、切换回滚、版本审计等能力 |
注：模型OTA一般跟随智驾软件，整个智驾系统OTA，模型往往与前后处理代码强相关。
Operate 阶段最佳实践：
- 边车模型观测器设计：在感知/预测模块旁部署轻量 agent，专门采集模型输出统计信息与推理指标
- Corner Case 捕捉策略：比如检测空车道误识别为行人、红绿灯误判等，标记回传
- 灰度模型上线流程：基于 VIN 白名单/地图区域逐步部署，保障控制安全性
- 与 CI/CD 流水线联动：模型上线前后自动验证关键路径，确保无回归
- 场景标签化反馈数据：为采集回来的数据打上标签（如“夜间-雨天-遮挡”），方便下一轮训练精准选样
监控 - Monitor
云服务
Monitor 阶段核心目标是实时、全面地观察系统和业务状态；及时发现性能、可用性、异常趋势；提供量化数据支持后续优化、容量规划、产品迭代；形成自动化告警体系，将问题第一时间推送到责任人。
Monitor 阶段关键活动：
| 活动 | 说明 |
|---|---|
| 指标收集 | 采集系统和应用的 CPU、内存、IO、响应时间、QPS 等指标 |
| 日志收集 | 集中收集、存储并分析应用和系统日志 |
| 分布式追踪 | 记录请求在多系统间流转的过程，定位链路瓶颈 |
| 用户体验监测 | 检测页面加载速度、API 失败率、App 崩溃率等 |
| SLA/SLO 监控 | 跟踪并验证服务可用性是否达成对客户承诺 |
| 告警系统集成 | 对超阈值或异常指标自动触发告警并通知相关人员 |
| 仪表盘与可视化 | 以图表、看板形式展示核心指标，便于持续关注和对比 |
Monitor 阶段最佳实践：
- 覆盖全栈监控：应用、数据库、中间件、网络、主机指标都应覆盖
- 三大可观测性支柱：指标（Metrics）、日志（Logs）、追踪（Tracing）统一分析
- 告警降噪：避免告警风暴，通过告警合并、静默期、优先级等减少误报
- 服务级别目标（SLO）：将可用性指标与业务目标挂钩，比如「99.9% 的 API 成功率」
- 与 CI/CD 联动：上线后持续观察核心指标，自动回滚有问题的版本
- 自动化容量预测：用监控数据驱动资源扩容或架构优化
Monitor 阶段常见挑战：
- Q: 只监控系统层面，缺乏业务指标
- A: 在应用中埋点，采集关键业务流程指标
- Q: 指标不一致或标准混乱
- A: 制定统一的监控指标规范
- Q: 告警频繁误报，导致运维疲劳
- A: 优化阈值、采用自适应告警或基于机器学习的异常检测
- Q: 可观测性孤岛：指标、日志、追踪分散在不同系统
- A: 采用集中可观测性平台（如 Elastic Observability、Grafana Cloud、Datadog）
Monitor 阶段核心产物：
- 监控仪表盘（Dashboard）
- 指标时序数据库（TSDB）
- 告警规则配置和记录
- SLA/SLO 报表
- 追踪数据和链路拓扑
- 分析报告（周/月/季度健康度
智驾软件
Monitor 阶段核心目标是持续收集并可视化整车和核心算法模块的运行状态；快速发现感知、定位、规划、控制等关键模块的性能异常；记录环境、驾驶行为、Corner Case 等情况，为模型迭代提供数据；支持异常自动告警，提前发现潜在风险并联动自动化处理。
Monitor 阶段关键活动：
| 活动 | 说明 |
|---|---|
| 系统健康监控 | 监控域控（DCU）、各 ECU、电源、传感器硬件状态 |
| 模块性能监控 | 监测感知帧率、延迟、定位精度、规划频率、控制误差等指标 |
| 环境与驾驶状态监控 | 记录天气、光线、路面状况、驾驶员接管频率等 |
| 车队状态聚合 | 云端汇总每辆车上传的数据，形成全车队健康大盘 |
| 数据可视化 | 在云端仪表盘上实时展示车辆状态、核心指标、告警分布 |
| 异常告警 | 配置指标阈值，自动触发本地或云端告警 |
| 日志和数据归档 | 异常情况下保存快照用于排查，正常运行中做定期归档 |
Monitor 阶段最佳实践：
- 多级监控：车载本地实时监控 + 云端汇总监控
- 指标与事件结合：对连续异常（如定位漂移）和突发事件（传感器掉线）都要监测
- 指标阈值动态调整：环境差异大，可用 AI 或大数据统计实现自适应告警阈值
- SLA/SLO 定义：例如「感知模块平均延迟 ≤ 50ms」，并监测是否达成
- 可视化一体化：整合车队状态、单车历史、告警记录、性能趋势到同一看板
- 数据合规：合规处理涉及地理位置、驾驶行为数据，满足数据安全和隐私法规
Monitor 阶段常见挑战：
- Q: 数据量巨大、上传带宽受限
- A: 边缘计算 + 数据分级上报（只上传关键指标或异常时全量上传）+ 按需拉取
- Q: 不同车型、不同硬件平台的指标标准不一致
- A: 制定统一指标标准，或在云端做多车型兼容
- Q: 本地告警延迟高或丢失
- A: 采用本地缓存+断点续传+优先级上报
智驾模型
Monitor 阶段核心目标是实时掌握模型推理性能：延迟、频率、硬件资源占用；监测模型结果的准确性、稳定性和一致性；捕获模型失效或输出异常；统计场景分布、置信度分布等趋势指标；形成可视化分析与自动化告警闭环；为数据回流和模型迭代提供可靠依据。
Monitor 阶段关键活动：
| 活动 | 说明 |
|---|---|
| 模型推理性能监控 | 跟踪每次推理的耗时、内存/显存占用、推理帧率，发现性能下降或波动 |
| 模型输出监控 | 分析模型输出的置信度分布、类别概率、连续帧一致性 |
| 结果合理性检测 | 例如检测目标突然消失/漂移，预测轨迹突变，规划意图异常等 |
| Corner Case 采集 | 识别易错场景并记录环境、传感器输入、模型输出上下文 |
| 自动化告警 | 模型性能/结果出现阈值外异常时推送告警给运维/研发人员 |
| 场景统计 | 根据天气、光照、路况等标签统计模型表现，找出模型弱点 |
Monitor 阶段最佳实践：
- 指标实时采集 + 上报：不要只做日志记录，要能实时汇总到云端
- 端到端一致性检测：感知-预测-规划模型串联输出是否自洽
- 动态阈值告警：不同车型、不同工况可以有不同的告警阈值
- 与环境关联：结合 GPS、IMU、摄像头等数据，将模型表现和环境关联起来
- 可视化：对车队中各车型、不同区域的模型表现形成趋势图，方便快速定位问题
Monitor 阶段常见挑战：
- Q: 数据量大，上传成本高
- A: 只在异常或弱场景中做关键数据回传
- Q: 不同版本模型混用，难以统一监控
- A: 强制上报模型版本号，并在云端对不同版本做分组对比
- Q: 现场问题难以重现
- A: 抓取模型输入、输出、环境元数据，并可在仿真环境中重放
上述各阶段中，有根据代码、模型维度分类，也有根据云服务、智驾软件、智驾模型维度分类，不同分类的目的，是为了更有针对性的展现该阶段的主要内容。虽然做了一定的划分，本质上区别不大，主要是关注的维度不同。
以上对 DevOps 无限循环图的 8 个环节做了概览性的描述，每一个环节都可以展开具体实践，期待后续的篇章。
