速查·5.X 团队落地清单补遗（一）

速查·5.X 团队落地清单补遗（一）

正文 5.3 给出了"对齐 → 骨架标准化 → 安全基线 → 可检查纪律"的主线。本条补落地运营期的六件事：沙箱跑起来之后，让它长期不腐才是真正的难点。

一、镜像资产治理

• 私有 registry 建仓：自建 Harbor 或用云厂商 registry，团队镜像不从公网 Docker Hub 直拉——外网抖一次，全员构建失败。
• 命名规范：统一结构如 registry.team.ml/base/torch:2.4-cuda12.1（用途/组件:版本），禁止 my-image-final-v2 这类名字。
• 保留策略：设置 tag 保留规则（如保留最近 20 个版本）与配额告警，防止 registry 变垃圾场。
• 责任到人：每个 base 镜像写明 owner，出 CVE 时知道找谁 rebuild。

二、Dockerfile 进代码库，进 CI

• Dockerfile 与代码同库、同评审：环境变更走 PR——谁改的、为什么改、影响什么，全部留痕。
• CI 流水线加镜像构建 job：主干合并即构建并推送新 tag。能自动构建的镜像才会被复用，靠人手 docker build 的镜像活不过三个月。
• 构建失败挂告警到群：基础镜像源变动导致的构建失败，必须第一时间有人认领。

三、新人 onboarding：第一天跑通"hello GPU"

• 准备一个 hello_gpu 样例仓库：clone → docker compose up → 容器内跑通一次小训练 → 输出结果。
• 新人第一天以"跑通这个"为目标，而不是"先读三篇文档"。环境能跑通，文档才有人读。
• 样例仓库同时是项目骨架模板：新项目从 copy 它开始，规范自然扩散。

四、升级节奏：定窗口，别让环境冻结

• 基础镜像：季度升级窗口，集中 rebuild + 回归验证。一直不升级的环境，半年后就没人敢动。
• 驱动升级：列入变更管理——提前公告 → 窗口内升级 → 跑冒烟测试集（nvidia-smi / 小训练 / 小推理各一条）→ 通过才算完成。
• 允许新旧并存：重要版本镜像保留 tag，任务可显式指定旧环境过渡，避免"升级日 = 停摆日"。

五、用数据汇报价值

向管理层证明沙箱工程值得投入，靠三类数：

• 环境工单数：推行前后"环境搭不起来"类求助的月度数量变化。
• 环境搭建时长：从入职/换机到跑通第一个任务的小时数。
• 镜像复用率：本月启动的容器里，来自标准镜像的比例。

每季度出一张表。沙箱工程的 ROI 不直观，不量化就永远停在"看起来可有可无"的位置上。

六、踩坑沉淀机制

• 任何一次"排查超过 30 分钟"的故障，复盘后写成一页：现象 → 根因 → 处置 → 预防。
• 沉淀位置就是本附录这类速查手册——让第 N 个人的排障时间从 2 小时变 2 分钟，这才是文档真正的产出。
• 指定附录 owner 定期归并去重，防止速查手册自己变成没人看的大杂烩。

一句话收尾

落地不是一次性运动：建仓、进 CI、能升级、可度量、有沉淀——做到这五条，沙箱才从"某个人的好习惯"变成"团队的工程资产"。

详细原理见正文第五章 5.1「从沙箱到标准化工程」与 5.2「团队落地、常见陷阱与演进展望」。