把50%值班时间抢回来：字节跳动 SRE Agent 从 0 到 1 的降噪与排障实践

如果无法正常显示，请先停止浏览器的去广告插件。

相关话题： #AI Agent

1. 把 50% 值班时间抢回来：字节 SRE Agent 从 0 到 1 的降噪与排障实战董善东 20251024

2. 个人&团队简介董善东博士字节跳动Dev Infra-观测平台算法负责人深耕 AIOps & 可观测行业多年，在异常检测、根因分析、Agent 应用等领域有比较深入的行业认知和产品功能 Build 经验。曾就职于腾讯云、阿里云。团队面向整个字节内部开发者提供观测平台，与多个团队协同构建Metrics/Traces/Logs/Events等数据埋点&加工链路&存储，并基于此提供一站式的监控、报警、日志、链路追踪、根因分析等产品化能力

3. 目录 01 现状和痛点 02 产品架构演进 03 落地场景1：噪音告警识别和处理 04 落地场景2：业务自定义分析 05 总结&展望 0

5. 01 现状与痛点

6. 现状简介现状和挑战： - 需服务内场最大的用户量、业务量，业务多样性大，很多业务处于狂奔 - 观测平台和业务部门的稳定性平台的合作与“竞争” - AI时代更需要直面业务的最终需求来解决问题双线并行、相辅相成、增强LUI/Agent化保持产品演进长期方向，建设好基础能力，同时为AI铺路提高AI投入，通过AI应用降低使用成本，同时辅助用户理解产品设计增强LUI的全新交互能力、逐步将各类应用Agent化、通过Agent实现发现-分析-处理的闭环产品演进数据标准覆盖度平台能力场景化应用 LUI 抄近路 - AIOps + LLM 自动化智能化内置RCA 各处集成 Agent化

7. 告警值守的4 大环节和痛点告警噪音突出、业务分析难、个性化知识加载困难 - 业务问题的分析比较难。 - 业务排查经验无法沉淀和复用。发现异常和分析 1 告警接手和处理 4 - 平台存在大量注入规则，大量告警无人查看和处理 - 噪音和重要告警传统手段区分不明显。 2 告警协同和复盘 3 - 告警上下游排查和协同成本高 - 告警和故障复盘总结消耗太大告警优化和预防 - 有些告警明显规则不合理，但是人没有精力和能力进行规则优化调整

8. Agent引入来解决这些痛难点，有哪些优势？ 1. 优秀的观测平台+AIOps基础： - 观测数据标准化、全面准确的元数据 - 异常检测、RCA分析、告警聚合面向微服务的检测分析做了很好的积累和内部落地 - 打造了low/mid/high level 的tool service 2. LLM 作为一个通用大脑，已经展现出语义理解、复杂任务规划与拆解、工具调用、自主决策与学习方面又得到了增强。 LLM + Agent范式 + 领域Tools + 知识&学习

9. 02 产品架构演进

10. 产品层：Tools-->Workflow-->Agent/Agent Studio 1. APM as a service->MCP Tools 工具集合 2. 流程编排的 Workflow 3. Agent Studio

11. Web & Lark LUI web端： - 结合页面context，进行进一步的分析移动端： - 结合告警的context，进行分析

12. SRE Agent平台架构

13. Agent执行请求

14. SRE Agent 的探索和踩得坑定位：打造SRE Agent，解决繁琐、重复的劳动坑 3：多场景扩展时，工具和场景Agent封装粒度的tradeoff 坑 2：多轮执行的准确率不稳定坑1: 需要用户不断交互进行下一步分析，用户不买单阶段3 阶段2 阶段1 探索Agent的上限 Agent快速尝试利用langgraph 等构建多Agent 利用MCP 实现tools 的封装实现多轮交互式的RCA Copilot 业务排障的SOP 能够执行 Agent在值守场景的 MVP与优化 - 变更值守的巡检 - 告警值守的噪音处理 - LogID 的自定义分析阶段4 SRE Agent上线 - 评估量化驱动优化

15. 总结：踩过的坑 Agent关键点： Agent 执行的准确率、如何提供个性化能力（Memory）、超长上下文（Context Engineering）多轮自动化执行（如流程类 React ）的准确率不稳定 2 尝试自动化执行业务排障 SOP 、多轮流程（如 React 类操作）时，复杂场景下执行准确率不足，无法可靠替代人工步骤。场景tool在封装粒度上的 tradeoff 3 1 随着值守、巡检等场景增多，工具的 “组织粒度”（过粗缺乏灵活性，过细则维护成本剧增）成为瓶颈，难以高效支撑多场景复用。 4 单一场景（RCA Copilot ）多轮交互的精准度与实用性不足其他坑初期聚焦 RCA Copilot 单一场景时，多轮交互式分析的准确率、场景覆盖度未达预期，难以真正替代人工高效定位问题。观测数据过期，辛苦打标的case 样本失效踩坑经验历史经验如何承载，选择了告警规则上有的处理SOP ，以及从历史的处理（对话）记录中学习出SOP

16. 03 噪音告警识别和处理

17. 噪音告警的定义与持续学习噪音告警的定义噪音告警通常是指对系统稳定运行无实际影响、可通过自动化手段快速处理的告警，如重复告警、低级别无关告警、快速恢复的毛刺告警等。传统手段一般通过：时序异常程度的方式来判定是否为噪音。噪音判定的方式从对话、处理历史中持续学习告警的基础特征：指标异常程度、随着处理记录的越来越丰富，整个知识 pattern、发送频次、级别等系统也越来越丰富历史知识：告警历史的对话记录、处理经验

18. 噪音判定的特征工程分类策略名称定义适用场景示例指标数据在短时间内迅速满足触发条件并快速恢复的瞬时波动网络抖动、硬件临时故障等导致的短暂异常。某接口响应时间突然升至500ms（阈值300ms），但10秒后恢复正常，触发指标突刺降噪。持续报警指标数据长时间持续触发报警或循环触发/恢复，形成冗余通知。慢性故障（如磁盘空间持续接近阈值）、周期性环境波动。某服务器CPU使用率连续8小时超过90%，后续报警每小时仅通知1 次。重复报警同一类报警在短时间内高频次触发（基于规则或标签分组）。接口频繁超时、日志重复错误等场景。某数据库连接失败报警每分钟触发20次，超出阈值（15次/分钟），后续报警每5分钟发送1次。未知报警历史上极少触发的规则或标签组合报警（避免漏报新异常）。新上线服务、罕见故障模式。某日志监控规则首次触发error级异常，即使频次低也不降噪。客观指标指标突刺其他特征：过于细粒度的报警、信息过载、低阅读率、用户打标数据、指标的异常程度得分... 不同优先级报警的噪声判定阈值不同，用户对同一级别的耐受度存在差异。生产环境与预发环境的报警分级处理。某金融交易系统中，Critical级别的支付失败报警始终不降噪，而 Warning级别的日志异常在夜间自动屏蔽。报警时段敏感性用户对不同时间段的报警敏感度不同（如夜间仅接受高优报警）。夜间运维值班、敏感时段（如会议期间）的报警管理。某医院HIS系统在凌晨1:00-5:00仅允许服务器宕机报警（Critical），其余报警暂缓通知。个性化降噪用户自定义噪声规则，覆盖特定场景下的差异化需求。多租户环境、复杂业务场景的定制化管理。某游戏公司运维团队自定义规则：<br> 1. 游戏高峰期（20:00- 24:00）放宽接口响应时间阈值<br> 2. 屏蔽非战斗相关的日志报警。主观感知报警级别与用户耐受度

19. 知识提取与经验应用历史对话积累和解析从历史对话提取出知识知识更新与规则优化批量将历史报警中的对话、处理记录通过 LLM 提取关键信息，并封装为新的告警的对话和处理记录，持续进行获取和清洗等预处理。知识检索的tool，为后续的知识沉淀的从其中提取知识。和经验学习提供基础。将结构化记录写入知识引擎的 “专家将非结构化文本记录转化为标准化格经验库”，实现知识的不断更新和规式的判定规则，使得处理记录更加规则的持续优化，提升 SRE Agent 的噪范、易于管理和分析。音识别能力。 question 提取知识 llm_answer 针对报警规则[3518xx]【P1】【火山 MongoDB】节点CPU使用率过高+时间信息 +告警维度变量，我该怎么做？ @user_name: xx类的告警为周结论：需要人工介入期性告警，进行持续关注即可，依据：历史处理知识包含“xxx”,根据无需升级处理 xx推导得出

20. 持续学习机制参考： https://arxiv.org/pdf/2508.19005

21. 持续学习历史告警处理方式的效果

22. 噪音判定Agent Agent Prompt 示例： 1. 角色定义：噪音告警识别专家 2. 工作流程：利用xx获取报警基础信息 --> 利用xx tool 获取获取报警历史处理经验 --> 根据用户给你的信息、rca报告、历史处理记录来综合判断，当前的报警是不是噪音报警

23. 噪音告警分析样例核心能力： ✓ ✓ ✓ ✓ ✓ 自动判断报警是否为噪音智能分析报警产生根因推荐标准化处理流程展示相关历史报警记录提炼历史处理对话精华值守case示例：根据对话可得，分析与最终人工排障结论一致

24. 单次告警处理--> 告警值守的演进 - 多Agent协作：实现噪音分析、告警RCA、告警Action的 Agent - 多Agent协作下的Context管理挑战 - 工程架构保证：长任务能力、告警状态管理、告警关联能力、

25. 04 业务自定义分析

26. 面临的挑战当前以大语言模型（LLM）为核心的智能系统在处理简单指令时表现优异，但在SRE复杂业务场景下面临以下问题 1. ReAct 架构的适用边界清晰: 1-3轮交互效果还符合预期，超出则执行准确率明显下降。 2. 对自定义的分析和排查的自然语言，执行的诉求明确：我们期望在工具完备的前提下，AI 能够支持自定义 SOP（标准作业程序）语言的执行。这一能力的实现，将有效解决自定义 RCA 分析及 Action（动作）执行的问题，让 AI 在更贴合实际业务需求的流程中发挥作用。

27. 自定义分析和处理的真实示例告警自定义处理SOP 分析 TCE 实例进程退出报警主进程发生了异常退出（ExitCode != 0），请查看服务日志或 systemd 日志，更多说明参考 TCE 业务进程异常退出追查思路[文档] - 关联到相关日志 - 需要从文档中检索相关检查SOP [P0] [OpenAPI-SLO] streamlog-OpenAPI查询 SLO告警(>10%) 通常是-->访问Bytelog异常 : 1. Check 是否底层bytelog单节点问题？ Metrics:proxy.thrift_writer 的tag: server_pod 2. Check 是否底层bytelog单节点OOM？(新指标)Metrics:tce oom_cnt 的 tag: _cluster=* 3. Check 是否底层bytelog单节点OOM？(旧指标)Metrics:tce oom.pod 的 tag: paas_cluster=* 4. Check 错误码底层bytelog返回错误码70x，Metrics: proxy.thrift_writer 的tag: thrift_resp_code 或 result - 需要通过指标，进行像单实例、离群分析、错误码分析、等。 feed 成功率下跌告警根据文档中的SOP 文档，提取分析 SOP

28. 一、DagAct: 解决自定义问题的规划、执行架构 - actionDAG的格式规范 - 子Agent/tool 的使用规范 - 前后参数的引用传递 ActionDag 设计思考：将原本泛化的、模糊的自然语言，通过约束ActionDag生成的方式，转变化规划一个有序、更加结构化、可复用、可验证的执行流程。这样一个执行流程类似动态构建的workflow一样，确定性更高。在这样一个流程中，可以标明在这个环节在做什么（dag_name、title）、执行流程（actions）、前后的依赖项（depends）、执行的工具或者 agent（"name": "get_total_data"），以及工具所需要的入参（arguments）。

29. 增强ActionDAG生成和执行准确率在Reasoning节点中，我们会让LLM依次完成以下几个工作 : - ack：对用户任务的简单响应 - thought：对于本次任务的思考，LLM需要基于上下文进行以下几个方面的思考 - 理解用户的需求 - 思考使用的Tool/Agent - 参数的完整性校验 - 对于历史Action的反思和总结 - 判断是否满足用户的需求 - action_dag: 一个可执行的动作有向图 - todo：待办事件列表 - final_output：最终的回答 - interrupt：当前的任务无法执行，需要向用户进一步询问

30. 定义语法糖，实现参数传递的引用引用是DagAct环节中十分重要的一环，如果没有引用，那么LLM将会看到Node的所有输出，并且需要输出Node的所有输入，整个效果将会降级到ReAct模式

31. Reasoning和Acting解耦 Reasoning 节点负责生成待执行的actionDAG list。 Acting节点中，我们将会基于LLM生成的执行计划进行执行。首先我们会基于 ActionDag生成一个LangGraph执行图。该图的每一个Node就是ActionDag中的每一个Action，而每一个Edge就是由depends参数来制定的。

32. DAGAct总结引入全局规划通过TODO list提供全局规划和任务，当前已经完成的任务。明确当前所处的阶段，和需要做的任务。避免多轮task执行中遗忘。 think-tool增强执行准确率语法糖避免参数值传递增强推理：定义thought、可行性分析、DAG生成采取参数语法糖，避免在多轮tool call中LLM复述 &校验、反思DAG等多个环节的拆分。封装 think - 观测数据或变量，提高参数引用准确率，也提高 tool，根据问题难易自动选择。 LLM的输出效率 DAG约束：如主要步骤、结束条件、输出描述和条件分支等，提高问题解决的效率和准确性。

33. 二、ContextEngineering：管理好你的context 1. tool result的总结、保存、检索 2. 超过model limit的context 压缩 3. message list格式的重组和改写 4. subagent作为context 的隔离

34. Context Engineering 实践的4 个阶段总结策略构建文件系统不同的记忆策略 DAG Context Offloading 直接截断结果总结 RAG 检索 rule+RAG 1. 底层支撑：FileSystem（内存文件操作层） - 文件读写： - 目录判断： - 文本检索： - 状态持久化： 2. 上层交互：TextEditorTool（长文本操作工具层）短期记忆层：存储最近的对话消息，包括用户输入、工具调用结果和系统响应。中期记忆层：存储经过压缩的对话历史，作为短期记忆的补充。长期记忆层：长文本保存、跨 session检索。重组 message list。保留DAG 中必要的内容，丢弃不必要的中间环节（thought\plan\dag \todolist ）、 dag output、ai- message(to user) tool result的处理 filesystem + text- editor 短-中-长memory 机制重组 message list

35. 三、构建分析Agent，确定工作流程 1 定义Prompt 角色、目标、工作流程、输入输出要求、约束工作流程示例： 1. 查告警上下文 2. 进行RCA 分析 3. 处理建议执行 4. 进一步分析Logid 5. 总结输出 2 定义model 、执行架构 model 相关： - model - name - temperature 等执行架构： - Plan & executor 3 定义subagent 、 tools agents: - metrics_agent - dashboard_agent tools: - alarm.get_alarm_data - lark.file.fetcher 4 定义输入和输出 context_schema: t- ype: object - properties: alert_group_id: type: string output_schema: null

36. 自定义分析示例

37. 05 总结与展望

38. 经验总结 01 架构演进的经验字节 SRE Agent 在从 0 到 1 的搭建过程中，经历了架构从 ReAct 到 CodeAct，最终到 DagAct 的迭代升级，积累了丰富的架构演进经验，为后续的技术发展提供了宝贵的借鉴。 02 降噪与排障的落地通过引入基于 LLM 的 “告警值守 SRE Agent”，实现了告警降噪和自定义排障，将 RD 和 SRE 从繁琐的运维工作中解放出来，助力他们抢回 50% 的值班时间，目前在部分业务落地取得了不错的效果。 03 知识沉淀与学习建立了有效的知识沉淀和学习机制，将历史处理记录、专家经验以及成功案例存储在知识引擎中，实现了 “一次执行，多次复用” 的学习效果，提高了团队的整体运维能力。

39. 未来展望

40. 未来展望

41. 未来展望

42.

43. 谢谢大家大模型正在重新定义软件 Large Language Model Is Redefining The Software