面對琳琅滿目的服務器硬件品牌和五花八門的硬件型號規格，如何選擇高性價比的硬件配置，是系統運維的一項重要工作。系統工程師需要根據產品線的不同需求，測試服務器的各項性能以及功耗，同時結合成本確定出性價比最高的服務器配置。因此，硬件測試便成為了服務器硬件選型的必要依據。
此外，處理器、內存、磁盤、SSD、磁盤陣列、網卡等配件的不同型號或規格，搭配起來存在無數種配置方案。面對產品線提出的各種配置需求，是否存在一種方法既能夠滿足業務需求，同時又能讓系統工程師輕松、高效地預算和管理服務器？在服務器規模達到千台的時候，我們開始了服務器配置套餐化的工作。
隨后為了能夠持續地優化成本，我們又開始了多品牌服務器、配件選型、硬件性能和功耗優化的工作。隨着服務器數量開始呈現出指數級增長，硬件故障處理的工作量也變得十分龐大。為了能夠實現自動化檢測和管理硬件故障，我們又開始了服務器硬件領域新的探索和實踐。
服務器硬件測試
引入硬件性能評測，提供選型依據
如何將不同硬件之間的差別更加具體化描述呢？比如，如何描述兩款不同型號處理器之間的性能差異呢？可視化的性能數據是最直觀的。這里就要引入硬件性能評測機制，通過運行權威的性能評測軟件將不同硬件之間的差異數據化，為選型提供更強的理性依據。比如E5-2630v2處理器性能評測得分是10000分，而E5-2640v2處理器得分是12000分，那么就能得到后者性能是前者1.2倍的數據性結論。
常用的硬件評測軟件有GeekBench、Stream、fio、netperf等。（1）GeekBench主要針對處理器的計算性能進行測試評分，能夠分別評估整數計算和浮點數計算能力。（2）Stream單獨針對內存提供較詳盡的性能測試，比如針對單線程和多線程的內存操作有不同的測試項目。（3）fio是一個靈活性很大的IO評測工具，可以用來評估SAS、SATA磁盤、SATA SSD以及PCIe SSD等各種IO硬件設備的性能。（4）netperf是一個常用的網絡性能評測工具，可以用來模擬各種網絡流量場景，可以評估網卡在不同場景下的包處理和數據吞吐能力。
如圖8-1所示是通過GeekBench和Stream工具對兩款處理器（E5-2620v2和E5-2630v2）做計算和內存性能評估收集到的原始數據。
圖8-1 通過GeekBench、Stream工具獲取到的測試數據
通過測試數據可以發現E5-2620v2的計算能力整體要比E5-2630v2低一些，而且兩者之間的性能差異也可以數據化。
（1）整數計算性能（Integer Score項目）后者比前者高18%，意味着數據處理能力強18%。（2）單線程混合內存操作（Single_Triad項目）后者比前者高8%，意味着單線程下內存處理效率高8%。（3）多線程混合內存操作（Mutil_Triad項目）則高45%，意味着多線程下內存處理效率高45%，后者更適合多任務環境使用。
如圖8-2所示是通過fio工具對不同陣列模式下的SAS磁盤做性能測試后收集到的原始數據。
圖8-2 通過fio工具獲取到的不同陣列模式下SAS磁盤的原始性能數據
通過數據可以更理性對比不同IO設備在隨機讀/寫、順序讀/寫方面的差異，為選型提供理性依據。 同類硬件只考慮一種規格通過硬件性能評測能夠准確地評估出處理器、磁盤、SSD等各種硬件的極限性能，便於我們將服務器按照計算、I/O、存儲為單元進行拆分並單獨評估性價比。在套餐精簡的基礎上，為了能夠形成更強的規模效應，應該從統一配件規格上着手優化。因此，硬件性能便成為了評估性價比的重要指標。
比如，通過評測工具得到候選處理器的性能評分，同時結合處理器的價格來評估性價比。假設處理器A的單價為4000元，性能得分是13000點；處理器B的價格僅為2000元，性能得分是10000點。雖然處理器A的性能是B的1.3倍，但是A的價格比B高一倍。通過性價比計算公式：性價比（點/元）=計算性能（點）/單顆價格（元），得到處理器A的性價比是3.25點/元，處理器B是5點/元，那么處理器B的性價比是處理器A的1.53倍。請參考圖8-3。
圖8-3 處理器A和處理器B性價比評估
在滿足業務性能的前提下，優先選擇處理器B，那么就不必考慮在套餐中同時存在兩種型號規格的處理器了。此外，同種規格的處理器采購量越大，成本的規模效應越明顯，也更容易通過部件進行議價。其他配件也同樣適用這個原則。 追求單機性價比在前面的例子中，雖然處理器的性價比是很重要的一項指標，但偶爾也會有意外的情況發生，比如某些注重單機計算能力的業務應用。這時單純考量單個處理器的性價比就不適用了，應該轉向考量整機的計算性價比。
比如，處理器C售價是6000元，是處理器B的3倍，但是C的計算評分是25000點，是B的2.5倍。C的整機成本是25000元，而B的整機成本為20000元。雖然處理器C在單個處理器的性價比上不如B，但如果從單機成本對比來看，C整機成本為B整機成本的1.25倍，因此處理器C的單機性價比是處理器B的2倍。請參考圖8-4。
圖8-4 處理器C和處理器B性價比評估
因此，選擇處理器C來提高業務的單機計算能力，節省成本。對於其他硬件也同樣適用該原則。
服務器套餐化
在大部分情況下產品線並不知道自己的真實需求：用什么處理器、多大的內存、多少塊磁盤。通常都是憑以往的使用經驗拍腦袋決定的：今天多加幾條內存，明天多加幾塊磁盤。這樣給系統工作帶來了極高的服務器配置管理成本。
例如，某公司每個月都會采購新的服務器，某個月產品線提出了共70個配置需求，服務器供應商總共有4家，那么系統工程師等同於要面對和管理共280個服務器配置。從需求收集到落實采購，這期間和產品線、供應商的溝通、確認將耗費大量的精力，時間幾乎都要耗在預算采購這一件事情上，而且還容易出錯。同時，如此眾多的服務器配置也無法形成相同配置的規模效應，無形之中增加了公司的運營成本。因此，服務器配置套餐化十分有必要。 什么是套餐化現在有兩家菜館：A餐館有100道菜，B餐館有10個套餐。那么，用戶去哪家餐館點餐最快？顯然是B餐館，而B餐館就是現在大家熟知的快餐店。在大部分情況下用戶並不清楚想吃什么，怎么搭配菜品更合理等。而套餐的存在能夠快速將餐品按一定原則分類搭配，給客戶提供了預選的方案，同時還精簡了菜品數量。
服務器配置套餐化也是同樣的道理，按照業務方需求提供預先設置好的配置，能夠讓業務更容易做出選擇，而且套餐數量精簡后更容易形成規模效應，增加采購議價能力。 對服務器套餐進行分類建立服務器配置套餐以后，為了方便管理就需要將套餐進行分類。根據業務需求，我們將服務器配置抽象分類成以下幾類。（1）計算型：We前端、緩存類業務等；這類配置一般處理器主頻規格和內存配置較高，對數據存儲的要求較低。（2）計算IO均衡型：業務中間件、數據庫等；這類配置通常處理器性價比較高，內存和磁盤配置適中。（3）重IO型：數據庫等；這類配置在均衡型的基礎上往往會將磁盤更換成SSD，以滿足高IO負載的需求。（4）存儲型：分布式存儲等；這類配置注重單GB成本，通常會使用廉價高容量的SATA磁盤，對處理器和內存的要求並不高。分類后，同一類套餐可能存在多種配置，接下來就是配置近似套餐的抽象合並過程。 精簡套餐數量，實現規模效應比如，另外一家公司總共擁有4個套餐配置，也面對4家服務器供應商，每次采購只需要管理和維護共16個配置。這樣一來，無論是采購還是資源管理都變得簡單、高效起來。同時，套餐數量越少也就意味着規模效應越明顯，采購議價能力越強。這就是為什么連鎖快餐店總是能把套餐價格做得很低，同時還能保證高效的供應，並且還能擁有較高的利潤的原因，一切都歸功於規模效應。
套餐配置分類以后總是能夠出現配置接近的套餐，盡可能地合並這些配置，將相似的配置抽象成一種套餐，不斷地精簡套餐數量。比如，X和Y套餐僅僅在內存配置上存在差異：X內存128GB，Y內存64GB，而X需求量是Y的10倍，那么就應該考慮將Y套餐合並成X套餐，因為X套餐的采購價格很可能低於Y套餐。
成本的持續優化
服務器套餐化帶來了成本的大量節省，但追求成本的持續優化只能另辟蹊徑。我們在如下幾個方面嘗試了一些探索。 多品牌服務器的引入通過多品牌差異化的競爭增加議價能力，降低成本。當然，引入多品牌服務器后很快出現了各種新問題，比如某些品牌服務器不支持共享口，BIOS配置標准各家有差異，管理口對運維支持情況各異等一系列運維可用性問題。很快，運維可用性測試便成為了多品牌服務器引入后的一項重要的測試指標。
通過可用性測試提前發現各種服務器機型的基礎運維問題，以便后續要求廠商按照用戶的運維習慣進行定制化。入圍的品牌我們會按季度來總結故障率，對故障率不達標又沒有完成可規避方案的品牌后續減少采購量，甚至不采購。 配件選型減少服務器規模前面提到了同類硬件盡可能要考慮一種規格，而且單機性價比才是最重要的，因此配件的測試選型也就顯得格外重要。
同一類配件如SSD，也存在PCIe和SATA兩種規格。假設某業務對存儲設備的IO需求較高，而使用SATA SSD的方案單機最多能夠提供的IOPs能力為20000，現在有一款PCIe SSD能夠提供的單機IOPs能力為60000。
雖然同容量PCIe SSD的成本是SATA SSD的2倍，但從整機價格來看，PCIe SSD卻只有SATA SSD的1.2倍，那么使用PCIe SSD可以有效減少2/3的服務器采購量，而單機成本僅提高了20%。因此，業務方全面使用PCIe SSD來縮小服務器投入規模，在降低成本的同時還減少了運維的開銷。 硬件性能調優以往提升單機性能的方法就是升級硬件，如何在不增加成本的前提下提升硬件的性能呢？通常的做法是軟件層面的優化，比如修改BIOS參數、修改內核、升級固件、修改操作系統參數等做法均能達到預期收益。
比如修改BIOS參數，打開處理器的Turbo（睿頻）功能能夠瞬間提升處理器的運行頻率，提升處理器的性能（如圖8-5所示是E5-2630v2處理器在開啟Turbo前后的性能測試數據，可以看到打開Turbo后整數計算性能得到了15%的提升）。
圖8-5 E5-2630v2處理器在打開Turbo設置前后的性能測試數據對比
再比如操作系統參數調優，舉的一個例子是在SATA SSD加直連卡的硬件環境下使用中斷多核綁定來優化IO性能。業務使用8塊SATA SSD加一塊直連卡的硬件方案，分別將數據保存在8塊SSD中進行讀/寫。
在優化前業務的QPS僅能夠達到27K，SSD的使用率為60%～70%，8塊SSD的IOPs總和達到了80K。通過mpstat命令可以發現直連卡產生的IRQ中斷全部壓在了處理器的第一個核心上（如圖8-6所示），產生了82K個中斷，這和前面提到的IOPs數量吻合。
圖8-6 優化前mpstat情況
這已經達到了單核的處理極限，而SSD的使用率卻還有盈余。因此，考慮對直連卡做多核的中斷綁定來優化I/O性能。通過/proc/interrupt可以發現直連卡中斷號為107～118，因此執行以下命令對中斷做多核綁定（如圖8-7所示），將不同的IRQ分別綁定到不同的處理器核心上。
圖8-7 執行多核中斷綁定
優化后業務QPS達到了39K，SSD的使用率也提升至80%～90%，性能提升達到40%之多。
硬件性能調優是最理想的成本優化方案，它在不產生任何直接成本的前提下就可得到單機性能提升的收益。
機櫃高密度部署的探索
業務對服務器的需求規模從幾百台一下子增長到了幾千台，服務器規模的突增給運維帶來了很大的沖擊。很快，公司原先的機架資源便面臨枯竭。由於原先公司體量不大，在和各數據中心談合作時很難及時獲取到機櫃資源，而業務卻等着要上線服務。這個時候為了能夠緩解機架資源的緊張程度，我們便開始探索機櫃高密度部署，很快高密度服務器便進入了我們的視線中。 降低服務器運行功率
通過BMC（BMC即服務器帶內管理控制卡，它可以獲取服務器狀態和故障信息，以及控制服務器的停機、開機等電源操作）獲取服務器實時運行功率，是另外一種實際且有效地掌握服務器用電情況的方法。結合大數據還能夠分析出同配置服務器的功耗運行規律，為單機櫃實現更高密度的部署提供真實的數據。
此外，還可以結合各種服務器功耗優化方案來實現單機櫃更高密度的服務器部署。服務器功耗優化的方式有很多種，例如：
（1）使用高標號電源（比如白金、黃金電源）提高電源轉換效率，減少電源諧波干擾；（2）使用低功率電源提高電源負載率，減少轉換損耗；（3）使用低功耗硬件設備，比如低電壓內存和低功耗處理器等；（4）優化服務器風扇散熱策略，在保證散熱的同時降低轉速，優化功耗。
硬件狀態掃描和故障預警
服務器達到規模后，故障維護也相應變得困難起來，主要體現在：（1）硬件故障無法提前預見。（2）硬件故障分類判斷不精准。（3）硬件故障無法被及時感知。
人工干預的故障排查不切實際，這些棘手問題都給系統運維工作帶來困擾。比如，某個服務器陣列類型是RAID 5，一塊盤出現故障后，業務仍舊能繼續正常運行。但是由於該故障無法被業務應用或運維人員及時感知，因此沒有及時更換磁盤。隨着時間的推移，繼而出現了第二塊磁盤的故障，最后導致整個陣列丟失了數據。在實際線上生產環境中，這類問題屢見不鮮。 大部分故障都是顯性的在積累了大量服務器硬件故障維護經驗后，我們發現大部分故障都是可預見的。可以通過系統、BMC（帶內管理卡）日志或者硬件本身記錄的日志，以及各種硬件狀態檢測工具進行故障定位。比如陣列卡本身帶有對磁盤設備的管理功能，可以通過專門的工具獲取到當前陣列卡、磁盤的狀態信息（如圖8-8、圖8-9所示），並且陣列卡本身也記錄了各類日志，可以方便地通過日志判斷故障（如圖8-10所示）。
圖8-8 通過MegaCli工具獲取到的陣列卡虛擬盤的狀態信息
圖8-9 通過MegaCli工具獲取到的陣列卡下磁盤或SSD的狀態信息
圖8-10 通過MegaCli工具獲取到的陣列卡終端日志
磁盤的SMART信息也能給診斷磁盤故障帶來幫助（如圖8-11所示）。此外，處理器、內存等故障也可以通過BMC的SEL日志獲取到（如圖8-12所示）。很快，我們就可以將故障按照部件進行分類，不同部件的故障定位使用不同的方法應對，工具和日志相結合，綜合分析。這便給自動化硬件故障監控提供了技術基礎。
圖8-11 通過smartctl工具獲取到的磁盤SMART信息
圖8-12 通過ipmitool工具獲取到BMC的SEL日志信息
統一硬件健康檢查工具為了能夠更加高效地管理監控服務器故障，統一硬件健康監控檢查工具的設想很快便被提出來。前面提到大部分故障都是顯性且可以分類的，因此如果能夠編寫一個對服務器不同硬件分別做狀態檢查的軟件工具，就可以及時了解到服務器當前是否存在異常或者故障。
前面提到過不同服務器硬件的狀態信息可以用不同的方法查看，而統一硬件健康檢查工具可以通過調用相關的硬件檢查工具，按照一定的方法邏輯檢查硬件狀態並分析日志，對服務器硬件整體健康狀態做一一檢查。其結果就是，工具在任何型號服務器上運行后便能輸出當前服務器的健康狀態信息：沒有問題就不輸出任何結果，而存在問題便輸出對應的故障分類和具體的故障信息（如圖8-13所示）。
圖8-13 通過統一硬件健康檢查工具輸出硬件狀態檢查信息
常用的檢查硬件狀態的工具和方法如下。
（1）磁盤類：MegaCli、hpacucli、smartctl等。（2）處理器、內存類：mcelog以及通過ipmitool工具查看SEL日志。（3）電源、風扇類：通過ipmitool工具查看SDR（傳感器）狀態。（4）其他類：通過ipmitool工具查看SEL日志。
再進一步，我們可以將工具與現有的監控系統結合，通過監控代理程序定期運行工具便能准確及時地獲取到服務器的硬件故障信息。甚至還可以對故障的嚴重程度進行分級，以便運維人員在獲取到報警信息后快速判斷故障的嚴重程度。
磁盤健康檢查工具
在所有服務器故障中磁盤故障占了相當大的比例（一般使用SAS磁盤的服務器50%以上均為磁盤故障），因此很有必要對磁盤做自動化健康檢查。磁盤系統作為服務器的IO設備是一個復雜且龐大的體系，它並不像內存那樣只有相對單一的結構和規格，光是磁盤的接口類型就有SAS、SATA兩種，而且還有陣列卡、直連卡等IO中間設備作為磁盤系統的一部分。通常使用陣列卡的服務器較多，下面來講講在陣列卡環境下如何實現磁盤的自動化健康檢查。 磁盤健康檢查工具的實現原理陣列卡作為磁盤系統的一部分，能夠將多塊物理盤通過不同的陣列算法組合成一個大的虛擬盤；同時陣列卡又承擔起管理虛擬盤和物理盤的責任，對於虛擬盤和物理盤出現的錯誤進行檢查和管理。而我們開發的自動化健康檢查工具，正是基於能夠和陣列卡信息交互的工具來了解虛擬盤和物理盤的健康狀況的（如圖8-14所示）。
圖8-14 磁盤健康檢查工具的實現原理圖
市面上的服務器大部分使用的陣列卡是基於LSI公司設計生產的芯片，因此和陣列卡的交互都可以通過MegaCli工具實現。
通過MegaCli工具可以獲取到虛擬盤和物理磁盤的拓撲結構以及一些基礎信息，比如某個陣列卡下有一個虛擬盤VD0由物理盤PD0、PD1、PD2組成，陣列類型是RAID 5，緩存設置為No Read Ahead、Write Back，並且當前狀態為Online等；物理盤PD0、PD1、PD2分別對應的槽位ID為slot0、slot1、slot2，並且磁盤狀態均為Online；以上信息說明虛擬盤VD0和物理盤PD0、PD1、PD2均處於Online狀態，沒有任何故障出現。進一步，我們可以單獨了解PD0的更詳細信息。
比如它的某項錯誤計數器Media Error Count數量已經大於100，表明已經有超過100個的物理壞道出現，但是磁盤仍舊處於Online狀態，這說明磁盤雖然還能正常工作，但是已經處於非健康狀態，這塊盤很可能會在近期出現故障，因此通過MegaCli工具獲取到這些信息提前預見了故障。通過上面的這些判斷邏輯，我們將健康檢查分成兩類：虛擬盤的健康檢查和物理盤的健康檢查。 定義不同級別的故障信息為了能夠區分磁盤故障的緊急程度，我們根據故障緊急程度的不同定義了不同級別的故障信息通知INFO、WARN、ERROR和FATAL。
◎ INFO：information，即信息級別，通知用戶磁盤處於非異常也非完全健康的狀態，緊急程度最低；比如虛擬盤正處於修復狀態中。
◎ WARN：warning，即警告級別，通知用戶磁盤系統存在一些問題，但是並非完全被定義為故障；比如出現Unconfigured Good狀態的磁盤，可能是虛擬盤出現了掉盤的問題。
◎ ERROR：error，即故障級別，通知用戶磁盤系統出現了故障但並不致命，不會出現數據丟失的情況，級別比WARN高，需要用戶盡快介入處理故障以避免故障級別升級；比如一組RAID 5的虛擬盤出現了一塊磁盤故障的情況，雖然虛擬盤仍舊可以提供IO服務，但是無法再忍受更多的磁盤故障，因此需要盡快更換故障盤。
◎ FATAL：fatal error，即致命故障級別，通知用戶磁盤系統出現了致命的故障，已經無法提供IO服務，並且有極大的概率會出現數據丟失的問題；比如一組使用RAID 0的虛擬盤有一塊磁盤出現故障，致使虛擬盤已經無法繼續提供IO服務，並且數據全部丟失。 虛擬盤健康檢查的設計邏輯根據虛擬盤的不同狀態來判斷其健康狀況，虛擬盤分別有Optimal、Offline、Recovery和Degraded四種狀態。
◎ Optimal為最佳狀態，意味着虛擬盤目前處於健康狀態，沒有任何故障和異常。
◎ Offline為離線狀態，意味着虛擬盤已經出現了嚴重的故障，比如RAID 0出現一塊磁盤故障，或者RAID 5出現兩塊磁盤故障，表示虛擬盤已經不可用並且數據有丟失。
◎ Recovery為虛擬盤修復中狀態，意味着虛擬盤之前出現了磁盤故障並降級，更換故障盤后陣列卡對新盤進行有效數據填充的過程。
◎ Degraded為虛擬盤降級狀態，意味着帶有陣列保護的虛擬盤出現了磁盤故障，但不至於對虛擬盤的數據完整性造成破壞，比如RAID 5出現一塊磁盤故障就會導致虛擬盤降級。
通過上面的這些狀態我們就可以設計一套判斷虛擬盤是否健康的邏輯，具體的設計邏輯圖如圖8-15所示。如果檢查一個虛擬盤狀態為Optimal，則不輸出任何信息，直接檢查下一個虛擬盤。檢查狀態為Offline，則按照最高級別FATAL輸出錯誤通知；狀態為Degraded，則按照比FATAL低一級別的ERROR輸出錯誤通知；狀態為Recovery，則表示處於非異常也非健康狀態，因此以INFO級別輸出錯誤通知。
圖8-15 虛擬盤健康檢查的設計邏輯圖
物理盤健康檢查的設計邏輯物理盤也有類似的一些狀態來判斷是否健康，如Unconfigured Good、Unconfigured Bad、Online、Offline、Rebuild等。
◎ Unconfigured Good為未被配置為陣列的健康盤，可能是新加的磁盤或者是某個陣列出現了掉盤都會被陣列卡設置為這種狀態。
◎ Unconfigured Bad為被陣列卡判斷為異常狀態的磁盤，可能之前屬於某個陣列，但是由於出現錯誤較多而被陣列卡從陣列配置中踢出，也有可能是新加入的磁盤被陣列卡檢查健康狀態后判斷為故障盤。
◎ Online為在線狀態，但並不意味着磁盤本身不存在問題，它僅僅代表該磁盤尚能提供IO服務。某些出現壞道而引發降速的磁盤，由於尚能提供IO服務，仍會被陣列卡判斷為在線狀態，因此還需要增加其他的因素去判斷一塊磁盤是否真正健康。
◎ Offline為離線狀態，拔盤或者因為接口通信異常而掉線的磁盤都會被陣列卡設置為該狀態，更嚴重的是磁盤故障到已經無法通信的情況也會被設置為離線狀態。
◎ Rebuild為修復中狀態，當一塊新盤被用以替換故障盤而參與整個虛擬盤數據修復時，陣列卡會將該盤設置為修復狀態。
◎ 此外，上面講到即使一塊物理盤處於Online狀態，也無法判斷為健康狀態，因此物理盤比虛擬盤還多了一種可以輔助判斷是否健康的因素，那就是錯誤計數器：MEC（Media Error Count）、OEC（Other Error Count）、PFC（Predictive Failure Count）。
◎ MEC（Media Error Count）為物理壞道計數器，通常指的是磁盤出現無法修復的物理壞道數量，該計數器積累到一定程度后即可判斷為磁盤故障。
◎ OEC（Other Error Count）為其他錯誤計數器，指的是物理壞道以外的錯誤數量。由於磁盤是一種比較精密且復雜的機械和電子部件，因此任何部件的異常磁盤都有一種檢查機制能夠感知並寫入磁盤的SMART信息中，因此該計數器可作為判斷磁盤是否故障的輔助手段。
◎ PFC（Predictive Failure Count）為故障預警計數器，它通常集合了一套判斷磁盤是否即將故障的邏輯，陣列卡根據磁盤提供的各種錯誤代碼和信息判斷磁盤即將故障，該計數器積累到一定程度后即可判斷為磁盤故障。
通過上面的這些狀態和錯誤計數器，我們就可以設計一套判斷物理盤是否健康的邏輯，具體的設計邏輯圖如圖8-16所示。如果檢查一塊磁盤為非Online狀態，就會開始一系列檢查：Unconfigured Good狀態會以WARN級別輸出錯誤通知；Unconfigured Bad或Offline狀態均會以ERROR級別輸出錯誤通知；而Rebuild狀態則會以INFO級別輸出信息通知。
最后，無論該物理盤狀態是否為Online，都會對計數器值進行檢查判斷，如果三個計數器有任何一個超過臨界值，都會以WARN級別輸出錯誤通知，以及時通知用戶磁盤存在異常。
圖8-16 物理盤健康檢查的設計邏輯圖 故障信息的輸出格式關於健康檢查的故障通知的輸出設計邏輯是：檢查到任何異常便輸出通知，沒有異常不輸出任何信息。因此，用戶可以專注於出現故障信息的服務器，而不必被一些過多的狀態信息所干擾。此外，對於信息的輸出格式我們也有精心設計，一條故障信息由故障定級、故障來源和故障原因三部分組成。具體的輸出格式演示如圖8-17所示。
故障定級：前面提到過錯誤信息的定級分類，錯誤輸出信息里也應該有這部分內容，以便用戶在獲取到信息后再次對錯誤信息按照緊急程度進行分類，增強用戶體驗。
故障來源：錯誤信息中應該包含具體哪個虛擬盤、哪塊物理盤的消息，甚至可以告知用戶物理盤的槽位號，幫助用戶精准定位故障來源。
故障原因：有了錯誤信息的具體來源還不夠，還需要告知用戶具體的錯誤原因，比如某塊物理盤處於Offline狀態，某個虛擬盤由於掉盤而出現Degraded狀態，這些具體的錯誤原因都要在錯誤信息中輸出，幫助用戶更好地判斷如何處理故障。
圖8-17 故障信息輸出格式演示