导读 提高运维意识。从下到上,从上到下的工作都要做,对上运维工作的价值和含金量可以得到认可,对下我们的工作能够提高效率解放自己。比如对于运维开发,我可以配合和协调,有技术困难可以解决,但是我不会追着别人去学习某些技术,因为这种事情会变味,运维意识里有这个,那么这个事情的意义就大不同。

运维工作中只要牵扯到运维开发,要去推动这件事情势必会有几类问题需要解决:

提高运维意识。从下到上,从上到下的工作都要做,对上运维工作的价值和含金量可以得到认可,对下我们的工作能够提高效率解放自己。比如对于运维开发,我可以配合和协调,有技术困难可以解决,但是我不会追着别人去学习某些技术,因为这种事情会变味,运维意识里有这个,那么这个事情的意义就大不同。

要有明确的运维目标。这里说是明确,光有规划不行,要有明确的运维目标,这个目标换个角度来看就是我们工作的痛点,解决了工作的痛点才是对我们自身意识的提升,这样也能解释实现运维目标的意义。

要有明确的时间窗口。有了目标,需要我们安排指定的时间窗口来做,如果没有时间范围,那么事情的进度和质量就难以追溯和保证。

我在这个事情上栽了很多的跟头,而且会发现事情变得越来越不可控。就好比我的期望是6,达到的结果是2,反差越大,发现改进的空间很大,以至于我会陷入一个死循环,我会想出很多的改进方法和建议,但是这些方法和建议就会抽象成为一系列的改进任务,这些任务涉及前端,后端和设计,于是乎,每一个点我都需要确认,沟通,落实,然后事情的进度就慢下来了,对待运维平台,要有「疯狗」一样的执行效率,我还记得这句话,有时候都会反问我这么坚持做这个事情,到底为了什么,对我们有什么好处,甩甩手放弃算是轻松了,就这这句话支撑了我:当你想要放弃的时候,想想当初为什么要开始。

我们来切入正题,即一个“悲剧”的部署安装场景,到底是不是悲剧,碰到了那些问题,如何来解决,当时是怎么纠结的,可以听听我的想法。

先来说一下实例部署的场景。

假设下面就是一个初步的安装部署页面。

要实现这个功能有一些目标能够达到。比如我们目前能够实现页面调用脚本内容,我们来看看有哪些需要注意的地方,或者容易让人纠结的地方。

首先这个需求是否符合预期,可能不是很好理解,比如我们的需求是部署一套数据库软件,那么内核参数需不需要调整,系统参数要不要初始化统一配置,数据库额外的插件是否需要安装,备份是不是要配置,监控是不是要部署,元数据是不是要自动生成。还有一点,这个环境是不是已经有实例,如果有,那么/etc/my.cnf的默认配置就需要重新调整了,这样一来,这个看似简单的页面就不满足需求了,于是我们扩展之后做收敛。上面的功能都是基础需求,我们都需要考虑,但是不是所有细节都需要统一执行,比如内核参数优化可能初始化执行一次就可以了。所以我们需要对脚本化的工作做到细化,能够实现模块化的功能,这样就牵扯到一些逻辑的改动和优化。

当然从前端来说,一个难点就是日志的执行结果回传,能够基本达到刷新的效果。这个需求对很多运维来说,是比较难实现的。所以可以抽象为两个难点,一个是进度的显示,一个是日志的显示,其中日志的显示是重中之重。

看起来脚本化的工作差不多了,假设我们花了一些功夫做了定制和改动。那么接下来的事情就是脚本的执行了。还是要引用之前画的一张图。

比如我们要做环境的部署,那么执行路径可能是ops(运维平台)->CM(中控)->DB Server(服务器),或者是ops(运维平台)->DB Server(服务器),比如从标准化的角度来说 ops(运维平台)->CM(中控)->DB Server(服务器)是一个更合适的路径,那么脚本从OPS端触发,怎么达到DB Server端,因为中间需要有一个中转的流程,可以使用paramiko,ansible或者salt来完成,但是怎么无缝衔接起来就是一个难点,如果从接入管理的角度来说,可能可以抽象成为接口。看起来就是一个命令的事情,但是衔接起来确实是个麻烦。

然后来说一下数据查询的需求,其实这是一个很基础的需求。能够通过界面显示出数据来,满足一定的查询需求。但是有面临一堆的问题和不确定的需求。

比如我要实现数据查询,执行路径按照上面的图来看可能就是ops->CM->Server->DB,这个路径很长,或者是ops->CM->DB,如果选中是这个路径的话,如何开通权限就是个难题,我们假设有100台MySQL服务器,写一个脚本批量传送脚本到这100台服务器上,在数据库上创建1个用户,然后开通防火墙权限,看起来是很简单的一件事情,但是你会发现这个方式是错误的,比如里面有主从复制,你如果在从库执行了,主从复制很可能就会断开了,那样你就需要处理更多的复制问题,所以有100台服务器,你需要做一层提取,那就是找出哪些是主库,哪些是从库,但是很快就会发现判断主从还是个麻烦,因为MySQL层面就没有一个明确的标识master还是slave,而是需要间接得到。从主库上直接得到slave的信息不够直观,如果我一台一台确认,又觉得这种方式太low,真要完美的衔接起来发现会碰到一层又一层的问题,最尴尬的还是元数据不够准确,忙活一场,发现还是缺了一些数据。

当然可以纠结,也可以做改进,我们就可以明确的梳理边界,比如我们解决的是运维部署,那么我们就聚焦在这个地方,看看需要投入多少的人力和时间成本来解决。一个一个初步解决,能够快速迭代出来一些效果。反之就会发现是一点一点的迭代,但是都在完善,都没有成型的结果。

原文来自:http://server.51cto.com/ManageDC-571757.htm

本文地址:https://www.linuxprobe.com/operation-maintenance.html编辑:王毅,审核员:逄增宝

本文原创地址:https://www.linuxprobe.com/operation-maintenance.html编辑:王毅,审核员:暂无