📚 课程目录第2章高频面试问题与回答框架

高频面试问题与回答框架：常见问题、答题结构、公司侧重点

面试中，同一类问题反复出现，但不同公司考察的角度和深度各不相同。掌握通用的回答框架，并针对公司业务特点调整侧重点，是拿下 SRE 岗位的关键。本章拆解 3 道最高频面试题，提供可直接套用的结构，并揭示面试官的深层意图。

🎯 公司侧重点速查

互联网大厂（字节、美团）→ 侧重STAR中的量化结果与改进闭环；金融SRE（银行、证券）→ 关注变更风险管理与合规；云厂商（阿里云、腾讯云）→ 重点考察大规模自动化与成本优化能力。

面试问题	请描述一次你主导解决的重大线上故障，你是如何排查和恢复的？
考察点	故障排查思路、应急决策、团队协作、事后复盘能力；是否具备SRE的“事后问责”到“事后改进”思维。
回答框架	STAR结构：情境（业务峰值+异常表现）→ 任务（恢复目标+止损）→ 行动（诊断链路、影响评估、止血操作）→ 结果（MTTR、改进项落地）。
示例回答	去年双11大促期间，数据库CPU飙升90%。我快速定位到异常慢查询，紧急Kill会话并限流。同时扩从库分担读压力，15分钟内恢复。事后提交分析报告，推动慢查询治理及变更审批流程，后续同类故障减少80%。
可能追问	1. 为何不直接重启？怎样确保Kill操作不影响事务？2. 事后复盘发现了哪些团队协作盲点？3. 如果资源无法扩容，你会怎么做？
避坑提醒	❌ 只讲技术细节，忽略监控、告警和沟通；❌ 归因单一，未体现根因分析；❌ 结果缺乏量化指标（如MTTR从30min→5min）。

面试问题	请解释什么是错误预算，以及它在SRE实践中如何落地？
考察点	对SRE核心理念的理解、风险量化思维、是否具备产品与稳定性平衡的视角。
回答框架	PREP结构：观点（错误预算=可接受的不稳定时间）→ 理由（平衡发布速度与可靠性）→ 举例（99.9%可用性每月约43分钟预算，耗尽则暂停发布）→ 重申（是SRE决策的核心量化工具）。
示例回答	错误预算是服务SLO与实际可用性之间的差距。比如SLO设定99.95%，那么每月允许宕机约21分钟。团队监控预算消耗，当预算低于20%时，优先修复稳定性；预算耗尽则紧急冻结新功能发布。这让我们平衡了迭代速度和用户信任。
可能追问	1. 你们公司如何设定SLO？是基于历史数据还是业务目标？2. 错误预算被耗尽后，团队如何应对？3. 多层级服务（如基础层、业务层）的错误预算如何联动？
避坑提醒	❌ 只背定义，没有结合自身业务案例；❌ 认为错误预算只用来“禁止发布”，忽视了预算用于指导日常资源投入；❌ 不提及监控和告警触发逻辑。

面试问题	当线上告警发出后长时间无人响应，你会怎么做？
考察点	应急意识、升级机制、主动推动改进的能力、对告警疲劳的理解。
回答框架	三段式：1) 立即响应并确认告警有效性 2) 按升级路线逐级通知（一线→二线→值班经理）3) 事后推动告警去重、分组合并、调整SLA。
示例回答	首先我会立刻查看告警详情，确认不是误报后，通过on-call群@责任人；若5分钟未响应，升级至其Leader；同时开始预排查（如查看基础监控）。事后推动优化告警分组，降低噪音，并规范升级流程，将响应时间从10分钟降至2分钟。
可能追问	1. 如果升级后仍无人，你会直接操作吗？有什么风险？2. 如何判断告警是否需要立即响应？3. 告警数量太多导致疲劳，你有什么优化方案？
避坑提醒	❌ 只说“等别人来处理”，缺乏主动性；❌ 跳级操作却未说明风险评估；❌ 不提及事后改进闭环，只讲应急。

💡 高频追问自检清单

⚠️ 常见失分点

1. 回答空洞，只说“我排查了日志”却不讲具体日志类型和排查链路；2. 只讲一次成功案例，无法举一反三；3. 对追问准备不足，被问到边界条件时卡壳。