78 lines
5.6 KiB
Markdown
78 lines
5.6 KiB
Markdown
# OPS 首期交付 TODO
|
||
|
||
来源：`/autoplan` 审查 `docs/integrated-ops-platform-blueprint-design.md`。
|
||
|
||
## P0
|
||
|
||
- [x] 处理 `.gitignore` 中忽略 `docs/` 的规则。
|
||
- 原因：当前需求、蓝图和后续验收矩阵都在 `docs/`，但 `.gitignore` 忽略该目录，交付文档无法正常纳入版本控制。
|
||
- 验收：`git status --short --ignored` 能清楚区分应跟踪文档与不应跟踪文件；必要时移除 `docs/` 忽略规则或显式强制添加交付文档。
|
||
|
||
- [x] 忽略 Git 远程地址明文凭据整改，不作为当前交付阻塞项。
|
||
- 原因：用户已明确要求忽略该 P0；该项不再阻塞首期文档、设计和后续实现准备。
|
||
- 风险：远程地址中如果保留账号、密码或 Token，仍存在泄露风险；后续推送、共享仓库或交付前建议重新评估。
|
||
- 验收：本文档已记录用户决策；不在当前任务中修改 Git 远程地址。
|
||
|
||
- [x] 编写 `docs/首期验收矩阵.md`。
|
||
- 原因：当前蓝图已经映射 33 条 OPS 需求，但缺少逐项演示路径、数据准备、通过标准和证据要求。
|
||
- 验收：每个 OPS 编号都有阶段归属、演示脚本、截图/录像证据、通过标准。
|
||
- 产物：`docs/首期验收矩阵.md`。
|
||
|
||
- [x] 明确第 1 阶段的数据模型与状态机。
|
||
- 原因：资源、指标、原始事件、告警、事件、工单、通知、审计是闭环主干，必须先稳定。
|
||
- 验收：文档中包含 ER 关系、状态枚举、非法状态迁移、审计字段。
|
||
- 产物：`docs/首期数据模型与状态机.md`。
|
||
|
||
- [x] 补齐第 1 阶段 UI 信息架构和状态覆盖。
|
||
- 原因：当前蓝图列出了页面，但未指定每个页面的加载、空态、错误、成功、部分成功、无权限状态。
|
||
- 验收：首页、综合监控、告警中心、工单、报表、大屏、权限页都有状态表。
|
||
- 产物：`docs/首期UI状态覆盖.md`。
|
||
|
||
## P1
|
||
|
||
- [x] 定义采集失败、Trap/Syslog 解析失败、通知失败、派单失败的错误与救援策略。
|
||
- 原因：一体化运维平台自身故障不能静默，否则验收时无法证明平台可靠性。
|
||
- 验收：每类失败都有重试、降级、用户提示、日志、审计和测试要求。
|
||
- 产物：`docs/P1故障救援策略.md`。
|
||
|
||
- [x] 为第 1 阶段建立后端与前端测试计划。
|
||
- 原因：当前仓库尚无实际 `server/`、`web/` 工程，测试策略需要先指导实现。
|
||
- 验收：后端包含单元、接口、SQLite 内存库测试；前端包含类型检查、状态渲染和核心 E2E。
|
||
- 产物：`docs/P1测试计划.md`。
|
||
|
||
- [x] 使用 gstack 工程评审口径梳理首期架构、数据模型和接口设计。
|
||
- 原因：P0/P1 文档已形成验收、状态机、UI 状态、救援和测试计划，但后续初始化 `server/`、`web/` 前还需要一份可编码的模块边界和 REST API 规格。
|
||
- 验收：文档包含后端/前端模块划分、核心数据流、数据模型、统一响应、错误码、API 路由、前端状态映射和实施顺序。
|
||
- 产物：`docs/首期项目架构数据模型与接口设计.md`。
|
||
|
||
- [x] 区分本地开发命令和验收部署说明。
|
||
- 原因：本地开发和调试使用 Windows PowerShell；会议已确认验收部署需要面向 Linux 与麒麟系统，模板 README 不能直接成为交付文档。
|
||
- 验收：实际 `server/`、`web/` 文档提供 Windows PowerShell 本地开发路径；`deploy/` 提供 Linux/麒麟部署、迁移、回滚和烟测说明，且不包含真实凭据。
|
||
- 产物：`docs/本地开发与验收部署说明.md`、`deploy/README.md`。
|
||
|
||
- [x] 完成 H3C/华三设备首批接入调研。
|
||
- 原因：会议确认现场设备以 H3C/华三为主，第 1 阶段应优先适配该品牌常见指标、接口状态和 Trap/Syslog 样例。
|
||
- 验收：明确首批设备型号、SNMP 版本、OID 清单、Trap 字典、Syslog 样例、账号权限和网络连通性。
|
||
- 产物：`docs/H3C华三首批接入调研.md`。
|
||
- 风险：仓库现有资料未提供现场具体型号、SNMP 版本、真实 Trap/Syslog 样例和账号权限；文档已提供首批接入基线和现场确认表，正式验收前必须由院方或现场工程师补齐。
|
||
|
||
- [x] 完成国产/国内生态时序数据库选型验证。
|
||
- 原因：高频指标和采集样本不应全部压入 PostgreSQL，需要选型 TDengine、Apache IoTDB、openGemini 或其他合适产品。
|
||
- 验收：形成选型记录，覆盖 Linux/麒麟部署、Go 连接方式、批量写入、范围查询、聚合、降采样、保留策略、备份恢复和授权风险。
|
||
- 产物：`docs/国产时序数据库选型验证.md`。
|
||
- 决策：采用 TDengine 开源版；正式部署前继续验证 AGPL 合规、麒麟兼容性、备份恢复和是否需要企业版支持。
|
||
|
||
## P2
|
||
|
||
- [ ] 规划拓扑、IPAM、机柜、动环进入第 2 阶段的导入和联动策略。
|
||
- 原因：这些能力是完整蓝图必备，但不应阻塞第 1 阶段告警闭环。
|
||
- 验收：每个能力明确数据来源、导入方式、与资源/告警的关联点。
|
||
|
||
- [ ] 设计外包 3D 机房前端所需后端接口。
|
||
- 原因：会议确认 3D 机房前端已外包，OPS 侧只需要提供数据中心、机房、机柜、U 位、设备和告警状态等后端接口。
|
||
- 验收：接口文档明确字段、刷新频率、权限控制、状态编码、样例响应和错误码。
|
||
|
||
- [ ] 设计告警质量评分和规则优化建议的第 3 阶段路线。
|
||
- 原因：第 3 阶段要从可处置走向可优化，需要沉淀告警噪声、误报、处理时长等指标。
|
||
- 验收：定义告警质量指标、统计口径、规则建议来源和人工确认边界。
|