背景
同事發現一個有重要服務在運行的物理機上，一個目錄雖然夠用，但是比另一台同樣服務的機器相比，空間很小。我們還是跟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過程中切一點點流量，實際證明確實是無損的。
總結思考
實際操作是整個處理過程的冰山一角，有驚無險就已經輸了。一次把所有事情做對是最高效的。
再早幾年的時候，我發現自己會經常想出來一些生活中的句子，覺得不亞於電影里的經典台詞。而在工作中，我經常需要發表一些自己的論點或者總結思考。而這時候，我總覺得自己說的是陳詞濫調。我總結了原因，從記事起，為生活思考是一種習慣，當我晚上在校園里一圈圈的走，當我坐車上，在車窗的玻璃哈氣上塗鴉，我都在思考。而自己為工作又思考了多少，思考了多久。
大學的時候，有個韓劇叫《黃真伊》，女主說：“藝術最需要的是痛苦。”從方法學的角度，痛苦起的作用是觸發人的深度思考。所謂興趣是最好的老師原理也是因為有興趣所以自然而然的會多為此思考。而現在我在事情的處理過程中思考還遠遠不夠。
推薦閱讀