xanpeng

@void1900

开发的底裤是不是要谨慎? —— 存储研发底线（底裤）就是不能丢数据。我们都知道和理解代码会有 bug，存储研发这里要谨慎地通过各种手段去容错。
存储一般也就是 raid，这里没人拿单机硬盘洗了 —— 我并非特指此文，可能本站其他文章里提及。
固件问题，我自己都碰过，镁光的 ssd，算靠谱吧？时间门，5000 小时候会导致系统死机 —— 固件问题遇到过的人不少，所以需要前面说的谨慎和容错
准入问题，bug 能遇见就不叫 bug 了，这里不是说有 bug 才对，而是 bug 不可避免，程序员应该理性面对 —— 这又是个概率问题了，是可能有 bug 的，不过出现几率小，真出现了，就认了，但同时也得反思准入流程是否有漏洞。而且真是大规模固件 bug，好事啊，这锅可以正大光明地甩出去了呀

@void1900 “我想说的其实是身为开发者要理性面对数据丢失问题” 附言里这句我认同。
不过现实是诸多中小企业难以都做到关键数据本地备份。

@reus 有可能是单点落盘，然后异步跟上。但可能性比较小，应该不会有人这么做，否则异步窗口期故障概率大很多，绝达不到 9 个 9.

另外关于备份，要求用户备份不大现实，这么多中小企业，让他们自己去做备份不大现实。一般买卖双方都相信那个 9 个 9.
反而云厂商自己做备份更好吧。不过主动做备份的云厂商有么，我也不清楚...

我也好奇，出过数据问题的国内外云厂商们，多少故障是落在那 9 个 9 之外的？我印象里还没有人这么承认过吧。

而且硬盘静默数据错误这个说法，十有八九是背锅的，真正错误原因没说出来。因为：
1、如果同批次硬盘固件有问题，丢数据的客户很可能不只这一家了。
2、如果真是硬盘固件问题，怎么准入的？ tx 肯定用大厂硬盘的吧（不然就是自己作死，相关人得负责任了），大厂硬盘大规模出现类似问题的，没怎么听过吧。这次真是问题的话，这个锅妥妥地甩给硬盘厂商了吧。

真正原因应该是副本间一致性没做好。

另外拿硬盘静默数据错误来挡枪，也是不专业的。
tx 这样的大厂，静默数据错误怎么着也得解决了吧。阿里肯定是宣称解决的，tx 我印象里也这么宣称过，但不确定。

这个问题没什么好洗的，做存储的都知道，底裤是不能丢数据。
你可以数据离线一段时间不能访问，就是不能丢数据。
是说 9 个 9 的可靠性，理论上的确不是 100%，但...没必要拿这个理论极值来洗了吧。

至于其他的，那是其他问题（比如赔偿方式额度等，比如备份等），可以把讨论重点放到其他问题上，但逃脱不了这个事实：你丢数据了。

也没必要拿备份来洗。
客户本地备份了，是客户自己做的好。掩盖不了你云存储丢数据的事实。
客户没有备份，他们自己可以怪自己没备份，但你 tx 就不能怪他没备份了。毕竟他相信你云存储宣称的 9 个 9，毕竟他本地可能就没有数据中心。

拿单机硬盘来类比的就更可笑了，这么来洗的，要么是真不理解，要么就是故意了。本来云存储多副本就是要解决单机硬盘可靠性问题的。

不怕JD“偷窥”你的代码么？

专业：计算机
工作：存储