摘要： 2025年4月，基础架构-SRE-GOC、基础架构-SRE-数据化和基础架构-SRE-基础平台三个团队深入合作，将LLM的多模态信息智能化分析能力应用于故障应急领域，助力事故应急的AI智能化升级，事故应急整体效率提升30%。

一、背景介绍

“GOC”（Global Operations Center）是字节跳动基础架构的稳定性保障组织，承接了字节集团主要核心业务的全量核心报警，提供7*24小时的监控盯屏+事故应急保障服务，是字节集团事故应急组织的一号位。

在整个应急流程中，监控是核心的一环，基础设施、基础组件、核心业务全链路的报警通过系统对接，转化为GOC 7*24值班台的应急事件，值班同学会进一步基于应急场景、指标异常、处置规范对每一条报警进行研判，发起不同程度的应急流程（风险预警，风险应急，事故应急），直至恢复闭环。

二、痛点分析

随着接入的监控场景的增多，当出现基础设施类事故的时候，往往伴随着大量报警的出现，网络、基础组件、业务侧会同时触发不同维度的报警推送到值班工作台，那么在报警的研判，事故应急的发起，初因定位，受影响方的通知以及恢复的判定上都需要对批量报警做重复性的判断和操作，会极大影响应急初期的黄金时间，从而影响应急止损的判断和执行。

而这个场景对于AI来说，是一个相对可理解、可判断、可执行的特定化场景。因此在系统接收到新增报警后，可以将报警统一输入到AI算法中，通过AI算法完成报警事件的分拣、分析、判断和关联，完成事故的自动创建、报警自动关联、初因定位定界、相关人员拉群等动作，实现事故应急发起的全套流程智能化，大大减少了值班人员的人工操作内容，同时提升了操作效率。同时，以事故所关联的监控信息、群聊信息、系统元数据信息作为输入，对事故的影响面、处理进展、当前状态完成智能化总结，用于事故进展的主动推送、自助问答，提升事故处理中信息整合与同步的效率。

三、智能化赋能GOC应急提效

智能化聚焦在GOC应急中的事前和事中提效，如上图所示：通过全链路的智能监控和诊断，赋能事故及时发现和初步定界，迅速拉起相关方应急，并可以进行升级推荐；对于变更类事故，事中进行可疑变更推荐，赋能故障排查人员迅速定位到根因变更；对于大型故障，事中人工处理海量信息是低效的，而LLM可自主学习、提取和交互关键信息，有效提升了信息整合与同步的效率。

3.1、全链路智能监控和诊断，赋能MTTR收敛39.91%

（1）核心能力

每天上报至应急值班台的需要 GOC 协同处理的告警数量超过100条，定位定界是影响故障处理效率的主要瓶颈，在大型云平台上，由于产品调用链复杂、业务组件相互影响，这个问题尤其突出。GOC应急值班台整合了“业务+架构+SYS”全链路核心指标，利用时序异常检测算法实时检测并下钻异常实例，并结合产品服务树、组件拓扑、跨组件血缘等信息，快速定界引起事故的根因组件/psm/库/实例，拉起组件协同应急，有效降低了故障恢复的MTTR。

运维指标有周期型、震荡型、趋势型等不同特征，很难有一种时序异常检测算法可以覆盖所有场景。我们利用“时序分型+集成学习”的方法，整合了一套自适应的时序异常检测算法库，对不同类型运维指标都可以准确检测异常，下钻具体异常实例，并分析异常模式。

即使异常检测算法的准确性很高，大型云平台的不同组件和产品也会有较多相对独立的无关告警。我们通过时间相关性、业务服务树、组件拓扑和组件间血缘依赖，进行初步的相关性分析，剔除噪声影响，获得关联告警集。

针对关联告警及其异常维度和模式，再结合窗口内变更、网络维护等系统事件，我们利用LLM学习稳定性专家的诊断经验进行根因定界，可有效识别调用链异常、重保实例异常、底层基础设施异常、组件面积型异常、Metrics监控类异常等不同模式的根因。诊断定界信息第一时间发送给应急值班台，值班同学确认后可直接拉起相关组件进入应急流程；如当前有正在应急的故障，则再次推理当前诊断信息是否与已有应急相关，是否需要进行应急合并。

特别的，我们训练LLM对P2等级以下的故障进行实时评估与智能升级建议，确保严重故障场景能够快速进入高优处理流程，提升重大故障的应急响应效率。例如，LLM会分析面积型告警的严重程度和告警增长率，并在应急群中自动推送当前告警情况的综合描述和可能存在更广泛影响的警示，并建议升级至P2或更高级别。值班人员即可直接点击卡片上的升级按钮，应急响应等级同步更新。

（2）实际收益

集团核心业务上报至GOC应急值班台的告警，已100%接入算法诊断。上线半年以来，共拉起10次有效应急，包括5次 Notice+ 故障，平均 MTTR 19分钟，对比同期业务通过 P0 Oncall 上报异常并转事故应急的 MTTR 收敛了39.91%。同时，P2+故障平均升级决策耗时从6分钟缩短至2分钟，有效防止了事故等级及影响面的进一步扩大。

3.2、智能变更推荐，赋能变更类故障MTTK收敛59.24%

（1）核心能力

基础架构内场和火山的事故根因最大来源是变更（2024年占比分别是85%和43.04%），故障拉起时通过可疑变更推荐迅速定位最相关的变更单，可以显著降低故障定位时间MTTK。

可疑变更推荐先基于时间相关性、故障语义相关性等因素进行初步排序，但是在这个过程中存在上报故障不准、产品知识缺乏、变更事件上报不规范等问题，导致初步排序效果不佳。我们引入LLM的总结和推理能力进行精排：

复杂变更对象改写：在多组件云平台，变更对象复杂多样，直接和故障信息进行比较效果不佳。我们利用LLM对变更对象进行改写，抽取其中集群、dc、psm等关键信息，以消除其他无关信息的影响。
故障信息完善：故障人工上报无法保证信息的全面与标准。我们利用LLM，对故障拉起之前的oncall群、告警群等群聊记录进行智能总结，提取故障产品、影响面、风险区域等关键信息，保证故障信息的完整准确。
LLM相关性判断：通过LLM的推理能力，对标准化改写后的变更事件与完善后的故障信息进行相关性判断，并通过多个大模型投票来消除LLM幻觉。

（2）实际收益

涵盖基础架构、火山云基础、字节云产品、系统部、边缘云等组件的可疑变更单推荐，在查询到全量变更事件的基础上TOP5召回率达到78.85%。TOP5 召回的 Notice+ 故障平均定位时长为15分钟，相比同期其他变更类故障收敛59.24%。

3.3、智能问答和总结，应急工作提效30%+

（1）核心能力

基础架构的故障往往涉及多个角色（RD、SRE、业务方等）与数百人协同。飞书群聊是故障最初讨论的入口，但由于上下文分散、结构化程度低、排查链路长，后续进群的处理人员极易出现沟通冗余、信息遗漏、理解偏差等问题，需要花费较多时间梳理上下文，进而影响整体应急处理效率和客户情绪的安抚。

为提升故障期间的信息响应效率和决策质量，我们推出了基于LLM的智能问答能力，监听和订阅群聊与故障上报信息，利用LLM的多模态能力对文字、表情、图片、电话会议内容进行学习，聚焦应急响应中高频、关键的信息交互任务，实现故障信息的结构化提取与智能问答，作为GOC应急流程的自动化助手，可自动回答关于故障现象、排查进展、影响面、故障根因等关键问题，降低信息理解成本，提升响应效率。

同时，GOC日常要对历史故障进行分析，找出共性问题重点解决。我们将事故离线数仓引入LLM，结合LLM自动生成代码的能力，根据用户问题，动态进行单表数据查询、多表数据关联、趋势和异常分析，在历史故障域提供智能数据处理能力。

（2）实际收益

LLM对故障信息自动学习和智能问答，相比人工更全面有效。以影响面分析为例，LLM回复能够包含90%以上受影响的产品信息，远比人工全面。故障应急期间，GOC信息同步工作大部分可由LLM代替，工作提效30%；在涉及多部门的复杂故障场景下，通过聚合答复与主动推送，进一步提升了沟通效率，整体应急效率可提升40%+。

四、规划展望

值班台无人值守

现在的事故等级与应急，还是由值班人员决策与拉起，甚至需要GOC值班人员与组件人员共同决策。这其中最重要的原因，是LLM可处理的场景不够全面，尤其在一些未处理过的故障类型表现的不够稳定。未来，我们将沉淀更多私域知识，训练LLM成为一个越来越聪明的稳定性值班长。同时，现在核心的SLI指标也不够全面，组件全量监控指标处理和分析的成本又很高。随着LLM多模态能力和推理能力的进步，我们相信有一天，LLM自己也可以看懂监控大盘，结合组件侧的细粒度观测，自己就可以决策什么时候该做应急，如何应急，真正做到值班台无人值守。