团队如何采用 ChatOps 进行事件管理

选择 ChatOps 的理由

正如 Jira 和 Bitbucket 产品营销主管 Sean Regan 所说，ChatOps 是将对话融于工作：

“ChatOps 是一种协作模式，它将人员、工具、流程和自动化连接成一个透明的工作流。工作流将待完成工作、进行中工作和已完成工作衔接起来，放进一个由人员、机器人和相关工具组成的持久场所。公开透明收紧了反馈循环，改善了信息共享，并且增强了团队协作。更不用说团队文化和交叉培训了……”

“聊天是一种新的工作方式，可以捕获团队的集体知识，并用它来推动产品交付和协同工作的持久变革。光是谈论感觉不到真正变化，但一旦开始采用这种方式，您便再也不想回到过去了。”

ChatOps 在事件管理中如何运作？

在事件管理背景下，ChatOps 将事件工作流整合到一个地方，让团队保持敏捷和步调一致。

它可集中处理有关事件、事件报告、计划和进度的所有沟通，让每个人都能实时了解最新动态。它还为 DevOps、IT、沟通、安全、法务和其他相关团队提供一个场所，通过协同工作来解决事件，并且预防未来事件发生并缓解相关风险。

在事件发生期间打破信息孤岛

人人访问相同信息

事件对话越孤立，出现沟通错误的几率就越高，以致项目进度被扰乱。让所有人进入同一聊天室可以降低这种风险。

对话实时进行

这意味着，每个需要参与对话并采取行动的人，从解决事件的开发人员到安抚最终用户的社交媒体经理，始终都能了解最新情况，没有丝毫拖延。

上下文切换更少

若无 ChatOps，事件管理通常会在各种应用之间进行，并通过电子邮件、电话和短信等途径进行沟通。而这伴随着大量上下文切换，也需要许多脑力来进行跟踪。

ChatOps 尽力对一切进行简化，汇集到一个地方。警报会现身于聊天中。报告也会进入聊天中。对话降格为聊天。因此，事件团队只需前往一个地方，就能获得最新的信息。

不做“穿井得人”传声筒游戏

熟悉老派传声筒游戏的人都知道，只需交接一两次就会彻底改变传递的讯息。ChatOps 可消除这种风险。如果人人都访问相同的原始对话，出现沟通错误的风险就会大大降低。

内置事件事后分析书面记录

出了什么问题？解决事件花了多久时间？最终依靠什么解决了问题？将来能不能自动修复？

这些都是事件事后分析中可能要调查的各类问题。而且，在一份记录中保存所有沟通并加上时间戳，清晰正确地回答这些问题就会容易许多。

将警报系统与聊天连接

有越多开发人员为了解决事件而必须加入和退出聊天，您因为任务切换而损失的时间就越多。也就是说，与其在事件发生期间将警报推送到电子邮件和电话，不如直接将它们推送到聊天室，这可以加快事件解决过程。

为警报设置智能阈值

警觉疲劳是一种非常现实的威胁，尤其是处理重大事件期间。当我们建议将警报直接发送到聊天中时，我们并不是指每一个警报。

哪些警报有助于团队快速、全面地响应事件？哪些警报噪音更大？哪些警报是重复的？

事先提出这些问题并为聊天设置智能警报阈值，从而对各个方面进行简化，并降低团队因警觉疲劳而遗漏重要内容的风险。在 Opsgenie 等工具中，您可以配置哪些操作应发送到聊天室，还可根据属性来筛选警报。

为每个重大事件设置单独的聊天室

处理重大事件的团队不应该担忧自己会陷入困境，去处理那些小事件、日常聊天或其他未排进优先事项清单的事件。确保每个重大事件都有专属的聊天室。

将操作引入到聊天中

通过诸如 Slack 加 Opsgenie 之类的组合，事件管理聊天可以转变角色，不再只是一个沟通渠道。您可以直接在聊天中启用文本命令或按钮来执行事件操作，如分配警报、接管所有权、添加备注、将事件静音，甚至是创建新警报。

邀请多个团队

从 DevOps 和 IT 到沟通主管和社交媒体经理，再到安全和法务团队，通常会有多个团队和角色需要实时参与到事件当中。提前弄清楚这些团队和角色分别是谁，并尽早将他们拉入聊天室中。

安全为先

确保聊天是安全的，只有您希望其采取行动的人才有权执行那些操作。

保存聊天记录

事件解决后，就该进行事后分析了；ChatOps 可简化这个过程。在单个聊天室内进行所有事件沟通，意味着事件结束之后，您可以拥有所有对话、操作、警报和报告的完整记录，全部集中在一个地方。您可以保存此记录以备日后参考，用它来更新事件行动手册，以及在事后分析期间钻研，以便想办法避免或缓解未来发生类似事件的风险。