94 lines
11 KiB
Markdown
94 lines
11 KiB
Markdown
## PM 审核报告
|
||
|
||
### 总体评级：B
|
||
|
||
**评级说明**：PRD 整体结构完整，用户旅程覆盖较全，AC 基本满足 SMART 原则，商业化闭环有框架但缺乏财务量化。存在 1 处 P0 级范围不一致、1 处 P0 级错误码冲突，以及工期估算严重偏乐观的问题。建议在进入 TechLead 评审前修复 P0/P1 问题。
|
||
|
||
---
|
||
|
||
### 优点
|
||
|
||
1. **用户旅程覆盖完整**：主流程（监控看板、配置审计回滚、告警处置）+ 异常流程（自愈失败、告警飙升、回滚失败）+ 边缘流程（无人处理告警、数据源丢失、误触发变更）全部覆盖，并配有 F-1~F-8 的独立失败路径表。
|
||
2. **AC 量化程度高**：12 条 AC 中，90% 以上包含明确的数值约束（如 <2s、<3s、30s、90 天、50 条规则、100 条/页），可直接转化为 QA 测试用例。
|
||
3. **In/Out of Scope 边界清晰**：明确排除了下游大模型监控、基础设施层监控、AI 自动扩缩容、外部监控系统整合，避免范围蔓延。
|
||
4. **技术约束明确**：统一 Go 1.22+ / 标准库 net/http / pgx / go-redis，禁止引入 Gin/Echo；支持独立运行与集成运行双模式；数据库表名强制 `ai_ops_` 前缀，减少集成冲突。
|
||
5. **发布策略安全**：分 4 阶段上线，自愈规则强制"沙盒模式"验证（>=10 次模拟），并设计了一键关闭自愈的权限开关，风险控制意识强。
|
||
6. **竞品分析有价值**：对 LiteLLM、Sub2API、NewAPI、FreeRide 的对标分析到位，差距分析直接转化为产品机会点。
|
||
|
||
---
|
||
|
||
### 发现问题（按严重度分类）
|
||
|
||
#### P0 — 阻塞性问题（必须修复后才能进入开发）
|
||
|
||
| 编号 | 问题 | 影响 | 位置 |
|
||
|------|------|------|------|
|
||
| P0-1 | **范围冲突：供应商智能切换未在 PRD 正文 In Scope 中明确纳入，但功能清单将其作为 Phase 3 核心模块（3.4，含 16+ 个任务）** | 该功能涉及自动路由变更、供应商探测、Fallback 链管理，本质上属于"自动化配置变更/扩容决策"，与 Out of Scope 第 3 条"不做自动扩容决策"存在擦边风险；且 In Scope 第 1 条明确"不含下游大模型服务"，而供应商切换直接依赖下游供应商接口。若不加明确界定，开发阶段极易产生范围争议。 | PRD §3 In Scope / 功能清单 模块 3.4 |
|
||
| P0-2 | **错误码不一致**：PRD 场景 F 与 AC-8 规定回滚失败错误码为 `OPS_AUD_4101`，但功能清单 3.3.2 使用 `AUDIT_ROLLBACK_TARGET_LOST` | 接口契约冲突，前后端/QA 无法对齐，将导致集成测试失败。 | PRD §4 场景 F、§5 AC-8 / 功能清单 3.3.2 |
|
||
| P0-3 | **工期估算严重偏离实际**：功能清单列出 138 个任务，总估算仅 18 人天（平均每个任务不足 1 小时），未包含联调、集成测试、Bug 修复、文档、评审、返工时间 | 该估算极可能导致项目延期、资源不足、质量下降。按行业常规，Go 后端 + 前端 + 测试的完整交付，138 个任务至少需要 6~8 周（30~40 人天）以上。 | 功能清单 "任务估算汇总" |
|
||
| P0-4 | **自愈动作"重启实例"在功能清单中遗漏具体任务**：PRD AC-6 明确列出"重启实例"为可选自愈动作之一，但功能清单 3.1.2 的自愈执行后端任务仅覆盖"切换备用路由、限流、触发脚本"，未提及"重启实例"的实现任务 | 功能遗漏，QA 无法验收该自愈动作。 | PRD §5 AC-6 / 功能清单 3.1.2 |
|
||
|
||
#### P1 — 重要问题（强烈建议修复）
|
||
|
||
| 编号 | 问题 | 影响 | 位置 |
|
||
|------|------|------|------|
|
||
| P1-1 | **双重失败判定线**：PRD §2 定义"开发期间任何一周内告警噪声率 >20% 或自愈规则误触发导致生产事故，即判定失败"；§8.3 又定义"上线 30 天内 MTTR 未下降至 <20min / 自动化覆盖率 <30% / 噪声率 >15% / 自愈误触发 1 次"进入救援模式 | 两条判定线的时间边界（开发期 vs 上线后）、指标阈值（20% vs 15%）、触发条件不统一，团队无法判断应以哪条为准。 | PRD §2 成功定义、§8.3 失败判定线 |
|
||
| P1-2 | **In Scope 使用"包括但不限于"**：第 1 条"包含但不限于：gateway/..." | "包括但不限于"是范围管理中的高风险词汇，为后续需求蔓延留下口子。应改为封闭列表，或明确"仅包含以下模块"。 | PRD §3 In Scope #1 |
|
||
| P1-3 | **通知渠道定义不一致**：PRD AC-4 要求"Webhook、邮件、飞书/企业微信至少 2 种"，但功能清单 2.3.2 和 3.4.3 出现了"钉钉"，且备份切换链为 Webhook→邮件→飞书→企微 | 若最终未实现钉钉，功能清单需同步删除；若实现，PRD AC-4 需更新。 | PRD §5 AC-4 / 功能清单 2.3.2、3.4.3 |
|
||
| P1-4 | **AC-7 "审计日志必须不可篡改"缺乏技术实现定义**：未说明是通过 WORM 存储、哈希链、数字签名还是仅通过数据库层禁止 UPDATE/DELETE 来实现 | QA 无法验证"不可篡改"，不同实现方式的成本和合规等级差异巨大。 | PRD §5 AC-7 |
|
||
| P1-5 | **AC-8 "操作前值有效"定义模糊**：未明确"有效"的判定标准（非空？JSON 可解析？符合当前 Schema？） | 可能导致回滚接口在边界情况下行为不一致。 | PRD §5 AC-8 |
|
||
| P1-6 | **级联故障回退（F-6）未在 AC 中体现**：PRD §6 F-6 描述自愈级联故障时"自动恢复上一步操作前的状态"，但 AC-6 仅提到"若未解除则升级为人工告警"，未要求验证级联回退能力 | 功能清单 3.1.3 有任务，但 AC 缺失，QA 无法据此验收。 | PRD §6 F-6 / §5 AC-6 |
|
||
| P1-7 | **容量预测算法缺乏可测试标准**：AC-9 要求"按当前增长率预测触达资源上限时间"，但注明"仅供参考，不自动执行扩容"，且未定义预测准确率、置信区间或最大可接受偏差 | "仅供参考"导致该功能无法被 QA 有效验收，开发完成后可能沦为无法量化的"演示功能"。 | PRD §5 AC-9 |
|
||
| P1-8 | **缺少 UI/UX 最低兼容性要求**：PRD 和功能清单均未规定浏览器支持范围、移动端适配策略、最低分辨率 | 前端工程师缺乏约束，可能在交付后因兼容性问题返工。 | PRD 全文 |
|
||
| P1-9 | **角色权限矩阵过粗**：AC-12 仅定义 3 个角色的一句话权限，缺少页面级/API 级权限对照表（如"运维人员能否导出审计日志？""查看者能否导出 CSV？"） | 功能清单 G1 中"管理员（可管理用户）"超出了 PRD 定义（PRD 未提用户管理），进一步加剧不一致。 | PRD §5 AC-12 / 功能清单 G1 |
|
||
|
||
#### P2 — 改进建议（建议纳入后续迭代）
|
||
|
||
| 编号 | 问题 | 建议 |
|
||
|------|------|------|
|
||
| P2-1 | 商业化闭环缺少 ROI 量化模型 | 补充"当前运维人力成本 = X 人月 × Y 元/人月，目标释放 40% 后节省 Z 元/月"的计算示例，使北极星指标与财务指标挂钩。 |
|
||
| P2-2 | 竞品分析中的技术设计模式未融入 PRD 正文 | 将 `CustomBatchLogger`、`DigestEntry`、`DualCache` 等设计模式从竞品分析报告迁移到 PRD 技术约束或架构建议章节，避免设计阶段遗漏。 |
|
||
| P2-3 | 发布策略缺少阶段门控的量化验收标准 | 阶段 2 进入阶段 3 的条件目前是"无 P1 以上告警 72h"，建议补充"告警噪声率 <10%""通知渠道成功率 >95%"等可量化门控。 |
|
||
| P2-4 | 未定义生产部署拓扑 | 建议明确是单集群还是多集群部署，自愈动作"重启实例"在 K8s 与裸金属环境下的实现差异巨大。 |
|
||
| P2-5 | 审计日志 90 天保留期未评估存储成本 | 高并发场景下全量 JSON 审计日志的存储量可能极大，建议补充日志压缩/归档策略或存储成本上限。 |
|
||
| P2-6 | PRD 自检清单声称"没有使用优化、支持、友好、尽量、快速等模糊词"，但正文中仍存在"等""等相关指标"等模糊表述 | 建议将 In Scope 中的"等"字去除，改为封闭列表；功能清单中的"等相关能力"也需同步清理。 |
|
||
|
||
---
|
||
|
||
### 改进建议（优先级排序）
|
||
|
||
1. **立即修复 P0 问题**：
|
||
- 在 PRD §3 In Scope 中明确加入"供应商智能切换（含健康探测、Fallback 链、策略化路由）"或将其移入 Out of Scope；若纳入，需在 AC 中补充对应的验收标准。
|
||
- 统一回滚失败错误码为 `OPS_AUD_4101`，功能清单同步修正。
|
||
- 重新进行工时估算，建议采用"任务 × 复杂度系数 + 联调缓冲（20%）+ 风险缓冲（15%）"的方式，输出 30~40 人天的 realistic estimate。
|
||
- 在功能清单 3.1.2 中补充"重启实例"自愈动作的实现任务（如调用 K8s API 或主机 agent）。
|
||
|
||
2. **本周内修复 P1 问题**：
|
||
- 合并/统一失败判定线，建议按"上线后 30 天"为统一时间窗口，阈值取更严格的版本（噪声率 <15%）。
|
||
- 删除 In Scope 中的"包括但不限于"，改为封闭枚举；如确需扩展，规定"新增范围需经 PM+TechLead 双签"。
|
||
- 明确 AC-4 通知渠道的最终列表（是否含钉钉），并同步更新功能清单的备用切换链。
|
||
- 在 AC-7 中补充"不可篡改"的实现方式（建议：数据库层禁止 UPDATE/DELETE + 应用层只追加写入）。
|
||
- 补充 UI 最低兼容性要求（如：Chrome/Firefox/Edge 最新 2 个版本，最小宽度 1280px）。
|
||
- 细化角色权限矩阵到 API 级别，建议以表格形式列出各角色对关键接口的 CRUD 权限。
|
||
|
||
3. **TechLead 阶段前补充**：
|
||
- 将竞品分析中的设计模式建议提炼为 PRD 架构约束章节（如告警批量化、摘要窗口、双缓存机制）。
|
||
- 为容量预测（AC-9）补充可测试标准，例如"预测值与实际值的平均绝对百分比误差（MAPE）<30%"或至少提供趋势方向判断准确率。
|
||
- 明确生产部署拓扑（K8s vs 裸金属 vs 混合），影响自愈动作设计。
|
||
|
||
---
|
||
|
||
### 审核结论
|
||
|
||
| 维度 | 评分 | 说明 |
|
||
|------|------|------|
|
||
| 用户旅程完整性 | A- | 主/异/边缘流程全覆盖，但级联回退未在 AC 中闭环 |
|
||
| AC 可测试性 | B+ | 大部分量化精确，但"仅供参考""有效""不可篡改"等不可测试 |
|
||
| In/Out of Scope 清晰度 | B | 主体清晰，但"包括但不限于"和供应商切换造成范围争议 |
|
||
| 成功指标与失败判定 | B- | 指标量化，但存在双重标准，时间边界模糊 |
|
||
| 商业化闭环 | B- | 有框架但缺 ROI 量化，外部收益链条弱 |
|
||
| 功能清单一致性 | C+ | 与 PRD 存在错误码冲突、渠道不一致、任务遗漏、估算失真 |
|
||
| 模糊词汇控制 | B+ | 主体控制良好，"等"字和"包括但不限于"需清理 |
|
||
|
||
**建议行动**：修复 P0-1~P0-4 后，可进入 TechLead 评审；P1 问题建议在技术方案评审前同步闭环。
|