工程团队如何合理地管理数据库访问

一直让 DBA 或者负责运维数据库的团队头疼的事情，是如何合理地管理数据库的访问。一方面，数据库运维团队希望能中心化地管控数据库的访问，但另一方面，使用数据库的开发团队希望可以随时随地就能访问数据库。

前者的极端就是，所有访问数据库的行为，都需要经过数据库团队的审批，这会导致数据库团队成为瓶颈，拖累产品交付进度，被研发团队不断投诉。

而后者走向极端的话，则是数据库的访问权限到处散落，数据泄漏；没有标准化的变更流程，导致 #删库跑路 之类的恶性线上故障。

那有没有既能兼顾管控，又能保证效率的理想方案呢？让我们先来拆解数据库访问的场景，再来提供解决思路。

数据库访问场景

访问数据库的场景分两大类：一种是程序访问 (Machine to Database），一种是人工访问 （Human to Database）。

其中程序访问分为：

• 响应用户从网页端/移动端发出的请求 (end user initiated)，通过应用服务器 (Application Server) 对数据库进行的增删改查操作，比如用户在外卖软件上下一个订单，最终就会在数据库中生成一条订单记录。

• 软件部署时的数据库变更 (change on deploy)。有时软件版本升级后，也需要对于依赖的数据库 schema 或者数据进行变更。许多软件的做法是在新版本第一次运行前进行变更，不少语言的应用开发框架以及 ORM 也都内置了相关的能力，比如像 Ruby on Rails 提供的 Active Record Migrations, django 的 Migrations。

• 后台定时服务访问数据库 (cron)。比如说财务对账系统，定期进行自动对账操作，最终在数据库中生成对账记录。也比如说下游数仓从数据库同步数据。

• 一次性执行 (one-shot / on-demand)。比如牵扯复杂业务逻辑的数据清理/迁移/订正。这些操作会包装成单独的脚本或者是命令行程序 (CLI)，仅在需要的时候被运行。

人工访问可以分为：

• 交互式的数据查询 (interactive query)。直接连上数据库，使用 SQL 语言进行数据查询。

• 数据订正 (ad-hoc data correction)。直接连上数据库，使用 SQL 语言进行数据订正。

• 数据库 schema 变更 (offline schema change)。用户有时也会直接连上数据库，进行 schema 变更。所谓的删库跑路，指的就是用户错误地执行了 DROP TABLE / Database 的 schema 变更操作，导致了严重的甚至是无法挽回的损失。

• 数据库运维管理 (admin operations)。DBA 连上数据库，进行管理员操作，比如终止执行时间过长的 SQL 语句。

直接人工连上数据库进行操作是高危行为，所以通常组织会设置跳板机 (Bastion / Jump server)，在跳板机上，可以对数据库操作进行一定的管控和审计。但设置跳板机对使用者也带来了更多的不便，也引入了额外的管理负担。比如要考虑究竟是给数据库访问设置单独的跳板机，还是共用访问其他生产系统的跳板机。

解决思路

首先我们要明确几个点。

1. 访问数据库尤其是线上生产数据库是高危操作。即使不是变更，一条不经意的 SELECT 语句也可能拖垮整个数据库，造成严重故障。所以说，但凡有条件，管控是必要的。

2. 尽量减少甚至避免手工直接连上数据库的操作。是人就会犯错误，而且手工连接数据库也意味着需要把数据库的访问信息给到个人，大大增加了数据泄露的隐患。

3. 应用程序访问数据库是无法避免的，否则程序就无法正常运行。但是对于数据库的 schema 变更是可以单独分离出来的，不需要在应用新版本部署后，第一次运行时进行变更。而且把 schema 变更和应用部署解藕可以更好地掌控整个变更流程，以及应对可能的回滚。

基于以上几点我们给出了数据库访问场景的理想划分：

这里我们引入了 Bytebase，它不仅可以包揽人工访问数据库的所有场景，同时也把 schema 变更统一成了一套具备管控能力的流程。

• Bytebase 定义了两层权限模型，一个是在整个 workspace 级别的全局权限，一个是在 project 级别的具体业务开发项目权限。这两层的权限体系分别对应到中央的 DBA 团队和各个应用项目组的开发团队。

• Bytebase 提供了可视化界面，来管理数据库 schema 以及数据的变更审核流程。同时还支持和 GitLab, GitHub 集成，提供 Database-as-Code 的 GitOps 流程。

• Bytebase 提供了 SQL Editor，开发者可以进行查询 SELECT 操作。而对于 DBA 们来说，可以在 SQL Editor 中开启管理员模式，执行数据库管理命令。

• 用户可以配置 SQL Review 审核规则。如下图，在数据变更流程中，规则阻止了用户执行不带 WHERE 的 DELETE 语句。并且针对研发流程中的 dev, test, prod 等不同环境，用户还可以配置不同的规则。

• 还可以配置不同的审核策略，比如 dev 环境，可以跳过 DBA 审核；prod 环境，必须 DBA 审核或者也可以要求 project owner 审核。

总结

对于数据库的操作需要慎之又慎，但在保持必要谨慎的同时，研发团队也希望能提高效率。Bytebase 作为被CNCF Landscape 唯一收录的 Database CI/CD 解决方案，提供了企业级的一站式数据库开发生命周期管理能力。

对于 DBA 或者负责数据库运维的团队来说，通过 Bytebase 便可以收口除应用程序访问之外的所有数据库访问路径，在此之上进行全局的数据库管控和操作审计。而对于需要使用数据库的应用开发者来说，Bytebase 提供了开发者友好的操作界面，辅助他们高效安全地完成数据库开发工作。

保障安全生产，兼顾开发效率。