运维开发流程梳理和思考

刚刚在运维分享群里分享了主题《运维开发流程梳理和思考》,希望有所帮助。

记得之前梳理过一个运维开发流程,也做了一些实践,从我的认识和理解来看,其实这更适合一个团队内的协作。

而早期的时候,整个项目的构建和建设主要是我一个人来做,我贯穿了整个项目的开始,不能说是从0开始,也算是从0到1的开始吧。

首先来说下一个基本的心路历程。通过这个可能对你也有一些借鉴和参考。

做自动化运维不是拍脑袋想的,而是这个是大势所趋,如果还在手工化,脚本化的阶段,其实整个运维的路基本都能看到头了。而开始提出来到要做的时候,其实也算是受到了蛮多的阻力。

做一件事情基本上是从上要支持,从下要配合,细节就不说了,总之,从上从下都很难,最后发现有一个目标,但是没法控制过程,所以这是一个随机结果。

这个事情要做成的概率就太低了,所以早期的时候没有这方面的技术就学,没有哪方面的内容就补,整个过程的迭代会花费一些时间,一方面见效难,很多人都会怀疑这个事情能不能做,如果从上没有明确的资源支持,你会发现就跟一个半创业状态差不多。

从下来说,其实主要是运维意识的提高,如果某个事情今天花30分钟能做完,那么改用自动化运维用了5分钟,对很多人来说确实是提高的,但是这个提高的代价对他们来说相对会比较高,所以很多人的想法就是差不多就行了,我也理解这种想法。

除了意识,还有一点就是技术沉淀方面,要提升一个团队的整体技术能力不是一个人能说了算,也能直接改变的。我最担心的情况就是说出一个想法,其实已经很成熟了,但是我需要做的事情是需要花很多的时间去说服别人,或者有时候别人对你的想法会有一些不大理解。碰到这种情况就两难了,所以有的时候我确实容易上火,事情如果明显达不到我的预期,我就会更加的急躁。有时候都在想到底这么坚持图个什么。

当然同事相对都是很支持配合的,能够在事务性工作之外给予我这么多的配合其实想想已经很不错了。我觉得一定是某些环节上有些问题或者不够清晰,导致事情很难推动下去。

第一个是就是事情的形式,多多少少还是得有仪式感和角色带入感,所以一种比较好的方式就是成立项目。做项目要写文档,这个之前觉得会浪费时间,其实细细想来,也是一种工作内容的体现。

第二个就是运维开发路程的梳理,也是本次分享的主要内容了。

前前后后做了很多磨合,最后也是捡了几个业务场景,每个场景逐个击破,比如部署安装,比如服务开通,每一个功能的标准就是能够支持线上业务,界面丑点没关系,多点击几下鼠标也没关系,关键流程要对,比如权限的开通,不能做侵入性的破坏,不能多也不能漏。

所以做了一些功能,沉淀下一些思路之后,我觉得运维开发的流程可能要分成几个环节,如果从大了来说,就是前后端开发。

当然这里的后端开发远比我们理解的要复杂的多。我来细掰扯下。

第一个阶段就是业务需求的提炼,比如我们现在需要解决的需求是什么,可能一二三四有好多个,但是我们可以按照优先级来排个顺序,哪个是痛点需要优先解决,这个重要性不用再强调了。

第二个就是梳理脚本,脚本的部分可能和大家的理解有很大偏差,每个运维其实多多少少都会沉淀下来不少的脚本,少则十多个,多则上百个或者是写个工具之类的。

所以有这么多的脚本或者工具,其实我们可以在这个基础上做提炼,满足当前需求的脚本有哪些,然后不同的方向上可能都会有一些相关的,接下来要做的而就是脚本的标准化,这个是脚本梳理的一个核心点。

比如运维同学A有10个脚本,有的是shell,有的是Python,没关系,都可以考虑接入,但是我们要指定一个接入的标准,这里我们就要组哦一个接入管理的工作,比如我们统一设置一个目录结构,os,mysql,redis。。。。 然后按照功能在每个目录下放入相应的脚本,结构的部分还可以细化。

然后我们需要制定脚本的标准,比如参数的使用说明,哪些是必须的,参数的含义,还有调用方式,脚本的返回结果等,这些都要明确,要不从开始就是一团糟。比如其中的一个标准就是脚本在本地是能够正常执行的,能够输出执行结果的标识的。

如果做了这些工作,后续去接入脚本其实就是一个标准化的工作了,其实放长远来说,其实这个过程单纯的运维也能够参与到整个运维开发工作中了,我们可以不断的merge脚本,尽可能做裁剪和边界划分,最重要的一点,这个脚本的接入管理需要有一个人来专门负责,这样入口是统一的,改进方式后续再细说。

第三步是REST接口和API化,我们的脚本可以使用很多种方式调用,比如salt,比如ansible,比如paramiko等等,这些都是接入方式而已。其实对于执行结果来说是没有差别的。

那么我们可以抽象成REST的接口服务,直接出发这个REST的接口就能够完成相应的指定任务。比如一个具体的例子,我们使用Django的rest_framework来做REST接口服务,可以很方便的使用认证体系。

这里的REST接口这是一个调用方式,不是我们说的重点,我这里说的是REST接口和REST API,这里的重点其实是API的环节。

比如我们查看防火墙的操作,我们可以输入一些基本参数,就得到一个防火墙信息列表,这个逻辑在Django中是需要在View层中来写的,其实我们可以上移到API层来做。

这样一来运维同学就可以直接调用REST接口来做调试了,是否满足需求其实通过这种测试就可以很清晰的测试。

到了这里可能是很多人理解的后端开发了。如果配合上前端,基本就是一个前后端分离的开发过程了,其实我要补充的是,我们可以做的更灵活,全面一些。

我们在这两个层之间做一些补充。Django的前端其实也还可以用啊,或者自己写也可以,但是我们的使用基础就是纯粹的API,这样一来,view层的逻辑上移,只负责分发和跳转,就能够很方便的和当前的前端方案整合起来。

如果要做后续的前后端分离这就是一种相对可行的迭代方案,如果再深入一步,其实我们的View层已经只负责最简单的分发任务了,那么这个工作其实我们可以继续抽象,比如把跳转的工作干脆直接放到数据配置中得了,通过前端的配置页面来完成跳转的配合,这样我们就可以在线维护这种看似负责的关系了。

整个完成的图其实通过下面的描述就会比较清晰了,我画个图先。整个流程图就会是这样

如果划分下边界,其实就是这样。

中间的部分就是后端的开发,而右侧的部分是前端的部分。

这样做的好处是只需要少数的几个人就可以负责某一个方向,而且能够保持持续交付的质量。比如交付的脚本,有了参数的说明和脚本规范,那么接入到API的时候会轻松许多,而在接入前端之前,其实后端就可以开始测试任务了。

相对原来所说的前后端分离,我们加入了中间的逻辑分发接入,可以很快的在本地构建出一个前端的方案,至于独立的前端方案我们完全可以持续的构建。

所以整个的过程就是一个异步开发,不需要串行强依赖。

而且还有一个好处就是能够充分的融合运维和运维开发。其实在这个过程中运维同学就可以参与很多的角色了。

纯粹的前后端分离其实也有很多的弊端,一个是沟通成本。在调试的时候可能因为后端API或者逻辑,或者是前端的支持情况,基本不大可能一口气调通的。反反复复可能会做很多次。

而且前后端分离的一个主要出发点其实是对于代码的复制所带来的维护代价,比如有ios版本,有android版本还有pc版本,如果按照原来的方式,就是快速复制代码,后期引入维护的时候成本巨大,这算是前后端分离的一个主要出发点。

相比到了我们很多工作环境中,前后端架构要分离,但是前后端的技术不一定完全分离,当然专业的前端可以做高级的前端功能,后端还是需要掌握基本的前端能力,而高级的前端也需要掌握一些后端的技能。

后续如何改进,其实最近把基础运维的事情搞定,不如部署,服务开通,如果我能够全部通过界面来搞定,完全不需要登录服务器,那么这就是一个初步的里程碑,然后后续就是简化流程,不断的迭代改进了,比如很多抽象出的任务可以组装成一个流程,这就又上升了一个台阶。

可以打个比方,你去菜市场买菜,顺路去买个早点吃,如果你已经吃过早点了,那么去买菜的时候就不用那么赶了。这里的吃早点就是我们需要先解放基础运维的工作,这个工作做好了,我们再去想其他的事情。

要不忙忙碌碌,自己的事情都解决不掉,工作的价值也不高,慢慢就会陷入一个恶性循环。

问答:

防火墙还是基于操作系统的iptables? 添加规则主要就是调用命令去添加? 防火墙这个主要有什么应用场景?

答:

防火墙这个比较有意思,最近是做了改进和提炼。把防火墙信息做成属性信息。可以标识几个维度(操作人,发起方,操作时间),读iptables信息的时候做成跟读数据库表类似的方式

类似这样

斑*^O^*竹:

最起码知道什么时候添加的 谁提的要求

答:

防火墙信息里的文本备注其实不靠谱,很不好参考。

时间戳和操作员可以做成隐式的,自动录入。就是先做加法再做减法。

斑*^O^*竹:

主要看写备注的时候靠谱不 手工填入的数据

答:

后续可以改进的话,比如根据开通时间排序。。。

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

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

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯云数据库(TencentDB)

Redis云端架构深入浅出

作者介绍:邹鹏,腾讯云数据库Redis产品负责人,多年数据库、网络安全研发经验。在网络、计算、存储、安全等领域有深入的研究和丰富的产品化经验。 在Redis、M...

9.9K15
来自专栏DevOps时代的专栏

无服务器化的微服务持续交付

前言 我在刚进入 ThoughtWorks 的时候就做微服务,当时不知道什么叫做微服务,只是我们通过一个小的技术应用替换原先的大应用的一个部分,当时只是做一个解...

4066
来自专栏Java架构师进阶

一个程序员对架构的认识

架构是一个系统的草图(逻辑+物理角度),它是有生命的,随着业务的变化会不断演进。没有完美的架构只有合适的架构。

1113
来自专栏技术杂文

微服务:真正的架构模式

微服务的相关知识和它的神秘令我着迷。概念上的微服务就像是现代最有趣的流行架构之一。它足够功能强大,有着广泛的使用方法;也足够模糊,难以统一而论。

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

一分钟读懂兼容测试报告(一):概况篇

原文链接:https://wetest.qq.com/lab/view/425.html

1221
来自专栏知晓程序

这个程序员爸爸,专门做了款小程序,教会小孩认字 | 晓组织 #9

由于一次学校的网页比赛误入前端行业,现一直从事前端方面的工作。这次非常意外又惊喜的收到知晓程序(微信号 zxcx0101)的邀请,来说一说我的第一款小程序「看图...

1152
来自专栏BestSDK

产品经理与测试工程师的5点根本区别

相对设计和开发来说,测试工程师是产品经理接触较少的一类人群,因为测试人员往往也是躲在项目幕后,默默地奉献着自己,确保产品能够正常运行。产品测试是很重要的一个环节...

3284
来自专栏开源项目

新零售时代如何玩转微信商城 | 码云周刊第 74 期

3212
来自专栏互联网数据官iCDO

【经典文章】运营优化的秘密武器:重新认识热图的力量!

主编注:这篇文章获得业内很高的关注。是宋星老师的另一篇讲述如何优化网站页面尤其是着陆页的经典文章。 引言   之前发布的文章:《优化高跳出率着陆...

3364
来自专栏developerHaoz 的安卓之旅

如何有效报告 bug

这也是「技术支持」被视为一个可怕工作的原因。然而,并不是所有的 bug 报告都是让人不愉快的。我一直在没赚钱的时候维护开源软件,有时候会收到一些非常清晰的、有帮...

1172

扫码关注云+社区

领取腾讯云代金券