如果一个团队不止关注眼下，也关注明天，那么显而易见他们应该做的两件事无非是：一，做领先于市场的事业；二，用更新更好的理念武装自己。在过去的许多年中，DevOps 逐渐成为了一个广受技术团队接受的工作理念，发展到今天，这个工作模式理应突破技术群体，发展为适应不同种类团队的方法模型，这也是 ChatOps 这个概念提出的背景之一。
我们试图在这里梳理 DevOps 与 ChatOps 的关系，介绍 ChatOps 的过去和现在，并且，试图介绍一些我们对 ChatOps 的尝试和经验。阅读这篇文章大致需要五分钟 :P
什么是 DevOps
DevOps 是来源于 Development 和 Operations 的一个组合词，顾名思义，是一系列过程、方法与系统的统称，旨在促进开发、测试和运维人员之间的沟通与协作。简单来说，是通过引入一系列的「工具」，通过三种不同角色的开发成员间的「协作」而实现的一种「自动化」的工作模式。这种工作方式带来的好处显而易见：
• 实现持续快速交付
• 能够降低人力成本
但很大程度上，DevOps 更多是指开发群体之间的一种协作模式（通常也在开发人员中实施），随着全行业的发展和人力成本的攀升，在团队所有角色间贯通的升级版「DevOps」逐渐登场，也就是我们将要重点介绍的 ChatOps。
ChatOps
ChatOps 的历史相对短暂，2013 年 GitHub 内部最早开始推行 ChatOps，希望能以聊天的方式更容易更快速的去完成 DevOps 承载的工作。
ChatOps 以聊天室，即沟通平台为中心，通过一系列的机器人去对接后台的各种服务，工作人员只需要在聊天窗口中与机器人对话，即可与后台服务进行交互，整个工作的展开就像是使唤一个智能助手那样简单自然。
在 GitHub 团队内部实现的 ChatOps 与一个叫做 Hubot 的机器人框架密切相关，Hubot 提供很多聊天机器人所需的基础设施，借助 Hubot 框架能比较方便的和自己编写的功能或自己的系统对接。目前，Hubot 已经发展出了较好的生态圈，有很多开源插件可以借用。
ChatOps 站在巨人的肩膀上发展，也为工作带来了显而易见的好处：
• 公开透明。所有的工作消息都在同一个聊天平台中沉淀并公开给所有相关成员，消除沟通壁垒，工作历史有迹可循，团队合作更加顺畅。
• 上下文共享。减少因工作台切换等对消息的截断，保证消息的完整性，让工作承接有序，各角色，各工具都成为完成工作流中的一环，打造真正流畅的工作体验。
• 移动友好。只需要在前台与预设好的机器人对话即可完成与后台工具、系统的交互，在移动环境下无需再与众多复杂的工具直接对接，大大提升移动办公的可行性。
• DevOps 文化打造。用与机器人对话这种简单的方式降低 DevOps 的接受门槛，让这种自动化办公的理念更容易的扩展到团队的每一个角落。
ChatOps 的实践经验
ChatOps 主要由四个部分组成，自动化的理念，一个沟通承载平台，一系列连接人与工具的机器人，一些后台工具和服务（基础设施）。
国外早期的工作沟通工具 HipChat，新秀 Slack 都是作为 ChatOps 承载平台的好选择，在中文的环境下，则可以选择 BearyChat（倍洽）等等。除上文介绍过的 Hubot 之外，还有一些比较成熟的机器人框架，比如 LITA、ErrBot 等。至于机器人后面对接的具体服务则更加数不胜数，以我们自己的团队举例，不仅为开发接入了 GitHub、Jenkins，也为产品运营接入了 Trello、Email 等。
除对接已有的产品，我们也使用 Hubot 框架对接了内部开发的一些具体的功能，如直接通过命令在聊天窗口查询待上线列表，实时了解 CPU 的使用状况等。
以上内容整理自 ChatDay 沙龙深圳站，DevOps & ChatOps 专场，来自腾讯、听云及 BearyChat（倍洽）的四位嘉宾现场分享了工作方式升级，共同探讨 DevOps & ChatOps 的共性，并介绍了一些相关实践案例。
四个分享主题回顾：
• 刘天斯/腾讯 《DevOps 持续改进之道》
• 唐晓敏/倍洽 《关于 ChatOps 应用于团队沟通方式的讨论》
• 许吉泉/听云 《追溯性能问题根源》
• 夏天/倍洽 《ChatBots 实践分享》
(新闻稿 2017-04-10)
