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

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不局限于运维，后续的一些更高阶做法，会在团队实践后再做分享。

关于作者： 顾伟

现任普元信息主任架构师。长期致力于IT技术研究、产品设计与开发、架构咨询等工作，擅长Web、OSGI、CI/CD、服务治理、云计算等领域技术。对DevOps、自动化运维、微服务架构有着浓厚的兴趣。