構建雲工廠的六部曲

IT行業是一個不可被取代，不可能磨滅的一個行業，它的發展之迅速也是超乎人想像的。 不管人類的怎麼努力，似乎都趕不上IT行業變革的步伐。 在變化之迅速的這個行業裡，雲計算在推動IT行業變革上的力量是不能被忽視的。 雖然IT的行業標準對於推動IT行業的變革功不可沒。 最近一些企業正在為引進虛擬化部署「舊系統」，對於資料中心來說比那個是唯一不變的真理。 為了處理這一涉及到整個企業工作量託管模式的重大變革，周密的計畫是我們必須完成的。

為了對雲轉型問題制定合適的框架。 對於解決這一問題需要涉及到許多方面，包括雲的敏捷性、靈活性、透明度以及最終使用者的利益。 其中歸根到底與新的具體基礎設施需求有關;自助服務入口網站的使用承載新的應用程式或者主機瞬態的加工需求。 當成千上百現存的工作量移入雲基礎設施，敏捷性通常是有受益的經歷。 事實上，相反的情況經常出現，因為雲提出了更高標準的需求(例如，限定目錄的尺度和軟體的選擇)，實際上將現存的物理和虛擬伺服器遷移到雲模型是相當困難的。 換言之，在新工作量的擴展方面，換個角度看敏捷性就顯得遜色了。

這就是雲工廠這一概念的來源。 在工業生產過程中，工廠就是檢測生產力的縮影。 儘管採取一些努力準備加工機械，一旦要組建經營公司就要提供有效的輸入和輸出——這是大規模改造的關鍵。 通過採用共同的方法，也就是適當的設計以提供可重複的結果;組織機構能夠投入最少的時間和精力;以此實現遷移到雲計算基礎設施。

在這一概念的指導下，重要的是進一步闡述適當設計。 許多企業能夠從基層解決這類問題，使用試算表和發揮聰明人的才智進而決定行動。 這一方法帶來的問題是它很少涉及到要點——引出真正準確的答案，主要原因是問題過於複雜。 將工作量遷移到雲中與很多方面有關，例如，處理大量的歷史資料、分析伺服器上的配置資訊、遷移應用軟體;建模目標的尺寸比例和軟體堆層、執行企業和監管要求、遵守服務等級協定和資料保護規則等。 使用試算表不是很好，大致相同的方式，企業會計平臺也不宜採用試算表。 即使他們被哄騙著為這一簡單環境給出體面的答案，他們也未必生成報告滿足股東、管理人員、工程師、經營人員等。 所有這些人員需要重要且詳細決定以便確保取得成就和風險最小化。

致力於雲遷移清單的分析得出結論：一個關鍵概念將所有這些連接在一起。 這一概念就是策略，它代表基本規則包括怎樣管理工作量;它們應何去何從;應該分攤多少資源等。 沒有適當的策略;託管決定留給從業者執行遷移;沒有計劃他們是否做了正確的是。 雲基礎設施的規劃和管理沒有正確的策略猶如沒有指示就試著填寫納稅申請——太多的可變因素在得到正確的策略。

對所有這些概念有所瞭解後，雲工廠也就變得清楚了。 它將問題分成一系列的邏輯步驟，這些都與資料有關。 例如，目標模型、計畫和管理政策。 為了完全決定實現自動化的過程將會怎樣發展以及規模如何。 以下是建立工廠的步驟：

1、候選資格：這一過程決定特定的工作量是否適合特定的雲環境。 定性和定量分析後，從工作量中挑選真正的候選資格 以便更好的實施以下步驟。 量化標準的例子包括：最大I/O速率、上下文切換限制、最大的CPU、記憶體大小等。 定性標準包括：資料的敏感性、服務等級協定的需要、備份策略以及其他需要考慮的因素。 制定策略需要抓住所有這些因素才能快速做出準確的評估。

2、工廠規模：確定了候選資格後下一步就是將雲託管到最適合的水準和利用模式。 這又要取決於政策，包括要考慮多少遺留下來的東西和目標利用水準。 實際所需實例大小的具體詳細情況和雲環境中工程利用水準。 明確使用時標準是關鍵的一步，CPU利用從目前環境向雲環境的轉化取決於每個CPU的相對速度。

3、平衡負載：這一步集中遷移負載平衡器和集群。 因為雲環境提供不同的規模可供選擇，也能夠提供更多先進的「彈性」特徵。 這些一對一的伺服器轉化並不總是令人滿意。 以最低的成本才能算得上成功。 這一結果要與一般規模相結合進而提供一個完整的計畫。

4、繪製軟體堆層：這一步要考慮到源伺服器的作業系統和軟體配置並且把它們配置在「最接近」雲的地方。 因為雲目錄中只提供有限的軟體選項設置，這是一個有效的標準化分析。 作為IaaS，這一步通常僅限於OS-級配置、與現有伺服器作業系統屬性相配、作業系統的虛擬機器等在雲上提供的服務。 (通常清單中很少)作為一種服務平臺，這一步也包括實際軟體清單的審議和應用程式的安裝。 結果可能說成是「X伺服器看起來像IIS v6伺服器，但是通過以下方式可以看出與標準圖像的不同」這不僅提供了最佳的堆層部署，而且生成一個修復清單以便減少這對減少實施過程中的風險。 這一點是關鍵。

5、合理佈置：這一切最終確定後，下一步就是內部雲環境的問題。 工作量應該放置在基礎設施中，實際上是控制雲環境。 因為大部分的雲基於虛擬的雲環境，適應新的虛擬機器的關鍵是優化利用伺服器資源。 這一步看起來與在虛擬環境中放置工作量多少有點像(這往往類似與俄羅斯方塊放置在可用的伺服器容量)，但是過量使用的政策在配置上產生的結果影響很大。 如果政策是為每一個雲實例嚴格儲備容量，雲環境會非常安全但相對低效，工作量強度相當低(想一想玩俄羅斯方塊的情形)。 如果政策是過量使用資源，高端客戶可能爭議的風險較高。 如果他們提出雲環境之外不曾預料到的要求，但是密度較高的結果可能大大降低成本(想想將俄羅斯方塊緊緊的放置在一起，需要的容積就少)。

6.異常情況處理：回頭看第一步，通常應用程式的元件或者業務服務在雲中的託管可能會不適合。 在這些情況下，就有必要評估其它的託管以便決定處理方法。 因為就託管選項來說通常有一個優先順序，這一步涉及到被拒絕的工作量系統資格是否違背設定的有序的託管戰略。 這些戰略包括使用定制的雲分配實例、使用專用的雲伺服器、在虛擬環境中的託管、使用專用的刀片伺服器、使用專用的機架式伺服器或者獨自留下工作量(不得已時)。

只有條不紊地實施這些步驟才能快速詳盡地規劃雲遷移過程。 通過以資料為中心並以政策推動的方法，實現了犯錯少，返工少。 應用程式的擁有者和其它股東滿懷信心地達到目的。 這種透明度，結合詳細規格和實施細則，能夠迅速加快雲舉措。 這不僅減少時間而且使IT行業能夠跟上技術創新的步伐。

【編輯推薦】

雲計算「十面圍城」 指點迷津也需有道盤點十大雲計算管理公司十一個開源雲計算資源推薦雲計算還是算計雲 雲手機意欲何為？ 雲計算浪潮 大量IT人員將丟「飯碗」？ 解析物聯網基石雲計算的「前世今生」【責任編輯：鑫瑋 TEL：（010）68476606】