集群醫生華佗是集群自動化故障監測和處理系統，是平臺和運維對接的關鍵系統。一方面完成飛天其他組件不擅長的OS和硬體的故障自動監測和處理，另一方面推動飛天去及時規避硬體和OS引起的故障，使得故障能夠閉環運轉，大幅度減少故障處理成本和造成的影響。飛天5K項目期間的規模效應凸顯出自動化處理故障的必要性，大幅提升了飛天平臺的穩定性，提高了運維人員的幸福感。華佗在飛天中的位置如圖1所示。
由來
2011年底和2012年初，飛天系統的通信系統使用的是夸父，夸父通過Agent代理負責本機所有的網絡通信，如果機器之間想要彼此通信，需要將彼此的IP加入到對方的配置文件中。由於集群變更頻繁和Agent本身穩定性的原因，出了好幾起和夸父配置及連通性相關的故障。夸父處於集群最底層，要保持集群的全連通，同時集群間也有通信的需求，也需要通過變更配置文件打通連通性。日常業務中，集群經常需要上線和下線機器，導致配置文件需要經常性地變更，偶爾A集群加了一批機器，B集群壓根不知道，造成集群間通信時而通，時而不通，查找原因非常困難。同時由於各種原因，會造成夸父之間的連接經常性地處於半通不通狀態。查找這樣的連接幾乎也需要兩兩測試連接，對於一個2000臺的集群，則需要測試2000×2000次操作，工作量非常大。華佗吸收了大量開發和運維經驗，用了隨機抽樣覆蓋加自動處理的方式解決了夸父連通性監控和處理的問題。
2013年初，雲梯2集群中的硬體3年保質期已過，但任務卻越來越多，連續好幾次的基線超時都與壞盤、慢盤相關。但對於壞盤和慢盤，大家一直都沒有一個很好的辦法和標準來界定——究竟壞到什麼程度、慢到什麼程度就會對應用產生影響。於是華佗就開始了解決壞盤和慢盤問題之旅。
飛天5K項目期間，由於規模效應，盤、機器、網絡的各種故障幾乎成為常態，各種異常都成為造成集群服務質量嚴重下降的根源。但在應用層來處理這種底層的異常顯然是隔靴搔癢，又慢又費勁，例如：
■ 發現總有一些機器有各種異常，使之很慢，但又沒有完全死透；
■ 集群間12根光纖有一根異常，造成部分通信異常，出現大量長尾的數據拷貝進程，拖慢總體進程；
■ 集群內的一臺交換機時斷時通，造成服務斷斷續續或者服務時間巨長；
■ 有一個Job的Worker進程內存總是超限造成被殺，影響其他進程。
定位和思考
在過去的3年裡，尤其是做飛天5K項目的3個多月裡，飛天單集群的規模增長了近一個量級，離線集群的數量也增長了10倍，而運維人員的規模卻沒有顯著的增加。按照當時的增速，運維人員和機器的數量比例將達到10000:1。根據以往的運維經驗，這個規模下，如果沒有故障的自動化處理，運維人員幾乎24小時都要處理故障，因為底層一個簡單的故障放大到上層可能是幾十倍到幾百倍的複雜度。例如一個交換機的網絡故障（半壞不壞），可能就會引起大批量的任務失敗，但調查失敗的根本原因可能要翻遍整個系統才知道是網絡故障。更重要的是單集群的規模增大之後，人為處理故障過程中可能出錯的概率更大，並且一旦出錯，整個集群會無法服務，影響面將更大。
飛天平臺各個組件設計之初已具備了非常好的容錯功能，但一直沒有和運維體系進行很好的對接，故障處理一直是運維人員通過各種零散的工具或人工在維護處理，成本越來越高。由於以上原因，華佗就承擔了飛天平臺自動化故障處理系統的任務，提升集群故障發現、處理的效率和準確性，解放運維人員，提高飛天穩定性和可靠性。
實現
如何能又快又好地發現和解決線上故障呢？我們進行了很長時間的思考，得到了圖2中的架構圖。
華佗一般通過華佗Master與外圍系統打交道， 既接受盤古、伏羲這樣的飛天組件訂閱硬體、OS相關對象的狀態機以便採取對應動作規避故障，同時支持驅動磁碟、內存這類對象的維修管理。
如圖3所示，每個C代表一個Checker，W代表一個Worker。個虛線框代表一個集群，每個集群會出一臺機器組成一組Master，通常3~5個大集群共用一組Master。
華佗內部是典型的Master/Slave架構
■ Master：一般1個數據中心共享一組Master ，Master採用Raft協議實現高可用，Master提供Agent所需的各種存儲、協調、全局決策調度服務。例如，狀態機服務、ODPS倒入服務、Quota服務和Checker分發。
■ Agent：調度本地Checker和Worker，同時提供本地Checker和Worker所需的服務——KV和Queue等。
■ Checker：按照Master配置要求，完成故障的發現和狀態維護，同時產生Action Checker來完成故障處理。
■Worker：處理Master發送的Task。
■Client：Client以SDK的形式內嵌在飛天的各個組件中，可以訂閱華佗各個對象的狀態、Event等。
外圍系統
■ ODPS：阿里雲自主研發的大數據系統，華佗用ODPS進行大規模系統和故障的數據挖掘，用以提高故障檢測準確率和預測故障的發生。
■ 維修系統：運維團隊和供應商對接的硬體維修平臺，華佗通過維修系統以工單的形式來報修硬體。
■ Portal ：華佗提供運維操作平臺，用來監控和管理整個華佗。
■ ApsaraComponent：飛天基礎服務模塊，包含伏羲（飛天的調度系統）和盤古（飛天分布式文件系統），通過華佗SDK訂閱華佗的狀態機來實現與華佗的交互。
詳細實現
描述故障
想要很好地處理故障，就需要清晰地描述故障。狀態機是一種不錯的選擇，我們對於任何需要華佗處理的對象都建立狀態機來管理其整個生命周期。常見的狀態機包括但是不限於：磁碟、機器、網絡、內存、CPU、Apsarad（飛天守護進程）、ChunkServer（飛天存儲進程)。
一個故障的定義很自然：對象狀態或狀態組合。例如，對於磁碟故障，當一塊盤處於ERROR狀態時，單純就是磁碟故障；3塊盤故障處於ERROR狀態時，就是整個機器的故障。
狀態機是整個華佗的核心，所有的故障發現、處理、預測都是圍繞狀態機來完成的。
故障發現
Checker負責發現故障，發現故障後產生故障事件，Master處理Checker發現的事件，派發相應的動作給Worker，Worker負責執行具體Action（短期）或者Task（長期運行）；同時如果滿足條件，將進行狀態遷移。每個對象的狀態都有對應的Checker，Checker會一直負責檢查處於本狀態的條件，如果已不滿足了，則直接將狀態機變回次態。Checker是整個華佗的基礎，所有故障的發現，觸發源頭都是Checker。Checker是系統裡量最大的，也是Badcase積累的結果，如果要保持系統Checker快速的迭代更新，同時要防止Checker本身有Bug而造成滾雪球效應，該怎麼辦？先思考一下，後面會說到。
處理故障
當Checker進行狀態變遷或處於某個狀態時，會產生對應動作（Action），對應動作會進行某個操作，一直到失敗或進入下個狀態。有些狀態的變遷在Master端可能會產生Task，Task需要一些機器整體統一做一個動作，例如，某個集群的Master Role遷移，或某個交換機下線。
版本控制：灰度發布，全量更新，版本校驗
Checker定位於可能快速更新迭代的組件，以便運維或者開發能夠快速地支持各種故障的處理，Checker本身可能是個Binary、腳本、Rule。為了保證線上Checker的質量，除了日常的Review和測試，線上的灰度發布和版本控制必不可少。華佗使用SVN進行Checker的版本管理，使用Master進行版本分發。華佗可以做到IP粒度版本控制和校驗，基於此，華佗可以進行多版本同時灰度，同時驗證發布，以增加Checker的迭代速度。
Quota管理和手工駕駛
在整個華佗運行過程中，可能會有我們預料不到的Bug產生，這些Bug可能會放大錯誤，產生滾雪球的效應。例如，可能磁碟的判斷會在特定條件下出錯，這樣會讓大批量的磁碟下線，造成集群劇烈抖動。也可能Kernel出現類似208天的問題（LinuxKernel著名的一個Bug：系統連續運行208.5天自行重啟），引起機器大批量的宕機。基於以上考慮，結合華佗自我保護機制，華佗引入Quota管理和手工駕駛，即當故障率超過華佗預設閾值時，它將直接報警，不再採取任何措施，進入手工駕駛狀態，同時日常的變更也可以進入手工駕駛的狀態。
Portal
華佗的所有狀態機、報警、事件和動作都可以通過Portal和API進行查詢和訂閱，方便其他系統接入。Portal也可以進行日常的華佗版本查看、變更和其他的操作。最常見的使用場景是當某個Job失敗後，可以通過Portal來查詢Job所在的機器是否發生過故障。
日常數據收集、故障深度挖掘和預測
除了日常的實時故障處理，華佗也收集OS和硬體的關鍵數據，如Dmesg、Smartctl、Top、Tcp、Ecc等。這些關鍵的數據進入ODPS進行數據挖掘，來預測某個對象下一個狀態（故障）的發生概率，同時也會根據挖掘的結果來調整Checker的規則和參數，以提高故障檢測的準確率。
常見的場景
華佗目前已能夠處理主流硬體和OS相關的故障，長尾Badcase處理逐漸增加中，可以適應快速迭代和開發節奏，同時幫助運維和開發共同沉澱線上集群的故障管理經驗。
磁碟管理
圖4中每個節點都是一個狀態，每條線上標註了進入到下一個狀態的條件。
A. 磁碟打分
華佗會根據磁碟的硬體、軟體相關的10多個檢測項目，按照既定規則庫對磁碟的100多個評分項進行一個綜合評分，將磁碟進行分級：Good、Slow、Warning、Error和Fatal。
磁碟的好壞和快慢受很多因素影響，加上應用對於磁碟的訴求也不一樣，如Online關注延時，Offline更關注吞吐，還有更細分的指標關注壽命等，所以打分規則是動態調整的，各個應用可以指定各個指標的權重和計算規則。 圖5是我們對一年的某個生產數據進行分析後得出各個規則和指標對於最終結果的影響度。
圖5中的橫軸是各個Rule（指標），縱軸是影響度。前面幾項都是根據後面的一些基礎指標慢慢積累調節出來的，例如在Offline的集群上，我們發現Kernel某個線程D狀態的次數決定了這塊盤的快慢，如果長期處於D狀態，則磁碟一定是出故障了。
B. 磁碟的狀態變遷
■ 在磁碟進入SLOW或WARNING狀態時，在線應用一般會選擇不再使用此磁碟，因為此時磁碟可能已經出現損壞的跡象，會造成延時大規模增加，但對於理想的應用則可以繼續使用。
■ 一旦磁碟進入ERROR狀態，則表明此磁碟可能馬上損壞，必須立即執行下線動作。此時盤古通過訂閱華佗的磁碟狀態機識別到後，會將磁碟設置成SHUTDOWN狀態，即磁碟不可讀寫開始備份數據。
■ 待華佗通過盤古確認數據備份完畢（數據安全），將磁碟進入REPAIR狀態。在REPAIR狀態時，華佗會通過運維的維修系統進行報修。
■ 供應商根據報修系統報修的狀態，每周進行2~3次的磁碟更換服務。更換完畢後，華佗會自動檢測到有新盤上線，繼而進入NEWBIE狀態。進入NEWBIE狀態的磁碟，華佗會進行自動分區、格式化、預掛載。
■ 預掛載完畢後，華佗就會進入TEST狀態，進行基本的檢查和小型Benchmark測試後決定繼續維修還是上線。
■ 測試通過的盤，就會掛載到真實的掛載點上開始供盤古使用。同時磁碟進入GOOD狀態。
C. 所有的磁碟數據都會通過Analyzer進入ODPS進行挖掘和分析，分析完畢後會通過調整規則、指標、參數等提高磁碟檢測的準確度，這是一個長期的過程。
機器管理
圖6是機器狀態轉換圖，機器管理和磁碟類似。
■ 當機器有各種原因（根分區只讀、Load 超高、內存壞）會進入的ERROR狀態，伏羲會訂閱華佗的狀態，發現進入ERROR狀態，會將在這臺機器上的進程全部調度走。
■ 調度走以後，華佗機器的狀態機會很快進入FIX狀態，進入FIX狀態後會根據進入原因採取對應的動作，儘量修復（Reboot、Restart相關進程、清理磁碟）。如果修復失敗，機器的狀態機將進入REPAIR狀態。
■ 進入REPAIR狀態後，盤古會通過訂閱的狀態機發現，自動將機器SHUTDOWN開始備份數據。備份完畢後，華佗會將其通過報修系統報修掉。廠商會根據情況進行每周2~3 次的機器維修。
■ 維修完畢後，機器進入NEWBIE狀態。進入NEWBIE狀態的機器將會進行RECLONE相關環境準備等操作。
■ 完畢之後進入待上線狀態TEST。華佗會進行基礎的環境檢查，檢查完畢後通知Fuxi上線。
網絡故障檢測
網絡的檢測不像磁碟，單機就可以解決掉，並且現在都是雙上聯、Multipath的網絡，就是你和A機器進行通信走的是一根線一條路，你和另外一個機器B進行通信走的是另外一根線一條路。而恰恰有問題的情況是：一根線或者其中一個交換機有問題，造成網絡時好時壞、時快時慢，加上集群熱點等情況，非常難於定位和排查。
華佗採用簡單投票的方式篩選出最有問題的機器，工作方式如下。
■ 每臺機器會實時監測到它所通信機器的網絡丟包、TCP重傳、RTT、帶寬等指標。
■ 應用本機規則決定是否投票給異常的機器，投票給其他機器的同時投票給自己。
■ 得票最多的top N機器就是有問題的機器。
■ 找出top N機器所有通信有問題的五元組（協議、源地址、源埠、目的地址、目的埠），根據五元組算出所有通信的路徑。
■ 對於算出路徑上的網絡設備，查詢其錯誤日誌，看是否有相應的故障，有問題報警給網絡。如果有問題，則將對應的機器轉換至ERROR狀態，進入壞機器的處理策略中。
心得
通過建立磁碟自動化的處理和磁碟故障的預測，可以大大提高集群磁碟的整體合格率，原因是新集群上線一段時間內，出廠不合格的磁碟，華佗通過集群預熱期就下線掉了，再經過半年壞盤淘汰後進入穩定期，集群整體磁碟的可使用壽命大大提高。在我們的實踐中，壞盤率可以做到非常接近磁碟的MTTF。磁碟作為集群中數量最多、增長最快（6塊→12塊→18塊→24塊）、故障率最高、處理最複雜（涉及到數據安全）、最消耗人力的硬體，自動化的處理收益最高。
機器各種故障區分度很低，對於Offline的業務，我們採用了最簡單直接的處理方式，Replace、Restart、Reboot、Reimage和SHUTDOWN。使得每種故障能夠有明確的行為，降低上層處理的複雜度。
網絡是非常基礎的服務，所有的服務都依賴網絡，使得網絡變得非常敏感和複雜。一個5K集群，其交換機數量100+，埠數量超過10K。一旦有問題，第一時間定位是最關鍵的，華佗的引入使得網絡故障定位由原來的小時級別降低到分鐘級別。
總結
由於故障的處理和平臺及業務密切相關，所以這裡只是介紹了華佗通用的一面，只是冰山一角。具體各種故障處理裡隱藏著大量的細節，這些細節的處理都是平臺拿一次次的故障堆出來的，這也是Google和Amazon等大型平臺對於自動化平臺諱莫如深的原因。