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

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

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

先看看实验室截图，我在聊天室中通过与某机器人沟通，获取容器云的测试环境的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的开源实现，呈三足鼎立之势：

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，由机器人伙伴去实际云中操作，人和机器人伙伴的通信走私有通道，机器人伙伴会将信息回复到聊天室中。
• 机器人伙伴同样分公共与私人的，最简单的方式就是用不同聊天室来隔离（不同的圈子嘛）。

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

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

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