背景
同事發現一個有重要服務在執行的物理機上，一個目錄雖然夠用，但是比另一臺同樣服務的機器相比，空間很小。我們還是跟SA溝通了此事。最終SA跟廠商確認是因為磁碟有壞道引起。因為我們磁碟陣列採用的是RAID1模式，所以並不影響服務執行，但是為了保證服務的穩定性，我們還是決定對磁碟進行修復。
結果呢，在約好的時間點，大家按照操作流程很輕鬆的修復了。但是前期我們做了很多工作。如果實際操作的時候並不輕鬆，而是突然出現了意外的情況或者沒有考慮到的步驟，雖然最終結果是有驚無險，那也說明我們的前期準備是非常失敗的。如果是一次飛機飛行，那就是在拿著生命開玩笑了。而輕鬆完成也只是入門等級，整個過程，我給自己打60分。
涉及的一些基本硬體知識
RAID
RAID是磁碟陣列，常用的模式有RAID0、RAID1、RAID5、RAID6、RAID10（這裡讀RAID一零）。
RAID0是機器使用兩塊硬碟，寫檔案的時候，採用分片模式，就是把檔案拆成均等的兩塊，同時寫入，這樣速度比使用一塊硬碟提高一倍。可用容量為硬碟容量之和。
RAID1是機器使用兩塊硬碟，寫檔案的時候，採用映象模式，就是把檔案寫入一塊硬碟，之後再複製一份到另一塊硬碟。這樣速度和一塊硬碟基本相同，兩塊硬碟容量其實只能用一半。但是通過冗餘進行容災，可以允許一塊硬碟損壞，不影響服務的執行。我們這次就是這種情況。
RAID5又稱為分散式磁碟，是兼顧容量、速度和容災的一個方案。至少要有3塊硬碟組成，採用單校驗機制(XOR校驗)。原資料和校驗資料會分開均勻儲存到各塊磁碟上。可允許一塊硬碟損壞。舉個例子，我有一段資料要儲存，內容是：
1 2 3 4 5 6
則：
| 硬碟1 | 硬碟2 | 硬碟3 |
| 1 | 2 | 1+2 |
| 3 | 3+4 | 4 |
| 5+6 | 5 | 6 |
RAID6是在RAID5的基礎上又增加一種校驗方式，至少要有4塊盤，從而可以允許兩塊硬碟損壞。由於複雜度高，功能比不高，所以一般RAID10或者RAID01這樣的組合模式更常用。RAID10是組合RAID1和RAID0，用4塊硬碟。資料有一塊盤做映象模式，一塊盤做分片模式，雖然容量還是隻有一半，但是速度提高了一倍，也可以容災。
rebuild
採用RAID1模式，一塊硬碟損壞，要更換可以採用熱插拔，之後會執行2到3小時的rebuild操作。rebuild過程重要做：磁碟檢查和資料複製兩件事情。
根據不同的硬體型號，rebuild過程中會有指示燈顯示磁碟狀態。比如有的rebuild過程中顯示黃色，完成後顯示綠色，代表狀態是online。
rebuild過程實際不影響服務執行，但是這個過程中讀寫硬碟會比較頻繁，通常建議隔離業務。
事件處理過程
事件處理開始，我們看到的現象就是根目錄的空間很小，其他目錄都是好幾百G，這個目錄只有十幾G。經過層層追問，最終和廠商一起查出是磁碟壞道引起。SA希望我們把業務隔離1天。而這個服務比較特殊，受外部制約，使用了一個十幾年前架構的閉源MQ。我們只有兩機房部署，每個機房都是單機執行，其他備份都是冷備。所以整體而言，磁碟修復過程中是單機執行的。所以我們和SA溝通，儘量縮短修復時間。最終我們的整個包含隔離和恢復業務耗時縮短為7個小時。做好準備之後，我們把整個處理過程整理成完整的時序；設計好異常處理流程；為了應對磁碟修復不好這種場景，我們制定了磁碟迴退的異常處理；為了應對不但磁碟沒有修好，反而整個物理機不能用的場景，我們制定了不得已啟用冷備機器的異常處理，這個處理需要進行網路變更，流程複雜，所以更要提前溝通好；然後我們統計好處理當天的業務量，估算好最壞影響時的影響的交易；還帶上廠商的分析等資料。總共列印出四張紙，我帶著去找領導彙報。
結果領導的兩個問題，證明我沒有把事情徹底搞清楚。一個是每個機房真的只能一臺機器執行嗎？因為用的MQ是閉源的，對接方也不清楚到底是為什麼只能一臺機器執行。確認的事情是對接方一個機房只給了一個IP，之前也諮詢過網路，是否可以使用虛擬IP。網路說不可以，但是具體的理由說的不是很清楚。另外一個說RAID1應該是熱插拔的，應該是插上就能用。建議說是否rebuild過程中就灰度一點點流量進來。這樣主要目的是如果另外一臺機器故障，流量可以自動全切到這個機房，達到容災的目的。領導還強調了一個關鍵詞：概率。帶著這個問題，我又和同事調研了一下。同事調研到不能用VIP的根本原因是通道訊息序列號問題。通道訊息序列號是記憶體計算的，每傳送或收到一條訊息，訊息序列號自動加1.通道兩端的序列號相差大於1，通道的狀態則從running變成fail。
另外一件事是概率的問題：我們認為單機執行7個小時是沒有問題的，是因為按照之前的執行情況，這7個小時發生事情的概率很小。所以我們認為這7個小時過程中完全隔離業務是無損的方案。實際情況是沒有發生問題是概率性的，不是確定的。而事情上rebuild過程中發生問題的概率也很低。SA制定的流程是從修復過程不出問題出發，因為他們做的是IAAS層的工作。而我們作為SAAS層，應該從整體對業務影響角度出發。領導還提了一個問題：7個小時能確保人會一點不走神的在那裡盯著嗎？如果另一臺伺服器一旦出現故障，從發現到處理，中間處理時間會很長。因為手動處理是需要溝通，並且操作要走審批。恢復不會很快。
針對這個問題，我讓同事在修復開始前，調整告警調整閾值，一筆失敗或者超時則簡訊告警。同時，我們又反思了在制定時序時的目標設定：無損交易下進行修復。但是沒有仔細考慮一旦單機執行時，執行機器發生問題時，必然交易損失，要手動來啟用EOP，那就是故障。而只是在硬碟插拔時隔離流量，rebuild過程手動驗證服務正常之後，切一點點流量，實際也是無損的，而且很可能rebuild過程中，一點正式流量都不會達到這臺rebuild中的機器。只是一旦另一臺機器出現問題，服務可以自動走這臺機器，不會造成故障(實際還有別的因素，實際自動容災行不通，這裡說明避免給我們自己的同事造成誤導，不影響對問題的說明)。所以我們最終決定rebuild過程中切一點點流量，實際證明確實是無損的。
總結思考
實際操作是整個處理過程的冰山一角，有驚無險就已經輸了。一次把所有事情做對是最高效的。
再早幾年的時候，我發現自己會經常想出來一些生活中的句子，覺得不亞於電影裡的經典臺詞。而在工作中，我經常需要發表一些自己的論點或者總結思考。而這時候，我總覺得自己說的是陳詞濫調。我總結了原因，從記事起，為生活思考是一種習慣，當我晚上在校園裡一圈圈的走，當我坐車上，在車窗的玻璃哈氣上塗鴉，我都在思考。而自己為工作又思考了多少，思考了多久。
大學的時候，有個韓劇叫《黃真伊》，女主說：“藝術最需要的是痛苦。”從方法學的角度，痛苦起的作用是觸發人的深度思考。所謂興趣是最好的老師原理也是因為有興趣所以自然而然的會多為此思考。而現在我在事情的處理過程中思考還遠遠不夠。
推薦閱讀