@lyl35023
一开始也是这么想的
但涉及到大量快照后增量数据同步的问题
而且...既然仓库 1 数据搬迁到仓库 2 的时候是错的，为什么业务能读取到正确数据？

@nullornull
这样的运维都能进腾讯。。。唉

@iConnect
所以确实没想通。。。

倒是因为这个事件围观各个帖子涨了不少存储领域的见识也算是有所收获

@ryd994
感谢科普！

@ryd994
能做块级存储集群的软件方案，不考虑读取写入校验是基本不可能存在的。
注意，要做到块级存储集群只可能是软件方案而不是硬件的 RAID 整列
能在各个计算节点互相飘的方案也只有走网络的 iSCSI 方案
（如果有别的方案希望给我科普一下，我实施过的只有 iSCSI ）

RAID 保证 uptime 不保证数据这点没错，但考虑到上层软件冗余与纠错... 这锅还是甩不掉啊...
而且 RAID6 的情况下本来就自带有错误发现的能力（读取过程中两个结果互相对比）
于是... 锅还是甩不掉...

@void1900
然而架构合理的情况下公告太不靠谱了...
所以...腾讯云依旧存在问题...

作为经历过各类云服务长毛事件的一代人（例如当年的 QQ 中转站）
我就没相信过任何云服务会可靠，数据在手才是自己的
提到的各种可靠性数字是一个字都不信的（没有单位，没有标准，作为广告都能算是虚假宣传）
云服务本身是否可靠，能否作为主业务节点，需要实际情况实际分析...
例如现在的各种负面...

另: 我关于是否选择云服务的看法可以看看这帖子的回复（#47 ）
https://www.v2ex.com/t/476956

@void1900
搞不懂你是在杠还是在讨论问题
本来我觉得你在贴头说的话还挺有理的
然后在回复这个帖子前重新看了回复对了下 id
现在我都不知道该怎么和你聊下去了

理性讨论问题是基本的礼貌与对别人的尊重且对双方的技术提升都能有所帮助，希望你懂这个道理。

@void1900
按照准则这个故障原因是日常不是异常

@void1900
给个场景？

@void1900
硬件 RAID 最基础最基础的低成本高可靠选项是 RAID6，不是 RAID5

RAID1 的存储成本过高
RAID5 存在两个磁盘损坏无法修复的可能性
RAID10 存在特定两个磁盘损坏后无法修复的问题（除非其中的 1 不止一个磁盘）
RAID50 存在特定两个磁盘损坏后无法修复的问题
RAID60 存在特定三块磁盘损坏后无法修复的问题

假设现在情况真的是磁盘回报异常，那么算是静默错误，当成磁盘写入全 0 好了
且故障真的是固件 BUG 引发，那么非同固件且非同批次磁盘构建阵列这个准则是否已经违反？

所以说在正确构建阵列的情况下这是概率极低的事件
除非。。。阵列卡出 BUG 了

@void1900
重新阅读回复，你会知道为什么同时损坏理应概率极低

@void1900
构建磁盘阵列的时候，静默错误是个必然需要考虑的异常情况
（事实上依据观察 V 站的各位似乎考虑到这个问题的并不多）

针对的是单个磁盘回报不正确数据的情况，该如何尽早的发现尽早的排除
在支持静默错误发现的阵列系统例如：ZFS
静默翻转 /静默写入读出不一致是不可能导致整个磁盘阵列丢失数据的
因为软件层面上会实时的校验读取到的数据与元数据是否一致（显然元数据也是冗余的）
对于异常磁盘一次读出就尽早修正并且抛出警告了
如果问题出自硬盘底层固件，那么问题范围也仅仅可能局限在一个磁盘阵列节点也不可能全存储系统的崩溃

高可用磁盘底层架构为非同批次、非同固件的等容量、等架构磁盘组建硬件 /软件 RAID
此磁盘柜应配合巡检定期校验数据是否可用，并尽早踢出异常磁盘
三备份应是基于此磁盘架构的冗余备份架构，无论是实时互备还是定时冷备

一般云 VPS 服务的自动迁移依赖独立的磁盘柜与计算集群实现
那么在腾讯的这个案例上，可能存在三台阵列柜、一套磁盘阵列网关与若干计算节点组成的计算机群
丢失数据的范围为一个集群（假定整个集群都出现静默错误，且真的存在三备份架构）

那么问题来了
1、为什么现在只有一家公司发声？
2、如果真的是三备份架构，为什么会三套存储设备同时故障？
3、为何阵列损坏后没有任何警告、通知直接就是静默错误？

假设现在的信息都为真实信息，没有人为修饰掩盖
有以下推断：
1、不存在三套设备互备的磁盘架构
2、这个软件 BUG 不在硬盘而在软件分布式上面
3、假设 2 推断为假，软件 BUG 位于磁盘，则阵列架设没有严格遵守高可用原则进行设计
4、假设 2 推断为真，那么更有可能的情况是 BUG 位于阵列卡，数据位于单一母机，丢失范围为一台母机
5、假设 2 推断为真，数据存在集群上面，且 BUG 位于自研的分布式存储平台上，那么...不多说了

说实在，怎么想都想不出来为什么一个成熟的云平台能搞到数据全丢
甚至有点怀疑是不是有人手动的“ rm -rf ”然后后续业务直接写花了集群

吹归吹，好好了解下云平台的架构（特指云服务器平台）就会知道，那东西本质上就是一个虚拟机。
问题来了：虚拟机的安全性与可靠性由什么来决定？

归根结底还是对技术的不了解，对数据的不负责。

@Backlitz
因为你真的不懂

@Backlitz
不懂别乱说

代理加速器一般是使用更高优先级的线路（例如 CN2、MPLS ）或者路由更好的落地服务器（某些特定的直连机房）
以在路由配置不妥的直连环境下人为的创造一个相对优化合理的虚拟链路

而现在，某些方案下，代理加速器使用的是 SDN （软件定义网络）技术
在不可靠的公有网络上创造一个相对可靠、快速的私有网络
同时在加入更多的冗余技术、选择更好的落地服务器，结合上文提到的更高优先级线路（ CN2 ）
提供更加快速、可靠、成本相对较低的虚拟链路方案。

可以补充考虑下：MSI GS 系列

AKG K701 亲测适合
Audio-Technica ATH-SR5 亲测适合

没有非黑即白的绝对占优的架构
什么时候适合上云，什么时候适合离开云，什么时候适合混合云
这些是需要结合实际业务、资金、人员进行考虑的，没有绝对的准则
（人员情况需要独立考虑而不是归入到资金是因为某些领域的研发能兼顾一部分的服务器运维工作）

对于互联网项目
在创业初期，云能提供最基本的数据安全保障，不必耗费大量的时间构建基础设施能快速的启动业务。
而在业务的发展期，云服务的动态扩展能力能进行无缝的扩容，显然这也是公司所需要的
在业务逐渐成熟的时候，显然基于带宽、存储、运算费用的考虑，会有一部分的业务迁出云平台
这时候就产生了混合云架构
最后当业务量足够大了以后，混合云的私有服务器占比会越来越高。
最终是否抛弃公有云转入自研，这就需要实际情况实际判断了。

但显然这是不一定的，对于某些类型的业务：例如特定小范围的视频直播分发
在一开始就会因为带宽的缘故组建自有的核心节点\边缘节点\单一混合节点
（虽说这类业务也有云，但考虑到带宽费用...）
显然这时候在创业初期选择私有服务器 /混合云方案能满足基本的业务需求即可
在业务量上来以后再逐步接入现成的网络基础设施能降低整体的费用
（业务的特殊性意味着接入现有的云服务不会有太多的代码上的修改甚至一开始就能做好相互兼容）

综上，在不带业务场景的情况下讨论这个问题感觉并不完整。

另：基于 ESXI 的私有云方案了解下？