摘要
在2024年10月29日至11月1日期间，四个站点的41块企业级NVMe硬盘在到达固定的通电小时数后停止接受命令，这是某个制造批次中的固件缺陷。镜像功能吸收了其中39次故障，对客户无影响。华沙的一个节点在40分钟内丢失了镜像的两半，因为两块硬盘来自同一批次并且同一天上架。该节点上的两个实例丢失了数据。第二部分是我们的错，不是供应商的错。
时间线
所有时间均为UTC。
| 时间 | 事件 |
|---|---|
| 10月29日 03:11 | 华沙节点上的一块硬盘从总线上掉线。镜像降级，热备盘开始重建。常规情况，未触发告警。 |
| 10月29日 03:49 | 同一镜像中的第二块硬盘掉线。节点丢失根存储池并停止运行。 |
| 10月29日 03:52 | 告警触发。值班人员于03:55上线。 |
| 10月29日 04:20 | 节点被宣布无法原地恢复。从热备盘重建不可能，因为热备盘正从已无响应的源进行重建。 |
| 10月29日 05:40 | 审核硬盘日志的工程师注意到两次故障相隔18个通电小时，而不是18个月。怀疑从坏运气转为批次问题。 |
| 10月29日 06:15 | 按批次标识符和通电小时数进行全舰队查询。受影响批次中有206块硬盘。31块已经超过计数并失败，其余距离该计数还有40到900小时。 |
| 10月29日 07:30 | 联系供应商。四小时内确认缺陷：磨损均衡遥测中的计数器在通电小时数达到1,536时溢出并卡死控制器。修复此问题的固件修订版已在六周前悄然发布。 |
| 10月29日 09:00 | 开始滚动更新固件，按剩余小时数排序。 |
| 10月30日 22:40 | 该批次的最后一块硬盘已更新或更换。 |
| 11月1日 14:00 | 受影响的客户实例已恢复或退款。 |
根本原因
两个原因，其中一个属于硬盘制造商。
他们的： 遥测计数器在固定通电小时数时溢出并卡死控制器。硬盘在断电重启后存活，但会在几分钟内再次卡死。盘上的数据完好但无法访问，这是凌晨四点诊断时最糟糕的组合。
我们的： 我们使用了同一次交付的硬盘来构建镜像。镜像本应是两个独立的故障域，而同一批次、同一下午上架、同一小时内通电的两块硬盘在任何重要意义上都不是独立的。整个舰队中有11个镜像以这种方式构建。其中10个幸运，因为热备盘首先完成了重建。一个没有。
我们多年来在原则上知道这一点。但没有人将其写入构建流程，而构建流程正是人们在凌晨两点交付期限下遵循的东西。
影响
- 三十九次故障被镜像吸收，对客户无可见影响。
- 一个节点离线九小时十八分钟。
- 该节点上的十四个实例从节点外备份恢复，最多丢失十一分钟的写入。
- 两个实例没有任何备份。两者都丢失了节点上的所有数据。
我们做的改变
- 购买批次被拆分。 任何两块来自同一批次的硬盘都不能组成镜像，保护一对的热备盘来自第三批次。由构建工具强制执行，而不是文档。11月4日完成。
- 通电小时数的群组告警。 现在，当多个共享批次标识符的硬盘在100小时内接近任何整数小时数时，我们会发出告警。这是一种粗略的启发式方法，但本可以提前19天抓住这个问题。
- 生产前固件浸泡测试。 新的硬盘系列在测试机架中运行两千个通电小时，然后才承载客户数据。这个缺陷本会在1,536小时时浮现。
- 我们现在按计划阅读供应商固件发布说明。 修复在我们需要它之前六周就已经存在。没有人被指派查看，所以没有人查看。
我们未改变以及原因
我们未更换硬盘系列或供应商。 缺陷是真实的，披露也不佳，但我们的损失来自相关的批次问题，我们会与任何制造商复制同样的问题。更换会显得果断，但解决不了问题。
节点外备份仍是每500GB九欧元的附加服务。 将其普及意味着向每个客户收费，而大多数客户自己复制了这些服务，我们不会为安全的外观而收费。改变的是订购表单，现在明确说明实例存储是镜像的，而镜像不是备份，确认步骤不再允许该句子被静默跳过。
我们未采用三镜像。 它每GB多增加三分之一成本，并不能解决相关故障——这是实际的机制。两个独立的故障域胜过三个依赖的。
两个客户
两者都全额退回了受影响期间的费用，以他们支付的资产形式，且无需任何证明。一位离开了。另一位留下，现在购买备份附加服务，读到了订购表单上的相同句子，而这句话以较弱的形式一直存在。
这两种结果都不在我们的掌控之中。唯一在我们掌控之内的是正确构建镜像，而我们没有做到。