标签：运维 人力 mysql 类型 客户端 增强 数据 企业客户 值班
需求背景：
随着业务的增长、对运维效率和质量的要求不断提高，对自动化运维体系的需求也不断增强。
目前笔者服务的很多中大型企业客户，运维其实还停留在“刀耕火种”的原始状态。
这里所说的“刀”和“火”就是运维人员的远程客户端，例如 xshell 和Windows 远程桌面。
这种工作模式有很多局限性，
比如服务器、数据库、中间件等的安装、初始化，应用软件部署、服务发布和监控都是通过手动方式来完成的。
这就需要运维人员登录到服务器上，一台一台去管理和维护。
如果有个几十上百台，累就累死人了。
笔者曾运维过超过4000千台服务器，团队二十多个人，仔细想想这活靠人力能干吗？
另外人工操作方式过于依赖运维人员的执行顺序和操作步骤，稍有不慎即可能导致生产事故，即便是变更前double check也很难保证不出事故。
常在河边走哪有不湿鞋。
这时候运维人员开始探索使用使用脚本和批量管理工具。
这种方式确实提升了效率和质量，但是不具有普适性。
每个运维人员都有自己的解决问题的风格，不同的人员之间存在巨大差异，那么不同的人开发这些脚本的版本管理就是一个挑战。
因此，构建自动化运维体系成了唯一的选择。
那么如何建设自动化运维体系呢？本文研究分为三个大的方面：
为什么要建设一个自动化运维体系。
肯定是运维过程中遇到的一些挑战。
第一个是变更的需求。
它表现为三个方面:
第二个是运维环境方面，主要表现为服务器数量多、数据库类型多。我们的客户可以自由选择使用哪种数据库，分别对应不同的环境。
第三是人的因素。
在建设自动化运维体系过程中，有一个比较重要的考虑点是人的因素。
正是因为每个运维人员的能力不一样，技术水平参差不齐，甚至是运维习惯和工具也不一样。
导致我们必须要创建一套规范的自动化运维体系，来提升工作效率。
下面我们来看一下每个模块是如何设计和工作的。
安装数据库是比较繁琐但数据又多的工作之一。
操作系统多，但是人少，可用时间也比较少，自动化安装省时省力。整个自动化流程采用通用的框架，主要是针对linux下的Oracle安装和MySQL安装。
交付用户之前，会进行基本的安全设置，这在一定程度上提高了安全性，也减少了需要人工做的一些操作。
当服务器由自动化安装完数据库以后，就会被自动化运维平台接管。
自动化运维平台是运维人员的操作平台，它主要解决安全、高效、快速等因数量特别多而带来的管理问题。
在设计的过程中要考虑了以下几个因素：把整个运维系统的操作界面设计成基于堡垒机的架构。
运维工程师无论何时何地都可以登录管理系统进行运维操作，这样的话就比较方便，由SecureCRT对被操作的机器发布指令。
充分利用现有协议和工具。这个平台的特点是所有的系统使用SSH管理，而不是自己开发一些Agent，这也体现了自动化运维的观点。
由于我们的客户系统比较多，业务也比较多，怎样设计一套系统去巡检它们的运行情况呢？
我们采用了两种方式：自我开发的中控系统和第三方管理平台先看自己开发的中控系统：
单独使用一台服务器巡检其他的数据库节点，脚本可以选用shell或者Python。
设定遍历时间间隔，遇到故障情况可以采用打电话或者发短信的方式及时通知运维人员。
第二是把所有的数据库节点纳管到第三方监控平台。
系统并不用永远都稳定运行，性能问题是无法逃避的问题。性能分析系统是重中之重。
这里笔者单独再写一篇文章。
通常客户的系统都是7*24小时运行的，这就要求必须有预警监控。
预警监控系统+值班人员是标准配置。
两地三中心+DG+NBU
笔者将自动化运维体系的建设目标总结为四个词。
总结
笔者目前也在从数据库的架构、优化和故障处理慢慢转型做自动化运维体系。
对过去进行总结，我觉得有3个方面可以供大家参考。
第一是循序渐进的原则：
聚焦当前的问题，把当前的问题处理好，后面的问题也就迎刃而解。
如果一开始设计的系统很庞大、功能特别丰富，会导致一些无法控制的局面。但是如果一开始的目标是解决一些特定的问题，有针对性，那么推进起来也会比较简单。在笔者参与的自动化运维体系建设过程中，我们的初始目标是构建的是一个基础的变更批量操作平台，先把一部分需要重复执行的工作搬到平台上来。
再依据运维的需求丰富这个操作平台的功能和提升效率，最后把周边的系统打通，相互对接，形成完整的自动化运维体系。第二是考虑可扩展性：
设计系统的时候，功能或者设计方面可能不用考虑那么多，但是要考虑当服务器数量发生比较大的扩张时，系统是否还能支撑。第三是以实用为目的：
使用不方便，运维人员第一个就放弃了，何谈推广？
更多内容请关注微信公众号：数据与人
标签：运维 人力 mysql 类型 客户端 增强 数据 企业客户 值班
原文地址：https://www.cnblogs.com/sunkang-dba/p/12657844.html
