如果你在挑云服务器硬盘、或者在操心自己的云盘能撑几年，这两家以 NVMe 存储为主打的高性能商家可以先看看报价和技术说明：terabix（AMD EPYC Genoa + DDR5 内存 + RAID-10 NVMe Gen4 存储的高端云虚拟机）、itldc（覆盖 20 个全球机房的 NVMe 云盘与独立服务器方案）
去年冬天我接手了一台跑了两年的云服务器，配置普普通通：4 核 8G，100G 系统盘加一块 200G 数据盘。业务方给我的说法是「我们就是每天写几百万行日志，怎么可能把盘写坏」。我信了，直到有一次做容量体检，我顺手看了一眼 SMART 里的写入量计数器。
系统盘 100G，SMART 显示累计写入 4800GB。数据盘 200G，写入量 21000GB。两块盘加起来不到 300G 容量，累计写入 2.5TB。听着好像还行？直到我把业务日志翻出来一算那套系统每天实际产生的日志量，按行数算大概 1.2GB，按字节算更小，撑死一天 2GB 不到。两年下来真实数据量应该在 1.5TB 以内。
也就是说，实际写入 1.5TB 的业务，在盘上变成了 2.5TB 的物理写入量。多出来的部分，就是写放大。
要理解写放大，得先明白 SSD 的存储单元是怎么工作的。机械硬盘是按扇区原地覆盖，写 1KB 就是物理上动 1KB 的磁头。SSD 不是这样，它最小的写入单位叫页（page），典型是 4KB 甚至更大，但擦除的单位是块（block），一个块由几十上百页组成，而且只能整块擦除。
关键矛盾就在这儿：写只影响一页，擦却要抹掉一整个块。假设一个块里有 100 页，只有 1 页需要写新数据，SSD 没办法只擦这一页，它必须把整个块读出来、合并成新数据、写成「擦除态」、再把新数据写回去。真正被业务改动的只有 4KB，实际落到 NAND 上的动作却是几百 KB。写放大系数（Write Amplification Factor，WAF）就是这么来的。
那为什么不同盘能差出 11 倍？三个原因叠加：
一、垃圾回收策略不同。盘里没有空闲块的时候，主控必须主动做垃圾回收（GC），把若干个块里的有效数据合并腾挪出去，才能腾出整块来擦。这个「腾挪擦除写入」的循环本身又是一次写。盘的预留空间（over-provisioning）给得越足，需要搬运的次数越少，写放大越低。廉价消费盘预留空间常常只有 7%，企业盘能给到 28% 甚至更多，这就是同容量价格差一大截的底层原因。
二、负载模式不同。这是我这台机器的真实原因。我的业务日志是「小块高频写 + 几乎不删」，日志文件写满一个就滚动一个，滚动的时候并不真正释放空间，文件系统层看是删了，但盘底层那块空间还留着旧数据，得等 GC 慢慢收。这种负载最伤盘。相反，如果是「大面积顺序写 + 大块删除」，写放大能低到 1.5 倍甚至接近 1。
三、写合并与缓存策略不同。主控有 DRAM 缓存，写请求先进缓存攒批再落盘，攒得越充分，一次擦除前能填满的页就越多，写放大越低。缓存掉电保护（掉电保护电容）做得好不好也影响这一环。
估算盘寿命，核心就两个数：Data Units Written（SMART 属性 235，单位是 1000 个 512 字节扇区）和盘的 Endurance（额定写入量 TBW）。公式很朴素：
可用写入量 = 盘容量 × TBW 系数实际能撑的天数 = 可用写入量 ÷（日均业务写入量 × 写放大系数）
拿我那台机器算：100G 的盘，标称 300TBW，可用写入量约 30TB。实际日均业务写入 1.2GB，写放大按 5 倍算，日均落盘 6GB。30TB ÷ 6GB 差不多 5000 天，还有富余。可它实际已经写了 4.8TB离极限还早，但带宽、备份周期和「云盘突然被限速」这些麻烦比寿命先到了。
这里要提醒一句：SMART 里看到的写入量本身就是写放大之后的数字，它是盘实际收到并落地的物理写入量。所以拿它直接除以业务量，算出来的是「业务量乘写放大」的合计，不会错，但你得自己去分离出放大系数。方法很简单：业务侧统计一段时间的真实落盘字节数，两者一除就是这台机器当期的真实 WAF。
写放大没法彻底消除，但完全可以压下来。以下是我现在给团队定的规矩：
1. 日志别按行刷盘。应用层每写一行就 fsync 一次，是最典型的放大来源。改成批量提交（每 200ms 或每 4KB 攒一次），或者干脆走 page cache 让内核攒批落盘。这一条通常就能把 WAF 从 5 降到 2 以下。
2. 给日志做轮转而不是原地追加。用 logrotate 配 copytruncate 或 create 模式，保证每次轮转产生的是全新文件，删除动作彻底，不给底层留「幽灵占用」。
3. 给盘留出空闲空间。云盘用到 80% 以上就该警觉了。剩余空间越少，GC 越频繁，写放大越高。可以挂个监控，超过 75% 就告警，超过 85% 触发扩容。
4. 确认 TRIM / discard 有没有生效。云环境里如果云盘没开 discard，挂载参数里加 no discard 反而会保留这些好处；但如果底层支持 discard 而文件系统又没主动发 TRIM，删除的数据就只能等 GC 慢慢回收。裸机上通常保留 discard；虚拟机里要问清楚云厂商。
5. 别拿系统盘跑数据库。系统盘上的碎片、更新包、swap、日志混在一起，块尺寸不一，合并效率极低。数据库和日志单独放数据盘，收益立竿见影。
6. 监控 SMART 而不只是容量。至少采集 Data Units Written、Percentage Used、Media and Data Integrity Errors、Unsafe Shutdown Count 这四项。我见过一块盘 Percentage Used 到 3% 就开始报错的，也见过 100% 才出问题的百分比只是参考，实际写入量和错误计数才是真信号。
7. 读多写少的场景别硬上 SSD。如果是归档、日志留存这类写一次读一次的负载，HDD 单位成本上的耐久度碾压 SSD。混合架构往往比全闪存更划算。
买云服务器的时候，别只问「是不是 NVMe」「IOPS 多少」。这三个问题更值钱：
第一，这块盘是共享还是独占？共享盘的写放大系数会随邻居负载波动，你今天测出来的性能明天可能就变了。
第二，给了多少预留空间（over-provisioning）？同一个「100G 云盘」，底层可能是 200G 也可能只有 107G，差别全在这。商家如果讲不清这个数，说明运维团队没摸到盘这一层。
第三，基线 IOPS 是多少，突发积分怎么算？很多云盘的持续性能是按基线给的，超过基线要消耗突发积分，积分用完就限速到基线甚至更低。日志写入突发性大，这一项直接决定你晚上 8 点会不会被限。
回到开头那台机器。我最终没有换盘，而是做了两件事：把日志改成批量提交并单独放到数据盘，把写放大从 5 倍压到 2.1 倍。半年后再看 SMART，累计写入量曲线明显变缓了。盘还是那块盘，但它多活了至少两年。
写放大这件事从来不是硬件的错，是工作负载和配置方式共同决定的。看懂它，你至少能知道自己该在哪一环省。
