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

大家好，今天来为大家解答数据库自动化运维这个问题的一些问题点，包括如何搭建数据库自动化运维体系也一样很多人还不知道，因此呢，今天就来为大家分析分析，现在让我们一起来看看吧！如果解决了您的问题，还望您关注下本站哦，谢谢~

35岁IT男,做数据库运维是否有前途

数据库运维，也就是数据库管理员，简称DBA。这个职业在十五年前是十分有前途的。薪酬回报很高，在那段时期，也诞生了很多十分有名的DBA。比如说Fenng，冯大辉（曾任支付宝DBA团队的Leader）（这里只说他有名，关于他的技术、人品不作讨论，无论你怎么看他，他在技术圈有一定知名度是无法否认的）。

但现在，DBA已经不是一个很好的工种。加班、工作时长、薪酬回报不高，这就是DBA职业的现状。不过，如果会开发，比如Python。Python+DBA，可以做运维自动化工程师，是非常有前途的。如果你想法DBA，建议向这个方向发展。35岁，也可以的。

数据库的话，建议以Oracle、MySQL这两大数据库为主。同时掌握这两种数据库的管理与运维。当然，选其他数据库也可以。这两个数据库比较主流。

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

需求背景：

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

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

这里所说的“刀”和“火”就是运维人员的远程客户端，例如 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个方面可以供大家参考。

第一是循序渐进的原则：

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

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

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

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

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

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

标签：能力两种ble扩展事故团队简洁体系之间

数据自动化运维应该注意哪些事项

一、基础数据概况

CMDB中文是配置管理数据库，存储与管理企业IT架构中设备的各种配置信息，与未来的IT运维管理标准化和流程化紧密关联，并且支持流程的运转。运维管理平台创建初期或初版中的CMDB更多是偏向IT资产管理，我们在这里定义的IT资产管理，暂时抛除公司个人使用的普通PC机。

日志主要存储CMDB中涉及到服务器或是其它设备的日志信息。

DB主要是所有IT系统的数据库信息，包括运维管理系统本身的数据库。由于数据库的重要性，所以在基础数据中单独一个模块管理数据库，包括生产数据库、测试数据库、开发数据库。数据库的日志放在日志模块进行统一管理，监控和备份。

知识库主要存储日常运维管理中发生的事件、问题以及一些经典问题的解决和常用的解决方案，主要起到运维管理辅助的功能。

二、基础数据三要素

基础数据要求完整、准确、实时，这三个特性缺一不可。

1.完整性

完整性，要求在数据采集整理阶段，要一一梳理，不能有遗漏。任何一个设备的疏漏都将会导致未来出现问题。例如最近的勒索病毒在防范上需要给服务器升级打补丁，这个时候就是根据服务器清单一一对照，升级。如果有遗漏落下的服务器未及时打补丁而导致病毒入侵，后果将很严重。那么，如何做到完整性呢？大致可以分为以下几步：

首先数据采集阶段多人（推荐三人以上）同时对IT资产进行采集，那么在数据采集完成后，将会有三份或以上的IT资产清单。

接下来就是相互确认阶段。相互check对比两方的清单和自己梳理的清单，找到不一样的地方，大家在一起开会进行讨论。经过这个阶段，会产生一份相对完整且三方（或以上）认可的IT资产清单。

最后就是三方（或以上）一同针对认可的IT资产清单进行最终check，确保最后的清单，是经过多方讨论确认，并最终又check过的IT资产清单。此时这份IT资产清单，相对比较完整。另外在梳理、讨论和check的过程中，针对新增、变更、删除的IT资产一定要及时更新我们的IT资产清单。

2.准确性

准确性要求IT资产清单或是CMDB中存储的数据不能与实际情况有任何差异。要做到基础数据的准确性除了在数据采集阶段要下功夫外，要在运维管理的每一个阶段定期对基础数据进行审计，确保基础数据中的数据无误。一般月度一小审，半年一大审，具体情况根据企业的IT规模而定。

3.实时性

基础数据的实时性可以确保数据的准确性。即基础数据的每一次变动，包括增加、删除、修改，不论大小，只要有变动（在运维流程完结阶段，执行运维操作成功后，就要及时更新基础数据。忽略基础数据的实时性，必将导致准确性大打折扣，在以后的月审、年审中必将导致额外的工作量。一般在审计的过程中，当数据的错误率达到一定程度后，需要重新梳理全部数据，以确保最终的准确和完整。

CMDB

CMDB总的来说分为：产品线、资产管理、供应商管理三个部分。

总的思路是：通过产品线管理IT资产，通过IT资产信息管理硬件或服务提供者，供应商管理。

1.产品线

产品线是指整个公司所有IT系统、产品按照属性进行归类划分。这有一个前提，就是梳理整个公司的IT项目和IT服务。这里项目也可以理解为每一套IT系统，例如OA、CRM、订单系统、支付系统等等。

IT服务主要是指：应用服务（Tomcat、WebLogic、数据库服务等），基础IT服务如Nginx、Varnish、Redis等。通过项目和服务两个维度来管理IT资产，尤其是虚拟机。因为一般系统和服务都是部署在虚拟机上，虚拟机的宿主机则是一台台物理主机。

产品线的划分一般除了根据业务分类划分几个大的产品线外，还需要划分一些基础产品线，如：信息安全产品线，主要管理信息安全、网络安全等系统和设备等;基础服务产品线，如Nginx反向代理大部分系统，Varnish缓存Web静态资源等。

在这里单独说一下产品线和项目包括的服务必须制定运维优先级等级。运维等级的制定不能简单定义为多少级，而应该是为每一套系统进行运维优先级打分，分值不能一样。这样保证在大面积故障的时候，可以根据优先级解决问题。

2.资产管理

资产管理主要有以下几个方面。

首先是比较大的机房管理。有的企业可能会有多个机房，每个机房的基础信息，如带宽、位置、值班电话等都需要加以整理存储用来管理机房信息。机房中的机架、机柜、交换机、路由器等硬件信息，机房的空调、UPS电源、环境监测系统等都属于机房管理的范畴。

安全设备管理。安全设备管理这里主要包含防火墙、IPS、WAF、VPN等网络设施。企业信息安全非常重要，在运维管理中也把安全作为一个单独的模块进行管理。通过购买安全硬件设备和安全服务，不断学习和研究，从而保护好企业数据信息。

服务器管理。这里假定企业实现了虚拟化，大部分系统和服务都部署在虚拟机，而虚拟机是部署在物理机上。服务器管理分物理机和虚拟机分开管理，同时又密切关联。虚拟机在哪一台或几台物理机需记录清楚。

根据产品线中定义的运维优先度等级，在资产管理中的每一个节点标注上相应的等级分值，以便出现大规模故障，有选择、有重点、有顺序地逐一解决问题。

3.供应商管理

供应商管理主要是管理由第三方企业提供的IT系统或设备的服务信息。记录供应商的具体信息、值班电话、硬件备件库等信息。

以上几个模块单独管理，但是又密切相连。如产品线包含哪些项目，包含哪些服务，这些项目和服务部署在哪些虚拟机上，虚拟机又在哪一些物理机上，物理机分布在哪些机房和在机房中的具体位置，物理机在机房中的网络位置和网络架构如何，经过哪些安全设备等等。

反过来需要知道某一些机房有哪一些物理机，物理机位置，安全设备，以及安全设备与物理机的网络架构等，物理机上又有哪些虚拟机上部署了哪一些项目和服务等。系统和服务属于哪些供应商提供，供应商又提供了哪些系统、设备或服务器等。都要多维度进行管理。要求做到某一环节的故障，一查就知道所有受影响的系统和服务。CMDB中的信息相互交织，多维度查询和管理，构建出一张完整的总体架构图，通过总体架构图除了展现出各个部分的基础信息外，还描述了所有的依赖关系，做到坏一点而知全面。

日志

通过日志可以比较准确全面地知道系统或是设备的运行情况，可以返查问题产生的原因，还原问题发生的整个过程。通过日志也可以提前预测系统可能要发生的问题或是故障，如系统安全日志，如果网络攻击会在系统安全日志中有一定的体现。

1.系统日志

系统日志主要指的是操作系统的日志，主要在/var/log下的各种日志信息。包含系统操作日志、系统安全日志、定时任务日志等。系统日志是运维管理安全模块中审计的重要依据。一般默认的操作系统日志不能满足要求，需要对系统的参数进行修改，如为history命令加上时间戳、IP，并且长久保留历史等功能。并且对日志文件进行处理，不允许用户进行清空命令，只能append。

2.应用日志

应用日志主要记录应用服务的健康运行情况以及业务操作的具体日志两部分。应用监控运行情况反应应用服务的健康状态，如果应用占用CPU或是内存过高或是忽高忽低不定，都可以通过分析应用日志结合业务操作日志得出结论。业务操作日志可以为业务审计提供主要依据。有一些系统喜欢把业务操作日志写到数据库中，这个也是需要注意的。不过不管在哪个地方，要求是不可缺少的，它为以后业务审计和问题返查提供依据。

3.数据库日志

数据库日志主要反馈数据库的运行情况。通过监控和管理数据库的日志，及时了解数据库的运行情况，遇到问题及时解决等。可以通过数据库日志结合数据库系统自带的数据库如Oracle的系统视图v$开头，MySQL的performance_schema等。虽然数据库的一些信息不是存在日志中而是在数据库里面，但是也可以作为数据库日志的一部分进行管理和监控，已便我们及时知道数据库的监控状况，从而预防可能出现的问题。

4.设备日志

设备日志一般是一个比较容易忽略的地方，但设备日志往往可以反映设备的运行情况。交换机故障，防火墙故障等设备故障都可能引起大面积的系统和服务故障。所以设备日志一定要收集，分析和监控预警。常用的设备日志有交换机日志、防火墙日志、网络安全设备日志等。

在CMDB中梳理的IT基础设施的基础上，对日志进行分类收集、管理、分析和监控，配着监控管理模块的系统，就已经可以达到多方位监控IT系统，保障IT系统的安全稳定。

DB

由于数据和数据库的重要性，在基础数据中，数据库作为单独的模块存在，根据环境划分为：生产数据库、测试数据库、开发数据库。严格区分三种环境的数据库，避免测试数据到生产环境，生产数据到测试环境等。另外数据库中数据也为业务监控提供数据依据。通过查询数据库中的数据，依据业务逻辑进行判断是否有错误或是遗漏的数据。

知识库

知识库在整个运维管理中是一个辅助功能，主要为运维提供事件管理、问题管理。很多朋友可能会疑惑为什么把事件库和问题库放在知识库这里，这些不是应该在CMDB中吗？这里稍微解释一下，其实本人也并不太清楚这种办法是否可行。在CMDB模块中更多是偏向IT资产管理，为以后的运维操作提供运维范围和运维目标。而事件（主要指运维过程中遇到的所有的运维事件）和问题（需要进行变更发布才能解决的事件升级）更多是在IT资产之上，是解决IT资产的过程中遇到的事件和问题。如果把CMDB作为IT运维的基础管理对象和范围目标的话，事件和问题应该单独出来。也许在后面的运维管理中，逐渐强化CMDB的功能，会把事件库和问题库回归到CMDB模块中。

知识库中还包含经典案例库，主要是解决一些常遇故障、经典问题的解决方法的整理和归档。

解决方案库只要是一些常用的或是探索中的解决方案，例如：Nginx+Tomcat+Redis部署方案，FastDFS分布式文件服务器方案等。

文档库主要用来存储运维管理过程中执行的运维标准和规范以及运维的流程规范，常用的一些规范举例：

文档库也包括一些企业或是部门的规章制度，与供应商的合同条文等。主要是涉及到IT系统文档的一个存放和查阅的地方。

运维标准和运维流程的文档一定是必不可少的。因为运维自动化的前提就是运维的标准化和流程化。如果没有明确的标准和规范的流程，运维自动化就只能一直停留在测试环境的假想空间中。

基础数据在整个运维管理中起到基础、奠基的重要作用，也是做运维管理平台的第一步和以后每一步的重要依据。一定要舍得投入时间、人力等来建立起完整、准确、实时的基础数据。打好地基，以后运维的每一步都将有条不紊地循序渐进，终将建设成属于运维的高楼大厦。

好了，文章到此结束，希望可以帮助到大家。