“五個九”的可用性真的有意義嗎？
譯文【51CTO 8月23日外電頭條】51CTO編輯注：現在互聯網服務商提到可用性，一般以“n個九”作為指標，而“5個九”是相對高可用的標準，也是大部分云計算服務商承諾的可用性。但是，隨著業務的構成更加復雜，“5個九”這樣簡單的指標還能滿足用戶的需求嗎？且看本文分解。
如今還有人真的把所謂“五個九”類承諾當回事嗎？從理論層面上來說，這意味著99.999%的可用運行時間比例，也就是說業務經理們每天會遭遇到的故障時段也就八分之一秒多一點。
這聽起來算是相當令人滿意的結果了，不是嗎？一周的故障時段為六秒左右，一年也才大概五分鐘。
紙上談兵沒有價值
回溯八十年代中葉，當時企業希望業務人員能夠熟悉IT部門的交流方式，并認為這種角色轉換具有積極的現實意義。不過放在現在看來，這種要求只能被稱為癡人說夢。業務負責人想要的只是在他們需要時所有設備能夠正常運轉并提供準確的服務，進而幫他們賺到錢。
在當下，系統管理工作又是如何進行的？IT負責人怎樣確定系統正在針對商務客戶的需要提供確切的幫助，而不僅僅是提供一份空泛的統計單？
“五個九現在已經不合時宜了。”Bill Roth說道，他是商業情報公司LogLogic的執行副總裁。
“人們需要計算機時刻保持正常運轉，但用戶描述需求的方式已經發生了改變。”
現在我們所需要的是，手頭的計算資源能夠在任何必要情況下正常運作，這也就是他口中提到的“有效的九”。當然，實際上我們有許多時段并不太需要計算資源，例如工作人員夜間休息的時候。
多層式結構樞紐
這意味著IT部門必須將IT系統視為一個整體，而不是過分側重于其中單個的組件。就IT基礎設施中的多個組件進行事件分析，能夠幫助管理員更好地了解當前的實際運行情況以及給客戶帶來的影響。LogLogic公司所打造的語義解析及識別系統不僅能夠用來闡釋某段特定的錯誤代碼，還會為我們展示其所造成的影響。
Hamish MacArthur說：對于大多數管理員來說，問題在于他們的系統已經是數年前的陳舊產物，而這正是多層式結構的噩夢。他是MacArthur Stroud分析公司的聯合創始人之一。
“我們以某種運行狀態作為最終方案，而人們卻總會在不同時段向其中引入大量不同類型的工具，”他說。“潛在的復雜性正在虛擬化的作用下進一步加劇。”
問題的另一大難點在于，此類工具往往并不是用戶自己購買的。“基礎設施管理工具往往基于一些假設向管理者做出很多許諾，令人以為上了工具就能在無需全程監控的前提下了解到當前的運行狀態，”MacArthur說道。
IT部門并不總是在預算成本中將額外的系統管理工具納入考慮范疇。但企業無疑需要在系統性能方面獲得充分肯定，而IT部門會旋即發現自己必須采用相關的性能及系統管理工具才能達成上述目標。
將此類工具全部整合起來并加以協調可謂超乎想象地困難。不同的系統管理環境可能會在特定的應用程序集合中發揮出不一樣的執行表現，但管理員需要跨業務單位對整從此管理系統進行維護。此外，他們還需要根據運營成本的限制對引入的授權許可數量制訂規劃。
以典型的統一型數據中心來說，例如思科的UCS，能夠徹底解決全部問題的方案非常有限。
解決方案的基本思路是在對一套單一的整合型系統進行管理時，從某個單獨的切入點著手。一切因素都經過預先設置、反饋良好，可以通過管理控制臺對整套系統進行鳥瞰式的監控。
但此類統一型服務器的局限也是明顯的。企業可能會通過使用新的數據機房或引入一套新的應用程序來實現部署角度的改進，但卻很少用它們徹底替代原有的計算基礎設施。
降低棧集成程度
因此，各大機構往往都在其自有計算基礎設施中殘留著雜亂無章的運行環境。甚至來自VMware, EMC的集成棧以及思科的 VBlocks、 NetApp的 FlexPod、以及甲骨文的Exadata都存在著此類問題。
據分析人士透露，這也正是集成棧的銷售情況長期游走于低位的原因。
提升自己對系統的觀察視角，意味著我們在系統管理方面進一步深化以服務為中心的思路；提供給用戶的不僅僅是特定的硬件套裝，更應該是經過嚴格考量的應用程序。這些服務項目應該能夠廣泛覆蓋常見的組件。
IT部門可以將其數據中心分為同步型、異步型以及獨立應用與服務型三種。同步型部分的關鍵性指標是正常運行時間；異步型應用程序能夠一次性脫機數小時仍然正常運作；而獨立型每個月可能只使用兩天左右。
從這個角度劃分系統類型并兼顧客戶的實際需要，將使系統管理工作的必要成本遠遠低于單純追求多少個九的運行統計數據。
原文：http://www.theregister.co.uk/2011/08/19/system_management/
【編輯推薦】
