答案

问题的背景：
现代信息系统通常在负载下运行，用户数量和数据量不断增长。业务需要产品具有高性能和可扩展性、无故障运行以及最小化停机风险。

问题：
性能要求很少能明确提出，通常是形式化的：“运行快速”或“可扩展到100,000用户”。缺乏完善的标准会导致无法验证、确认或测试解决方案，有时还会导致资源的过度消耗。

解决方案：

1. 分析师与架构师/基础设施合作，收集基准测试，分析峰值负载。
2. 在需求收集阶段，明确大规模使用的场景：最大同时用户数、交易量、SLA响应时间。
3. 形成可度量的非功能性要求：“在1000个并发请求下，5秒内加载1,000,000项。”
4. 额外使用性能分析和原型工具来评估实际性能。
5. 所有参数相互确认并与业务目标对齐（例如，客户服务的SLA）。

关键特征：

• 注重可度量标准（具体指标，SLA）
• 与架构师和DevOps在负载测试方面的互动
• 在“理想状态”和实际业务优先级之间的平衡

tricky问题

是否可以在没有产品分析的情况下使用行业标准指标？

行业标准指标作为参考是有用的，但必须根据业务和产品目标的具体情况进行调整。否则，可能会忽视关键场景和负载。

在开发测试中，仅有负载就足够确认可扩展性吗？

不，测试环境的基础设施参数通常与生产环境大相径庭。需要进行尽可能接近实际的负载测试，并定期重复。

是否可以在不影响业务功能的情况下实现最大性能？

几乎总是存在折衷：有时为了稳定性和预算符合，会引入限制（例如，批处理或单个场景的限制）。

常见错误和反模式

• “凭感觉”提出的要求缺乏具体性
• 发布和变更后缺乏重复测量
• 在设计阶段忽视可扩展性（推迟到“用户很多时再处理”）

生活中的例子

负面案例: 在技术规格中提到“高负载下的工作”，但未定义指标。发布后数据加载耗时数小时，业务损失了客户。 优点：快速确认要求。 缺点：系统在负载下行为不可预测。

正面案例: 分析师请求业务场景，与架构师共同确认了限制，并进行了负载测试。在发布中，系统承受了促销活动的峰值负载。 优点：可预见的增长，成功进行市场活动。 缺点：由于额外测试而延迟发布。