對于一款服務器產品而言，我們可以從三個角度去評估它——質量、功能和服務。

質量是產品可用的第一要素，這里主要是指硬件的故障率，這個數值應當低于2%，一些廠商的硬件質量甚至可以做到小于1%。不要小看這個數字的變化，對于海量模式的硬件平臺，基數越大差距效果就越明顯。假設服務器總量是三萬臺，多出一個1%就意味著平均每天會多觸發一次故障事件。即便是更換硬盤的維修，也會對生產系統的運行產生一定影響。故障率如果控制不住的話，那么SLA的承諾就是一紙空談。

同時質量也直指另外一個重要指標，那就是性能。在這里，我們把產品性能也納入到質量里面去。為什么這樣講呢？如果一個產品的性能很差，意味著它的可用性就很差，一個不可用的產品，從概念上講基本就等同于質量不合格。一個性能極差的產品基本上就是不可用的，對生產業務的正常運行是非常不利的。

功能是另外一個很重要的影響因素。如果說質量關系到業務的正常運行，那么功能就關系到業務的高效維護。一般所謂的功能主要是指服務器的帶外管理功能。因為在硬件配置方面，除了RAID卡和電源以外，能夠相互一較高下的地方并不太多。但是服務器的帶外管理功能確實可以有效地拉大不同產品之間的距離。

質量和功能是在我們的技術評估中是占有很大比重的，而服務部分會相對偏輕一些。服務好不如質量好，手冊好不如產品好。如果一款產品，質量可靠有保障，使用簡單不求人，那么誰還會需要售后服務和說明書呢？如果產品的質量跟不上去，功能又有缺陷，那么服務再好也是沒有意義的。相反的，如果產品功能強大且質量過關，我們反而很少會使用到售后服務。

在海量模式下的運維場景中，甲方都有自己專門的運維團隊。當觸發任何緊急事件時，第一時間都需要運維團隊自己解決。我們不可能像過去傳統的系統集成那樣，把所有工作交付給廠商來完成。這涉及到一個時間成本的問題。一個線上系統發生故障了，難道你要我打800開Case，再等著廠商派工程師出現場嗎？這顯然是不可能的。業務就算停止一分鐘的損失都難以估計，你根本就等不起。只有像硬件維修或是技術咨詢這類不緊急的問題，我們才會依靠廠商來支持。

另外，服務是一個長期積累的過程。一個廠商的服務好與壞，在短期內是很難做出評判的。對于那些以前根本就沒有使用過的產品，服務這一項也僅能通過測試階段的售前表現來看。這也是不能把服務占比過重的一個客觀因素。

帶外管理有多重要

做系統運維的同學會經常提到帶內管理與帶外管理這兩個名詞。所謂的“內”、“外”之分，就是指管理通訊鏈路和業務生產通訊鏈路之間的關系。如果我們使用業務所在的鏈路進行消息傳遞和管理，我們就稱之為帶內（In Band），反之就是我們所講的帶外（Out of Band）。

我們日常維護生產環境，主要是通過帶內網絡進行管理。所依靠的手段，無非就是RDP、VNC、SSH、TELNET這些方式。但是，這些服務都運行在操作系統上面，并且通過網絡遠程訪問，其中就存在很多不穩定的因素。比如硬件故障，操作系統崩潰，或者是人為操作失誤導致系統無法訪問等等。由此看來，帶內管理這條通道是很脆弱的。我們需要使用另外一個備用的手段，來確保我們對設備和操作系統的控制權。

帶外管理是完全獨立于現有生產環境的，從硬件接口、網絡鏈路，再到存儲和操作系統都是單獨分離出來的。帶外管理系統存放在一個很小的控制芯片上面，里面是一個經過修剪的、只讀的最小系統環境，通過單獨的接口與網絡去訪問。所以它的可靠性比帶內管理網絡要高得多。只要控制芯片加電且帶外的網絡正常，我們就可以始終把控制權牢牢地掌握在手中。

當帶內管理網絡崩潰時，我們依舊可以憑借帶外管理提供的虛擬控制臺，遠程登錄生產系統的本地console界面，這相當于在機房里面直接接上KVM（Keyboard-Video-Mouse）設備。是我們處理故障最有效的保障手段。除了斷后之外，帶外管理也扮演著開路先鋒的角色。在設備剛剛上架加電的時候，我們是沒有帶內環境的，系統的安裝部署，服務器的開關啟停都離不開帶外管理。

也許在一些人看來，帶外管理不過是提供了一個遠程的虛擬控制臺而已。但實際上，它所能完成的任務遠遠不止這些。優秀的帶外管理可以說是提供了所有你在本地操作面前能做的一切功能，甚至還有額外的增值項目。我們可以借此獲取詳盡的硬件清單配置列表，收集監控數據信息，設置BIOS參數，甚至操控硬件。

異構平臺融合能力

從管理角度講，單一使用一家廠商的產品，對于資產的統一管理與配置是有利的。如果出貨量大，雙方相互之間還可以簽署框架協議，進一步推動價格成本控制和產品定制化。這對于平臺初期的快速建設是有一定幫助的。不過，當平臺規模從溪流模式發展到江河模式或者海量模式的時候，一些政策法規不允許只此一家的這種采購形式的存在，同時單一化產品也存在品牌綁架的風險。這個時期，就會突然涌現出許多不同品牌，它們都有可能在未來同時入駐到我們的服務體系當中去。由于來自不同產品之間的差異會帶來多樣化管理的難題，這就對服務器的異構平臺融合能力提出了嚴苛的要求。我們不希望看到，因為產品差異化而增加運維的管理成本。因此，必須弱化這種差異效應，讓運維團隊的成員感受不到不同產品之間的切換與變化。

支持并使用標準的公有開放式協議是異構融合的關鍵。私有協議不管做的多好，對于一統天下是沒有任何幫助的。除非你沒有競爭對手，或者你的私有協議能成為公認的標準。

IPMI協議盡管發展使用了將近20年的時間，可以方便地為用戶提供電源控制、傳感器監控等通用型功能，但是它已經是一個落后于時代的產物了。作為x86平臺的工程師，我們一直都很羨慕小型機上面有專門獲取硬件信息的命令。而IPMI對于這方面需求的發展一直是難有作為。事實上，一些廠商像Dell、聯想在IPMI上也有oem接口，但是IPMI所能作的工作實在是太有限了，我們需要一個新的方案來解決異構平臺上的管理難題。

WS-Management，全稱叫做Web Services-Management，是DMTF組織基于SOAP(Simple Object Access Protocal，簡單對象訪問協議)制定的一種開源標準。該標準致力于在不同的x86設備廠商當中，提供一種IT基礎架構信息訪問與修改的統一接口。這對于那些支持該標準的廠商來說，會給用戶有效地管理資產配置工作提供極大的幫助。例如，我們有很多來自不同廠商的服務器設備。如果它們都能夠很好地支持WS-Management標準的話，那么就可以通過wsmancli工具，統一采集或修改所有服務器的硬件配置信息，而不必因為私有化工具分治的問題而形成多頭管理的局面。像AMD、Dell、Intel、Microsoft這些知名廠商都是該項標準組的成員。

這里我們就目前已經實際應用了WS-Management協議的DELL服務器為例，如果我們需要獲取網卡的MAC地址的話，可以使用如下命令實現。

使用WS-Management，必須先在客戶端上面安裝名為wsmancli軟件包。DELL在這方面走得還是非常靠前的，官網上不但給出了wsman的使用實例，同時還在git上面提供了一整套范例腳本。具體內容請讀者自行參考如下鏈接。

3）范例腳本下載地址和說明：

q?https://github.com/dell/recite

q?http://en.community.dell.com/techcenter/systems-management/w/wiki/3757.recite-interactive-ws-man-scripting-environment

q?http://en.community.dell.com/techcenter/extras/m/white_papers/20066176

q?http://en.community.dell.com/techcenter/extras/m/white_papers/20066181

除了WS-Management以外，類似的標準還有Redfish，最新版本是2.0。它是一個通過RESTful接口利用JSON數據來實現的集成解決方案。Redfish的是一個更加輕量級的協議。比起WS-Management來，它同樣借助了HTTP模式，但傳輸數據更少，協議層更加簡單，Redfish所能夠支持的成員也更多。國內一些廠家已經在推動Redfish項目的進程了。具體的詳細內容可以參考如下鏈接：http://www.dmtf.org/standards/wsman。

另外一點就是兼容性。兼容性的優勢將使產品在未來異構融合的競爭中處于有利的位置。我們可以回顧一下歷史，看一看WinZip為什么會輸給了WinRAR。當年WinZip是壓縮軟件界的老大哥，而WinRAR只是初出茅廬的毛頭小子而已。不過，WinRAR在推廣自己壓縮率更高的rar格式的同時，也兼容了zip格式。而WinZip卻不愿意把rar格式納入到自己的帳下，也許WinZip覺得這樣做實在是丟不起那個人。這兩種策略最終形成了兩種完全不同的結果。盡管后來各式各樣的壓縮軟件如雨后春筍般的出現，但都無法撼動WinRAR霸主的地位。原因就在于WinRAR能夠謹記WinZip失敗的教訓，不斷地兼容后來者的各項功能，穩固了自己的江山。

我們就拿虛擬控制臺舉例，絕大多數服務器的虛擬控制臺依舊是通過Java程序來實現的。而HP提供的C/S模式的工作效率顯然要比Java高很多，并為本地登錄提供了冗余手段。按理說，HP能做到這一步，在眾多廠商里面已經算是很領先的了。但是DELL的思維模式卻顯得更加前衛，它把VNC服務直接嵌入到帶外管理模塊中，在本地登錄的時候使用VNC Viewer就可以了，而不是像HP那樣要安裝一個私有化的客戶端。使用開放標準的VNC協議的優勢就在于沒有開發成本，而且它的通用性和可行性都很強，在未來異構平臺融合的大背景下具有很大的競爭優勢。在寫這本書的時候，我已經在和華為、聯想、浪潮的銷售與技術團隊的技術交流中，建議廠商嘗試在帶外管理中嵌入VNC服務。這也許將在未來形成一種趨勢，我個人希望借助宣講和推動，為業界產品的異構融合邁出堅實的第一步。

完善的信息數據展示

信息展示分為靜態和動態兩個部分，靜態信息是指硬件清單的配置信息，動態信息是指部件狀態的實時監測數據。

硬件清單的配置信息用于資產管理和安裝部署之用，采購的機型不止一種，所以需要通過硬件清單列表的詳細內容對服務器進行辨識，同時也有助于我們檢查供貨設備硬件配置的準確性。硬件配置清單列表中應當盡可能地包括如表1所示的內容信息。

表1 ?Business-IP的對應關系表

Items	Detail
CPU	Vendor, Type, Frequency, Amount
Memory	Vendor, Type, Size, Amount
RAID	Vendor, Type, RAID info
PD	Vendor, Type, Size, SN, Amount
LD	Pool info, Size
NIC	Vendor, Type, Port, MAC, Amount
Power	Power, Amount
OOB	MAC, Firmware
Server	Vendor, Type, SN, Service Tag, BIOS

部件狀態的實時監測數據分為兩種。第一種是硬件的健康狀態，表明它是好的還是壞的。第二種是溫度、電壓、電流、風扇轉速、能耗等傳感器的實時讀數。

軟硬件環境兼容性

軟硬件環境的兼容性的優劣，決定了一款產品應對使用場景的靈活性和適用性。如果適用性太差，就很難去推廣到大規模、多樣化的應用場景里去。

1. 瀏覽器兼容性

基于B/S架構的圖形化管理是帶外管理最早的表現形式。說到B/S架構，我們就不得不提到瀏覽器這個話題。近年來，Chrome和Firefox確實比較流行，但是我希望更多情況下，產品對于IE瀏覽器的兼容性還是要多考慮一些。畢竟IE是Windows原生的，而很多工作我們還是要基于Windows平臺來實現的。

2. JRE兼容性

絕大部分產品都是基于Java開發的，所以JRE是遠程虛擬控制臺和一些私有化管理工具必不可少的運行支持環境。然而不幸的是，因為廠家眾多，產品的生命周期也不盡相同。一些產品只能運行在老版本的JRE上面，而另一些產品則必須使用最新版本的JRE。一個平臺下同時使用多套JRE環境是很麻煩的。一個兼容性差的產品就像一個不合群的人一樣，會受到別人排擠的。我們對待產品也是一樣，少數要服從多數，新來的要入鄉隨俗，只有那些能夠向下兼容的產品才會被留下來。

3. 協議兼容性

比較常用的協議有FTP、LDAP、HTTP、HTTPS、NTP、SMTP、SNMP、SSH、rsyslog等，而且類似SNMP、SSH等還有多個不同版本。對于產品所支持的協議的種類與版本，肯定是越多越好。

4. 硬件及驅動程序兼容性

這個問題主要體現在和部署系統的配合上面。例如因為硬件特殊或是驅動程序的問題，使得部署系統無法識別，從而導致安裝失敗。這種問題嚴格來講，不能全都賴在廠商這邊。但是用戶作為甲方，是有一定話語權的。能夠解決問題是最好不過了，但如果解決不了，或者解決成本太高，有可能用戶會因此令你出局。

用戶體驗

產品生產出來就是給人用的，評價一件產品的優劣往往是很主觀的，這就是我們常說的用戶體驗。對于產品研發來說，良好的用戶體驗是至關重要的。如果你把產品當成一個人，當你和這個人接觸過一段時間之后，他或多或少地都會給你留下一個印象，那么你對這個人的評價就來源于你對他的印象。當然，這個評價可能好的，也可能差的，就是所謂的用戶體驗。一個獲得好評的人，雙方以后相互往來的可能性就會增加，反之人們就會疏遠他。同樣的，如果一個產品的用戶體驗很差勁，那么用戶最終的感受就是——“我再也不想見到你了”。

用戶體驗是在用戶使用產品的過程中建立起來的感受。但是對于一個界定明確的用戶群體來講，其用戶體驗的共性是能夠經由良好的設計來實現的。產品設計的中心原則就是以用戶為中心、以人為本。

1. 響應時間

魯迅先生說過：“生命是以時間為單位的，浪費別人的時間等于謀財害命；浪費自己的時間，等于慢性自殺。”不錯的，我想這世界上沒有比等待更令人煩躁的事情了。如果點擊一個頁面之后，等了半天沒有反應，實在是很令人沮喪。在毫無提示的情況下，等待會讓人不知所措。尤其是在我們急于得到結果的時候，這種慢吞吞的節奏令人感到非常的不合拍。

2. 用戶界面

我們不得不承認這是一個看臉的時代，“顏值”在產品里面也顯得十分重要。

我認為DELL的導航菜單做得最為出色。它的界面完全符合web頁面的瀏覽習慣，隱藏類細節信息都會以加號展開的方式展現。操作方式也十分便捷，只需要點擊兩次鼠標，就完成大多數的操作與信息展示。DELL的所有操作和信息展示都是在同一個頁面下完成的，而不會給你彈出一堆pop窗口，也不會利用超鏈接給你跳轉到另一個頁面去，如圖1所示。

?

圖1 ?DELL服務器的帶外管理界面

H3C也很有特點，從管理界面和菜單結構上，還是可以看到很多HP的影子的。不過相比HP，我認為H3C還是有一些自己的特色在里面的。比如說Overview這個總覽頁面的右下角，匯集了很多常用的功能，點擊對應的快捷方式可以方便的跳轉到相應的功能當中去。如圖2所示。

本來對于超鏈接，我還是不太推薦的。因為很多產品在設計的時候，亂用超鏈接。看上去很方便，實則不停地跳轉頁面，像goto語句一樣把用戶搞得暈頭轉向。而H3C的這個超鏈接設計卻是可行的。它把所有常用功能都放到了一起，相當是一個門戶頁面的結構，還有類似Dash Board的關鍵數據展示。這個設計思路還是很用心的。

?

圖2 ?H3C服務器的帶外管理界面

3. 產品邏輯

產品設計的優先級順序應該是：邏輯性>穩定性>性能>功能。

產品的邏輯性非常重要，一個產品的使用邏輯有問題，往往就帶來極其糟糕的用戶體驗。使用一個邏輯混亂，結構模糊的產品，對用戶就是一種折磨。

在這里，我舉兩個例子。

第一個例子是我們在調試一款產品的功能時發現的。我們要求服務器廠商提供的產品，在系統配置上必須有圖形和命令行兩套接口。圖形主要適用于調試使用，而命令行則有利于我們日常的批量設置。我在配置一個新的參數時，發現在命令行里找不到這個參數，而且文檔里面也沒有提及。之所以我找不到，是因為圖形界面里面菜單的組織形式和命令行中樹形的組織形式不完全一樣。這樣一來，我沒法根據圖形界面的菜單去定位它在命令行樹形結構中的位置。最后我不得不采取了一個笨辦法，把根目錄下的所有屬性都列了出來，再通過過濾關鍵字的方式來搜索答案。

第二個例子是在一次測試過程中遇到的。我個人負責產品測試，另外一個同事負責安裝部署測試。有一款產品，我先對它做了功能評估的測試，然后轉給同事去測試安裝部署。過了一會，同事轉過頭跟我說，這個產品不行，好多硬件信息根本看不到。我笑著告訴他，其實信息是有的，只是它們因為害羞躲起來了。那些硬件信息的細節全部都被隱藏起來了，而且隱藏得太好了，導致我的同事根本沒有發現。因為它們的打開方式并不統一，窗口、標簽和鏈接，可以說是各式各樣。如果不仔細看的話，就會給人造成信息缺失的假象。

關于產品的邏輯問題還有很多，但我想原因只有一個，歸根到底是設計人員從來不用自己設計的產品造成的。

總結

以上是生活随笔為你收集整理的服务器选型：怎样的一款服务器产品才算是优秀的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。