通过预测硬盘错误来提升云上的服务可用性
最近云平台上面一件比较严重的事故就是腾讯云出现了用户数据丢失，根据官方的回复，主要是因为硬盘的静默错误 + 运维的不规范操作造成的。网上已经有很多文章来分析这次事故了，我们自己内部也在讨论如何快速的发现硬盘的故障，毕竟对于 TiKV 来说，存放的是用户的数据，也会面临着盘坏的风险，如果能提前知道盘有问题，那么就能更早的做出处理，提升服务的稳定性。
刚好看到了一篇 Paper Improving Service Availability of Cloud Systems by Predicting Disk Error ，讲述的是 Microsoft （MS）的团队如何在 Azure 上面通过 CDEF 方法，预测硬盘的错误，并有效的提升 Azure 的可用性的。
对于云服务来说，如果能预测硬盘错误， 那么在分配 VM 以及 VM 实时迁移的时候，就会有非常大的好处，毕竟我们不想让一个 VM 跑在坏的盘上面。而腾讯云上次的事故就是在运维在迁移的时候将用户的 VM 放到了一个坏盘上面。
但是在生产环境中，预测硬件的错误其实是非常困难的，主要有几个问题：
- VM 在硬盘完全坏掉之前，其实已经早就挂掉了。
- 现阶段的一些预测方法，譬如 cross-validation，并不准确。
- 给硬盘打上 health labels 然后训练也很困难，譬如对于 azure 来说，每天只有 3 块盘坏掉，而正常的盘是 10000 块，这个比例是极度不平衡的。
为了解决这些问题，Microsoft 的团队使用了 CDEF (Cloud Disk Error Forecasting) 方法。
对于问题 1，我们知道，硬盘通常都有一个监控固件用来汇报硬盘当前的状态，我们叫做 SMART (Self-Monitoring, Analysis and Reporting Technology)，一些常用的 SMART 数据如下：
| SMART ID | Description |
|---|---|
| S2 | Start/Stop Count |
| S12 | Power Cycle Count |
| S193 | Load Cycle Count |
但是，仅仅有 SMART 的数据是不够的，因为当通常 SMART 知道硬盘有问题的时候，VM 其实已经出现了问题，所以，我们不光要收集 SMART 的数据，还需要收集系统级别的信号，譬如：
| Signal | Description |
|---|---|
| PagingError | Windows 在创建一个 paging 文件的时候遇到了错误 |
| FileSystemError | 当尝试读，写或者打开文件的时候出错 |
| VMFrozen | VM 不响应连接请求 |
因为这些系统级别的信号，通常都是会在硬盘出错之前报出来，所以当我们收集了这些以及 SMART 之后，就可以用我们的预测模型来预测相关的硬盘错误了，包括延迟，超时，sector 错误等。
虽然现在有了收集的数据，但现在的很多模型其实预测的并不精确，Microsoft 团队就没选择一些传统的训练方法，而采用了在线预测的方式来解决问题 2。因为这里涉及到很多机器学习相关的东西了，本人不怎么了解，直接略过了。
而对于问题 3，MS 的团队采用了一种 ranking 的方式，与其简单的告诉一块盘是坏的还是不是，他们按照硬盘的故障趋势来为硬盘分了等级。为了训练 ranking 模型，MS 的团队根据历史的硬盘故障数据，按照出现错误的相应时间来分级（譬如从开始采集数据到第一次发现 error 的间隔天数），具体训练又涉及到机器学习了，直接忽略了。
为了提升服务的可用性，当分配 VM 的时候，当然希望分配到未来一段时间损坏概率低的盘上面。为了达到这个目的，MS 的团队根据盘坏掉的概率定义了故障盘和健康盘。对于大部分的盘来说都是健康的，只有少量的是故障的，MS 的团队根据上面的 ranking 模型选择最高的 r 个结果，计算公式如下：
cost = Cost1 * FPr + Cost2 * FNr
FR 和 FN 是 r 个预期结果里面假正（false positives）和假负（false negatives）的个数， Cost1 是错误的将一个健康的盘标记成故障的开销，主要是在实时迁移中，将 VM 从一个『故障』的盘迁移到了正常的盘上面。Cost2 则是漏掉了实际的故障的盘。这两个 cost 都是根据经验来的，在 MS，Cost1 和 Cost2 通常是 3:1 的关系。
现在有了数据，有了模型，剩下的事情就是验证这套机制是否生效了。对于 MS 来说，Azure 就是一个非常好的验证的地方，具体结果可以看 Paper，看起来是不错的。
那么，对于 TiKV 来说有啥借鉴意义呢？虽然这个方法看起来挺不错的，但 TiKV 其实并没有那么多的磁盘，盲目的引入这么一套判定方法有点不切实际。另外，TiKV 有三个副本，能很大程度上面缓解相关的磁盘问题。当然如果能有一个轻量级的定期数据检查的机制会更好。
