如何避免删库跑路，这几乎是一个老生常谈的话题，也是大部分上了规模的企业都很关心的话题，京东到家、微盟、链家、思科... 在这些大企业上发生过的删库事件仍然历历在目，无论是否当事人有意为之还是系统 BUG 导致，造成的后果与损失都是深刻且无法挽回的，只有从物理层面上拦截删库操作，才能在真正意义上杜绝此类事件，毕竟谁都无法保证自己不会成为下一个受害者。

因此本文要聊的话题，虽不标新立异，却也兹事体大，关系到企业最核心的财产：数据。

传统的变更流程

数据的重要性自然不必多言，懂的都懂，然而懂是一回事，实际情况就是，很多企业的数据库仍然存在如下问题：

直连数据库

这是最大的安全隐患，很多企业的数据库账号通常是根据部门划分，即一个部门下所有成员使用同一个账号，难以区分 SQL 执行来自哪个人员，审计难度很大。同时，无法基于每个人员的职责定制权限，存在无关人员拥有变更权限的风险。此外，人员新增、转岗与离职等原因导致的数据库权限变更，也难以有效地进行管理。

变更毫无章法

开发人员的经验和习惯各不相同，他们可能会使用不同的数据库设计模式、命名规则、数据类型等。这可能会导致数据库结构混乱，数据冗余，形成恶性循环，导致数据库时间越长越难以维护。虽然企业可能通过培训等方式推广生产数据库规范，但在缺乏平台规范以及审批流程等强制措施的情况下无法保证所有开发人员按规矩办事。

变更流程不完善

针对数据源提交的变更，多数情况下是由研发人员通过邮件、JIRA 等方式提交给 DBA，当然其中不乏流程不完善的企业直接通过聊天工具进行数据变更的沟通与提交。更有甚者，由研发人员直接进行生产的变更，非常的不安全。

解决上述问题就可以在很大程度上规避删库跑路的风险。下面我将提供一种解决方案，通过 NineData 工具，完整演示从录入数据源、配置规范和审批流程，到研发人员提交生产发布的全过程，展示 NineData 如何解决删库跑路问题。

NineData 集成了数据库 DevOps、数据复制、数据对比多个模块，而我们需要利用它的数据库 DevOps 模块来管理我们的数据库。数据库 DevOps 具有数据库管理、数据查询、SQL 执行、数据编辑、数据导入导出、SQL 审批流、SQL 规范预检、审批流程、敏感数据保护等等功能，可以完整覆盖我们上面说的几个问题。

步骤一：录入数据源到 NineData

通过将数据源录入到 NineData，实现企业内部统一化平台登录，无需再使用各种各样的客户端和工具，最重要的是，彻底杜绝了直连数据库带来的安全问题。

NineData 提供了一个 数据 Owner 的特性，该特性将在后期配置审批流程的时候发挥重要的作用。在创建完数据源（即录入数据源到 NineData）后，该数据源的创建人默认为 Owner。

步骤二：配置开发规范和审批流程

默认情况下，NineData 平台提供了 开发和 生产环境下的通用规范和流程，每个数据源在创建的时候需要选择环境，创建完成后将基于选择的环境默认绑定该环境对应的规范和流程。

如果默认的规范和流程无法满足您的要求，可以根据实际情况手动配置。本流程以 禁用生产库的 SQL 窗口变更能力，以及 配置二级审批流程为例，介绍配置方法。

打开需要配置的 SQL 开发规范详情页面，找到负责管理 SQL 窗口变更能力的两条规则，删除所有允许操作的 SQL 类型。

打开需要配置的审批流程详情页面，找到目标任务的审批流程，新增审批流程并选择审批人。

根据图片的配置，研发人员如果提交了 SQL 任务，并且在规范预检通过的情况下，需要分别通过一级审批和二级审批，才可实际执行到生产库。

这里不得不提一下图片中配置的 数据源 Owner，我们在步骤一中提到过，这是一种简化审批流程配置的方案。因为通常情况下，企业配置审批流程会有两种方法：

把所有审批人员放到一个审批流程：在单个审批流程中放入多个业务负责人，由提交人根据实际情况选择。该方法优点是配置方便，后期有人员变动只需要调整一次；缺点是业务负责人多的情况下，找都要找半天，如果提交人对业务情况不熟悉，还可能选错业务负责人。

为所有业务创建不同审批流程：为避免上述问题，每个业务拥有独立的审批流程。该方法优点是精准；缺点是如果有 1000 个业务，那就需要配置 1000 条审批流程，先不论初始化配置成本，万一有个人员变动，每条流程都需要调整，维护难度巨大。

而通过 数据 Owner 方案，管理员可以为每个业务（数据源、库）配置不同的负责人，即数据 Owner，并在审批流程中选择 数据 Owner 作为审批人，而不用配置具体的人员，当提交人针对某个数据源或库提交操作申请时，系统将自动拉取该数据源或库的数据 Owner，有效简化审批流程配置，降低了操作成本和维护难度。

使用效果

经过上述配置之后，基本就已经大功告成，剩下的就是要求企业内所有需要接触数据库的员工通过 NineData 平台登录来执行相关操作。

已禁用 SQL 窗口变更，普通员工无法在 SQL 窗口直接对生产库进行 DDL 或 DML 操作，页面将引导用户创建 SQL 任务，走审批流程进行发布。

用户在提交 SQL 任务后，系统将先根据管理员预先配置的 SQL 开发规范，对 SQL 进行审核，审核通过后，才需要进行人工审核。由于我们在上面步骤中配置了 规则级别为 符合规范情况下的二级审批流程，因此当系统判断当前 SQL 命中 符合规范之后，用户需要选择两个审批人。

并且，由于我们在配置审批流程时，将 数据源 Owner（即示例中名为 NineData 的用户)选为了一级审批人，因此用户在选择一级审批人的时候，系统自动拉取了名为 NineData 的用户。

当审批人通过审批之后，用户选择的 SQL 任务执行人即可将该 SQL 执行到生产库中了。由于本示例选择的是自动执行，因此当审批人通过后，系统将立即执行该 SQL。

执行完成后，通过 SQL 窗口查询，发现已经成功写入。

总结

至此，企业已经获得了一个较为可靠的数据变更解决方案，再也无需担心删库跑路问题了。

推荐 NineData 的原因，不仅仅是因为它可以完美解决企业的问题，更重要的是，如果企业的数据源数量低于 10 个，它是完全免费的。对于中小企业来说，能够以零成本获得如此全面且强大的数据管理和保护工具，无疑是降本增效的绝佳方案。

不仅如此，笔者介绍的其实仅仅是 NineData 最基础的几个功能，正如本文中的演示效果，可以看到页面左侧导航栏中还有数据追踪、数据归档、SQL 代码审核、慢查询分析、DSQL、数据导入导出等等功能，这些都是可以帮助企业管理数据库的强大工具。实际上NineData 一站式支持数据库 DevOps、数据复制及数据对比、基于 AI 的数据管理，集成企业级身份、安全等能力，帮助开发者高效、稳定的管理多环境、多种数据库。，建议直接上手尝试，亲自体会 NineData 的强大之处。

NineData产品提供三种灵活交付形态，覆盖从个人开发到企业核心的全场景需求！