第2章 高频面试问题与回答框架
SRE架构师面试中，问题虽然千变万化，背后考察的思维模型和答题结构高度一致。本章提炼三大高频问题、一套可迁移的 PRSA 回答框架，并对比不同大厂在稳定性、成本、迭代速度上的侧重点差异，帮助你在面试中快速构建有深度的答案。
公司侧重点对比 —— 同一道稳定性问题，不同大厂考核的优先级不同：
| 公司 | 核心关注点 | 常见追问方向 |
|---|---|---|
| 阿里 | 全链路稳定性、故障演练（Chaos Engineering） | 如何验证降级策略？混沌工程覆盖度？ |
| 字节跳动 | 高并发、容量规划、极致弹性 | QPS翻倍时扩容策略？资源成本控制？ |
| 腾讯 | 混合云、多活容灾、迁移平滑 | 跨城容灾方案？DNS切换时效？ |
| 美团 | 微服务治理、依赖健康、调用链 | 如何避免雪崩？服务降级粒度？ |
📌 面试问题 1：请设计一个高可用架构，确保99.99%可用性
面试官考察点： 架构全局观、技术选型权衡、故障边界定义。
回答框架（PRSA）：
- P 明确99.99%对应年度故障时间约52min，需覆盖单机房故障、流量突发。
- R 常见根因：网络分区、依赖雪崩、资源不足。
- S 多活/主备切换 + 熔断降级 + 自动扩缩容。
- A 微服务拆分、无状态化、异地多活单元化。
- 效果 压测验证、故障注入测量MTTR。
简短示例回答： “我会以异地多活为基线，业务按单元化拆分，每个单元独立扩容。通过DNS切流和跨机房数据同步保障容灾。压测验证下，MTTR控制在5分钟内，年可用性可达99.995%。”
可能追问： 数据最终一致性如何处理？异地多活延迟导致写冲突？成本膨胀怎么办？
📌 面试问题 2：描述一次你处理过的重大故障，以及你的角色和优化
面试官考察点： 故障归因能力、应急响应规范、事后改进闭环。
回答框架（PRSA）：
- P 某电商大促流量超预期，DB连接池耗尽导致核心接口超时。
- R 根因：限流阈值过低 + 缓存未命中导致回源激增。
- S 紧急限流+扩容 + 降级非核心服务；事后优化限流算法和缓存预热。
- A 引入自适应限流（BBR），缓存提前加载。
- 效果 故障后MTTR从25min降至5min，系统韧性显著提升。
简短示例回答： “去年某秒杀活动DB连接池被打满，我作为on-call负责人立刻启动限流并扩容读库。事后分析是缓存未预热导致雪崩。我主导实现自适应限流和缓存预热脚本，后续同场景故障未再发生。”
可能追问： 为什么不用降级代替限流？缓存预热如何保证一致性？有没有做故障复盘汇报？
📌 面试问题 3：SRE如何平衡稳定性与业务快速迭代？
面试官考察点： 工程文化认知、风险控制与实际落地手段。
回答框架（PRSA）：
- P 业务要求每周发布，但稳定性策略不能成为阻碍。
- R 单纯加审批会导致积压，需要自动化门禁和灰度发布。
- S 建立发布质量Pipeline：自动化测试+Chaos实验+灰度观察。
- A 与CI/CD集成，设置安全护栏（回滚、熔断）。
- 效果 发布成功率提升至99.7%，同时交付周期缩短30%。
简短示例回答： “我会设计灰度发布流水线，新版本先导入5%流量，自动监控错误率。同时嵌入Chaos实验，在灰度期注入故障验证降级效果。这样既保证稳定性，又让业务每周可发布。”
可能追问： 灰度比例如何动态调整？Chaos实验影响真实用户怎么办？没人写自动化测试怎么推进？
💡 本章小结： 无论问题如何变换，始终用 PRSA 框架组织答案，并提前准备每个维度对应的量化数据。面试前对照公司侧重点表中高频追问方向，模拟2-3轮追问训练，能显著提升回答的深度和说服力。