从“悲剧”的几个运维场景谈谈运维开发的痛点

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

  1. 提高运维意识。从下到上,从上到下的工作都要做,对上运维工作的价值和含金量可以得到认可,对下我们的工作能够提高效率解放自己。比如对于运维开发,我可以配合和协调,有技术困难可以解决,但是我不会追着别人去学习某些技术,因为这种事情会变味,运维意识里有这个,那么这个事情的意义就大不同。
  2. 要有明确的运维目标。这里说是明确,光有规划不行,要有明确的运维目标,这个目标换个角度来看就是我们工作的痛点,解决了工作的痛点才是对我们自身意识的提升,这样也能解释实现运维目标的意义。
  3. 要有明确的时间窗口。有了目标,需要我们安排指定的时间窗口来做,如果没有时间范围,那么事情的进度和质量就难以追溯和保证。

我在这个事情上栽了很多的跟头,而且会发现事情变得越来越不可控。就好比我的期望是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,真要完美的衔接起来发现会碰到一层又一层的问题,最尴尬的还是元数据不够准确,忙活一场,发现还是缺了一些数据。

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

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2018-04-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏软件测试经验与教训

张老师聊面试

1、现在有个程序,发现在Windows上运行得很慢,怎么判别是程序存在问题还是软硬件系统存在问题?

943
来自专栏CSDN技术头条

如何为微服务选择数据库

作者 | Jeff Carpenter, InfoWorld 翻译 | Jackyrong 你的微服务架构需要多种数据模型。你是应该选择混合持久化呢还是多模型数...

24110
来自专栏云计算D1net

公有云提供商挑选准则

当涉及到选择一个公有云供应商时,成本常常是第一个考虑的因素。但其他的因素,例如虚拟机迁移,存储和自动扩展等,也都应该考虑在内。 在企业转移到公有云或混合云时,不...

3967
来自专栏软件成本造价评估

软件造价之:浅析快速功能点方法度量软件的规则及过程

快速功能点方法是一种软件规模度量方法。该方法适用于软件项目早期、中期、后期等各个阶段的规模估算或测量。   采用优化后的功能点方法——快速功能点方法进...

1240
来自专栏Debian社区

使用 Go 语言的三个原因

几个星期前,我一个朋友问我:“为什么要关心 Go 语言”? 因为他们知道我热衷于 Go 语言,但他们想知道为什么我认为 其他人 也应该关心。本文包含三个我认为 ...

1543
来自专栏编程

程序员提高编程能力万无一失的办法

那就是去读别人写的代码。读那些你常用的库、编程框架的源代码,读那些你景仰的大牛的源代码,读代码里的测试(测试本身就是一种有效的文档);读代码、改代码、运行代码。...

2719
来自专栏杨建荣的学习笔记

运维平台中的业务树初版设计

资源服务的一个基本单元是服务器,可以是虚拟机,物理机,也可以是docker等。这是最底层的资源服务。

1793
来自专栏个人分享

大数据理论体系总结--数据仓库管理与全链路数据体系

  就这样,大数据领域蓬勃发展了好几年,有很多伙伴执迷于技术,成为了分布式计算与存储的领域专家。也有很多伙伴执迷于数据,成为了行业的数据研发专家。当然还有很多小...

3444
来自专栏WeTest质量开放平台团队的专栏

如何用UPA优化性能?先读懂这份报告!

原文链接:http://wetest.qq.com/lab/view/375.html

43014
来自专栏ThoughtWorks

性能测试问题与思考 | 洞见

性能测试对于大部分测试人员都是一个神秘地带,因为在很多公司,性能测试都是由一个性能测试团队来做,所以普通测试人员没有机会接触到真实的性能测试,因而很难学习到很多...

1092

扫码关注云+社区

领取腾讯云代金券