最近云平臺上面一件比較嚴重的事故就是騰訊云出現(xiàn)了用戶數(shù)據(jù)丟失斤彼，根據(jù)官方的回復绊起，主要是因為硬盤的靜默錯誤 + 運維的不規(guī)范操作造成的色难。網(wǎng)上已經(jīng)有很多文章來分析這次事故了席赂，我們自己內(nèi)部也在討論如何快速的發(fā)現(xiàn)硬盤的故障，畢竟對于 TiKV 來說矛渴，存放的是用戶的數(shù)據(jù)椎扬，也會面臨著盤壞的風險，如果能提前知道盤有問題具温，那么就能更早的做出處理蚕涤，提升服務的穩(wěn)定性。
剛好看到了一篇 Paper Improving Service Availability of Cloud Systems by Predicting Disk Error 铣猩，講述的是 Microsoft （MS）的團隊如何在 Azure 上面通過 CDEF 方法揖铜，預測硬盤的錯誤，并有效的提升 Azure 的可用性的达皿。
對于云服務來說天吓，如果能預測硬盤錯誤， 那么在分配 VM 以及 VM 實時遷移的時候峦椰，就會有非常大的好處龄寞，畢竟我們不想讓一個 VM 跑在壞的盤上面。而騰訊云上次的事故就是在運維在遷移的時候?qū)⒂脩舻?VM 放到了一個壞盤上面汤功。
但是在生產(chǎn)環(huán)境中物邑，預測硬件的錯誤其實是非常困難的，主要有幾個問題：
- VM 在硬盤完全壞掉之前，其實已經(jīng)早就掛掉了拂封。
- 現(xiàn)階段的一些預測方法茬射，譬如 cross-validation，并不準確冒签。
- 給硬盤打上 health labels 然后訓練也很困難在抛，譬如對于 azure 來說，每天只有 3 塊盤壞掉萧恕，而正常的盤是 10000 塊刚梭，這個比例是極度不平衡的。
為了解決這些問題票唆，Microsoft 的團隊使用了 CDEF (Cloud Disk Error Forecasting) 方法朴读。
對于問題 1，我們知道走趋，硬盤通常都有一個監(jiān)控固件用來匯報硬盤當前的狀態(tài)衅金，我們叫做 SMART (Self-Monitoring, Analysis and Reporting Technology)，一些常用的 SMART 數(shù)據(jù)如下：
| SMART ID | Description |
|---|---|
| S2 | Start/Stop Count |
| S12 | Power Cycle Count |
| S193 | Load Cycle Count |
但是簿煌，僅僅有 SMART 的數(shù)據(jù)是不夠的氮唯，因為當通常 SMART 知道硬盤有問題的時候，VM 其實已經(jīng)出現(xiàn)了問題姨伟，所以惩琉，我們不光要收集 SMART 的數(shù)據(jù)，還需要收集系統(tǒng)級別的信號夺荒，譬如：
| Signal | Description |
|---|---|
| PagingError | Windows 在創(chuàng)建一個 paging 文件的時候遇到了錯誤 |
| FileSystemError | 當嘗試讀瞒渠，寫或者打開文件的時候出錯 |
| VMFrozen | VM 不響應連接請求 |
因為這些系統(tǒng)級別的信號，通常都是會在硬盤出錯之前報出來技扼，所以當我們收集了這些以及 SMART 之后伍玖，就可以用我們的預測模型來預測相關的硬盤錯誤了，包括延遲剿吻，超時私沮，sector 錯誤等。
雖然現(xiàn)在有了收集的數(shù)據(jù)和橙，但現(xiàn)在的很多模型其實預測的并不精確，Microsoft 團隊就沒選擇一些傳統(tǒng)的訓練方法造垛，而采用了在線預測的方式來解決問題 2魔招。因為這里涉及到很多機器學習相關的東西了，本人不怎么了解五辽，直接略過了办斑。
而對于問題 3，MS 的團隊采用了一種 ranking 的方式，與其簡單的告訴一塊盤是壞的還是不是乡翅，他們按照硬盤的故障趨勢來為硬盤分了等級鳞疲。為了訓練 ranking 模型，MS 的團隊根據(jù)歷史的硬盤故障數(shù)據(jù)蠕蚜，按照出現(xiàn)錯誤的相應時間來分級（譬如從開始采集數(shù)據(jù)到第一次發(fā)現(xiàn) error 的間隔天數(shù)）尚洽，具體訓練又涉及到機器學習了，直接忽略了靶累。
為了提升服務的可用性腺毫，當分配 VM 的時候，當然希望分配到未來一段時間損壞概率低的盤上面挣柬。為了達到這個目的潮酒，MS 的團隊根據(jù)盤壞掉的概率定義了故障盤和健康盤。對于大部分的盤來說都是健康的邪蛔，只有少量的是故障的急黎，MS 的團隊根據(jù)上面的 ranking 模型選擇最高的 r 個結果，計算公式如下：
cost = Cost1 * FPr + Cost2 * FNr
FR 和 FN 是 r 個預期結果里面假正（false positives）和假負（false negatives）的個數(shù)侧到， Cost1 是錯誤的將一個健康的盤標記成故障的開銷勃教，主要是在實時遷移中，將 VM 從一個『故障』的盤遷移到了正常的盤上面床牧。Cost2 則是漏掉了實際的故障的盤荣回。這兩個 cost 都是根據(jù)經(jīng)驗來的，在 MS戈咳，Cost1 和 Cost2 通常是 3:1 的關系心软。
現(xiàn)在有了數(shù)據(jù)，有了模型著蛙，剩下的事情就是驗證這套機制是否生效了删铃。對于 MS 來說，Azure 就是一個非常好的驗證的地方踏堡，具體結果可以看 Paper猎唁，看起來是不錯的。
那么顷蟆，對于 TiKV 來說有啥借鑒意義呢诫隅？雖然這個方法看起來挺不錯的，但 TiKV 其實并沒有那么多的磁盤帐偎，盲目的引入這么一套判定方法有點不切實際逐纬。另外，TiKV 有三個副本削樊，能很大程度上面緩解相關的磁盤問題豁生。當然如果能有一個輕量級的定期數(shù)據(jù)檢查的機制會更好兔毒。
