在数据库运维领域，高可用和性能是两个最核心的关注点，大部分日常的运维工作也都是围绕这两个主题展开的。而性能往往又会影响到高可用，是数据库高可用的一个重要因素。
因此，对数据库性能的管控（尤其是应用开发的SQL语句的管控），是数据库运维领域最重要也是难度最大的工作。
◆ ◆ ◆ ◆ ◆
招商银行经过多年的建设，形成了数据库性能管理的几大有效手段：
预防体系：通过SQL审核系统，实现SQL语句质量管控，实现SQL语句的开发、测试、上线一体化管控，实现上线后的持续监控审核管控；
告警体系：除了常见的数据库指标告警外，还增加了对性能的管控，细化到诸如SQL缺索引、SQL并发度、SQL执行计划变化，等细粒度指标的告警，可以在性能产生波动的情况下快速发现问题；
快速分析体系：通过性能容量平台，快速定位数据库故障根因，实现分钟级分析问题，且无需专业经验即可自动实现；
一键修复体系：经过对历史故障的分析，预置了一键处理脚本，对部分可能出现的故障实现了一键修复，分钟级自动修复故障。
在招行内部，我们将上述几个管控能力简称为1-3-5，即1分钟发现问题，3分钟分析问题，5分钟解决问题。经过多年的发展建设，现在的1-3-5管控能力已经覆盖了多个场景，大部分历史故障都可以完成管控，完成了数据库领域的不可能完成的任务。
对数据库性能问题的处理策略，可以总结为两句话：能预防的要提前预防，不能预防的要有预案。秉承这一策略，就可以将大部分场景的被动式运维转换为主动式运维，避免出现故障时手忙脚乱。
◆ ◆ ◆ ◆ ◆
以下主要介绍上述性能管控方案中审核预防，即SQL审核部分。
SQL审核系统已经被越来越多的银行采用，作为SQL质量管控工具，SQL审核系统能够有效发现问题SQL，提升整体代码质量。常见的SQL审核系统功能包括如下几个方面：
SQL语法审核：主要审核不规范的SQL写法，发现其中的隐患，比如select *或where 1=1这种问题；
SQL执行计划审核：获取SQL执行计划，并审核其中的性能风险点，比如笛卡尔积操作；
SQL性能的审核：根据SQL性能指标，判断SQL是否足够优化；
数据库对象的审核：审核表等对象的不合理设计，比如不合理的索引等；
这些SQL审核功能提供了基础的审核能力，“看起来很美”，但在使用过程中往往都会遇到各种问题，比如：
SQL语法审核需要开发人员主动发起，但实际执行中往往大部分人都不会主动来进行这部分审核；
常见的SQL审核内置规则，与使用者定义的开发规范，往往是不完全一致的，这会导致SQL开发人员面对多重规范无所适从；
测试环境只能审核测试到的功能，而无法知道哪些功能没有测试到，漏测是一个比较普遍的问题；
生产环境的审核，缺乏持续跟进的能力，审核结果需人工介入处理，无法实现自动化；
开发、测试、生产，几个环节无法实现有机的整合，生产出现问题后无法回溯开发测试的审核情况；
我们在建立SQL审核系统之初，充分调研了市场上SQL审核产品的上述不足之处，结合我行的开发、测试、生产现有资源与流程，建立了贯穿整个产品生命周期的SQL审核系统，尽量整个数据避免信息孤岛，尽量自动化避免人工操作。
建立SQL审核系统，要解决的第一个问题，就是主动性问题。事实证明，等着开发者主动进行自我审核的策略，是无法保证100%审核覆盖率的。
这个问题我们的解决策略是：SQL审核系统集成到开发流水线之中，通过开发流程实现强制审核环节。
如上图所示，对于一个未上线的新项目，开发与测试阶段的审核是强制性的，如果开发阶段未审核或审核未通过，项目在流水线中无法流转到测试环节，如果测试环节未审核或审核未通过，项目在流水线中无法流转到上线环节。
通过与流水线的整合，将SQL审核作为流程管控的一个模块，通过与sonar等代码扫描工具的配合，实现程序代码+SQL语句的双重质量管控。
开发、测试、生产的元数据自动整合
SQL审核常见的另一个问题是，开发、测试、生产环节各自为战，分别进行独立的审核，无法将审核的结果进行对比验证。
比如一条SQL语句在开发阶段审核通过，这时无法得知其在测试阶段的审核情况，因为无法将开发项目信息、测试库信息、生产库信息进行有机的整合。
在SQL审核嵌入开发流水线的前提下，通过开发、测试、生产的元数据自动整合技术，可以实现SQL语句在多阶段的统一审核，解决信息孤岛问题。
该部分主要有两个技术来实现，一是项目信息与数据库信息的整合，既通过开发项目的元数据信息、测试库元数据信息、生产库元数据信息，实现项目在上线前就可以与数据库的关联关系自动匹配。
二是SQL语句的特征码计算算法，通过该算法，可以将同一SQL语句的不同表现形式，识别为同一特征码，过滤掉语句大小写、空格、回车换行、变量与常量等的区别。
这一技术主要解决了SQL语句在开发阶段的代码文本与数据库内部监控数据之间的差异，这个计算出的hash_id在之后的测试生产阶段都是唯一确定的，也就保证了从开发到生产每条SQL都有一个唯一的身份进行识别，方便后续问题的定位。
整合后的系统能够实现的场景：
应用进行版本迭代时，能够及时掌握生产上的SQL运行情况，并在新版本中进行改进；
生产系统SQL问题可以进行回溯，追踪开发与测试阶段的审核结果。
全流程自动化审核
我行SQL审核系统的另外一个特点，就是全流程是自动化的，开发人员、测试人员、运维人员都不需要进行额外的操作，即可实现全部的审核功能。
开发阶段，SQL语句文本采集模块自动扫描程序代码与配置文件，识别其中的SQL语句文本，并按照项目代码+版本+label+文件名+行号的模式，自动将SQL文本入库。
入库后的SQL会自动被进行语法审核，并自动将审核结果输出到开流水线系统，开发人员看到的只是最终的审核报告。
测试阶段，SQL语句性能采集模块自动识别该项目相匹配的测试库，并识别测试管理系统中的项目状态，自动连已启动测试的项目对应的接数据库，采集数据库中运行的SQL语句及其性能指标并自动将所有信息入库。
入库后的SQL语句及性能信息在后台完成自动审核，并监控测试管理系统中的项目状态，在项目结束的时候自动生成测试报告，对测试未通过的项目自动将报告发送给响应的开发人员进行通知。
生产阶段，数据库性能容量系统会持续对生产数据库进行跟踪审核，所有的SQL语句信息均在系统的管控之下，如有SQL执行指标出现异常，会自动生成问题单，并通过邮件自动通知相应系统的开发人员。
SQL审核是全流程自动化的审核。自动监控SQL，自动审核SQL，自动生成问题单，自动发送邮件，一键分析问题，自动给出优化建议，自动追踪优化效果，自动关单，自动持续监控，自动reopen。
真正达到全流程自动化，有效地避免了以往人工方式低效、覆盖率低、依赖评审人技能水平等问题。
与性能容量平台整合成
数据库全生命周期管理平台
SQL审核在生产阶段发现的问题，可以跳转到性能容量平台进行智能分析。
对问题进行具体分析，比如表的基本信息，表的分区索引信息等。通过与性能容量平台的整合可以对数据库全生命周期进行管理。
通过两个平台的关联，可以在审核系统中直接查看SQL语句在生产上实际执行的效率，这种操作对于应用的版本迭代时非常有帮助的。
比如在进行应用后续版本的开发过程中，针对某条SQL审核未通过而需要进行性能分析以便评估优化方案的时候，可以直接从审核系统中查看对应语句在生产的执行效率及执行计划，得到最真实的SQL执行数据。
另外在性能容量平台中分析SQL问题的时候，也可以手工触发SQL的实时审核。
通过上述介绍我们可以了解到，招商银行SQL审核系统与开发流水线进行了集成，各阶段元数据与SQL数据均进行了打通，实现了每条SQL的全生命周期管控，这一架构设计正是受到了DEV-OPS的启发，结合数据库管理运维的特点建设而成的。
我们将这种新的SQL语句管理思路叫做SQL-DEVOPS。
通过SQL-DEVOPS的全流程管控，各个角色都可以看到完整的SQL生命周期。
无论是开发人员、测试人员，还是DBA，都可以查看某一条SQL语句在开发阶段、测试阶段、生产阶段的表现，并需要各角色配合对SQL的全生命周期的执行效率负责，打破了部门墙的壁垒。
各阶段的SQL覆盖度管控
开发、测试、生产环节，都有各自的SQL集合，由于我们已经打通了每个阶段的元数据与SQL身份特征码，所以对这几个集合的联合运算就比较方便了，运算后可以对交集与差集进行分析，并对应到不同的场景，实现各阶段SQL覆盖度的管控。
开发阶段扫描到的SQL语句是否完整，将在后续的测试阶段与生产阶段加以验证；
测试阶段是否覆盖全部功能，可以通过开发阶段扫描到的SQL进行验证；
生产阶段运行的SQL是否都经过测试，可以通过开发与测试阶段的审核结果进行验证；
SQL审核是一种数据库管理运维方式的转变，即由被动式运维向主动式运维的转变。
航空界有一条著名的海恩法则：每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患，这一法则放在数据库运维领域也同样适用。
每一次性能问题背后一定有一些长期存在隐患的SQL语句，通过对隐患SQL的管控，将问题消除在初始阶段，为后续的数据库运维降低了压力，对提升数据库可用性、提升资源利用率与人工效率等方面，均为我行带来了巨大的价值。
本篇文章为您介绍了我行数据库SQL审核系统的建设经验，后续会继续为您带来数据库性能管控方面的技术文章，欢迎关注。
Head picture by NASA on Unsplash
