本文来自：

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

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

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

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

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

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

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

什么是 ChatOps？

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

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

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

技术架构

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

聊天 APP

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

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

连接中心

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

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

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

基础设施应用

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

ChatOps 给我们带来什么价值？

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

信息透明化，提升协作效率

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

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

公开透明协作，提升工作体验

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

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

快速上手，提升工作质量

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

极狐 GitLab 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 绑定，作为运维统一入口。

1. 多项目下的 ChatOps 命令模式

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

• 直接执行：针对一些快速的、简单的 API 操作，执行动作直接在 ChatOps 项目中完成。

• 触发下游并等待：ChatOps 的 job 不会直接执行操作任务，而是触发下游项目流水线，并等待下游流水线的返回结果。这个场景适用于，对应的系统需要较为复杂的维护脚本（如 ansible palybook），且这些脚本在其他项目中。

• 触发下游并直接返回：仍然通过 ChatOps 触发下游项目流水线，但是触发成功后不等待下游流水线执行完成，而是直接返回流水线的链接地址。这个场景适用于，要触发的任务耗时较长，如环境升级等。

2. 权限控制

在 ChatOps 中，我们往往需要比常规的流水线控制，更细粒度的权限划分。如小 A 作为 SRE 可以调整负载均衡的流量配比，小 B 作为开发可以查看当前环境下某个功能开关的的开启状态等。

极狐 GitLab 在这方面支持很好的扩展。在 ChatOps 触发的流水线作业中，我们可以通过一些 CI 预定义的变量，在权限上做一些「手脚」：

• CHAT_INPUT：用户通过 ChatOps 传入的额外参数；

• CI_JOB_NAME：用户通过 ChatOps 执行的命令名称；

• CHAT_CHANNEL：用户执行 ChatOps 命令时所在的 Slack channel；

• GITLAB_USER_LOGIN：执行 ChatOps 命令的用户在极狐 GitLab 中绑定的用户名。

通过这些变量，ChatOps 程序可以很好的回答这些问题：是谁在执行？在哪执行？执行了什么命令？传入了那些参数？

得到这些问题的答案后，接下来，就是 ChatOps 项目做权限判断的时候了。

使用场景

以下就是极狐(GitLab) SRE 团队的 ChatOps 日常使用场景：

1. 开启极狐 GitLab SaaS 的功能开关

这是一个直接执行的命令模式。直接通过 ChatOps CI 中的程序与极狐 GitLab SaaS 的功能开关做交互，实现功能开关管理。

使用示例：

2. 管理负载均衡的流量比

极狐 GitLab  SRE 的大量服务器配置管理工作依赖于 Ansible playbook 项目，因此此类工作不会直接在 ChatOps 自动完成。这个命令采用的是「触发下游并等待」的模式，命令传入到 ChatOps 项目后，触发 Ansible playbook 项目流水线，实现对负载均衡器管理。

使用示例如下：

3. 管理 Helm Chart 部署

K8S 上的负载通过 helmfile + hem chart 管理，因此也不会直接在 ChatOps 项目中执行。出于部署时长和安全性的考虑，ChatOps 只会直接返回部署流水线的 URL，并且使用者需要在该流水线中点击手动作业才会执行。

使用示例如下：

以上，就是 ChatOps 的定义、价值与最佳实践。

在 ChatOps 能力加成下，极狐 GitLab 能够帮助企业研发团队大幅提升工作效率与工作体验，已获得众多客户认可。

虽然现在的 ChatOps 相较于 ChatGPT，还过于稚嫩。但我们相信在不远的未来，ChatOps 一定会成长为研发团队更智能和贴心的伙伴。ChatOps 下一步如何发展？让我们拭目以待。