运维/SRE 工程师面试题与常见问题：回答思路

练习题与回答骨架

1. 讲一次你处理过的线上故障,从发现到恢复的完整过程

回答骨架:

• 交代背景:什么系统、影响范围多大、持续多久、怎么被发现的
• 讲处置顺序:先做了什么止损动作,再怎么一层层缩小范围
• 说清根因,以及当时判断根因的依据是什么
• 给出后续改进:补了什么监控、改了什么流程,后来有没有再犯

2. 服务等级目标怎么定?和服务等级协议、服务等级指标是什么关系

回答骨架:

• 先分清三者:指标是测量项,目标是内部承诺的数值,协议是对外的合同约束
• 说明指标怎么选:要贴近用户实际感受,比如请求错误比例和延迟分位数,而不是机器负载
• 讲目标值怎么定:参考历史水位和业务容忍度,定得过高会让团队疲于奔命
• 补上统计口径:按什么窗口算、用哪个分位数、哪些请求要排除

3. 错误预算是什么?它在实际工作中怎么用

回答骨架:

• 解释来源:目标不是百分之百,允许的偏差就是可以消耗的预算
• 讲实际用法:预算充足时可以更激进地发布,预算快用完时收紧变更
• 说明它的最大价值是把稳定和速度的争论变成有数可依的决策
• 承认落地难点:需要业务和开发共同认可这套规则,否则只是运维单方面的表格

4. 告警太多、大家都麻木了,你怎么治理

回答骨架:

• 先统计现状:哪些告警最多、其中多少条真的需要人介入
• 分类处理:能自愈的自动化处理,不需要立刻响应的降级成日报,重复的做聚合收敛
• 给告警定标准:每一条都要能回答"收到后我要做什么",做不到就该删掉
• 建立回顾机制,定期复盘无效告警,防止规则只增不减

5. 一个接口响应突然变慢,你的排查思路是什么

回答骨架:

• 先确认范围:是单接口还是全站、单机还是全部节点、什么时候开始的
• 优先排查变更:最近有没有发布、改配置、调整依赖
• 按层往下:入口和网关、应用自身、下游依赖和数据库、再到系统资源和网络
• 每一层说清用什么手段验证,并强调先止损再深挖

6. 怎么做容量规划

回答骨架:

• 先建立基线:当前资源用量、单机能承载的量、瓶颈在哪个资源上
• 结合业务节奏预测增长,尤其是可预期的峰值活动
• 用压测验证推算结果,不能只靠线上均值线性外推
• 给出提前量和预案:什么水位触发扩容,以及扩容需要多长时间

7. 故障复盘怎么做才有价值

回答骨架:

• 明确目的是改进系统而不是追责,对事不对人
• 讲清必备内容:时间线、影响面、根因、当时为什么没更早发现、为什么恢复用了这么久
• 强调改进项要有负责人和时间点,并且后续要验证是否落地
• 补一句:同类故障是否重复发生,是检验复盘是否有效的唯一标准

8. 你们的发布流程是怎样的?怎么保证可以回滚

回答骨架:

• 讲清流程:代码合并、构建、测试环境验证、灰度、全量的完整链路
• 说明灰度策略:按比例还是按节点、观察哪些指标、观察多久
• 回滚方案要具体:回滚需要多长时间、数据库变更怎么处理、有没有真的演练过
• 补上变更窗口和审批规则,尤其是高风险时段的约束

9. 怎么推动开发团队配合做稳定性改进

回答骨架:

• 先用数据说话:把问题量化成影响时长、影响用户范围、重复次数
• 把要求转成对开发有价值的表述,比如减少被打扰的次数、缩短排查时间
• 提供工具和模板降低对方成本,而不是只提要求
• 借助复盘和目标机制把改进项变成有共识的待办,而不是私下催促

10. 你搭过哪些自动化运维能力

回答骨架:

• 挑一到两个真正上线并被别人用起来的,而不是罗列工具清单
• 说清替代了什么人工动作,节省了多少时间或降低了什么风险
• 讲一个设计上的取舍,比如为什么没有做全自动而保留人工确认
• 补上推广过程:怎么让其他同事愿意用

11. 备份和容灾方案你怎么验证有效

回答骨架:

• 强调没验证过的备份等于没有备份
• 说明验证方式:定期做恢复演练,记录恢复所需时间和数据丢失范围
• 讲清两个关键指标:能容忍多久不可用、能容忍丢多少数据
• 补充演练发现的真实问题,比如备份文件损坏、恢复文档过期、权限缺失

开口练习与复盘

先选一道题，结合本人经历说清背景、个人动作与依据。录下来听一遍，标出重复、跳步和暂时说不清的地方；补充资料后再用自己的话讲一次，对比表达顺序与完整度。练习材料不代表招聘方的题目、流程或评价标准。