云和恩墨：保险行业SQL审核的落地与实施

回顾多年的保险行业DBA生涯，大多数时间在与SQL“厮杀“。在数据库故障中，SQL引发的故障占比为44.4%，运维和BUG引发的故障分别占比为36.4%、19.2%。2015年底我们与云和恩墨团队合作对数据库架构与管理进行了全面的评估，依托云和恩墨的专业团队与行业经验，针对运维与bug引发的故障，我们引入专业监控工具并对其进行相应的定制开发；针对SQL引发的故障，决定引入SQL审核机制，加强线上线下SQL质量控制；为此，我们进行了长达2年的SQL审核工作机制试点与推广，取得了一些成果，下面分别从SQL审核的必要性、组织架构、工作切入点、考核机制、工具选择等方面与大家共同分享。

SQL审核的必要性：

如果把SQL审核当作一个产品的话，我们可以问自己它解决了一个什么问题，这个问题是否可以避免、是否有好的替代解决办法、值不值的去解决；

从我们公司来看，我们面临的一个问题是：44.4%故障是由于SQL性能问题引发的；

我们期望通过SQL审核来消除或大幅度降低SQL性能问题引发的故障；

那么针对这个问题：

SQL性能问题不可避免，我们不断地有新系统上线，基本上每周都有版本，都会引入新的SQL到数据库中，所以，SQL性能问题引发故障不可避免，必须要去解决；

在关系型数据库领域里，不采用SQL审核，有没有其他办法更好的消除或大幅度降低SQL性能问题？目前好像还找不到一个更好的替代解决办法；

保障IT系统稳定运行是所有运维人员所期望的，消除SQL性能问题有利于系统稳定运行；另外从数据库管理的角度来看，套用时间管理中的四象限法则，故障是重要且紧急的事情，需要优先处理，而SQL审核是一个重要不紧急的事情，把时间花费在SQL审核上，可以有效避免引发重要且紧急的事情，即降低故障发生；所以这是一个值得我们去解决的问题。

SQL审核的组织架构：

SQL审核的工作要持续开展下去，首先要确定组织架构，即明确岗位角色和职责，然后再选人到合适的岗位上，确保有人可用，最后配套相应的流程和制度，这项工作才可以正常的开展起来。我们目前的开发主要以外包为主，SQL审核工作主要涉及的人有：甲方DBA，甲方项目经理，乙方项目经理，乙方骨干开发人员，其组织架构图如下：

1） SQL审核leader主要工作职责为: 由甲方资深DBA担任，主要负责SQL审核工作机制制定、指定SQL审核小组成员、制定年度SQL审核计划；

2） 甲方DBA主要工作职责为：

作为SQL审核小组组长，整体推进该业务系统的SQL审核工作；根据系统/项目

特性特征确定SQL审核规则集，并在今后的实施过程中不断调整达到最优设置。

根据系统/项目特性特征同甲方PM讨论确定是否实施SQL审核，以及实施SQL

审核的频度和环境。

执行SQL审核的具体操作：包括SQL审核初始化配置，确定审核时段，执行审

核操作，生成审核结果等。

召开SQL审核小组会议，同甲方PM、乙方PM和乙方骨干开发人员一同评估

SQL审核结果, 确定问题SQL清单，撰写SQL审核报告。

定期跟踪问题SQL清单处理情况，提供技术支持解决疑难问题SQL。

3） 甲方PM主要工作职责为：代表项目组作为SQL审核的接口人，甲方DBA的需求均提交给甲方PM；负责与乙方沟通管理工作；

4） 乙方PM主要工作职责为：

为DBA提供应用程序的上线信息，支持DBA完成SQL审核操作。

参加SQL审核小组会议，同甲方DBA和骨干开发人员一同评估SQL审核结果，

确定问题SQL清单。

督促项目组成员按时完成问题SQL的修改工作。

5） 乙方骨干开发人员主要工作职责为：

参加SQL审核小组会议，同DBA和PM一同评估SQL审核结果, 确定问题SQL清单。

确定问题SQL的承诺修改时间。

根据承诺修改时间按时完成问题SQL的修改工作。

反馈问题SQL的修改进展、遇到的问题以及建议。

对逾期问题说明情况。

这是一个虚拟的组织架构，每个重要业务系统都会有成立一个SQL审核小组，由DBA担任小组组长，PM和开发人员担任成员，在发生SQL审核工作的场合构成临时TEAM，平常以各自工作为重。

SQL审核的切入点与审核范围：

在确定了组织架构和工作流程后，如何有效的切入到乙方项目组的日常开发工作中，既不可以大幅增加项目组工作量，也不可以让DBA投入大量的精力，其难点在于如何选择切入点和确定审核范围及频度；切入点没有选择好，SQL审核的效果不佳导致达不到SQL质量控制的目标；审核的范围及频度选择不恰当，会给项目组及DBA团队带来较大的工作量。

我们选择三个切入点，分别为：

1） 测试环境的SQL审核；

2） 用户验收环境的SQL审核；

3） 生产环境的SQL审核。

测试环境的SQL审核：

测试环境SQL审核属于上线前审核。在测试环境实施，一般针对较大的项目组且有专门的测试团队进行。实施团队较小的项目往往因测试不全无法通过SQL审核工具获取全量的SQL，导致SQL审核的效果不佳，浪费项目组和DBA团队的精力。对于测试环境SQL审核工作，我们按需实施，即项目组要求进行SQL审核，DBA协助部署SQL审核工具及组建审核小组。

用户验收环境的SQL审核：

用户验收环境指的是项目组开发好程序并内部测试通过后部署到一个专门的环境供业务部门的业务人员进行功能验收，验收合格后方可发布到生产环境（可能每个公司叫法不一样）。在用户验收环境部署SQL审核工具可以获取到比较全的SQL，在上线前进行审核可以有效地提前发现问题，是非常理想的SQL审核切入点；重要业务系统的大版本发布及新系统上线强制要求在该环境进行SQL审核，主要涉及的流程如下：

1） 项目组准备好用户验收环境后通知DBA部署SQL审核工具；

2） DBA通过SQL审核工具按照固定的频度自动获取SQL；

3） DBA通过SQL审核工具生成初步的问题SQL清单并整理成SQL审核报告初稿；

4） DBA组织SQL审核小组会议，要求甲方PM、乙方PM、乙方骨干开发人员参加并现场确认问题SQL清单中的问题，对于双方予以确认的问题，项目组在会后要给出明确的整改时间表；对于影响较大的SQL问题，项目组需在上线前予以解决；影响较小的SQL，允许项目组延后整改；

5） DBA在项目组承诺对问题SQL的整改时间表后，出具最终的SQL审核报告，上线材料中有SQL审核报告才可以上线。

生产环境的SQL审核：

对所有的生产系统进行SQL审核是不现实的，我们根据业务系统的重要性等级划分，对等级为“核心系统”的数据库排期进行SQL审核，该SQL审核由DBA主动发起，主要流程如下：

1） 对于核心系统涉及的生产数据库，DBA制定全年的 SQL审核计划，一般确保每个核心的

业务系统的SQL每年审核两次；

2） DBA按照 SQL审核计划开展SQL审核工作；

3） SQL审核一般按照业务系统为单位出具SQL审核报告，并召集甲方PM、乙方PM、乙方骨干开发人员讨论SQL审核发现的问题，讨论后达成最终的问题SQL清单交付给甲方PM；

4） 甲方PM督促乙方PM对问题SQL清单给出明确的整改时间表并反馈给DBA；

5） DBA按照乙方提供的整改时间表督促项目组整改并予以考核；

6） DBA每周以周报的形式通报各业务系统的整改情况。

SQL审核范围与频度：

SQL审核的工作可大可小，我们的策略是坚持“二八”原则，以最小的代价获取最大的效果：

1）核心系统的SQL做到全覆盖的审核，因为版本非常频繁，没有办法做到每个版本都进行上线前SQL审核，所以我们干脆让SQL进入到生产环境中来，定期进行SQL审核，这样做虽然没有办法完全避免新SQL带来的性能问题，但是可以定期清理掉系统中存在的SQL隐患；

2）对于非核心生产系统，如果该业务系统频繁运行不稳定，可以专门安排一次SQL审核，平常多以TOP SQL优化来保持系统稳定运行；

3）对于新上线系统，上线前强制要求进行SQL审核；

按照这样范围与频度安排SQL审核，可以大大降低SQL审核的工作量，又可以一定程度上提高系统运行稳定率。

SQL审核的考核机制：

SQL审核工作会给甲方PM、乙方PM及乙方骨干开发人员带来额外的工作量，如何让他们有动力来配合完成SQL审核工作，我们主要做到了三点：

1） 让开发部的领导及PM明白“SQL性能问题会严重影响系统的稳定运行”

在平常的工作中，有意识突出TOP SQL优化的重要性，在发生TOP SQL引发故障的场合，写一份详细的故障分析报告，说明TOP SQL的形成原因、对应的解决方案、优化前后的性能对比； 阶段性的总结各类TOP SQL，形成案例集分发给各项目组；

2） 制定SQL审核制度，在部门级正式发布，明确规定哪些场合必须进行SQL审核；

一旦形成制度，他就是DBA手里的“尚方宝剑”，可以按照规章制度要求否决项目的上线需求，项目组为了确保需求及时上线，会积极主动要求进行SQL工作；

3） 让双方明白这是一个“双赢”的合作工作；对DBA来说该工作可以提高数据库的稳定运行，对项目组来说可以提高系统的稳定运行并避免用户的投诉。

在上面三点的基础之上我们制定SQL审核考核机制，主要从以下三个指标来进行考核：

1） SQL审核问题未排期整改数：指项目组对已确定的SQL审核问题未进行整改上线排期的数量；项目组必须对所有已确定的SQL审核问题进行排期，排期时效是以SQL审核小组沟通会为开始时间点的1个月内，未在排期时效内进行排期的问题，每个问题扣5分（总分为100分）；

2） SQL审核问题超时解决数：指超过承诺解决时间完成上线的SQL审核问题数量；对于未及时整改的SQL问题，每个问题扣5分；

3） SQL审核问题超时未解决数：未在SQL审核周期内（我司SQL审核周期定义3个月）整改上线的SQL审核问题数；SQL审核周期结束时，若存在未解决的SQL审核问题，每个问题扣10分；

对于SQL审核的工作我们定位为重要不紧急，所以SQL审核的整改工作不要求在短时间内马上完成，可以适当的延长期限，让项目组在充分评估自身的人力情况下予以安排；这个考核结果并不会影响项目组的最终考评，但一旦因SQL问题导致故障发生那最终会追责项目组。

SQL审核工具的选择：

SQL审核需要进行大量上线SQL代码的捕获和初步分析，因此，需要专业的SQL审核工具。在专业工具的基础上，开展如下的SQL审核流程提供高效SQL管控：

在我们看来，SQL审核工具应具有如下的特点：

基于与恩墨团队的良好合作关系，恩墨Z3 SQL审核工具很好的满足了以上的特点，我们选择了Z3 SQL审核工具，很大程度上提高DBA工作效率。

SQL审核工作的实施效果：

1） 2017年生产数据库没有发生因SQL性能问题引发的故障；

2） 2017年全年共完成29个业务系统的SQL审核，共解决2348个SQL问题。

SQL审核工作的下一步计划：

1） SQL审核工具中提供的从JDBC连接中旁路截取SQL的功能非常适合开发测试阶段的SQL审核，计划在各项目组中推广使用，让开发人员借助SQL审核工具自我提前发现SQL问题。

1） SQL审核工作并不是简单的引入SQL审核工具即可，甲方需要花费更多的精力去建立制度与组织架构，组织架构是为了明确岗位与职责，确保有人可用；制度是为了明确流程，确保有“法”可依，工作才可以持续的开展下去，否则很容易虎头蛇尾；

2） 不建议在SQL审核工具中嵌入工作流程（比如创建工单之类），传统行业里流程的建立与改造涉及各方的利益，往往难以落地；我们通过一个简单的EXCEL清单及碰头会议把工作落实下去，最终只要项目组把问题修改好了就达到SQL审核的目的；

3） DBA要把工作做在平时，树立好“专家权威”，要善于展示工作成果，与各方建立“双赢”的局面，要具备过硬的技术功底与沟通技巧，塑造好DBA的影响力，有了较好的影响力后来推广SQL审核工作会事半功倍。