阿里如何做到百萬量級硬體故障自愈？
阿里妹導讀：隨著阿里大資料產品業務的增長，伺服器數量不斷增多，IT運維壓力也成比例增大。各種軟、硬體故障而造成的業務中斷，成為穩定性影響的重要因素之一。本文詳細解讀阿里如何實現硬體故障預測、伺服器自動下線、服務自愈以及叢集的自平衡重建，真正在影響業務之前實現硬體故障自動閉環策略，對於常見的硬體故障無需人工干預即可自動閉環解決。
另外，我們建立了阿里智慧運維交流群，為運維同行及 AIOPS 探索的技術人員提供交流平臺，期待與你共同探討。 入群方式見文末。
1.背景
1.1.面臨挑戰
對於承載阿里巴巴集團95%資料儲存及計算的離線計算平臺MaxCompute，隨著業務增長，伺服器規模已達到數十萬臺，而離線作業的特性導致硬體故障不容易在軟體層面被發現，同時集團統一的硬體報障閾值常常會遺漏一些對應用有影響的硬體故障，對於每一起漏報，都對叢集的穩定性構成極大的挑戰。
針對挑戰，我們面對兩個問題： 硬體故障的及時發現與故障機的業務遷移。 下面我們會圍繞這兩個問題進行分析，並詳細介紹落地的自動化硬體自愈平臺——DAM。在介紹之前我們先了解下飛天作業系統的應用管理體系——天基（Tianji）。
1.2.天基應用管理
MaxCompute是構建在阿里資料中心作業系統——飛天（Apsara）之上，飛天的所有應用均由天基管理。天基是一套自動化資料中心管理系統，管理資料中心中的硬體生命週期與各類靜態資源（程式、配置、作業系統映象、資料等）。而我們的硬體自愈體系正是與天基緊密結合，利用天基的Healing機制構建面向複雜業務的硬體故障發現、自愈維修閉環體系。
透過天基，我們可以將各種物理機的指令（重啟、重灌、維修）下發，天基會將其翻譯給這臺物理機上每個應用，由應用根據自身業務特性及自愈場景決策如何響應指令。
2.硬體故障發現
2.1.如何發現
我們所關注的硬體問題主要包含：硬碟、記憶體、CPU、網絡卡電源等，下面列舉對於常見硬體問題發現的一些手段和主要工具：
在所有硬體故障中，硬碟故障佔比50%以上，下面分析一下最常見的一類故障：硬碟媒介故障。通常這個問題表象就是檔案讀寫失敗/卡住/慢。但讀寫問題卻不一定是媒介故障產生，所以我們有必要說明一下媒介故障的在各層的表象。
a. 系統日誌報錯是指在/var/log/messages中能夠找到類似下面這樣的報錯
Sep 3 13:43:22 host1.a1 kernel: : [14809594.557970] sd 6:0:11:0: [sdl] Sense Key : Medium Error [current] Sep 3 20:39:56 host1.a1 kernel: : [61959097.553029] Buffer I/O error on device sdi1, logical block 796203507
b. tsar io指標變化是指rs/ws/await/svctm/util等這些指標的變化或突變，由於報錯期間會引起讀寫的停頓，所以通常會體現在iostat上，繼而被採集到tsar中。
-
在tsar io指標中，存在這樣一條規則讓我們區分硬碟工作是否正常 qps=ws+rs<100 & util>90，假如沒有大規模的kernel問題，這種情況一般都是硬碟故障引起的。
c. 系統指標變化通常也由於io 變化引起，比如 D住引起load升高等。
d. smart值跳變具體是指197(Current_Pending_Sector)/5(Reallocated_Sector_Ct)的跳變。這兩個值和讀寫異常的關係是：
-
媒介讀寫異常後，在smart上能觀察到197(pending) +1，表明有一個扇區待確認。
-
隨後在硬碟空閒的時候，他會對這個197(pending)中攢的各種待確認扇區做確認，如果讀寫通過了，則197(pending) -1，如果讀寫不通過則 197(pending)-1 且 5(reallocate)+1。
總結下來，在整條報錯鏈路中，只觀察一個階段是不夠的，需要多個階段綜合分析來證明硬體問題。由於我們可以嚴格證明媒介故障，我們也可以反向推導，當存在未知問題的時候能迅速地區分出是軟體還是硬體問題。
上述的工具是結合運維經驗和故障場景沉澱出來，同時我們也深知單純的一個發現源是遠遠不夠的，因此我們也引入了其他的硬體故障發現源，將多種檢查手段結合到一起來最終確診硬體故障。
2.2.如何收斂
上一章節提到的很多工具和路徑用來發現硬體故障，但並不是每次發現都一定報故障，我們進行硬體問題收斂的時候，保持了下面幾個原則：
-
指標儘可能與應用/業務無關： 有些應用指標和硬體故障相關性大，但只上監控，不作為硬體問題的發現來源。 舉一個例子，當io util大於90%的時候硬碟特別繁忙，但不代表硬碟就存在問題，可能只是存在讀寫熱點。我們只認為io util>90且iops<30 超過10分鐘的硬碟可能存在硬體問題。
-
採集敏感，收斂謹慎： 對於可能的硬體故障特徵都進行採集，但最終自動收斂分析的時候，大多數採集項只做參考，不作為報修依據。 還是上一個硬碟io util的例子，如果單純出現io util>90且iops<30的情況，我們不會自動報修硬碟，因為kernel問題也可能會出現這個情況。只有當 smartctl超時/故障扇區 等明確故障項出現後，兩者關聯才確診硬碟故障，否則只是隔離觀察，不報修。
2.3.覆蓋率
以某生產叢集，在20xx年x月的IDC工單為例，硬體故障及工單統計如下：
去除帶外故障的問題，我們的硬體故障發現佔比為97.6%。
3.硬體故障自愈
3.1 自愈流程
針對每臺機器的硬體問題，我們會開一個自動輪轉工單來跟進，當前存在兩套自愈流程：【帶應用維修流程】和【無應用維修流程】，前者針對的是可熱拔插的硬碟故障，後者是針對餘下所有的整機維修硬體故障。
在我們的自動化流程中，有幾個比較巧妙的設計：
a. 無盤診斷
-
對於宕機的機器而言，無法進無盤(ramos)才開【無故宕機】維修工單，這樣能夠大量地減少誤報，減少服務檯同學負擔。
-
無盤中的壓測可以完全消除當前版本的kernel或軟體的影響，真實地判斷出硬體是否存在效能問題。
b. 影響面判斷/影響升級
-
對於帶應用的維修，我們也會進行程序是否D住的判斷。如果存在程序D住時間超過10分鐘，我們認為這個硬碟故障的影響面已擴大到了整機，需要進行重啟消除影響。
-
在重啟的時候如果出現了無法啟動的情況，也無需進行人工干預，直接進行影響升級，【帶應用維修流程】直接升級成【無應用維修流程】。
c. 未知問題自動化兜底
-
在執行過程中，會出現一些機器宕機後可以進無盤，但壓測也無法發現任何硬體問題，這個時候就只能讓機器再進行一次裝機，有小部分的機器確實在裝機過程中，發現了硬體問題繼而被修復了。
d. 宕機分析
-
整個流程巧妙的設計，使得我們在處理硬體故障的時候，同時具備了宕機分析的能力。
-
不過整機流程還以解決問題為主導向，宕機分析只是副產品。
-
同時，我們也自動引入了集團的宕機診斷結果進行分析，達到了1+1>2的效果。
3.2.流程統計分析
如果是同樣的硬體問題反覆觸發自愈，那麼在流程工單的統計，能夠發現問題。例如聯想RD640的虛擬串列埠問題，在還未定位出根因前，我們就通過統計發現了： 同個機型的機器存在反覆宕機自愈的情況，即使機器重灌之後，問題也還是會出現。 接下來我們就隔離了這批機器，保障叢集穩定的同時，為調查爭取時間。
3.3.業務關聯誤區
事實上，有了上面這套完整的自愈體系之後，某些業務上/kernel上/軟體上需要處理的問題，也可以進入這個自愈體系，然後走未知問題這個分支。其實硬體自愈解決業務問題，有點飲鴆止渴，容易使越來越多還沒想清楚的問題，嘗試通過這種方式來解決兜底。
當前我們逐步地移除對於非硬體問題的處理，迴歸面向硬體自愈的場景（面向軟體的通用自愈也有系統在承載，這類場景與業務的耦合性較大，無法面向集團通用化），這樣也更利於軟硬體問題分類和未知問題發現。
4.架構演進
4.1.雲化
最初版本的自愈架構是在每個叢集的控制機上實現，因為一開始時候運維同學也是在控制機上處理各種問題。但隨著自動化地不斷深入，發現這樣的架構嚴重阻礙了資料的開放。於是我們採用中心化架構進行了一次重構，但中心化架構又會遇到海量資料的處理問題，單純幾個服務端根本處理不過來。
因此我們對系統進一步進行分散式服務化的重構，以支撐海量業務場景，將架構中的各個模組進行拆解， 引入了 阿里雲日誌服務(sls)/阿里雲流計算(blink)/阿里雲分析資料庫(ads) 三大神器， 將各個採集分析任務由雲產品分擔，服務端只留最核心的硬體故障分析和決策功能。
下面是DAM1與DAM3的架構對比
4.2.資料化
隨著自愈體系的不斷深入，各階段的資料也有了穩定的產出，針對這些資料的更高維分析，能讓我們發現更多有價值且明確的資訊。同時，我們也將高維的分析結果進行降維，採用健康分給每臺機器打標。通過健康分，運維的同學可以快速知曉單臺機器、某個機櫃、某個叢集的硬體情況。
4.3.服務化
基於對全鏈路資料的掌控，我們將整個故障自愈體系，作為一個硬體全生命週期標準化服務，提供給不同的產品線。基於對決策的充分抽象，自愈體系提供各類感知閾值，支援不同產品線的定製，形成適合個性化的全生命週期服務。
5.故障自愈閉環體系
在AIOps的感知、決策、執行閉環體系中，軟體/硬體的故障自愈是最常見的應用場景，行業中大家也都選擇故障自愈作為首個AIOps落地點。在我們看來，提供一套通用的故障自愈閉環體系是實現AIOps、乃至NoOps（無人值守運維）的基石，應對海量系統運維，智慧自愈閉環體系尤為重要。
5.1.必要性
在一個複雜的分散式系統中，各種架構間不可避免地會出現執行上的衝突，而這些衝突的本質就在於資訊不對稱。而資訊不對稱的原因是，每種分散式軟體架構在設計都是內斂閉環的。現在，通過各種機制各種運維工具，可以抹平這些衝突，然而這種方式就像是在打補丁，伴隨著架構的不斷升級，補丁似乎一直都打不完，而且越打越多。因此，我們有必要將這個行為抽象成自愈這樣一個行為，在架構層面顯式地宣告這個行為，讓各軟體參與到自愈的整個流程中，將原本的衝突通過這種方式轉化為協同。
當前我們圍繞運維場景中最大的衝突點：硬體與軟體衝突，進行架構和產品設計，通過自愈的方式提升複雜的分散式系統的整體魯棒性。
5.2.普適性
透過大量機器的硬體自愈輪轉，我們發現：
-
被納入自愈體系的運維工具的副作用逐漸降低（由於大量地使用運維工具，運維工具中的操作逐漸趨於精細化）。
-
被納入自愈體系的人工運維行為也逐漸變成了自動化。
-
每種運維動作都有了穩定的SLA承諾時間，不再是隨時可能執行報錯的運維指令碼。
因此，自愈實際上是在複雜的分散式系統上，將運維自動化進行充分抽象後，再構築一層閉環的架構，使得架構生態形成更大的協調統一。
我們建立了 阿里智慧運維交流群 ，為運維同行及 AIOPS 探索的技術人員提供開放的交流平臺。在群裡，我們歡迎就基礎設施運維、應用運維、平臺運維等最新的解決方案、技術實踐案例做探討學習。
釘釘搜尋群號： 23352075 ，或者用釘釘掃描下方二維碼，即可加入。期待與你共同交流、探討。
你可能還喜歡
點選下方圖片即可閱讀
ofollow,noindex"> 雙11背後的全球數字經濟“作業系統”
關注 「阿里技術」