企業需要著眼于如何利用云計算建立模型來滿足對靈活性、創新、質量和效率的更高期望。許多企業已經和不少公有云服務提供商打過交道，并且確信自己也需要為內部用戶提供云服務。籌建新的IT項目，分配預算與選擇供應商。達到涅磐，對不對?錯了。
非常錯誤的決定。2009年我在云發布會上告訴滿屋的與會者，大多數企業的私有云計劃會失敗。一次又一次，我發現大型企業部署的私有云，總會讓亞馬遜和谷歌的工程師們嗤之以鼻。
私有云犯了什么錯誤?
利益相關者們不需要云服務;他們需要的是可以在幾分鐘內完成配置，運行應用程序的容器。他們只希望為自己所使用的資源付費;他們希望因不同年代導致的企業架構、信息安全與ITIL基礎流程，能有所改變而不需要花費數周時間來審批。
私有云并不是AWS.它太受限制，很難使用。它缺乏相應的應用程序編程接口(API)，并沒有管理工具與其集成。這可能會花費公司兩倍于AWS和Google云的成本，甚至可能更多。缺乏完整的服務目錄，而且所有這一切，沒有經過產品負責人的驗證，很可能會被管理者直接否定。
讓我們看看眾所周知的試金石：五分鐘內提供一個完整可用的容器。企業私有云管理與信息安全棧缺乏自動化工具，很難在規定期限內完成作業要求。虛擬機可以在5分鐘內搭建，但可能需要在隨后一周甚至更長時間著手信息安全與管理配置。
你就像被供應商牽到屠宰場中待宰的羔羊一樣，云計算就是屠刀。你既無法將私有云建設成具有15年IT自動化套件，可以完整上線的架構，也無法像大廠商那樣通過融合基礎架構上線，實現部分自動化框架。
如果你仍然決定建立能與亞馬遜匹敵的內部云堆棧，以下是你需要做的五個步驟：
1.花更多的錢--多很多
亞馬遜已經花費數十億美元去打造云服務。如果你想要達到AWS的靈活性與效率，不可能只花費100萬美元投資在半生不熟的供應商產品上。
2.組織變革規劃
如果云實施成功了，許多IT人員的角色會改變或消失。如果整個過程結束了，相同的人還在做同樣的工作，那么你已經失敗了。服務器管理率在很多企業是25或50比1.在大的云服務提供商，預計是1000甚至10000服務器配置1名管理員。涉及到人工操作的只有拉出與更換設備。
確保云方案在執行層面獲得足夠的支持，要消除那些擔心因此而丟掉飯碗或喪失重要性的反對者們的顧慮。
最受影響的地方是通過私有云部署需要手動過程的云堆棧現在自動化了。IT人員意識到這會對他們的工作產生威脅，因此他們對云項目帶來消極影響，所以給他們未來職業發展的清晰前景，激勵他們留下來協助自己展開工作，并提升技術十分重要。
3.實施初期不需要IT運維團隊參與
Forrester的分析師James Staten表示，IT運維團隊主導企業私有云的方案注定失敗的結局。我目睹了許多現實中的案例與教訓。盡管試圖擺脫“例行作業”的思想，大多數IT運維團隊被過于灌輸了ITIL、COBIT以及其他的驅動流程標準，重點關注使云計算對用戶更有價值。
首批云用戶最好是開發團隊;讓他們完成從上至下的架構設計。這意味著強大的開發人員友好服務目錄與API,可以與他們日常開發工具簡單集成等等。他們的開發實踐也需要改變;不再為AWS構建應用程序，而是為自己的虛擬化基礎架構構建程序。
在最終定型與實施時，需要讓IT運維團隊與開發者一起參與。開發人員仍然需要在這一時期負責，避免受供應商驅動的IT運維團隊在工作初期出現問題。
4.不留余地實現自動化
自動化通常是失敗的源頭。人們喜歡各種功能，并且在當前任務還沒完成前就去著手新任務。不要急著躍進：留著一些自動化任務不去解決的話，會導致云功能缺陷。
尋找每個手動過程，無論看似多么簡單或微不足道，盡量讓其自動化，你提升服務器管理比率。雖然永遠都無法達到10000:1這樣頂級云服務提供商的程度，但需要讓工作人員的工作量盡可能的降到最小--僅保留移動硬件與接線。從服務器通電開機后，自動化應該是唯一的動作。
5.測試云計算，并讓測試自動化
云是復雜的系統。自動化可以控制其復雜性，但同樣能導致更大的失敗。測試內部云并不意味著只是增加工作負載;這意味著讓你的員工完成用戶需求配置，并宣布成功。
需要營造一個大規模的全功能系統混亂，看看是否會有事件導致整個云崩潰。Netflix使用Chaos Monkey將AWS中的服務器與系統弄崩潰，測試自己的彈性。可能這種測試云自動化彈性的工具在企業環境下也可以得到很好的使用。
在擁抱類似AWS殺手級私有云之前要慎重考慮以便取得成功。很少有IT部門擁有足夠的資源、預算、技術和政治意志來支撐自己走向成功。但這并不意味著不該將私有云作為IT投資組合的一部分。但它確實提醒了用戶，自己建設與運營私有云，只有雄心壯志是不夠的。
京公網安備 11010502049343號