开发者友好的 SQL 审核工具

Bytebase 的 SQL 审核功能开始正式支持 PostgreSQL 数据库，并且相关规范在逐步丰富中。

作为一款数据库变更管理工具，SQL 审核是其中非常关键的一个环节，同时作为 DevOps 工具集中的一员，用户群中将有相当大部分是开发者，因此今天想聊聊什么是开发者友好的 SQL 审核工具。

为什么要审核

SQL 也是代码，所有其他代码需要审核的理由也同样对 SQL 适用。如果说的更具体一些，SQL 是与数据库进行交互的，而数据库实在太重要了。无论各大厂商们如何承诺自己的产品稳定、健壮、高性能，如何宣传自动、AI、HTAP、分布式、云原生等新概念，数据库依然是个复杂、脆弱并且不太聪明的存在。即便我们不考虑误删除这种「一个命令引发的惨案」，普通的查询也很可能让数据库不堪重负轰然倒下。这朵娇花其实经不起粗暴用户们的蹂躏，遗憾的是，大部分数据库用户都是「无知的暴徒」，他们的行为需要进行一定程度的约束。

某开发：「把代码写明白就用尽洪荒之力了，居然还要知道数据库这里不能动那里不能碰？不可能，这辈子都不可能！」

谁来审核

以往的认知里 DBA 是数据库的负责人并且最懂数据库，因此理应是 SQL 审核人。这个观点没有错，但是却产生了一个矛盾：开发者作为数据库用户无法理解诸多限制希望拥有最大的自由，DBA 坚持稳定压倒一切宁可错杀不可错放，于是双方开始了经年累月的攻防战。

伴随着 DevOps 等概念的提出，组织的研发流程也在进化，很多传统 「Ops」的工作开始融入 「Dev」 团队，一些在 DevOps 方面领先的企业已经开始组建 Platform Engineering 团队，专职为开发团队提供工具和平台，具体的维护管理工作全部由开发团队自己完成。

面向开发者的审核工具

因此我们也开始思考，如果以 DevOps 为目标，让开发团队自己对自己负责，相应的审核流程、审核工具应该怎样进化？我们尝试站在开发者视角，从审核能力、工作习惯、常用技术、业务压力、知识沉淀等角度对这一问题进行探究。

更精细的审核能力

大多数开发者对数据库的认知非常薄弱，一般只具备与应用开发相关的审核能力，例如对象命名、数据变更逻辑等，至于特定变更是否影响性能与可维护性，往往缺乏认知。幸运的是，不少工具已经集成了常见问题的审核规范，可以自动化的给出建议。但是数据库类型五花八门，引擎技术日新月异，某些规范对于特定数据库、特定版本是无意义甚至有害的，一套祖传规范走天下，拿着上个版本的剑斩这个版本的SQL，可能会严重影响业务开发效率，这也是以往开发团队与 DBA 的矛盾来源之一。当审核者能力不足时，就对审核工具提出了更高要求，一个优秀的审核工具应该具备更精细的审核能力：

• 针对不同数据库种类

• 针对不同业务类型，如 OLTP、OLAP、HTAP

• 针对不同生产环境，如开发环境、测试环境、线上环境

• 及时跟随数据库版本更新规范

流程前置提供连贯的开发体验

面向开发者的工具，使用体验也应该尽可能贴近开发团队的工作习惯。如果 SQL 脚本在版本控制系统（VCS）上管理，却需要登录另一个系统粘贴 SQL 进行审核，这种体验总归是不太愉快的。因此开发友好的审核工具应该尽可能融入组织现有研发流程，例如与主流研发环境集成或是开放 API。你说 GitHub 与 GitLab？难道不应该默认支持吗。

完整的 Database CI/CD 工作流

当审核流程前置，就意味着在 SQL 产生的源头就需要对其进行解析。主要的挑战来自于各种 ORM 以及基于状态（State-based）的变更工具，这些场景下开发团队并非直接提交 SQL 语句。例如，基于某种 State-based 变更工具，开发团队只需要进行申明式配置，变更语句完全是由工具动态产生，这时候审核工具将很难自动捕获对应 SQL。我们认为有三条可行的路径应对：

• 主动拥抱一些主流的 ORM 或相关工具，在源头进行更好的集成

• 提供 API 应对一些组织自研系统，通过主动提交产生的 SQL 来获取审核结果

• 提供包括 State-based 变更能力与自动部署在内的完整 Database CI/CD 工作流，从而实现真正的 Database DevOps

弹性审核机制平衡效率与稳定

SQL 规范的制定是为了帮助用户更好的使用数据库，而不应该成为业务的掣肘。当稳定性由其他团队负责时，往往容易产生一刀切机制。但是在 DevOps 体系下，开发团队需要兼顾效率与稳定，就有必要执行更灵活的审核机制，作为审核工具则可以提供一些相应的能力：

• 规范针对业务负载动态生效。在不同的业务负载下，同样的操作产生的后果也截然不同，例如对于分析型业务，一些有业务价值但消耗较多资源的查询方式，即可在业务低峰期被放开。

• 针对不同数据规模采取不同的管控力度。大多数问题的根因都是数据量太大，对于较小规模的数据库或表，一些规范即可降低严重等级或是被完全放开。

• 允许偶尔违规，但要有底线。生产环境下难免发生一些特殊情况，只要不是绝对禁止的行为或是满足一定条件，应该允许偶尔违规，当然为了避免机制被滥用，可以辅以违规次数限制等条件。

• 鼓励遵守非强制规范。当某些规范并非强制时，往往意味着没有规范，通过施加软性惩罚则有助于减少此类问题发生，例如频繁违反非强制规范时动态增加审批环节。

知其然而知其所以然

就像智能汽车，在没达到 L5 级别的完全自动驾驶前，驾驶员依然需要考取驾照。作为一个审核者，在使用自动审核工具时，也应该了解特定规范背后的原因，否则某些规范在引起眼前的麻烦时会被放弃执行而埋下隐患，又或者一些特殊场景无法被合理应对。飞机降落时总是听到「...调直座椅靠背，收起小桌板...」，也许你会不以为然，但是当你知道突发状况发生时轻则影响你逃生效率，重则小桌板直插你的腹部，你还会介意这小小的不便吗？当然，我们不认为开发者都必须具备专业数据库知识，但是面向开发者的 SQL 审核工具应该通过合理的方式清晰的阐明规范的原理与意义，从而帮助开发者潜移默化的学习，这将有助于推动规范的真正落地。如果你想成长为一个架构师，怎么能不懂数据库呢？

开源与共享才有生命力

天下大势合久必分，Oracle 在上一轮的数据库大战中胜出并坐拥了半壁江山，但近十几年伴随着互联网和云的高速发展，各类新兴数据库再次涌现。SQL 规范若考虑数据库引擎类型、版本、行业等因素，将衍生出非常复杂的规范库，而这已经很难靠单一组织完成及时的支持。同时大量的规范是来源于生产实践中，足够多的用户是产生高质量规范的前提。因此只有通过开源形式，吸引更多组织与个人参与建设，才能让工具保持旺盛的生命力。

未来是否不再需要 SQL 审核

如前所述，SQL 也是代码，所有其他代码需要审核的理由也同样对 SQL 适用，所以完全不需要审核是不可能的。但从狭义上看，那些针对性能、可维护性、可扩展性的规范，确实有可能伴随着数据库引擎技术的进步而逐渐减少，从而让开发团队只需要专注于业务的实现。在现阶段，严格的 SQL 审核仍然是数据库稳定运行必不可少的保障，Bytebase 将承担起这个角色，在我们的社区与用户陪伴下，努力打造开发者友好的 SQL 审核工具，并结合产品其他 CI/CD 能力，在 DevOps 生态中拼上 Database DevOps 这张关键拼图。