解读

国内互联网节奏快，产品经理（PM）为抢占市场窗口，常出现“周更需求”“迭代内插需求”现象。性能测试的输入——非功能性需求（NFR，Non-Functional Requirements）一旦漂移，脚本、数据模型、基准环境、SLA 全部失效，造成重复投入甚至线上事故。面试官关注的不是“吐槽 PM”，而是候选人能否在高压下建立“可审计、可回滚、可量化”的 NFR 治理机制，并兼顾交付速度。

知识点

1. NFR 的构成：并发模型、业务峰值、数据量级、SLA（RT、TPS、错误率、资源上限）、稳定性时长、可扩展性指标。
2. 版本化载体：Git 分支 + Tag、Confluence 页面历史、需求管理工具（Jira/禅道）版本字段、测试用例管理工具（TestLink、Xray）基线。
3. 可追溯四要素：谁改的、改了什么、为什么改、对测试资产的影响。
4. 国内常用流程：需求评审 → 技术方案评审 → 性能评审 → 用例评审 → 上线评审，性能评审环节必须强制卡点。
5. 工具链：Git + Markdown（NFR 说明书）、Jira 自定义字段“性能变更类型”、Jenkins 流水线打 Tag、Allure 报告绑定需求 ID、SonarQube 质量门。
6. 法规与合规：央行《金融 IT 基础设施规范》、工信部《云计算服务安全评估办法》均要求性能指标可追溯，审计时需提供基线对比报告。

答案

我会把 NFR 当作“代码”来管理，建立“一份说明书 + 一条工作流 + 一套自动化钩子”，让任何变更都有数字足迹。具体分五步：

1. 建立单一可信源
   在 GitLab 新建 nfr-repo，目录按“业务域/子系统/版本号”划分，README.md 中固化 3 类指标：

   • 并发模型：峰值 QPS、日活占比、漏斗转化率；
   • 数据量级：核心表规模、Redis key 数量、日志增速；
   • SLA：P99 RT ≤ 500 ms、TPS ≥ 3000、CPU ≤ 60%、内存无泄漏。
     文件命名采用“子系统_vYYYYMMDD_序号”，每次变更必须 Pull Request，禁止直接 Push。

2. 把变更关进评审流水线
   在 Jira 新增 Issue Type“性能需求变更”，必填字段：

   • 变更原因（市场活动、运营配置、架构升级）；
   • 影响范围（脚本、数据量、监控阈值）；
   • 风险等级（高/中/低）。
     与研发负责人、PM、测试、SRE 四方评审，评审结论以“评论+截图”形式沉淀，Git PR 必须关联 Jira ID，否则合并按钮置灰。

3. 自动化基线对比
   Jenkins 流水线在合并后触发：

   • 拉取 nfr-repo 最新 Tag，解析 Markdown 中的指标，写入 InfluxDB；
   • 调用 Gatling/JMeter 脚本，跑 10 分钟基准场景；
   • 生成 Allure 报告，自动打上 Git Commit 与 Jira ID；
   • 若 P99 RT 或错误率劣化超 5%，流水线失败，飞书机器人 @ 责任人。

4. 版本快照与回滚
   每次上线前，使用 Git Tag 打快照，格式“prod-系统-日期-上线单号”。若线上出现性能回退，可在 5 分钟内回滚到上一个 Tag，并用同版本 NFR 重新压测，确保回滚后指标仍达标。

5. 定期审计与复盘
   双周召开“性能变更 Review”，统计变更次数、回退次数、缺陷密度，输出《性能需求变更健康度报告》。对高频无价值变更，推动 PM 写进 OKR 改进，必要时升级到技术委员会仲裁。

通过以上闭环，任何一次 PM 变更都能追溯到人、需求、代码、报告，且回滚可验证，既保护了测试资产，也避免了“拍脑袋”性能目标。

拓展思考

1. 如果 PM 坚持“口头变更”怎么办？
   可引用《研发管理规范》中“无 Jira 单不排期”条款，拒绝提供性能报告，并邮件同步 TL 与 PMO，把风险上升为项目级问题。
2. 如何量化“频繁”？
   建议用“迭代需求变更率 = 迭代内性能相关变更单数 / 总需求单数”，超过 30% 即触发治理。
3. 对于外包团队，如何同步 NFR？
   在合同技术附件中固化 NFR 基线，并约定“超出基线部分按人日计费”，用商业条款抑制随意变更。