凡墙皆门:移动云自动化运维平台的破墙与进化之路

戴声 2017-12-26 10:03:15

文根据戴声老师在〖Gdevops 2017全球敏捷运维峰会广州站〗现场演讲内容整理而成。

 

(点击底部“阅读原文”获取戴声演讲完整PPT)

 

讲师介绍

戴声,中国移动“移动云”运维研发团队leader,Python开发高级工程师。目前负责移动云整体自动化运维架构设计及运维平台开发。在大规模OpenStack云环境的标准化、自动化运维、监控系统、DevOps工具链应用等方面有较丰富经验。

 

移动作为传统运营商,在实施自动化运维方面时还是遇到了颇多困难,今天就借这个机会跟大家分享一下“移动云”如何在一年多的时间里,实现从纯人工到自动化的运维转变。

 

运维:传统到自动化的一般路径

 
 

 

事实上,近几年接受了诸多运维大会的“洗脑”,对于一个运维团队的运维开发之路,我们比较遵从这样一个理念,即做自动化运维,一般是经历下面四个步骤:

 

 

  1. 标准化。包括整个环境、服务的标准化。进行标准化后,事实上整个环境已变成相对可控了。所有的厂家或者是不同的单位按照我们的这些规则来部署之后,很多的东西包括自动化都变成了可能,所以马上就进入了第二个阶段。

  2. 脚本化与工具应用。这时我们从人工运维往上跳了一个台阶,很多东西都变得可以用脚本或工具来实现,便慢慢开始积累更多的原子脚本。

  3. 平台化服务化。随着运维规模的不断扩大,这些脚本慢慢变得混乱和复杂,有些也变得不太适用某些场景,所以我们开始考虑如何把这些所有脚本及工具整合成一个平台,来实现我们的配置管理、资源服务,以及怎样把所有的运维动作场景化。

  4. 智能化。在上述三步的基础上,慢慢考虑如何利用长期积累下来的数据,推动整个平台往智能化方向发展。

 

这样的路径大家都比较认可,事实上,我们在完成了第一步的标准化之后开始尝试后续的步骤,这也是接下来演讲的主要内容:我将从工具化与脚本化的阶段开始,介绍我们一步步打造移动云自动化运维平台的若干经验。

 

4

Step4:场景化编排

 

执行时我们又发现了一个问题,其实它并没有真正解决很多实际落地的运维场景,比如说现在想要调用一个网络工具包的某个命令,执行完之后,再去调一个组件工具包的命令,然后我再把某一个文件发回来,再把结果发一个邮件等。因此我们开始实现下一步的功能——场景化的编排。

 

这个编排功能的作用是什么?事实上,光有了前面基础的能力和工具包是不够的,我们虽然可以利用这些工具包来帮助我们去管理一些资源或者做一些业务运维操作,但这些工具包如果只是每次至执行一步单步的的操作还不能实现一个完整的场景,还得再给它新增一些辅助性的单步的操作能力,再把这些能力编排起来。

 

比如说除了刚刚讲到的这种命令或脚本的批量执行外,我们还做了文件管理和一些场景的审核功能(例如,现在我要封堵一个客户虚拟机的IP,可能需要有网络管理跟主机的同事一起审核)。所以,假设我要新增一个应用,它可能是下面几个步骤编排起来:

 

  1. 审核通过

  2. 新增一个虚拟机

  3. 在这个虚拟机上推送一个中间件

  4. 在这个中间件上分发一个应用并启动

  5. 把虚拟机、中间件、应用在Zabbix监控起来

  6. 发送邮件通知,事情搞定了

 

这里面其实只做了一些单步的步骤,然后把这些单步的步骤做成了一个场景的编排,编排完了,如果这时变成了真正可以提供给所有人使用的一些小应用、小工具,那这个东西就非常好用了。

 

这里有一个背景要补充介绍下,我们的运维团队并不是什么事都包的,还有一个“服务台”的团队,他们比较擅长的不是技术,而是跟客户沟通,但他们有一个指标,就是对投诉的拦截率有多少,在他们的层面如果不能解决,再给我们运维同事派工单。事实上,我们可以把这些编排出来的小场景程序提供给服务台的同事。所以这时大家都比较爽,为什么呢?因为对二线运维同事来说,他没有工单要处理了,很多故障和投诉已经在服务台团队利用小场景程序解决了;而服务台这边也很爽,因为他们有拦截率的要求,靠这个运维同事提供的东西可以很快地提高他们的故障和投诉处理率(拦截率)。

 

当然,除了服务台以外,还有更多对资源有需求,或者需要对资源做操作的,是我们的研发,研发经常向我们的运维同事说:你给我一个虚拟机、给我一个数据库、给我配一条网络策略,或者我要看哪个状态信息。像这种事情,也能够通过这种编排小程序提供给他了。

 

 

那做这个东西有什么实现上的问题呢?最主要的问题是命令/脚本的批量执行,因为慢慢的,平台的使用量大起来了,像之前threading的多线程方式已不适用了,效率出现了较大问题。所以这时我们考虑使用了一个简单好用的分布式异步队列Celery,加上一套RabbitMQ,从而解决了并发量的问题。

 

第二个问题是文件管理。如果说用nfs的方法,IO性能可能不太行。我们想了一个办法,找了一个东西叫Minio。Minio可以实现AWS的S3的协议,而后端的存储它不管,可以用各种高可用方式去扩展,所以这也是一个可扩展的文件管理方式,是一种对象存储。

 

最后的问题是前端,我们改用了VUE.js。

 

全部做下来,我们发现对业务场景编排用得非常多,而对资源的管理场景则非常少,为什么?因为每一次组件的推送或者是我创建某一个虚拟机,我们做完了之后发现我的这些数据并没有存下来,只是帮你创建了资源,但并没有数据的维护。所以又绕回去刚刚那个问题了,我们是不是需要一个CMDB?或者说我这个资源管理服务,它其实并不完善,我是不是应该做一个比较完善的资源管理的服务来提供各种各样的资源?

 

<section 0px="" aria-describedby="tooltip411733" background-position:="" background-repeat:="" background-size:="" class="_135editor" data-color="rgb(14, 139, 215)" data-id="89434" data-original-title="" data-ratio="0.4139194139194139" data-tools="135编辑器" data-type="jpeg" data-w="1911" https:="" img="" mmbiz.qlogo.cn="" mmbiz_gif="" p="" section="" span="" src="http://dbaplus.cn/uploadfile/2017/1226/20171226100843389.jpg" strong="" style="margin: 0px; padding: 0px; width: 2.5em; height: 3em; color: rgb(255, 255, 255); font-size: 1em; line-height: 3em; display: inline-block; background-image: url(" tibrg3aoijtvkxob8sfwxnn0ydoaiwmejehqxygiyams8sbnzakwhzribwcj80tsia9c231sbfyvyicz3ettrzagcq="" title="" wx_fmt="gif" );"="">

6

Step6:配置信息库与配置自动化

 

还是回到资源配置管理这个问题,绕不开,必须做。后面我们做起来了,这里我们实现的CMDB跟最早传统意义上的ITIL中描述的CMDB有些不同,因为它并不是一个大而全的CMDB,里面并不包含资源服务功能,更多的是提供一个数据信息模型,以及这个模型的对外提供的数据服务。而对资源的管理则提到外面去,独立出来。

 

 

第二,我们有一个对配置管理额外的需求。这时我们正在推进整个“移动云”在各个业务部门和研发之间的DevOps流程。大家应该了解,在做DevOps时,自动化配置管理这个坎是绕不过去的,你必须要能够管住应用的配置信息,使它必须能够在不同的环境之间进行切换,而且必须要有接口,可以自动。在这件事情上,我们想了一个办法,就是给它做了一个配置项的管理。

 

这个配置项的管理是基于配置项级的管理(相对应的,另外一种则是配置文件级的管理),并且每一个配置项可以实现不同环境之间的切换。在实现上,底层对接了etcd+confd/disconf两套配置管理工具,从而解决了多环境下的应用配置项的秒级发布功能,并且额外做一些配置信息的备份、回滚、防篡改等必要的功能。由此,可以给DevOps提供了一个比较好的配置管理服务的能力。

 

这些东西全部做下来之后,我们发现自己”好象”做了一个运维平台,有了比较完整的功能:第一个是场景自动化,像刚才所讲的,场景可以进行编排。第二个是资源服务化了,有物理机、虚拟机、网络设备等各种各样的资源,并且可以推送各种各样的基础组件,并且这个资源服务化可提供给我们的DevOps使用。第三个是配置自动化。配置自动化也是DevOps的一环。我们可以借此使整个DevOps流程跑起来。

 

 

一些经验思考

 
 

 

1、在功能上,要讲求实用主义,好用为王。

 

大家对于传统企业、运营商的印象,大概都是:今年年初要规划,然后年终看有没有做出来。其实最好不要这样,因为需求和应用场景是一直都在变的,所以我们可以有规划,但不要一味地按照规划去做,必须是解决最实在的问题,才能更好地使运维平台在运维团队里推进。

 

2、在进度上,不要着急,但速度要快!

 

其一,运维平台做出来的功能必须符合DevOps流程,是DevOps所需要或是符合DevOps的才做,如果还是传统老运维那一套的类似需求,则一概拒绝实现。其二,运维开发本身要遵循DevOps敏捷迭代和持续发布,使运维需求得到快速响应,将运维同事的其它“法外”小工具小系统扼杀在摇篮里。避免烟囱林立的局面,也省去整合的痛苦。可怎么才能快起来?这个要看自己团队的实力,我个人觉得可以更多地借用开源,更快地提升实现的速度。

 

3、在对运维团队的引导上,要立足全员开发。

 

不能将开发局限在三五个运维研发的同事身上。避免这种局面:发现有人负责开发运维系统了,整个运维团队有什么需求,全部向他们提,这样的话其实又回到传统运维老路子上去了。这种方式不仅不能提升运维团队的整体效率,最后也会压垮运维开发团队,不是一个可持续的工作模式。

 

所以运维开发团队的职责是,向整个运维团队提供更多的通道,或者说提供通道框架能力(比如我们通过做这种场景的通道,可以让你编排,然后让运维同事再组装上小应用去解决实际的问题和场景),并且要不停地迭代出新的功能,每一次迭代新功能,根据运维同事的反馈去考虑后续的开发,去考虑应该跟进还是引导,这样才能锤炼出好的运维平台。

 

以上是我们在运维平台开发过程中的一些体会,最后用加缪的一句话来作结:“凡墙皆是门”。我们在做自动化运维平台的过程中,每一次碰壁都是一次进化,都能助你锤炼出更好用的自动化运维平台。。

   

Q&A

 
 

 

Q1:您好,这个平台这么大,部门分得这么散,你们是怎么把这个标准比较有效地推广到全公司的运维里面去,或者是让开发的都知道要按你的规则来走?

A1:这个事情不在本次分享我讲到的内容里面,而是在正式做自动化运维开发之前要完成的工作。这里首先你肯定会有一个PK,肯定会有拍桌子、瞪眼睛的过程,这个过程是跑不掉的,毕竟涉及各方的工作量。但在这个过程中,首先你得对这自己设计的一套标准部署方案有信心,要实力过硬,要相信一套好的部署方案,除了能解决运维的困难,也能释放研发团队大量的时间。第二,部署的过程必须是运维自己来实施,这样就天生有了部署标准的控制权。第三,我觉得应该争取得到各团队的自上而下的支持。 

 

Q2:您好,我也来自运营商的,对你们团队怎么运作很感兴趣,你们是如何组建这个团队的,驱动力是什么,在这个过程这么“撞墙”,然后穿过“墙”的?

A2:我觉得我刚刚说的比较多是技术上的“撞墙”问题,这里您提的应该是人方面的撞墙。首先,其实对我们来讲,最早是我们都靠人力运维的方式,甚至我们去外买一些厂家的平台,这实际上经历了较长的时间,然而事实证明这种方式不能很好地解决我们的问题。因此,我们团队的人其实也是从零开始的,一开始也是一边维护,一边研究工具,一遍开发,再引导整个运维团队去使用和改变运维方式。在这种模式下,自动化运维才慢慢做起来了,也吸引了更多的关注,并随着成果和效益的出现,慢慢去形成相对比较独立的运维开发团队,大概是这么一个过程。

点这里下载干货PPT

https://pan.baidu.com/s/1gfAhgHX

最新评论
访客 2018年05月22日

立场大于分析

访客 2018年05月15日

不先从业务上优化,发现并消灭慢查询;一来就改架构,…

访客 2018年05月12日

我感觉标题不应该叫上云引发的雪崩

访客 2018年05月10日

docker run -d --name=sqlops504 --net=host p…

访客 2018年05月09日

支持,加油

活动预告