如何搭建数据库自动化运维体系

需求背景：

随着业务的增长、对运维效率和质量的要求不断提高，对自动化运维体系的需求也不断增强。

目前笔者服务的很多中大型企业客户，运维其实还停留在“刀耕火种”的原始状态。

这里所说的“刀”和“火”就是运维人员的远程客户端，例如 xshell 和Windows 远程桌面。

这种工作模式有很多局限性，

比如服务器、数据库、中间件等的安装、初始化，应用软件部署、服务发布和监控都是通过手动方式来完成的。

这就需要运维人员登录到服务器上，一台一台去管理和维护。

如果有个几十上百台，累就累死人了。

笔者曾运维过超过4000千台服务器，团队二十多个人，仔细想想这活靠人力能干吗？

另外人工操作方式过于依赖运维人员的执行顺序和操作步骤，稍有不慎即可能导致生产事故，即便是变更前double check也很难保证不出事故。

常在河边走哪有不湿鞋。

这时候运维人员开始探索使用使用脚本和批量管理工具。

这种方式确实提升了效率和质量，但是不具有普适性。

第一是脚本的非标准化的问题。
每个运维人员都有自己的解决问题的风格，不同的人员之间存在巨大差异，那么不同的人开发这些脚本的版本管理就是一个挑战。

第二是脚本的交接问题，公司人员的架构不是一成不变的，有人来就有人离开。离职和工作交接，都会导致脚本无法很好地在运维人员之间传承和再利用。
因此，构建自动化运维体系成了唯一的选择。

那么如何建设自动化运维体系呢？本文研究分为三个大的方面：

第一个是为什么要建设自动化运维体系？
第二个是根据笔者经验介绍运维系统是怎样设计、运行和处理问题的。
第三个是笔者在自动化运维过程中遇到的一些问题的思考，做一个总结。

本文针对数据库自动化运维系统
核心内容如下：

一、建设自动化运维体系的原因
为什么要建设一个自动化运维体系。

肯定是运维过程中遇到的一些挑战。
第一个是变更的需求。

它表现为三个方面:

一是变更数量多，目前我们服务的客户达到3万家企业，这个体量是很大的。
二是变更种类多，不同的客户需求是不一样的，包含但不限于扩容、性能优化、故障处理、DG切换迁移、RAC搭建等。
三是变更风险大，有些变更都是一些高危操作，自动化处理更安全等。

第二个是运维环境方面，主要表现为服务器数量多、数据库类型多。我们的客户可以自由选择使用哪种数据库，分别对应不同的环境。
第三是人的因素。

在建设自动化运维体系过程中，有一个比较重要的考虑点是人的因素。
正是因为每个运维人员的能力不一样，技术水平参差不齐，甚至是运维习惯和工具也不一样。

导致我们必须要创建一套规范的自动化运维体系，来提升工作效率。

二、如何搭建自动化运维体系
下面我们来看一下每个模块是如何设计和工作的。

1、自动化安装系统
安装数据库是比较繁琐但数据又多的工作之一。

操作系统多，但是人少，可用时间也比较少，自动化安装省时省力。整个自动化流程采用通用的框架，主要是针对linux下的Oracle安装和MySQL安装。

交付用户之前，会进行基本的安全设置，这在一定程度上提高了安全性，也减少了需要人工做的一些操作。

2、自动化运维平台
当服务器由自动化安装完数据库以后，就会被自动化运维平台接管。

自动化运维平台是运维人员的操作平台，它主要解决安全、高效、快速等因数量特别多而带来的管理问题。

在设计的过程中要考虑了以下几个因素：把整个运维系统的操作界面设计成基于堡垒机的架构。

运维工程师无论何时何地都可以登录管理系统进行运维操作，这样的话就比较方便，由SecureCRT对被操作的机器发布指令。
充分利用现有协议和工具。这个平台的特点是所有的系统使用SSH管理，而不是自己开发一些Agent，这也体现了自动化运维的观点。

3、自动化巡检系统
由于我们的客户系统比较多，业务也比较多，怎样设计一套系统去巡检它们的运行情况呢？

我们采用了两种方式：自我开发的中控系统和第三方管理平台先看自己开发的中控系统：

单独使用一台服务器巡检其他的数据库节点，脚本可以选用shell或者Python。

设定遍历时间间隔，遇到故障情况可以采用打电话或者发短信的方式及时通知运维人员。

第二是把所有的数据库节点纳管到第三方监控平台。

4、自动化性能分析系统
系统并不用永远都稳定运行，性能问题是无法逃避的问题。性能分析系统是重中之重。

这里笔者单独再写一篇文章。

5、自动化监控预警系统
通常客户的系统都是7*24小时运行的，这就要求必须有预警监控。

预警监控系统+值班人员是标准配置。

预警监控系统的搭建方式参考巡检系统，只不过采集的指标不一样。
6、自动化备份系统

两地三中心+DG+NBU

三、建设自动化运维体系的思考
笔者将自动化运维体系的建设目标总结为四个词。

第一个是完备，这个系统要能涵盖所有的运维需求。
第二个是简洁，简单好用。运维人员的学习成本不要高，越复杂难用的系统越不容易发挥系统本身的能力和效率。
第三个是高效，特别是在批量处理或者执行特定任务时要高效。
第四个是安全，如果一个运维系统不安全，可能导致很快就被黑客接管了。
总结

笔者目前也在从数据库的架构、优化和故障处理慢慢转型做自动化运维体系。

对过去进行总结，我觉得有3个方面可以供大家参考。
第一是循序渐进的原则：

聚焦当前的问题，把当前的问题处理好，后面的问题也就迎刃而解。

如果一开始设计的系统很庞大、功能特别丰富，会导致一些无法控制的局面。但是如果一开始的目标是解决一些特定的问题，有针对性，那么推进起来也会比较简单。在笔者参与的自动化运维体系建设过程中，我们的初始目标是构建的是一个基础的变更批量操作平台，先把一部分需要重复执行的工作搬到平台上来。

再依据运维的需求丰富这个操作平台的功能和提升效率，最后把周边的系统打通，相互对接，形成完整的自动化运维体系。第二是考虑可扩展性：

设计系统的时候，功能或者设计方面可能不用考虑那么多，但是要考虑当服务器数量发生比较大的扩张时，系统是否还能支撑。第三是以实用为目的：

使用不方便，运维人员第一个就放弃了，何谈推广？