60 lines
2.1 KiB
Markdown
60 lines
2.1 KiB
Markdown
|
# AI-Ops 智能运维系统
|
|||
|
|
|
|||
|
|
> 立连桥（立交桥）平台的智能运维子系统，把从人工排查转为机器主导的实时保障。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 快速导航
|
|||
|
|
|
|||
|
|
| 文档 | 路径 | 说明 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 产品需求 | `prd/PRD.md` | 需求范围、AC、用户场景、上线策略 |
|
|||
|
|
| 竞品分析 | `prd/competitor-analysis.md` | 14 个竞品全景矩阵与差距分析 |
|
|||
|
|
| 高层设计 | `tech/HLD.md` | 架构总览、模块设计、数据模型、安全与性能 |
|
|||
|
|
| 接口设计 | `tech/INTERFACE.md` | 内部接口、REST API、WebSocket、错误码 |
|
|||
|
|
| 部署设计 | `tech/DEPLOYMENT.md` | 容器化部署、资源需求、灾备方案 |
|
|||
|
|
| 测试设计 | `tech/TEST_DESIGN.md` | 测试策略、用例矩阵、灰度门禁 |
|
|||
|
|
| 功能清单 | `specs/功能清单.md` | 按 Phase 划分的模块级功能清单 |
|
|||
|
|
| 竞品分析 | `specs/竞品分析.md` | 竞品差异化与市场定位 |
|
|||
|
|
| 测试用例 | `test/CASES.md` | 按 AC 编号的测试用例 |
|
|||
|
|
| 测试策略 | `test/STRATEGY.md` | 分层测试模型与工具链 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 技术栈
|
|||
|
|
|
|||
|
|
| 组件 | 选型 |
|
|||
|
|
|---|---|
|
|||
|
|
| 语言 | Go 1.22+ |
|
|||
|
|
| HTTP | 标准库 `net/http` + 自定义中间件 |
|
|||
|
|
| 数据库 | PostgreSQL 15+ (`jackc/pgx/v5`) |
|
|||
|
|
| 缓存 | Redis (`redis/go-redis/v9`) |
|
|||
|
|
| 配置 | YAML + Viper |
|
|||
|
|
| 时序库 | Prometheus / VictoriaMetrics |
|
|||
|
|
| 前端 | React 18+ + ECharts 5.x |
|
|||
|
|
| 测试 | Go testing + testify + miniredis + sqlmock |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 当前状态
|
|||
|
|
|
|||
|
|
- **门控结论**：HLD 与 TEST_DESIGN 均为 `REQUEST_CHANGES`，尚未达到进入开发的标准。
|
|||
|
|
- **待补齐项**：
|
|||
|
|
1. 错误码统一（已完成）
|
|||
|
|
2. 低级笔误修复（已完成）
|
|||
|
|
3. 数据库 migration SQL
|
|||
|
|
4. 项目骨架（go.mod、Makefile、Dockerfile）
|
|||
|
|
5. 功能清单裁剪（PM 越界细节）
|
|||
|
|
6. 门控行动项转化为可执行任务
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 与桥项目的关系
|
|||
|
|
|
|||
|
|
本系统是桥项目的延伸，技术体系保持一致：
|
|||
|
|
- 同样的分层架构（Repository + Service + Handler）
|
|||
|
|
- 同样的 Store 接口（含乐观锁版本控制）
|
|||
|
|
- 同样的独立运行 + 集成运行双模式
|
|||
|
|
- 同样的审计事件模型（与 supply-api/ 一致）
|
|||
|
|
- 数据库表前缀 `ai_ops_`，避免 schema 冲突
|