“数据丢失事件”续集：腾讯云还原“人为失误”全过程

雷锋网消息，8月7日晚，腾讯云官方微信公众号发布了《关于客户“前沿数控”数据完整性受损的技术复盘》，对“数据丢失事件”全过程进行了还原。

“数据丢失事件”指的是北京清博数控科技有限公司所属“前沿数控”平台一块操作系统云盘发生故障，导致文件系统元数据损坏这一事件，而该公司购买的正是腾讯云的服务。

据了解，这是腾讯云继8月6日上午《关于用户“前沿数控”数据完整性受损及腾讯云补偿措施的说明》之后的第二次官方回应。此前声明见文章：腾讯云回应“数据丢失事件”

据雷锋网观察，此次腾讯云发布的“复盘通知”主要有4点信息：

1、还原了故障过程

2、解释了故障原因

3、公布了改进措施

4、提出了客户建议

腾讯云指出，“前沿数控”平台数据丢失除了物理因素外，人为失误是重要原因，腾讯云为此做了深刻检讨：

复盘发现，该故障缘起于因磁盘静默错误导致的单副本数据错误，再加上数据迁移过程中的两次不规范的操作，导致云盘的三副本安全机制失效，并最终导致客户数据完整性受损。

“前沿数控”平台数据丢失，发生在2018年7月20日，当天腾讯云运维人员是如何发现，又是如何尝试组织技术专家修复的呢？

还原故障过程及故障原因

且看腾讯云还原的全过程：

当天（7月20日）上午11:57，我们的运维人员收到仓库Ⅰ空间使用率过高告警，准备发起搬迁扩容；

在14:05时，运维人员从仓库Ⅰ选择了一批云盘搬迁至新仓库Ⅱ，为了加速搬迁，手动关闭了迁移过程中的数据校验；

在20:27 搬迁完成之后，运维人员将客户的云盘访问切至仓库Ⅱ，同时为了释放空间，对仓库Ⅰ中的源数据发起了回收操作；

到20:30 监控发现仓库Ⅱ部分云盘出现IO异常。

这个过程中涉及多次人为操作步骤，但“磁盘静默错误导致的单副本数据错误”这一物理过程，运维人员是无法操控的，只有当中两次操作是出了“大问题”的：

第一是正常数据搬迁流程默认开启数据校验，开启之后可以有效发现并规避源端数据异常，保障搬迁数据正确性，但是运维人员为了加速完成搬迁任务，违规关闭了数据校验；

第二是正常数据搬迁完成之后，源仓库数据应保留24小时，用于搬迁异常情况下的数据恢复，但是运维人员为了尽快降低仓库使用率，违规对源仓库进行了数据回收。

腾讯云后续如何改进？降低人工干预、优化巡检机制

实际上，这件事给腾讯云带来了不小的公关负担。在复盘通知里，腾讯云诚恳地给出了一些加强和改进措施：

首先，我们将全面审视所有的数据流程，涉及数据安全的流程自动化闭环，进一步提升我们常规运维自动化和流程化，降低人工干预。同时把全流程的数据安全校验作为系统的常开功能，不允许被关闭。

其次，针对物理硬盘静默数据错误，在当前用户访问路径数据校验自愈的基础上，我们优化现有巡检机制，通过优先巡检主副本数据块、跳过近期用户访问过的正确数据块等方法，加速发现该类错误，进行数据修复。

公告最后，腾讯云提示客户，实际上，腾讯云自2016年3月以来一直在提供免费的快照功能，可以对重要数据进行定期备份。同时出于对客户数据隐私性和安全性的考虑，客户可以自由选择开启或者不开启这一免费功能。腾讯云呼吁客户开启这一功能，进一步提升自身数据的安全性。

双方商量恢复运营方案：和解金额未透露，未公布责任员工名单

此前，“前沿数控”平台基于自身评估就此次故障对腾讯云提出了高达11016000元的索赔要求，腾讯云认为这明显高于他们能够提供的方案——这也是此次双方此前未能达成一致的主要原因之一。

眼下，据腾讯云方面透露，他们正在“积极与前沿数控方商量恢复运营的方案”。

雷锋网看来，关键的一点是，他们最终会达成多少金额的赔偿方案，此前腾讯云14万的赔偿+补偿方案遭拒（客户消费额的37倍），这次会是多少？

因为，这不是个例，后期其他云厂商也会遇到类似的问题，市场都会关注腾讯云的处理方式，毕竟，被“碰瓷”总不是件好事。

值得注意的是，对于这次事件中误操作的工作人员，腾讯云没有点名，也没有公布处罚方式，预计已做内部处理。

何为磁盘静默错误？腾讯云两次公告都提及

雷锋网认为，腾讯云两次公告都提及一个原因：磁盘静默错误。究竟这是什么类型的错误？元凶是什么？

Martin Petersen 和 Sonny Singh在《Emulex 和 Oracle 最佳实践》一书中曾指出，数据损坏经常发生在写入磁盘驱动器的时候。磁盘驱动器损坏有两种基本类型：

第一种是潜在扇区错误，通常由物理磁盘驱动器故障导致。例如，磁盘阵列报告的文件系统读取错误。这种类型的损坏通常由 I/O 路径中的纠错码 (ECC) 或循环冗余校验 (CRC) 检测到，常常会自动纠正。

第二种是静默数据损坏，可在没有警告的情况下发生，可以定义为组件故障或管理操作疏忽所导致的非恶意数据丢失。静默数据损坏发生在读取或写入无效数据时，不会导致 I/O 操作失败。这种类型的损坏是最具灾难性的，如果没有端到端的数据完整性检查，是没有有效的方法来检测它的。

使用虚拟化服务器和多核处理器，会增大故障存储单元导致错误的可能。如果在应用程序或数据中心工作人员不知情的情况下发生这样的错误，就称为静默数据损坏。尽管静默数据损坏相对比较少见，但它可能长时间不被发现，从而导致代价高昂的关键业务功能无法使用的损失。

导致静默数据损坏的常见元凶包括：

1、操作系统，包括核心操作系统和设备驱动程序

2、存储硬件和固件

3、管理错误

那么“静默数据损坏”发生的概率有多少呢？

《Silent data corruption in SATA arrays: A solution - Josh Eddy August 2008》一书曾对静默错误进行了解释。该文提供了一组数据：

一项针对NetApp数据库中150万个硬盘驱动器的学术研究在32个月内发现，8.5％的SATA磁盘会产生静默损坏。某些磁盘阵列运行后台进程，以验证数据和RAID奇偶校验是否匹配，并且可以捕获这些类型的错误。然而，该研究还发现，后台验证过程中错过了13％的错误。

这意味着——没有被发现的那些错误，最终会让企业为此承担风险、付出代价。实际上，随着网络安全越发重要，关于“静默数据损坏”这个领域，相当值得各大云厂商加以关注并投入研究。