ITPub博客

对待运维平台,要有「疯狗」一样的执行效率

原创 作者:jeanron100 时间:2018-04-11 09:35:54 390 0 删除 编辑

从去年发起里程碑来做自动化平台的事情到现在,已经几个月过去了。在这段时间里,其实我的心态是很焦灼的。

其实从很多维度来说,做运维平台的事情,从不明朗的需求和定位开始,很难有说服力。

如果用业务价值的一把标尺来衡量,那基本没戏;如果从做这件事情的难易程度来说,很多人算是从入门到放弃;当然还可以有很多维度。

最直接的一个痛点就是纯运维的开发技能不够好,纯开发的运维背景不够,所以两者能够结合起来,算是一种互补,当然做这个事情要投入的精力,还有毅力,你们自己尝试去推动体验一下,还是有收获的。

如果说这个事情的转变,我觉得虽然慢了很多拍,好歹这个事情算是提上日程了,但是落地的情况虽然差强人意,相比于去年底的时候,已经有了很大转变。这里面要做一些工作,从上到下,从下到上。从上到下,就是从一个更高的角度来和领导谈这个事情,从意念上达成一个共识,在这个地方我觉得我犯了一个错误,那就是如果已经有很多显而易见的事实,我觉得就不需要去说服别人,说服领导了,但是恰恰在这个点上,我们还是要做一些推动力的,这个时候很可能就是信息不对称,我们认为重要,领导认为一般,结果导致了结果有了较大的偏差。

另外从下到上,其实就是事情怎么去做,算是一些具体的分工和安排了,最纠结的莫过于没人,没技术了。其实这个还不算最糟糕的,最糟糕的是大家认为这个事情还不够重要,先保持现状吧。这种时候我很焦躁,我们的价值在哪里。

原来是感觉有很多事情可以做,但是必要性不大,结果有了一些阶段性的讨论之后,基于各种因素吧,发现事情一旦有了转机,你就会发现有很多的事情可以做,值得做了。

所以车轮子转了起来,我觉得好歹就是进步了。

以上的可以理解是牢骚,也可以理解是一个苦逼的心路历程。对我来说,抱怨不够,要做解法,所以前期我的投入会很多,以至于我感觉我现在就是做运维开发的了。

运维开发以后怎么走,我觉得我们可以看看Google的路,运维开发一个很不错的方向:SRE

SRE的特质有两条:

1.对重复性,手工性的操作有天然的排斥感

2.有足够的技术能力快速开发出软件系统以替代手工操作

SRE的经验法则

“SRE团队必须将50%的精力花在真实的开发工作上”。

所以开发了几个月,平台搭建起来了,有了初步的系统功能,有了元数据的基本功能,做了一些基本功能的调试和使用,我发现事情开始有了变化。

我画个图来表达一下。

这可能是我眼中的运维平台,无论是数据库运维平台还是系统运维平台,大概念就是运维平台,我希望有树干(好的架构),绿叶(支持丰富的功能),果实(有产品的亮点)

结果做着做着发现好像和自己预期的不一样了。

发现是这样的情况,其实事实上比这个还要糟糕。

这是什么,有时候自己都犯嘀咕。对我来说,把以前的工作全盘否定也不太公平,所以,我决定做需求和功能的收敛。期望达到的这样的一个效果。

这是不是树,首先可以肯定说是,抓住几个亮点,有了好的设计,那么后续的工作要衔接起来就是一个迭代的过程。

所以我希望的结果是这样的,那些果子可能是一些目前要解决的痛点。

所以在我的脑海里闪出了一句话,可能听起来不大好,我决定叫它是“疯狗一般的执行速度”。

有了前面的思考之后,我发现其实我虽然实现了一些基本功能,但是面对复杂的运维场景的时候还是有些乏力。

我又画了一个图,这次是个技术图。通过这个图我可以做很多的总结和思考。

假设通过左侧的运维机器要访问数据库,有很多中路径可做。

中间的是中控机器,也可以理解是代理服务器,右上角的是DB服务器,右下角的是DB服务器中的数据库。

比如通过运维机器来访问数据库,我们有很多的路径可选。

如果面对的场景不确定如何能够做到一种灵活的插件方式呢。

我计划分成几个维度,运维机器-Ops,中控-CM,DB服务器-host,DB实例-DB

那样下来就可以拆分,比如ops_to_cm

cm_to_host,host_to_db,ops_to_db,ops_to_host等等

对于每一个路径或者分支我们可以使用多种技术来实现,到时候串联起来即可,比如Ops_to_db如果使用程序脚本逻辑的方式,那么sql的方式就满足不了了,我们可以使用ops_to_host,host_to_db,或者加一层中控,ops_to_cm,cm_db来实现,

当然方法有很多种,我们来适配即可。

所以这个地方如果抽象出来,然后单独实现,我觉得能够解决一些通用的问题,所以在这里我把它做概念提取,这就是一个工具管理的功能。

上面的方式其实主要侧重点是接入管理,如果我们做针对性的管理,比如系统管理,数据库管理,其实就可以做很多的细分了,这样一来,我们拼接出的工具就好比是一个乐高玩具,堆叠出很多的玩法来。

我设计的一个初步的demo是下面这样的。

说到这里一定要提一下原型设计的重要性,这个也是我走过的弯路之一。

这是我最近整理的一个运维开发的流程图。原型设计还是很重要的,如果原型设计没想明白就开始很具体的数据库设计,那么后面要返工的可能会非常高。

这个图建议大家好好理解一下,可能我的理解有偏差,希望你能够提出宝贵的建议来。

所以把之前的工作如果再做一层高度的提取,我觉得要做的应该会分为两大部分,一部分是通用平台,另一类是业务运维支持。

所以通用模块我的想法应该是能够普世很多业务场景,我们经过讨论,目前补充的会是下面的一些通用模块。

而从基础运维来说,比如数据库运维来说,就是一些具体的业务场景了,比如:

  1. 数据库一键部署

  2. 数据库备份模块

  3. 数据库恢复模块

  4. 一键搭建从库模块

  5. 服务开通模块

基础打牢了,后面可以做高可用,分布式,SQL审核等等。

这些工作有些已经做差不多了,有些还没有开始,所以要继续我开始说过的,我们需要“疯狗一般的执行效率”

所以这个里程碑里我计划要实现的就是这些基础的事情。如果这个时候我强调这是一个很重要的转折点,大家可能就理解了。

通用模块中我比较喜欢的是任务调度,我觉得如果做好,能做太多的事情了,甚至会激发出一些很亮点的功能,当然我现在想的很好,手底下不停使唤,所以我还是会做好规划,看看能做到什么程度。

这个月过去,小半年就过去了,如果还是在打口号,在提思想,我觉得就太失败了。有句话说得好,快就是慢,慢就是快,你太慢了所以觉得哪里都快,你太快了觉得哪里都慢,可能就是这个道理吧。我很喜欢做事情主动能拼的同学,我不喜欢追着别人做事情,要达到初步的预期,我觉得有两点分享下,一个是做事情需要有明确的目标和计划,比如这个月我要实现基础的功能,那么我来拆分,本周,下周,下下周要做的事情。第二就是deadline,做事情没有截止日期,结果简直没法提。

以上就是我的一些基本想法,很多事情听起来确实泛泛,需要不断的细化和梳理,要不时间花了,事情没成,我觉得太不值了。

我的分享就到这里。谢谢大家。

请登录后发表评论 登录
全部评论 0

注册时间:2012-05-14

  • 博文量
    1499
  • 访问量
    14153484