解读

国内互联网迭代节奏快，PRD 平均 2～3 周就有一次大版本刷新。性能测试介入时机常被压缩，如果风险描述停留在口头或邮件，需求方一旦变更优先级，性能瓶颈就可能被“默杀”。面试官想确认两点：第一，你能否把抽象的性能风险翻译成产品语言并固化到 PRD；第二，你能否在敏捷节奏里建立“可追踪、可量化、可复盘”的闭环机制，避免“测试背锅”。

知识点

1. 性能风险三要素：业务场景、容量指标、失败代价。
2. PRD 中性能章节的标准位置：位于“非功能需求”栏，与埋点、合规并列。
3. 风险分级模型：P0 阻断发布、P1 限流降级、P2 可延后优化。
4. 可追溯字段：风险编号、场景描述、SLA、Owner、Deadline、状态、验证方式。
5. 变更联动流程：需求变更 → 影响分析 → 风险再评估 → 更新 PRD → 重新评审。
6. 国内常用工具链：Tapd/飞书多维表格做需求池，Jira 做任务跟踪，Confluence 做 PRD 版本管理，Git MR 做代码关联，Prometheus+Grafana 做线上监控。
7. 闭环证据：PRD 版本 diff、测试报告编号、线上监控截图、复盘会议纪要。

答案

我在上一家公司把性能风险写进 PRD 并闭环分为五步，可直接落地。

第一步，风险条目化。
在 PRD 模板里固定“性能风险”子目录，每个风险给唯一编号，格式：PERF-YYMMDD-序号。内容用“一句话用户场景 + 量化指标 + 失败影响”三段式，例如：
PERF-230411-01：秒杀下单场景，5w 并发，99 响应时间 ≤ 800 ms，失败会导致库存超卖及客诉。指标直接引用业务 SLA，避免争议。

第二步，风险分级与 Owner。
用 T-shirt 尺码标注容量缺口：XL 表示当前只能到 30% 目标，必须阻塞发布；L 表示需限流降级方案；M 表示可接受 1 周性能技术债。每个风险指定两名 Owner：开发负责人 + 测试负责人，保证后续跟踪有人认领。

第三步，变更联动。
需求变更评审会强制检查“性能风险”章节。任何需求池 Story 状态变为“已更新”，飞书机器人自动 @Owner，要求 24h 内回复“影响分析”。若新增或修改了核心链路，必须重新提交容量评估报告，并在 PRD 里更新风险状态，否则测试有权打回评审。

第四步，测试验证与证据留存。
性能测试报告标题直接引用风险编号，如《PERF-230411-01 验证报告》。报告结论只有两种：①风险关闭 ②风险遗留。遗留风险需给出“线上降级开关+下次迭代 deadline”。所有报告以附件形式挂到 Confluence 页面，Git 打 tag 时把报告链接写进 MR 描述，保证代码、性能、需求三点一线可追溯。

第五步，线上监控与复盘。
上线后 48h 内，把核心接口的 P99、P999 曲线截图贴回 PRD 对应风险条目，状态置为“线上已验证”。若出现 SLA 击穿，自动创建 P0 故障单，周会复盘必须回溯到原始风险编号，检查是否漏测、指标是否合理、Owner 是否及时响应。复盘结论更新至 PRD“经验沉淀”栏，形成下一版基线。

通过这五步，我们把“性能风险”从口头提醒变成 PRD 里的硬条目，变更一次评审一次，上线一次验证一次，半年内性能故障下降 42%，需求方也养成“改需求先看性能”的习惯。

拓展思考

1. 如果组织采用 OKR，可把“PRD 性能风险闭环率”设为测试团队季度 KR，定义闭环率 = 已关闭风险数 / 新增风险数，目标值 ≥ 95%，用数据倒逼流程落地。
2. 对于微服务架构，可把风险条目再拆分到“接口级”，利用 Swagger + 注解自动生成性能基准文档，减少手工维护。
3. 当业务进入大促模式，可提前 6 周锁定 PRD 性能章节，任何新增需求走“性能豁免”审批，由 CTO 级别拍板，避免临时插单冲垮容量基线。