看中国移动云数据库自动化运维平台建设之路

讲师介绍

刘书浩

中国移动DBA

▼

负责“移动云”业务系统的数据库运维、标准化等工作；擅长技术领域MySQL，熟悉MySQL复制结构、Cluster等架构及运维优化；具有自动化运维经验，负责“移动云”数据库管理平台的开发和部署。

一、前言

作为云服务供应商，“移动云”发展到现在大约有15万的在网客户，提供云主机、云存储、云网络、云安全、RDS等大约10种产品。

随着“移动云”业务的不断增长以及全国各地资源池的陆续上线，我们管理的数据库实例较两年前翻了一倍，但DBA人数基本没有变化：

一方面是因为“移动云”标准化完成的比较早；

另一方面要归功于自动化运维工作的开展，在不到两年的时间内，我们从数据库的标准化、工具化过渡到了自动化和平台化，未来的目标是希望能进一步做到智能化和服务化。

本文就将针对我们DBA团队完成的“EcloudDB数据库管理平台”的构建和开发思路做一些简单介绍，主要分享前期数据库运维遇到的瓶颈，标准化构建和自动化平台“模块化”、”轻量化“搭建思路方面的内容。

二、自动化运维演进过程

首先，平台化的过程并不是一蹴而就的。

在业务上线初期，数据库管理员每天工作强度都很大，因为很多系统是刚刚上线交维的，变更操作比较频繁，经常会遇到一些突发故障需要处理。即便是简单的更改数据库参数配置的工作，也因为MySQL实例数较多，又涉及不同的业务系统，要耗费较多的时间和精力。

在这样的情况下，我们开始考虑将重复的工作简单化，并且把我们的数据库管理人员解放出来，做一些优化类的工作，从而使系统更加稳定。

早期我们主要从标准化、工具化以及脚本化三个方面探索自动化运维的可行性，并储备了一些运维研发技术，像Python语言和一些Web开发技术，可以说是平台化的前身。

1、标准化

首先，标准化是自动化的重要前提。“移动云”的标准化制定的比较早，并且从OS标准化到DB层的标准化都有着统一的要求。

OS层标准化

主要包括：

操作系统版本、文件系统类型、磁盘调度算法（Deadline）、RAID、IPSAN挂载、基础依赖包、NTP服务、SELinux、NUMA特性、ulimit、vm.swappiness、防火墙和网络策略等。

数据库标准化

•目录结构：程序目录、配置文件目录、数据目录、日志目录、PID/Socket、脚本目录、工具目录、软连接；

•用户权限：bcrdb：bcrdb 775；

•参数配置：规定了my.cnf文件全部参数配置、除个别参数（硬件相关、主机IP）外，其余保持一致；

•账号权限：统一DB账号权限要求：最小权限原则、限定来源IP范围、加密措施等；

•密码策略：安装密码验证插件，设置强密码规则；

•日志要求：安装审计插件，开启审计日志、错误日志、慢日志、binlog和备份日志；

•线程池：线程池参数设置需考虑服务器硬件配置和业务系统并发情况；

•常用工具：安装percona-xtrabackup 2.2.12备份工具、安装percona-toolkit 2.2.16工具集用于日志切分、慢日志分析、在线改表、数据一致性校验等功能；

•计划任务：在bcrdb用户下创建计划任务，用于定期进行数据备份及校验、调用Zabbix监控脚本等。

其中，目录结构标准化的好处是，无论谁来处理问题，都能根据标准化路径到达目的地，找到自己所需的内容，也使得我们可以通过编写脚本实现对数据库的批量操作。

标准化的好处有很多，但在未做到自动化部署之前，MySQL严格要做到标准化是比较困难的。

早期我们投入了很多精力做“标准化部署文档”，但效果并不好。因为早期部署阶段由工程人员实施，而工程人员的流动性比较大，导致对“标准“的掌握并不到位，部署结果总是跟标准化有偏差，经常要进行标准化整改，使部署周期变的很长。

后来我们总结经验，从“移动云”五期部署开始，除了提供“标准化部署文档”外，还提供了标准部署工具包和Ansible playbook文件，通过Ansible工具自动推送部署。到现在数据库的部署安装，慢慢用自动化的方式来实施了，进一步保证了标准化的质量。

自动标准化部署过程

Step 1：根据数据库的部署规划和配置要求分配物理机或创建虚拟机。

Step 2：部署Ansible工具。

Step 3：OS初始化，结合数据库部署要求。

操作系统版本、文件系统、磁盘调度算法Deadline、RAID10、挂载点、基础依赖包、NTP服务、SELinux、NUMA特性、ulimit、vm.swappiness、防火墙端（服务和节点通信同步复制端口）、网络策略等。

Step 4：上传Ansible剧本包、标准bcrdb部署包。

•采用Ansible roles的方式编写playbook，实现数据库的批量推送安装；

•上传ansible剧本包playbook.tar.gz至Ansible服务器的/apps/components/roles/目录下并解压；

•上传bcrdb.tar.gz程序包至Ansible服务器/apps/components/roles/bcrdb/files目录并解压；

•修改文件用户、组及权限。

Step 5：制定初始化参数（编写Inventory文件）。

初始化参数：

•集群节点参数：node_address、node_name、cluster_address

•业务和硬件配置相关参数：max_connection、innodb_buffer_pool_size、wait_timeout

打开hosts.sample中数据库部署Inventory文件，替换本次部署安装的实际参数，生成本次部署安装用的Inventory文件：

vim/components/hosts。

Step 6：执行推送部署

选择playbooks目录下对应的数据库playbook文件，使用ansible –playbook命令执行安装

ansible –playbook –i host playbooks/bcrdb.yml

2、工具化和脚本化

有了标准化作为基础，我们开始慢慢引入了一些开源工具，有针对性的解决一些运维中的问题。这个阶段引入的工具主要有Zabbix、ELK、Ansible、Percona tookit工具集、Percona xtrabackup备份工具。

•其中，Zabbix的引入解决了数据库的监控问题，早期我们运维是非常依赖Zabbix的。它的好处是监控项很全，并且有告警发生会第一时间通知到DBA。Zabbix足够的轻量化，比较容易部署和配置，在运维起步阶段提供的帮助是非常大的。

•ELK可以用于日志采集和分析。我们同步了现网数据库的审计日志、慢日志和错误日志，通过ELK可以按条件对日志进行筛选和查询，对于故障快速定位和故障原因追溯有很大帮助。

•Ansible主要用于数据库批量标准化部署。

•PT工具集主要用来进行日志切分、慢日志分析、在线改表和数据一致性校验等功能。

•Xtrabackup用于数据库的在线备份，是最常用的工具之一。

同时DBA也不断开发和自研一些自动化脚本，例如：

•自动化巡检脚本，用于定期巡检并按模板生成巡检报告；

•备份和备份有效性校验的脚本，用于定期执行备份，并对备份文件的有效性进行测试验证；

•另外，还有数据一致性校验脚本、标准化核查脚本等等，用于辅助DBA日常工作，减轻一些重复性的劳动。

3、平台化目标

有了运维工具和脚本，解决了我们早期工作中的一些难点，但是工具解决的大部分是如何发现问题，却很少涉及如何解决问题，而且工具之间的壁垒也使得整个运维体系显得零零散散。

另外，大多时候运维人员还是要通过堡垒机ssh登录到数据库主机，再经手工执行命令或脚本进行运维操作。因此，一定程度上存在操作不便、效率低、重复工作、安全性较差等问题。

总的来说，工具和脚本运维，虽然缓解了一部分的工作压力，但是没有一个体系化的构建。所以在这样的背景下，我们也开始寻求更高阶的运维方式——运维平台的建设 。

平台化的目标是整合已有自动化运维工具和手段，将复杂操作、重复操作程序化，并收口登录数据库主机的操作行为，提高操作安全性，增加管理和审核机制，提升运维效率，减少人为故障，解放运维人员。

三、自动化运维平台

1、构建思路

在平台的构建模式上：

首先，平台实现的功能要以实用为主，并且可以满足快速搭建这两个特点。开发过程中要避免过度设计，后续再以快速迭代的方式对平台进行不断完善。

其次是平台的扩展性要好，为了尽量避免耦合采用前、后端分离的方式。因为平台不仅面向DBA，还要面向一部分系统运维人员和研发人员，因此需要动态菜单。不同权限，不同业务的人看到的菜单是不一样的。平台还要记录操作日志，登录人员做了哪些操作这些信息还是需要格外重视的，起到一个安全审计的作用。

最后，在交互实现方面，要做到可视化、自动化和自助化。通过使用直观的用户界面，使DBA、开发人员和管理人员能够清晰的看到数据库的总体运行情况，帮助DBA更轻松地解决复杂的数据库问题。

2、技术栈

技术栈的选型主要考虑满足平台可扩展性和快速搭建这两个特点。平台后端采用的是Django框架，前端采用Vue.JS，同时利用了缓存Redis和MySQL作为数据存储，整套系统采用的技术栈较简单，实现的功能对于目前来说是比较实用的。其中：

•vue属于前端的架构，平台采用前后端分离的方式，并没有采用Django的Jinja2，主要是考虑到未来后端框架的扩展性以及伸缩性。后台和前端的交互，只通过标准的restful接口进行数据传输。后台采用成熟的Django架构，能够快速搭建一个后台网站。

•Redis作为信息缓存器，主要存储一些前端Dashboard以及数据库的基本信息，加快前端访问速度。

•Django-Celery模块用于异步任务，由于一些数据库操作（备份、任务调度等）执行的时间较长，没有办法立即返回结果，因此需要采用异步形式完成操作。

•Ansible用于一些批量的数据库推送、搭建以及批量的数据库配置。

•数据连接采用pymysql模块，能够实现不同种类数据库连接。

3、平台架构

平台的架构体系设计为三层：

•首先是交互层，主要指用户对平台的使用体验，在一定层次上对用户的操作行为有一定限制性。主要作用是使用户可以通过浏览器对平台进行操作处理，包括web UI层及接口层。

•中间是服务层，主要任务是将交互层用户提交过来的请求及参数，通过相应的API接口连接到后台，后台控制器通过各自API和路由列表匹配到相对应的view，然后进行一系列的逻辑处理。这一系列的逻辑处理我们把它归类为服务层处理。

•底层属于资源层，主要包括：

数据服务，为服务层提供数据管理、查询和数据逻辑处理、数据读、存取等服务；还包括系统层（主要指主机OS层）为上层提供基本的运行环境保障、基础组件支撑、和本地文件路径等服务；另外还有一些其他资源，为上层数据逻辑处理提供公共组件和日志输出等服务。

平台的访问流程如下：

•首先，用户通过浏览器访问前端页面，前端页面将请求发送到后台API，后台经过中间件，通过用户认证后跳转至主页。根据平台用户权限不同，会返回相应的页面给用户；

•然后是用户进行自助操作，平台根据用户自助操作选项找到对应的view进行处理，view根据请求是否耗时，判断要不要采用异步任务；

•另外，view还需要根据请求查看是否牵扯系统层的操作，如果牵扯则需要调用Ansible接口工具，对远程主机进行操作。

4、平台功能

平台是分两个阶段进行开发，一阶段主要实现的功能有：

•Index展示页面；

•平台用户管理：管理员设置、访问用户设置；

•备份管理：备份执行、备份恢复、历史备份、备份策略；

•数据库账号权限管理：DB账号权限概览、账号申请、账号审批、账号管理；

•实例管理：一键标准化部署、实例管理，创建数据库、表、存储过程、触发器、事件、视图；

•巡检管理：一键巡检、常规巡检项快速排查、自定义巡检项；

•SQL审核。

平台Index页面

用户认证成功后会跳转到Index页面，主页最上面可以展示：各资源池MySQL实例总体运行情况，在这可以直观看到是否有节点存在异常。

下面可以显示不同资源池、不同业务系统后端数据库的健康度、性能指标（TPS、QPS、请求队列长度、活跃线程数等情况）以及各资源池告警信息展示。有了健康度信息，DBA就可以直观的掌握生产环境的运行情况，并且在此基础上，判断数据库的运行状态，对可能出现的问题进行预测：

另外由于数据备份的重要性，我们也把备份监控放在了首页上进行展示，页上可以看到备份的执行时间、执行情况、备份校验和备份文件大小等信息。除了以上主页，还可以展示平台用户的访问和操作记录。

用户管理

管理员可以通过用户管理模块对平台已注册账号的相关权限进行修改。普通用户可以通过如下步骤申请开通数据库账号：

首先是用户填写HTML表单并提交，此时状态将更新为等待管理员审批，当管理员登录平台系统会提示有待办，点开后可进行处理，如果管理员审批通过，系统会自动创建账号，并通知用户创建完成。

管理员待办页面普通用户是看不到的，另外，管理员还可以对现有DB账号的权限进行修改，也可以创建和删除账号。

备份管理

平台侧可以提供备份执行和备份恢复的功能，这里的备份功能，更多是用于变更前或故障发生时的临时备份，并不是日常备份。

“移动云”的日常备份是利用xtrabackup工具在数据库本地做物理备份，然后定期拉取到测试机上进行恢复校验，每次恢复测试并不是全量，而是抽样对核心的数据库实例做测试，最后通过日志记录测试结果，也会定期使用NBU进行异地备份，以上都是通过计划任务和备份脚本实现的。

平台也提供了备份恢复的功能，可以指定某个时间点的备份文件对现网数据进行恢复。平台也提供了在测试环境进行数据恢复的接口，可以将个别业务表的历史数据恢复并导出，用于数据比对和故障排查。

平台侧可以对备份策略进行设置，对日常备份的执行时间、保留周期、备份方式等进行设置或修改，并且提供了对每套数据库进行策略修改的接口，例如：可以设置OP数据库每周日凌晨两点执行全量备份，周一到周六每天凌晨两点执行增量备份，也可以设置备份文件的保留周期为一个月或两周。

巡检管理

平台设计了一键巡检功能，用于数据库的例行巡检。可以选择多台数据库批量执行巡检，巡检结果可以在Web页面上查看，DBA可以直接填写巡检结论。针对每套数据库会生成一份标准格式的巡检报告，报告可以从Web页面直接下载，这项功能为DBA减少了很多重复工作。

巡检的项目一共有40多项，涵盖了主机硬件、操作系统和数据库三个层面。包括：

CPU和内存利用率、磁盘空间剩余情况、磁盘读写情况、平均TPS/QPS、业务表主键、数据量大小和高水位等情况以及业务压力、慢查询和备份等情况。

另外，平台也提供了快速巡检功能，用于对一些常规项巡检进行快速排查。常规巡检项主要是DBA根据以往故障处理的经验总结下来的一些常用的排查项目，例如：processlist当前连接情况核查、数据库阻塞的情况核查、锁争用的检查以及一些临时表和查询缓存等情况的检查。

对于DBA来说，一般出问题或者接到告警，通常都要登录到服务器通过手工执行命令排查故障。

其实这个诊断过程完全可以被自动化掉，日常处理问题的核心原则是“快”，所以平台必须能提供这样的能力，出问题时尽量减少 DBA 思考的时间，平台可以将 DBA 常用的排查命令集都整合到一起。DBA 只需要进行简单操作，系统就会自动执行所有命令，如：SQL执行计划分析、慢查询分析、锁分析、processlist快照查看等常见操作。虽然这些功能看似简单但是却非常实用，可以提高DBA故障定位的效率。

作为对常规巡检项的补充，平台也提供了自定义巡检项的功能。并且执行SQL语句的时候，结合了语义审核和转译的功能，保证DDL及DML的正确使用，不会造成线上事故。

SQL审核

为了避免性能比较差的SQL语句进入生产系统影响数据库性能，平台也提供了SQL语句审核的功能。

这个功能并不是完全自主开发的，我们借助了开源工具YearningSQL，并做了一些扩展，加入自定义的一些规则。平台会自动对要执行的SQL做分析，通过触碰事先定义好的规则来判断这个SQL是否可以通过审核，无法通过自动审核的SQL再由人工来处理。

实例管理

平台为实例创建，提供了一键部署的功能，进一步简化了标准化部署的过程。平台通过调用底层Ansible模块可以进行数据库的批量推送安装，只需要在Web页面上选择要推送的主机，并对一些初始化参数进行定义就可以了。推送完成后平台会调用标准化核查脚本对部署情况进行核查。

另外，还可以在平台实例管理模块下面，创建数据库、表、存储过程和触发器等。用户只需要按照菜单提交申请。后台核实用户权限后会自动根据需求进行创建。平台也会自动记录创建人和组别等信息。

此外，平台也为DBA提供数据库、表和存储过程的管理接口，DBA可以在平台侧对数据库、表字段等内容进行修改。

二阶段规划的功能有：

•日志管理

•慢查询管理

•阻塞与锁冲突分析

•信息查询

•监控告警

四、总结和建议

最后是一些经验总结，希望能给大家提供一些帮助。

首先

在设计产品或数据架构上要遵循一个原则，就是化繁为简，避免过度设计，大到功能的实现，小到一些页面美观的细节，不要拘泥于追求完美，最好能做到敏捷开发，通过不断迭代来完善平台的功能。

其次

开发过程中要注意需求管理。我们在实际开发过程中有过几次需求变更。相比于早期的规划，不断的提出一些新的功能需求，导致开发周期被拉长。

最后

平台的稳定性是一切的基础，在正式上线前一定要经过严格测试，保证各项功能的实用性和稳定性，这样才能最大限度的发挥平台的效率优势。

Q：请问平台的建设是否采用敏捷性开发呢？

A：采用，一阶段先完成基础功能，后期二阶段每次都交付一个最小可用的产品，不断的迭代来满足业务需求，可以让用户快速看到已经落地的功能，提升平台的可用性，避免陷入越做越大、交付周期过长的困局。