5.3 团队落地清单与安全基线：把"沙箱"变成"工程纪律"
文档摘要
5.3 团队落地清单与安全基线：把"沙箱"变成"工程纪律" 第五章前两节讲了方法论提炼（5.1）与团队落地、常见陷阱、演进展望（5.2）。这一节给一份可执行的"落地清单 + 安全基线"，让你关掉教程就能照着在团队里推行。我的立场很明确：技术选型和配置只是地基，真正决定沙箱能否长期存活的，是把它变成可检查的工程纪律。 一、推行前的三件事（先对齐再动手） 对齐项 | 要回答的问题 | 不对齐的后果 硬件底数 | 有哪些卡、驱动版本、是否支持 MIG | 镜像 CUDA 版本选错，全员翻车 协作模式 | 单人单卡探索，还是多人多卡长期迭代 | 方案过重或过轻 权限现状 | 是否有 root、是否在超算无 root 环境 | 误选 Docker 而实际该用 Singularity 这三点对应 1.
5.3 团队落地清单与安全基线：把"沙箱"变成"工程纪律"
第五章前两节讲了方法论提炼（5.1）与团队落地、常见陷阱、演进展望（5.2）。这一节给一份可执行的"落地清单 + 安全基线"，让你关掉教程就能照着在团队里推行。我的立场很明确：技术选型和配置只是地基，真正决定沙箱能否长期存活的，是把它变成可检查的工程纪律。
一、推行前的三件事（先对齐再动手）
| 对齐项 | 要回答的问题 | 不对齐的后果 |
|---|---|---|
| 硬件底数 | 有哪些卡、驱动版本、是否支持 MIG | 镜像 CUDA 版本选错，全员翻车 |
| 协作模式 | 单人单卡探索，还是多人多卡长期迭代 | 方案过重或过轻 |
| 权限现状 | 是否有 root、是否在超算无 root 环境 | 误选 Docker 而实际该用 Singularity |
这三点对应 1.3 的选型决策树。别急着写 Dockerfile，先把底数摸清——很多团队一上来就撸镜像，结果发现超算根本不给 root，白干。
二、骨架标准化清单（每人照做）
- 基础镜像锁定具体补丁版本，如
nvidia/cuda:12.1.1-runtime，禁用latest； - 四层版本锁定：CUDA、Python、框架（
torch==2.2.1+cu121这类带后缀精确版）、应用依赖用 lock 文件； - Dockerfile 分层顺序固定：基础 → 系统依赖 → Python 依赖（基于 lock）→ 业务代码最后 COPY；
- 数据全部走挂载：权重、数据集、日志挂 volume，绝不写进镜像；
- 端口只开必要的：Jupyter/训练只在内网，推理按需映射并加健康探活；
- 镜像进私有仓库：团队共享同一份不可变镜像，新人
docker pull即得一致环境。
这套清单就是 2.1–2.3 的"压缩版操作卡"。建议把它贴在团队 wiki 首页，作为 PR 合入前的自检项。
三、安全基线（别让沙箱变成攻击面）
沙箱解决了"环境一致"，但若配置不当，反而引入新风险。我给出六条必须守住的基线：
- 不要为图省事用
--privileged：特权容器等于把宿主root让出去，确需设备访问时用精确--device与--gpus； - 推理服务别裸奔公网：Jupyter、训练端口绑内网，对外只留做了鉴权的推理网关；
- 镜像来源可信：优先官方
nvidia/cuda、pytorch/pytorch，自构建时校验基础镜像 digest； - 密钥不进镜像：API key、token 用环境变量或 secret 注入，别
ENV KEY=xxx烤进层； - 资源设上限：训练/推理容器加
--shm-size、--memory、必要时的显存约束，避免单任务拖垮整机； - 定期更新基础镜像：CUDA/框架的安全补丁要跟，但更新走"锁版本 + 回归测试"流程，不盲目追新。
第六条尤其容易被忽视：团队往往"镜像一旦能跑就再也不动"，结果里面躺着一堆已知漏洞。把"基础镜像升级"排进季度例行，既能安全又不破坏可复现。
四、把它变成可检查的纪律
光有清单不够，得有检查机制，否则三个月后就走样：
- CI 卡点：提交 Dockerfile 时，CI 自动校验"是否用了 latest""是否把数据 COPY 进镜像""是否暴露了不必要端口"；
- 镜像扫描：入库前跑漏洞扫描，高危项不许合入；
- 复盘模板：每次 GPU 故障，按 3.3 / 4.3 的"定位-归因-处置"填一张表，沉淀进团队知识库。
五、给负责人的一句话收尾
把"隔离式沙箱"从个人习惯升级为团队工程纪律，核心不是技术多炫，而是让它可被复制、可被检查、可被复盘。技术细节你已在本教程前四章备齐，这一节给的是"让它们活下去"的护栏。至此，从沙箱到标准化工程的全链路已经闭环——你手里握着的，不再是一堆能跑的命令，而是一套能交付、能传承的工程方法。