Archery DBpass→NineData，数据库审计工具升级换代最佳实践（2）

云掣YunChe4天前客户案例34

试用结果

NineData 工具从 7 月 3 日，开始在 商品商家 和 物流组 中展开试用。8 月 7 号开始，订单组和 APP 也陆续参与试用。以下是本次试用和调研的背景信息：

参与试用人数：31 名
参与调研人数占比：90%
平台试用时长：60 天
平台累计提交变更任务：426 个任务
平台累计执行 SQL 数量：15 万条

运维视角

NineData 提供了很多可以提升研发效率的功能，已经在商品商家生产环境上得到了验证。以下是运维视角的总结：

研发视角

NineData SQL 任务提交审核的能力，得到所有研发人员一致认可。提升的点主要包括：

动态分批，让原本要驳回的工单，可以直接提交，避免来回流程时间的浪费；
任务通知，执行状态都有通知以及备案，可直接查询朔源；
风险提示，有风险的 SQL 会有提示, 有效拉高数据库语句生产水平，降低生产数据库故障风险；
审批流等级划分，可以让审批流更短，节约时效；
无锁变更，不用拖到凌晨或者低峰期变更，改变严峻的精力消耗情况；
变更备份便于问题回溯；
任务备份，可快速恢复异常数据；
内置规范限制，可拦截绝大多数违规操作；
操作 UI 相比 DBpass 有很大提升，更简单易用，上手容易；
SQL 查询和变更任务提交在一个平台，提升操作便捷度，节省时间。

DBpass 不具备 IDE 的能力，就导致数据库生产环境的访问，没有统一入口，大家都用各自的 IDE 工具，无法做到风险管控和操作审计，会存在账号泄露、违规操作、忘记关闭的慢查询等问题，对生产环境的安全稳定产生威胁。

NineData 具有 SaaS 化 IDE 的能力，可作为生产环境的统一访问入口，其中内置了很多规范和审计功能，可完全杜绝违规操作和账号泄露等问题。经过统计羽如 80% 研发人员，都使用 DataGrip 作为数据库访问工具，切换到 NineData 的话，可能会有使用不习惯等问题，所以在研发试用后，我们对 NineData 是否能够替代本地连接工具的问题，进行了调研，下面是调研结果：

NineData 统一访问，SQL 查询的功能，在研发人群中褒贬不一，大多数认可。其中优点和缺点如下：

AI 提问：可以提问一些数据库相关的问题，比如某些语法想不起来了可以问，甚至一些复杂语句也可以创建编写。
支持会话管理，可以查看数据库会话。
SQL 风险提示，一些可能会对生产有影响的风险 SQL 会有提示和拦截，比如隐式转换。
智能代码转换，可以将表结构转换 java 代码，提升开发效率。
SQL 窗口操作体验：相比本地 DataGrip 要逊色，主要体现在联想提示上。
使用习惯：大部分研发用惯了 DataGrip，NineData 需要重新习惯，数据库管控服务和 IDE 还是存在部分差异。

管理者视角

使用 NineData 作为统一访问入口，任何来自本地的访问都可以通过白名单屏蔽掉，只开通 NineData 的访问生产环境，这样所有的访问都可以被管控，回溯，查询，统计的，有违规操作可以提前拦截，提升生产环境数据库的安全性。

反面案例：

7 月 11 日，在商品商家的只读实例上发现一条非常复杂的查询，持续执行了 5 小时，如果不人为干预，可能会导致集群磁盘打满故障。这时候商品商家已经使用上了 NineData 作为统一访问入口，所以当时非常疑惑，以为组内人员没有按照要求执行。最后定位到是其他团队的员工，拿了商品数据库的连接地址和账号密码，在商品的数据库上执行 SQL，险些造成 S2 级别的故障。

从这次事件中发现的漏洞：

生产环境的连接地址和数据库账号，可能已经在多个业务组之间流通，比如这次事件账号泄露是在两个团队新员工之间流通的，这类情况很难从管理流程上彻底杜绝，总会产生漏网之鱼。

使用 NineData 统一生产环境访问入口，可以完全避免上面情况。