近年來，雲計算市場可以說是井噴式增長。圍繞雲的各種新技術、新公司如雨後春筍，市場上不斷出現各種聲音和討論。每周各種新聞層出不窮，新品發布，公司獲得投資，當然還有大規模系統宕機等新聞出現。

客戶逐漸從被動走向前臺。前幾年客戶說做壹個項目只有雲標題才會時髦。現在更多的客戶已經開始從不同的角度去實踐和嘗試，有業務驅動的，有企業轉型的，有實驗測試的，有大規模推廣的。很多機會和想法的出現是好事，給不同層次的公司提供了展示的機會和發聲的舞臺。這類人徹底改變了過去IOE等大型企業級外企市場形成的穩定平衡。但是有沒有出現壹種新的平衡來打破這種平衡呢？其實並不是因為大家都在不斷的探索和嘗試。我也觀察並支持我個人參與到這壹波當中。我想和妳們分享這壹波雲的浪潮何時到來，或者改變的機會何時到來。什麽樣的潮流和趨勢才是適合客戶的，才能夠真正的和自己的業務融合，重新形成穩定。畢竟傳統企業客戶的IT不是實驗室。他們無法擁有互聯網行業的人力資源和千變萬化的業務前端，也無法擁有運營商運營的龐大基礎設施。對於他們來說，構建雲的核心在於業務整合，可以從創新、交付體驗、成本、穩定性以及對未來轉型的支持等方面提供支持。這個過程不僅是對客戶的體驗，也是對服務商的考驗。就像煉鋼壹樣，需要壹步壹步的工藝和技術，才能成為合格的產品。當然，我自己的崗位和工作範圍讓我更關註客戶私有雲、行業雲的建設和運營，也就是如何幫助客戶細化成壹個好的雲。

您的組織和企業準備好轉向雲計算了嗎？

先說私有雲的建設。幾年前，如果我們和客戶交流雲計算，客戶更關註虛擬化。當時的主要工作是讓客戶接受虛擬化，所以只要我們能虛擬化，所有項目都可以冠名為雲。隨著近年來大規模公有雲的成熟經驗和雲技術的普及，客戶逐漸接受了雲不僅僅是虛擬化，而是壹個面向服務、面向交付的系統，包括終端用戶、業務部門的自助獲取，從網絡連接到服務質量保障的壹體化運維，甚至轉型客戶需要的壹些行業雲從運營到銷售管理的業務模式。這種真正的雲對客戶的投入是巨大的，首先要判斷是需要做真正的私有雲(行業雲)還是直接購買公有雲或者別人的行業雲服務。壹方面考慮定制，另壹方面考慮安全，公有雲服務就像在食堂吃飯壹樣。雖然飯菜種類很多，但不壹定好吃，也不壹定適合自己。壹些企業特性的需求對基礎設施或者中間層有很多要求，妳只能自建雲服務。當然，追求極致數據安全的公司更需要它。另壹個方面是客戶的應用是否需要上雲。從邏輯上看，客戶的應用壹般分為不可雲應用、可雲應用、雲適應用和原生雲應用。判斷這些類別的標準不僅僅是技術上的虛擬化、分布式存儲和融合計算。還包括應用的彈性需求、業務交付需求、變更需求，以及外圍API和其他應用的交互需求。對於搭建私有雲的客戶來說，彈性資源池，也就是底層平臺，是不能隨意部署和加載的，資源池需要經過壹定時間的設計、采購、租賃等才能部署到位。因此，構建私有雲的重要目的是保證自己構建的池的最佳投入產出比，即正在運行的應用和負載能夠合理地充分利用現有的資源池資源，保證壹定的冗余，並且能夠在大量服務離線後適度縮減資源池。從應用的角度來說，不同類型的應用可以通過不同的手段實現，當然成本和技術可能會有很大的不同。原生雲應用壹般是企業目前正在嘗試的新業務產品和方向。如果這類應用在數據和信息安全的範圍內，最適合公有雲或者混合雲。當然，更廣泛的基於雲的應用和支持雲的應用是目前企業的主流。對於這種類型的應用程序，應用程序開發部門和團隊在考慮構建雲時需要介入。單純為虛擬機和存儲服務器提供純IAAS或虛擬化雲平臺並不能改善服務交付模式。因此，從交付模式出發，能否將應用加載留給業務部門選擇，讓他們根據業務轉型選擇啟動或關閉從應用到底層基礎設施的服務？這是給雲系的。這個過程需要申請部門和基建部門的配合，* * *制定出彈性方案，保證炸彈能收回來。這個過程稱為服務編排。

從我們的經驗來看，要順利實現雲化，有兩大任務要做。第壹步叫搭起架子，第二步叫上雲。當然，我們應該從整個生命周期的角度來構建它。只有在“不要忘記妳的首創精神”中，我們才知道無論我們走多遠，做多少嘗試，我們都能到達終點。下圖主要展示了雲平臺建設的流程和需要的服務。

現在來說說擱置。擱置是雲計算的規劃和評估，設計整個雲服務的交付模式，其中包括需要考慮1的路線圖。應用雲化，因為搭建雲平臺，應用改造，遷移，測試，擴展等。不會壹蹴而就，而必須通過壹定的時期來實現。2.標準化資源和工具的需求。如果是所有企業標配，當然可以使用公有雲甚至混合雲。但由於不同應用的開發和時間的積累，不同企業使用的部署架構和中間件數據庫各不相同，需要考慮準備集成版，在搭建雲平臺的過程中逐步統壹，為後期的服務安排提供可能。3.運維流程標準化和SLA。雲是壹個容器，在其中構建各種應用程序，並通過服務交付自動化和自助服務交付給最終業務部門和用戶。交付什麽，交付流程和規範，尤其是SLA，要從壹開始就設計好，因為這將直接影響技術系統的布局和運維管理服務的成本負荷。4.最後是雲環境下持續交付的過程，其中要考慮應用擴展靈活性、業務連續性等壹系列問題。做好這些步驟，構建壹個完善的雲系統至少不會很盲目，缺乏方向。但僅憑這些，這個架子還沒有完全搭建起來，更重要的壹步是服務安排和資源池設計。服務的安排是從應用的角度來看的，是通過壹個自動化的過程，根據需要啟動或關閉應用組合，將基礎設施部分完全融入到應用的自動化運行中。服務編排的設計非常重要，了解應用程序和了解基礎架構甚至後來構建雲管理平臺的人需要壹起工作。這個過程就是對基於項目的應用軟件和底層架構的集成進行標準化和模板化，最終實現所謂的工作流。通過這部分的設計，我們可以知道服務需要編譯哪些自動化的模板，底層架構需要的基礎資源以及相關的技術體系。

資源池的設計，說到這部分，就不得不說說OpenStack了。OpenStack是壹個非常好的工具，可以幫助客戶連接包括計算、存儲、網絡在內的整個基礎設施，不斷動搖IOE和VMware廠商固守的商業產品陣地。客戶完全可以通過OpenStack開啟開源雲計算之旅。但既然是開源的產品和系統，就必須具備開源產品的特性和約束。商業產品缺乏穩定性和成熟度，缺乏清晰的產品演進路線，缺乏配套服務，都是客戶需要面對的問題，尤其是穩定性和運維。從目前的體驗來看，OpenStack更像是壹個樂高玩具，不同的技術人員在客戶處可能會有不同的部署和實現方式，所以軟硬件之間的耦合就變得非常重要。當客戶設計資源池時，什麽樣的硬件配置、網絡、存儲服務器和軟件可能會產生大量不同的排列和組合。由於硬件的壹些耦合性和特性，問題和故障會變得非常頻繁，而客戶又不能做反復實驗的小白鼠，所以參考架構就變得非常重要，即通過實驗和項目，已經總結出哪些品牌的配置機在組合時可以滿足要求。當然，除了機器配置，標準化設計也為客戶在項目實施中提供了指導，大大減少了實施時間。客戶只需要通過POC驗證功能的合理性。

有了系統和架子，基本上就算妳想清楚了怎麽做壹個雲，也有很多方法可以做。可以自己從頭做起，也可以請人購買、管理、托管私有雲。當然，成本和交付時間，以及後期運維的ROI都可以作為評判的標準。當然也有人覺得這很復雜，所以我會找壹個OpenStack的廠商來建壹個池或者用VMware來提供虛擬機，存儲，網絡。我有基本的IaaS，我已經在雲端了。這個當然可以，但是規模有多大，是否只針對業務部門，如何管理和交付，後續項目是否有成長性，這些都是無法回避的。所以要不要做雲，就像前面說的，是商業模式的改變，組織也要做相應的改變，比如增加壹些服務交付專員、布局設計架構師等角色。

雲計算管理平臺的重要性

雲管理平臺其實是壹個非常重要的平臺，不僅在Gartner上有單獨的魔力象限，而且在我們建設的整個生命周期中都可以看到，這其實是整個雲建設的重要立足點。當然，再來說說Gartner的魔力象限。事實上，在目前國內的雲管理平臺中，客戶更喜歡本地化和定制化。這是因為雲管理平臺是客戶管理靈魂的體現。如何與自身管理相結合，大量定制是必然的，所以雲管理平臺的競爭是最激烈的。

可以說，雲管理平臺有著非常悠久的發展歷史。早在幾年前，當客戶發現僅通過VCenter無法實現面向客戶端的自動交付、滿足交付流程需求時，雲管理平臺應運而生。現在的雲管理平臺已經是橫向和縱向的匯聚點，是接入核心。向後兼容和管理基礎設施系統，包括各種資源池，如VMware、KVM、Power等。，KVM系統資源池基本是通過調用OpenStack實現的因為OpenStack，VMware是vCenter，Power是PowerVC。通過與底層管理軟件的交互，雲管理平臺可以看到不同的資源池，同時更重要的是在資源Ikenoe中構建壹個服務層，即將不同的資源組織成服務，通過編排交付給客戶。這是雲管理平臺的向下維度，向上維度是雲管理平臺與PaaS層應用層的整合。目前大多數雲使能應用和雲適配應用使用傳統中間件和數據庫，因此雲管理平臺主要通過服務安排將基於雲的軟件中間件模板和底層虛擬機模板集成，最終直接交付給客戶應用系統，而不僅僅是通過服務交付底層資源。這部分是目前雲管理平臺開發的壹個熱點，尤其是對於企業客戶。當然，現在的應用承接也有Docker模式，所以雲管理平臺可以通過加載Docker服務，為客戶提供原生雲應用的部署環境和能力。要充分實現雲管理平臺的價值，需要橫向協同，即運維監控和混合雲接口。在過去，雲平臺通常是實驗性質的，許多管理流程，尤其是ITIL，並沒有加載到其中。壹方面，我們希望雲管理平臺提供的監控過程是集成的，可以幫助我們了解基礎資源池、虛擬機甚至中間件的性能和狀態，也希望編排好的規則可以自動啟動和關閉，從而徹底實現雲的自動化和靈活性價值。這就要求雲管理和監控系統能夠完全集成或者提供壹些功能。對於混合雲來說，雖然部署方式、數據傳輸、安全仍然是需要面對和考慮的問題，但是雲管理平臺可以管理遠程公有雲自己購買的環境，集成管理已經被很多雲管理平臺逐步實現，下壹步壹定是跨雲部署監控和計費。因此，作為雲最重要的組成部分之壹，雲管理平臺在服務業務的交互和交付中起著非常重要的作用，這不是僅僅通過OpenStack的壹個漢化視界就能實現的。當然也有很多軟件廠商做這部分雲管理平臺，因為不會影響生產底層，所以只存在定制實現能力和易用性的問題。當然，不要小看這種定制性和可用性。其中壹點就是用戶的可用性設計。比如因為OpenStack本身設計的壹個問題就是它的用戶群是虛擬化的管理者，而雲管理平臺是為真實用戶設計的軟件系統。這是OpenStack的兩個設計思路和兩個方向。

運行和維護管理

客戶進入雲世界後，運維管理也發生了翻天覆地的變化。以前客戶的業務系統相對隔離，基本保持HA、穩定主機、網絡、存儲等高可用形式，可以通過API和端口自動發現和監控。目前，雲管理平臺大多采用SDE架構。在這種架構下，硬件相對標準化和簡單化，比如X86服務器，更像家用電器。在操控硬件產品的過程中，軟件變得更加重要。從支持虛擬機核心到存儲再到聯網，都是通過軟件來實現的，必然會讓客戶和操作系統甚至內核參數打交道。在水平方向上，應考慮網絡、存儲和計算的整體健康狀況。比如我們遇到過壹個項目中虛擬機丟失的案例，追溯到長連接會議卡和OPENSTACK中的網卡是Redhat自帶的Intel網卡驅動版本太低的問題，最後升級版本解決了問題。不算這些，還要考慮與硬件的匹配性和兼容性，我們在項目中也遇到過反復停機，最後鎖定硬件微碼的情況。

當然有人會說，我們構建的雲平臺應該是HA高可用的。是的，從雲平臺的架構設計和功能來看，這是非常重要的。我們必須在設計中考慮所有級別的高可用性，從存儲到OPENSTACK再到雲管理平臺。所有級別的高可用性都可以通過監控軟件實現整個平臺的穩定性。而且在實際生產過程中，VM支持在線遷移是非常重要的。例如，壹個資源池支持所有物理機的微碼升級，但已經有許多關鍵生產業務在運行。為了在不影響業務的情況下實現物理機升級，在雲平臺部分，因為支持高可用性，停止壹臺物理機的服務不會影響雲平臺的運行，所以可以叠代升級。在計算節點，因為支持VM在線遷移，所以也可以叠代升級。當然，這些底層運維場景只是壹部分，還有壹部分是業務和中間件的融合。我們也遇到過只有壹臺虛擬機反復丟包的情況，最後調查是應用問題。

所以，雲服務是壹個大容器。這個大容器不能說是高壓鍋，但壓力也不小。應用到今天的雲運維服務中，整個工具鏈體系是不斷進化的。目前我們雲運維團隊常用的工具有開源和商用，其中saltstack、nagios、elk和lpar2rrd都是開源的。還有itm，powershellcli，最後還得自己寫腳本。客戶要想自己運營好雲，壹方面要整合雲管理平臺和這些監控工具，另壹方面也要把時間投入到學習和研究中。相比傳統的壹體化運維，雲運維是1。雲運維不僅關註硬件和物理層，更關註整個系統和應用層。2.雲運維更需要軟件和系統的自動化部署。3.通過生命周期形式管理應用程序，如自動軟件更新。4負載均衡和自動擴容保持私有雲的最佳投入產出比。5.降低運營和維護成本。

所以從目前的項目來看，客戶更關心的是基於VMware的雲平臺的應用層。對於OPENSTACK搭建的雲平臺，客戶應該更多的依賴服務商，或者通過整合自己的工具和資源，逐步實現運維。目前比較時尚的模式是為客戶提供管理雲服務。管理雲服務是管家雲服務，專業的人做專業的事。管家雲服務通過提供專業的管理運維工具或管理服務，幫助客戶維護和運營穩定的OpenStack基礎設施。這種業務完全可以解放客戶，專業團隊有專業的知識庫和人員共享。當然，這種商業模式犧牲的是完全的定制化，因為客戶的硬件系統甚至軟件，尤其是OpenStack，必須由運維廠商來管理，管理服務廠商必須遠程監控運維，才能達到壹定的服務水平和響應。

雲安全

雲計算通過資源池模式集中管理數據，比分布在大量終端上的傳統數據更安全。由於數據的集中，安全審計、安全評估、安全運維更加簡單，更容易實現系統容錯、高可用、冗余和容災。然而，傳統的IT安全威脅仍然存在，因此傳統的安全保護方案仍然可以發揮壹定的作用。

雲平臺的安全可以分為管理和技術兩個層面。首先，在技術上，要按照分層的思想，在安全域劃分的基礎上，從物理基礎設施、虛擬化層、網絡、系統、應用、數據等多個層面進行全面防護；其次，在管理方面，要對雲平臺、雲服務、雲數據全生命周期、安全事件、運維監控、測量評估進行管理。考慮到雲計算帶來的變化和風險，從保證系統整體安全的角度出發，構建安全雲。除了基礎設施安全、虛擬化層安全、虛擬網絡邊界安全、主機安全、應用安全、數據保密和防泄漏，還要註意安全運維管理、法律和合規的要求。

目前我們實施的大部分項目都是讓客戶在傳統網絡和安全防護的層面加入多應用和虛擬化層的安全控制。因為現在廣泛使用開源軟件，尤其是應用軟件，業務上線前必須進行漏洞掃描補丁管理，雲計算中的物理金屬邏輯加入雲平臺後需要同步安裝防護軟件，避免互聯網端裸奔。總的來說，雲計算的安全問題是普遍存在且嚴峻的。最好的辦法是，安全設備可以像存儲設備壹樣形成壹個池化的資源池，當用戶申請雲服務器時，可以和計算資源、存儲資源壹起按需分配給用戶。目前，在公共雲市場上，壹些雲服務提供商已經將安全作為基本屬性交付給用戶。當用戶購買雲計算服務時，用戶獲得了安全的ECS、CDN、RDS和OSS。相信在不久的將來，各種池化的安全資源也會用在私有雲環境中。屆時，安全也將成為構建雲服務的眾多樂高積木之壹，妳可以選擇和掌控。它受限於妳的安全需求和想象力。

摘要

上面說了這麽多，其實是和大家分享做項目這麽多年的壹些想法。構建壹個好的雲就像構建壹個工程作品。妳必須壹開始就設計圖紙。有了圖紙，妳可以選擇自己來，也可以直接購買合適的雲服務。因為市場競爭激烈，又沒有明確的規範，客戶很難選擇。

我個人的建議是分類看，把雲管理和底層分開看。雲管理最終可以通過定制和項目壹步壹步來達到效果，但是壹旦底層選擇再次替換，就會非常費時費力。同時，底層與運維的匹配度也很重要。壹個無法管理，不方便監控管理的底層，無異於壹個徹頭徹尾的黑洞。所以能夠提供好的管理甚至管理工具的底層會變得非常有價值。談完這些，其實就是考察隊伍了。壹個廠商的雲建設團隊其實很難做到全能。因為存在各種不同的條件，如技能水平、客戶站點復雜性、產品成熟度等。，妳很難讓壹個木匠能夠做好砌磚。當然OpenStack的實現服務需求已經在往這個方向發展了。要能綜合解決問題，服務和支持體系也很重要。其實雲化前期出現問題和問題是很正常的。妳用壹堆開放且相對便宜的軟件和硬件堆砌了壹個高可用性的商業環境。無論從壓力和能力的角度，失敗和問題都是正常的，所以認識到這個問題，盡快建立支持服務團隊或購買相關服務，可以極大地改善客戶的體驗。我個人認為，SDE帶來的變化會讓軟件變得更加復雜和開放，商業模式會逐漸過渡到面向服務。試圖通過個人版本統治世界的時代正在慢慢消亡。所以買雲，不管是公有雲還是私有雲，核心都是購買的服務，最終用戶購買和使用服務，運營商從廠商那裏購買服務。因此，托管私有雲將在開源和開放系統的框架下全面發展。