行業云化落地，政務云首當其沖。一來，政務服務大眾，牽涉到廣大人民群眾的福祉；二來，政務受限于大眾，云化進程受成本、效率的制約。

我們知道，云計算給企業商業和運維模式帶來了根本性的變革，政務云的運維成為眾矢之的。政府行業因自身的局限性，大都不會自建運維團隊，企業的運維通常與運營商合作。但是，運營商對傳統數據中心的運維有豐富的經驗，卻缺少對云數據中心的運維經驗。

[[236410]]

換句話說，本身正處在向云轉型過程中的運營商，又負擔了當地政務云的運維工作，這中間要解決的問題就變得頗為復雜。上海政務云，就遇到了這樣的難題，所以它們想到了云運維經驗最為豐富的華為，這會產生怎樣的故事？

上海政務云的運維難題有很強的共性

實際上，在進入互聯網時代之后，我國有過一個階段的電子政務建設黃金期。比如在2011到2015年，電子政務建設達到高峰。但各地數據中心建設繁雜，且缺乏統一規劃造成資源利用率低，后期運維難度大。

所以，政務云的出現，恰好可以作為新一代數據服務和共享平臺，將電子政務發展中遇到的問題一一解決。所以各地政府都在加速走向政務云。

這就引出了傳統數據中心與云數據中心的區別。 

從表面上看，云是數據中心的新IT形態，云數據中心與傳統數據中心的建設目標是一致的，都是為政府或企業提供IT服務。 

但是在運維對象和服務內容上又所有不同：以IaaS層為例，傳統數據中心運維對象主要包括機房基礎設施、網絡及網絡設備、服務器及存儲等硬件相關的實體資源；而云數據中心的運維對象，除了包括傳統數據中心關注的實體資源之外，還要關注架設在基礎架構之上的虛擬資源，比如網絡資源、計算資源、存儲資源，以及虛擬化平臺本身。

換言之，云數據中心是將基礎設施(IaaS)以服務的形式提供給最終用戶，它利用虛擬化、SDN等技術將網絡、計算、存儲等資源池化，通過自動化技術按需為用戶分配IT資源。

[[236411]]

無疑，云服務的需求會驅動運營商從賣資源的運營模式向賣服務、賣能力的模式轉型，這涉及到運維組織架構、資源配備和運維流程的變革，運營商找到了華為來為其提供量身定制云數據中心運維規劃設計方案，共同服務于上海政務云項目。

羅馬不是一天建成，華為如何做到抽絲剝繭？

我們知道，任何政務云項目都是既有共性，也有特定的需求，上海政務云項目絕對無法一蹴而就。這要求華為，拿出專家的精神和專業的態度，抽絲剝繭，抓到運維的關鍵。 

而此刻擺在華為面前的也有很多的難題有待解決。

經過前期詳細的調查后，華為面臨的首要難題是現有運維工具是否滿足云運維需求。受限于預算等原因，客戶還是希望依托現有工具來實現運維。所以，要求項目組需要對當前客戶正在使用的運維平臺的功能進行全面的了解，找出可以適配的部分進行改造和定制。其中，現有的運維工具和承載的業務是否可以與云平臺對接都是運維所要思考的問題。

在客觀的評估現有環境之后，第二個難題是：基于政務云并參考ITIL的標準和框架，制定一套上海政務云的運維組織架構、管理流程、制度規范和SOP。

[[236412]]

但運維組織架構的設計，并不能一蹴而就。華為采取了循序漸進的方式，在前期先輸出一個標準運維組織模型，根據目前的客戶業務特點進行調整，甚至在運營初期，還會對組織架構進行精簡。同時在故障處理階段，如果初期現場還不具備技術能力，就把崗位職責放在后方，隨著業務量的增加，根據工作量再來細分崗位角色，最終期望達到理想高效的組織模型。

在經過了漸進式的部署之后，事情也并沒有結束，華為還會對于已經輸出的流程、規范和SOP，在實際運營中還會不斷的進行優化。而由于當前的流程沒有工具承載，華為還建議客戶采用紙面件先把流程固化，在線下形成規范操作后，隨著工具和平臺的部署，再轉移到線上處理，比如在運營初期，故障量不多，運維現場主要通過電話、微信等方式來進行事件的溝通和傳遞，以保證效率，再通過紙質工單進行記錄和統計。 

總體來看，華為在用一種自上而下的方式，進行了專家式的貼身服務，從初期的內部流程梳理，團隊組建，到拿出方法論，并根據需求不斷優化，克服重重困難，可以說是抽絲剝繭，老成持重。

以上海政務云為模板，華為已有完整的云運維方法論

其實，政務云的建設與其它云服務項目相比還是有明顯的自身特色。比如，政務云運維以核心業務保障為主，不同于互聯網業務的快速迭代，政務云的新業務增速比較緩慢，安全性要求高，更注重管理和績效，往往有分級管理要求，同時也關注數據的潛在價值。

以上海政務云項目為例，華為總結并輸出政務云運維的四個典型階段。

1

***階段，是初級階段。在此階段，更側重于資產管理，還談不到CMDB（配置管理數據庫）的建設，運維流程也只能實現單一的故障處理流程，同時崗位職責上沒有專職的服務臺和管理角色。所以，首先要做好一體化監控，將虛擬化資源池當中的計算資源、存儲資源和網絡資源全部監控起來，做到資源的可視化。以此為基礎就可以及時發現問題并解決問題。

2

第二階段，是基礎建設階段。要在一體化監控的基礎上建設CMDB，CMDB建設成敗會直接影響到運維的效率和成本，CMDB規劃要長遠，但部署要分層次分階段來進行。華為認為，初期的建設可以在IT資產項的基礎上增加邏輯關系，顆粒度不必過細，因為往往過細的顆粒度又會導致運維復雜度增高，運維成本過高，效率反而降低，所以CMDB的建設最能體現一個組織的運維能力。 

例如，上海政務云項目本身涉及到的CI量并不是很大，而且是全新部署的模型，業務應用是逐漸增加，業務管理關系還未成規模，這給CMDB的建模和部署都留出足夠的時間和空間。由于運維組織模型還不夠成熟，一般在這個階段，運維流程往往只是側重于資源申請、發放，以及故障的受理，對于更高級的功能，要隨著運維組織成熟度的加深而不斷完善。

3

第三階段，是流程的標準化運作階段。當CMDB的建設日趨成熟，顆粒度可以滿足日常運維需求，ITIL的運維流程體系才可能真正發揮作用，資源申請、事件、問題、變更、發布也才能真正實現其價值。這個階段運維組織模型已經比較成熟，業務量也會達到相當的規模，流程的標準化運作會讓運維效率，得到大大提升。

4

第四階段，是政務云運維進入自動化和智能化的***階段。這個階段需要更多的工具支撐，一般以定制開發為主，而且需要與業務進行適配。每一個政務云運維最終都要走到這個階段，才能夠稱之為真正的落地。

[[236413]]

去年底，權威機構IDC將中國政務云***的位置授予了華為，顯然是非常有根據的。從這套方法論當中，我們看到了華為對政務云建設，是從客戶的實際情況出發，做到因地制宜，既不做躍進，也不徘徊不前，可以說既滿足了政務云安全、穩定的訴求，也考慮到了運維對業務升級的要求。讓政務云落地成雨，華為做到了。