为什么很多团队上了 SQL 审核，数据库变更管理仍然容易出现偏差？

这两年来，走访了好些技术团队。存在着一个耐人寻味的普遍现象。公司已然部署了Yearning、Archery这类SQL审核平台。生产变更也强制规定要“先提单后执行”。照理来讲，数据库变更应当会变得更可控。然而，DBA们依旧频繁地“救火”。审核流程实行了，可是有人一转身就在客户端里直接去修改生产数据。审批流配置好了，然而审批与执行却是两套系统，中间统统全靠人工去传递SQL脚本。规范虽说存在着，却只是停留在提醒的层面，很难真正去拦截高风险操作。

审核入口与执行入口脱节

相当多的团队的确是要求“生产变更先提审核”的，然而生产库的权限依旧开放式给予研发、测试乃至运维人员。这就表明着同一个人既能于审核平台提交工单，又能够在Navicat或者DBeaver这类客户端当中直接连接生产库去执行SQL。在这样的模式之下，SQL审核变成了一种“推荐流程”而非“强制流程”，只要执行入口没有统一收口，任意流程都有可能被轻易绕开。

真正被DBA所在意的，实际上并非制度是否存在，而是平台层面欠缺实质性的约束力，当用于审核的工具仅仅覆盖了变更链路的一小部分，并且执行入口依旧分散于各类客户端之中的时候，数据库变更管理出现偏差就难以避免，在这种情形下，再怎么完善的审核规则也仅仅是浮于表面，没办法从根本上杜绝违规操作的出现。

审批流程与执行系统分离

有些团队的流程设计，看上去似乎清晰，开发人员提交SQL工单，等审批人审核通过后，再把SQL复制出来去执行。然而问题正好出在这儿，审批系统跟执行系统是分开的。审批通过之后，SQL语句或许得被复制到聊天群里，粘贴到工单备注中，又或者由DBA手动复制到客户端里去执行。中间只要有一个环节出现复制错误，执行错环境，或者漏掉某条语句，风险就会再次浮现。

从数据库管理员的视角去看，这类问题超越单一工具缺陷，显得更为棘手。它并非是某个用以审核的按钮按错不当的情况，而是那整个流程链路在中间就断开了。审批在其中作为决策环节，执行则作为落地环节，这两者之间是依靠人工进行“跳转”来相互连接的，不仅整体效率很低低下，而且极其容易引入人为失误，会导致出错。当审批通过的那个时刻到来之际，这并不意味着变更能够安全顺畅地落地，真正存在的风险常常就隐匿于这段凭借人工传递的灰色地带之中。

权限模型与责任边界混乱

数据库异常出现得不少，其根源不是没做SQL审核，而是像谁能看、谁能改、谁该审批这些基础权限方面的问题没梳理好。业务库数量增多后，审批人被固定写在流程里，业务一旦调整就需人工去修改；负责人以及权限关系变得纠缠繁杂，一个变更究竟该谁审、谁批、谁执行，常常得临时进行沟通确认。在权限模型和责任边界处于混乱状况时，即便SQL审核十分严格，那也不过是做了一层表面的控制而已。

假若权限跟责任没能构建出较清晰的映射关联，那么审核流程便会变得刻板且不容易维护。比如说，特定业务线的数据库负责人离职了，可是审批流里却依旧留存着他的名字，新来的负责人没办法自动承接审批权限。这样一种混乱会径直使得流程执行出现不确定性，DBA不得不经常介入其中进行人工协调，原本应由平台承担的治理能力，又落到了人身上。

DBA视角的治理诉求

那些并非 DBA 角色的人士看待数据库变化情况，重心普遍在于“是否能够圆满实现发布”。然而 DBA 观察问题所采用的方式却全然不一样，他们在意的是在执行之前是否具备足够的规则校验措施，在执行过程当中能不能精确把控风险状况，在执行完毕之后一旦出现问题可不可以迅速进行定位处理以及全面回滚操作所涉及内容。所以，基于此 DBA 对于平台的要求自然而然并非仅仅是“增添一项审核功能”这般简单，而是需要构建起一整套能够实现切实追踪、严格施行限制、全面达成回溯目标的系统性有效运作机制。

即使不存在此一机制的情形下，假令SQL审核已然臻于足够完善的境地，却仍旧极易演化为那种仅是流程存在然而风险依旧照旧维持原状的状况。DBA所需的并非是另外一个处于孤立状态单独留存的工具，而是能够将数据库访问事务、规范限定事宜、审批流程事宜、执行操作事宜、安全保障事宜以及审计检查事宜，通通都纳入到一整套完整周密的体系体制之中。应当促使生产变更的模式，从原本依赖经验进行补充缺漏的方式，转变成依靠机制予以严格约束的方式，这才是治理工作所应当蕴涵的真正意义所在。一旦缺失掉任何其中一个环节的话，那就意味着风险仍然是处于控制范围之外而未被有效管控的游离状态。

打通链路建立闭环

针对数据库治理，不能仅仅将目光聚焦于“审核”这一行为动作，而是要去查看在整个链路方面是否存在闭合情况。这就需要从多个不同方面来着手进行：要统一数据库的访问入口，而不是让每个人都对生产库进行连接；要把SQL规范预检的相关工作提前放置，而不是依靠人工去进行审核；要把审批以及执行放置在同一个链路当中，而不是在审批通过之后再经由人工进行转发；对于高风险的DDL/DML在生产环境下要强化约束，而不是仅仅依靠提醒；与此同时要补充完善审计、追踪以及回滚的能力，从而能够确保在问题发生之后可以进行查询、可以进行控制、可以进行恢复。

仅在这些环节通通被打通之际，SQL审核才切实被纳入数据库DevOps体系中，并非独立悬挂在外边。当下的平台设计趋势也证实了这一情况，像NineData这类产品不再仅仅做一个审核工具，而是弥补上了审核前后所缺失的环节。凭借规则去限制生产环境SQL窗口内的DDL/DML，叫高风险操作强行转为SQL任务，接着经由规范的预检以及审批流程去执行，从机制层面解决了入口没收口的问题。

从工具思维转向体系思维

在往昔，不少团队的行径是，客户端承担连接数据库以及实施执行的职责，DBA 负责于这些系统之间进行人工填补空缺。当审核工具仅仅是诸多分散系统里的一个点之际，数据库变更管理出现偏差近乎是必定的。缘由在于，你们尽管部署了 SQL 审核，然而却未曾构建数据库变更闭环。审核工具处理了“这条 SQL 是否存有问题”的局部判定，却不能够回应“这条 SQL 可不可以在恰当的人、恰当的流程、恰当的环境之中，以可审计、可追踪、可回滚的方式予以执行”这个整体问题。

对数据库管理员而言，更具价值的并非增添一个工具，而是将数据库访问、规范、审批、执行以及安全、审计纳入一套平台之中。使得生产变更从依赖个人经验去填补漏洞，转变为依靠机制自动保障安全。唯有如此，SQL审核才切实发挥了其在治理体系里的效用，而不是沦为一个被绕过的徒具形式之物。

在你团队于数据库变更管理进程里，有没有发生过“流程结束了，问题依旧出现”这种状况呢？欢迎于评论区讲述你们是怎样去处理这些闭环难题的。

相关标签： # 数据库治理 # SQL审核 # 变更管理 # 闭环机制 # DevOps平台