从“人肉运维”到一键迭代：创业公司算法团队的 DevOps 求生指南

前言

在创业公司，算法工程师的日常往往是：上午改代码，下午跑数据，晚上盯模型。可一旦缺少趁手的 DevOps，时间就被 “文件找不到、版本对不上、部署靠手敲” 一点点吃掉。

今天这篇文章，基于 GitLab 16.x + Docker 24.x 技术栈，提供一套经实战验证的轻量级流水线方案，帮你把模型、数据、代码统统纳入版本控制，实现 实验可复现、部署可回滚、协作可追踪—— 即使迭代再快，也能稳得住节奏。

第一章 DevOps 基础与初创团队需求

1.1 什么是 DevOps

DevOps 是 开发（Development）与运维（Operations）一体化 的理念与实践，核心目标是：

• 自动化交付与部署；
• 缩短迭代周期；
• 提升协作效率。

1.2 初创团队常见痛点

• 人手有限：缺少专职运维，研发需自行维护环境；
• 频繁实验：算法团队需快速迭代模型（超参数调整、模型版本更新）；
• 成本敏感：需在预算内构建 “够用不冗余” 的 DevOps 体系；
• 易用性要求高：新人加入后能快速上手，避免复杂配置学习成本。

1.3 为什么选择 GitLab + Docker Compose

工具 / 组件	核心价值（针对算法团队）
GitLab	代码、模型文件、CI/CD 流水线一体化管理，无需跨平台切换
GitLab Runner	自动执行模型测试、镜像构建、服务部署任务，解放人工操作
Docker + Compose	环境隔离（避免 “我这能跑” 问题）、轻量化部署（无需 Kubernetes 复杂集群）
云服务器	弹性扩展（训练高峰期加 GPU 实例，闲时缩容），降低硬件采购成本

第二章 基础环境准备

2.1 云服务器选型

• 操作系统：推荐 Ubuntu 20.04 / 22.04 LTS（长期支持版，稳定性优先）；
• 最低配置：4 核 CPU + 8GB 内存 + 100GB SSD（若需本地训练，建议 16GB 内存 + GPU 卡）；
• 带宽：≥ 10Mbps（拉取 Docker 镜像、推送模型文件需足够带宽）；
• 推荐版本：Docker 24.x、GitLab 16.x（兼容性已验证）。

2.2 服务器安全配置

创业公司服务器常忽略安全防护，导致服务暴露或被攻击，需优先配置：

2.2.1 配置 UFW 防火墙（仅开放必要端口）

# 1. 更新系统并安装 UFW 
sudo apt update && sudo apt upgrade -y 
sudo apt install -y ufw 

# 2. 启用防火墙并开放关键端口 
sudo ufw enable 
sudo ufw allow 22/tcp        # 服务器 SSH 管理（必开） 
sudo ufw allow 80/tcp        # GitLab HTTP 访问 
sudo ufw allow 443/tcp       # GitLab HTTPS 访问（后续可配置 SSL） 
sudo ufw allow 8080/tcp      # 算法 API 服务访问 
sudo ufw allow 2222/tcp      # GitLab SSH 端口（避免与服务器 22 冲突） 

# 3. 查看防火墙状态（确保上述端口均为 ALLOW） 
sudo ufw status

2.2.2 配置云服务器安全组

进入云服务商控制台（阿里云 / 腾讯云 / AWS），找到对应服务器的「安全组」，添加以下入站规则：

• 端口 22、80、443、8080、2222；
• 源地址：团队办公网段（或 0.0.0.0/0，测试阶段临时使用，生产需限制）。

2.3 安装常用工具

sudo apt install -y vim git curl wget htop

2.4 安装 Docker

# 1. 卸载旧版本（若有） 
sudo apt remove -y docker docker-engine docker.io containerd runc 

# 2. 安装依赖 
sudo apt install -y apt-transport-https ca-certificates software-properties-common 

# 3. 添加 Docker 官方 GPG 密钥 
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg 

# 4. 添加 Docker 软件源（国内优先选阿里云源） 
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null 

# 5. 安装 Docker 
sudo apt update 
sudo apt install -y docker-ce docker-ce-cli containerd.io 

# 6. 配置 Docker 国内镜像加速（避免拉取镜像超时） 
sudo mkdir -p /etc/docker 
sudo tee /etc/docker/daemon.json <<-'EOF'
{
  "registry-mirrors": [
    "https://docker.mirrors.ustc.edu.cn",
    "https://hub-mirror.c.163.com"
  ]
}
EOF 

# 7. 重启 Docker 并设置开机自启 
sudo systemctl daemon-reload 
sudo systemctl restart docker 
sudo systemctl enable docker 

# 8. 配置当前用户免 sudo 使用 Docker（需重新登录生效） 
sudo usermod -aG docker $USER 
echo "Docker 安装完成！请重新登录服务器使权限生效"

2.5 安装 Docker Compose

Docker 20.10+ 已默认集成 Compose（命令为 docker compose，无横杠），无需单独安装独立版：

# 1. 验证集成版是否已安装 
docker compose version 

# 2. 若未安装（旧版本 Docker），通过插件安装 
sudo apt update 
sudo apt install -y docker-compose-plugin 

# 3. 验证（输出类似 "Docker Compose version v2.27.0" 即为成功） 
docker compose version

2.6 配置 Python 国内源

算法项目常用 Python，配置国内源避免 pip install 超时：

# 1. 创建 pip 配置目录 
mkdir -p ~/.config/pip 

# 2. 写入国内源（清华源） 
tee ~/.config/pip/pip.conf <<-'EOF'
[global]
index-url = https://pypi.tuna.tsinghua.edu.cn/simple
trusted-host = pypi.tuna.tsinghua.edu.cn
EOF

第三章 GitLab 部署

3.1 为什么需要 GitLab

• 统一管理代码（.py/.ipynb）、模型文件（.pt/.onnx）、配置文件（.yaml）；
• 追踪模型版本（超参数、训练日志、性能指标与代码绑定），实现实验复现；
• 支持团队权限管理（如 “仅核心成员可合并主分支”“新人仅可读”）。

3.2 GitLab 核心架构

GitLab 官方镜像已封装所有组件，无需手动部署：

• Gitaly：处理 Git 仓库存储（含 LFS 大文件）；
• PostgreSQL：存储项目信息、用户权限、流水线记录；
• Redis：缓存数据与任务队列；
• Sidekiq：执行异步任务（如邮件通知、备份）；
• NGINX：代理 HTTP/HTTPS 请求。

3.3 部署步骤

3.3.1 准备目录（规范存储配置 / 日志 / 数据）

sudo mkdir -p /srv/gitlab/{config,logs,data} 
sudo chmod -R 755 /srv/gitlab # 确保权限足够

3.3.2 编写 docker-compose.yml（关键：修改 SSH 端口）

version: '3.6'

services:
  gitlab:
    image: gitlab/gitlab-ce:16.10.0   # 指定具体版本，避免自动升级导致兼容性问题
    container_name: gitlab
    restart: always                   # 服务器重启后自动拉起 GitLab
    hostname: 'gitlab.ai-team.local'  # 团队内部域名（可替换为服务器 IP）
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        # 访问地址：若无域名，替换为服务器公网 IP（如 http://1.2.3.4）
        external_url 'http://gitlab.ai-team.local'
        # GitLab SSH 端口：与服务器 22 错开，避免冲突
        gitlab_rails['gitlab_shell_ssh_port'] = 2222
        # 关闭不必要的服务（降低资源占用，适合创业公司低配服务器）
        gitlab_rails['env'] = {
          'GITLAB_ELASTICSEARCH_ENABLED' => 'false',
          'GITLAB_KAS_ENABLED' => 'false'
        }
    ports:
      - "80:80"     # HTTP 端口
      - "443:443"   # HTTPS 端口（后续可配置 SSL）
      - "2222:22"   # GitLab SSH 端口（容器 22 → 服务器 2222）
    volumes:
      - /srv/gitlab/config:/etc/gitlab  # 配置文件
      - /srv/gitlab/logs:/var/log/gitlab # 日志
      - /srv/gitlab/data:/var/opt/gitlab # 数据（含仓库、LFS 文件）
    deploy:
      resources:
        limits:
          cpus: '3'
          memory: 6G

3.3.3 启动 GitLab 并验证

# 1. 启动 GitLab（首次启动需 5-10 分钟，耐心等待）
cd /srv/gitlab
docker compose up -d

# 2. 查看启动日志（确认无报错）
docker compose logs -f gitlab

# 3. 访问 GitLab
## 方案 A：用域名访问（需配置本地 hosts）
# 在团队成员电脑上编辑 hosts 文件：
#   Windows: C:\Windows\System32\drivers\etc\hosts
#   Linux/Mac: /etc/hosts
# 添加一行：
#   [服务器公网IP] gitlab.ai-team.local
# 然后在浏览器访问：
#   http://gitlab.ai-team.local

## 方案 B：直接用服务器 IP 访问（无需域名）
# 若步骤 3.3.2 中 external_url 改为 http://1.2.3.4
# 则直接在浏览器访问：
#   http://1.2.3.4

# 4. 获取初始 root 密码（登录用）
sudo cat /srv/gitlab/config/initial_root_password
# 注意：密码有效期 24 小时，首次登录后需立即修改

3.4 GitLab 数据备份

代码和模型是算法团队的核心资产，必须配置定时备份：

3.4.1 手动备份（紧急场景用）

# 进入 GitLab 目录
cd /srv/gitlab

# 执行备份
# 备份文件存储在 /srv/gitlab/data/backups
# 格式为 [时间戳]_gitlab_backup.tar
docker compose exec -T gitlab gitlab-rake gitlab:backup:create

# 验证备份文件是否生成
ls -lh /srv/gitlab/data/backups/

3.4.2 定时自动备份（生产级配置）

通过 crontab 设置每天凌晨 2 点备份，并保留 30 天内的备份（避免占满磁盘）：

# 1. 编辑定时任务
sudo crontab -e

# 2. 添加以下内容（按 i 进入编辑模式，编辑完按 Esc 然后 :wq 保存）
# 每天凌晨 2 点执行 GitLab 备份，并删除 30 天前的备份文件
0 2 * * * cd /srv/gitlab && \
           docker compose exec -T gitlab gitlab-rake gitlab:backup:create && \
           find /srv/gitlab/data/backups -mtime +30 -delete

# 3. 查看定时任务是否生效
sudo crontab -l

3.5 算法团队必备：Git LFS 管理模型大文件

Git 原生不适合存储 .pt（PyTorch 模型）、.onnx（推理模型）、.ckpt（ checkpoint 文件）等大文件（会导致仓库膨胀、拉取缓慢），需启用 Git LFS（Large File Storage）。

3.5.1 步骤 1：在 GitLab 全局启用 LFS

1. 登录 GitLab（root 账号或管理员账号）；
2. 进入「Admin」→「Settings」→「Repository」→「Git LFS」；
3. 勾选「Enable Git LFS for all projects」；
4. 点击「Save changes」保存。

3.5.2 步骤 2：开发者本地安装 Git LFS

# Ubuntu / Debian 系统安装 Git LFS
sudo apt install -y git-lfs

# MacOS 安装 Git LFS（需先安装 Homebrew：https://brew.sh/）
brew install git-lfs

# 初始化 Git LFS（各系统通用）
git lfs install

3.5.3 步骤 3：在算法项目中启用 LFS

以「CV 模型项目」为例，追踪常见模型文件格式：

# 1. 进入项目目录
cd cv-models

# 2. 追踪模型文件格式（可根据项目需求添加，如 .pth/.h5）
git lfs track "*.pt"
git lfs track "*.onnx"
git lfs track "*.ckpt"
git lfs track "*.pth"

# 3. .gitattributes 文件会自动生成（记录 LFS 追踪规则），需提交到仓库
git add .gitattributes
git commit -m "enable git lfs for model files (*.pt, *.onnx, *.ckpt, *.pth)"

3.5.4 步骤 4：提交 / 拉取模型文件

# 提交模型文件（与普通代码提交流程一致）
git add outputs/resnet50.pt   # 假设模型存在 outputs 目录
git commit -m "add trained resnet50 model (acc 92.5%)"
git push origin main

# 拉取含 LFS 文件的仓库（新成员加入时）
git clone http://gitlab.ai-team.local/ai-team/cv-models.git
cd cv-models
git lfs pull                  # 单独拉取 LFS 大文件（避免 clone 时超时）

# 验证 LFS 文件是否生效
git lfs ls-files
# 输出示例：abcdef1234 * outputs/resnet50.pt（带 * 表示 LFS 管理成功）

第四章 GitLab Runner 部署

GitLab Runner 是执行 CI/CD 任务的 “工人”，负责自动测试代码、构建镜像、部署服务。推荐使用 Docker Executor，确保任务环境隔离（避免 “环境污染”）。

4.1 安装 Runner（Docker 方式）

# 1. 准备 Runner 配置目录
sudo mkdir -p /srv/gitlab-runner/config
sudo chmod -R 755 /srv/gitlab-runner

# 2. 启动 Runner 容器
docker run -d --name gitlab-runner --restart always \
    -v /srv/gitlab-runner/config:/etc/gitlab-runner \
    -v /var/run/docker.sock:/var/run/docker.sock \   # 允许 Runner 调用宿主机 Docker
    gitlab/gitlab-runner:v16.10.0                    # 与 GitLab 版本匹配（避免兼容性问题）

4.2 注册 Runner（绑定到 GitLab 项目）

4.2.1 步骤 1：获取 GitLab 项目的 Runner 地址与 Token

1. 进入 GitLab 目标项目（如 cv-models）；
2. 进入「Settings」→「CI/CD」→「Runners」；
3. 记录「GitLab instance URL」（如 gitlab.ai-team.local）和「Registration token」。

4.2.2 步骤 2：执行注册命令

# 进入 Runner 容器执行注册 
docker exec -it gitlab-runner gitlab-runner register

按提示输入以下信息（示例）：

1. Enter the GitLab instance URL: gitlab.ai-team.local（步骤 4.2.1 记录的地址）；
2. Enter the registration token: xxxxxxxxxx（步骤 4.2.1 记录的 Token）；
3. Enter a description for the runner: cv-model-runner（自定义描述，便于识别）；
4. Enter tags for the runner (comma-separated): docker, cpu, cv-model（标签，后续流水线需匹配）；
5. Enter optional maintenance note for the runner: （直接回车，留空）；
6. Enter an executor: docker（选择 Docker executor）；
7. Enter the default Docker image: ubuntu:22.04（默认基础镜像）。

4.2.3 验证 Runner

回到 GitLab 项目的「CI/CD → Runners」页面；若看到「cv-model-runner」状态为「online」，则注册成功。

第五章 CI/CD 流水线实战

5.1 GitLab CI/CD 核心概念

• Stage：流水线阶段（按顺序执行，如 build→test→deploy）；
• Job：阶段内的具体任务（如 build-image 是 build 阶段的任务）；
• Pipeline：完整流水线（代码 push 后自动触发，或手动触发）。

5.2 前置准备：启用 GitLab Container Registry

GitLab 内置容器仓库（Registry），用于存储算法服务的 Docker 镜像，无需额外搭建 Harbor：

1. 进入 GitLab 项目 →「Settings」→「General」→「Visibility, project features, permissions」；
2. 找到「Container Registry」→ 勾选「Enable」；
3. 点击「Save changes」，此时 Registry 地址为 http://gitlab.ai-team.local/ai-team/cv-models/container_registry。

5.3 实战：算法项目 .gitlab-ci.yml

以「CV 模型推理服务」为例，流水线包含 3 个阶段：

• build：构建 Docker 镜像并推送到 Registry；
• test：执行单元测试（验证模型加载、API 调用）；
• deploy：部署推理服务到生产环境。

项目目录结构（参考）

cv-models/
├── api/                  # 推理 API 服务（FastAPI/Flask）
│   ├── Dockerfile        # API 服务镜像构建文件
│   └── main.py           # API 入口（含 /predict 接口）
├── model/                # 模型加载逻辑
│   └── model_loader.py   # 加载 .pt 模型并提供推理函数
├── tests/                # 单元测试
│   └── test_api.py       # 测试 API 可用性、模型推理正确性
├── docker-compose.yml    # 服务部署配置（API + Redis）
├── requirements.txt      # Python 依赖（如 torch, fastapi, uvicorn）
└── .gitlab-ci.yml        # CI/CD 流水线配置（核心）

.gitlab-ci.yml 完整配置

# 1. 定义流水线阶段（顺序：build → test → deploy）
stages:
  - build
  - test
  - deploy

# 2. 全局配置：指定 Runner 标签（仅匹配带这些标签的 Runner）
default:
  tags:
    - docker
    - cpu
    - cv-model

# 3. 启用 Docker 守护进程（供 build 阶段构建镜像）
services:
  - docker:24.0.5-dind

# 4. Build 阶段：构建 API 服务镜像并推送到 GitLab Registry
build-api-image:
  stage: build
  image: docker:24.0.5          # 用 Docker 镜像执行构建任务
  script:
    # 4.1 登录 GitLab Registry（变量由 GitLab 自动注入，无需手动配置）
    - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin
    # 4.2 定义镜像名称（$CI_REGISTRY：项目 Registry 地址，$CI_COMMIT_SHA：当前代码提交哈希，确保镜像唯一）
    - IMAGE_NAME="$CI_REGISTRY/ai-team/cv-models/api:$CI_COMMIT_SHA"
    # 4.3 构建镜像（指定 Dockerfile 路径）
    - docker build -t $IMAGE_NAME -f ./api/Dockerfile .
    # 4.4 推送镜像到 Registry
    - docker push $IMAGE_NAME
    # 4.5 记录镜像名称（供后续 deploy 阶段使用）
    - echo "IMAGE_NAME=$IMAGE_NAME" > image.env
  artifacts:
    # 保存 image.env 到 artifacts，供 deploy 阶段读取
    paths:
      - image.env
    # artifacts 保留 1 天（避免占满磁盘）
    expire_in: 1 day
  # 仅在 main 分支或 feature 分支 push 时触发
  only:
    - main
    - /^feature/.*/

# 5. Test 阶段：执行单元测试（验证模型与 API 可用性）
unit-test:
  stage: test
  image: python:3.10-slim       # 用 Python 镜像执行测试
  script:
    # 5.1 安装项目依赖
    - pip install --no-cache-dir -r requirements.txt
    # 5.2 执行测试（-v 显示详细日志，--cov 查看测试覆盖率）
    - pytest tests/test_api.py -v --cov=model --cov=api
  # 缓存 pip 依赖（加速后续测试任务，避免重复下载）
  cache:
    paths:
      - ~/.cache/pip/
  # 所有分支 push 时均触发测试
  only:
    - main
    - /^feature/.*/
    - /^bugfix/.*/

# 6. Deploy 阶段：部署 API 服务到生产环境（仅 main 分支触发）
deploy-api-service:
  stage: deploy
  image: ubuntu:22.04           # 用 Ubuntu 镜像执行部署命令
  script:
    # 6.1 安装 Docker Compose（若镜像中未预装）
    - apt update && apt install -y docker-compose-plugin curl
    # 6.2 登录 GitLab Registry（拉取镜像需权限）
    - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin
    # 6.3 读取 build 阶段保存的镜像名称
    - source image.env
    # 6.4 替换 docker-compose.yml 中的镜像名称（用 sed 命令）
    - sed -i "s|API_IMAGE_PLACEHOLDER|$IMAGE_NAME|g" docker-compose.yml
    # 6.5 拉取最新镜像并启动服务
    - docker compose pull
    - docker compose up -d
    # 6.6 验证服务是否启动成功（检查 API 端口是否监听）
    - sleep 10                     # 等待服务启动（根据模型加载时间调整）
    - curl -f http://localhost:8080/health || exit 1   # /health 是 API 健康检查接口
  # 仅 main 分支 merge 或 push 时触发部署
  only:
    - main
  # 标记部署环境（便于在 GitLab 查看部署历史）
  environment:
    name: production
    url: http://gitlab.ai-team.local:8080

5.4 流水线触发与查看

• 触发方式：开发者 git push 代码后，流水线自动触发；
• 查看路径：GitLab 项目 →「CI/CD」→「Pipelines」；
• 问题排查：若某阶段失败，点击「失败任务」→「Job log」查看详细日志（常见问题：镜像推送权限不足、依赖安装超时、服务启动失败）。

第六章 Docker Compose 部署算法业务应用

算法团队常见的服务形态是「API 服务 + 模型服务 + 缓存服务」，通过 Docker Compose 实现一键部署，且支持服务解耦（更新模型无需重启 API）。

6.1 实战：推理服务 docker-compose.yml

version: '3.8'

services:
  # 1. API 服务（接收外部请求，调用模型服务）
  api:
    image: API_IMAGE_PLACEHOLDER     # 占位符，由 CI/CD 流水线替换为实际镜像
    container_name: cv-api
    restart: always
    ports:
      - "8080:8080"                  # 宿主机 8080 端口 → 容器 8080 端口
    environment:
      - MODEL_SERVICE_URL=http://model:5000  # 模型服务地址（容器间通过服务名通信）
      - REDIS_URL=redis://redis:6379/0       # Redis 缓存地址
    depends_on:
      # 关键：等待模型服务和 Redis 健康后再启动 API（避免连不上服务）
      model:
        condition: service_healthy
      redis:
        condition: service_healthy
    # 健康检查：验证 API 可用性
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 10s                 # 每 10 秒检查一次
      timeout: 5s                    # 检查超时时间
      retries: 3                     # 连续 3 次失败视为不健康
      start_period: 20s              # 启动后等待 20 秒再开始检查（给模型加载时间）

  # 2. 模型服务（加载模型，提供推理接口，与 API 解耦）
  model:
    build:
      context: ./model
      dockerfile: Dockerfile
    container_name: cv-model
    restart: always
    volumes:
      # 挂载模型文件（若模型通过 Git LFS 管理，需先拉取到 ./models 目录）
      - ./models:/app/models
    environment:
      - MODEL_PATH=/app/models/resnet50.pt   # 模型文件路径
      - LOG_LEVEL=INFO                        # 日志级别
    # 健康检查：验证模型是否加载完成
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5000/ready"]
      interval: 15s
      timeout: 5s
      retries: 3
      start_period: 30s                       # 模型加载耗时较长，延长启动等待时间

  # 3. Redis 缓存服务（缓存高频请求结果，减少模型调用次数）
  redis:
    image: redis:6.2-alpine                  # 轻量级 Redis 镜像
    container_name: cv-redis
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data                      # 持久化 Redis 数据
    # 健康检查：验证 Redis 可用性
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 3

# 持久化 Redis 数据（避免容器删除后缓存丢失）
volumes:
  redis-data:

6.2 服务管理常用命令

# 1. 启动所有服务
docker compose up -d

# 2. 查看服务状态（确认所有服务均为 Up）
docker compose ps

# 3. 查看服务日志（如查看模型服务日志）
docker compose logs -f model

# 4. 停止所有服务
docker compose stop

# 5. 重启服务（如更新模型后重启 model 服务）
docker compose restart model

# 6. 查看服务资源占用（CPU/内存）
docker stats

6.3 算法团队最佳实践

• 模型与 API 解耦：模型服务单独部署，更新模型时只需重启 model 服务，无需重启 api 服务；
• 配置文件外部挂载：敏感配置（如 API 密钥、数据库地址）通过 .env 文件挂载，避免硬编码到镜像；
• 日志集中管理：生产环境可添加 ELK 栈（Elasticsearch + Logstash + Kibana）收集服务日志，便于问题排查。

总结

本文提供的 GitLab + Docker 轻量级 DevOps 方案，专为创业公司算法团队设计，具备以下特点：

1. 低成本落地：无需采购昂贵硬件，基于云服务器弹性扩展，符合创业公司预算；
2. 高实用性：聚焦算法团队核心需求（模型版本管理、实验复现、自动部署），避开复杂技术栈；
3. 生产级保障：包含安全配置、数据备份、健康检查、定时任务等关键能力，避免 “demo 能跑，生产崩掉”；
4. 易上手：步骤清晰，代码可直接复制使用，新人 1-2 天即可掌握全套流程。

落地建议

• 第一阶段（1 周内） ：完成 GitLab 部署 + Git LFS 配置，实现代码 / 模型版本管理；

• 第二阶段（2 周内） ：部署 GitLab Runner，搭建基础 CI/CD 流水线（实现自动测试 + 镜像构建）；

• 第三阶段（1 个月内） ：完善部署流程，添加监控告警（如 Prometheus + Grafana），实现全链路自动化。

通过这套方案，算法团队可彻底告别 “手动传模型、靠嘴同步版本” 的低效模式，将更多时间投入到模型优化与业务创新中。