Yearning 部署实战：用 Docker Compose 实现 SQL 审核流程化

前阵子帮团队把数据库变更环节规范了一下，核心引入的开源工具是 Yearning，部署方式选了 Docker Compose。这篇文章把我从环境准备、容器编排、首次初始化的完整过程，到后来线上使用遇到的坑都整理出来。适合正在准备引入 SQL 审核的 DBA、后端负责人，以及想搞明白 Yearning 到底怎么跑起来的运维同学。

Yearning 本质上是一套带 Web 界面的 SQL 审核与执行平台，承接的是数据库变更里最难管的一段：开发写好的 SQL 怎么经过审核、由谁执行、执行前后怎么留痕、出了问题怎么回滚。以前很多团队的流程是开发在群里喊一句“帮我跑下这条 SQL”，DBA 拿到手直接在线上执行，没有任何审批记录。小问题靠运气，出大事连是谁执行的、执行前长什么样都说不清。部署 Yearning 之后，这条链路就变成线上化的工单系统：有人提交、有人审核、有人执行，全程留痕。

仓库地址在 GitHub 上能直接找到，镜像也有官方版本，不需要自己再包一层。用 Docker 部署的意义不只是“起个容器”这么简单，它让 Yearning 的代码、配置、依赖和底层数据库环境彻底解耦，升级、回滚、迁移都变成几条命令的事。下面我按实际操作顺序来写，你可以直接对着敲。

1. 项目概述：Yearning 到底解决了什么问题

1.1 没有审核流程时，数据库变更有多失控

先还原一个我见过太多次的现场。业务上线新版本，后端开发需要给订单表加一个索引，还要把一批历史订单的状态批量修正。他写好 SQL 之后，直接在 Navicat 里连上生产库执行了。执行完发现 update 语句里的 where 条件写漏了一个状态字段，导致几千条正常订单被误改。等发现问题的时候，离线备份已经是前一天晚上的，当天白天的数据只能靠脑子回忆去补。

这不是能力问题，而是流程缺失。人总有手滑的时候，SQL 越复杂、影响的数据越多，出错的概率越大。更隐蔽的是执行前的审查环节：这段 SQL 会不会导致锁表？影响行数是不是被刻意限制过？涉及的表是不是被列为敏感表？这些单靠一个人盯着屏幕看，很难每次都看全面。Yearning 这类 SQL 审核平台，就是用系统化的规则去强制卡这道关口。

Yearning 做的事，说起来并不玄乎：把数据库变更分成“提交、审核、执行、回滚、审计”五个环节。开发写好 SQL 后在网页上提交工单，系统自动做语法解析和规则检查；审核人看到工单后在线审批，也可以驳回要求修改；审核通过后由有权限的人点击执行，平台负责把 SQL 真正跑到目标数据库上；如果操作有风险或者执行后需要回退，平台还能基于 binlog 生成回滚语句。每一步操作记录都留在系统里，随时能查。

1.2 Yearning 的核心功能模块

如果只看官网截图，会觉得 Yearning 的界面和常见的工单系统差不多。但它的功能模块拆开看，每个都对应一个真实的运维场景：

审核规则是 Yearning 比较有特点的地方。它不只是简单看关键字，而是能识别出“你这是 update 语句，但没有 where 条件”，或者“你这条 delete 会影响整张表”。这种能力在自研的审核系统里往往要花不少精力才能做到，Yearning 直接把规则内置了，并且允许管理员自定义。

1.3 为什么我选了 Docker 部署而不是裸机二进制

Yearning 官网也提供二进制包，但部署到 Linux 服务器上要自己处理 systemd 服务、配置文件目录、版本升级路径，尤其是后端存储的 MySQL 版本兼容问题经常让人头疼。用 Docker 不是逃避问题，而是把环境差异收敛到镜像层，让平台本身只关注业务逻辑。

具体到我个人的选择依据，主要是三点。第一，官方镜像会跟随版本更新，升级时只需要拉新镜像重建容器，代码和配置不会被环境搞乱。第二，用 Docker Compose 可以把 Yearning 和它的元数据库一起编排，新环境部署时一条命令拉起，不用每次手工初始化数据库再写一堆启动脚本。第三，Yearning 本身是有状态的系统，它的配置、工单记录、审计日志都存在 MySQL 里，把 MySQL 数据目录外挂到宿主机磁盘，后续无论是容器迁移还是备份恢复都简单很多。

2. 部署前准备：先把版本和目录规划清楚

2.1 基础环境与 Docker 版本要求

Yearning 是前后端一体的 Web 服务，自身资源消耗不大，但它依赖的 MySQL 容器至少要几百 MB 内存。所以部署这台机器建议 2 核 4G 起步，如果业务量大或者工单并发高，再把配置往上提。最低 1G 内存的机器也能跑起来，但 MySQL 一启动可能就吃掉大半内存，系统会不停触发 swap，体验很差。

Docker 环境方面，当前官方推荐使用 Docker Compose V2 语法，也就是 docker compose 命令。如果你的机器上还只有老版本的 docker-compose，也没关系，大部分 compose 文件是兼容的，只是个别新特性用不了。部署前先确认两个命令能用：

bash复制docker --version
docker compose version

如果 docker compose 提示找不到命令，大概率是 Docker 版本比较旧，或者没有安装 compose 插件。建议先升级 Docker 到较新版本再继续，因为后面我可能会用到 depends_on 条件等待这类相对新的特性。

对于需要从 Docker Hub 拉镜像的机器，如果网络拉取比较慢，可以在 /etc/docker/daemon.json 里配置 registry mirror，配置完记得重启 Docker。这一步不是必需，但在国内服务器上实践下来非常影响体验，镜像拉取从几十分钟变成几十秒都是正常的。

2.2 版本兼容性：两张“MySQL”要先分清

部署 Yearning 时最容易混淆的一个点是：系统有两套数据库概念。一套是 Yearning 用来保存自己工单、用户、配置的“元数据库”，这套库在 Docker Compose 编排文件里作为 MySQL 容器出现。另一套是 Yearning 将来要去审核和执行的“业务数据库”，也就是你们公司真正存放订单、商品、用户数据的那些库。

这两套数据库的版本要求并不完全一样。先说你自己的元数据库，官方长期在用的方案是 MySQL 8.0，部署时直接拉 mysql:8.0 镜像最稳。年份稍微早一点的部署教程里会写 MySQL 5.7，但从兼容性和长期支持来看，新装环境直接用 8.0 是更省心的选择。业务数据库这边，Yearning 目前主要面向 MySQL，如果你的业务库是其他数据库，需要去官方文档确认支持情况。

另一个要注意的点是镜像 tag。生产环境不要随手拉 latest 就算完事，至少应该记住你部署当天的镜像版本。比如你想锁版本，可以拉 yearning/yearning:3.1.0 这种具体版本号。锁版本不是为了不升级，而是为了出问题时可追溯、可回滚。

2.3 端口、数据目录与网络规划

Yearning 的 Web 服务默认监听容器内 8000 端口，所以你需要把宿主机的某个端口映射到 8000。如果宿主机 8000 端口被别的服务占了，可以改成 18000 之类的端口，但后面访问地址要跟着变。我在生产环境喜欢用 18000 这种不常见的端口，减少被扫描器盯上的概率，前面再套一层 Nginx 反代对外提供 80/443 访问。

数据目录建议单独规划，不要随便放在家目录里。我习惯把所有容器数据放到 /data/<项目名> 下面，这样备份、迁移时一目了然。Yearning 需要持久化的核心就是它的元数据库，所以至少要把 MySQL 容器的 /var/lib/mysql 目录挂载到宿主机。

存储规划其实还有一个隐藏点：MySQL 容器运行一段时间后，binlog 和 undo log 会把数据目录撑得很大。尤其是如果你在容器里开启了 binlog 用于恢复演练，磁盘占用增长速度会超出预期。部署时就要给数据目录留足余量，至少按 20G 规划。

3. 一步步 Docker Compose 部署实施

3.1 编写 docker-compose.yml

先在服务器上创建项目目录并进入：

bash复制mkdir -p /data/yearning
cd /data/yearning

然后创建 docker-compose.yml 文件。我这里给出一份可以直接使用的编排配置，包含两个服务：mysql 作为 Yearning 的元数据库，yearning 作为平台主体。

yaml复制services:
  mysql:
    image: mysql:8.0
    container_name: yearning-mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: "YourRootPass_2024"
      MYSQL_DATABASE: Yearning
      MYSQL_USER: yearning
      MYSQL_PASSWORD: "YourYearningPass_2024"
    command:
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_unicode_ci
    volumes:
      - /data/yearning/mysql:/var/lib/mysql

  yearning:
    image: yearning/yearning:latest
    container_name: yearning
    restart: always
    depends_on:
      - mysql
    ports:
      - "8000:8000"
    environment:
      MYSQL_ADDR: mysql:3306
      MYSQL_USER: yearning
      MYSQL_PASSWORD: "YourYearningPass_2024"
      MYSQL_DB: Yearning

注意几个细节。MySQL 容器的 MYSQL_USER 和 MYSQL_PASSWORD 是用来创建普通账号的，MYSQL_DATABASE 会同时创建名为 Yearning 的数据库，并把这个账号的权限授权到该库上。Yearning 容器里配置的 MYSQL_ADDR 填的是 mysql:3306，不是 127.0.0.1，因为两个容器在同一个 Docker 网络里，容器之间通过服务名访问是最稳定的方式。restart: always 保证服务器重启后服务能自动恢复。

如果还想让 Yearning 等待 MySQL 真正就绪后再启动，可以给 mysql 服务加 healthcheck，然后修改 depends_on 条件。完整写法是这样：

yaml复制services:
  mysql:
    ...
    healthcheck:
      test: ["CMD-SHELL", "mysqladmin ping -h127.0.0.1 -uroot -p$$MYSQL_ROOT_PASSWORD"]
      interval: 10s
      timeout: 5s
      retries: 10
      start_period: 30s

  yearning:
    ...
    depends_on:
      mysql:
        condition: service_healthy

这个配置能避免一个很常见的启动竞态：MySQL 容器显示 started，但内部还在初始化，Yearning 连接数据库时提示 Access denied。我用这个配置之后，新环境部署基本不再需要手动等待。

3.2 启动容器并观察日志

配置写好后，先校验一下编排文件格式：

bash复制docker compose config

如果 YAML 文件有缩进错误或字段写错，这一步会直接报出来。确认无误后执行：

bash复制docker compose up -d
docker compose ps

第一次启动需要拉镜像，MySQL 第一次初始化也要花一些时间，通常几十秒到几分钟不等。这时候别急着打开页面，先看 Yearning 的日志，重点是确认数据库迁移是否成功：

bash复制docker compose logs -f yearning

看到日志里不再报错，并且出现监听 8000 端口的提示，说明 Yearning 已经启动成功了。如果日志里一直在重试连接 MySQL，多半是 MySQL 还没初始化完，等一会儿再看，或者用我上面说的 healthcheck 配置解决。

3.3 首次登录与管理员账号处理

Yearning 的官方镜像默认带了初始化的逻辑，大多数版本首次启动后可以用默认账号登录，账号一般是 admin，初始密码通常是 Yearning_admin。用这个账号登录后，系统会引导你修改密码，这时要立刻换成强密码，不要继续用默认密码对外。

如果你部署的版本没有默认密码可用，还有一个通用的处理思路：进入 Yearning 容器，用自带的命令行工具执行初始化。

bash复制docker exec -it yearning /Yearning install

执行过程中会让你设置管理员邮箱和密码，按提示输入即可。这个命令本质上是在元数据库里写入管理员信息和初始化数据，正常执行一次就够了，重复执行可能出现“表已存在”之类的提示，不影响使用，但没必要反复跑。

不管用哪种方式拿到管理员权限，我建议登录后的第一件事不是急着连业务库，而是把平台自己的管理员密码改掉，再创建一个日常维护用的管理员账号。这样做的好处是，即使日常账号密码泄露，也还有一把单独的 root 权限备份钥匙。

3.4 进入 Web 界面后先检查什么

浏览器访问 http://服务器IP:8000，如果打不开，先别怀疑 Yearning，大概率是云平台防火墙或者服务器本机防火墙没有放行 8000 端口。这个问题我遇到太多次了，部署一切正常，页面就是进不去，排查半天发现是安全组规则没加。

登录成功后的首页，对刚部署完的新系统来说，核心任务有三个：第一，在系统设置里确认基本配置是否正常；第二，去用户管理里创建好后续要用的普通用户和角色；第三，在资源组里规划好后续要接入的业务线。我见过不少团队部署完平台，直接把 admin 发给全组人用，这样虽然省事，但完全失去了权限审计的意义。Yearning 的权限体系本身不复杂，但一定要从第一天就按角色分好，后面再补权限只会越来越乱。

4. 配置数据源与真实使用流程

4.1 给业务库准备最小权限账号

把 Yearning 接入你们真正要管理的数据库之前，有一个前置工作：给 Yearning 准备专用的数据库账号，而不是用业务库的 root 或者管理员账号直接连。这一步既是安全考虑，也是合规需要，万一出现问题至少能通过账号定位到是平台在操作。

不同用途建议分开账号。如果 Yearning 需要执行 DDL/DML，创建一个执行账号，按实际需要授权。以 MySQL 业务库为例，常见授权脚本类似于：

sql复制CREATE USER 'yearning_exec'@'%' IDENTIFIED BY 'YourExecPass_2024';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP, REFERENCES
ON `app_db`.* TO 'yearning_exec'@'%';
FLUSH PRIVILEGES;

如果只是希望通过 Yearning 做只读查询，单独创建一个查询账号，只给 SELECT 权限就够了：

sql复制CREATE USER 'yearning_query'@'%' IDENTIFIED BY 'YourQueryPass_2024';
GRANT SELECT ON `app_db`.* TO 'yearning_query'@'%';
FLUSH PRIVILEGES;

注意授权范围里 % 只是一个示例，生产环境一定要限制为 Yearning 所在服务器的 IP 网段，否则等于把一个能改数据库的账号暴露在整个网络里。授权语句里的权限列表也要结合团队实际切割，能不给 DROP 就不给 DROP，避免平台账号被攻破后造成更大损失。

4.2 在 Yearning 后台添加数据源与资源组

Yearning 里的数据源概念，通俗理解就是“一台数据库连接”。在管理后台新增数据源时，需要填写的核心字段包括：数据源名称、数据库地址、端口、用户名、密码、默认连接的数据库名，以及它归属的资源组。

这里有一个容易踩坑的细节：如果业务数据库不在 Docker 容器里，而是在宿主机上或者另一台服务器上，配置数据源地址时不能想当然填 127.0.0.1。在容器里面，127.0.0.1 指向的是 Yearning 容器自己，不是宿主机。这种情况最稳的做法是填宿主机在局域网里的实际 IP，也就是 ip addr 看到的那个内网地址。如果宿主机是 Docker Desktop 之类的桌面环境，也可以考虑在 compose 里加 extra_hosts 把 host.docker.internal 指向宿主机网关：

yaml复制services:
  yearning:
    extra_hosts:
      - "host.docker.internal:host-gateway"

加了这个之后，数据源地址可以填 host.docker.internal，对于经常迁移环境的情况会更灵活。

数据源添加成功后，Yearning 会做一次连通性测试。如果测试失败，优先检查网络通不通、账号密码对不对、业务库是否允许远程连接。MySQL 默认配置里如果 bind-address 只写了 127.0.0.1，外部容器是连不进去的，需要在业务库的 MySQL 配置里监听内网地址，或者用 Docker 网络互通的方式处理。

4.3 一条 SQL 审核工单的完整生命周期

先把平台接入真实业务库，再来看一条工单是怎么跑通的。以最常见的场景为例：开发需要对 app_db 的订单表做一次批量状态更新。

开发登录 Yearning 后，选择目标数据源和对应的资源组，点击提交 SQL 工单。在编辑框里粘贴要执行的 SQL：

sql复制UPDATE order_info SET order_status = 3 WHERE order_status = 1 AND update_time < '2024-01-01 00:00:00';

提交之前，Yearning 会自动做一轮基础检查。比如当前语句是 update，但 where 条件写得不够明确，影响行数估算较大，系统会根据规则给出风险提示。这里要注意，Yearning 的检查规则不是一个只能被动接受的开关，它允许管理员在后台配置哪些是关键规则、哪些只是提醒。比如你希望所有不带 where 的 update 直接禁止，就可以在规则里把它设成 error 级别，这类工单根本提交不了。

提交成功后，工单进入待审核状态。具备审核权限的人会收到待办，点开工单能看到完整的 SQL 内容、影响行数预估、涉及的数据表。审核人如果觉得 SQL 有问题，可以填写驳回意见退回给提交人；如果确认没问题，审核通过后根据团队配置，可能还需要执行人再一次确认，才能真正点击“执行”。

执行不是简单的把 SQL 丢进数据库。Yearning 会记录执行开始时间、结束时影响的行数、执行人信息，执行完成以后，这个工单会变成一条永久可查的操作记录，和提交时的 SQL 文本放在一起。以后不管谁来问“这条 SQL 是谁改的、当时影响了几行”，翻工单记录就有答案。

4.4 回滚能力依赖 binlog 配置

Yearning 的执行后回滚能力，对 DBA 来说价值很高，但它不是凭空生成的。它依赖业务数据库开启了 binlog，而且格式必须是 ROW，也就是行级日志。如果你的业务库用的是默认的 statement 格式或者 mixed 格式，部分操作无法生成精准的回滚语句。

生产环境的 MySQL 配置里，至少需要保证这些参数正确：

ini复制server_id = 1001
log_bin = mysql-bin
binlog_format = ROW
binlog_row_image = FULL

binlog_row_image = FULL 这个参数容易被忽略。只有在 FULL 模式下，binlog 才会记录每一行修改前和修改后的完整镜像，Yearning 才能根据这些信息拼出反转的 SQL。如果是 MINIMAL 模式，日志体积是小了，但回滚需要的信息也不全了。

要把这个能力真正用起来，还需要在 Yearning 中配置对应数据源的“回滚账号”或者使用具备读取 binlog 权限的账号。这块不同版本界面略有差异，总的原则是：先确认业务库 binlog 开启，再配置连接账号权限，然后在功能页面做一次真实的小事务测试，确保能生成回滚语句再全面推广。

5. 常见问题与排查技巧

5.1 启动阶段连不上元数据库

这种问题第一次部署时非常高频，现象是 Yearning 容器日志里反复出现连接数据库失败，错误信息通常是 Access denied、Unknown database 或者 dial tcp ... connection refused。

先按这个顺序排查：第一，确认 MySQL 容器是否已经正常运行，docker compose ps 看状态；第二，确认 MySQL 容器内账号密码和 Yearning 环境变量一致；第三，确认 MYSQL_ADDR 写的是服务名 mysql:3306 而不是写成了别的名字。如果 MySQL 是第一次初始化，要给足时间，不要一看到报错就改配置，等日志输出稳定后再判断。加了 healthcheck 条件等待之后，这种竞态问题基本不会再出现。

5.2 页面能登录但保存数据源失败

这种问题通常不是 Yearning 服务本身出错，而是 Yearning 容器访问不到业务数据库。最容易栽的点就是前面提到的地址问题：容器里填 127.0.0.1 连的是自己。解决方式是在数据源地址里填宿主机的内网 IP，或者使用 host.docker.internal。

还有一种情况是数据源所在的 MySQL 限制了访问来源。比如业务库的 MySQL 用户允许的 host 是 localhost 或某个固定 IP，Yearning 容器每次访问的源地址是 Docker 网桥的 IP，不在授权范围里。这种情况需要去业务库给对应账号重新授权，host 改成 Yearning 服务器的内网 IP 或网段。

5.3 容器反复重启与内存不足问题

系统运行一段时间后，突然发现 Yearning 页面打不开，docker compose ps 显示容器状态一直在 restarting。这背后最常见的原因不是程序 bug，而是内存不足导致容器被系统杀掉。

先看是不是被 OOM 了：

bash复制docker inspect yearning --format='{{.State.OOMKilled}}'

如果输出 true，说明的确是被内存杀了。解决方案要么给机器扩容，要么限制 MySQL 容器的内存占用。MySQL 8 默认 buffer pool 不小，在 2G 内存的机器上确实可能和 Yearning 抢资源。可以用环境变量或者 command 参数把 MySQL 内存调小，比如：

yaml复制command:
  - --innodb-buffer-pool-size=256M
  - --character-set-server=utf8mb4
  - --collation-server=utf8mb4_unicode_ci

这个参数可以根据业务量灵活调整，Yearning 平台自身的数据量在初期不会太大，256M 的 buffer pool 足够支撑很长时间。调整完重新创建容器才会生效。

5.4 新建数据源的按钮正常，但测试连接报错

带外提一个容易被忽略的细节：如果你在服务器防火墙或者云平台安全组里只放行了 80/8000 这类端口，但业务 MySQL 的端口没有对 Yearning 所在服务器开放，那数据源测试连接会一直失败。很多团队习惯了“数据库只允许内网访问”，结果 Yearning 容器在另一台机器上，中间网络被防火墙拦截，这时候不是 Yearning 本身的问题，而是网络策略需要调整。

排查时可以先用容器里的客户端工具连通性测试一下：

bash复制docker exec -it yearning bash

进入容器后，用 mysql 客户端或者 telnet 测试目标数据库端口是否能通。如果容器里没有这些工具，可以在宿主机上用 nc -vz <数据库IP> 3306 做测试，宿主机通不代表容器通，反过来容器通也不代表宿主机通，两头都要确认。

5.5 忘记管理员密码的应急处理

Yearning 用久了，管理员密码丢失是很正常的事，尤其是测试环境。应急思路不是去翻数据库改密码，而是直接用容器里的 CLI 工具重置。

bash复制docker exec -it yearning /Yearning install

这个命令在部分版本中可以在已有库的基础上重新初始化管理员信息，执行完用新设置的账号登录即可。需要提醒的是，不同版本对这个命令的支持情况不完全一致，如果执行后提示需要清空数据库之类的操作，一定要先确认清楚再继续，不要在生产环境随手重置。

最稳的兜底方案其实是平时做好元数据库的定期备份。真到密码丢了、CLI 也不给力的时候，直接从备份里恢复一个可用状态，比在线上折腾要安心得多。

6. 生产环境上线前值得做的几项优化

6.1 用 Nginx 反向代理并启用 HTTPS

默认通过 8000 端口访问 Yearning 的方式，适合内网测试。真的面向团队开放使用，建议在前面加一层 Nginx 反代，把对外端口收敛到 80/443，同时把 HTTPS 配上。这样做的原因很直接：Yearning 页面上会展示 SQL 文本和数据库信息，属于敏感数据，明文传输风险太高。

一个简单的 Nginx 服务端配置类似这样：

nginx复制server {
    listen 443 ssl;
    server_name yearning.example.com;

    ssl_certificate     /etc/nginx/certs/yearning.pem;
    ssl_certificate_key /etc/nginx/certs/yearning.key;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

如果团队内部已经有统一的网关或反向代理，也可以直接把 Yearning 的端口映射到内网网关上，不一定要单独起 Nginx。核心思路是：不要让 Yearning 的 8000 端口裸奔到公网，至少要通过一层访问控制。

6.2 元数据库的定时备份与恢复演练

平台本身在跑，平台保存的审计记录和工单数据同样重要。万一元数据库所在的磁盘坏了，工单记录全丢，后面的审计和追溯就无从谈起。所以备份不是可选项。

一个相对简单的备份方案是写个脚本，每天凌晨用 mysqldump 导出 Yearning 元数据库并压缩存档：

bash复制#!/bin/bash
DATE=$(date +%F)
docker exec yearning-mysql mysqldump -uroot -p'YourRootPass_2024' \
  --single-transaction --default-character-set=utf8mb4 Yearning \
  | gzip > /backup/yearning_${DATE}.sql.gz
find /backup -name "yearning_*.sql.gz" -mtime +30 -delete

再把脚本挂到 crontab 里每天执行。密码直接出现在脚本里不够安全，生产环境建议把密码放到环境变量文件或者使用 MySQL 的 --defaults-extra-file 方案。备份不止要能生成文件，还要定期做恢复演练，否则真到恢复的时候才发现备份文件是坏的，那可比不备份还让人沮丧。

6.3 把审核流程嵌进团队协作规范

平台部署好了，规则配置好，并不代表 SQL 审核就真正落地了。我见过不少团队把 Yearning 搭起来之后，开发觉得“多了一道流程”很麻烦，继续私下连库执行，平台慢慢变成摆设。要让工具真正发挥作用，需要从管理规范上做配套。

比如明确规定：所有生产环境的 DDL/DML 变更，必须提前通过 Yearning 提交审核，审核通过后才能执行；临时查询不准直连生产库，必须走平台的查询入口。一开始肯定会有人觉得麻烦，但坚持一段时间后，回看操作记录和排障记录时，大家都体会到这句话