返回 登录
0

解读ChatOps:开源聊天机器人怎样协助运维?

阅读3946

ChatOps通常是指依靠群组聊天室进行管理运维工作的一种。在ChatOps领域,我是一个新人,通过学习与运用,再回过头来看,对GitHub、Apple这样的一些先行者更是崇拜。

在现在这个概念为王的时代,ChatOps更像是一个“弱建筑”定义,低调不失优雅。希望通过我的分享,和大家一起来发现其生态建设(以我熟悉的Hubot为例)、基本设计,为后续更好的实践提供一个参考。

背景,何为ChatOps?

先看看实验室截图,我在聊天室中通过与某机器人沟通,获取容器云的测试环境的top5资源以及主机健康信息表。

图片描述

直观的感受就是ChatOps给了一个全新的工作环境,让我们可以在聊天室中,通过聊天的方式,获取想要的反馈。

说到ChatOps,自然会想到DevOps。市场上这两年在“疯狂”的传递着DevOps的理念,那我们有没有考虑过DevOps的核心是什么?有哪些实现分支?又存在一些什么问题?很多人都像我一样,会习惯的去说,DevOps有四大核心,包括技术、组织、流程、文化;实现DevOps可以从CI/CD着手,以自助自动为指导思想;DevOps要落地很难,因为有太多历史债务,有太多规章制度……

那该怎么正确看待ChatOps呢?机器人?聊天室?机器人聊天运营?先看看SneakyCode上的总结:“At the heart of DevOps is CAMS …… ChatOps isan extension of DevOps and enhances it with and extreme focus on CAMS”。这里,CAMS是指a culture of automation, measurementand sharing,认为ChatOps是对DevOps的一个实现与加强。

一直以来,运维的工作方式给大家的感觉就是脚本,部署要执行脚本、变更要执行脚本;或者进阶一层来看,运维会用各种小工具,比如Puppet、SaltStack等,对脚本形成统一管理、下发、执行。很多人都在讲:要把繁重且重复的劳动交给机器人,让人做更有趣更创新的事情。比如运维同学所做的日常巡检、故障处理,则可以由这些机器人伙伴来协助处理。而作为运维同学的伙伴机器人,一个很好的参与工作方式是加入到我们的日常聊天组,一起共事、一起学习。—–这就是ChatOps,但不局限于Ops。

低调,互联网时代的另类

现在市场上ChatOps的开源实现,呈三足鼎立之势:

1.Hubot:CoffeeScript实现,GitHub提供且自用

2.Lita:Ruby实现,支持容器部署,依赖redis

3.Err:Python实现,我目前还没有用过

以Hubot为例,这是GitHub在5年多前开发的一套用于管理GitHub自己的软硬件的机器人,中间历经了自用、开源、重写再开源三个阶段,现在俨然成为GitHub上最火热的项目之一:

图片描述

在过去的5年多时间中,其宣传相比DevOps、微服务、容器这些概念来说,少的可怜;但是最近ChatOps更像是被推出到了风口,被越来越多的提及到了。

开源生态讲究的是合纵连横,单向集成是生态建设的最大阻力。在第一次使用Hubot时,其生态建设的完备性相当让我出乎意料,在出向上,Hubot本身已适配很多:

图片描述

而在入向上,我使用的Slack、HipChat都默认地做了对Hubot的集成。以Slack为例,进入应用管理后,直接就可以集成Hubot、Lita,而不需要自己通过API做集成了。

图片描述

除了上面提到的与chat软件的集成,在部署环境上,Unix、Windows都可支持,而且Hubot支持了Azure、Bluemix、Heroku等云环境的快速部署(虽然还没全自动化)。这里不免又一次吐槽,咱们国内的一朵朵公有云,天天在谈生态,为什么没有一家去做做这些事情呢……

机器人,说的少做的很多

现阶段,机器人像是你团队里刚来的新人,更多的是在有序的安排下一步步做事(这里当然不包括AlphaGo这些高端的东东 )。最常规的工作方式如下:

图片描述

• 通过给予command,由机器人伙伴去实际云中操作,人和机器人伙伴的通信走私有通道,机器人伙伴会将信息回复到聊天室中。

• 机器人伙伴同样分公共与私人的,最简单的方式就是用不同聊天室来隔离(不同的圈子嘛)。

机器人伙伴作为聊天室的一个成员,表象上它和所有人是一样的。

图片描述

但机器人就像是很多团队里都存在的那种个性员工,说的少做的多:

说的少——一个聊天室里,大部分时间机器人伙伴是沉默的,或者默默在后面做事的;说话的都是我们这些喜欢“闲扯”的人,真有事情来了,才想起机器人伙伴能不能帮忙给做了,这时候他才会被逼着跟你“说”两句。

做的很多——如果你愿意,机器人伙伴可以帮你做所有事。当然这里有一个度的问题,不是所有的事情都应该让机器人伙伴去做。机器人伙伴本质上是一种有规律下的封装,只有事情是稳定的、可持续的,才考虑招聘机器人来做。但是,千万不要无限的去招聘机器人,即使是私人的。因为和你招聘其他团队成员一样,想象一下你的团队无限扩展,有些方面自然有好处,但带来的问题也不言而喻。

那一般我们怎么招聘机器人呢?再以Hubot举例,前面提到这是基于CoffeeScript的,需要一定的脚本基础,不过从我的使用情况来看(我脚本基础也很一般),关系也不大(具备node,npm相关的知识就可以),因为真正和CoffeeScript相关的工作很少,一般就两步(当然,这个是Slack适配后做了易用性,默认可不是这么简单的,后面会提到如何适配):

图片描述

定义robot:每个机器人的定义方式基本上是一模一样的;

匹配command:发送返回信息,上面只是截取的示例,一般会在匹配后,发送http rest请求实际去工作(这个就有很大的可操作空间了),将结果format后再发到聊天室中。

如果你的公司用的是没有与Hubot集成的chat软件,还需要做一次client的封装,这个稍有点复杂,需要一定的脚本基础,可参考hubot-slack项目:https://www.npmjs.com/package/@slack/client,我用一张图来说明Hubot的扩展架构,其集成时的插件点很明确(注:下图只标识了最重要的几个方法):

图片描述

通过实现Adapter的必要方法,完成机器人的生命周期管理。在与Slack集成时,稍有特殊性在于:run方法中,注册了Slack的message事件(当Slack有消息时触发),在message方法里,通过消息类型、发送人、channel等上下文信息,将具体消息封装后dispatch给机器人。

避免误区

我认为在接纳ChatOps这个理念的过程中,容易存在三种思想误区,会在一定程度上阻碍ChatOps的落地。

误区1:ChatOps纯粹是为了好玩。大家体验过人工智能,或者指挥过机器人做事,当时是持着什么样的心态去做的呢?我在一开始用Hubot的时候,兴冲冲的拉着部门同学分享,很直观的反馈就是:大家觉得很新颖,却真心不觉得有实际作用,感觉就是在我们聊天室里发发指令,用来看看数据图表等,运维门户上同样可以做。

误区2:聊天室里做事很不规范。企业用IM,比如钉钉、Slack、HipChat,也有用微信、QQ的,但很少有企业会把IM工具及内容纳入到标准管理体系中,很多时候就是纯粹的聊天工具。在这类工具中做事,大家会觉得无法保障规范性、可审计性等。

误区3:Command让工作不再专业。就像我们公司的产品EOS(SOA下的开发运行平台),自出生就饱受技术人员争议,原因是封装了太多底层实现。而ChatOps中的Command工作方式,同样会让我们觉得专业技能受到挑战。

上面这三种看法真的有道理吗?其实不然,在我看来这种误解的本质上来源于:

不同层面上的认知偏差。很多同学都在广用开源和工具,但从来没有觉得这些屏蔽了底层实现,为何对于ChatOps中的机器人伙伴做事,就有这个感觉呢?比如说大家用Eclipse开发代码,很少有人关心Eclipse工具本身屏蔽的内容,但一旦在Eclipse加了些插件辅助,很多人就觉得不直观了;再比如很多前端同学使用React、Bootstrap这些框架,是否关心过它屏蔽了prototype、闭包这些基础知识呢?这其实是不同层次的对问题的认知,说的直白些,我觉得是惯性让人变得封闭,不想跳出习惯的工作方式。

责任心缺失&个人主义。在ChatOps领域中,我们都说要机器人,但有时候会发现团队里就你在贡献,这当然是个很不好的体验,让人很受打击;再者,聊天室里去工作,让新同学看着聊天窗口就能学到你的工作方法,这个会让一些人觉得不爽,仿佛侵犯了一些个人信息,他宁可去写文档或手把手的教,就是不想在一个好像被“监视”的环境下做事。这个其实涉及到了Freedom & Responsibility的问题,如何权衡相信大家自有评判。

总结

虽然接触ChatOps领域时间不长,但已深刻感受了其独特魅力:

聊天室不再是聊天,随着伙伴角色的丰富与能力提升,聊天室会成为一个协作、学习的基础支撑平台。当然,不同于现在很多微课堂,这里会让你看到高手的实操方式、让每个成员可拥有很酷的机器人拍档。

生态从小团队做起。以前一说生态就被放得很大,即使企业里面说生态,也时常会放到基线平台的概念里;现在我们真的可以快速去建立小生态了,你只要在一些基础上招聘一些机器人,就可以为你的团队生态提供一份贡献,相信每个企业的可优化空间都很大吧。

合理处理人与机器的关系,不要再是e-e关系 ,而把他作为团队里的成员,最吃苦耐劳的成员来看待,这才是ChatOps所期望的。

止于至善,这是我的校训,在IT这个领域,尤其是现在的DevOps、ChatOps领域更为适用,这些都是点滴积累,精益求精的建设过程,不可能有万能钥匙(标准产品)。

这里讨论的知识初步做一些基础运维的事情,但是正如文章之前所提,ChatOps不局限于运维,后续的一些更高阶做法,会在团队实践后再做分享。
普元云计算专区:http://primeton.csdn.net/m/zone/primeton/index#

普元公众号:

图片描述

评论