解读

国内一线互联网及金融公司面试时，这道题考察的是“把模糊体感翻译成可验收指标”的能力。业务方只会用“慢”“卡”“崩”描述，面试官希望听到你：

1. 用业务语言先共情，再引导；
2. 用分层模型（用户层、网络层、服务层、数据层）快速定位“慢”发生的边界；
3. 把“慢”拆成可测量的三维指标：时间（RT）、容量（TPS/QPS）、质量（成功率、错误码）；
4. 给出可落地的验收阈值，并反向映射到 SLA、峰值流量、日活、营销节奏等商业变量；
5. 同时兼顾国内监管与行业惯例，如银保监会 99.9%、工信部重大故障 30 分钟上报等硬性红线。

知识点

1. 业务建模：UV→PV→峰值并发公式、二八原则、漏斗转化率。
2. 性能指标：RT（P50/P95/P99）、TPS、QPS、并发数、吞吐量、错误率、CPU/Load/内存/IO/网络利用率。
3. 基准法：基线对比（上周同期、上版本）、竞品对标（支付宝/微信公开 SLA）。
4. 容量换算：峰值 QPS = 日活 × 人均访问次数 × 峰值系数 ÷ 86400 × 业务放大倍数。
5. SLA 常见阈值：金融交易类 99.9% 成功率、P99 RT≤500 ms；电商秒杀 P99 RT≤1 s、成功率≥99%；政府类系统 P95 RT≤3 s。
6. 国内监管：银保监会《商业银行应用程序接口安全管理规范》、央行《非银行支付机构检测认证指南》对交易响应、灾备 RTO/RPO 的量化要求。
7. 需求分级：核心交易、次核心查询、后台批处理，分别给指标，避免“一刀切”。
8. 可测性原则：指标必须“可重复、可观测、可验收”，用 Prometheus、SkyWalking、ARMS 等工具可直接采集。

答案

我会用“五步量化法”把“系统慢”变成可验收的性能需求。

第一步，建立共情并锁定场景
先跟业务方确认“慢”发生的入口：是 App 首页加载、下单支付，还是后台导出报表？再确认“慢”的用户量级：是全员还是个别省份？同时记录发生时段，是否与大促、发券、批量代扣重叠。

第二步，采集体感数据
在业务方现场复现，用抓包工具（如 Charles、Fiddler）记录 HTTP 耗时，用 APM 探针看方法级 RT。假设抓到“下单接口平均 2.3 s，P99 5.1 s，错误率 1.8%”，就把“慢”初步量化成“P99 RT 5.1 s”。

第三步，对标行业与监管 SLA
金融核心交易监管要求 P99≤500 ms、成功率≥99.9%；公司去年双十一峰值 P99 600 ms。综合给出版本目标：P99 RT≤600 ms，成功率≥99.9%，TPS 支撑 1.2 万/秒，较当前提升 8.5 倍。

第四步，容量换算与确认
根据运营给出的日活 800 万、下单转化率 12%、峰值系数 5，计算峰值 QPS = 800w×12%×5÷86400 ≈ 556 TPS；考虑营销 10 倍突发，最终峰值目标定为 1.2 万 TPS。业务方签字确认“只要不超过 1.2 万 TPS，系统需满足上述 RT 与成功率”。

第五步，落地到测试用例
用 JMeter 在生产等配容器云环境压测，阶梯线程 5 min 内从 0 加到 1.5 万 TPS，持续 30 min，监控 RT、错误率、CPU、Load、GC、DB 慢 SQL。若 P99 RT>600 ms 或错误率>0.1%，即视为不达标，出具火焰图与 SQL 报告，推动代码或索引优化，回归通过后方可发布。

通过以上五步，“系统慢”就被转化为可量化、可验收、符合国内监管及行业惯例的性能需求：
“在 1.2 万 TPS 峰值压力下，下单接口 P99 RT≤600 ms，成功率≥99.9%，CPU≤60%，Load≤核数*1.5，无重大 GC 停顿。”

拓展思考

1. 如果业务方补充“还要支持 2025 年春节红包，日活翻 3 倍”，你如何快速重估峰值模型？
2. 当指标达成后，生产环境仍出现“用户体感慢”，但监控 RT 正常，你会如何引入“前端首屏时间、CDN 边缘耗时、客户端解析耗时”来重新刻画 SLA？
3. 面对监管现场检查，你如何证明“P99 RT≤600 ms”不是事后拼凑，而是持续 7×24 达标？需要哪些原始监控数据与留痕流程？