最近在搞SQL 审核的工作，从开始到目前有3个月的时间，
随着时间的推移从想法很简单认为这个事情很简单，到目前
的认知，还是希望能分享一下。
首先SQL审核到底是从技术入手，还是从规范入手，甚至从
管理制度入手，这最终会导致你的项目的影响力和最后的成
功的概率比。
为什么要进行SQL审核,答案可以归结为
1 公司的规模比较大,已经到了通过人工无法进行审核保证SQL符合一定的规范和安全的需要,整体的控制处于失控的状态
2 公司本身没有SQL 审核的流程,想通过软件达到规范开发SQL撰写,提高软件质量,以及开发SQL 可控的理想状态
在从三个角度来阐述前，先将SQL 审核 和 数据库审计分清
楚, SQL 审核核心是针对开发上线的SQL语句进行检测, 数据
库审计是针对DBA 或运维人员对数据库的操作进行检测和记
录,方便后面找问题(清算某些不规范的操作).所以这两个东西
没有任何关系, 针对的人员和场景都是不同的,工作的原理和
部署的方式和管理制度都是不同的.
所以我们今天要说的是SQL审核,是针对开发和项目规范,保证
软件上线的质量的一种工作方式和方法的统称.
下面从三个角度来看SQL审核
1 技术层面, 从技术层面来看,SQL 软件要达标的满足以下几点
1.1 SQL 审核软件的支持的数据库种类的问题
1.2 SQL 审核软件安装的便利性和侵入性的问题
1.3 事前审核的接入的问题
1.4 事后审核方法的问题
1.5 软件是否带有流程模块,或对接相关其他的OA系统
1.6 软件是否能进行简单的自定义的规则的工作
1.7 软件其他附加的功能,如慢查询监控,或者历史记
录, SQL自动执行和定 时执行,白名单,旁路审核, 数据库容量
提示和特殊语句的给出等等
1.8 与现行的开发系统对接,例如 Jekenis , mybatis,
openAPI 等方面的支持和自动获取SQL 语句的方式.
从技术的层面来看SQL 审核, 其实能完全能满足功能的自研,
或者外部购买的系统都未必能满足以上的所有要求, 但考虑
这些要求是,SQL 审核的核心吗
1.9 SQL审核可视化,可度量化,可历史化的功能需求
SQL审核的核心到底是什么?
SQL 审核的核心, ---- 规则
规则是什么,可以表述为SQL的规范. 那么每个单位的SQL
的规范是一致的吗,或者大部分都一致吗? 经过我们这几个月
的调研和供应商的沟通中,发现了其中的问题, 规则基本上多
数银行的规则都不一样,有的大型银行只有15条规则, 有
的可能有几十条, 那么规则是越多越好,大多数人的想法估计
是的,规则自然是越多越好,管理的越严格越好. 实际上我们并
不是这样认为的,可落地的规则,深入人心规则是初步推进项目
最好的规则,切记贪大求全.
例如:我们下面列一些规则看看如何
1 MYSQL SQL 中不允许一个表查询在一个SQL 出现两次的情况 (其实就是查询和子查询都带有这个表)
2 POSTGRESQL 不允许使用CHAR 模式的字段
3 MONGODB 不能出现没有ISODATE的collection
当然这上面的原理和来源就不说了,懂得自然懂.
那么规则在实现中遇到最大的问题是什么, 我们认为规则守不
住就是最大的问题,这说明两个问题,
1 制定的规则本身就有问题
2 目前的规则对于目前的开发水平,要求过高
例如 上面MYSQL 的规则,实际上有些语句通过添加索引,也
可以进行相关的优化和问题的解决,那么这样的规则在初期可
以有,也可以没有, 当我们发现系统中由于没有这个规则,引起
了问题后,我们在将问题,反哺规则,这样规则的说服力就大了.
那么规则就可以分为两种
1 与数据库性能有关的 (包含表设计)
2 与数据库性能无关 例如库名必须小写, 表名必须小写, 这
些和性能没有什么关系,和整体的规划和计划有关.
那么有了规则,SQL 审核软件实施起来就没有后顾之忧了?
NO NO NO , 其实SQL 审核软件实施关键的问题是管
理.
不少单位都想通过SQL 审核软件来改变软件质量差,软件质
量在数据库方面无法把控的情况, 但恰恰忘记了一点, 最终这
个软件如何进行实施,和落地的问题,规则列了一大堆,最终还
是没有控制住软件的SQL质量.
那么这个事情就又能讲出一个故事,关于如何实施的事情,实施
本身又能分出三种类型
1 事前审核
2 事中审核
3 事后审核
三种实施的方式各有各的好处和特点,也有各自的无奈, 大部
分SQL软件的供应商都推荐事前审核, 事前审核就是在软件开
发的初期, 就将SQL 审核软件介入,边开发边审核,在最终交付
上线的时候,给付的软件在SQL方面是基本合格的.
事中审核,其实可以理解为在UAT系统部署要测试软件的过
程中,提供SQL语句,或者在上线UAT后,通过软件来扫描系统
正在运行的语句.通过这个过程发现问题,修改问题
事后审核,在系统上线后,对系统进行扫描,发现有问题的语句,
并进行修改.
大部分银行也认为自己应该通过事前审核的方式介入管理, 可
问题在于管理和各种非技术的问题,导致事前审核无法落地,
例如数据库组织在公司IT部门内部,没有分量,说话和放屁一样,
那么事前审核能行得通的可能性就比较低,并且没有对开发的
要求,或者项目并未对此有要求,做到事前审核的可能性就更低
了.
事中审核,事中审核可能是大部分公司的现状,在做用户测试的
时候,开始提交SQL审核,并且在系统内进行扫描,发现问题,提
出问题,解决问题. 看上去也很美,可软件设计中有些SQL是无
法更改的, 主要的原因也可以从,技术本身,和 技术以外两个方
面考虑.
技术本身,一个表设计已经定了,那么SQL的撰写的方式也大部
分定了,如果在审核过程中,发现问题,想改可能就比较困难,没
有那么方便了.
技术以外, 那就是管理的问题,SQL 改写可能消耗项目的时间,
不改后期埋雷,权衡利弊项目上线的时间与改不改就和SQL审
核软件没有什么关系了,和整体的流程和管理有关
事后审核,事后审核其实是一个亡羊补牢的过程,基本上这个时
间在做审核的意义在于将不得不改的,影响核心系统的性能的
问题抛出, 来算算账, 让之前那些放过这些问题SQL 的设计人
员 "肉疼" 一下. 此时能改的就改改,不能改的,那就的想想特
殊手段,做好长时间持久战的问题了,以及怎么应对客户可能投
诉的问题了.
经过几个月的努力,也总结了一些市面常见的主流的SQL审核
系统功能特点,以及"缺陷". 至于规范制度和管理,我们
也大致心里有了 1 2.
那么SQL 审核到底审了个什么 !
下图是一个工作的过程
