团队规模一大数据库查询就成了高危环节。我有段时间天天被开发拉着“帮我看看线上这张表的数据”加好友发SQL查完还得叮嘱“别动数据”。更让人后怕的是有同事用客户端直连生产库本意是select结果手滑执行了update条件又写漏了几万行数据直接改错。事后复盘问题不在SQL本身而在于查询入口不受管控——账号落在个人手上SQL没人审行为没记录。后来我们把Archery引进来统一收口所有数据查询请求。Archery算得上国内使用面很广的开源SQL审核与查询平台在我们内部它承担了“数据查询规范配置”的核心职责查询权限、SQL规则、审批流程、脱敏审计基本都在平台里配置落地。这篇文章不聊PPT式的架构图就讲从零配置Archery数据查询规范时我踩过哪些坑、哪些配置必须改、哪些规则建议开、以及遇到问题怎么排查。内容偏向实操DBA、SRE、后端负责人应该都用得上。1. 查询规范到底在管什么先把Archery的管控闭环拆开1.1 未上规矩前的数据库查询乱象在我接手规范治理之前团队里查询数据的状态可以用三个词概括入口分散、内容失控、无据可查。入口分散意思是每个人手里都握着直连账号Navicat、DataGrip、命令行工具五花八门生产库连接串在群里传来传去。内容失控更常见“SELECT *”满天飞动不动就全表扫描遇到大表直接把数据库IO打满。无据可查最致命——谁在什么时间查过什么数据、有没有导出敏感信息出了事完全追溯不到。那时候我很清楚不是大家故意不守规矩而是根本没有一个能把“查询”这件事管起来的抓手。Archery能解决的核心问题就是把这团乱麻梳理成一条可管控的链路查询必须走工单工单必须过审核审核通过才能执行执行结果可选脱敏行为全程留痕。说白了它就是在数据库前面加了一道闸门把原本“裸奔”的查询操作全部规范起来。1.2 Archery的三层模型身份、资源、动作初次接触Archery很多人会被它的一堆菜单绕晕。我的经验是先抓住它的三层模型后面所有配置都围绕这个模型展开。第一层是身份也就是用户体系。Archery支持本地账号也能对接LDAP统一认证。这一步要提前定好内部如果已有账号体系建议直接对接LDAP省得每个库单独维护一套密码。第二层是资源也就是实例管理。你录入的每一个数据源包括MySQL、Oracle、SQLServer、PostgreSQL之类的连接信息都属于资源层。资源要被“资源组”划分归属再和用户绑定。第三层是动作指具体的数据库操作。查询工单、上线工单、权限申请工单都属于这一层。用户不直接碰数据库他只能提交动作请求请求通过后由平台执行。这三个对象通过“资源组”和“工单流程”扭在一起。查询人不能直连数据库他只能提交查询工单由实例所属资源组的审核人审查SQL通过后再执行。这样一来“大家都有权限”变成了“按需申请、过程审批”权限边界清晰非常多。1.3 查询规范的四个落点落到配置层面我习惯把查询规范拆成四个落点每个落点对应Archery里的具体功能模块规范维度管的是什么Archery对应的能力权限规范谁能查、能查哪些库哪些表资源组、实例授权、角色权限流程规范怎么申请、找谁审批、如何执行查询工单、审批流配置内容规范SQL写成什么样才允许执行SQL审核规则引擎行为规范查完能不能导出、能看多少行数据脱敏、导出限制、查询时限这四个落点不是孤立配置的。比如你只做了权限规范但没有内容规范用户拿到查询权限后照样可以写慢SQL只做内容规范不考虑脱敏敏感字段一样会通过结果集漏出去。所以下面的配置过程我是按权限、流程、内容、行为四个维度一起推进的。2. 环境就绪MySQL、Git、Python到Archery核心组件2.1 Meta库选型与MySQL安装配置Archery本身需要一个元数据库Meta库来存放工单、用户、实例配置这些平台数据我建议直接用单独的MySQL实例来装版本在5.7以上或者8.0都可以。MySQL安装配置这一步看似基础但有一堆细节会影响后面Archery的稳定性列几个关键点字符集统一utf8mb4别用默认的latin1否则工单里存中文SQL容易出乱码。max_allowed_packet建议调大我最早用默认值4M结果开发提交一条带长参数的SQL工单直接保存失败。后来调到64M问题再没出现过。时区参数要和Archery保持一致避免工单时间显示差八个小时。Meta库账号建议独立创建不要直接给Archery用root。给一个最小权限账号并限制来源IP降低Meta库被波及的风险。还有个容易被忽略的选型问题Meta库一定不要和业务生产库共用同一个实例。Archery承担的是管控角色如果管控平台自己长在业务库上一旦平台产生慢查询或锁就会反噬业务。2.2 拉取源码、Python依赖与Django初始化Archery的部署方式有Docker和源码两种我这边因为是内网环境加上要做较多定制选择的源码部署。Git安装及配置教程网上很多不赘述只是提醒一下Git拉取代码前先把user.name和user.email配好后面提交配置修改时才不会报身份不明。依赖环境方面Python建议单独建虚拟环境避免污染系统Python。装依赖只需要一行pip install -r requirements.txt接下来是Django初始化把Archery的配置项填进去然后执行数据库迁移并创建管理员账号python3 manage.py makemigrations sql python3 manage.py migrate python3 manage.py createsuperuser启动服务后登录后台第一件事就是确认系统配置能正常读取Meta库。如果页面打不开优先排查数据库连接串、Python包版本、静态文件路径这三处八成问题都出在这里。2.3 配置文件里最容易翻车的几个点源码部署比Docker多很多手动环节我遇到过几个典型的配置问题写出来可以帮你少走弯路。ALLOWED_HOSTS很多人在settings.py里不填或填错DEBUG一关整个页面全变“请求被拒绝”。按实际访问域名或IP填写。静态文件路径Django在开发模式下能自动服务静态文件但生产环境通过Nginx反代时必须把静态目录准确映射不然页面白屏、样式丢失。前端资源构建Archery前端是Vue工程打包后交给Django托管的源码方式部署需要Node环境参与构建。这一步经常被跳过结果后台页面打开一片空白控制台全是资源404。所以NodeJS安装及环境配置也要提前准备好别只依赖Python侧。反代上传大小限制如果团队习惯在工单里贴长SQL甚至传附件Nginx的client_max_body_size默认1M大概率不够建议调到10M以上。环境层面的坑大多一次性的配好以后基本不用再动。真正需要反复调整的是后面查询规范本身的配置。3. 查询规范配置实操实例、资源组与权限矩阵3.1 录入实例把只读账号和业务账号分开在Archery后台新增实例时有几个字段要特别注意数据库类型、主机、端口、实例名以及一个非常重要的“查询账号”。这个账号是平台代替用户去连数据库用的必须单独创建并且建议遵循最小权限原则——只给SELECT权限禁止给定点更新、删除权限。查询账号只用来执行查询工单里的SQL跟业务应用使用的账号完全隔离。我见过不少团队图省事直接把业务主账号填进去。这样做短期内能用但一旦Archery自身被攻破等于把数据库钥匙也交出去了。正确的做法是单独造一个账号起名类似archery_read并做好账号审计确保它只能在工作时间段内从平台IP连入目标实例。如果业务使用主从架构查询账号建议填从库地址。查询规范里有一条潜规则线上查询默认走从库把压力挡在Analytics库或者从库侧绝不让查询工单直接打在写入主库上。这样既保证查询可用性也避免慢查询拖垮主库写性能。3.2 资源组实例、审核人、查询人的关联资源组是Archery权限模型的中间层理解它查询规范的权限部分就通了一半。我的习惯是每条业务线建一个资源组比如“交易中台”“用户增长”“财务系统”。每个资源组里要配置审核人通常由该业务线的DBA或资深后端担任工单审批会自动流转到这里。实例绑定把业务线相关的数据源实例挂到组下。成员管理把需要查询该数据的用户加进来并指定角色。用户在资源组里的角色决定了他能做什么。比如有的组里有“查询人”和“查询执行人”两个角色前者只能提交工单后者在审核通过后还能自己点执行。权限矩阵这一层非常容易混乱我的建议是初期配置时先统一用“查询人”角色审核和执行的职责都归到DBA身上跑顺之后再逐步放权。3.3 查询工单流程从提交到执行的权限链路查询工单是Archery里最常用的功能模块。用户登录后选“查询”新建工单选择目标实例、数据库Schema然后粘贴SQL。提交后流转到资源组审核人那里。审核人能看到SQL内容、涉及的库表以及Archery给出的SQL检查结果。这一步的关键在于审核人不能只看“能不能查到”还必须关注“查得是否安全”。比如SQL里有没有SELECT *有没有跨表大关联有没有可能造成大结果集。审核通过后工单进入执行阶段DBA或者有执行权限的人员点“执行”平台才会真正去连数据库跑这条SQL。我在配置这一步时额外注意了两件事一是把“查询工单是否允许执行人自行执行”这类权限开关明确打开。如果不打开用户提交工单后干等DBA执行遇到业务高峰期效率很低。二是给每个资源组单独配置审核人避免所有工单堆给同一个人产生审批单点瓶颈。到这里权限和流程的框架已经完整。但光有框架还不够因为用户提交的SQL内容如果没人把质量关再规范的流程也挡不住一条烂SQL把库拖垮。4. 把“不许裸查”落进审核规则和脱敏策略4.1 高危SQL检查规则从根上卡住危险写法Archery内置了一套可配置的SQL检查规则这是“内容规范”的核心。我的建议是第一波规则不要开太多先把下面这五条加上基本能堵住90%的查询安全事故禁止SELECT *强制手写字段清单既减少全字段返回的网络消耗也逼着查询人想清楚自己到底要哪些列。强制LIMIT查询工单里的SQL如果没有LIMIT子句直接拦截。尤其线上大表少了LIMIT很容易扫出几百万行。禁止不带WHERE条件的UPDATE/DELETE虽然查询工单理论上只允许SELECT但防止有人把其他工单类型的SQL误传过来规则也要兜底。禁止DDL语句查询场景下不允许建表、删表、改表结构。禁止高危函数和可疑关键字比如sleep、benchmark这类函数防止有人用查询工单做SQL注入测试或拖慢数据库。配置完规则后建议在一台测试实例上先自测一遍提交几条符合规则的正常SQL再提交几条违规SQL确认正确拦截和放行。这一步别跳过因为规则引擎的拦截行为受版本影响很大有的规则在某个版本里只提示不拦截有的则会直接报错。我还想多说一句代码规范。很多团队在应用层对代码评审盯得很紧却对SQL这块没做检查这是很大的疏漏。把Archery的审核规则当成“数据库侧的CI检查”和日常代码检查配合起来使用效果会好很多。团队成员在提交查询工单时就被拦住的问题不会留到线上再去暴露。4.2 数据脱敏与导出控制守住隐私底线查询规范里数据安全是最不能含糊的部分。Archery支持在查询结果返回前对敏感字段做脱敏处理比如手机号、身份证号、银行卡号、邮箱这类字段可以配置成打码显示或部分隐藏。我配置脱敏时的经验是先盘点业务方真正会接触哪些敏感数据。最常见的是用户手机号和身份证号但不同业务还有自己的敏感性字段比如财务场景里的薪资库存场景里的成本价。把字段清单列出来逐个在后台配置脱敏规则并绑定到对应实例。有一点容易误解脱敏是应用层做的不是改数据库。也就是说底层数据还是真实值只是Archery把结果集“加工”了一下再返回给用户。这也意味着脱敏只对走查询工单的链路生效如果用户绕过平台直连数据库脱敏规则形同虚设。所以脱敏配置必须和直连权限的回收一起做。导出控制同样重要。查询结果“能看”和“能导出”是两回事。我会把导出权限默认关闭只对少数确需导出做数据分析的同事开放并要求导出敏感数据时走审批加备注。这样既保证日常查询不受影响也把数据泄露的出口管住了。4.3 查询时限与返回行数限制调参经验规范里还有一类不起眼但很关键的内容查询时限和返回行数。Archery允许配置查询连接超时、执行超时以及单次查询返回的最大行数。我遇到过最典型的问题用户提交一条不带LIMIT的查询虽然开了LIMIT规则但总有人忘了加如果平台不兜底这条SQL就会把整表数据一次拉出来。所以我建议把返回行数默认设置在一个安全值比如5000行超过部分不展示。需要更多数据时用户得明确调整工单说明由审核人单独审批。超时时间则需要根据业务和实例负载来定。设置过大慢查询照样能拖垮实例设置过小正常的复杂分析SQL也会被误杀。我的做法是先看实例的慢查询日志和平时业务SQL耗时通常将执行超时控制在30秒以内高负载实例再收紧。阈值定完后通知到所有查询用户让大家对平台的行为有预期。5. 规范落地时的真实坑位与完整排查链路5.1 坑位一工单审批通过执行时提示无权限这是我刚上Archery时遇到的头号问题。开发提交查询工单DBA审核也通过了等开发自己点“执行”系统却提示没有执行权限。开发急DBA也纳闷平台明明配好了为什么不能执行。我从几个角度排查了一遍先看工单状态确认审批动作确实完成而不是停在半路。再看用户的资源组成员关系确认他所在资源组是否正确。重点看角色权限在Archery的后台配置里“提交查询工单”和“执行查询工单”是两种不同的权限点。用户如果只有提交权限在审批通过后仍然无法自己执行。最后查到权限矩阵里漏了一个“查询执行”授权补上后问题才解决。这件事让我意识到查询工单的权限链路是环环相扣的登录身份、资源组归属、实例授权、角色权限任何一环缺了都会出现“看起来有权限实际用不了”的情况。排查时不要只看工单状态要把整条权限链路走一遍。5.2 坑位二脱敏规则没生效手机号还是明文脱敏配置上线后有同事反馈查询结果里手机号依然是完整明文。这种问题很打击信心毕竟数据安全流程规范都定了规则却不生效。我的排查链路是检查脱敏规则是否绑定到目标实例。很多脱敏规则配了字段忘了跟实例绑定等于没配。检查字段类型是否匹配。比如手机号在库里用bigint存脱敏规则如果用字符串类型匹配就覆盖不到。需要把规则改成数字类型或者统一按字段名匹配。检查结果导出通道。Archery的查询结果界面上可能显示脱敏后的数据但导出功能如果走了另一套逻辑可能导出的是原始值。后来我查下来那次问题就出在导出权限没限制白名单上。检查规则版本或缓存。某些版本的规则修改后需要重新提交新工单才生效旧工单还是沿用旧的脱敏策略。脱敏不生效往往不是单点原因建议把上面四步当成固定排查清单每次按顺序过一遍。5.3 坑位三规则配置过猛业务方集体“抗议”还有一次翻车属于策略问题。我一开始想一步到位把Archery里几乎所有高危SQL检查规则全开了结果第二天业务方集体反馈查询工单大量被拦截连一些小需求都被卡住工单积压成山。后来我意识到规范配置要讲节奏不能一上来就搞“一刀切”。正确做法是分阶段推进第一阶段只开最关键的五条规则禁止SELECT *、强制LIMIT、禁止无WHERE条件的写操作、禁止DDL、禁止高危函数。第二阶段跑顺后再叠加慢查询、多余函数、隐式类型转换这类优化型规则。第三阶段上脱敏和导出限制并对特殊业务线开放白名单。同时规则改动前要把明细同步给所有开发看结合代码规范和技术文档写清楚“哪些写法在查询工单里不允许为什么”。这是运维规范中容易被忽略的环节——很多人不是故意违规是不知道规则存在或不知道规则背后的风险。到这里Archery数据查询规范配置的核心链路基本讲完了。从我这几年的实践来看规范的价值不在于平台本身装得有多好看而在于规则能不能真正跑在业务前面。踩过几次坑之后我最大的体会是先让团队跑通最简单的查询工单闭环再逐步加规则、加脱敏、加导出控制顺序反了就会引起大量反弹。配置不追求一步到位持续迭代才是数据查询安全最稳妥的路线。