SQL 审核到底审了个什么 ? 三种角度三种格局

2021-04-27 00:00:00 软件 规则 系统 审核 事前


近在搞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 审核到底审了个什么 !


下图是一个工作的过程

 



相关文章