本文来自：

彭亮极狐(GitLab) 高级产品经理

郭旭东极狐(GitLab) 资深创新架构师

舒文斌极狐(GitLab) 高级网站可靠性工程师

最近几天，ChatGPT 真是杀疯了！

相信大家的朋友圈，已经被调戏、询问或探讨 ChatGPT 的贴子刷屏。

看到这个上知天文、下知地理，博古通今、学贯中西，不管什么问题都能告诉我们答案的 “杀手级应用”，不禁想问：“这么好玩东西不会只拿来玩吧，能不能帮我分担一些工作？”

虽然ChatGPT还没答应，但另一个不吃不喝不摸鱼的 “智能” 员工——ChatOps，已经在上班了。

什么是 ChatOps？

顾名思义，ChatOps 就是 Chat + Ops 的组合词，是使用即时通讯软件客户端、聊天机器人和实时通信工具，来促进软件开发和操作任务的通信和执行方式。ChatOps 往往也被认为是对话驱动的 DevOps。

在 ChatOps 中，所有任务都是由对话驱动，团队成员只需在聊天软件中键入相应的命令或包含相应关键字的内容，聊天机器人就会自动调用相关内容的平台，从而自动完成各种任务。

而这些任务的范围，从代码部署到安全事件响应，从团队成员通知到任务进度查询。理论上，ChatOps 可以继承 DevOps 大多数工具与优点，进一步提升团队自动化水平。

技术架构

一般来讲，ChatOps 由三部分组成：即时通讯软件客户端（也就是聊天 APP）、连接中心（机器人）、基础设施应用。

ChatOps 主要动作，就是将之前 DevOps 中通过 Web 页面进行的操作，通过聊天机器人来代替。也就是说，聊天 APP 成为用户进行操作的一个客户端，用户的任何操作，都可以通过聊天 APP 来实现。

这也为聊天 APP 提出了要求，它需要将用户的输入发送给响应与连接中心，也就是我们常说的聊天机器人，这样机器人才能进行后续的自动化操作。所以聊天 APP 需要支持像 slash commands 或 outgoing 这样的机制，允许用户将自己在聊天框中输入的内容发送向第三方平台。

一般情况下，大家都喜欢叫这部分为机器人或聊天机器人，但这个表述并不精确，经常会造成误解，所以这里将其描述为连接中心。

它的工作就是接收聊天 APP 发送来的消息，识别处理消息内容，根据识别内容调用基础设施中的应用，等待基础设施应用完成任务，并返回通知（可选）。

可以看出这部分的主要作用，就是接受识别请求并连接基础设施应用，只有在识别请求处接入自然语言识别系统，其能力才更贴近机器人。

这部分与 DevOps 系统与各个基础设施应用的连接方式相同，如果已有则可以直接复用，需要注意的是，基础设施应用不同版本的 API 可能有所差异，需要谨慎维护这部分代码。

ChatOps 在 DevOps 的基础上，进一步降低了使用门槛，一些常见的 DevOps 场景，均可以借助 ChatOps 来大大提升使用便利性与用户体验。

信息通知是目前 ChatOps 最常见场景，目前主流的即时通讯办公软件，如：Slack、钉钉、飞书均内置了极狐 GitLab 消息通知，只需简单配置，就可以将代码提交、issue 变更、MR 合并等消息，实时同步到聊天群内，一个操作能被团队所有人看到，提升沟通效率。

不仅是极狐 GitLab，很多应用都内置了 Webhook 功能，所有事件都可以通过 Webhook 推送到办公聊天软件，实现实时通知。

相信很多人都经历过「弄清某个特定命令是否同时执行」的痛苦。

在 ChatOps 中，所有的命令均在群内执行，向所有群成员公开，每个人的操作、通知和信息均在聊天群内展现，所有的任务都置于前台。上下文一目了然，减少了因工作台切换导致消息被截断，承接有序，打造流畅的工作体验。

将过去手动完成的任务通过 ChatOps 自动完成，不但可以提升工作效率，降低重复劳动，还可以减少手动操作可能导致的失误。另外，新同学进入团队，能够通过观察老司机的工作方式，迅速上手，赋能团队提升工作质量。

极狐GitLab 已和国内外众多主流 IM 产品进行集成，从而实现 ChatOps。

如飞书、钉钉、Slack、Mattermost、Discord、Google Chat、Microsoft Teams、Webex Teams。其中和飞书、钉钉的集成是极狐专享功能，已在极狐GitLab 15.1 旗舰版本正式对外发布。

在极狐GitLab SRE 团队如何落地实践 ChatOps？

极狐(GitLab) SRE 团队的日常工作大部分都实现了代码化，并分布在各个项目。

例如，服务器配置管理放在 ansible playbooks 项目里，K8S 部分部署放在了 helm chart 项目中，还有一系列基于目标系统 api 的操作需求。

SRE 团队希望基于 ChatOps，可以进一步降低这些自动化资产使用的复杂度，使团队成员都可以轻松上手琐碎的运维工作，实现操作与操作人解耦；同时，包装好的命令也可以在程序上对操作者的行为做出一定限制，避免操作者直接接触环境，提高操作安全性。

为此，极狐(GitLab) SRE 创建了 ChatOps（名为chatops-go）项目，该项目直接与 Slack 的 slash command 绑定，作为运维统一入口。

由于 SRE 运维脚本分布在各个项目中，我们将 ChatOps 的命令类型分成这三种模式：

直接执行：针对一些快速的、简单的 API 操作，执行动作直接在 ChatOps 项目中完成。
触发下游并等待：ChatOps 的 job 不会直接执行操作任务，而是触发下游项目流水线，并等待下游流水线的返回结果。这个场景适用于，对应的系统需要较为复杂的维护脚本（如ansible palybook），且这些脚本在其他项目中。
触发下游并直接返回：仍然通过 ChatOps 触发下游项目流水线，但是触发成功后不等待下游流水线执行完成，而是直接返回流水线的链接地址。这个场景适用于，要触发的任务耗时较长，如环境升级等。