企业官网建设流程全解析

简介：Archery是SQL审核与查询平台，同时提供丰富的MySQL运维功能。本手册面向数据库开发人员与DBA，系统讲解SQL审核规范、执行方式、回滚SQL、钉钉通知，以及SQL优化、慢日志分析、binlog清理、会话与事务管理、账号和参数配置等实用功能。手册结合实践案例，详细演示开发与测试环境的SQL审核流程、优化建议生成、阻塞排查与锁信息处理，并介绍PTArchiver数据归档、Binlog2SQL解析、SchemaSync结构同步三个插件，帮助读者在真实场景中灵活运用。资源为1个doc文档，压缩包约1.2MB，内容按功能介绍与实战案例组织，便于按需查阅。目前已有1476人学习下载，适合正在引入或使用Archery的团队参考。手册配有完整操作步骤和示例，可帮助读者快速上手，在业务中落地自动化SQL审核与数据库运维，提升效率与安全性。

1. Archery是什么：SQL审核平台的定位与解决问题

先设想一个场景：你负责的MySQL实例已经有几十个业务接入，每周的变更工单排着队等审核。开发提交上来的SQL，有的忘了where条件，有的在几亿行的大表上直接加列，还有的干脆把索引删了重建。你把规则在群里发了一遍又一遍，嘴上说着“注意点啊”，结果该踩的坑一个没落下。等出了线上故障，翻半天查不到是谁在什么时间执行了什么语句。

Archery就是冲着这个痛点来的：它把SQL审核、上线执行、查询审计、权限管理这一套DBA日常操作，做成了统一平台。开发提交SQL工单，系统自动按规则跑审核，DBA在线看结果、给意见，审核通过后点了执行由平台统一操作，全程留痕。适合那些已经过了“一把梭”阶段、想把数据库变更管起来的团队——不管你是专职DBA，还是后端同学兼职管库，Archery都能把“人肉审核、口头沟通”变成“工单化、平台化”。

2. 部署Archery：用Docker Compose拉起最小可运行环境

2.1 为什么选Docker Compose而不是源码部署

Archery官方提供了源码部署和容器化两种方式。我接触过的大多数团队最后都走Docker Compose，原因很现实：Archery依赖的组件比想象中多，除了自身的Web服务，还得有MySQL存元数据、Redis存会话和异步任务。源码部署意味着你还要自己处理Python环境、pip依赖、Node前端构建，光是版本对齐就能耗掉半天。容器化之后，一台2核4G的机器就能跑起来，先让流程通起来，后面再慢慢加固。

常见做法是套一个nginx反代放在前面，但第一天上手没必要。直接在服务器上装好Docker和docker-compose-plugin，然后拉一份Archery的docker-compose.yml。如果你已经用docker方式管理其他服务，这个方案几乎不用额外学习成本。

2.2 最小拓扑：MySQL + Redis + Archery三个容器

一份能用的docker-compose.yml长这样。我建议按你自己的镜像仓库地址替换image字段，版本Tag选稳定版即可，不要追最新。

version: '3' services: mysql: image: mysql:5.7 container_name: archery-mysql environment: MYSQL_ROOT_PASSWORD: archery-root-pass MYSQL_DATABASE: archery volumes: - ./mysql-data:/var/lib/mysql ports: - "3307:3306" command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci redis: image: redis:6 container_name: archery-redis ports: - "6380:6379" volumes: - ./redis-data:/data archery: image: archerysec/archery:latest container_name: archery-app depends_on: - mysql - redis ports: - "8000:8000" environment: MYSQL_HOST: mysql MYSQL_PORT: 3306 MYSQL_USER: root MYSQL_PASSWORD: archery-root-pass REDIS_HOST: redis REDIS_PORT: 6379 REDIS_DB: 0 DJANGO_SECRET_KEY: your-random-secret-key

用docker compose up -d启动后，先去容器里确认两个依赖的连通性：登录到archery容器里尝试连mysql和redis，通了再继续初始化。这段逻辑值得停下来解释：Archery本身是一个Django应用，启动时会先做数据库迁移，如果MySQL没就绪，初始化过程会直接报错退出。所以depends_on只能保证启动顺序，不能保证MySQL可用。我一般会加一个健康检查，或者干脆启动后睡30秒再初始化。

参数方面注意三点。第一，mysql端口我映射到宿主的3307、redis到6380，是不想跟宿主机已有的实例冲突，你自己按环境改。第二，MYSQL_DATABASE: archery会自动建库，但Archery需要的是它的管理库，不是业务库，别把同一个MySQL既当存储又当审核目标。第三，DJANGO_SECRET_KEY随便生成一段长字符串，不要用默认值。

2.3 初始化流程：迁移脚本、创建管理员、打开页面

容器起来之后，需要手工执行建表和初始数据导入。Archery官方把这一步放在容器内完成，命令如下：

docker exec -it archery-app /bin/bash cd /opt/archery source /opt/venv/bin/activate python3 manage.py makemigrations sql python3 manage.py migrate python3 manage.py createsuperuser

这里每一条命令各司其职。makemigrations sql只会为sql这个应用生成迁移文件，Archery把工单、审核历史这些模型都放在sql应用下；migrate是真正把表结构落到MySQL里，同时会把内置的菜单、权限点、默认配置项一并初始化。createsuperuser会交互式问你用户名、邮箱、密码，这个账号就是后续登录管理后台的入口。

初始化完成后，浏览器访问http://服务器IP:8000，用刚创建的账号登录，进入的就是Archery的主界面，左侧是工单列表、SQL审核、查询、资源组这些菜单。到这一步，最小环境就通了。如果你看到页面能打开但样式加载不出来，多半是容器里静态文件没collect，Archery比较老的版本有这个问题，新版本基本都处理了。

3. SQL审核规则配置：把公司规范变成平台规则

3.1 审核规则从哪来：从检查项到规则模板

Archery的SQL审核能力，核心是基于goInception做语法解析和规则检查。goInception是一个独立的SQL审核工具，Archery通过RPC接口把提交的SQL语句送过去，等它返回一个JSON格式的检查报告，再把报告展示到前端。这就解释了为什么Archery部署时要多一个组件——它自己不做语法分析，只做流程编排和结果展示。

规则模板的概念是：goInception内置了几十种检查项，从“禁用的语法”“表名大小写”“索引数量限制”到“影响行数预估”，每一项可以单独开关。Archery把这些检查项组织成“模板”，一个模板绑定一个环境实例，比如“生产库用严格模板”“测试库用宽松模板”。模板里还可以配置审核级别的阈值，比如max_tables_count设置为30，超过就报错；max_keys_count设置5，业务说“我要建8个索引”，直接打回。

3.2 配置一个可用的SQL审核规则模板

我们以最常见的MySQL生产库为例，说清楚怎么配。

登录Archery后台，在“系统管理”菜单下找到“审核规则”或“goInception参数”，不同版本菜单位置略有差异，但逻辑一样。你会看到一长串参数项，不是每一项都值得动，我一般只调这几个：

保存模板之后，注意要把“资源组”和“实例”绑定到这套模板上。算是Archery设计里容易绕晕的地方：实例是物理的MySQL连接串，资源组是权限边界，模板是规则集，三者通过关联关系协作。新加入的数据库实例，如果没绑定模板，审核结果会走默认值，可能比你的预期宽松得多。这是一个常见盲区。

配置完成后可以做一个验证：提交一条会造成全表更新的SQL，比如update user_info set status = 1;，看审核结果是否命中行数限制。如果命中，说明规则已经生效。

3.3 资源组与权限：谁能提交、谁能审核、谁能上线

Archery的权限模型，大致可以理解为三层：用户、资源组、角色。用户就是登录账号；资源组是逻辑边界，一般按“业务线/应用”划分，比如“订单中心实例组”“用户中心实例组”；角色决定了你能干什么——只读查询、提交工单、审核工单、执行上线、管理员。DBA通常属于“审核+执行”角色，开发属于“提交+查询”角色，这样各司其职。

配权限时值得注意的一个坑是：Archery对“查询”和“工单”走的是两套权限体系。查询权限绑定在你个人账号上，按资源组授权，授权后才能看到对应实例的“查询”入口；工单提交流程则受“资源组-用户组”关联约束。如果不小心只配了查询权限没配工单权限，开发会发现能查数据但提不了变更工单。

这个阶段的目标是把“规则集”和“人”对应起来——哪些实例用严格规则，哪些人负责审核，哪些人只能执行。配清楚后，后续的工单流转才有意义。

4. 从提交到上线：走通一次SQL变更工单

4.1 流程引擎：提交、审核、执行三段状态

Archery把一次SQL变更拆成“提交申请→DBA审核→平台执行”三段，每一段都有独立的状态和操作入口。开发提交一个工单后，工单进入“待审核”状态；DBA打开看审核报告，没问题就点“审核通过”，有问题的写上修改意见打回。审核通过的工单进入“待执行”状态，由有执行权限的人在工单操作区选择“执行”或“定时执行”。执行完成之后，平台返回执行日志，包括每一条SQL的ROW_COUNT和影响行数。

这套流程本身没有特别新颖的地方，关键在于Archery把“谁在什么时候做了什么操作”全程都记下来了。从提交人、审核人到执行人，每一步都有时间戳和操作记录，后续回溯问题时直接翻工单，省去了“你跑一下binlog看看”这种低效沟通。

4.2 走通一条工单：从SQL提交到执行回显

假设业务同学要在一张名为user_wallet的表上新增一个字段。

在Archery界面里步入“SQL审核”菜单，选择目标实例，填写变更说明，然后在SQL输入框里粘贴下面这条语句：

ALTER TABLE user_wallet ADD COLUMN total_bonus DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT '累计红包金额';

提交后，Archery会把这条语句送到goInception做语法解析和规则检查。审核结果出来会逐条列出：语句语法是否正确，是否命中表名规范，是否涉及大表DDL风险，影响行数预估是多少。正常情况下，系统会提示“审核通过”或给出一个风险等级。

审核通过后，DBA在“我的待办”里找到这个工单，点击“通过”，然后到工单详情页点击“执行”。执行页面上可以选择“直接执行”或者“定时执行”，我建议第一次使用先选直接执行，方便观察返回结果。执行完成后，界面会返回类似下面的执行回显：

执行结果： 【1】ALTER TABLE user_wallet ... ROW_COUNT = 0, 执行成功 耗时: 120ms

到这里，一次最小流程就跑通了。你回头看整个过程会发现，开发没有直连生产库的账号，所有变更动作都发生在Archery平台内，平台账号和数据库账号分离，中间多了一道有审计的隔离层。

4.3 查询审批与脱敏：读权限怎么收敛

Archery的“查询”功能容易被当成一个普通的在线SQL执行工具用，但它真正的价值在于可控的在线查询。运维同学可以在“查询”入口里直接写SELECT语句，平台会记录查询人、查询语句、执行时间和返回行数。同时支持脱敏配置——比如身份证、手机号这些字段可以配置成只看前几位和后几位，防止敏感数据在界面上完整暴露。

脱敏配置在实例级别的“敏感字段设置”或者管理后台的“脱敏规则”里维护。常见做法是把常用的敏感列名配置成脱敏模式，比如手机号字段统一脱敏为138****1234。需要注意的一点是，Archery的脱敏是展示层的脱敏——SQL结果集返回后前端做处理，而非SQL解析时拦截。这意味着通过Archery API直接拿结果的方式不受脱敏约束，有高安全要求的团队需要再评估一层面。

如果你所在的团队还没有数据库查询的统一入口，Archery这一步相当于把“裸奔的数据库客户端”收拢成了可审计的在线工具。查询即留痕，这六个字在后续追责和合规检查时能省掉大量麻烦。

5. 避坑：Archery部署与使用中常见的5个问题

5.1 启动后前端页面打不开或样式错乱

现象：docker compose up -d之后，8000端口能连通，但返回的是空白页或纯文本。

原因：Archery的Django应用需要在启动时collectstatic收集静态文件，同时需要检查前端静态文件是否挂载到容器内正确路径。部分版本镜像中静态文件打包不完整，或者启动脚本没执行这一步。

解决：进入容器手动执行静态文件收集，然后重启容器。

docker exec -it archery-app /bin/bash cd /opt/archery python3 manage.py collectstatic --no-input exit docker restart archery-app

这里尤其要留意：如果用了自定义的STATIC_ROOT路径，需要确认该路径已挂载到宿主机卷，否则重启后静态文件又丢失。

5.2 审核结果“永久待审核”或超时

现象：提交SQL后，审核状态一直停在“等待审核中”，等几分钟也没结果。

原因：Archery调用goInception的RPC接口是同步的，如果goInception服务没有正确注册或网络不通，审核请求会挂起。另一个常见原因是Redis连接异常，请求队列没有正常触发。

解决：先看Archery后端的worker日志。如果是RPC连接问题，检查goInception的地址和端口是否配置正确；如果是Redis的问题，重新确认REDIS_HOST和REDIS_PORT。一个隐蔽的坑是Redis密码——如果Redis设置了密码而配置里没写，整个异步任务链表面正常但实际全部失败。

5.3 原有数据库账号与平台账号混用

现象：通过Archery执行工单时报权限不足，但用同样的账号在命令行里可以执行成功。

原因：平台执行语句时使用的不是你自己配的数据库账号，而是实例连接串里配置的账号。比如你的实例连接串用的是archery_ro（只读账号），那工单里的UPDATE和DDL自然执行失败。

解决：为Archery配置独立的数据库账号，并授予它SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, INDEX等权限，同时单独配置查询账号给只读场景。设计职责分离时，可以配两个实例连接：一个只读实例给“查询”功能用，一个读写实例给“工单执行”用。

5.4 工单通过但执行时翻车：DDL锁表导致业务超时

现象：一条ALTER TABLE在生产库执行后，业务写入超时报警。

原因：Archery默认在事务内执行DDL，MySQL 5.7及更早版本里，ALTER TABLE会锁表，虽然执行时间短，但大表上锁的时间足以让一批写入请求堆积。

解决：在Archery的实例配置里打开“执行参数”选项，给DDL语句加ALGORITHM=INPLACE, LOCK=NONE。这类MariaDB特有的语法选项需要确认你的审核链路支持，否则会被goInception拦截。对超大表，我倾向于把变更拆成小批次，或者先加列再统一刷数据，而不是靠平台一口气执行完整DDL。

5.5 升级版本后原有工单查询报错

现象：从旧版本升级到新版本后，历史工单打开显示异常，或工单列表打不开。

原因：Archery升级通常涉及数据库迁移，部分版本对表结构做了较大调整。如果升级前没有备份，或者跳过了中间版本，迁移脚本可能不完整。

解决：升级前备份Archery的元数据库，并且按版本号逐级升级，不要从1.x直接跳到2.x。备份命令很简单：

mysqldump -h127.0.0.1 -P3307 -uroot -p archery > archery_backup_$(date +%Y%m%d).sql

恢复时用同一份文件导入即可。升级完成后建议跑一遍现有的审核规则模板，因为新版本有时会重置某些系统配置。

6. 从会用到用好：巡检、权限收敛与工具链整合

6.1 每天早上看什么：三个巡检维度

Archery上线后，我对它的定位不是“装完就完事”，而是把它当成每天打开的第一个平台。我一般会看三块内容：昨天提交的SQL工单审核通过率、待办里有没有滞留的审核任务、资源组里哪些实例的账号权限有变动。通过率能反馈出开发整体的SQL书写质量；滞留待办意味着流程断点，可能是审核人请假但没做好工作交接，也可能是工单状态卡住了，需要人工介入调整。

Archery自带简单的数据统计页面，能看到工单数量趋势、审核耗时分布，但维度有限。有自动化习惯的团队可以把Archery的MySQL元数据库接进Grafana，做一些自定义看板。我个人觉得数值不重要，重要的是形成每天巡检的习惯，让变更不再是“通知一声就上了”，而是“每天有交代”。

6.2 权限收敛：把账号体系接入LDAP/SSO

部署初期大家为了方便，直接用createsuperuser建的账号分发给所有人用。这个做法起步可以，长期用下去会越来越难管——有人离职了账号不清理，或者一口共享账号变成谁都能登的后门。

好在Archery支持对接LDAP和企业SSO登录。配置路径在“系统管理”→“认证设置”里，常见做法是把登录模式切换为LDAP，填入你的LDAP服务器地址和搜索基DN，然后把用户的邮箱前缀与LDAP账号绑定。配置完成后，新员工入职自动获得登录资格，离职后LDAP侧禁用，平台侧也随之失效。

如果你所在公司有统一的运维平台，更推荐走SSO方案，把Archery的登录操作合并到自己的统一入口里，减少一次独立登录。这个改造对日常使用几乎无感，但对权限审计的价值是质的提升。

6.3 与自动化平台整合：API调用与工单自动创建

Archery的最终价值是融入研发流程，而不只是给DBA用。它暴露了一套HTTP API，可以创建工单、查询工单状态、执行已审核工单。这意味着你可以把SQL变更接入自家的持续交付流水线里：开发在代码仓库里发PR，CI构建通过后自动调Archery API提交SQL工单，DBA在Archery平台上审核，审核通过后由流水线里的定时任务触发执行。

我自己在一个发布系统里这样实现过“先审后发”的卡点：发布单里关联了数据库变更，只有对应的Archery工单状态是“执行成功”，发布流程才允许继续。整合之后，开发几乎感觉不到Archery的存在，但每一次数据库变更都自动留痕、自动走审核。从这个角度看，Archery真正值得投入的地方不在于它的界面做得多好看，而在于它把一个团队最重要的安全底线——数据库变更——变成了有约束的流程。

用了这么久Archery，我最大的教训就是：工具只是把流程固化了，它不会替你思考规则本身合不合理。模板里的阈值设得太严，开发会被你逼得写绕过审核的SQL；设得太松，它又形同虚设。我建议你每季度回头看一眼规则命中率和审核驳回原因，把那些“总在犯的低级错误”单独捞出来同步给开发团队，顺便把规则模板调一版。审核工具的价值不在“拦了多少问题”，而在于“让问题在形成故障之前就变得可见”。希望帮到你。

本文还有配套的精品资源，点击获取