解读

面试官真正想考察的是：在没有“现成数据”这一安全网的情况下，候选人能否用“业务语言”把容量需求翻译成“技术语言”，并快速给出一个可落地、可验证、可迭代的性能模型。国内互联网节奏快、版本迭代频繁，很多初创业务或新模块确实拿不到历史日志，却要在两周内交出压测结论。此时，建模思路是否结构化、数据来源是否合规、指标是否可回溯、模型是否预留校准通道，是评分关键。

知识点

1. 业务预测三要素：日活/峰值DAU、核心场景转化率、业务增长系数（促销、扩城、投放）。
2. 竞品数据四来源：公开财报、行业白皮书、第三方数据平台（QuestMobile、艾瑞）、灰度抓包（仅接口维度，脱敏）。
3. 漏斗模型：UV → 场景PV → 接口QPS，层层放缩。
4. 并发度公式：并发数 = 峰值QPS × 平均RT（秒）。
5. 业务系数：峰值系数（35倍）、冗余系数（1.52倍）、未来3~6个月增长系数（视业务节奏）。
6. 模型校准策略：上线后通过APM埋点、网关日志、灰度流量对比，两周内完成第一次修正；大促前第二次修正。
7. 国内合规红线：抓取竞品数据不得涉及用户隐私、不得逆向破解，仅统计量级与趋势。

答案

我会把建模拆成“三步七表”，输出一份《初始容量评估报告》，评审通过后再落地压测脚本。
第一步：业务预测

1. 找产品运营拿到未来3个月日活目标，假设给到“峰值DAU 100万”。
2. 梳理核心场景漏斗：首页 → 商品详情 → 加购 → 下单 → 支付，转化率依次为100 %、45 %、20 %、10 %、9 %。
3. 计算各场景峰值PV：以“商品详情”为例，100万DAU × 45 % = 45万PV；按“8二法则”20 %时间贡献80 %流量，峰值PV=45万×0.8/(0.2×24×3600)≈21 PV/s。
   第二步：竞品对标
4. 去QuestMobile拉同赛道Top3 App的“人均日启动次数”“人均使用时长”，取中位数，得到“单次会话平均22分钟、日均启动4.2次”。
5. 用抓包工具对自己App和竞品同功能接口采样，发现详情页接口平均RT 180 ms，竞品 150 ms；把RT目标定在 120 ms，留20 %余量。
6. 参考竞品去年双11公开战报，峰值QPS是日均峰值的4.6倍，我把峰值系数暂定为5。
   第三步：合成初始模型
7. 接口QPS = 21 PV/s × 5（峰值系数）× 1.5（冗余）≈ 158 QPS。
8. 并发数 = 158 × 0.12 s ≈ 19 并发；考虑思考时间3 s，并发再放大到 60。
9. 容量层推导：单机8C16G容器历史经验值 400 QPS，158 QPS只需 1 实例，但可用区容灾要求双活，最终给 2 实例。
10. 把以上数据写进报告，同时给出“假设清单”：DAU误差±20 %、峰值系数误差±1、RT目标误差±30 %；并约定上线后两周内用网关日志回灌模型，误差>15 %即触发重评。

这样，即使没有任何历史日志，也能在3个工作日内拿出可评审、可压测、可校准的初始性能模型。

拓展思考

1. 如果业务是“toB SaaS”而非“toC App”，DAU概念失效，可改用“租户数 × 同时在线率 × 人均活跃接口数”来建模。
2. 对金融支付类场景，监管要求“强一致”和“零差错”，冗余系数要放到2倍以上，且需把TPS与账务平衡校验耗时纳入模型。
3. 当竞品也找不到数据时，可退而求其次：用“业务目标倒推”——先确定营收目标，再按客单价、订单量反推QPS，同时把不确定性写进风险登记册，申请预生产环境做“极限探测压测”，用系统实际崩溃点来标定上限。