Linux 运维工程师面试题精选（三）：项目深挖与简历追问

基础题答得再流利，也替代不了项目深挖。简历上写着"主导自动化运维平台""负责公司监控体系"的候选人很多，经得起三轮追问的却不到一半。这一组题不问概念，全部顺着简历往下挖：先问架构和数据，再问选型取舍，最后问踩过的坑和事故，面试官可按回答深度决定追到哪一层。

本文题目一览

• 自动化平台：架构分层与执行通道选型
• 自动化平台：为什么选 Ansible（或自研）
• 自动化平台：上线后踩过最大的坑
• 监控体系：核心服务的 SLI 怎么定
• 监控体系：告警治理的真实数据口径
• 监控体系：监控没发现的那次故障
• CI/CD：从提交到上线的流水线分段
• CI/CD：应用与数据库的回滚策略
• CI/CD：印象最深的一次发布事故
• 批量运维：上千台主机变更的灰度与验证
• 批量运维：巡检结果汇总与异常闭环
• 备份容灾：RPO/RTO 是怎么定出来的
• 备份容灾：恢复演练做没做过
• 备份容灾：备份完整性与防勒索

方向一：自动化运维平台与脚本项目

题 1：你简历上写主导了自动化运维平台，先讲它解决了什么问题，整体架构怎么分层？

先讲痛点和收益，再讲架构。只报功能清单、不说省了多少人力的，参与度要打折。

• 痛点要具体：比如新机交付原来 2 天、上线后 40 分钟，数字能对上时间线
• 分层能说清：接入层（Web/API）、编排层（任务流、审批）、执行层（Agent 或 SSH 通道）、数据层（CMDB、执行记录）
• 执行通道的取舍讲得出来：Agent 长连接可控但要部署维护，SSH 无侵入但并发和审计弱

题 2：为什么选 Ansible（或自研脚本框架），不用 SaltStack 或 Puppet？

考的是选型有依据，而不是用过哪个就吹哪个。好的回答一定带当时的约束条件。

• 能对比维度：无 Agent 与否、推送还是拉取、并发规模、学习成本、生态
• 结合自身规模：几百台和几万台的选型结论完全不同，说清自己的盘子
• 讲得出所选工具的短板：比如 Ansible 大并发下的 forks 调优、SSH 连接复用的坑

题 3：平台或脚本上线后，踩过最大的坑是什么？

这一问分水岭最明显。真做过的人立刻能想起具体事故，包装的人只会说"没什么大问题"。

• 高频真实答案：脚本不幂等改坏配置、批量任务没限流打满带宽、凭据明文写在脚本里被审计挑出
• 定位过程讲得清：从哪个日志、哪个指标发现，怎么缩小范围
• 整改落在机制上：加幂等校验、执行前 dry-run、凭据进 Vault、批量任务分片限速
• 影响范围和持续时间说得出，不回避、不夸大

方向二：监控体系建设项目

题 4：你们核心服务的 SLI 是怎么定的？为什么不能只看机器指标？

考指标选型的层次。停留在 CPU、内存、磁盘三件套的，监控还停在资源层，没走到业务层。

• 能区分资源指标、服务指标、业务指标三层，并说清各层用途
• SLI 从用户侧定义：请求成功率、P99 延迟、核心接口可用性，而不是"机器还活着"
• 知道黄金指标（延迟、流量、错误、饱和度）并能结合自己的服务裁剪

题 5：告警治理你简历上写"告警量下降 70%"，这个数是怎么统计出来的？

专问数据口径。治理类成果最容易注水，口径说不清，数字就是编的。

• 口径定义清楚：统计周期多长、按原始条数还是聚合后的事件算、基线取哪个月
• 手段分得出主次：阈值调优、聚合抑制、告警分级、无效告警下线，各占多少贡献
• 不只看降量，还看质量：有效告警率、平均确认时间、夜间告警占比同步改善没有

题 6：讲一次监控没发现、靠用户投诉才知道的故障，后来怎么补的？

考盲区意识和复盘能力。声称"监控从来没漏过"的，可以直接扣分。

• 典型盲区说得出：第三方依赖、证书有效期、批处理任务、业务逻辑型错误（返回 200 但内容错）
• 补的手段对路：黑盒拨测、合成流量、业务埋点对账，而不是再加几个机器指标

方向三：CI/CD 落地项目

题 7：画一下你们的流水线，从代码提交到生产上线分哪几段，每段卡什么？

考流水线的完整度。只说得出"打包、部署"两段的，多半只参与了其中一小块。

• 分段完整：扫描 → 单测 → 构建镜像 → 镜像扫描 → 预发 → 自动化测试 → 灰度 → 全量
• 每段的质量门禁说得清：覆盖率阈值、高危漏洞阻断、测试通过率，卡不住的流水线等于没卡
• 制品只构建一次、逐环境晋升，而不是每个环境重新打包

题 8：发布出问题怎么回滚？如果这次发布带了数据库变更呢？

应用回滚人人会说，数据库回滚才是分水岭。答不出兼容发布，基本没主导过带库变更的上线。

• 应用侧分得清三件事：版本回退、流量切回、配置回滚
• 数据库讲得出扩展-收缩：先加新列双写、再切读、最后删旧列，每一步可回退
• 知道哪些变更不可逆：删列、改字段类型、大批量订正，要提前备份和回滚脚本
• 回滚有触发标准和决策人：错误率到多少、谁拍板，而不是"看情况"

题 9：讲一次印象最深的发布事故。

与题 3 呼应，但聚焦发布链路。重点听归因是否诚实、整改是否系统。

• 事故链条完整：什么变更、为什么没测出来、监控为什么没先于用户报警、止损动作是什么
• 归因不甩锅：能区分直接原因和流程缺陷（没灰度、没开关、评审走过场）
• 整改有闭环：加功能开关、补灰度比例、改回滚脚本，并验证过有效

方向四：大规模批量运维

题 10：给上千台主机做一次批量变更（比如内核升级），灰度和验证怎么做？

考批量操作的工程化程度。敢说"写个循环一把梭"的，不管经验几年都要警惕。

• 分批策略明确：按机房/业务线分批，先 1 台、再 1%、再 10%，每批有观察窗口
• 执行前有前置检查：磁盘空间、业务状态、是否在冻结期黑名单
• 验证自动化：变更后跑健康检查（进程、端口、关键接口），失败自动停批
• 失败处置有预案：单批失败率超阈值自动暂停，坏机器先摘流量

# 分批执行的常见控制方式（以 Ansible 为例）
ansible web -m ping --forks 20              # 先探活，剔除不健康节点
ansible web --limit 'web[0:5]' -a "uptime"  # 小批先行，观察后再放大

题 11：定期巡检上千台主机，结果怎么汇总成一份能看的结论？异常怎么闭环？

考从数据到结论的能力。巡检不是把一万行输出打包发群就算完。

• 结果结构化：每项检查有阈值和结论（正常/警告/严重），不是原始命令输出
• 汇总分层：全局概览 → 按业务线聚合 → 异常明细，Top 问题一眼可见
• 异常有跟踪：负责人、期限、复检结果，老问题重复出现能统计出来

方向五：备份容灾项目

题 12：你们系统的 RPO 和 RTO 分别是多少？这个数是怎么定出来的？

先问数字，再问来源。张口就是"RPO 为零"的，先追问他用什么技术实现的。

• 数字与业务挂钩：核心交易系统和内部报表的要求不同，能分级说
• 来源讲得清：业务能承受的数据丢失和停机时长，技术再倒推方案，不是技术自己拍
• 知道成本随指标陡增：同步复制、双活、异地多活分别对应什么量级的 RPO/RTO

题 13：恢复演练做过吗？最近一次恢复了什么，花了多久，发现什么问题？

这是备份类项目最硬的一问。没做过演练的备份，可信度直接归零。

• 演练细节说得出：恢复到什么环境、用哪天的备份、实际耗时与 RTO 的差距
• 发现的问题真实具体：备份脚本静默失败、恢复顺序错了应用连不上库、备份不含配置和证书

题 14：备份的完整性怎么验证？如果生产被勒索病毒加密，备份还安全吗？

考备份的最后一道防线。备份和生产同域同权限，是这几年最常见的团灭方式。

• 完整性有自动校验：校验和比对加定期试恢复，备份成功不等于文件可用
• 有隔离副本：一份与生产网络和账号体系隔离（不可变存储、离线介质、独立账号）
• 备份账号权限最小化：保留周期内的历史版本删不掉

面试官视角

这组题考的不是知识面，而是参与的真实性和思考的深度。判断方法很固定：每个项目沿着"做了什么 → 为什么 → 出过什么事 → 数据是多少"四连问往下走，包装型候选人通常第二问开始含糊，第三问就对不上细节。

• 加分回答的共同特征：有数字（规模、耗时、前后对比）、有取舍（为什么不用另一个方案）、有事故（讲得出失败和整改）、时间线自洽（入职时间、项目周期、技术版本对得上）
• 露馅信号：全程只有名词，一问细节就"这块是同事负责的"；数字巨大但说不出口径；从没出过事故、没踩过坑；号称主导却讲不清参数为什么这么设
• 使用建议：不必十四道全问。挑简历上最亮眼的两个项目追问到底，比泛泛聊五个更能定级。定级看的也不是答对几道，而是他能在第几层追问上依然给出具体细节

Mr丶点心

打赏 海报 链接