引言
本文将分两部分，主要讨论微信机器人的实现与适用性以及在此基础上的ChatOps可行性探索。
微信机器人的技术实现与适用性
实现微信机器人的方式有很多，目前开源的微信机器人也不少，常见的实现方式有以下几种：
- 基于PhantomJS/Selenium操作微信
- 基于Hook方式操作微信
基于PhantomJS / Selenium操作微信
这种方式本质上是对于自动化测试在特定领域的应用。其原理是不断遍历监听微信Web应用中特定元素（比如新消息的红点标识或消息文本框），因为其本质上是HTML元素，因此当监听到特定元素出现时，模拟鼠标来点击，并自动化遍历获取DOM树中所有新消息文本。
回复原理类似，同样是模拟键盘输入，一般通过Chrome或Webkit等技术实现，比如使用PhantomJS、electron等基于webkit的headless方式实现，也可以直接使用Selenium。如果使用headless方式启动浏览器， 用户是无感知的。采用这种方式实现机器人，被甄别及封禁的概率相对第一种方式会低很多，稳定性也能有一定的保障。但是被逐步淘汰的问题依然还在。
基于Hook方式操作微信
这种方式最初是始于Windows的自动化技术。由于微信PC的UI是采用HTML渲染的，因此直接在Windows中无法获得页面控件的句柄。但由于需要与服务端通信，因此可以直接模拟客户端给服务器发送HTTP数据包并监听响应来实现。此外，客户端与微信服务端是通过加密协议通信的，直接对协议做分析也是一种思路，但成本相对较高，不是特别经济。优点在于能解决上面两种方式的问题，支持新注册微信号且规避了灰度下线，即使微信Web被封禁也不会影响PC端应用。
此外，这种思路可以进一步引申到其他设备终端，比如Android操作系统支持Xposed或VirtualXposed框架，可以直接用来修改apk的行为并且是无感知的。iOS系统则可以考虑Method Swizzling或类似实现方式，都能满足需求。
这类解决方案的优点是：基于事件触发机制，时效性会比较高；进行扩展和定制的工作量也相对适中，安全性也比较高，不易被封禁。但缺点也同样存在：对于手机厂商及系统版本会比较敏感，对于微信版本也比较敏感，某些升级可能会导致功能不可用。
ChatOps可行性探索
ChatOps缘起
先从DevOps说起，其实最初的软件研发是从瀑布式开始的，此后不断涌现出各种先进思想，如敏捷与精益，目的是加强研发团队的协作与沟通，提高开发效率并维持快速交付。而一旦产品或系统开发测试完毕，部署上线后，后续的维护则交由运维团队执行，那么如何填补运维与研发之间的信息落差，这是引入DevOps的缘由。
DevOps是由Development和Operations的组合而成，本质上是过程与方法的改进，目标是促进研发运维一体化，降低沟通成本并提高协作效率。这种协作模式可以通过下图清晰描述：
图1：DevOps范围定义与流程
通过引入一系列自动化工具，将三种不同角色有机融合起来。从研发交付、自动化编译与测试、到自动化发布部署、生产自动回归、自动化监控，各角色协作流程在同一视图中循环往复，持续集成与交付上线。其中，一方面是不同角色的协作，这些角色可以是不同团队，也可以是同一团队同一批人来担当。其次是自动化工具的引入，通过各种自动化工具最大程度上降低沟通成本，提升各个环节的效率。
从DevOps到AIOps
人工智能兴起带来了时髦的名词：AIOps，即智能化运维。这个词最初来自Gartner Group，并且AI实际上是指Algorithmic IT，其愿景是希望通过机器学习对生产环境的海量数据进行自动化分析，自动对故障进行预判并执行对应操作。因此可以说是DevOps的升华，想象空间很大。部分大厂号称已经落地，比如腾讯织云，但对大多数企业来说，还需要时间深入探索和实践。
为什么ChatOps会兴起？
ChatOps的同样由DevOps发展而来，从另一个方面演绎新的工作理念与工作方式。由于社交通信软件的普及，团队成员间通过微信等社交软件广泛连接。而业务系统与自动化工具等通过标准化接口相互关联。Chatbot机器人则作为纽带将人与系统紧密连接在一起，进一步提升沟通与协作的效率。
图2：ChatOps架构
其实早在2013 年，GitHub就已经有过尝试，试图以聊天形式完成DevOps。核心思想是通过机器人去对接后端服务，包括业务监控、预警系统以及其他自动化运维工具等。技术人员以对话方式与机器人沟通并完成业务操作。这里的机器人，本质上是一个包装成社交聊天对象的自动化连接的工具。
ChatOps相比以往的协作模式，主要有以下两个特点：
- 移动：传统方式通过笔记本或工作站连接远程桌面进行办公，相对来说ChatOps的自由度更高，随时随地可以办公，受环境与场景的制约非常小，工作体验快捷灵活。
- 共享：预警事件、操作记录在工作群中共享，降低了沟通成本；值班中如有缺失也方便补位。此外，对于团队新旧交替、工作承接、业务传续也有帮助。
ChatOps探索
ChatOps包括三个组成部分：社交平台（例如微信）、机器人（人与系统自动连接）、后端服务（基础设施&开放接口）。其本质上是一种新的协作模型。不仅仅可以应用于技术团队，同样也适用于产品运营等其他团队。
图3：ChatOps的组成
社交平台国内外有很多，比如国外的Slack、Whatisapp，再比如国内的微信、企微、QQ，都是不错的选择。机器人框架可以使用成熟产品，比如国外比较有名的Hubot、LITA和ErrBot等；也可以基于本身需求进行定制，笔者团队内部会倾向于使用自研的微信机器人实现。至于后端服务则因人而异，因需求而异，不一而足。
相关的后端服务系统，通过接入机器人，会将关联的系统消息（比如业务监控或者预警事件）从外而内逐步向中心点汇聚，这个中心点一般是团队沟通群或类似的消息汇聚点。所有消息按照时间顺序聚集，团队所有成员能够第一时间了解各项信息，透明共享，快速响应。
图4：ChatOps消息汇聚模型
在业务探索与实践中，我们期望通过汇聚运营信息、预警事件等一系列相关信息，使得团队在统一的沟通窗口中，简单交互就能完成大部分运营工作，避免在多个系统、多个窗口间频繁切换，导致时间碎片化与精力分散。通过自动化方式降低人工运营的成本，从而提升投入产出比。
图5：ChatOps业务预警&运营处理原型
ChatOps的想象空间
GitHub在2013年开发了Hubot 的机器人框架，通过命令匹配方式提供服务，其理解力比较低；随后出现了Lita、Errbot等机器人。Lita与Hubot相似，基于Ruby编写且采用Redis存储；Errbot则是由Python编写并引入工作流概念，可以支持审批类需求。此外，其他主流社交软件也相继提供其机器人插件，比如Slackbot。但无论哪一种，其交互过程仍然是使用命令式交互，或者通过特定词汇的自然语言，本质上仍是基于字符串匹配的原理来进行意图识别。机器人相当于是社交平台上的插件，提供终端功能，但与简单终端不同的是，它引入了移动与共享的特性。
而随着NPL技术的发展，ChatOps将会变得更智能，进入NLU（Natural Language Understanding）阶段。在这一阶段，机器人对于自然语言的理解将变得更深入而细腻，能更准确掌握用户的意图。比如，Amazon Lex已经提供类似服务，它具备自然语言理解（NLU）和自动语音识别（ASR）功能，支持语音直接输入转换，并通过意图（Intent）、表述（Utterance）、数据槽位（Slot）和实现（Fulfillment）等核心概念实现意图理解。此外Google Actions和Watson Conversation也提供类似的交互与意图识别服务。
在NPL/NPU的基础上，更进一步则是语音智能的提升。不仅仅局限于文字交互与理解，而是通过语音助手以对话形式直接完成运营情况监控更新、异常事件处理、流程审批等工作，并且通过声纹识别等技术进行统一的鉴权控制与管理。
总结
ChatOps其实在国外已经是比较成熟的协作模式，成熟的机器人框架也非常多。一些巨头公司对于ChatOps智能化研究也在不断进步，尤其是NLP/NLU以及语音交互产品与服务。国外对于Kubernetes、Istio 等项目， Google发起了适应云原生的开源项目Prow来支持ChatOps；而国内近期企微也开始提供群机器人服务。总而言之，ChatOps将会带来新的思考方式与协作模式，并极大提升整个团队的效率。
参考资料
[1]Amazon Lex开发指南：https://docs.aws.amazon.com/zh_cn/lex/latest/dg/what-is.html
[2]ChatOps的前世，今生和未来：https://www.jianshu.com/p/7aa2ced21302
Will Jiang