5.5.1 chatOps解决方案（2）

本篇是《数智万物下的运维思考》第5部分“场景”第5节的“chatOps”（2），主要介绍一下主流的chatOps解决方案思路。

1.chatOps由来

chatOps最早由GitHub提出，解决的主要痛点是他们有60%的人员远程办公，而运维和研发人员有相当部分工作是操作性的，比如：

- 运维人员需要远程登录OS进行各种运维命令，要和同事远程沟通运维出现的监控报警，查看报警等等。

- 研发人员在持续集成过程中，需要反复进行代码提交，包括代码合并、检查指标是否正常等操作性工作。

所以他们在命令行中开发了hubot机器人，协助他们完成上述操作性工作，我理解这个机器人的前身应该是一个简单的“问答+命令执行”的解决方案。接下来，这个解决思路，整合到了IM聊天软件，在聊天软件中增加了一个虚拟的机器人角色，与这个机器人交互可以与后端的服务进行交互。

我对chatOps的第一次认识是在两年前，在对slack的调研中学习到。在slack channel中的聊天输入窗口中输入“/+命令”，你可以快速匹配到相应命令，调用后台服务API，获得后端服务，相当于有一个7*24小时的服务助手，在聊天室这种扁平高效的工具中连接人、后台服务，解决一件多方协同、远程、实时的事情（注：slack的这个channel的概念是有主题的聊天室，这个区别于微信中的聊天室，这个话题有空再扩展）。如果将chat的能力融入到了运维场景将是一个很有趣的事，所以我们当时取名为chatWork，并在团队中做实践，即在聊天中高效的完成运维工作。

2.从协同看chatOps的优势

chatXXX的思路，在我们生活中同样出现，比如各大电商，电子政务网站，移动网站，线上座席等都有他的影子。chatOps的关键是用chat来解决Ops的问题，评价chatOps的优势应该从chat在协同角度上的优势来解答问题，以下是我前两年梳理的几个协同工具的简单对比，现在看来还适用，摘几个特征比对：

从表格看，虽然chat也有一些不足，比如与OA相比，数据结构化不强，不利于数据分析；虽然实时性强，但比电话或视频差点；与邮件相比，因为IM信息比较分散，主题性不强，某一个主题上下文关系关联相对弱等等。但是，chat的优势也相当明显，比如：

• 实时性强
• 利用碎片化时间
• 体验好（移动、熟悉）
• 利于融合各种业务场景
• 自组织性
• 传播速度快
• 兴趣点聚集

利用好上述chat的优势将极大的提升协同效率，尤其是在当前每个人都习惯于点开IM，用IM连接人并融入到运维场景上意义重大。

3.chatOps解决方案的几个关键

chatOp解决方案并不复杂，用下面这个图就能理解。其中场景是关键，找到涉及协同、移动、自动化等特征的运维场景，融入chatOps的解决方案。chatOps的发起点可以工具，也可以是IM；机器人是连接后端服务的连接点，有些IM工具内置机器人，也有开源的机器人解决方案，但需要IM支持扩展；底层的API总线及监管控析工具是原材料。可以说，chatOps的这几个模块必不可少，少了其中一个，chatOps可能就是鸡肋，或者说没有发挥他的优势。

当然，前面讲的chatOps解决方案不复杂的前提是你首先要有一个合适的IM工具，比如像SLACK这种支持丰富的扩展性工具，相关解决方案将如鱼得水。但如果你们的IM扩展性不强，则要进行相应的妥协，放弃一些能力，比如企业微信开放的接口则不多，在聊天室的回调、监听，以及聊天室中根据输入的模糊匹配等有意思的交互及能力无法实现。

chatOps在运维场景中的具体实践，各位可以结合chat的特征，发挥自己丰富想象力。ok，今天先到这里先。