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 is an extension of DevOps and enhances it with and extreme focus on CAMS”。这里,CAMS 是指 a culture of automation, measurement and sharing,认为 ChatOps 是对 DevOps 的一个实现与加强。
一直以来,运维的工作方式给大家的感觉就是脚本,部署要执行脚本、变更要执行脚本;或者进阶一层来看,运维会用各种小工具,比如 Puppet、SaltStack 等,对脚本形成统一管理、下发、执行。很多人都在讲:要把繁重且重复的劳动交给机器人,让人做更有趣更创新的事情。比如运维同学所做的日常巡检、故障处理,则可以由这些机器人伙伴来协助处理。而作为运维同学的伙伴机器人,一个很好的参与工作方式是加入到我们的日常聊天组,一起共事、一起学习。----- 这就是 ChatOps,但不局限于 Ops。
低调,互联网时代的另类
现在市场上 ChatOps 的开源实现,呈三足鼎立之势:
- Hubot:CoffeeScript 实现,Github 提供且自用
- Lita:Ruby 实现,支持容器部署,依赖 redis
- 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 不局限于运维,后续的一些更高阶做法,会在团队实践后再做分享。
作者简介
顾伟,毕业于东南大学,现任普元公司主任架构师;先后参与和带领了华为 BME、中信银行 CBJUP、工商银行 CTP、中航信 RI、阿里云 ACE、普元云计算平台、普元 The Platform 等大型项目的交付;长期致力于 IT 技术研究、产品设计、架构咨询等工作,擅长 Web、OSGI、CI/CD、服务治理、云计算等领域技术;对 DevOps、自动化运维、微服务架构有着浓厚的兴趣。
如果你对 ChatOps、DevOps 相关话题感兴趣,欢迎扫码加入由顾伟主持的“普元云计算研发开放群”,讨论更多微服务、DevOps、容器相关内容,加群暗号“ChatOps”。
感谢木环对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们。
评论