Agent Skills
返回列表
🔒

OpenSRE 生产事件调查与补救

IT 运维与安全 更新于 2026.08.29

将以下提示词粘贴到你的 AI 对话框中：

请根据 https://skillhub.cn/install/skillhub.md，安装 @user_3c6cb52e/investigate-production-incidents-across-observability-signals-and-draft-next-remediation-steps-with-opensre

技能介绍

它解决什么问题

一次生产故障发生时，日志在日志平台里，指标在时序库里，调用链散落在 tracing 系统里，runbook 又存在另一个知识库里。人肉排查时需要在多个界面之间来回切换，上下文是碎的；而 LLM 驱动的 SRE agent 如果没有结构化的调查闭环，也很容易直接跳到"我觉得根因是 X"这种猜测。这个技能把调查流程先固定下来：在任何人（或 agent）下结论之前，先把多路信号汇聚到一个调查循环里。

它是怎么工作的

核心能力

  • 多信号汇聚：把 logs、metrics、traces 三类可观测性信号拉进同一个 incident 上下文，而不是分别查看
  • runbook 注入：把已有的 runbook 上下文带入调查过程，让排查步骤和既有预案挂钩，约束假设空间
  • 工具连接：基于 OpenSRE 框架，可接入你已在运行的 60+ 工具，也能自定义调查 workflow
  • 草拟补救步骤：调查结束后产出下一步补救动作的草案，交由人工 operator 评审执行

关键步骤

  1. 按 incident 时间窗口拉取相关日志、指标与追踪数据
  2. 绑定 runbook 与 incident 上下文，确定调查范围
  3. 由 OpenSRE 按定义的 workflow 逐步调查，过程中调用已连接的基础设施工具
  4. 输出根因分析结论与下一步补救措施草案

适用边界与注意点

  • 需要预先装好 OpenSRE，并具备目标可观测性栈、incident 上下文、受支持基础设施的凭据以及终端访问权限
  • 需要配置 LLM_PROVIDER 及对应 API key，并以 Python/FastAPI 运行时（如 Dockerfile 或托管应用宿主）方式部署
  • 输出是补救措施的草稿，定位是给人工 operator 参考，而不是无人值守的自动执行
  • 上游文档见 https://opensre.com，安装与部署细节以仓库说明为准

使用场景

  • 线上服务告警触发后，需要在日志、指标、追踪多路信号间拉齐时间窗口内的数据，拼出完整事件上下文。
  • 排查跨微服务调用异常时，需要把 traces 与各服务日志关联，定位是哪一跳先出错。
  • 事件处理到一半，需要对照已有 runbook 验证当前假设，避免重复走历史预案里已排除的路径。
  • 根因分析收尾阶段，需要产出一份下一步补救动作的可评审草稿，供值班 operator 决策执行。

适合人员

  • 值班 SRE：需要在告警触发后快速拉齐多路信号，缩短人工切屏排查的时间。
  • Incident commander：需要在事件推进中对照 runbook 约束假设空间，指挥团队下一步动作。
  • 平台工程师：需要把 OpenSRE 接到团队已有的日志、指标、追踪工具上，固化一套调查 workflow。
  • 后端开发：需要在定位到嫌疑服务后，拿到一份可执行的补救措施草稿作为排查收尾。