转载本文需注明出处：EAII企业架构创新研究院，违者必究。如需加入微信群参与微课堂、架构设计与讨论直播请直接回复此公众号：“加群 姓名 公司 职位 微信号”。前端
ChatOps一般是指依靠群组聊天室进行管理运维工做的一种。在ChatOps领域，我是一个新人，经过学习与运用，再回过头来看，对GitHub、Apple这样的一些先行者更是崇拜。node
在如今这个概念为王的时代，ChatOps更像是一个“弱建筑”定义，低调不失优雅。但愿经过个人分享，和你们一块儿来发现其生态建设（以我熟悉的Hubot为例）、基本设计，为后续更好的实践提供一个参考。redis
背景，何为ChatOps？npm
先看看实验室截图，我在聊天室中经过与某机器人沟通，获取容器云的测试环境的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。运维
低调，互联网时代的另类dom
如今市场上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、自动化运维、微服务架构有着浓厚的兴趣。
关于EAII
EAII（Enterprise Architecture Innovation Institute）企业架构创新研究院，致力于软件架构创新与实践，加速企业数字化转型。
eaworld项目（微信号：eaworld，长按二维码关注）
eaworld是EAII的官方微信帐号。
以“企业数字化变革中的技术与架构创新”为主题的PWorld 2016大会即将召开！来自普元、红领集团、蓝月亮实业、星环科技的20余位技术大咖、近30场技术分享与你共议企业数字化将来！大会已于8月26日在北京及9月6日在上海举行、将于9月20日广州举办，感兴趣的能够扫二维码了解活动报名参与，欲了解详情请戳：阅读全文。
本文分享自微信公众号 - EAWorld（eaworld）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。