8.0 KiB
8.0 KiB
Subapi 集成专家审核与博弈机制（v1）
- 版本：v1.0
- 日期：2026-03-17
- 适用范围：S1-S2（集成 subapi + 逐步替换 + 企业级商用达标）
- 关联文档：
llm_gateway_subapi_evolution_plan_v2_2026-03-17.mdrouter_core_takeover_execution_plan_v3_2026-03-17.mdsubapi_integration_compat_security_reliability_design_v1_2026-03-17.mdsubapi_integration_risk_controls_execution_tasks_v1_2026-03-17.md
1. 机制目标
- 在实施前对架构、兼容、安全、可靠性和商业可运营性做“全面独立审查”。
- 通过“对抗式博弈（Red vs Blue）”提前暴露盲点，而不是上线后被事故教育。
- 形成可执行的 GO / CONDITIONAL GO / NO-GO 决策与整改清单。
2. 专家组成（建议 9-11 人）
2.1 内部专家（必选）
- 架构负责人（Router Core 负责人）。
- 平台工程负责人（CI/CD、发布与配置）。
- SRE 负责人（稳定性与故障恢复）。
- 安全负责人（应用安全 + 云安全）。
- 计费/财务数据负责人（对账与幂等）。
- 合规/法务接口人（ToS、审计与数据合规）。
- 产品负责人（商用目标与边界）。
- 测试负责人（兼容回归与质量门禁）。
2.2 外部专家（建议）
- LLM 网关实战专家（有多供应商网关生产经验）。
- 攻防专家（API 安全、SSRF、密钥泄漏与供应链风险）。
- 高并发系统专家（流式、重试、背压与故障隔离）。
- 可选：企业采购/交付顾问（SLA、审计、交付可行性）。
- 核心用户代表（迁移试点客户，验证真实可用性）。
- 重构项目专家（大规模替换路径与技术债治理）。
2.3 回避与独立性规则
- 同一模块负责人不能单独裁定自己模块通过。
- 安全与法务拥有一票否决权（P0 风险未关闭时）。
- 所有评审结论必须记录反对意见，不允许“口头通过”。
3. 博弈规则（防止形式主义评审）
3.1 Red Team vs Blue Team
- Blue Team：提出当前方案“为何可行”。
- Red Team：站在“攻击者 + 故障 + 合规审计 + 客户投诉”视角拆解方案。
- 每轮必须回答三个问题：
- 这个设计最先会在哪个条件下失败？
- 失败后会造成什么业务损失？
- 30 分钟内如何止血并可审计复盘？
3.2 强制替代方案对比
每个关键决策至少对比 2 个方案（例如：
subapi 外部模块化 vs 深度 fork），并给出：
- 复杂度成本。
- 失败半径。
- 回滚难度。
- 团队运维负担。
3.3 预演失败（Pre-mortem）
假设“2026-06-30 项目失败”，倒推失败原因并映射到当前行动项：
- 兼容回归导致客户 SDK 大面积失败。
- 账务冲突引发客户争议与财务风险。
- 安全配置疏漏导致 SSRF/密钥风险事件。
- 运维流程复杂导致故障恢复超时。
4. 审核维度与评分模型
4.1 评分维度（100 分制）
| 维度 | 权重 | 核心问题 |
|---|---|---|
| 兼容性 | 25 | 协议、错误语义、流式边界是否稳定 |
| 安全性 | 25 | SSRF、鉴权、密钥、供应链与审计是否可控 |
| 可靠性 | 20 | 故障隔离、熔断、回滚、恢复时间是否达标 |
| 运维简化 | 15 | 是否可标准化操作，是否减少人肉介入 |
| 账务正确性 | 10 | 幂等、对账、冲突告警是否闭环 |
| 合规可审计 | 5 | ToS、审计链、证据导出是否完整 |
4.2 通过门槛
- 总分 >= 85。
- 任一维度不得低于 70。
- 安全/合规存在 P0 未闭环：直接 NO-GO。
5. 四轮审核流程（建议）
Round-1：架构与替换路径审核（2026-03-19）
- 输入：v2/v3 规划文档、替换路径图、接口边界。
- 重点：是否能从“集成”平滑走到“替换”，且不锁死在 subapi。
- 输出：架构问题清单（含优先级与 owner）。
- 必邀角色：架构负责人、重构项目专家、网关专家、核心用户代表。
Round-2：兼容与计费一致性审核（2026-03-22）
- 输入：Connector 契约、接管率 SQL、验收用例。
- 重点：协议兼容、错误归一、流式 no-replay、幂等扣费。
- 输出：兼容差异矩阵 + 账务风险清单。
- 必邀角色：测试专家、网关专家、计费负责人、核心用户代表。
Round-3：安全与合规攻防审核（2026-03-25）
- 输入：配置硬化基线、认证链路、ToS 风险台账。
- 重点：query key、SSRF、出网策略、凭证安全、审计可追溯。
- 输出：安全整改单（P0/P1/P2）+ 合规结论。
- 必邀角色：安全负责人、测试专家、法务接口人、安全攻防专家。
Round-4：可靠性与运维演练审核（2026-03-29）
- 输入：告警看板、Runbook、回滚脚本。
- 重点：升级失败自动回退、30 分钟恢复、值班可执行性。
- 输出：演练报告 + GO/CONDITIONAL GO/NO-GO 决议。
- 必邀角色：SRE、测试专家、产品负责人、核心用户代表。
6. 决策与治理机制
6.1 决策类型
GO：可按计划推进。CONDITIONAL GO：允许推进，但必须在明确日期前关闭指定问题。NO-GO：冻结升波，先整改后复审。
6.2 一票否决条件（任一满足）
- 存在未闭环安全 P0 风险。
- 存在账务正确性 P0 风险。
- 无法在 30 分钟内完成回滚恢复演练。
- 法务未给出 ToS 风险可接受结论。
6.3 争议升级路径
- 技术争议：架构负责人 + SRE + 安全三方联裁。
- 商业/合规争议：产品负责人 + 法务 + 管理层联裁。
- 所有联裁必须形成 ADR（Architecture Decision Record）。
7. 必备评审材料（会前 24h 发出）
- 架构图与替换路线图（现状/目标/过渡）。
- 接口契约与兼容差异报告。
- 风险清单（含 P0/P1/P2、状态、owner、截止日期）。
- 近两周指标快照（P95、5xx、接管率、账务冲突率）。
- 上次整改项关闭证据。
8. 评审输出模板（必须留档）
- 评分表（总分 + 分维度评分）。
- 问题清单（编号、等级、负责人、截止日期）。
- 决议结果（GO/CONDITIONAL GO/NO-GO）。
- 风险接受记录（谁批准、基于什么证据）。
9. 与两周任务单的绑定方式
- 每轮专家评审都要映射到任务单任务 ID（COMP/SEC/REL/EXP）。
- 若评审新增问题，必须生成新任务 ID 并进入 daily gate。
- Round-4 决议是两周验收（2026-03-31）的前置条件。
- 三角色联合复审（
EXP-007）是EXP-006最终决议前置条件之一。
10. 立即可执行动作（本周）
- 确认专家名单与角色映射（内部 + 外部）。
- 发布 Round-1 邀请与会前材料清单。
- 指定评审秘书，负责记录与问题跟踪。
- 将评审结论同步到风险任务单与周报。
11. 已准备好的执行模板（可直接使用）
- 专家名单与回避：
review/experts_roster_2026-03-18.md - 邮件邀请模板：
review/templates/expert_invitation_email_templates_2026-03-17.md - IM 邀请模板：
review/templates/expert_im_message_templates_2026-03-17.md - 外部专家保密与回避声明：
review/templates/external_expert_nda_coi_template_2026-03-17.md - 评分表模板：
review/templates/expert_review_scorecard_2026-03-17.md - 会议纪要模板：
review/templates/expert_review_minutes_template_2026-03-17.md - 问题台账模板：
review/templates/expert_issue_register_template_2026-03-17.md - 邀请发送跟踪台账：
review/invitation_dispatch_tracker_2026-03-17.md - 邀请发出前检查单：
review/dispatch_ready_checklist_2026-03-17.md
12. 三角色联合评审输入（新增）
为强化“用户可接受性 + 质量阻断 + 网关可替换性”的联合校验，新增：
subapi_role_based_review_wargame_optimization_v1_2026-03-18.md- 用户代表、测试专家、网关专家三角色的 Red/Blue 博弈结论
- 新增任务
UXR/TST/GAT/EXP-007映射 - 作为 Round-2 与 Round-4 的强制预读材料