如何为峰值就绪构建自动化工作负载模型
内容提要
本文介绍如何利用可观测性工具（如New Relic/Dynatrace）自动构建负载测试工作负载模型，替代传统手动方法。通过六步查询流程（峰值日、小时、分钟、场景混合、并发用户、活跃会话），直接从生产遥测数据推导出RPS目标、虚拟用户数和场景权重，并应用增长系数。文中还提供了Java工具Peak Workload Analyzer，可将13-22小时的工作缩短至5分钟，确保每个数字可追溯至真实数据，消除猜测。
延伸解读
为什么手动建模风险高
手动建模依赖人工从APM工具导出CSV、在Excel中透视，并靠访谈开发人员来还原用户旅程，整个过程耗时13到22小时，且每个环节都有出错风险。更关键的是，基于猜测的模型可能在压测时才发现场景权重错误，导致容量预估偏差，直接影响大促准备。
自动化方法的核心价值
通过直接查询生产遥测数据，自动化工具将建模时间从13-22小时缩短到5分钟以内，且每个数字都可追溯到真实数据。这种方法不仅消除了猜测，还让模型可复现、可审计，为团队节省大量人力，同时提高压测的准确性。
并发用户公式的选择
文章强调，计算虚拟用户数应使用会话级公式：并发用户 =（每小时会话数 × 平均会话时长秒）/ 3600，而非事务级的Little's Law（RPS × 平均响应时间）。前者模拟真实用户浏览旅程，后者用于服务器线程池容量规划，两者用途不同，建议结合使用。
增长系数的应用
生产遥测反映的是去年的峰值，今年可能更高。文章建议根据业务增长趋势选择1.2x到2.0x的增长系数，并额外乘以1.1的安全缓冲，以覆盖峰值分钟内的流量尖峰。这确保压测目标面向未来，而非历史。
Q&A
如何从生产遥测数据自动构建负载测试的工作负载模型？
通过使用可观测性工具（如New Relic或Dynatrace）执行六步查询流程：识别峰值日、峰值小时、峰值分钟、场景混合、并发用户和活跃会话，直接从生产遥测数据推导出RPS目标、虚拟用户数和场景权重，并应用增长系数。
Peak Workload Analyzer工具是什么？它如何帮助减少工作量？
Peak Workload Analyzer是一个Java Spring Boot应用，自动执行六步查询流程，连接New Relic或Dynatrace，自动计算并发用户、识别用户旅程，并生成交互式仪表板和JSON报告。它将传统13-22小时的手动工作缩短至5分钟，减少99%的工作量。
如何确定负载测试的RPS目标？
通过查询峰值分钟内的请求数，除以60得到基线RPS，再乘以增长系数和安全缓冲（1.1）得到最终目标。例如，峰值分钟4800请求，基线80 RPS，1.3倍增长和1.1缓冲后为114 RPS。
如何计算负载测试中的并发用户数？
使用公式：并发用户 = (每小时会话数 × 平均会话时长秒) / 3600。例如，峰值小时4280个会话，平均时长444秒，则并发用户为529，应用1.3倍增长后为688 VU。
如何确定负载测试中的场景权重？
通过查询峰值小时内实际发生的交易和URL分布，以及漏斗分析，得到每个场景的流量占比。例如，首页→浏览分类占28%，搜索→产品列表占23%等，这些百分比直接作为场景权重。
为什么在负载测试中要使用增长系数？
因为生产遥测数据反映的是去年的峰值，今年的流量可能更大。增长系数用于调整目标，以测试未来的流量。建议根据业务增长选择1.2x（保守）、1.3x（中等）、1.5x（激进）或2.0x（压力上限）。
如何从用户旅程数据中构建负载测试场景？
通过四查询链（7A-7D）分析每个会话的入口、出口、页面访问和结果，生成入口×出口矩阵和结果计数，从而确定每个用户旅程的权重和VU分配。例如，转化、购物车放弃、支付失败等结果分类。
手动构建工作负载模型有哪些风险？
手动方法耗时13-22小时，依赖人工猜测，容易出错，导致低估峰值流量或错误假设用户旅程，造成资源过度或不足配置，影响业务准备。
