lucasperrier/OpsSage

GitHub: lucasperrier/OpsSage

OpsSage 是一个面向生产环境的云原生事件智能平台,通过治理化知识摄取、有据检索和置信度感知升级机制,实现事件响应自动化和运维辅助决策。

Stars: 0 | Forks: 0

# OpsSage **云原生事件智能平台** OpsSage 是一个面向生产环境的 AI 平台,旨在用于事件响应和支持运营。它的设计目标是摄取运维知识,检索有据可依的证据,协助进行分流(Triage)和下一步操作生成,并以明确的置信度感知升级机制,将不确定的案例路由给人工处理。 预期的最终成果是一个看起来和表现得像真正的云原生 ML 平台的系统:受治理、可测试、可部署、可复现且可观测。 ## OpsSage 是什么 OpsSage 旨在支持五种主要工作流: 1. **事件接入** - 摄取事件工单、支持请求和告警摘要 - 预测严重程度和可能的归属团队 - 生成简洁的结构化摘要 - 推荐下一步行动 - 返回置信度和明确的 `escalate_to_human` 标志 2. **基于检索的辅助** - 使用有据可依的证据回答运维问题 - 引用 Runbook、复盘报告、KB 文章和历史工单 - 避免不受支持的自由形式回答 3. **人机协同审查** - 将低置信度或依据薄弱的案例标记为 `needs_review` - 返回顶级证据和理由,而不是虚张声势 - 倾向于安全弃权,而非虚假自信 4. **管理员摄取和重新索引** - 根据受治理的数据契约验证文档 - 对语料库工件进行去重和版本控制 - 重新索引并回滚到先前的索引版本 - 记录摄取和索引工件以保证可审计性 5. **发布评估和晋升** - 在晋升前评估检索、分流、依据 grounding 和延迟 - 应用基于阈值的发布门控 - 防止不支持回答率或运维行为的倒退 ## 产品目标 该项目有意强调 **系统设计而非模型新颖性**。 OpsSage 不仅仅是一个模型演示。该平台旨在展示以下方面的责任感: - 受治理的摄取 - 检索和证据 grounding - 模块化推理任务 - 发布级评估 - 生产级 API 设计 - 工作流编排 - 基于基础设施即代码 的 AWS 部署 - 可观测性、告警和运维安全 ## 核心能力 ### 受治理的摄取 OpsSage 将摄取: - 事件工单 - 支持对话 - Runbook - 复盘报告 - KB 文章 - 服务目录和团队元数据 - 遥测摘要和运维元数据 每个对象应: - 经过 schema 验证 - 可追溯血缘 - 经过哈希去重 - 在语料库清单中进行版本控制 - 如果无效则干净地拒绝 ### 作为一等子系统的检索 OpsSage 将支持运维检索,而非通用 RAG。 示例: - 工单检索 Runbook 和类似的过往事件 - 支持问题检索 KB 文章和历史解决方案 - 路由使用服务和所有权元数据 - 生成的下一步操作引用支持证据 检索将支持: - 按文档类型分块 - 元数据感知拆分 - 向量索引 - 可选混合检索 - 按服务、来源、团队和文档类型的元数据过滤 - 索引版本控制和回滚 ### 模块化推理 推理将被分解为明确的任务: - 严重程度分类 - 路由 / 团队预测 - 摘要 - 有依据的下一步生成 - 弃权 / 升级决策 这使系统保持可测试和可读性。 ### 发布级评估 OpsSage 将使用评估来决定候选发布是否可晋升。 评估领域包括: - 严重程度和路由性能 - 检索质量和覆盖率 - Grounding 和引用支持 - 弃权质量和选择性准确性 - 延迟、吞吐量和失败率 - 与先前批准版本的回归对比 ### 生产级 API 应用 API 层将公开: - 面向用户的分流和辅助端点 - 用于摄取和重新索引的管理操作 - 健康和就绪检查 - 指标 - 请求追踪和结构化日志 - 敏感操作的速率限制和认证 ## 目标架构 该仓库旨在演变为五个主要模块/服务: ### 1. 摄取服务 职责: - 解析原始文档 - 验证 schema - 对工件去重 - 分块并丰富元数据 - 分配血缘 ID - 编写工件清单 ### 2. 检索和索引服务 职责: - 构建 Embedding - 管理向量索引 - 支持元数据过滤 - 版本化索引 - 支持回滚到先前的索引版本 ### 3. 推理服务 职责: - 严重程度分类 - 路由预测 - 摘要 - 有依据的下一步生成 - 弃权策略 ### 4. 评估服务 职责: - 离线评估 - 回归评估 - 发布门控 - 基准报告生成 ### 5. API 应用 职责: - 公共/用户端点 - 管理端点 - 认证 - 速率限制 - 追踪 - 请求日志 ## 云目标 预期的 AWS 部署目标是: - **S3** 用于原始文档、清单、模型工件和评估工件 - **RDS PostgreSQL** 用于元数据和工作流状态 - **OpenSearch** 或 **pgvector** 用于检索 - **ECS Fargate** 用于服务部署 - **ECR** 用于容器镜像 - **CloudWatch** 用于日志、指标、仪表板和告警 - **GitHub Actions** 用于 CI/CD - 可选 **EventBridge + Lambda** 或 **Prefect** 用于调度工作流 这使项目保持面向生产,而不会使平台过于复杂。 ## 建议的仓库结构 ``` opssage/ README.md roadmap.md Makefile pyproject.toml .github/workflows/ infra/ terraform/ envs/dev/ envs/prod/ modules/ configs/ data/ retrieval/ training/ inference/ evaluation/ deployment/ data_contracts/ ticket.schema.json runbook.schema.json postmortem.schema.json kb_doc.schema.json src/ opssage/ api/ ingestion/ retrieval/ training/ inference/ evaluation/ orchestration/ storage/ monitoring/ utils/ scripts/ tests/ unit/ integration/ smoke/ release/ docs/ architecture/ runbooks/ reports/ examples/ notebooks/ ``` ## 设计原则 为了保持项目的可信度,OpsSage 应该明确做到: - **受治理** — 明确的 schema、清单、血缘、可审计性 - **可测试** — 模块化服务、契约、回归套件、发布门控 - **可部署** — 容器、CI/CD、基础设施即代码、环境隔离 - **可复现** — 版本化的数据集、索引、模型工件、报告 - **可观测** — 日志、指标、追踪、告警、仪表板 目标是避免“作品集表演”,而是构建一个看起来像工程系统项目的东西。 ## 更详细的受支持工作流 ### 事件接入 **输入** - 事件工单 - 支持请求 - 告警摘要 - 可选服务/团队元数据 **输出** - 严重程度预测 - 路由/团队预测 - 简洁的结构化摘要 - 推荐的下一步行动 - 置信度分数 - `escalate_to_human` 标志 ### 基于检索的辅助 **输入** - 事件或支持查询 **输出** - 带有引用的可靠回答,引用指向 Runbook、复盘报告、KB 文档或先前工单 ### 人工审查流程 当置信度低或证据弱时,系统应: - 将请求标记为 `needs_review` - 返回顶级证据和理由 - 避免过度自信的回答 ### 管理员摄取和重新索引 管理工作流应支持: - 文档验证 - 语料库版本控制 - 重新索引 - 工件日志记录 - 回滚到先前的索引版本 ### 发布评估 在晋升发布之前: - 检索指标必须通过阈值 - 分流和路由指标必须通过阈值 - 延迟必须保持在界限以下 - 不支持回答率不得倒退 ## 该项目优化的目标 OpsSage 旨在成为 ML 系统、平台工程和生产 AI 职位的强有力作品集工件。 它旨在展示: - 应用 LLM 系统设计 - 有依据的检索和运维 AI - 安全弃权和人工升级 - 发布治理和回归测试 - AWS 部署和基础设施所有权 - 可观测性和生产运维意识 ## 建议的构建顺序 为了保持项目的连贯性,建议的顺序是: 1. 冻结基线 2. 正式化数据契约 3. 添加检索和索引 4. 将推理重构为明确的任务 5. 围绕发布决策重建评估 6. 加固 API 7. 使用 Terraform 部署到 AWS 8. 添加监控并完善文档 这避免了在系统契约稳定之前进行表面的云工作。 ## 完成的定义 当以下所有条件都成立时,OpsSage 即被视为完成: - 文档受治理、版本化且可复现 - 检索是一流的且可衡量 - 分流、路由和有依据的下一步生成端到端工作 - 低置信度案例安全升级 - 发布报告控制部署决策 - 系统通过 Terraform 管理的基础设施部署在 AWS 上 - 日志、指标、仪表板和告警存在 - CI/CD 构建并部署平台 - 架构和评估文档清晰完整 - 仓库在五分钟内传达出云原生 ML 系统所有权 ## 里程碑 路线图的一个实用的八里程碑版本是: 1. 冻结基线并编写迁移规范 2. 正式化数据契约和受治理的摄取 3. 添加具有元数据感知 grounding 的检索/索引 4. 将推理重构为明确的任务加弃权 5. 构建发布级评估和回归门控 6. 加固 FastAPI 服务和管理工作流 7. 使用 Terraform 和 CI/CD 部署到 AWS 8. 添加监控、告警、仪表板和最终文档 ## 招聘叙事 该项目预期的简历框架是: - 构建并部署了一个基于 AWS 的 AI 平台,用于事件和支持工作流,结合了严重程度分类、路由、基于检索的响应生成以及基于置信度的人工升级。 - 扩展了受治理的运维语料库管道,包含版本化清单、schema 验证、去重、元数据感知分块,以及在 Runbook、复盘报告、KB 文章和先前工单上的可复现向量索引。 - 设计了发布级评估,涵盖路由准确性、检索质量、grounding、弃权、延迟和回归门控;标准化基准报告以管理模型和索引晋升。 - 使用 FastAPI、Docker、Terraform、CI/CD、结构化日志、云监控、调度重新索引/评估工作流和告警实现了生产化,以确保运维可靠性。 ## 状态 本仓库目前处于 **概念和规划** 阶段。 第一个实现目标是创建一个干净、面向生产的基础,而不是积累互不关联的实验。 ## 下一步 最好的即时后续工作是: 1. 创建初始仓库结构 2. 添加 `pyproject.toml`、`Makefile` 和基础包布局 3. 为第一个文档类型编写数据契约 4. 搭建带有健康端点的最小 FastAPI 应用 5. 为开发基础设施添加 Terraform 骨架 6. 添加用于 linting、类型检查和测试的 CI 检查 如果您愿意,下一步可以将此计划转化为带有第一个实现脚手架的实际启动仓库结构。
标签:AIOps, Incident Response, IT服务管理, LLM Ops, MLOps, SRE工具, 人工智能平台, 人机协同, 企业级AI, 分级上报, 大语言模型应用, 工单分诊, 故障排查, 故障摘要, 文档问答, 智能化运维, 检索增强生成, 置信度评估, 自动化运维, 证据溯源, 请求拦截, 运维支持, 运维知识库, 运维自动化, 逆向工具, 风险控制