一、背景介绍

我们企业的IT建设采用了不同的数据库产品，有免费的MySQL，也有收费的Oracle，最近信创要求，又上了国产数据库TiDB，数据库众多多样，运维复杂度和难度逐步升高，运维部门的DBA也不多，大部分运维同志对于数据库运维还都是一般水平，远远没有达到专家级别，一方面数据库数量逐步攀升，一方面人员及技能平稳不懂，领导一拍板，让我们采购一款数据库运维产品。

二、选型目标

公司需求

数据库类型有点多，所以我们运维同事非常期望能够又一个统一运维平台来支持，在一个系统内可以直接管理不同类型的数据库，也就是一个平台所有管理。

目前公司10多个业务线条都有自己的业务系统，与之匹配的也都有自己的数据库，再加上测试环境、仿真环境以及各种临时要求，数据库搭建也是经常的任务，对数据库的资源回收也是日常重要工作。如果可用资源不足，就导出检查哪里的资源可以释放，哎，真的是累人，所以最好能够有统一资源管理机制，可以将数据库与实体资源隔离，在线动态管理数据库的资源，方便回收。

在构建环境的时候，我们也引入了一些自动化工作，但是都不是专门为数据库运维的自动化工作，很多脚本都要自己摸索，也给公司带来不少的浪费，如果专业的数据库运维工作可以做到一键创建数据库实例那就太好了。

核心用户DBA需求

DBA是公司数据库运维的核心人物，他们的由于掌握了数据库运维的核心技术，所以每天都非常忙碌，可是大部分时间都忙在一些基础的维护上，相对数据库进行优化、技术咨询等工作都被占用了，实在是太可惜了。

这次DBA们特别强调能够将一些日常巡检工作、数据备份、安全不定、环境构建以及常见的故障分析处理都能够平台化，最好可以由其他人员完成。

综上，希望这次的产品具有平台化特征、自动化能力以及初步智能化诊断水平。

三、数据库运维整体建设三步骤

结合目前市面上给出的产品以及公司内部实际的情况，计划分为一下三步完整公司数据库运维体系化建设。

第一步：运维动作标准化

根据公司目前的运维经验，这里出运维的SOP，当然也不能是全部动作，把常用的且可以整理的做了，先出公司内部的流程规范，通过公司内部流程改进，把标准化动作固定下来。

同步在标准化基础上也收集一波专家常用的解决方案，将解决方案与标准化动作的节点（也就是场景）结合，做到知识场景化。

第二阶段：标准化动作自动化

将已经规定好的标准化流程SOP以及场景化知识，从文档上搬迁到自动化作业平台上。这个公司在实施其他自动化的时候有过相关经验。

一般可以写成脚本的，与机器打交道的都可以放到平台的自动化任务上。

第三阶段：智能运维

将运维数据对接到企业数据中台，通过现在的数据中台的机器学习能力进行分析，主要辅助容量管理，预测未来容量的扩缩容。

同时将历史的告警信息也通过机器学习，进行趋势预测告警

四、本期建设重点：数据库监控

故障管理是目前最最迫切的需求，能够及时发现故障，告警触达到位，多种手段辅助故障定位以及快速的故障恢复是核心能力。

监控指标要全：

数据库监控产品在日常监控方面，基础指标要完整，必须包括存活、会话数、使用空间、基础性能指标、各种日志等内容，我们也非常关心性能指标，才寄上来的性能指标要求能够覆盖场景复杂问题，可以协助DBA快速分析异常。同时要能够做到实时在线监控，大屏上显示的指标要求30秒内刷新一次，关键业务指标最好能够做到10秒内更新。

通知渠道要多：

在发现故障后，要能够在秒级内通知干系人，必须支持多种通知方式，电话、微信、短信一个都不能少，这个不行自动切换成另一个，总之得通知到人。

支持数据库要多：

最少支持主流数据库和国产数据库TiDB。

提供主动巡检功能：

每日巡检必不可少，通过平台工具化，最好能够自动化+告警，可以减少大量的工作，必须有。

监控大屏：

领导要看，值班同事要看，必须好看好用，还得上关键指标，最好有监控大屏案例参考一下。

针对慢SQL能够提供优化建议：

根据采集的性能指标,对于场景的慢查询SQL、阻塞情况、锁表情况提供瓶颈分析以及运维知识关联