解读

在国内敏捷交付节奏下，NFR（非功能需求）常被“一句话”带过：系统要“快”、要“稳”、要“能扛双11”。性能测试工程师如果只在显性指标里打转，上线后往往会踩坑——不是CPU飙高被限流，就是半夜被运维打电话“磁盘打满”。隐性需求不写在合同里，却直接决定SLA能否兑现。面试官问这道题，想看候选人能否跳出“并发2000、RT<500ms”这种表面数字，从运维、安全、成本、用户体验等维度把“没说出口但必须做”的需求挖出来，并给出可落地的验证方案。

知识点

1. 隐性需求：未被明确写进PRD、却会在生产环境触发故障或投诉的性能相关约束，包括资源、弹性、可观测、合规、成本、用户体验等维度。
2. 资源上限与突发抑制：云原生时代，K8s Request/Limit、云主机突发网络包、共享型云盘IOPS、带宽突发计费模式等，都会让“压测达标、上线翻车”。
3. 弹性与冷启动：国内微服务+容器场景下，HPA缩容到0后首次流量高峰、函数计算冷启动、JVM CDS/AppCDS未预热，带来的RT尖刺远超压测模型。
4. 可观测完整性：Trace/Metrics/Log 采样率、线程池队列长度、Netty直接内存、Off-Heap、G1 Region大小等指标未暴露，导致线上出现“性能黑洞”无法定位。
5. 成本边界：云账单与性能挂钩，SLA每提高一个9，成本指数级上升；压测时若未评估“极限场景下的最大账单”，财务部门会在月底“追责”。
6. 合规与限流兜底：等保2.0、央行《分布式系统技术指引》、银保监“业务高峰保障”检查，都要求“在突发流量下具备降级、限流、熔断能力”，但PRD往往只字未提。

答案

最容易被忽略、却最让国内团队“交学费”的三项隐性需求如下，并给出评审时可直接落地的检查单：

1. 资源上限与突发抑制
   隐性点：云主机/容器的“突发网络包数”“共享盘IOPS突增余额”“NAT网关并发连接数”等硬限制，在PRD里不会写，但压测一旦触顶，云厂商直接丢包或限流，RT瞬间飙高。
   评审动作：

   • 让运维导出当前账号的Quota清单，把“网络PPS、内网带宽、单盘IOPS、Pod最大PID、容器最大打开文件数”全部转成可量化的NFR条目。
   • 在压测方案里设计“阶梯突击”模型，5分钟内从0打到峰值，观察云监控是否出现“CPU积分耗尽、带宽突发余额归零”等事件。
   • 输出《资源红线表》，明确“达到80%即触发扩容或限流”，并写进SLA。

2. 冷启动与弹性滞后
   隐性点：国内为了省成本，测试环境Pod副本数常设1，生产环境HPA最小副本也设1；大促流量一来，HPA 30秒才能拉起新Pod，JVM+容器启动再耗20秒，这50秒空白期RT暴涨，用户投诉“卡死”。
   评审动作：

   • 把“冷启动RT95线”单独列为NFR，要求“从0副本到可服务<15s”，并指定预热方案：镜像预拉取、JVM AppCDS、Spring AOT、静态资源懒加载关闭。
   • 在压测脚本里增加“从0并发直接打到峰值”的脉冲场景，用SLA断言“冷启动期间错误率=0、RT95不超过基线3倍”。
   • 推动研发在启动探针里暴露“就绪时间”指标，方便监控自动比对。

3. 可观测黑洞与成本封顶
   隐性点：Trace采样率设1%，导致大促时1万QPS只有100条Trace，错过慢请求；为了保SLA盲目扩容，云账单翻倍，财务事后追责。
   评审动作：

   • 把“可观测完整性”写进NFR：Trace采样率动态可调，错误>5%时自动升到100%；线程池、直接内存、GC次数、云账单小时粒度全部接入监控。
   • 压测期间同步记录“每1万并发对应成本”，输出《性能-成本曲线》，让业务方签字确认“可接受的最大账单”。
   • 设定“成本熔断阈值”：单小时费用超过X元即触发自动降级，用配置中心开关，提前在压测环境演练。

把这三项隐性需求转成可度量、可验证、有红线的NFR后，性能测试报告就不再是“RT、TPS、CPU、内存”四件套，而是可以直接给运维、财务、合规同时签字的“生产准入证明”。

拓展思考

1. 如何把“隐性”变“显性”：建立《NFR检查清单》模板，按“资源、弹性、可观测、成本、合规、用户体验”六维打分，0分代表完全未提及，5分代表已写进SLA并有自动化验证。每次需求评审前，性能测试工程师先跑一遍清单，缺失项直接拍桌子“需求不接收”。
2. 与FinOps结合：把压测产生的云账单实时推送到财务群，让业务方在“性能”与“成本”之间做权衡，避免“性能达标、公司亏钱”。
3. 法规驱动：等保2.0、央行《金融分布式系统技术指引》已明确“高峰流量下具备限流、熔断、降级”能力，下次评审可直接把法规条款贴进PRD，让产品无法回避。
4. 灰度与演练：隐性需求验证必须进“全链路灰度”环境，用生产真实流量1%做探针，结合Chaos工程注入“Quota打满、Pod驱逐、NAT连接耗尽”等故障，观察系统是否满足隐性NFR，真正做到“先验证、再上线”。