不要讓複雜性影響雲服務推廣

複雜性是雲計算普及路上的一個潛在殺手：為了實現雲服務所承諾的可擴充性以及高可靠性，基於雲的系統架構就會變得越來越複雜。 而服務本身必須設計具有足夠的冗余度並且有自我監控能力，資料必須能夠自動備份到多個不同地點，同時多個伺服器間的工作負載必須平衡。 隨著企業越來越多的關鍵性應用遷移到雲環境，系統錯誤的風險，以及與任何錯誤相關的成本損失，都會相應的增加。

在傳統的IT系統中，使風險最小化的方法就是設置監控和報警系統。 與這些系統不同，隨著雲計算系統的複雜性日益增加，任何人或者團隊都無法對於系統出現的故障做出足夠與及時的反應。 而隨著雲服務之間的交互性越來越強，很難快速鎖定系統錯誤的始發點，而人工介入調查往往會導致更大的風險出現。

如果雇傭大規模的IT團隊來管理雲服務系統，就意味著將企業應用遷移到雲服務所帶來的成本節約效果完全消失。 而降低雲服務系統的複雜性，看上去也並不是一條可行的路線。

而唯一可行的方案，就只能依靠自動化的任務管理工具了。 隨著雲架構、平臺以及軟體的進化，很多專業性的雲服務管理解決方案應運而生，這些方案可以讓企業在雲上的日子過得更舒適。

基於雲的監控和報警

此類工具中最好的產品屬於基於雲的自動化監控工具。 此類工具可以讓任何人監控不同伺服器上的多種資源，並根據所監控的任何參數設定報警觸發機制。 此類產品的代表之作是Amazon的 CloudWatch 和CloudKick (目前已經被Rackspace收購)。 這兩款解決方案都支援對資源的即時監控，並自帶多種報警設置。 這兩款產品同樣都擁有豐富的視覺化介面，並且具有可擴充性。 CloudKick支援所謂的「外掛程式」，即客戶自訂的監控腳本，而CloudWatch則通過API的方式與其它應用程式通信，獲取監控資訊。

這兩款解決方案的不同之處在于它們的監控範圍。 CloudWatch 的監控重點放在Amazon自身的伺服器和服務上，並通過API以及客戶的相應開發，來支援其它伺服器。 而CloudKick則可以支援更多的雲服務供應商，雖然這種支援是通過代理來實現的，但這些代理可以支援多種作業系統。 因此他可以更快更容易的開始監控任何雲伺服器，而不管是哪家的雲服務供應商。

另一種方案是由很多大型雲服務供應商提供的雲伺服器管理服務。 雖然這種方案並不算真正的自動化工具，但是卻可以讓管理雲伺服器的工作變得更簡單。 但不幸的是，這些服務一般都非常昂貴。 而如果考慮到價格差異，為了獲得高可靠性的另一個方案就是選擇多個雲服務供應商，這意味著會有不同的人來管理企業架構的不同部分(基本上也會有不同的服務等級)，這種方案基本上沒有任何吸引力。

從監控到自我修復、直至更高級的功能

一旦應用了上述監控解決方案，原本由管理員手工處理的工作就轉為了自動執行的任務。 很多雲服務供應商都帶有自己的報警系統，可以集成進監控解決方案中，此類功能可以通過電郵，電話或SMS短信的方式將警告資訊發送給管理員。 但是報警僅僅是第一步。

諸如Rackspace 和 Amazon這樣的供應商可以提供API，通過API可以實現一系列自動化任務，實現系統的可靠運轉。 比如，一旦監控系統檢測到CPU或記憶體超載，系統就會自動加大CPU或記憶體的處理能力，同時將報警資訊傳遞給技術支援小組。 在極端情況下，該方案還可以自動將出現問題的伺服器下線，並將該伺服器的IP動態分配給新的伺服器，而這個過程作為使用者是察覺不到的。

監控自動化是把雙刃劍

和很多以技術為基礎的解決方案一樣，監控自動化解決方案也是一把雙刃劍。 在一些失敗的案例中，自動化的資料恢復過程可能會導致災難性的後果。 實際上，Amazon在去年4.21日就出現過這樣的情況。 當時一個配置上的錯誤導致了一個可用性錯誤，繼而觸發了系統的自動化回應機制，最終導致大範圍的系統不可用。 同時，在安裝設置過程中必須確定的一系列元素，也使得人工參與管理變得很不可行。

當然，如果依賴于傳統的監控系統來跟蹤雲應用服務，也不是不可行，只不過傳統的監控系統不是針對監控雲應用而設計的。 而這些產品中的大部分要麼是沒有針對雲環境進行商業化開發，要麼就是缺少某種監控雲服務所必須的功能，或者是許可證費用太高。 自動化併合理的使用API對於監控系統來說十分重要，尤其是在雲環境中。 因此，企業應當儘量使用專業的雲解決方案。

(責任編輯：蒙遺善)