一、Ceph 存储篇
Ceph 是这场面试的深挖重点，也是最容易”背了但说不清”的模块。
TIP针对灾备运维岗位，Ceph 不需要学到源码级别，但下面这些必须能讲清楚。学习优先级：
第一优先级：Ceph 架构 → MON/MGR/OSD → 副本 → CRUSH → OSD 故障 → 数据恢复 → 扩容 第二优先级：Ceph + Kubernetes → CSI → PV/PVC → 持久化存储 第三优先级：灾备 → 备份 → 恢复 → RPO → RTO → 恢复演练 第四优先级：商业备份软件的基本概念和工作流程
1.1 Ceph 是什么，有哪些组件
用自己的话说：
“Ceph 是一个分布式存储系统，可以提供对象存储、块存储和文件存储能力。它通过多节点组成存储集群，把数据分布到不同节点上，从而提高存储的可靠性、扩展能力和容错能力。”
核心组件（这个必须会）：
| 组件 | 职责 |
|---|---|
| MON（Monitor） | 维护集群状态、集群地图（Cluster Map） |
| OSD | 真正负责数据存储、数据复制、恢复 |
| MGR | 集群管理、监控、管理接口 |
| MDS | CephFS 使用，负责文件系统元数据 |
| RGW | 提供对象存储接口 |
WARNING不要为了显得厉害，把没实际操作过的组件说成”熟练”。 可以说：“我主要接触的是 MON、MGR、OSD，项目中重点还是 OSD 和整个存储集群的运维管理。”
如果面试官问”你们为什么用 Ceph”，结合项目说：
“我之前项目中主要是为了给 Kubernetes 提供持久化存储，同时需要根据业务增长对存储集群进行扩容和管理。“
1.2 OSD 是什么，为什么会故障
一句话理解：
OSD 是 Ceph 集群里真正负责”存数据”的工作单元，一般对应一块或多块物理存储设备。
OSD down 了怎么办（面试版回答）：
“我首先通过 Ceph 状态确认具体是哪个 OSD 异常，然后检查对应服务器和磁盘状态，再结合日志判断是磁盘故障、网络问题还是 OSD 服务本身的问题。如果确认是硬件故障，会根据业务情况进行替换和恢复，同时观察集群恢复状态，最后确认数据和集群状态恢复正常。”
常用命令：
ceph -s # 集群状态（注意是 ceph -s，不是 safe-S）ceph health # 健康状态ceph health detail # 详细健康信息ceph osd tree # 看 OSD 的层级、节点以及状态（很实用）ceph osd status # OSD 状态CAUTION
systemctl status ceph-osd@3这个命令不是所有 Ceph 环境都能直接用，取决于安装方式和服务管理方式。 面试时不要把这个命令说死。 更稳妥的说法：“我会先确认 osd.3 所在的节点，然后在对应 Linux 节点上检查 OSD 进程或者服务状态，如果是 systemd 管理的，可以使用 systemctl 查看对应的 Ceph OSD 服务状态，同时结合 Ceph 日志进一步判断具体原因。”
知道”为什么执行这个命令”比死记命令更重要。
1.3 OSD 之间怎么通信
核心认知：OSD 之间以及 OSD 与其他 Ceph 组件之间主要通过网络通信，不是依靠某一个像 Nginx 那样的独立”通信服务”。
面试版回答：
“Ceph 的 OSD 之间主要通过网络进行通信，底层使用 Ceph 自己的通信机制。OSD 会和 MON、MGR 以及其他 OSD 进行通信，用于集群状态同步、数据读写、数据恢复和心跳检测等。网络层面主要使用 TCP/IP，具体端口根据 Ceph 版本和配置有所不同，所以实际排查时我会结合 Ceph 配置和监听端口来确认。”
三类通信关系：
| 关系 | 用途 |
|---|---|
| OSD ↔ OSD | 数据复制、数据恢复、数据重新均衡、心跳/状态判断 |
| OSD ↔ MON | 集群状态与集群地图同步，参与集群状态管理 |
| OSD ↔ MGR | 集群管理、监控、管理接口 |
IMPORTANT关于端口：面试时不要死背一个端口号。 不同 Ceph 版本的默认端口范围和配置可能不同。更稳妥的说法：
“Ceph 不同版本的端口配置会有区别，我在实际排查的时候会通过 Ceph 配置以及
ss -lntp、netstat等方式查看当前服务监听情况，同时结合防火墙和网络连通性进行排查。“
1.4 一台服务器上多个 OSD 怎么通信
Server A├── OSD.1├── OSD.2└── OSD.3OSD.1、OSD.2、OSD.3 本质都是独立运行的 OSD 进程。
- 同一台服务器上的 OSD：可以通过本机网络协议栈完成，不需要真的经过外部交换机
OSD.1 → Linux TCP/IP 协议栈 → OSD.2- 不同服务器上的 OSD：需要经过实际网络
OSD.1 → TCP/IP → 网卡 → 交换机 → 网卡 → TCP/IP → OSD.4面试版回答：
“一台服务器上可以运行多个 OSD 进程，每个 OSD 都是独立的服务。OSD 之间通过 Ceph 的网络通信机制进行通信，本质上还是基于 TCP/IP。相同节点上的 OSD 通信主要经过本机协议栈，不需要经过外部交换机；不同节点上的 OSD 通信则需要经过网卡、交换机和网络协议栈。因此排查 OSD 通信问题时，我会先检查节点之间的 IP 连通性，再进一步检查 TCP 连接、OSD 状态和相关日志。”
CAUTION不要说”一个服务器对应一个 Ceph 集群”。 准确说法：一个 Ceph 集群可以由多个服务器/节点组成，而一台服务器上也可以运行多个 OSD。
“能不能 ping 两个 OSD？” ——答案是：可以排查，但不能简单理解成给 OSD 做 ping。因为 ping 验证的是 IP 层连通性，而 OSD 是应用进程，真正通信还涉及 TCP 连接和 Ceph 自身的通信状态。
1.5 OSD 排查的层次感（这条最实用）
记住这个顺序，面试时沿着它往下讲就不会乱：
Ceph 状态 → OSD 进程 → 网络连通性 → TCP连接/端口 → 日志 → 磁盘/IO具体命令：
ceph -s / ceph health detail # ① 集群状态：有没有 OSD down、网络告警ps -ef | grep ceph-osd # ② 进程是否存在ss -antp | grep ceph-osd # ③ TCP 连接状态ping 192.168.1.101 # ④ IP 层连通（只能证明 IP 可达）nc -zv 192.168.1.101 <端口> # ④ 端口连通# ⑤ OSD 日志# ⑥ 磁盘 I/O看 ss -antp 时关注有没有大量 ESTAB、TIME-WAIT、SYN-SENT、SYN-RECV 等异常状态。
面试版回答：
“我会先通过
ceph -s和ceph health detail确认集群是否存在 OSD down、网络相关告警，然后检查对应节点之间的网络连通性，再检查 Ceph 相关端口是否正常监听以及防火墙策略，之后结合 OSD 日志判断是网络问题、OSD 进程问题还是底层磁盘问题。”
如果日志里大量 heartbeat 超时 / 连接异常，说明：
OSD 进程虽然还在运行，但是 OSD 与其他 Ceph 节点之间的通信可能不正常。
1.6 MON 为什么至少要部署 3 个（多数派 quorum）
面试官问法：Ceph 的 MON 是干什么的？为什么要部署多个？
MON 的职责：维护和管理集群的状态信息、集群地图。
部署多个的原因：提高集群管理面的高可用性和容错能力。如果只有一个 MON，这个 MON 出现故障就可能导致整个集群无法进行状态变更。
面试版回答：
“部署多个 MON 主要是为了提高集群管理面的高可用性和容错能力。如果只有一个 MON，这个 MON 出现故障可能导致集群状态无法维护，所以需要部署奇数个（通常 3 个或 5 个）MON 来形成多数派。“
最难的一个追问：为什么剩 2 个行，剩 1 个就不行
这是整场面试里最精彩的一问。你的直觉可能是：
“如果挂了一个还剩两个，两个人表决开会嘛，一个说开会一个说不开会就出状况了；但如果挂了两个只剩一个，这一个人他可以选择开会或者不开会，不就能正常工作了吗？”
关键点：MON 不是一个普通的”开会成员”，它需要确认自己看到的集群状态，是不是整个集群认可的状态。
只剩 1 个 MON 时：
- 它不知道另外两个为什么消失
- 可能是真挂了，也可能是自己跟它们网络断了（网络分区）
- 如果它在没有多数派的情况下认为”我就是整个集群的正确状态”，就会出现脑裂（split-brain）或集群状态不一致
所以 Ceph 的设计是：宁可在没有 quorum 的情况下限制部分管理/状态变更，也不让一个孤立的 MON 自己拍板。
TIP一句话记住： 能不能自己运行 ≠ 能不能代表整个 Ceph 集群形成共识。
面试版回答：
“MON 需要通过 quorum 保证集群状态的一致性。3 个 MON 挂掉 1 个以后，剩余 2 个还能形成多数派；如果只剩 1 个，就无法形成 quorum，因此 Ceph 会避免让这个孤立的 MON 单独代表整个集群进行状态决策。”
这个程度就够了，不需要深入 Paxos / Raft 选举算法。如果被追问到算法层面，如实说”选举算法的细节我没有深入”即可，硬编会更糟。
1.7 数据怎么分布到 OSD（CRUSH 与 PG）
CAUTION错误认知：MGR 决定数据放在哪些 OSD。 MGR 不负责数据放置决策。
正确的映射链：
客户端 → Pool → PG → CRUSH → OSD一份数据 ↓Pool ↓PG（Placement Group，数据映射和管理的中间层） ↓CRUSH 算法（根据集群拓扑、故障域、副本策略计算） ↓选择合适的 OSD ↓OSD 存储数据面试版回答（值得背熟）：
“主要是通过 PG 和 CRUSH 来完成。数据首先会映射到对应的 PG，然后 CRUSH 根据集群的拓扑结构、故障域以及副本策略计算出应该使用哪些 OSD，最终把数据分布到相应的 OSD 上。这样可以尽量保证副本分布在不同的故障域，提高数据的可靠性。”
三副本是什么意思：
“同一份数据保存三份副本，尽量分布在不同的故障域，这样单个 OSD 或节点发生故障时，其他副本仍然可以提供数据。“
1.8 Ceph 副本 ≠ 备份（本题是灾备岗位的核心）
IMPORTANT这是整篇最该记住的一条。 Ceph 的副本机制不能恢复误删的数据。
如果业务层把数据删除了，这个删除操作通常也会同步到其他副本。副本不能替代备份。
| 机制 | 主要解决的问题 |
|---|---|
| Ceph 副本 | 磁盘 / OSD / 节点故障、提高可用性 |
| 备份 | 误删、误操作、数据损坏、勒索等场景的恢复 |
| 快照 | 保存某个时间点的数据状态，可用于特定场景的数据恢复 |
面试版回答：
“如果业务方误删了一批数据，Ceph 的副本机制本身不能直接恢复这些误删的数据。因为 Ceph 副本主要是为了提高数据的高可用性和容错能力，比如某个 OSD 或节点发生故障时，其他副本还能保证数据正常访问。但是如果业务层把数据删除了，这个删除操作通常也会同步到其他副本，所以副本不能替代备份。真正需要恢复误删数据，还是要依靠独立的备份、快照或者其他数据恢复机制。“
1.9 Ceph 与灾备的区别（主动讲出来会加分）
Ceph 解决的是”数据怎么可靠地存储”；灾备解决的是”发生更大范围故障以后，业务和数据怎么恢复”。
| Ceph 副本 | 灾备 | |
|---|---|---|
| 场景 | 一台 OSD 挂了 | 整个存储集群 / 机房 / 区域故障 |
| 解决 | 其他副本还能提供数据，Ceph 自动恢复 | 有没有另外一套数据副本，能不能恢复业务 |
| 指标 | — | RTO / RPO |
在面试里主动说出这个区别，会比较加分——因为它说明你理解的是”体系”，而不只是”一个存储软件”。
1.10 Ceph + Kubernetes
简历里如果 K8S 和 Ceph 都写了，这题几乎必问：
“Kubernetes 为什么要用 Ceph？”
“Kubernetes 中容器本身是比较动态的，容器删除以后本地数据可能不存在，所以对于数据库、业务文件等需要持久化的数据，需要使用持久化存储。Ceph 可以提供可靠的分布式存储，通过 CSI 等方式可以给 Kubernetes 提供持久化卷。”
Ceph 扩容怎么说（简历写了就一定会被问）：
“之前负责过 Ceph 存储集群的扩容和变更。扩容的时候首先确认现有集群状态和容量，检查节点和磁盘资源，然后加入新的存储资源，观察数据重新分布和集群恢复情况，最后确认集群状态和业务访问正常。”
追问”扩容以后为什么要观察”：
“因为新增 OSD 后会涉及数据重新均衡，也就是数据迁移，如果集群负载比较高，需要关注恢复和迁移对业务 I/O 的影响，同时确认最终集群回到正常状态。“
二、灾备与数据恢复篇
2.2 手里有一份备份，怎么恢复
面试官问法：业务方误删数据，你手里有一份之前的备份。你准备怎么恢复？你会先做什么，而不是直接把备份覆盖回去？
CAUTION不要直接把备份覆盖回去。
核心原则：先用备份恢复出一份数据进行验证，确认无误后再执行正式恢复。
面试版回答思路：
“首先我不会直接用备份覆盖现有数据。我会先利用备份恢复出一份副本进行验证，确认数据完整性、时间点是否符合预期，同时确认恢复操作不会影响现有业务数据。验证通过以后，再按照恢复计划执行正式恢复，并在恢复后进行完整性校验和业务验证。“
2.3 如果发现备份本身损坏了
面试官问法：恢复过程中发现备份损坏，怎么办？
IMPORTANT核心原则：不继续强行恢复。
面试版回答：
“如果发现备份损坏，我不会继续强行恢复，而是先确认损坏范围，再检查其他备份、历史备份或者其他副本，评估可用的恢复点。同时把情况同步给业务方和相关负责人，说明当前可恢复的时间点和可能的数据丢失范围。”
这道题不需要讲得特别深，抓住”不强行恢复 + 先确认范围 + 找替代恢复点 + 及时同步”就足够了。
2.4 备份失败怎么排查
标准六步：
- 查看备份任务日志；
- 检查网络连接；
- 检查存储空间；
- 检查权限和账号；
- 检查源端服务状态；
- 验证恢复是否正常。
注意第 6 步——备份成功的唯一验证标准是”能恢复”，而不是”任务返回成功”。
2.5 为什么想转灾备方向
“我原来的工作涉及云平台、存储、容器和数据恢复等内容。灾备方向更加聚焦数据安全和业务连续性，我认为这是未来很重要的技术方向，希望在已有运维基础上深入发展。“
2.1 “你做过灾备吗” 怎么回答
这是灾备岗位的开场必问题，也是最容易一句话答死的地方。
CAUTION绝对不要说：“我没做过灾备。” 这句话一出口，后面所有问题都会变成”那你为什么来投这个岗位”。
正确答法的核心是 重新定义边界，而不是否认：
“我之前主要从事云平台和运维工作，在项目中参与过数据灾备和恢复方案。例如在 Ceph 存储环境中，负责数据完整性校验、恢复计划制定以及故障恢复验证。虽然没有长期使用专门的商业备份软件，但对灾备体系、数据备份流程、恢复演练等工作有实践经验，也具备快速学习能力。”
如果对方追问”你了解灾备吗”，按五个层次展开：
我理解灾备主要是保障业务连续性，包括： 第一，数据备份； 第二，数据恢复； 第三，恢复演练； 第四，容灾切换； 第五，恢复时间（RTO）和恢复点（RPO）管理。
RTO 和 RPO 这两个词一定要能说出来——它们是灾备岗位的行话，说出来就说明你懂这个领域。
附录 · 一页纸速查
Linux 排障命令
top / free -h / vmstat 1 # CPU、内存、整体负载iostat -x 1 / iotop / pidstat -d 1 # 磁盘 IO 与进程 IOdf -h / df -i # 空间与 inodess -lntp / ss -antp # 端口监听与连接nc -zv IP PORT # 端口连通性journalctl -u 服务名 --since # 服务日志crontab -l / last / dmesg | grep oom # 定时、重启、OOMshow processlist / show engine innodb status # MySQLexplain select ... # 执行计划Kubernetes 排障命令
kubectl get pods / describe pod <pod> # 状态与 Events（Pending 第一步）kubectl logs <pod> # 应用日志kubectl get svc / endpoints <svc> # Service 与后端映射kubectl top nodes / describe node <node> # 节点资源kubectl rollout history / undo # 版本与回滚Ceph 排障命令
ceph -s / ceph health detail # 集群状态ceph osd tree / ceph osd status # OSD 层级与状态ps -ef | grep ceph-osd # 进程ss -antp | grep ceph-osd # TCP 连接ss -lntp # 确认实际监听端口（不要背固定端口）必背的三个”不等于”
- Java 进程存在 ≠ 应用正常提供服务（还要看端口与绑定地址）
- ping 通 ≠ 业务通（ICMP 可达 ≠ 端口可达）
- Ceph 副本 ≠ 数据备份（副本防硬件故障，备份防误删）
必背的两个”设计思想”
- 声明式管理：改 Deployment，不改 Pod——改的是期望状态
- Taint 在 Node、Toleration 在 Pod：控制权在资源侧
写在最后
这份宝典里所有题目，都来自同一个人被连续追问几十轮的真实过程。里面大量的”错误回答”不是编出来凑数的，是真实发生过的——包括把 crontab 说成 “current type”、把 OSD 说成 “OST”、把 Ceph 说成 “safe”。
技术的部分可以靠刷题补，但”被追问到第三层还答得上来”这件事，只能靠真实经历。
所以最实在的建议是：把这份题库里每一题，都换成你自己项目里真实发生过的场景，然后对着讲三遍。讲到第三遍，你就不需要背了。
TIP这是「运维工程师面试宝典」系列的第三篇（完结篇）。 上一篇：（二）Kubernetes 排障与面试表达 第一篇：（一）Linux 排障与监控选型
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时