解读

面试官问“多久”与“通过标准”，表面看是时间长度和指标阈值，实质在考察三方面的工程判断力：

1. 业务连续性等级：国内金融、运营商、政企系统普遍要求 7×24，稳定性测试必须覆盖“至少一个完整业务周期+垃圾回收/批处理窗口”。
2. 资源泄漏与隐性缺陷的发现概率：经验上 4 h 以内可暴露 80 % 的明显内存泄漏；8–12 h 可暴露连接池、句柄、线程漂移；24 h 以上才容易把“只有凌晨 02:00 触发批处理”或“Full GC 累积”问题逼出来。
3. 成本与风险平衡：云资源按小时计费，国内甲方项目常把“连续 8 h 无异常”写进招标文件，但核心系统验收前必须追加“72 h 长稳”作为强制条目。

因此，回答不能给“一刀切”的小时数，而要给出“选型的方法论 + 可落地的通过标准”，再辅以真实案例，体现资深工程师的决策路径。

知识点

1. 业务周期法：T = 峰值持续时长 ×（2~3）倍，覆盖日终、日初、批处理、缓存重建、定时任务。
2. 资源趋势法：连续采样周期 P ≤ 5 min，线性回归斜率 k；若 k > 0 且置信区间不包含 0，则判定泄漏。
3. 错误率收敛法：按泊松分布建模，累计错误数在 6σ 置信区间外即不通过。
4. SLA 反向推导：若线上 SLA 为 99.95 %，则长稳测试可用 1 – 0.9995 = 0.0005 作为错误率上限，再换算到测试时长内允许的最大错误数。
5. 国内合规要求：人行《金融行业信息系统稳定性保障指南》要求“重要系统长稳测试 ≥ 8 h，核心系统 ≥ 24 h”；工信部《电信设备进网测试规范》明确“48 h 连续负载无重启、无致命告警”。

答案

稳定性测试的持续时间应“以业务周期为核心、以资源泄漏收敛为判停条件”，推荐分三档决策：

1. 常规 Web/APP：≥ 8 h，覆盖日终批处理；通过标准“TPS 衰减 ≤ 5 %，平均响应时间增幅 ≤ 10 %，内存斜率 ≤ 0.5 MB/h，无 OOM、无重启、错误率 ≤ 0.1 %”。
2. 金融支付/核心账务：≥ 24 h，必须跨两个日切；通过标准“TPS 零衰减，响应 99th 增幅 ≤ 5 %，Full GC 间隔不缩短，句柄数、线程数、DB 连接数斜率 ≈ 0，零错误、零告警”。
3. 电信/网关类设备：≥ 48 h，含自动巡检窗口；通过标准“CPU 利用率峰值漂移 ≤ 3 %，内存泄漏 ≤ 1 MB/h，会话表零泄漏，零丢包，零核心转储”。

判停流程采用“7 点法”： ① 每小时采样 100 + 指标；② 连续 3 个采样周期无 Fatal/Error 日志；③ 内存、句柄、线程线性回归斜率 95 % 置信区间包含 0；④ 业务成功率 ≥ 线上 SLA；⑤ 资源峰值预留 ≥ 30 %；⑥ 无人工重启；⑦ 通过代码覆盖率工具确认热点路径均被执行。七项同时满足即可提前结束，否则持续跑到下一检査点，最长不超过 72 h，避免无效资源消耗。

拓展思考

1. 云原生场景：Pod 频繁漂移，稳定性测试需把“滚动发布+HPA”纳入场景，持续 12 h 内完成 3 次版本热更新，验证长连接零中断、指标无跳变。
2. 大数据管道：Spark/Flink 任务采用“24 h 微批+ 1 h 全量批”混合模型，通过标准要额外检查 checkpoint 大小增长、背压趋势、Kafka 消费 lag 是否收敛。
3. 成本优化：利用 Spot 实例做 72 h 长稳，需设计断点续跑与结果聚合脚本，把“中断 ≤ 5 min”视为可接受噪声，既满足合规又节省 70 % 云费用。
4. 结果可视化：在内部复盘会上，用“内存斜率图 + GC 间隔散点图 + 错误率累积图”三板斧向领导汇报，比单纯贴通过/不通过结论更具说服力，也体现性能团队的专业度。