4. 容量规划与性能优化
容量规划与性能优化是 SRE 面试中的核心考察领域，面试官重点关注你是否具备数据驱动的容量思维、实战性能调优经验以及量化结果输出能力。本章围绕「评估→测试→定位→优化→验证」的完整链路，梳理 3 个高频面试问题及回答框架，并附赠一个真实项目案例模板，帮助你快速构建面试回答体系。
容量评估核心指标速查
| 维度 | 关键指标 | 评估方法 | 常见阈值 |
|---|---|---|---|
| CPU | 使用率、Load Average | 趋势分析 + 压测 | 使用率 < 70% |
| 内存 | 使用率、GC 频率与停顿 | Heap Dump + 压测 | 使用率 < 80% |
| 网络 | 带宽、延迟、丢包率 | 网络压测 + 流量录制 | P99 延迟 < 100ms |
| 存储 | IOPS、吞吐量、延迟 | 存储压测 + 慢日志分析 | IOPS 饱和度 < 80% |
| 应用 | QPS、成功率、P99 RT | 全链路压测 + 容量模型 | P99 RT < 500ms |
📌 面试问题 1：请描述你们团队的容量评估方法
🎯 面试官考察点
- 是否具备数据驱动的容量评估思维，而非凭经验拍脑袋
- 是否掌握主流的容量评估工具与模型
- 能否将评估结果转化为可执行的扩容/优化建议
📐 回答框架
- 数据采集：说明监控指标来源（Prometheus + 自研 Agent）
- 模型建立：时间序列预测 + 业务增长系数
- 阈值判定：结合压测数据与业务容忍度设定水位线
- 输出报告：容量报告 + 预警建议 + 扩容计划
✏️ 示例回答
我们基于 Prometheus + Grafana 构建容量监控体系，采用时间序列预测 + 业务增长模型，每月对核心服务进行容量评估。通过压测确定各服务的容量拐点，输出容量报告，提前 1 个月预警资源瓶颈，并给出弹性伸缩策略建议。
🔍 可能追问
- 如何处理突发流量？预测模型如何保证准确度？
- 容量评估的周期是多久？出现过误报吗？
- 不同业务线（交易/搜索/推荐）的评估方法有何差异？
⚠️ 避坑提醒：不要只说“我们用了 Prometheus”，而没有方法论；避免只谈工具不谈逻辑；务必强调“数据驱动”和“闭环验证”，这是面试官最看重的点。
📌 面试问题 2：性能测试中如何设计负载模型？如何确定容量阈值？
🎯 面试官考察点
- 是否理解真实业务场景与负载模型的映射关系
- 是否掌握阶梯增压、拐点识别等关键测试方法
- 能否将测试结果转化为可落地的容量阈值
📐 回答框架
- 场景分析：基于线上流量录制，提取高峰/均值/突刺三种画像
- 负载建模：按比例设置接口权重 + 思考时间 + 数据倾斜
- 阶梯测试：使用 K6/JMeter 阶梯增压，监控各维度拐点
- 阈值确定：取拐点 80% 作为安全水位，结合业务容忍度微调
✏️ 示例回答
通过分析线上流量特征，构建高峰/均值/突刺三种负载模型。使用 K6 进行阶梯增压测试，监控 CPU、内存、IO 等指标拐点，结合业务容忍度确定容量阈值（如 CPU 70%、P99 500ms）。同时设计混合场景验证多服务并发下的系统表现。
🔍 可能追问
- 如何模拟真实数据分布？数据倾斜怎么处理？
- 如何判断是性能瓶颈而不是测试脚本问题？
- 做过跨集群的全链路压测吗？怎么协调多个团队？
⚠️ 避坑提醒：避免使用均匀负载模型，忽略思考时间和数据倾斜是常见扣分点；不要只给出阈值数字而不说明推导过程；面试官希望看到你对“拐点”和“安全水位”有清晰定义。
📌 面试问题 3：举例说明你做过的一次性能优化，背景、方法和效果
🎯 面试官考察点
- 是否有真实的性能优化实战经验
- 能否清晰描述问题发现 → 根因分析 → 方案实施 → 效果量化的完整链路
- 优化效果是否有数据支撑，是否具备可迁移性
📐 回答框架
- 问题发现：监控告警 / 用户反馈 / 压测数据异常
- 根因分析：Profile → 慢日志 → 代码审查 → 链路追踪
- 方案设计：确定优化层次（应用/中间件/架构/资源）
- 实施与量化：灰度上线 → A/B 对比 → 输出效果指标
✏️ 示例回答
针对订单服务 MySQL 慢查询，通过索引重构 + 读写分离 + 本地缓存分层，将接口 P99 延迟从 800ms 降至 120ms，QPS 从 2000 提升至 8000，节省 4 台 DB 实例。优化后持续监控两周，确保性能未回退。
🔍 可能追问
- 如何确定优化优先级？同时有多个瓶颈时怎么决策？
- 优化后如何防止性能退化？有自动化回归机制吗？
- 同样的优化思路可以迁移到其他服务吗？遇到过不适用的情况吗？
⚠️ 避坑提醒：不要只说“做了优化”而没有量化对比；避免只谈单一维度（只改代码不改架构）；务必包含“优化前 vs 优化后”的具体数值，这是面试官判断真伪的关键。
📁 项目实战参考：电商大促容量保障体系建设
该案例适用于回答“请描述你做过的一个容量规划/性能优化项目”类问题，可直接迁移至面试场景。
| 维度 | 内容 |
|---|---|
| 项目名称 | 电商大促容量保障体系建设（双11/618场景） |
| 业务背景 | 每年大促流量峰值呈爆发式增长，预估峰值 QPS 50 万，需要保障系统不降级、不宕机 |
| 规模指标 | 500+ 微服务节点、100+ 数据库实例、20+ 缓存集群、峰值 QPS 50 万 |
| 技术栈 | Prometheus + Grafana + K6 + K8s HPA + 自研限流组件 + 全链路压测平台 |
| 核心难点 | ① 流量预测难度大，历史数据参考价值有限；② 资源成本与性能保障的平衡；③ 多团队协作，压测与业务开发并行 |
| 面试高频追问 | 如何预估大促峰值流量？容量不足时如何快速响应？限流降级策略如何设计？压测如何不影响线上用户？ |
| 可迁移回答话术 | 建立容量基线 → 自动化弹性伸缩（HPA）→ 兜底限流降级（Sentinel/自研）→ 全链路压测验证 → 事后复盘优化，形成“评估→测试→保障→复盘”的正向循环。 |
💡 加分提示：在面试中引用该项目时，建议同时提及“优化前后资源利用率对比”和“大促实际表现数据”，例如：“通过该体系，大促期间系统整体可用性维持在 99.99%，资源成本降低 35%。”