数据库自动化运维实践

IT 运维团队的日常工作往往都比较琐碎，DBA 群体则尤为突出。在大多数情况下，DBA 不是在修数（修改数据）就是在提数（提取数据），而且要花很多时间去沟通，不难想象一个 SQL 脚本在 DBA 和开发人员之间反复修改和审核的场景，其根本原因在于数据订正没有一个标准化的流程，而这样的标准化流程需要一个自动化的平台来做强有力的支撑。结合实际经验，DBA 工作大概有 5 个方面的痛点。

一、DBA 痛点

1、库表设计规范的落地

自动化运维的一个前提在于标准化，库表设计及 SQL 语句标准化无疑是数据库团队标准化梳理中最为关注的内容，比如命名规范、表设计规范、字段设计规范、索引设计规范以及 SQL 使用规范等，标准确立之后，如何进行标准化落地也是一项难题。通常情况下由开发或测试人员将 SQL 语句提交给 DBA，DBA 会通过人工分析的方式验证语句规范性、合法性和执行性能等，随着标准化的规范越来越多，待审查的 SQL 语句越来越多，检查的成本也越来越高，这在无形之中间接造成 DBA 推行的规范越来越多，验证工作也越来越复杂，久而久之，规范的约束力就很难保障。

2、SQL 语句审核

人工审核很难在大量的 SQL 脚本中发现潜在的问题。像多字符或少字符、半角或全角等完全取决于“视力”好坏的问题着实很难发现，更深入的问题就更不容易被发现了，例如添加已存在的字段，或删除不存在的字段等。如果操作失败，想要回滚也很麻烦，因此每当生产环境要执行 SQL 脚本时，DBA 都会再三确认，小心翼翼地执行每一个操作，因为数据回滚的成本很高，或者有些脚本执行后根本不敢回滚，只能一条道走到底，通过修数解决问题，但这又会引出另外的问题。

此外，SQL 的版本控制也是一个问题。DBA 团队希望在测试环境执行的脚本与将在生产环境执行的脚本完全一致，但如果没有科学的流程和工具，很难实现。多个环境之间执行的 SQL 版本不一致是常态，若完全一致极有可能导致一些不确定的后果。所以，希望 SQL 审核是一个全自动化、纯线上、强约束力的操作。

3、数据提取

在业务发展初期，提数的需求尤其多，原因在于此时业务对应的运营系统还没来得及建设，遇到问题就得查库，在没有相关的自动化平台支撑的情况下，DBA 很大一部分人力资源都得耗在这上面。

4、资源管理

量变引发质变，对于业务规模相对较大的企业，即便是资源管理这样的小事儿，对 DBA 来说也可能演变成一件头疼的琐事。以数据库的创建为例，此类操作本身并不复杂，但考虑到对不同版本以及不同容错模式的支持，加之随着业务规模的扩大，重复性的资源创建等，资源的频繁创建和分配将是常态，若采用人工管理的话，成本投入高不说，也很“费”人，所以通过自动化的方式对资源进行管理很有必要。

5、监控的需求

数据库监控也存在多种维度：从资源存活性角度来看，我们需要对数据库进程进行监控；从数据库性能角度来看，我们需要对事务的执行状况以及吞吐量进行监控；从 SQL 执行的角度来看，我们需要对慢 SQL 进行监控；从容量的角度来看，我们需要对数据库的表空间进行监控等。

数据库自动化运维以解决 DBA 的实际痛点为主，主要包括了 SQL 语句审核的自动化，数据提取的自动化，数据库元数据的系统化管理，以及数据库资源的创建、监控等。

二、数据库自动化运维

1、自动化 SQL 语句审核

自动化 SQL 语句审核完成了从人工操作到自动化的转变。它通过流程来规范审核的过程，底层则是通过相应的中间件来对 SQL 进行检查和约束，实现对关系型数据库（如 MySQL、Oracle）的 SQL 语句自动化评审和校验。

SQL 审核的流程由开发人员发起，请求一经提交，审核平台就会自动检查提交的 SQL 是否符合规范，如果不符合，那么提交就会失败，并提示用户失败的原因。提交成功之后，会生成相应的审核记录，由具备权限的 DBA 审核。DBA 会重新通过自动审核的方式来进行审核，当然也可以人工审核，当审核确定通过之后，审核订单的状态也就变成已通过，此时可以选择直接执行，也可以由请求发起者来自己执行。这里的执行者没那么重要，原因在于 SQL 已经通过双重检查，满足执行要求，同时，SQL 执行完成之后，也会自动生成相应的回滚语句。

在整个 SQL 语句审核的过程中，多数情况下，DBA 需要做的仅仅是在审核完成之后，点击“XXX”按钮，令审核订单变成通过状态。整个过程是全线上操作，便捷度和执行效率都非常高，真正做到了 SQL 审核的自助化，使安全性和可靠性得到有效保障，同时 SQL 规范也能顺利落地，给 DBA 的工作开展带来极大的便利。

2、关于数据提取

关于数据提取，首先想到的是平台化的解决方案，即通过 Web 平台来完成数据库的查询，这本身并不复杂，更重要的需求在于权限的控制以及数据查询的脱敏。

• 权限控制。一方面是数据库账号的权限，对于数据提取来说只能是只读，且预先已经由 DBA 配好，不需要用户关注；另一方面针对权限控制的逻辑，通过平台来进行库和用户角色的关联，就能实现应用负责人只能对所使用的库进行查询。

• 数据脱敏。可以考虑采用动态脱敏的方式，即对 SQL 查询语句进行解析，识别出敏感字段，然后通过替换函数来改写 SQL。敏感字段的匹配则通过维护敏感字段的字典表实现。该表由业务部门自行在平台上进行字段添加维护，由 DBA 进行管理，以保证敏感字段的维护比较完善。

3、元数据管理

针对数据库自动化运维，主要从几个维度进行了配置信息管理，分别是机房、主机、业务、集群、实例、库等。通过这些信息能够比较容易地构建出数据库的物理部署拓扑以及业务对数据库的依赖关系。一方面这些信息在故障关联分析上能发挥较大的作用，另一方面也为后续的自动化运维提供了数据基础。

4、资源的一键部署

通过数据库运维平台实现一键创建适配不同版本、不同容错机制的数据库，例如单机/主从/多主模式，极大地提高了生产力，缩短了交付周期。传统运维模式主要通过人工方式创建数据库，效率低下，执行过程高度依赖于运维人员的个人经验，且重复性的运维工作本身是常态化的；脚本运维模式虽然能够解决人的问题，但难以管理；而平台化的方式则能将类似于数据库创建的操作带到 Web 平台上来，从而实现一键部署，也使操作体验得到进一步提升。

5、数据库监控

对数据库的监控主要从系统存活、性能以及容量三个方面考虑。系统存活监控主要通过对数据库进程的定时探测完成，获取探测结果后，通过部署在服务器上的代理将结果上报到自动化平台。数据库性能监控则主要通过执行数据库内置的指令来查询 QPS、TPS、并发数、连接数等监控指标，慢 SQL 则主要通过日志来进行分析，同样通过代理的方式将相关指标上报到管理平台来进行聚合、图形化展示、分析等。容量监控则主要通过周期性查询 MySQL information_schema 表来进行总体统计、分析。通过数据库运维平台进行监控的优势在于监控指标丰富，可定制化程度高，同时具备较高的可配置性图形化展示以及大屏监控，能够进行周期性的趋势预测。

三、总结

建设数据库自动化运维平台的初衷非常简单，想简化 DBA 的工作，解放 DBA。数据库自动化运维平台除了功能囊括各项日常操作，更是面向数据库运维的综合性的解决方案：一方面，对数据库运维的能力进行了统一封装，提高了操作标准化程度，也极大程度地提高了效率，并且通过流程审批的方式来将这种能力赋予资源请求者，具体的执行过程对用户来讲是透明的，由平台来保证；另一方面，DBA 通过数据库管理平台将自身的角色从一个最终执行者转换为平台的管理者、审核者，规范了流程。