anshikapundeel/ai-ops-design

# ai-ops-design 这是一份关于 **AIOps 平台** 的设计文档 —— 一个面向中型生产基础设施（10–1000 个服务）的 AI 增强事件响应与可观测性平台。 本仓库**仅包含文档**，不包含任何代码。其目标是从端到端全面阐述一个生产级 AIOps 平台的设计：包括数据流、故障模式、扩展策略、成本模型、安全威胁模型，以及客观分析 LLM 在哪些方面能发挥作用，在哪些方面则不能。 平台本身是在其他几个仓库中实现的；本仓库提供了将它们串联起来的系统级视图。如果某个子系统已有相应的代码实现，文档中会提供相关链接。 ## 本文档存在的意义 大多数已公开的 AIOps 设计往往落入以下两种故障模式之一： - **供应商营销图表** —— 在每个组件框图上都贴上 "AI"、"ML" 和 "预测性分析" 的标签；缺乏具体的数据流；没有故障模型；也不讨论成本。 - **玩具级演示** —— 仅仅是在一个 notebook 中针对某条日志调用 LLM，然后就宣称解决了事件响应问题。 真正的生产级 AIOps 平台在极大程度上*并非*依赖 AI。AI 层在技术栈顶端提供了约 20% 的核心价值；而其余的 80% 则是平凡却至关重要的基础设施 —— 可靠的数据接入、结构化的关联分析、持久化的存储、谨慎的故障处理机制以及合理的 UX。 本文档力求客观地看待这一比例，并诚实地探讨系统的哪些部分真正受益于 LLM，而哪些部分使用规则引擎（rule-engine）能处理得更好。 ## 高层架构概览  共分为两个平面（plane）的八个组件： **数据平面**（Data plane，全时运行、低延迟、确定性）： 1. **遥测收集器（Telemetry collectors）** —— 指标（metrics）、日志（logs）、链路追踪（traces）、硬件事件 2. **存储层（Storage tier）** —— 时间序列数据库（time-series DB）、日志存储（log store）、链路追踪存储（trace store） 3. **告警管理器（Alert manager）** —— 基于阈值/异常规则触发告警 4. **关联引擎（Correlation engine）** —— 基于规则、确定性的；用于生成结构化的分析结果 **智能平面**（Intelligence plane，尽力而为、异步、咨询性质）： 5. **事件叙述器（Incident narrator）** —— 利用 LLM 将分析结果转化为人类易读的事件报告 6. **历史事件检索（Past-incident retrieval）** —— 针对过往事件的向量相似度检索 7. **部署风险分析器（Deployment risk analyzer）** —— 规则引擎 + LLM，用于评估每次发布的风险 8. **回归检测器（Regression detector）** —— 将当前性能与基线进行对比；标记性能漂移 这种架构划分是刻意为之的：**数据平面的运行绝对不能依赖于智能平面**。如果 LLM 提供商的服务发生中断，事件依然会被触发、进行关联并得到路由分配。智能平面的作用仅在于提升报告的清晰度；它并不处于关键路径（critical path）上。 ## 如何阅读本仓库 请按顺序阅读。每篇文档大约需要 10 分钟。总计约 80 分钟。 | 序号 | 文档 | 涵盖内容 | |---|-----|----------------| | 1 | [系统概览](docs/01-system-overview.md) | 整个平台的全貌巡览，各组件间的交互关系，以及每个部分存在的原因 | | 2 | [事件流水线](docs/02-incident-pipeline.md) | 单个告警的生命周期：触发 → 分流 → 陈述 → 路由 → 解决 | | 3 | [数据流](docs/03-data-flow.md) | 数据的存储位置，保留层级，热/温/冷数据路径 | | 4 | [故障模式](docs/04-failure-modes.md) | 各种故障发生的时间点，以及平台如何实现优雅降级 | | 5 | [扩展策略](docs/05-scaling-strategy.md) | 各组件的独立扩展维度；每一层的系统瓶颈 | | 6 | [成本模型](docs/06-cost-model.md) | 在 10 / 100 / 1000 个服务规模下的粗略每月成本估算 | | 7 | [安全威胁模型](docs/07-security-threat-model.md) | 攻击者可能的行为；我们的防御范围；以及我们不设防的领域 | | 8 | [LLM 集成](docs/08-llm-integration.md) | LLM 能增值的领域、无法发挥作用的环节，以及必须重视的故障模式 | ## 参考实现 部分子系统已作为独立仓库存在。以下链接展示了从设计到代码的对应关系： | 设计中的子系统 | 参考实现 | |---|---| | 硬件遥测收集器 | [redfish-exporter](https://github.com/anshikapundeel/redfish-exporter) —— 针对 DMTF Redfish BMC 的 Prometheus exporter | | 内核调度器遥测 | [sched-trace](https://github.com/anshikapundeel/sched-trace) —— 用于分析 CPU 调度器尾延迟的 eBPF/bpftrace 工具包 | | 分布式链路追踪收集器 | [flow-trace](https://github.com/anshikapundeel/flow-trace) —— 支持 OTLP/HTTP-JSON 接入、分片环形缓冲区（ring buffer），内置 UI | | 关联引擎 | [perf-advisor](https://github.com/anshikapundeel/perf-advisor) —— 基于规则的 Linux 性能分析器，带有可选的 LLM 钩子 | | 性能审计工具包 | [linux-perf-toolkit](https://github.com/anshikapundeel/linux-perf-toolkit), [pg-perf-toolkit](https://github.com/anshikapundeel/pg-perf-toolkit) | 本文档介绍的子系统中，有三个**尚未实现**： - **事件叙述器 + 历史事件检索** —— 设计方案请参阅 [docs/02-incident-pipeline.md](docs/02-incident-pipeline.md)。 计划命名为 `incident-pilot`。 - **部署风险分析器** —— 设计方案请参阅 [docs/08-llm-integration.md](docs/08-llm-integration.md)。 计划命名为 `deploy-risk`。 - **回归检测器** —— 设计方案请参阅 [docs/05-scaling-strategy.md](docs/05-scaling-strategy.md)。 计划命名为 `regression-radar`。 ## 本设计的适用范围与局限性 **适用范围（Is）：** - 一套连贯且带有明确主张的设计，专为 10–1000 个服务规模的 AIOps 平台而打造。 - 坦诚地探讨了哪些部分真正受益于 AI，而哪些部分作为确定性系统（deterministic systems）运行效果更好。 - 作为参考资料，明确了运行各个组件的实际成本、扩展方式、故障模式及其面临的威胁面。 **局限性（Isn't）：** - 这**不是**一套超大规模设计。在达到 10,000 个服务的规模时，需要考虑许多截然不同的因素（例如全面的多区域架构、用于链路追踪存储的 lambda 架构、每租户隔离等），而本文档并未妄图涵盖这些内容。 - 这**不是**针对特定供应商的推荐。当设计中提到“时间序列 DB”时，它可以指代 Prometheus *或* VictoriaMetrics *或* Mimir；该设计兼容上述任何一种工具。 - 这**不是**对新颖性的宣称。本文所采用的架构模式均广为人知；目标只是在一个地方清晰地将其记录下来，并客观地对待 LLM 的集成问题。 ## License MIT（适用于正文文本）。图表则采用 CC-BY-4.0 协议。

标签：AIOps, API集成, Docker镜像, 可观测性, 库, 应急响应, 架构设计, 用户代理, 系统设计, 自定义请求头, 运维平台