xAI 用 Grok Bot 的 IncidentWatch 与 IncidentSweep 检测和响应产品事故

当产品事故发生时，支持队列往往是它最早显现的地方之一。客户开始报告同一个问题，有时甚至早于工程告警触发或任何人宣布事故。

在事故处理过程中，这些报告会持续涌入。起初，支持团队可能并不知道出了什么问题，也没有可以自信给出的答案。等到问题解决时，可能有数百甚至数千名客户在等待回复。支持团队必须在整个事故期间跟踪这些客户，然后确保在问题解决时每个人都得到正确的答复。

我们使用 Grok Bot 来处理这项工作的两个环节。它为我们提供 AI 队友，由它们负责运营性工作，尤其是那些原本落在人员和系统之间无人负责的重复性工作流。正如我们在最近一篇博客中分享的，SpaceXSI 客户支持团队使用 Grok Bot 中的 Support Bot 来处理面向客户的沟通。

现在我们又新增了两个专门用于事故处理的 AI 队友。第一个是 IncidentWatch，它监测支持队列中相似工单的激增情况，并在发现激增时提醒我们的团队。第二个是 IncidentSweep，它负责另一端的工作，识别受影响的工单并以经批准的批次关闭它们。

在 9 月 18 日的一次事故中，我们的 Bot IncidentSweep 在约 10 分钟内清理了 204 张工单，并由一名支持工程师审核和批准了该批次。此前，我们不得不花费数小时逐张回复这些工单，或者使用批量宏，而那样我们对谁收到消息的控制要弱得多。

通过客户报告检测事故

客户往往在我们的内部告警触发之前就发现问题。当多位客户同时报告同一问题时，这些工单可能是事故的早期信号。

IncidentWatch 是我们构建的一个 Grok Bot 队友，用于检测这一信号。它每五分钟检查过去 15 分钟的工单，寻找围绕同一问题的激增。如果该模式与已知事故不匹配，IncidentWatch 会向值班的支持工程师发出警报，说明明显的问题、匹配工单的数量以及可供调查的示例。

由支持工程师判断这些报告是否指向一起事故，并与工程团队合作进行调查。与此同时，IncidentWatch 会暂留那些明显与该问题匹配的工单。

一旦团队确认事故，我们会将其发布到公开状态页面。我们的主要面向客户的 Bot——Support Bot 会回到被暂留的工单，对照事故信息进行检查，并回复报告内容匹配的客户。随着事故进展，它可以再次返回并提供更新。

清理事故积压工单

事故解决后，队列中可能仍有数百张相关工单，每一张都需要最终回复。传统上，支持团队有两种清理方式，而两者都有缺点。他们可以逐张回复每张工单，这可能要花费数小时；或者使用批量操作，这虽然快，但几乎没有余地来发现不应收到该消息的工单。

我们构建 IncidentSweep，是为了将第一种方式的可控性与第二种方式的速度结合起来。

支持工程师首先告诉 IncidentSweep 要考虑哪些工单、排除哪些工单，以及具体要发送什么消息。IncidentSweep 会找出匹配的工单，逐一审核，并将任何无法确信与事故相关的工单搁置一旁。

在发送任何内容之前，IncidentSweep 会向工程师展示拟议的批次、其中包含的工单以及它们将收到的确切消息。工程师可以抽查这些工单，并在批准发送前进行修改。

随后，IncidentSweep 会以小批次发送经批准的消息，并记录每一项操作。它在批准后绝不会添加工单；如果出现任何失败，它会停止并报告发生了什么。

给 Bot 工作，而不是任务

Grok Bot 引入了一种与 AI 协作的不同方式。团队不必再借助 AI 工具来协助完成单个任务，而是可以创建拥有工作职责、并将整个工作流推进到结果的 AI 队友。

客户支持一直是我们实践这一模式的自然场景。IncidentWatch 和 IncidentSweep 承担的工作，过去需要团队中有人盯着、分拣并处理数百张单独的工单。在整个 SpaceXSI，我们正在寻找更多工作流，让 AI 队友能够承担同样类型的职责。

立即试用 Grok Bot