本文是《产品要懂得的性能指标：性能需求，你要好好提》的下篇。

上一篇解决的是“产品需要看懂哪些性能指标”：响应时间、并发用户数、吞吐量、成功率、可用性、资源利用率、数据规模、客户端流畅度，以及启动、耗电和流量。

但认识指标只是第一步。真正写需求时，产品还要解决几个更现实的问题：哪些功能必须重点保障？性能需求什么时候提？写到什么程度才可以验收？最后达不到又该怎么办？

这篇不再逐个解释指标，而是继续往下讲，怎么把指标真正写进需求、带进评审，并变成可以验收的标准。

产品经理写需求时，通常会把主要精力放在业务流程上：用户点哪里、页面展示什么、什么情况下成功、什么情况下失败。

功能写得很细，性能却经常只留下一句话：

系统响应要快，用户多的时候不能卡。

这句话看起来提了性能，实际上跟没提差不多。

多快算快？多少用户算多？哪个功能不能卡？可以失败多少次？持续一分钟和持续一小时是不是同一个要求？这些问题不说清楚，开发无法判断要按什么规模设计，测试也没有明确的验收标准。

性能需求很容易被忽视，却无比重要。功能做错了，可能只是某个流程不好用；性能没想清楚，可能是用户全部涌进来的时候，登录、注册、充值一起跪掉。

一、先别急着写数字，先给功能分级

不是所有功能都需要同样高的性能标准。

如果给每个接口都写“响应时间 500 毫秒以内、可用性 99.99%”，成本会非常高，也没有必要。产品首先要判断这个功能对业务有多重要，再决定性能要求。

我习惯把功能分成四类。

1. 关键功能：不能跪

关键功能是用户进入系统、使用资金或完成核心交易必须经过的功能，例如：

• 登录；
• 注册；
• 验证码与身份校验；
• 充值；
• 提现；
• 支付；
• 下单与订单结果查询。

这些功能一旦不可用，用户不是“体验差一点”，而是根本无法继续使用产品，甚至会怀疑资金是否安全。

关键功能的性能需求，不能只写响应时间，还要同时写：

• 峰值并发量；
• 响应时间 P95、P99；
• 请求成功率；
• 超时率和系统错误率；
• 是否允许重试；
• 重复提交是否会产生重复充值、重复订单；
• 服务不可用时如何降级；
• 多久必须恢复；
• 用户能否看到明确的处理状态。

例如，充值请求已经提交，但第三方支付通道迟迟没有返回结果。此时不能简单提示“充值失败”，更不能让用户反复提交。产品需要定义“处理中”状态、查询方式、到账后的通知方式，以及超过多长时间需要人工处理。

关键功能真正要保证的是：慢一点还可以解释，状态不能乱；暂时没结果可以等待，资金不能重复处理。

2. 高频功能：不能卡

高频功能不一定涉及资金，但用户一天会操作很多次，例如：

• 首页；
• 搜索；
• 商品或行情列表；
• 消息列表；
• 订单列表；
• 刷新和筛选。

这类功能每慢一点，都会被大量用户重复感知。它们的重点通常是：

• 首屏多久出现；
• 点击后多久给出反馈；
• 列表滚动是否流畅；
• 分页或加载更多是否稳定；
• 弱网下是否一直转圈；
• 高频请求是否会把系统打满。

对于高频功能，优化 200 毫秒可能比优化一个一年只用一次的后台功能更有价值。

3. 特色功能：不能砸卖点

特色功能是产品对外宣传的卖点，例如：

• 实时行情；
• 智能推荐；
• 秒级到账；
• 一键生成报告；
• 实时风险预警；
• 大规模数据分析。

如果广告写着“实时”，结果数据十几秒才更新；如果宣传“一键生成”，用户点完要等两分钟，那么功能即使最终能用，卖点也已经不存在了。

特色功能的指标应该从宣传承诺反推：

• “实时”究竟是 1 秒、3 秒还是 1 分钟？
• “秒级”是否要求 5 秒内完成？
• “海量数据”具体是多少条？
• “智能分析”从提交到结果需要多久？
• 高峰期是否仍能维持卖点？

性能不是特色功能的附加项，很多时候，性能本身就是产品卖点。

4. 数据量大的功能：不能越用越慢

有些功能刚上线时数据不多，看起来很快，半年后就完全不同了，例如：

• 订单查询；
• 流水查询；
• 日志检索；
• 报表统计；
• 批量导入；
• 数据导出。

这类功能不能只在空数据库里验收。产品要写清楚：

• 基础数据量；
• 单个用户可能拥有的数据量；
• 查询时间范围；
• 筛选条件；
• 导入或导出上限；
• 同时执行任务的人数；
• 超过同步处理能力后，是否转为后台任务。

例如，“订单导出 3 秒内完成”是不完整的。1,000 条和 10 万条不是同一个需求，10 个用户导出和 500 个用户同时导出也不是同一个需求。

二、系统整体性能和单个功能性能，要分开提

性能需求通常有两个层次。

系统整体性能

系统整体性能描述产品在总体压力下能不能稳定运行，常见内容包括：

• 支持多少在线用户；
• 峰值并发用户数；
• 每秒可以完成多少笔核心业务；
• 系统可用性；
• 压力需要持续多久；
• CPU、内存、磁盘和网络是否保留合理余量；
• 超过设计容量后如何限流、排队或降级；
• 故障后多久恢复。

整体性能解决的是“系统会不会一起跪”的问题。

单个功能性能

不同功能应该有不同的性能要求。例如：

“登录响应 2 秒、并发用户 500、TPS 500、CPU 不超过 75%”看起来很完整，但仍然可能有问题：

• 2 秒是平均值、P95，还是最长时间？
• 500 人是同时在线，还是同一秒点击登录？
• 一次登录包含多个请求，TPS 如何计算？
• CPU 75% 是瞬时峰值，还是持续 30 分钟的上限？
• 登录失败多少次还能验收通过？

所以，参数必须带上统计口径和测试条件。

三、性能需求到底应该什么时候提？

答案很明确：写需求时就要写，需求评审时必须说。

不要等开发完成后，才突然问一句：“这个能不能支持十万人同时用？”

因为性能会影响技术方案、开发时间和项目成本。是否需要缓存、异步任务、排队、限流、数据分片、第三方备用通道，都可能取决于性能目标。

如果功能已经开发完成，再临时把目标从 100 并发改成 10,000 并发，这不是简单调一个参数，可能需要重新设计。

在需求编写阶段

产品需要先给出业务信息：

• 预计用户量；
• 日活和高峰时段；
• 哪些场景会产生集中流量；
• 哪些功能绝对不能失败；
• 哪些体验是对外宣传的卖点；
• 数据量未来半年或一年可能增长到多少；
• 失败会造成什么业务损失。

产品不需要替技术团队设计服务器和数据库，但必须把业务规模、重要程度和失败后果说清楚。

在需求评审阶段

评审时不要只确认功能流程，还要逐项确认：

1. 这次需求有没有关键、高频、特色或大数据量功能？
2. 预估峰值是多少，依据来自哪里？
3. 关注平均响应时间，还是 P95、P99？
4. 可接受的失败率是多少？
5. 压力超过目标后，系统应该排队、降级还是拒绝？
6. 是否需要专项压测？
7. 测试环境和生产环境有什么差异？
8. 性能不达标会不会阻止上线？

这些问题在评审时说出来，开发才能评估成本，测试才能提前准备数据和压测场景。

在上线前

上线前不是第一次讨论性能，而是验证需求阶段已经确认的指标。

此时应该检查：

• 核心场景是否完成压测；
• 测试数据量是否接近真实规模；
• 峰值压力是否持续了足够时间；
• 性能结果是否包含 P95、P99、成功率和错误率；
• 限流、降级和恢复方案是否实际演练；
• 上线后的监控和报警是否准备好。

四、一条性能需求应该包含什么？

可以直接使用下面这个公式：

业务场景
+ 数据规模
+ 访问压力
+ 持续时间
+ 目标指标
+ 统计口径
+ 超限处理
+ 验收方式

不合格的写法

登录接口响应要快，用户多的时候不能失败。

可以执行的写法

场景：用户使用手机号和验证码登录。

测试条件：
- 测试数据包含 100 万注册用户；
- 2,000 名用户同时登录，峰值 500 次登录提交/秒；
- 峰值压力持续 10 分钟。

验收指标：
- 登录请求响应时间 P95 ≤ 1 秒，P99 ≤ 2 秒；
- 系统原因导致的登录失败率 ≤ 0.1%；
- 验证码错误、账号冻结等正常业务拒绝单独统计；
- 不允许出现重复会话或错误登录状态；
- 达到容量上限时返回明确结果，不允许请求一直等待；
- 压力结束后 5 分钟内恢复到正常资源水位。

注意，上面的数字只是写法示例，不是所有产品都必须采用的统一标准。合理数值应该来自历史数据、业务预测、竞品体验、用户预期和技术评估。

五、风险监控也有性能要求

很多产品会写“增加风险监控”，却只描述风险规则，没有说明监控多快执行、告警多久送达。

风险监控的核心性能参数包括：

• 数据采集延迟；
• 风险规则计算耗时；
• 从风险发生到告警送达的总时长；
• 每秒可处理的事件数；
• 告警送达率；
• 重复告警和漏报情况；
• 数据积压后的追赶速度；
• 监控系统自身的可用性。

例如：

用户连续登录失败达到规则阈值后，风险事件应在 3 秒内完成识别，95% 的高风险告警应在 10 秒内送达值班人员。峰值每秒接收 5,000 个事件时，不得丢失高风险事件；发生积压后，应在流量恢复正常的 10 分钟内处理完毕。

风险监控不是后台有一条记录就算完成。告警晚了半小时，即使最终算对，也可能已经失去意义。

六、性能需求达不到怎么办？

性能不达标时，最不应该做的事情，是直接把指标改低，然后宣布通过。

先回答两个问题：

1. 原来的指标是否合理？
2. 实际结果与目标相差多少？

第一步：重新检查指标是否合理

需要检查：

• 指标是否有真实业务依据；
• 测试压力是否远高于可能出现的峰值；
• 测试数据是否不符合真实分布；
• 是否把正常业务拒绝统计成系统失败；
• 是否只看了平均值，忽略 P95、P99；
• 测试环境是否明显低于生产环境；
• 是否把第三方服务的限制遗漏了；
• 是否要求所有功能达到同一个最高标准。

如果指标本身不合理，可以调整，但必须记录调整原因。不能因为做不到就说需求不重要。

第二步：量化到底差多少

不要只写“性能未达标”，要写出差距：

差 5% 和差 5 倍，处理方式完全不同。只有知道差多少，团队才能判断是小范围优化、增加资源，还是重新设计。

第三步：找到差距发生在哪里

常见原因包括：

• 客户端渲染慢；
• 网络或网关排队；
• 服务端计算耗时；
• 数据库查询慢；
• 缓存命中率不足；
• 外部支付、短信或身份认证服务慢；
• 多个接口串行执行；
• 大量重试进一步放大流量；
• 日志、监控或消息出现积压；
• 容量扩展速度跟不上流量增长。

产品不需要指定技术怎么修，但需要确认业务上哪些流程可以调整、哪些体验不能牺牲。

第四步：给出明确处理结论

性能不达标后，通常有五种选择：

1. 继续优化：指标合理，差距可控，优化后重新测试。
2. 增加容量：通过增加资源达到目标，同时确认成本是否能接受。
3. 调整业务流程：例如把十万条同步导出改成后台生成，完成后通知用户。
4. 限流或降级：优先保证登录、充值、支付等关键功能，暂时关闭次要功能。
5. 调整指标：确认原指标确实不合理，并记录新指标、原因和风险。

无论选择哪一种，都要重新验收。不能用“测试环境问题”“后续再优化”作为没有负责人和时间点的结论。

七、系统快要扛不住时，先保什么？

高峰期间资源有限，不可能所有功能都得到相同保护。产品应该提前定义优先级。

一个常见顺序是：

1. 保护登录、身份验证等入口功能；
2. 保护充值、提现、支付和订单等资金功能；
3. 保护状态查询，避免用户不知道钱和订单去了哪里；
4. 保护风险监控和告警；
5. 保留核心产品卖点；
6. 降低推荐、排行、非必要统计等次要功能的频率；
7. 暂停大数据导出、批量任务等高消耗功能。

这不是技术团队临时决定的事情。哪些功能可以降级、降级后给用户看什么、什么时候恢复，应该在需求和应急方案里提前确认。

八、产品可以直接复制的性能需求模板

## 性能需求

### 1. 功能等级
- 功能名称：
- 等级：关键 / 高频 / 特色 / 大数据量 / 普通
- 不能失败的原因：
- 失败造成的业务影响：

### 2. 使用场景
- 用户在做什么：
- 主要操作路径：
- 高峰发生时间：
- 是否存在集中操作事件：

### 3. 数据与压力
- 基础数据量：
- 预计在线用户数：
- 峰值并发用户数：
- 峰值 QPS/TPS 或每秒业务量：
- 峰值持续时间：

### 4. 验收指标
- 响应时间 P95：
- 响应时间 P99：
- 请求成功率：
- 系统错误率：
- 超时率：
- 数据处理时长：
- 可用性：
- 故障恢复时间：

### 5. 超限处理
- 达到容量上限时：排队 / 限流 / 降级 / 拒绝
- 优先保护的功能：
- 可以暂停的功能：
- 给用户展示的状态：
- 是否允许重试：
- 如何防止重复提交：

### 6. 测试与上线
- 测试环境：
- 测试数据准备人：
- 压测负责人：
- 是否影响上线：
- 上线后的监控指标：
- 报警阈值和负责人：

九、最后提醒

性能需求不是技术团队自己的事情。

技术团队可以决定怎么实现，但产品经理需要说清楚：哪些业务最重要、会有多少人使用、用户能等多久、失败有什么后果、超出容量后先保谁。

不要只写一句“系统要快”，也不要等上线前才补一条“支持十万人同时使用”。

需求编写时写进去，需求评审时说出来，开发前确认口径，上线前按同一套标准验收。

如果指标没有达到，就重新检查指标是否合理，量化实际差距，找到瓶颈，再决定优化、扩容、调整流程、降级还是修改目标。

性能需求确实容易被忽视。但用户真正开始使用产品时，他们未必知道你的功能设计有多复杂，只会记得一件事：关键时刻，这个产品到底能不能用。