Linux 运维工程师面试题精选（四）：场景处置与故障应急
场景题最难蒙混：没有标准答案，但动作顺序对不对、第一反应是止损还是查根因，一听就知道有没有真值过班。这一组八个场景全部来自真实高频故障，答案按"先做什么、后做什么"排列。多数场景后附面试官常用的追问，专用来区分"背过答案"和"真处理过"。
本文题目一览
- 场景一：凌晨告警，网站大面积 502
- 场景二：磁盘被日志打满，业务不能停
- 场景三：数据库主从延迟持续扩大
- 场景四：证书过期导致服务不可用
- 场景五：误执行 rm / 改错配置的止损与恢复
- 场景六：机房断电 / 网络中断的应急动作
- 场景七：发布后大面积报错，回不回滚
- 场景八：内存泄漏服务拖垮整机
场景题
场景一：凌晨 3 点告警，网站大面积返回 502，你是值班，怎么处置？
背景：监控显示核心站点 5xx 比例超过 30%，电话告警已响，你手边只有一台笔记本。
先止损、后定位，第一目标是恢复可用性，而不是当场查清根因。
- 确认影响面（1 分钟）：全站还是局部、单机房还是全部，避免对局部问题做全局动作
- 顺链路定位：负载均衡健康检查 → 后端实例存活 → 应用进程与端口 → 机器资源
- 先看变更记录：故障前 1 小时有无发布、配置变更、扩容，有则优先回滚或摘除新实例
- 快速止损：摘异常实例、重启明确假死的进程、流量切健康机房，并同步值班群
- 恢复后留现场：保留日志和监控快照，根因分析放到白天
追问：后端实例都活着、进程也在，还有什么会导致 502？——连接数打满或监听队列溢出、后端响应超时被网关断开、健康检查与业务路径不一致。
场景二：业务高峰期，一台服务器根分区被日志打满，但业务不能停，怎么处理？
背景：磁盘 100%，应用还在跑，停机窗口要等到夜间。
先腾空间、再治来源。绝不直接 rm 正在写入的日志：句柄不释放，空间不返还，还丢现场。
- 先定位：
df -h看分区，du逐层找大目录，确认是日志、转储还是数据增长 - 查已删除仍被占用的空间：
lsof +L1，只能靠进程重开日志或重启释放 - 正在写的日志用清空代替删除：
truncate -s 0，空间立即释放且不影响写句柄 - 临时腾挪：历史日志迁到其他分区或挂临时盘，并盯住释放速度
- 根治：查暴涨原因（报错刷屏还是没轮转），补 logrotate 并验证，加磁盘分级告警
lsof +L1 | grep deleted # 找出已删除仍占空间的进程
truncate -s 0 /var/log/app/app.log # 清空正在写入的日志，立即释放空间
追问：df 显示满了但 du 加起来对不上，差的空间去哪了？——已删除未释放的句柄占用、文件系统保留块、挂载点下被遮住的老文件。
场景三：数据库主从延迟从几秒涨到几千秒，还在持续扩大，怎么处理？
背景：MySQL 主从、读写分离，业务反馈读到的数据越来越旧，延迟告警持续半小时未收敛。
先判断延迟卡在哪个环节，再决定止损方式，不要一上来就重启从库。
- 看从库状态：IO、SQL 线程是否都在跑，延迟在接收还是回放阶段产生
- 根因逐个排除：大事务、单线程回放跟不上并发、从库磁盘 IO 瓶颈、无主键表回放慢
- 止损先保一致性：强一致读切回主库，能容忍旧数据的走从库，先解业务投诉
- 条件允许开并行复制，大事务联系业务方拆分或暂停批量任务
场景四：早上用户反馈网站打不开，排查发现 HTTPS 证书昨晚刚过期，怎么处置？
背景：证书已过期 8 小时才被用户发现，监控没有报警。
先恢复、后追责。证书问题没有"调一调"能好的，第一动作就是换证。
- 确认范围：所有共用这张证书的域名和入口（Web、API、内部服务）一次全查
- 快速换证：有备用证书就立即替换并 reload 网关；自动续期的先查续期为何中断
- 验证不只看浏览器：用命令查有效期和证书链，多节点逐个核对
- 根治：到期分级告警（30/15/7 天）、自动续期加成功校验、建证书台账
# 查任意站点证书的到期时间，适合写进巡检脚本
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -dates
追问：换上新证书后部分老客户端还是报错，可能是什么原因？——证书链缺中间证书、老客户端不支持新签名算法或 TLS 版本、节点间证书不一致。
场景五：同事在生产线上误执行了删除命令（或推错了配置），影响还在扩散，你第一步做什么？
背景：误操作类型不确定：可能是 rm 删了数据目录，也可能是错误配置已下发一半。
第一原则是先冻结事态：停掉扩散通道，再评估损失，"赶紧恢复"往往造成二次破坏。
- 立即止损：停掉批量任务和发布流水线，误操作主机断开自动化通道，防止脚本重试
- 删文件的先保现场：禁止往同一分区写数据，尽快卸载或只读挂载，保住可恢复的数据块
- 改错配置的先回滚：回到上一个已知正确版本，确认服务恢复再谈谁改的
- 按备份恢复并验证：先校验数据完整性和业务可用性，再对外宣布恢复
- 复盘落到机制：高危命令拦截、配置变更双人复核与灰度、删除操作回收站化
场景六：机房突然断电（或专线中断），大量系统不可达，你作为运维负责人先做什么？
背景：凌晨市电中断，UPS 预计撑 40 分钟；或跨机房专线中断。任选其一讲处置顺序。
基础设施级故障拼信息和决策速度：确认范围、保核心、按预案降级，不挨个登机器。
- 5 分钟内定性：向机房、运营商、云厂商确认故障类型、预计恢复时间与影响面
- 保核心：优先保障核心系统供电与流量，非核心主动关机给 UPS 让续航
- 执行预案：流量切备用机房、摘除故障侧，切换前确认备侧容量，双活倾斜最怕把备侧压垮
- 固定同步节奏：每 15–30 分钟通报进展与预计恢复时间
- 恢复后按序拉起：先存储与数据库、再中间件、最后应用，逐层验证再放流量，不要全量自动启动
追问：备机房容量只有主站的 60%，流量全切会怎样、怎么切？——好的回答：按优先级分级切入，非核心只读降级或限流，核心先行并预设熔断阈值，宁可部分降级不要全站雪崩。
场景七：新版本发布 10 分钟后错误率飙升，业务方在催，你回滚还是热修？
背景：灰度已放到 50% 流量，核心接口错误率从 0.1% 涨到 8%，开发说"给我 20 分钟定位"。
默认动作是回滚。故障时刻的决策标准只有一个：哪条路径恢复更快、风险更低。
- 先看爆炸半径：还在灰度还是已全量、是否涉及数据写错（写错的数据要单独处理）
- 回滚条件预先明确：错误率超阈值、无把握短时定位、涉及资金或数据正确性，任一满足立即回滚
- 回滚要完整：应用、配置、数据库变更按发布单逆序退回，退完验证错误率回到基线才算止损完成
- 热修只在一种情况可选：根因已完全明确、改动极小且可灰度验证，否则就是拿生产做实验
场景八：一台机器上的服务内存持续上涨，最终把整机内存吃满、连带其他服务被 OOM 杀掉，怎么处置和善后？
背景：机器混部了几个服务。凌晨整机内存耗尽，OOM killer 杀掉了无辜的数据库进程，泄漏的服务反而还活着。
先隔离故障源保住整机，再谈泄漏定位；善后的重点是让单个服务的问题不再升级成整机问题。
- 紧急止损：按 RSS 排序确认内存大户，限流或摘除泄漏服务，必要时受控重启，优先保同机核心服务
- 定位泄漏：看曲线区分真泄漏（单调涨不回收）与流量突发、缓存膨胀，结合发布时间判断是否新引入
- 资源隔离整改：用 systemd/cgroup 给服务设内存上限，泄漏者死在自己围栏里；调 OOM 分数保护核心进程
- 监控补盲：加单进程内存增速告警，不只看整机水位
# 给服务划内存围栏（systemd），泄漏时只杀自己不拖垮整机
# 在 unit 的 [Service] 段加入：
# MemoryMax=4G
# OOMScoreAdjust=-500 # 核心服务降低被 OOM 命中的概率
追问：怎么判断是内存泄漏而不是正常缓存增长？——看长曲线是否单调上涨、重启后是否从低位重演；缓存增长会趋于平台，必要时对比堆快照的对象分布。
面试官视角
这组题考三件事：动作顺序、止损意识、善后完整性。真处置过故障的人开口先讲确认影响面和止损，再讲定位；只背过理论的人会一头扎进查日志、看代码，十分钟过去故障还在扩散。
- 加分回答：先定影响面再动手；止损动作明确（摘流量、回滚、切备侧）；知道哪些操作不可逆，会先留证据；处置完主动讲复盘预防，而不是"修好就结束"
- 露馅信号：讲原理排不出先后；只会重启且说不出重启前要留什么；回滚全凭感觉、没有阈值概念；从不提对外同步和复盘
- 使用建议：每场挑 3–4 个场景足够，重点用追问验真：把某个动作再往下问一层（"具体敲什么命令""阈值怎么定的"），背题的人第二层就卡住。评分看处置顺序里有没有"先恢复业务"的实际动作
