隨著阿里大數(shù)據(jù)產(chǎn)品業(yè)務(wù)的增長(zhǎng)，服務(wù)器數(shù)量不斷增多，IT運(yùn)維壓力也成比例增大。各種軟、硬件故障而造成的業(yè)務(wù)中斷，成為穩(wěn)定性影響的重要因素之一。本文詳細(xì)解讀阿里如何實(shí)現(xiàn)硬件故障預(yù)測(cè)、服務(wù)器自動(dòng)下線、服務(wù)自愈以及集群的自平衡重建，真正在影響業(yè)務(wù)之前實(shí)現(xiàn)硬件故障自動(dòng)閉環(huán)策略，對(duì)于常見(jiàn)的硬件故障無(wú)需人工干預(yù)即可自動(dòng)閉環(huán)解決。

1.背景

1.1.面臨挑戰(zhàn)

對(duì)于承載阿里巴巴集團(tuán)95%數(shù)據(jù)存儲(chǔ)及計(jì)算的離線計(jì)算平臺(tái)MaxCompute，隨著業(yè)務(wù)增長(zhǎng)，服務(wù)器規(guī)模已達(dá)到數(shù)十萬(wàn)臺(tái)，而離線作業(yè)的特性導(dǎo)致硬件故障不容易在軟件層面被發(fā)現(xiàn)，同時(shí)集團(tuán)統(tǒng)一的硬件報(bào)障閾值常常會(huì)遺漏一些對(duì)應(yīng)用有影響的硬件故障，對(duì)于每一起漏報(bào)，都對(duì)集群的穩(wěn)定性構(gòu)成極大的挑戰(zhàn)。

針對(duì)挑戰(zhàn)，我們面對(duì)兩個(gè)問(wèn)題：硬件故障的及時(shí)發(fā)現(xiàn)與故障機(jī)的業(yè)務(wù)遷移。下面我們會(huì)圍繞這兩個(gè)問(wèn)題進(jìn)行分析，并詳細(xì)介紹落地的自動(dòng)化硬件自愈平臺(tái)——DAM。在介紹之前我們先了解下飛天操作系統(tǒng)的應(yīng)用管理體系——天基（Tianji）。

1.2.天基應(yīng)用管理

MaxCompute是構(gòu)建在阿里數(shù)據(jù)中心操作系統(tǒng)——飛天（Apsara）之上，飛天的所有應(yīng)用均由天基管理。天基是一套自動(dòng)化數(shù)據(jù)中心管理系統(tǒng)，管理數(shù)據(jù)中心中的硬件生命周期與各類靜態(tài)資源（程序、配置、操作系統(tǒng)鏡像、數(shù)據(jù)等）。而我們的硬件自愈體系正是與天基緊密結(jié)合，利用天基的Healing機(jī)制構(gòu)建面向復(fù)雜業(yè)務(wù)的硬件故障發(fā)現(xiàn)、自愈維修閉環(huán)體系。

透過(guò)天基，我們可以將各種物理機(jī)的指令（重啟、重裝、維修）下發(fā)，天基會(huì)將其翻譯給這臺(tái)物理機(jī)上每個(gè)應(yīng)用，由應(yīng)用根據(jù)自身業(yè)務(wù)特性及自愈場(chǎng)景決策如何響應(yīng)指令。

2.硬件故障發(fā)現(xiàn)

2.1.如何發(fā)現(xiàn)

我們所關(guān)注的硬件問(wèn)題主要包含：硬盤、內(nèi)存、CPU、網(wǎng)卡電源等，下面列舉對(duì)于常見(jiàn)硬件問(wèn)題發(fā)現(xiàn)的一些手段和主要工具：

在所有硬件故障中，硬盤故障占比50%以上，下面分析一下最常見(jiàn)的一類故障：硬盤媒介故障。通常這個(gè)問(wèn)題表象就是文件讀寫失敗/卡住/慢。但讀寫問(wèn)題卻不一定是媒介故障產(chǎn)生，所以我們有必要說(shuō)明一下媒介故障的在各層的表象。

a. 系統(tǒng)日志報(bào)錯(cuò)是指在/var/log/messages中能夠找到類似下面這樣的報(bào)錯(cuò)

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指標(biāo)變化是指rs/ws/await/svctm/util等這些指標(biāo)的變化或突變，由于報(bào)錯(cuò)期間會(huì)引起讀寫的停頓，所以通常會(huì)體現(xiàn)在iostat上，繼而被采集到tsar中。

?●??在tsar io指標(biāo)中，存在這樣一條規(guī)則讓我們區(qū)分硬盤工作是否正常 qps=ws+rs<100 & util>90，假如沒(méi)有大規(guī)模的kernel問(wèn)題，這種情況一般都是硬盤故障引起的。

c. 系統(tǒng)指標(biāo)變化通常也由于io變化引起，比如D住引起load升高等。

d. smart值跳變具體是指197(Current_Pending_Sector)/5(Reallocated_Sector_Ct)的跳變。這兩個(gè)值和讀寫異常的關(guān)系是：

?●??媒介讀寫異常后，在smart上能觀察到197(pending) +1，表明有一個(gè)扇區(qū)待確認(rèn)。
?●??隨后在硬盤空閑的時(shí)候，他會(huì)對(duì)這個(gè)197(pending)中攢的各種待確認(rèn)扇區(qū)做確認(rèn)，如果讀寫通過(guò)了，則197(pending) -1，如果讀寫不通過(guò)則 197(pending)-1 且 5(reallocate)+1。

總結(jié)下來(lái)，在整條報(bào)錯(cuò)鏈路中，只觀察一個(gè)階段是不夠的，需要多個(gè)階段綜合分析來(lái)證明硬件問(wèn)題。由于我們可以嚴(yán)格證明媒介故障，我們也可以反向推導(dǎo)，當(dāng)存在未知問(wèn)題的時(shí)候能迅速地區(qū)分出是軟件還是硬件問(wèn)題。

上述的工具是結(jié)合運(yùn)維經(jīng)驗(yàn)和故障場(chǎng)景沉淀出來(lái)，同時(shí)我們也深知單純的一個(gè)發(fā)現(xiàn)源是遠(yuǎn)遠(yuǎn)不夠的，因此我們也引入了其他的硬件故障發(fā)現(xiàn)源，將多種檢查手段結(jié)合到一起來(lái)最終確診硬件故障。

2.2.如何收斂

上一章節(jié)提到的很多工具和路徑用來(lái)發(fā)現(xiàn)硬件故障，但并不是每次發(fā)現(xiàn)都一定報(bào)故障，我們進(jìn)行硬件問(wèn)題收斂的時(shí)候，保持了下面幾個(gè)原則：

?●??指標(biāo)盡可能與應(yīng)用/業(yè)務(wù)無(wú)關(guān)：有些應(yīng)用指標(biāo)和硬件故障相關(guān)性大，但只上監(jiān)控，不作為硬件問(wèn)題的發(fā)現(xiàn)來(lái)源。 舉一個(gè)例子，當(dāng)io util大于90%的時(shí)候硬盤特別繁忙，但不代表硬盤就存在問(wèn)題，可能只是存在讀寫熱點(diǎn)。我們只認(rèn)為io util>90且iops<30 超過(guò)10分鐘的硬盤可能存在硬件問(wèn)題。
?●??采集敏感，收斂謹(jǐn)慎：對(duì)于可能的硬件故障特征都進(jìn)行采集，但最終自動(dòng)收斂分析的時(shí)候，大多數(shù)采集項(xiàng)只做參考，不作為報(bào)修依據(jù)。 還是上一個(gè)硬盤io util的例子，如果單純出現(xiàn)io util>90且iops<30的情況，我們不會(huì)自動(dòng)報(bào)修硬盤，因?yàn)閗ernel問(wèn)題也可能會(huì)出現(xiàn)這個(gè)情況。只有當(dāng) smartctl超時(shí)/故障扇區(qū) 等明確故障項(xiàng)出現(xiàn)后，兩者關(guān)聯(lián)才確診硬盤故障，否則只是隔離觀察，不報(bào)修。

2.3.覆蓋率

以某生產(chǎn)集群，在20xx年x月的IDC工單為例，硬件故障及工單統(tǒng)計(jì)如下：

去除帶外故障的問(wèn)題，我們的硬件故障發(fā)現(xiàn)占比為97.6%。

3.硬件故障自愈

3.1 自愈流程

針對(duì)每臺(tái)機(jī)器的硬件問(wèn)題，我們會(huì)開(kāi)一個(gè)自動(dòng)輪轉(zhuǎn)工單來(lái)跟進(jìn)，當(dāng)前存在兩套自愈流程：【帶應(yīng)用維修流程】和【無(wú)應(yīng)用維修流程】，前者針對(duì)的是可熱拔插的硬盤故障，后者是針對(duì)余下所有的整機(jī)維修硬件故障。

在我們的自動(dòng)化流程中，有幾個(gè)比較巧妙的設(shè)計(jì)：

a. 無(wú)盤診斷

?●??對(duì)于宕機(jī)的機(jī)器而言，無(wú)法進(jìn)無(wú)盤(ramos)才開(kāi)【無(wú)故宕機(jī)】維修工單，這樣能夠大量地減少誤報(bào)，減少服務(wù)臺(tái)同學(xué)負(fù)擔(dān)。
?●??無(wú)盤中的壓測(cè)可以完全消除當(dāng)前版本的kernel或軟件的影響，真實(shí)地判斷出硬件是否存在性能問(wèn)題。

b. 影響面判斷/影響升級(jí)

?●??對(duì)于帶應(yīng)用的維修，我們也會(huì)進(jìn)行進(jìn)程是否D住的判斷。如果存在進(jìn)程D住時(shí)間超過(guò)10分鐘，我們認(rèn)為這個(gè)硬盤故障的影響面已擴(kuò)大到了整機(jī)，需要進(jìn)行重啟消除影響。
?●??在重啟的時(shí)候如果出現(xiàn)了無(wú)法啟動(dòng)的情況，也無(wú)需進(jìn)行人工干預(yù)，直接進(jìn)行影響升級(jí)，【帶應(yīng)用維修流程】直接升級(jí)成【無(wú)應(yīng)用維修流程】。

c. 未知問(wèn)題自動(dòng)化兜底

?●??在運(yùn)行過(guò)程中，會(huì)出現(xiàn)一些機(jī)器宕機(jī)后可以進(jìn)無(wú)盤，但壓測(cè)也無(wú)法發(fā)現(xiàn)任何硬件問(wèn)題，這個(gè)時(shí)候就只能讓機(jī)器再進(jìn)行一次裝機(jī)，有小部分的機(jī)器確實(shí)在裝機(jī)過(guò)程中，發(fā)現(xiàn)了硬件問(wèn)題繼而被修復(fù)了。

d. 宕機(jī)分析

?●??整個(gè)流程巧妙的設(shè)計(jì)，使得我們?cè)谔幚碛布收系臅r(shí)候，同時(shí)具備了宕機(jī)分析的能力。
?●??不過(guò)整機(jī)流程還以解決問(wèn)題為主導(dǎo)向，宕機(jī)分析只是副產(chǎn)品。
?●??同時(shí)，我們也自動(dòng)引入了集團(tuán)的宕機(jī)診斷結(jié)果進(jìn)行分析，達(dá)到了1+1>2的效果。

3.2.流程統(tǒng)計(jì)分析

如果是同樣的硬件問(wèn)題反復(fù)觸發(fā)自愈，那么在流程工單的統(tǒng)計(jì)，能夠發(fā)現(xiàn)問(wèn)題。例如聯(lián)想RD640的虛擬串口問(wèn)題，在還未定位出根因前，我們就通過(guò)統(tǒng)計(jì)發(fā)現(xiàn)了：同個(gè)機(jī)型的機(jī)器存在反復(fù)宕機(jī)自愈的情況，即使機(jī)器重裝之后，問(wèn)題也還是會(huì)出現(xiàn)。接下來(lái)我們就隔離了這批機(jī)器，保障集群穩(wěn)定的同時(shí)，為調(diào)查爭(zhēng)取時(shí)間。

3.3.業(yè)務(wù)關(guān)聯(lián)誤區(qū)

事實(shí)上，有了上面這套完整的自愈體系之后，某些業(yè)務(wù)上/kernel上/軟件上需要處理的問(wèn)題，也可以進(jìn)入這個(gè)自愈體系，然后走未知問(wèn)題這個(gè)分支。其實(shí)硬件自愈解決業(yè)務(wù)問(wèn)題，有點(diǎn)飲鴆止渴，容易使越來(lái)越多還沒(méi)想清楚的問(wèn)題，嘗試通過(guò)這種方式來(lái)解決兜底。

當(dāng)前我們逐步地移除對(duì)于非硬件問(wèn)題的處理，回歸面向硬件自愈的場(chǎng)景（面向軟件的通用自愈也有系統(tǒng)在承載，這類場(chǎng)景與業(yè)務(wù)的耦合性較大，無(wú)法面向集團(tuán)通用化），這樣也更利于軟硬件問(wèn)題分類和未知問(wèn)題發(fā)現(xiàn)。

4.架構(gòu)演進(jìn)

4.1.云化

最初版本的自愈架構(gòu)是在每個(gè)集群的控制機(jī)上實(shí)現(xiàn)，因?yàn)橐婚_(kāi)始時(shí)候運(yùn)維同學(xué)也是在控制機(jī)上處理各種問(wèn)題。但隨著自動(dòng)化地不斷深入，發(fā)現(xiàn)這樣的架構(gòu)嚴(yán)重阻礙了數(shù)據(jù)的開(kāi)放。于是我們采用中心化架構(gòu)進(jìn)行了一次重構(gòu)，但中心化架構(gòu)又會(huì)遇到海量數(shù)據(jù)的處理問(wèn)題，單純幾個(gè)服務(wù)端根本處理不過(guò)來(lái)。

因此我們對(duì)系統(tǒng)進(jìn)一步進(jìn)行分布式服務(wù)化的重構(gòu)，以支撐海量業(yè)務(wù)場(chǎng)景，將架構(gòu)中的各個(gè)模塊進(jìn)行拆解，引入了 阿里云日志服務(wù)(sls)/阿里云流計(jì)算(blink)/阿里云分析數(shù)據(jù)庫(kù)(ads) 三大神器，將各個(gè)采集分析任務(wù)由云產(chǎn)品分擔(dān)，服務(wù)端只留最核心的硬件故障分析和決策功能。

下面是DAM1與DAM3的架構(gòu)對(duì)比

4.2.數(shù)據(jù)化

隨著自愈體系的不斷深入，各階段的數(shù)據(jù)也有了穩(wěn)定的產(chǎn)出，針對(duì)這些數(shù)據(jù)的更高維分析，能讓我們發(fā)現(xiàn)更多有價(jià)值且明確的信息。同時(shí)，我們也將高維的分析結(jié)果進(jìn)行降維，采用健康分給每臺(tái)機(jī)器打標(biāo)。通過(guò)健康分，運(yùn)維的同學(xué)可以快速知曉單臺(tái)機(jī)器、某個(gè)機(jī)柜、某個(gè)集群的硬件情況。

4.3.服務(wù)化

基于對(duì)全鏈路數(shù)據(jù)的掌控，我們將整個(gè)故障自愈體系，作為一個(gè)硬件全生命周期標(biāo)準(zhǔn)化服務(wù)，提供給不同的產(chǎn)品線?；趯?duì)決策的充分抽象，自愈體系提供各類感知閾值，支持不同產(chǎn)品線的定制，形成適合個(gè)性化的全生命周期服務(wù)。

5.故障自愈閉環(huán)體系

在AIOps的感知、決策、執(zhí)行閉環(huán)體系中，軟件/硬件的故障自愈是最常見(jiàn)的應(yīng)用場(chǎng)景，行業(yè)中大家也都選擇故障自愈作為首個(gè)AIOps落地點(diǎn)。在我們看來(lái)，提供一套通用的故障自愈閉環(huán)體系是實(shí)現(xiàn)AIOps、乃至NoOps（無(wú)人值守運(yùn)維）的基石，應(yīng)對(duì)海量系統(tǒng)運(yùn)維，智能自愈閉環(huán)體系尤為重要。

5.1.必要性

在一個(gè)復(fù)雜的分布式系統(tǒng)中，各種架構(gòu)間不可避免地會(huì)出現(xiàn)運(yùn)行上的沖突，而這些沖突的本質(zhì)就在于信息不對(duì)稱。而信息不對(duì)稱的原因是，每種分布式軟件架構(gòu)在設(shè)計(jì)都是內(nèi)斂閉環(huán)的?，F(xiàn)在，通過(guò)各種機(jī)制各種運(yùn)維工具，可以抹平這些沖突，然而這種方式就像是在打補(bǔ)丁，伴隨著架構(gòu)的不斷升級(jí)，補(bǔ)丁似乎一直都打不完，而且越打越多。因此，我們有必要將這個(gè)行為抽象成自愈這樣一個(gè)行為，在架構(gòu)層面顯式地聲明這個(gè)行為，讓各軟件參與到自愈的整個(gè)流程中，將原本的沖突通過(guò)這種方式轉(zhuǎn)化為協(xié)同。

當(dāng)前我們圍繞運(yùn)維場(chǎng)景中最大的沖突點(diǎn)：硬件與軟件沖突，進(jìn)行架構(gòu)和產(chǎn)品設(shè)計(jì)，通過(guò)自愈的方式提升復(fù)雜的分布式系統(tǒng)的整體魯棒性。

5.2.普適性

透過(guò)大量機(jī)器的硬件自愈輪轉(zhuǎn)，我們發(fā)現(xiàn)：

?●??被納入自愈體系的運(yùn)維工具的副作用逐漸降低（由于大量地使用運(yùn)維工具，運(yùn)維工具中的操作逐漸趨于精細(xì)化）。
?●??被納入自愈體系的人工運(yùn)維行為也逐漸變成了自動(dòng)化。
?●??每種運(yùn)維動(dòng)作都有了穩(wěn)定的SLA承諾時(shí)間，不再是隨時(shí)可能運(yùn)行報(bào)錯(cuò)的運(yùn)維腳本。

因此，自愈實(shí)際上是在復(fù)雜的分布式系統(tǒng)上，將運(yùn)維自動(dòng)化進(jìn)行充分抽象后，再構(gòu)筑一層閉環(huán)的架構(gòu)，使得架構(gòu)生態(tài)形成更大的協(xié)調(diào)統(tǒng)一。