原理预计 30 分钟

值班手册：SOP 与故障复盘

把前面所有知识固化成可交接的流程，这才是工程师的产出物。

学完这节你能做到

写出一份别人能照着执行的处置 SOP
主持一次不追责的故障复盘
建立变更前的检查清单

工程师的产出物不只是"把问题解决了"

一个人默默把故障处理完，没有留下任何文档——下次别人遇到同样的问题，还要从零摸索一遍。

真正的产出物是可交接的流程：别人照着能做对，你休假时集群也不会失控。这一节把前面所有知识固化成三样东西：处置 SOP、变更纪律、故障复盘。

一、处置 SOP

SOP 的检验标准很硬：一个刚入职两周的同事，照着能不能做对。

模板长这样：

# SOP-003：单块 OSD down（疑似坏盘）

## 适用条件
ceph health detail 报 OSD_DOWN，且只涉及 1~2 个 OSD

## 不适用（需升级处理）
- 同时超过 3 个 OSD down
- 整台主机不可达
- 出现 PG incomplete 状态

## 处置步骤
1. 确认范围
   ceph -s && ceph health detail
   → 记录 down 的 OSD 编号与所在主机

2. 判断根因（Ceph 层 + 硬件层双证据）
   systemctl status ceph-osd@<id>
   ssh <host> dmesg -T | tail -30
   ssh <host> smartctl -a /dev/<dev>
   → 有 medium error 或 SMART FAILED ⇒ 确认坏盘，继续
   → 无硬件错误 ⇒ 转 SOP-004（OSD 进程异常）

3. 【关键】评估容量与迁移影响
   ceph df
   ceph osd df | sort -k17 -rn | head -5
   → 若最满 OSD > 85%，先执行"步骤 3b 限速"，并向值班组长报备
   3b. ceph config set osd osd_max_backfills 1
       ceph config set osd osd_recovery_sleep 0.1

4. 下线
   ceph osd out <id>
   → 等待 ceph -s 显示 PG 回到 active+clean（大盘可能数小时）

5. 移除
   ceph orch daemon stop osd.<id>
   ceph osd purge <id> --yes-i-really-mean-it

6. 换盘
   → 记录：槽位号、旧盘 SN、新盘 SN、时间
   → 提厂商工单（附 SMART 报告）

7. 重新加入
   ceph orch device zap <host> /dev/<dev> --force
   ceph orch daemon add osd <host>:/dev/<dev>

8. 收尾
   ceph -s → HEALTH_OK 且 PG 全部 active+clean
   恢复限速参数为默认值
   更新资产台账
   顺手普查同批次盘寿命：
     pdsh -w ^all 'nvme smart-log /dev/nvme0n1 | grep -i "percentage used"'

## 预计耗时
30 分钟操作 + 2~6 小时等待数据迁移

## 升级条件
任一步骤出现预期外结果，立即停止并联系 <值班组长>

✓SOP 最重要的两段是「不适用」和「升级条件」

新人最危险的行为不是不会做，而是在不该继续的时候继续做。

明确写出"什么情况下不要用这份 SOP"和"什么时候必须叫人"，比把正常流程写得多详细都重要。上面那份 SOP 里的第 3 步（评估容量）就是从真实事故中学到的——不评估容量直接 out，把小故障升级成业务中断。

值班应该准备的 SOP 清单：

编号	场景
SOP-001	集群 HEALTH_WARN 通用排查入口
SOP-002	容量 nearfull / backfillfull
SOP-003	单块 OSD down（疑似坏盘）
SOP-004	OSD 进程反复重启（非硬件原因）
SOP-005	MON quorum 异常
SOP-006	MDS slow request / CephFS 卡顿
SOP-007	RGW 5xx 或签名错误激增
SOP-008	PVC 创建失败 / Pod 挂载失败
SOP-009	计划内重启存储节点
SOP-010	集群滚动升级

二、变更纪律

存储是有状态服务，变更失败的代价远高于无状态应用。四条纪律：

1. 变更窗口

不在业务高峰、不在周五下午、不在长假前一天。留出足够的观察和回滚时间。

2. 变更单

## 变更单 CHG-2026-0813-01
- 内容：调整 osd_memory_target 4GB → 6GB（全集群 36 个 OSD）
- 原因：32 盘节点内存利用率偏低，缓存命中率不足
- 影响面：所有 OSD 会分批重启，预计每个 OSD 中断 30 秒
- 风险：内存计算错误会导致 OOM；分批重启期间 PG 短暂 degraded
- 前置检查：集群 HEALTH_OK，PG 全部 active+clean，可用内存 > 80GB
- 回滚方案：ceph config set osd osd_memory_target 4294967296
- 回滚耗时：约 20 分钟
- 窗口：2026-08-14 22:00 - 24:00
- 执行人 / 复核人：xxx / yyy
- 验证方式：ceph -s 健康；4K 随机读 IOPS 复测；观察 24 小时无 OOM

3. 双人复核

不可逆操作必须第二个人看过命令再敲回车：ceph osd purge、rbd rm、mmdelfs、ceph osd pool delete、wipefs、dd。

×最容易出事的三类操作

盘号写错：wipefs /dev/sdb 本想擦新盘，结果擦了在用的盘
忘记设备属主：在错误的机器上执行了正确的命令
复制粘贴上一条：命令历史里的旧 OSD 编号

对策是敲命令前先打印确认：

# 先看清楚，再动手
lsblk -o NAME,SIZE,SERIAL,MOUNTPOINT /dev/sdb
hostname && ceph osd tree | grep -A2 "host $(hostname -s)"

这几秒钟能避免一场事故。

4. 不夹带

一次变更只做一件事。别在升级集群的同时顺手加盘、改 crush rule。出问题时你会分不清是哪个动作导致的。

三、故障复盘

复盘的唯一目的是让同类故障不再发生。它不是追责会。

# 复盘：2026-08-11 存储集群写入中断 42 分钟

## 影响
- 时间：10:14 - 10:56（42 分钟）
- 范围：rbd 池所有写入被拒绝，约 120 台虚拟机不可用
- 业务损失：训练任务中断 6 个，需重跑

## 时间线
10:14  osd.14 因盘介质错误崩溃退出，集群 HEALTH_WARN
10:22  值班收到告警，开始排查
10:31  确认坏盘，执行 ceph osd out 14
10:38  数据迁移使 osd.29 达到 full_ratio(0.95)，rbd 池拒绝写入
10:41  业务方报障
10:47  紧急临时调高 full_ratio 到 0.97，写入恢复
10:56  迁移完成，水位回落，恢复 full_ratio 为 0.95

## 根因
1. 直接原因：osd.14 物理盘介质损坏（SMART 已用寿命 97%）
2. 关键失误：执行 out 之前未评估容量余量。osd.29 当时已 86%，
   吸收迁移数据后越过 full_ratio
3. 深层原因：
   - 缺少"换盘前必须评估容量"的 SOP 约束
   - nearfull 告警在 3 周前就出现过，但被当作"已知问题"忽略
   - 无 balancer，PG 分布标准差达 9.4%，最满与最空的 OSD 差 37%

## 改进项（每项都有责任人和期限）
| # | 改进项 | 责任人 | 期限 |
|---|---|---|---|
| 1 | SOP-003 增加"评估容量"为强制步骤，含判断阈值 | xxx | 08-15 |
| 2 | 开启 balancer upmap 模式，降低分布标准差 | xxx | 08-16 |
| 3 | 增加"最满 OSD 使用率"到看板第一屏 | yyy | 08-18 |
| 4 | nearfull 告警升级为 P2 并接入值班群，不允许静默 | yyy | 08-18 |
| 5 | 全集群盘寿命普查，寿命 > 80% 的排入采购 | zzz | 08-22 |
| 6 | 增加 90 天容量趋势预警 | yyy | 08-29 |

## 做对了什么（同样重要）
- 硬件根因判断准确，依据完整（dmesg + SMART）
- 紧急处置选择了正确的手段（临时调高 full_ratio 而非删数据）
- 恢复后及时把参数改回，没有留下隐患

!复盘的三条纪律

不追责。追责的直接后果是下次没人愿意如实还原时间线，复盘就失去了价值
每个改进项都要有责任人和期限。没有这两项的改进项等于没写
要写"做对了什么"。只列问题会让人觉得复盘是批斗，也会让好的做法无法被复制

另外：改进项要跟踪到关闭。上一次复盘的改进项没做完就出下一次同类故障，是团队管理的失败信号。

知识沉淀与交接

值班要交接的东西：

□ 拓扑图与资产台账（机型、盘型号、SN、槽位、上线时间）
□ SOP 清单与最近更新时间
□ 当前所有已知问题及其状态（尤其是"暂时这样"的临时方案）
□ 集群上设过的非默认参数及原因（含 noout 之类的开关状态！）
□ 告警规则清单与静默列表（谁静默的、为什么、什么时候恢复）
□ 厂商支持联系方式与合同有效期
□ 最近三次变更记录与复盘改进项进展

×临时方案和静默规则是交接的头号地雷

"先这样临时处理一下"和"这个告警太吵先静默了"，如果没写进交接文档，就会变成下一任接手时的定时炸弹。

L2 讲过 noout 忘记取消的后果；告警静默同理——静默了三个月的 nearfull 告警，正是上面那份复盘里事故的根源之一。

所有临时状态都要有到期时间和负责人。

检查点单选

写 SOP 时，哪两个部分对新人最重要？

检查点单选

故障复盘会上，有人开始追问是谁执行了那条命令。作为主持人该怎么做？

检查点多选

值班交接时，下面哪些必须写进文档？（多选）

这节课的落点

SOP 的检验标准：入职两周的同事照着能不能做对
SOP 最关键的是"不适用条件"和"升级条件"
变更四纪律：选窗口、写变更单（含回滚方案）、不可逆操作双人复核、一次只做一件事
敲危险命令前先打印确认设备和主机
复盘不追责、每个改进项有责任人和期限、要写"做对了什么"
改进项必须跟踪到关闭
所有临时状态（参数、开关、静默规则）都要有到期时间和负责人

到这里，整条学习路径走完了。

回头看：L0 让你能在任何一台 Linux 机器上定位性能问题；L1 给了你与产品无关的存储心智模型；L2 让你能独立运维一套 Ceph；L3 让你能把业务需求翻译成机器配置；L4 让你能走出 Ceph 的舒适区，并把个人能力变成团队能力。

最后一句：这个行业里真正稀缺的不是会敲命令的人，是能在故障中保持判断力、并且愿意把经验写下来的人。