17 KiB
17 KiB
AI-Ops 智能运维系统 — 汇总审核报告与改进任务清单
审核日期：2026-05-11 审核角色：PM + TechLead + QA + Security（小龙统筹） 审核范围：PRD、HLD、INTERFACE、DEPLOYMENT、TEST_DESIGN、CASES、STRATEGY、功能清单、竞品分析、migration SQL
一、各角色审核结论
| 角色 | 总体评级 | 审核文档 | 核心判断 |
|---|---|---|---|
| PM | B | PRD.md, 功能清单.md, competitor-analysis.md | 用户旅程完整，AC 量化程度高，但存在范围冲突、工期估算失真、功能遗漏 |
| TechLead | B | HLD.md, INTERFACE.md, DEPLOYMENT.md, migration | 架构方向正确，但文档间接口严重不一致，ER 图与 migration 表缺失，IntegrationPlugin 未定义 |
| QA | C | TEST_DESIGN.md, CASES.md, STRATEGY.md | 测试策略框架较好，但负向用例大面积缺失、异常流程漏了 4 条、CI 零配置、性能压测无载体 |
| Security | C+ | HLD.md, INTERFACE.md, PRD.md, migration | 基础 RBAC 和脱敏有设计，但 LLM 特有风险未覆盖、审计防篡改触发器缺失、WebSocket/指标端点无鉴权 |
综合判断：当前设计不足以支撑进入开发，必须先修复 P0 问题，同步闭环 P1 问题，才能达到生产级交付标准。
二、P0 阻塞级问题（合计 16 项，已去重）
2.1 文档一致性（4 项）
| 编号 | 问题 | 影响 | 责任文档 | 修复方案 |
|---|---|---|---|---|
| D-P0-01 | 接口定义严重不一致：HLD 与 INTERFACE 中 gateway/supply-api/token-runtime 的路径、命名完全不同 | 开发团队无法确定真实契约，集成测试必败 | HLD §7, INTERFACE §2 | 召开接口对齐会，以 INTERFACE.md 为基准，生成 INTEGRATION_CONTRACT.md 作为唯一信源源 |
| D-P0-02 | ER 图与 migration 存在 4 张表缺失：ai_ops_events、ai_ops_notifys、ai_ops_configs、ai_ops_snapshots | 核心流程（通知、快照、配置版本）无法落地 | HLD §4.1 vs §4.2, migration | 确认是否需要：若需要则补齐表结构和 migration；若不需要则从 ER 图删除并说明替代方案 |
| D-P0-03 | 自愈动作类型命名不一致：HLD 用 restart_instance/switch_route，INTERFACE 用 restart_service/switch_provider | 存储序列化、API 校验、前端枚举全部混乱 | HLD §3.3, INTERFACE §1.3 | 统一命名，建议采用 snake_case 一致规范 |
| D-P0-04 | IntegrationPlugin 接口未定义：集成模式核心契约无 Go interface，无生命周期、注册方式 | 集成模式无法编码实现，CI 无法断点检查 | HLD §1.3, §3.2, §7, §10.2 | 在 INTERFACE.md 中增加 IntegrationPlugin Go interface 定义 |
2.2 需求完整性（2 项）
| 编号 | 问题 | 影响 | 责任文档 | 修复方案 |
|---|---|---|---|---|
| R-P0-01 | 范围冲突：供应商智能切换未在 PRD In Scope 明确纳入，但功能清单作为 Phase 3 核心模块（16+ 任务） | 与 Out of Scope “不做自动扩容决策”擦边，开发阶段极易产生范围争议 | PRD §3, 功能清单 3.4 | 明确纳入 In Scope 或移入 Out of Scope，若纳入则在 AC 中补充验收标准 |
| R-P0-02 | 自愈动作“重启实例”在功能清单中遗漏具体实现任务 | QA 无法验收该自愈动作 | PRD AC-6, 功能清单 3.1.2 | 补充重启实例实现任务（如调用 K8s API 或主机 agent） |
2.3 测试设计完整性（4 项）
| 编号 | 问题 | 影响 | 责任文档 | 修复方案 |
|---|---|---|---|---|
| T-P0-01 | AC 负向测试用例大面积缺失：12 个 AC 中至少 8 个无负向/异常输入用例 | 无法验证非法输入、边界越界、权限不足等场景，生产缺陷逃逸 | TEST_DESIGN.md, CASES.md | 为 AC-01/02/04/05/06/09/10/11 各补充至少 1 条负向用例 |
| T-P0-02 | CASES.md 遗漏异常流程 F-05~F-08（审计满盘、级联故障、数据库中断、看板超时） | 核心容灾与降级场景无测试用例实底 | CASES.md | 补充 TC-E5~E8 四条异常流程用例 |
| T-P0-03 | CI 集成零配置：STRATEGY.md 仅文字描述，无 workflow 文件、覆盖率阻断逻辑、失败通知机制 | 无法形成自动化质量门禁 | STRATEGY.md | 创建 .github/workflows/ci.yml，含覆盖率解析与阻断、失败通知 |
| T-P0-04 | 性能压测无执行载体：k6 脚本、环境规格、P99 计算方式、持续时间均未定义 | 性能基准无法复现和验证，灰度门禁无法判定 | TEST_DESIGN.md §9.1 | 创建 test/perf/ 目录，含 k6 脚本和环境规格文档 |
2.4 安全设计完整性（6 项）
| 编号 | 问题 | 影响 | 责任文档 | 修复方案 |
|---|---|---|---|---|
| S-P0-01 | LLM 特有风险未覆盖：提示注入、提示泄露、幻觉、模型偷取等 OWASP LLM Top 10 风险 | 系统集成 LLM/Gateway 后可能遭受提示攻击或数据泄露 | HLD §10.1 | 在威胁建模中增加 LLM 特有风险识别与缓解策略 |
| S-P0-02 | 审计表无防篡改触发器：migration 未创建 audit_log_prevent_update_delete 类似触发器 |
审计日志可被更新或删除，违背不可篡改要求 | migration | 补充 PostgreSQL 触发器或在应用层强制只追加 |
| S-P0-03 | Append-only 审计设计未在 HLD 中明确陈述：无“先写审计再执行业务”的 fail-closed 设计 | 业务操作失败时可能丢失审计记录，影响故障定责 | HLD §3.3 | 明确审计写入与业务执行的事务顺序和回滚机制 |
| S-P0-04 | WebSocket 接口无鉴权说明：告警数据为敏感生产信息 | 公网可能监听告警流，数据泄露风险 | INTERFACE §3.4 | 补充 JWT Token 鉴权说明，包括连接建立时的 token 校验 |
| S-P0-05 | SQL 注入防护无明确设计：HLD 未强制参数化/预编译查询 | 自定义规则、日志查询等功能存在 SQL 注入风险 | HLD §4 | 在 HLD 数据层设计中增加参数化查询强制要求 |
| S-P0-06 | /metrics 探针端点无鉴权说明：揭露生产指标给公网风险 | 攻击者可通过 /metrics 获取系统运行状态和敏感信息 | INTERFACE §3.2 | 限制内网 IP 访问或增加 API Key 鉴权 |
三、P1 重要级问题（合计 18 项，已去重）
3.1 需求与产品
| 编号 | 问题 | 责任文档 |
|---|---|---|
| R-P1-01 | 双重失败判定线：开发期 vs 上线后 30 天阈值不统一（20% vs 15%） | PRD §2, §8.3 |
| R-P1-02 | In Scope 使用“不仅仅包括于”留下范围蔓延口子 | PRD §3 In Scope |
| R-P1-03 | 通知渠道定义不一致：PRD 未含钉钉，功能清单出现钉钉 | PRD AC-4, 功能清单 2.3.2/3.4.3 |
| R-P1-04 | AC-7 “不可篡改”缺乏技术实现定义 | PRD AC-7 |
| R-P1-05 | AC-8 “操作前值有效”定义模糊 | PRD AC-8 |
| R-P1-06 | 级联故障回退（F-6）未在 AC 中体现 | PRD F-6, AC-6 |
| R-P1-07 | 容量预测算法缺可测试标准（“仅供参考”导致无法验收） | PRD AC-9 |
| R-P1-08 | 缺少 UI/UX 最低兼容性要求 | PRD 全文 |
| R-P1-09 | 角色权限矩阵过粗，缺少 API 级权限对照 | PRD AC-12, 功能清单 G1 |
3.2 技术设计
| 编号 | 问题 | 责任文档 |
|---|---|---|
| D-P1-05 | DEPLOYMENT “主备”与 active-active 多活逻辑矛盾 | DEPLOYMENT §1.1 vs §4.2 |
| D-P1-06 | Worker 执行 migration 存在多副本并发冲突风险 | DEPLOYMENT §3.2 |
| D-P1-07 | ai_ops_roles 表在 HLD 中提及但 migration 未定义 |
HLD §8.1 vs migration |
| D-P1-08 | 快照表缺失影响级联故障回退 | HLD §3.3 |
| D-P1-09 | 告警聚合状态机不完整（解除规则未定义） | HLD §5.2 |
| D-P1-10 | 规则评估性能扩展性未给出分片策略 | HLD §9.1/9.2 |
3.3 测试
| 编号 | 问题 | 责任文档 |
|---|---|---|
| T-P1-01 | 覆盖率门槛缺少验证机制 | STRATEGY.md |
| T-P1-02 | 混沌测试无具体用例设计 | STRATEGY.md, TEST_DESIGN.md |
| T-P1-03 | 测试数据管理策略缺关键细节 | STRATEGY.md |
| T-P1-04 | 灰度门禁缺自动化判定脚本 | TEST_DESIGN.md §5.2 |
| T-P1-05 | 安全扫描工具与阈值未指定 | STRATEGY.md |
| T-P1-06 | E2E 测试缺少详细场景设计 | STRATEGY.md, TEST_DESIGN.md |
3.4 安全
| 编号 | 问题 | 责任文档 |
|---|---|---|
| S-P1-01 | 敏感字段脱敏策略仅有文字，无具体实现（如密码替换、数据加密） | HLD §8 |
| S-P1-02 | 自愈引擎权限边界未明确（如何防止自愈动作被滥用去重启关键服务） | PRD AC-6, HLD §3.3 |
四、P2 改进建议（关键项）
| 编号 | 问题 | 建议 |
|---|---|---|
| R-P2-01 | 商业化闭环缺 ROI 量化模型 | 补充运维人力成本节省计算示例 |
| R-P2-02 | 发布策略缺量化门控标准 | 补充告警噪声率<10%、通知成功率>95% 等可量化条件 |
| R-P2-03 | 审计日志 90 天保留未评估存储成本 | 补充压缩/归档策略或存储成本上限 |
| D-P2-11 | 错误码排版混淆（4001 与 4101 相邻易混） | 重新分段排版或增加注释说明 |
| D-P2-12 | metrics 分区表仅有 DEFAULT，无按天分区和自动清理 | 引入 pg_partman 或应用层定时任务 |
| D-P2-14 | Graceful Shutdown 未说明 WebSocket 长连接关闭策略 | 补充 close frame + ack 等待机制 |
| D-P2-15 | 存储估算假设 Prometheus 每样本 8 bytes，与实际严重偏低 | 参考官方容量规划公式重新估算 |
| T-P2-01 | 用例编号风格不统一（TC-01-01 vs TC-1.1） | 统一为 TC-{AC}-{seq} |
| T-P2-02 | CASES.md TC-E2 漏掉 5xx 场景 | 补充 Webhook 5xx 测试 |
五、改进任务清单（按模块分类，已去重排序）
Phase 0 — 文档修复与对齐（开发前必须完成）
| 任务 ID | 任务名称 | 严重度 | 责任文档 | 估算工时 | 验收标准 |
|---|---|---|---|---|---|
| D0-01 | 召开接口对齐会，统一 gateway/supply-api/token-runtime 路径、命名、字段 | P0 | INTEGRATION_CONTRACT.md | 0.5d | 三份文档无接口冲突 |
| D0-02 | 补齐或删除 ER 图中 4 张缺失表（events/notifys/configs/snapshots） | P0 | HLD §4.2, migration | 0.5d | migration 与 ER 图一致 |
| D0-03 | 统一自愈动作命名并同步到所有文档 | P0 | HLD, INTERFACE, 功能清单 | 0.5d | 全文档自愈动作命名一致 |
| D0-04 | 定义 IntegrationPlugin Go interface 并写入 INTERFACE.md | P0 | INTERFACE.md | 0.5d | interface 定义包含 Init/RegisterRoutes/HealthChecks/Shutdown |
| R0-01 | 解决范围冲突：明确供应商智能切换 In/Out of Scope 定位 | P0 | PRD §3, 功能清单 | 0.5d | PRD 与功能清单范围一致 |
| R0-02 | 重新估算工期：138 任务按复杂度系数 + 20%联调 + 15%风险缓冲 | P0 | 功能清单 | 0.5d | 工期估算在 30~40 人天 |
| R0-03 | 补充自愈动作“重启实例”实现任务 | P0 | 功能清单 3.1.2 | 0.5d | 功能清单包含重启实例任务 |
| S0-01 | 在威胁建模中增加 LLM 特有风险（提示注入、幻觉、模型偷取） | P0 | HLD §10.1 | 0.5d | 威胁建模覆盖 LLM Top 5 风险 |
| S0-02 | 补充审计表防篡改触发器或应用层只追加约束 | P0 | migration | 0.5d | 审计表无法 UPDATE/DELETE |
| S0-03 | 明确审计写入与业务执行的事务顺序（fail-closed） | P0 | HLD §3.3 | 0.5d | 文档明确"先写审计再执行业务" |
| S0-04 | 补充 WebSocket JWT 鉴权说明 | P0 | INTERFACE §3.4 | 0.5d | WebSocket 接口含鉴权流程 |
| S0-05 | 在 HLD 中增加参数化查询强制要求 | P0 | HLD §4 | 0.5d | 所有数据库交互层必须使用参数化查询 |
| S0-06 | 限制 /metrics 端点访问（内网 IP 或 API Key） | P0 | INTERFACE §3.2 | 0.5d | /metrics 含访问控制说明 |
| T0-01 | 为 8 个缺失负向用例的 AC 补充负向用例 | P0 | TEST_DESIGN.md, CASES.md | 1d | 每个 AC 至少 1 正向 + 1 负向 |
| T0-02 | 补充 F-05 |
P0 | CASES.md | 0.5d | 8 条异常流程全部覆盖 |
| T0-03 | 创建 .github/workflows/ci.yml 含覆盖率阻断与失败通知 |
P0 | STRATEGY.md, ci.yml | 0.5d | PR 提交时自动触发并阻断不达标 PR |
| T0-04 | 创建 test/perf/ 目录含 k6 脚本和环境规格 |
P0 | TEST_DESIGN.md, test/perf/ | 0.5d | 性能压测可复现执行 |
Phase 1 — 需求与产品级 P1 闭环
| 任务 ID | 任务名称 | 严重度 | 责任文档 | 估算工时 |
|---|---|---|---|---|
| R1-01 | 统一失败判定线：上线后 30 天为统一窗口，噪声率<15% | P1 | PRD §2, §8.3 | 0.5d |
| R1-02 | 删除 In Scope 中“不仅仅包括于”，改为封闭列表 | P1 | PRD §3 | 0.5d |
| R1-03 | 统一通知渠道列表（是否含钉钉） | P1 | PRD AC-4, 功能清单 | 0.5d |
| R1-04 | AC-7 补充不可篡改的技术实现定义 | P1 | PRD AC-7 | 0.5d |
| R1-05 | AC-8 补充“有效”的判定标准 | P1 | PRD AC-8 | 0.5d |
| R1-06 | 在 AC-6 中补充级联故障回退验收点 | P1 | PRD AC-6 | 0.5d |
| R1-07 | 为容量预测（AC-9）补充可测试标准（如 MAPE<30%） | P1 | PRD AC-9 | 0.5d |
| R1-08 | 补充 UI 最低兼容性要求 | P1 | PRD | 0.5d |
| R1-09 | 细化角色权限矩阵到 API 级别 | P1 | PRD AC-12, 功能清单 G1 | 0.5d |
Phase 2 — 技术设计级 P1 闭环
| 任务 ID | 任务名称 | 严重度 | 责任文档 | 估算工时 |
|---|---|---|---|---|
| D1-05 | 修正 DEPLOYMENT “主备”为 active-active 多活 | P1 | DEPLOYMENT §1.1 | 0.5d |
| D1-06 | 分离 migration 执行从 Worker 启动逻辑（init container 或 Job） | P1 | DEPLOYMENT §3.2 | 0.5d |
| D1-07 | 补充 ai_ops_roles 表结构 |
P1 | HLD §8.1, migration | 0.5d |
| D1-08 | 补充 ai_ops_snapshots 表结构（级联故障回退） |
P1 | HLD §3.3, migration | 0.5d |
| D1-09 | 完善告警聚合状态机（解除规则、子告警同步） | P1 | HLD §5.2 | 0.5d |
| D1-10 | 补充规则评估分片策略与负载均衡方案 | P1 | HLD §9.1/9.2 | 0.5d |
| D2-12 | 完善 metrics 分区表管理策略（pg_partman 或应用层） | P2 | migration, HLD | 0.5d |
| D2-14 | 补充 Graceful Shutdown 中 WebSocket 关闭策略 | P2 | DEPLOYMENT §3.2 | 0.5d |
| D2-15 | 重新校准时序存储容量估算 | P2 | HLD §9.3 | 0.5d |
Phase 3 — 测试资产完善
| 任务 ID | 任务名称 | 严重度 | 责任文档 | 估算工时 |
|---|---|---|---|---|
| T1-01 | 建立覆盖率验证机制（CI 解析 domain≥70%, service≥80%） | P1 | STRATEGY.md | 0.5d |
| T1-02 | 设计 3 条混沌测试用例（Pod 杀死、Redis 分区、PG 主从切换） | P1 | TEST_DESIGN.md | 0.5d |
| T1-03 | 完善测试数据管理规范（fixtures 目录结构、大数据生成脚本、并行隔离） | P1 | STRATEGY.md | 0.5d |
| T1-04 | 为灰度门禁增加自动化判定脚本 | P1 | TEST_DESIGN.md §5.2 | 0.5d |
| T1-05 | 明确安全扫描工具（Trivy/Gosec）与阈值 | P1 | STRATEGY.md | 0.5d |
| T1-06 | 补充 E2E 详细场景设计（完整链路） | P1 | TEST_DESIGN.md, CASES.md | 0.5d |
| T2-01 | 统一用例编号风格为 TC-{AC}-{seq} | P2 | TEST_DESIGN.md, CASES.md | 0.5d |
| T2-02 | 补充 Webhook 5xx 测试场景 | P2 | CASES.md TC-E2 | 0.5d |
Phase 4 — 安全与运营工具
| 任务 ID | 任务名称 | 严重度 | 责任文档 | 估算工时 |
|---|---|---|---|---|
| S1-01 | 补充敏感字段脱敏具体实现（密码替换、加密） | P1 | HLD §8 | 0.5d |
| S1-02 | 明确自愈引擎权限边界（防止滥用重启关键服务） | P1 | PRD AC-6, HLD §3.3 | 0.5d |
| R2-01 | 补充 ROI 量化模型与财务指标 | P2 | PRD, competitor-analysis | 0.5d |
| R2-02 | 补充发布策略量化门控标准 | P2 | PRD §8 | 0.5d |
| R2-03 | 补充审计日志存储成本评估与压缩策略 | P2 | PRD, HLD §9.3 | 0.5d |
| D2-11 | 优化错误码排版并增加注释说明 | P2 | INTERFACE §3.3 | 0.5d |
六、总体改进计划
| 阶段 | 任务数 | 预估工时 | 目标 |
|---|---|---|---|
| Phase 0 文档修复与对齐 | 16 项 | 8 人天 | 消除所有 P0 问题，文档间一致 |
| Phase 1 需求与产品级 P1 | 9 项 | 4.5 人天 | PRD 完善，AC 可测试，权限明确 |
| Phase 2 技术设计级 P1 | 9 项 | 4.5 人天 | HLD/DEPLOYMENT 完善，部署可执行 |
| Phase 3 测试资产完善 | 8 项 | 4 人天 | 测试用例完整，CI 可运行 |
| Phase 4 安全与运营工具 | 6 项 | 3 人天 | 威胁建模完善，安全门禁可执行 |
| 合计 | 48 项 | 24 人天 | 达到生产级设计质量 |
七、小龙结论
- 当前状态不能进入开发：合计 16 项 P0 阻塞级问题，涵盖文档一致性、测试完整性、安全基线三大类。
- 最危险的系统性风险是接口定义不一致：HLD/INTERFACE/DEPLOYMENT 三份文档对同一集成点有不同路径和命名，开发团队无法确定真实契约，必须第一时间对齐。
- QA 是最薄弱环节：评级 C，负向用例大面积缺失、CI 零配置、性能压测无载体。建议优先补齐 T0-01~T0-04。
- Security 未覆盖 LLM 特有风险：项目集成 LLM/Gateway 后，提示注入、幻觉等风险可能导致严重安全事故，必须在威胁建模中补充。
- 工期估算严重失真：138 任务仅 18 人天，实际至少需要 30~40 人天，建议重新估算并预留 20% 联调 + 15% 风险缓冲。
- 建议执行顺序：Phase 0 → Phase 1 → Phase 2 → Phase 3 → Phase 4，每个 Phase 完成后由对应角色复审，所有 P0 闭环后才能进入开发。