从个人经验到组织资产：小米 AI for SRE 闭环实践与资产沉淀

导语

在亿级日活与海量微服务的业务规模下，SRE 团队长期处于告警多、Oncall 杂、应急恢复慢的高压状态。随着大模型的引入，我们拥有了更强大的工具，但 AIOps 的真正瓶颈并未迎刃而解——模型能力在提升，但运行环境与工程化配套却相对滞后。

小米在 AIOps 领域的探索得出一个核心认知：AIOps 的瓶颈不在模型，而在环境；SRE 的核心资产不在脚本，而在大脑。 只有将 SRE 散落在个人大脑中的隐性知识、经验与判断逻辑进行工程化提取，转化为组织资产，才能让 AI 真正在运维场景中闭环。本文将系统拆解小米在 SRE 知识资产沉淀、AIOps 平台架构及落地实践中的思考与经验。

核心问题与挑战

在推进 AI for SRE 的过程中，我们面临来自业务本体与工程落地的双重挑战：

• 业务痛点显著：业务规模大、形态广，直接导致告警风暴频发、Oncall 信息繁杂、应急恢复耗时，SRE 疲于奔命。
• 智能场景碎片化：我们打磨了大量的工具（手脚），却忽视了调度策略（大脑）。AI 在面对故障时，不知道在什么情况下、以什么顺序调用何种工具，陷入“有工具无策略”的困局。
• 隐性知识未工程化：真正的排障经验与判断逻辑散落在资深 SRE 的大脑中，未转化为可被机器读取与执行的工程化资产。
• 确定性与不确定性的矛盾：SRE 工作要求极高的确定性与安全性，而大模型天生具有不确定性与幻觉风险，两者存在根本性冲突。
• 前端技术债：流式输出与复杂事件机制的结合，导致前端交互层技术债严重，影响平台可用性。

方案与实践

为打破上述困局，我们将重心从“堆砌工具”转向“注入灵魂”，构建了以知识资产为核心的 AIOps 闭环体系。

构建三位一体的 SRE 资产体系

我们将 SRE 资产拆解为技能、知识库与记忆三个核心主体，并统一纳管。

1. Skills（技能）：规范与安全并重的原子能力

• 统一规范：建立 Skills 创建规范，通过工具化手段将规范落地，采用 AI 驱动生成与自动化验证，确保技能质量。
• 意图捕获与安全扫描：明确 Skills 的意图边界，并在上线前执行敏感信息扫描（如云服务凭证、DB 连接串等），防止越权与泄露。
• 技能托管：实现 Skills 的全生命周期托管，确保可观测、可审计。

2. Knowledge Base（知识库）：生产消费解耦，宁缺毋滥

• 解耦设计：知识库作为独立基础服务建设，生产与消费解耦。基于飞书文档快速复用历史沉淀，只抓取入库不改写原文档。
• 质量红线：坚持“宁缺毋滥”原则，保证入库知识的准确性，避免错误知识污染 AI 决策。
• 闭环管理：提供知识未命中分析能力，决定是忽略还是补录，形成知识迭代闭环。

3. Memory（记忆）：业务隔离的上下文信息系统

• 架构演进：记忆系统从早期的 MySQL/纯文本，演进至 LLM 抽取结合向量数据库的阶段，提升语义检索能力。
• 多维隔离：按业务和用户维度进行数据边界与权限隔离，确保多租户场景下的信息安全与上下文纯净。
• 三层信息架构：构建以业务为维度的“上下文（单次 Session）- 记忆（历史沉淀）- 知识（全局规范）”信息系统。

AIOps 平台：企业级管控与交互收敛

资产体系需要坚实的平台底座来承载。小米 AIOps 平台的核心定位是企业级管控，而非单纯的脚本执行器。

• 架构选型折中：在手写逻辑、纯函数调用与完全自主 Agent 之间，我们采用了 LangGraph/eino 等 Agent 框架的折中方案，平衡编排灵活性与开发效率。
• 全局可观测与安全兜底：平台对 Agent 执行链路实现全局可观测，并在关键执行节点设置人工审批（如 Oncall 入口审批前的人工确认），以安全兜底化解大模型不确定性带来的风险。
• Agent 机制：提供通用默认 Agent 应对日常对话，同时支持自定义 Agent 满足特定业务流编排需求。

落地案例验证

• Redis 告警自动分析：通过自定义 Agent 监听目标告警，自动获取集群信息并关联分析，大幅缓解 SRE 告警焦虑，改善睡眠质量。
• 群内 Oncall 与知识闭环：结合知识体系在群内自动响应 Oncall，并在处理完成后抽取经验落地知识库，实现从“用知识”到“长知识”的闭环。
• 容器单点异常排查：针对个别 Pod 异常，Agent 交互式排查并执行重建，平台保留完整历史执行记录与报告，供事后审计与复盘。
• SRE 综合查询：覆盖域名治理查询、产品线资源利用率分析等运营类场景，验证了 Agent 在非紧急但繁琐的数据检索场景中的价值。

原则/方法论沉淀

在工程落地过程中，我们提炼了以下避坑原则：

1. 工程化重点是融合隐性知识：SRE 的经验与判断逻辑是核心，工具只是载体，必须将隐性知识显性化、机器可读化。
2. 不要为低质模型过度优化架构：工程壁垒在模型之外，架构设计应保持前瞻性，模型会迭代，但糟糕的架构债很难还。
3. 能力越强，交互越收敛：交互设计应从复杂的表单与界面回归自然语言对话，将复杂性下沉到 Agent 编排层。
4. 前后端事件协议需先行：在流式交互场景下，前后端的事件协议必须在架构设计阶段明确定义，否则后期技术债极重。
5. 知识库宁缺毋滥：一条错误知识带来的破坏力远大于知识缺失，入库质量是生命线。

总结与行动建议

AI 正在驱动 SRE 从脚本工具向 Agent 工作流演进，知识工程也从“让人能找到”转向“让机器能找到”。未来，AIOps 架构必将向数据驱动的自进化飞轮发展，让数据反哺知识资产，从优化走向自进化，从可用走向可度量。

给工程团队的建议：

• 立即启动 SRE 隐性知识的盘点与工程化抽取，优先沉淀高频故障场景的 SOP。
• 在引入大模型时，优先建设企业级管控平台，确保有安全兜底机制再放开执行权限。
• 重新审视前端交互，拥抱对话式交互，但务必在首日就定义好流式事件协议。

开放问题与延伸方向

1. Skills生命周期中的“意图捕获”和“自动化验证”具体是如何定义的，其通过率和拦截效果的基准数据是什么？
   （关联方案实践：关乎技能规范落地的实际效能度量）
2. Memory系统按业务和用户维度隔离，其数据边界和权限控制基准是如何在多租户复杂SRE场景中精确划定的？
   （关联方案实践：涉及记忆系统架构的安全与隔离细节）
3. 在SRE高确定性要求下，如何防范Agent编排中大模型幻觉或工具调用错位所引发的级联误操作风险？
   （关联核心挑战：直击确定性与不确定性矛盾的安全底线）
4. 将SRE隐性知识工程化并交由AI执行，如何解决知识老化问题，即当业务架构频繁变更时如何保证Skills和知识库不失效？
   （关联原则沉淀：对“宁缺毋滥”与知识闭环机制的极限施压）
5. 知识库建设遵循“宁缺毋滥”原则，是否会导致平台初期冷启动时知识覆盖不足，进而引发一线SRE对系统的信任危机？
   （关联原则沉淀：冷启动阶段的质量与覆盖率平衡难题）
6. 大模型的不确定性与SRE强确定性之间的矛盾，仅靠“企业级管控与安全兜底”是否足以消除一线SRE让渡控制权的抵触心理？
   （关联核心挑战：技术方案之外的组织与心理认同问题）
7. 交互设计从复杂界面回归对话并实现收敛，在实际告警风暴等高压场景中，带来了多大比例的Mean Time To Resolve效率提升？
   （关联方案实践：交互收敛带来的核心业务指标量化验证）
8. 除了基于飞书文档解析和向量数据库，是否考虑过引入知识图谱来增强SRE复杂故障关联推理的可解释性与准确性？
   （关联方案实践：知识库技术路线的扩展可能性）
9. Skills原子能力和自定义Agent的框架，能否横向迁移至研发侧（如CI/CD流水线排障），实现SRE与DevOps的智能协同？
   （关联总结展望：架构通用性与跨团队协同的延展）
10. 在迈向“数据驱动的自进化飞轮”过程中，当前最优先需要补齐的数据反馈闭环是哪一个环节，下一步验证重点是什么？
    （关联总结展望：自进化愿景下的落地优先级判定）