企业官网建设流程全解析

第一次接触Ceph集群的时候，带我的人只交代了一句：每天过来看一眼ceph -s，只要它显示HEALTH_OK就没事。我信了挺长时间，直到一个OSD悄悄掉盘、而集群因为min_size的配置还勉强能对外提供服务，我才反应过来——真正的Ceph运维根本不是守着绿灯，而是在各种“看起来一切正常”的状态里，把隐患一个一个提前挖出来。

这篇文章是写给正在接手或准备接手Ceph集群的运维朋友的。我会把自己实际维护Ceph集群的经验，按照组件盘点、部署取舍、巡检清单、故障排查链路、性能定位、日常变更这六个方向理一遍，每一节都能直接落地。涉及到的命令和参数都是我实际用过的，也夹带了不少踩坑后的个人判断，适合K8s/OpenStack/分布式存储方向的运维参考，也适合刚入门想系统建立Ceph运维体系的人。

1. 接收集群先盘点家底：MON、OSD、MGR各自埋着哪些雷

Ceph被包装得很玄乎，但运维视角下其实就是一套“三段式”系统：MON负责决策，OSD负责数据，MGR负责辅助管理。这三者的角色边界要是捋不清，后面所有排障都会绕弯路。我第一次排查一个“整个集群不可写”的故障时，先在OSD上折腾了半天，最后发现是MON仲裁丢了一个、剩下的两个又发生网络分区，压根没往MON上想。这个教训让我养成了习惯：接手任何集群，先画清楚组件分布图。

1.1 MON是集群的大脑，问题总藏在细节里

MON保存的是整个集群的元数据，比如osdmap、pgmap、crushmap这些核心映射关系，所有客户端读写前都要先跟MON要最新地图。MON之间通过Paxos协议维护一致性，所以部署上有一条硬性规矩：奇数个，不少于3个。为什么是奇数？因为仲裁要求“超过一半”，3个正常能挂1个，5个正常能挂2个，偶数个部署（比如2个或4个）在极端情况下容易谁也说服不了谁，直接脑裂。

MON最常见的坑有三个：

• 时钟漂移。MON之间对时间同步非常敏感，漂移超过mon_max_clock_skew（默认0.05秒）就会告警，严重时会影响仲裁。我见过某套集群因为没配好chrony，MON之间的时钟偏差到了几百毫秒，客户端访问时断时续，日志里全是“clock skew too great”相关的报错。这个问题排查起来很隐蔽，因为它不会直接把HEALTH_OK变成HEALTH_ERR，只是行为异常。
• MON节点磁盘空间被撑满。MON的数据是增量日志型的，如果长期不清理（比如ceph log和mon Store增长），磁盘一满，整个集群的读写都会hang住。这块空间单独挂一个分区是有必要的，别跟系统盘挤在一起。
• 网络分区。MON分布在不同的物理机/机柜时，如果它们之间通信不稳，就会出现“少数派MON反复尝试选举”的情况，表现就是ceph -s时好时坏。值班被半夜叫起来，很大比例是这个原因。

1.2 OSD撑起数据面，掉盘只是开始

OSD是真正存数据的角色，一个OSD进程通常对应一块物理磁盘（也可以一节点多盘）。默认存储引擎是BlueStore，数据直接管理裸设备，不再依赖传统文件系统，性能和稳定性比老的FileStore好很多。运维里跟OSD打交道的频率最高，噩梦清单也最长：

• 磁盘物理损坏，SMART已经报了reallocated_sector_ct这类告警，但系统还能跑，如果不提前替换，后面可能直接掉盘。
• 盘符漂移。重启机器后/dev/sdb变成/dev/sdc这种，如果没用UUID/LVM标签管理，OSD起不来。这也是为什么现在都推荐用ceph-volume而不是直接写/dev/sdX设备名。
• 内核、驱动兼容性问题。某些内核版本和磁盘控制器驱动组合，在高负载下会出现IO超时，OSD进程自己没挂，但内核把设备置为不可用，最终导致OSD反复flapping。
• 容量不均衡。新增OSD默认权重可能和历史盘不一致，或者数据分布策略调整不及时，导致个别OSD接近full而其他还很空，整个集群被“短板盘”拖慢。

OSD掉盘的影响范围取决于副本数和min_size。三副本集群掉一个OSD，数据还是完整的，只是PG会进入degraded状态，业务读写不中断；如果掉到只剩一个副本还开着min_size=1，那就是拿数据安全赌运气，我很不建议这么干。

1.3 MGR/MDS与三类接口的运维差异

MGR（Ceph Manager）是后来加进来的辅助角色，负责跑dashboard、prometheus监控指标、balancer（数据均衡器）、pg_autoscale这些功能。MGR挂了不会直接中断用户IO，但管理面会很难受，dashboard看不到了，自动均衡也不跑了。所以生产环境我都会部署至少2个MGR，避免单点。

如果集群提供CephFS文件存储，还要关注MDS（Metadata Server）。MDS负责文件系统的元数据，层级上类似HDFS的NameNode，生产环境一个活动节点配一个热备是常规操作。MDS出问题，CephFS的访问会直接受影响，但RBD和RGW不受影响——不同接口模块之间相对独立，这也是Ceph设计上讨喜的地方。

运维上要清楚自己主要服务哪种接口：

• RBD块存储：通常给OpenStack Cinder、K8s PV用，要关注块设备延迟、克隆/快照空间占用。
• RGW对象存储：S3兼容，要关注Bucket索引、小对象较多时的rgw_bucket_default_quota和生命周期管理。
• CephFS文件存储：要关注MDS缓存、文件数/目录深度对元数据性能的影响。

不同接口的调优侧重点不一样，别拿一套参数套所有场景。

1.4 组件故障影响速查

接手集群第一周，我的建议是先把这套组件清单和IP对应关系整理成表格，贴在值班文档里。后面所有故障排查的第一步，几乎都是“先确认哪个组件挂了”，这一步跑偏，后面全白费。

2. 部署阶段的关键取舍：硬件选型、PG数量与容量红线

很多集群后期各种怪毛病，根源其实都在最早那批决策上。运维工作量的60%在集群设计阶段就已经定了，这话不夸张。我自己见过一套集群，为了省钱把公共网络和集群网络混着跑，业务高峰期OSD之间心跳丢失，OSD被反复标记down，值班同学整晚都在重启进程。后来物理上把网络分开，问题基本消失。

2.1 硬件选型时最值得多花钱的地方

• 网络：公共网络（客户端访问）和集群网络（OSD之间复制/心跳）必须分开，至少万兆起步，全闪场景建议25G。集群网络不要跟业务流量混跑，这是最容易踩的坑。心跳延迟一旦变大，OSD会被误判down，然后触发不必要的数据迁移，越迁移越慢，恶性循环。
• 磁盘：机械盘大容量场景下，强烈建议给BlueStore配SSD做WAL/DB（ceph-volume lvm create --bluestore --wal-disk /dev/sdX --db-disk /dev/sdX）。随机小IO性能提升非常明显。全闪集群省心但成本高，适合对时延敏感的场景。
• 内存：MON机器32GB起步，OSD机器按“每OSD进程1GB左右预留”再加系统内存比较稳妥。BlueStore会利用内存做缓存，内存太小会直接限制读缓存命中率。
• CPU：OSD节点别买低功耗U，压缩、校验和计算都吃CPU，尤其是启用EC纠删码池之后。

硬件上多花的钱，会在之后无数个安稳的夜里赚回来。这台词有点像广告，但运维做过一年以上的人应该都有同感。

2.2 PG数量到底怎么算，以及为什么不用官方最低值

PG（Placement Group）是Ceph数据分布的基本单位，所有数据先映射到PG，PG再映射到OSD列表。PG数量直接影响集群均衡速度和单PG内对象规模。官方有个经验公式：

PG总数 ≈ (OSD总数 × 单个OSD期望PG数) / 副本数

单个OSD期望PG数，机械盘建议取50~100，全闪可适当偏高但也不建议超过200。举个例子：一套50个OSD、三副本集群，想做每个OSD约100个PG，算出来是50 × 100 / 3 ≈ 1667。取2的幂，向上取到2048。为什么取2的幂？因为Ceph的pg_num在均衡分布和后期split时，按2的幂次变化更平滑，早年间这也是一个比较“玄学”的习惯，但实测下来确实稳定。

很多人图省事直接用官方最低值（比如mon_pg_warn_max_per_osd推荐的每OSD几十个PG）都嫌麻烦。我的建议是初期宁可稍微偏大，不要偏小。PG太少，单个PG里对象太多，故障恢复时数据迁移粒度太粗，一小块盘的故障都可能引发大规模风暴；PG太多，元数据压力和内存占用变大，均衡过程也会更久。后期pg_num扩容比较简单，缩小则非常麻烦，所以初始设计时偏大一点更安全。

如果你用的是较新版本，可以开启pg_autoscale按池自动调整，但我依然建议定期人工审一下结果，别完全放飞。自动扩缩的逻辑基于监控数据，偶尔也会给出让人看不懂的调整方案。

2.3 容量水位与故障域设置

容量管理是Ceph运维最容易忽略的部分。默认mon_osd_full_ratio是0.95、mon_osd_nearfull_ratio是0.85，但按这个阈值才告警，实际上已经太晚了。我个人的经验是，当任意OSD利用率达到80%就要触发提醒；超过85%要准备扩容或清理数据。因为OSD之间永远不会绝对均衡，总有一两个“胖盘”会先顶到上限，而且PG迁移/备份期间还会产生临时空间占用。

故障域设置是另一个设计点。默认CRUSH规则把故障域设为host，意思是同一个PG的多个副本会尽量落在不同主机上。如果你的集群跨多个机柜，建议把故障域改成rack甚至row级别，否则一个机柜断电可能带走同一PG的所有副本。“把鸡蛋放在不同篮子里”这句话在Ceph里是字面意思。修改故障域是在创建pool时通过ceph osd pool create ... crush_rule指定，或者在crushmap里自定义rule来实现。

部署阶段还有一条“不要做”清单，都是我用教训换来的：

• 不要把副本数调成1跑生产，哪怕测试也少这么干，养成习惯很危险。
• 不要为了加快恢复把osd_max_backfills和osd_recovery_max_active调到极大，恢复风暴会挤掉正常业务IO。
• 不要跳过部署前的ceph-volume lvm zap，旧盘上的分区残留会带来各种稀奇古怪的问题。

3. 巡检不是看灯：我每天盯的核心指标与告警阈值

服务器能跑不代表存储能跑，存储能跑不代表数据安全。HEALTH_OK只是最低门槛，真正的巡检要关注从正常到异常之间的渐变过程。我接过不止一次“昨天还好好的，今天突然慢到没法用”的工单，最后查下来往往在几天前就有先兆，只是没人注意到。

3.1 三层巡检法：从ceph -s到磁盘SMART

第一层，每天早上执行基础状态检查：

ceph -s ceph df ceph osd df ceph pg stat

这一层回答“集群现在是否健康、容量还剩多少、PG有没有异常状态”。重点看有没有HEALTH_WARN，以及它为什么warn。HEALTH_WARN不是摆设，绝大多数严重故障都是从一条warn开始的。

第二层，深入检查异常详情：

ceph health detail ceph osd tree ceph pg dump | grep -E 'incomplete|degraded|peered|undersized' ceph daemon osd.0 dump_ops_in_flight

这一层回答“如果有点小问题，具体在哪、影响多大”。比如某个PG长时间active+degraded，说明有副本不在正确位置，数据冗余度在下降。另一个高频项是检查slow ops，ceph -s里如果出现1 osds have slow requests，就要立刻定位是哪块盘、什么IO慢。

第三层，系统与硬件层巡检：

smartctl -a /dev/sdX journalctl -u ceph-osd@0 | tail -n 100 ceph time-sync-status

磁盘的SMART指标里，重点关注Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable这三项，任何一个飙高都意味着盘在走向死亡。系统内存、CPU负载、网卡丢包也顺手看一眼，很多Ceph故障最终根因在更低层。

3.2 监控面板与告警阈值设置

Prometheus + Grafana的方案在Ceph里非常成熟，新版Ceph直接内置了prometheus模块：

ceph mgr module enable prometheus

启用后在MGR节点的9283端口就能拉到ceph_开头的指标。我常用的阈值和它们对应的告警条件：

注意，告警不是越灵敏越好。太敏感会把人“告疲劳”，狼来了喊多了，真出事反而没人看。比如OSD down这个告警，单独一个OSD掉线其实不致命，但为了及时发现，我会设成“持续1分钟”就告警，因为时间窗口很短，值得人工确认一下原因。容量告警这种渐变型的，则可以设更长的持续时间，避免偶尔的瞬时波动骚扰。

3.3 巡检自动化的思路

只靠人肉巡检不可持续，尤其集群规模上来以后。我的做法是写一个巡检脚本，每天定时跑一遍，把关键输出存成文件，并将异常状态通过webhook推到值班群。脚本里包含几个判断：

• 解析ceph -s的状态字段，非HEALTH_OK则发送警报。
• 遍历ceph osd df输出，检查最大util比最小util高出多少，差异过大说明数据不均衡。
• 检查每个OSD进程最近日志中是否有ERROR或WARN关键字。
• 跑一遍ceph pg dump，统计degraded和incomplete的数量。

自动化还有一个重要职责：记录历史。每天把ceph osd df、ceph df、PG分布结果写到历史文件里，出问题时你才知道“是从哪一天开始恶化的”。这个信息在复盘时价值极大，也是普通监控面板不太容易回溯的。

4. 故障排查的完整链路：从告警到根因再到恢复

故障排查最忌讳一上来就乱试命令。我自己长期用的排查链路是四步：看清状态→向上看系统→向下看硬件→做处理再复盘。这个顺序基本能覆盖90%的Ceph运维场景。

4.1 OSD down引发的degraded风波

这是最常见的故障。某天你收到“osd.12 is down”的告警，随后集群变成HEALTH_WARN，部分PG变成active+degraded。按下面顺序来：

第一步，确认影响面：

ceph health detail ceph osd tree

ceph health detail会明确告诉你哪个OSD down、哪些PG degraded。ceph osd tree看这个OSD在哪台机器、是不是在同一主机上还有其他OSD也异常。如果同一个宿主机上多个OSD同时down，先怀疑机器层，比如系统盘满了、网络断了、内存耗尽；如果只有单个OSD down，先怀疑盘本身。

第二步，登录主机看进程和内核日志：

systemctl status ceph-osd@12 journalctl -u ceph-osd@12 | tail -n 200 dmesg | tail -n 100

重点关注：日志里是bluestore读写出错，还是网络心跳超时？dmesg里有没有IO error、磁盘reset、设备不可用的记录？这决定了问题的性质。

第三步，确认盘还在不在：

lsblk pvdisplay | grep -A 5 '12' smartctl -a /dev/sdb

这一步非常关键。有时候盘和系统都活着，只是OSD进程异常退出，直接重启就能恢复；有时候是盘符漂移，/dev/sdb变成了/dev/sdc，需要修正设备映射；最麻烦的是SMART已经显示盘硬件故障，那就别重启了，准备换盘。

第四步，决定重启还是替换：

如果是进程崩溃或偶发超时，systemctl restart ceph-osd@12，然后观察。如果OSD启动后很快又down，或者反复flapping，不要硬扛，先把它out掉：

ceph osd out osd.12

out之后集群会启动数据迁移，把这块OSD承载的PG挪到其他健康盘上。等迁移完成、所有PG恢复健康，再决定是替换还是修复。

这里有一个非常重要的提醒：不要在OSD还是in状态时就purge或拔盘。先out，等数据安全迁移，这是数据安全的第一原则。我见过有人为了“快速解决问题”，直接ceph osd rm，结果丢掉大量PG还没法回滚，最后只能靠备份恢复，教训太深刻。

4.2 PG卡在peered/incomplete时的数据抢救思路

相比OSD down，更让人头皮发麻的是PG状态卡在peered或incomplete。peered说明PG还没有选出主OSD，无法对外提供服务；incomplete说明这个PG的副本信息不足以恢复出完整数据。简单说，这块数据正处于“可能丢失”的悬崖边。

出现这种状态，通常意味着同一PG的所有副本OSD里有不止一个不可用，或者副本所在OSD的数据损坏。排查链路：

ceph health detail ceph pg dump | grep incomplete

然后针对具体PG，看它映射到哪些OSD：

ceph pg map <pgid>

确认这几个OSD的存活状态。如果只是其中一个OSD暂时不可用，想办法把它拉起，PG会自动恢复peering；如果某个副本所在的盘物理损坏，且另一个副本也刚好处于异常状态，这就进入“数据抢救”环节。

抢救incompletePG的基本思路是：把残留可用副本临时接管为权威数据，让PG恢复服务。常用的操作是ceph-objectstore-tool，从残留OSD的本地对象存储中导出PG数据，或者调整PG的权威副本。**这类操作风险极高，执行前一定要先备份涉及OSD的本地元数据，并且仔细阅读当前版本对应文档。**我个人的建议是，非资深玩家在遇到incomplete时，第一选择是联系有经验的同事一起看，而不是贸然动手。宁可多花时间确认，也别把最后一份副本弄丢。

4.3 slow requests慢请求的定位路线图

ceph -s里出现slow requests时，业务上表现为读写卡顿，但根因可能是网络、磁盘或客户端并发，三者的处理方式完全不同。定位顺序我建议这样：

# 看OSD的op队列和延迟 ceph daemon osd.0 dump_ops_in_flight ceph daemon osd.0 perf dump | grep -E 'osd_op_latency|commit_latency|apply_latency'

如果发现某个OSD的commit_latency明显偏高，再看磁盘层：

iostat -x 1

await和%util双双偏高时，大概率是磁盘硬件瓶颈或RAID卡策略问题；如果磁盘层正常，就要看网络：

ethtool -S eth0 | grep -E 'err|drop' ping <mon_ip> -c 100

丢包率不是0，就要查交换机端口、网线、光模块。集群网络（OSD之间复制流量）和公共网络（客户端流量）是否混跑，这时候也会暴露问题。还有一个常被忽略的点：客户端并发IP数量太多，比如几十个K8s节点同时挂载RBD并跑高并发IO，OSD的op队列会被瞬间打满，这时候磁盘和网络都是正常的，瓶颈在OSD进程的处理能力。排查时可以用ceph tell osd.* ops看队列里的操作数量来交叉验证。

慢请求这类问题，往往不是单点故障，而是多个因素叠加。所以一定要按“磁盘-网络-客户端-OSD进程”的顺序逐个排除，别一上来就调一堆参数，调完都不知道哪个起作用。

5. 性能问题分层定位：别把锅都甩给Ceph

做运维被人问得最多的一句话：为什么Ceph这么慢？我的回答永远是先反问一句：慢在哪个环节。Ceph的IO路径是“客户端→网络→MON/OSD→磁盘”，每一层都可能成为瓶颈。性能排查最忌讳的就是直接把参数拉满乱调，最后搞出一堆隐形问题。

5.1 客户端和网络层：先确认“慢”在哪里

先做客户端基准测试，排除应用自身问题：

rados bench -p <pool> 60 write --no-cleanup rados bench -p <pool> 60 seq fio --name=test --rw=randrw --bs=4k --size=1G --numjobs=8 --direct=1 --group_reporting

rados bench测的是数据面裸性能，fio测的是块设备挂载后的表现。如果rados bench正常而fio慢，问题多半在客户端挂载方式、内核RBD模块参数或文件系统层；如果rados bench就慢，那继续往下查。

网络层注意几个容易被忽略的点：MTU是否一致（跨交换机时1500还是9000不匹配会引发奇奇怪怪的间歇性延迟）、网卡中断是否均衡（多队列没开的话，单核CPU会被网卡中断打满）、是否存在跨机柜流量拥塞。

5.2 池与PG层：参数调整的边界在哪

如果客户端和网络没问题，接下来看池和PG配置。这里有个速查表：

参数调整要克制。举例来说，osd_max_backfills默认1，数据迁移时确实偏慢，但直接调到8会让恢复风暴瞬间拉满磁盘IO和带宽。我的经验是2~3比较稳，且要同时限制osd_recovery_max_active，给正常业务IO留出余量。任何一次调参都做记录，避免半个月后忘了为什么改过。

5.3 OSD与磁盘层：用perf dump和iostat说话

深入到单盘层面，依赖两个工具配合：

ceph daemon osd.N perf dump iostat -x 1

perf dump里的commit_latency和apply_latency能看出BlueStore的提交延迟。iostat -x的r_await和w_await反映磁盘硬件的响应时间。如果await超过几十毫秒且%util接近100%，基本就是磁盘硬件瓶颈，只能换盘或降负载；如果磁盘指标正常但OSD行为异常，那就是进程层问题，比如线程数、内存或文件系统异常。

全闪场景下，重点还要看SSD的固件版本，有些SSD在写入达到一定水位后垃圾回收会让延迟抖动剧烈。列一个性能分层速查表：

调优这件事，稳定优先。默认参数在绝大多数场景下都不会太离谱，高频工作其实是“确认瓶颈在哪一层”，而不是“改什么参数”。只要找到瓶颈层，往往不用大调就能解决80%的问题。

5.4 我的调优选择：稳定优先

说白了，Ceph参数是牵一发动全身，给“慢”找解药前，先花20分钟确认到底是哪层慢，比直接上参数要有效得多。我遇到最典型的一次：用户反馈“存储太慢”，最后查下来是客户端NFS挂载参数问题，跟Ceph一毛钱关系没有。如果我们一上来就调Ceph的恢复限流和缓存，反而可能把本来就健康的集群调坏。所以遇到性能问题，先动手做基准测试，用数据说话，再谈调参。

6. 日常变更与自动化沉淀：替换、扩容、升级的规范动作

如果说前面几章是为了“出事能救”，这一章就是“平时不出事”的操作规范。Ceph运维里，业务中断很少来自单点故障，大多数来自变更操作不规范。换盘的顺序错了、升级时选错节点、扩容后忘记调整weight，都可能导致大规模PG迁移甚至IO中断。

6.1 安全替换坏盘的完整顺序

替换坏盘有一套标准动作，顺序一个都不能乱：

# 1. 标记out，触发数据迁移 ceph osd out osd.12 # 2. 观察迁移完成，等待所有PG恢复健康 ceph -w # 3. 确认无异常后，停掉OSD进程 systemctl stop ceph-osd@12 # 4. 清理OSD的所有痕迹 ceph osd purge osd.12 --yes-i-really-mean-it # 5. 拔掉旧盘，插入新盘，然后重新创建 ceph-volume lvm zap /dev/sdb ceph-volume lvm create --bluestore --data /dev/sdb

这套流程里，最容易犯错的是第1步和第4步的顺序。第4步没等第2步完成就执行，等于数据还没搬走就把“存储抽屉”给拆了，PG直接变成inactive。另外，purge之后ceph-volume创建新盘时，如果原来盘上有残留分区，zap步骤一定不能省，宁可多花几分钟清理，也不要在脏盘上叠Buff。

6.2 扩容新OSD与滚动升级的注意点

扩容OSD本身不复杂，ceph-volume lvm create之后OSD自动注册到集群，但几个细节要注意：

• 新OSD的初始weight。如果历史OSD容量不同，新盘加入后要确认weight匹配实际容量，否则CRUSH均衡会出现偏差。
• 扩容后的数据迁移。新盘加入后，集群会启动rebalance，把部分PG从旧盘迁移到新盘。如果一次加入太多OSD，迁移风暴会比较猛，建议分批加入，每批间隔几小时，让集群有时间慢慢消化。
• MON/MGR扩容。扩MON需要修改ceph-mon配置并同步monmap，操作相对繁琐，稳妥做法是先确认现有MON的健康状态，再按官方步骤加节点。

滚动升级是另一个容易翻车的变更。新版Ceph用cephadm管理后，升级方式简化了很多，但仍要遵循“先MON，再MGR，后OSD，最后MDS”的节奏，每一批节点升级完都观察一段时间。升级前先做一次ceph osd dump > before_upgrade.txt存档，万一出问题，这个文件能帮你恢复或回滚。别问为什么，问就是有过惨痛经历。

6.3 把重复巡检交给自动化，把危险操作留给人工

自动化能减少重复劳动，这是每个运维都清楚的事。我推荐的自动化分层是：

• 巡检与预警自动化：脚本定时跑，异常推提醒。这部分放心大胆交给机器。
• 批量命令执行自动化：比如用Ansible在几十台OSD节点上批量执行日志清理、内核参数修改、ceph-volume状态收集。提高效率，但执行前要严格审阅主机清单，别把灰度命令撒到全量。
• 变更操作自动化：危险动作（osd out、purge、restart）尽量保留人工确认，自动化脚本只输出建议命令，由人来执行。因为机器没法判断“当前业务高峰适不适合踢出OSD”。

我一个长期坚持的习惯是：任何涉及集群变更的操作，执行前先存档现状，比如ceph osd dump > before_change.txt、ceph config dump > config_before.txt。这个习惯救过我很多次。曾经有一次改pool参数后性能明显劣化，靠存档文件几分钟就回滚到原状，而如果凭记忆去还原，大概率要折腾很久。

自动化要改的是重复且低风险的劳动，不是把高风险操作交给脚本自动跑。“复用脚本+人为把关”才是运维自动化的正确姿势。

最后说个个人习惯：每次处理完一个故障，我都会把时间线、判断过程和最终处理步骤整理成一篇简短的事故记录，放在团队文档里。这个东西初看不值钱，但三个月后当你遇到类似问题，翻出来一看，能省下几小时的排查时间。Ceph的运维经验就是这样一点点堆出来的，系统本身再复杂，也经不住你把它遇到的每个问题都摸一遍。