我們知道，云計算給企業(yè)商業(yè)和運維模式帶來了根本性的變革，政務云的運維成為眾矢之的。政府行業(yè)因自身的局限性，大都不會自建運維團隊，企業(yè)的運維通常與運營商合作。但是，運營商對傳統(tǒng)數(shù)據(jù)中心的運維有豐富的經(jīng)驗，卻缺少對云數(shù)據(jù)中心的運維經(jīng)驗。
換句話說，本身正處在向云轉型過程中的運營商，又負擔了當?shù)卣⻊赵频倪\維工作，這中間要解決的問題就變得頗為復雜。上海政務云，就遇到了這樣的難題，所以它們想到了云運維經(jīng)驗最為豐富的華為，這會產(chǎn)生怎樣的故事？
上海政務云的運維難題有很強的共性
實際上，在進入互聯(lián)網(wǎng)時代之后，我國有過一個階段的電子政務建設黃金期。比如在2011到2015年，電子政務建設達到高峰。但各地數(shù)據(jù)中心建設繁雜，且缺乏統(tǒng)一規(guī)劃造成資源利用率低，后期運維難度大。
所以，政務云的出現(xiàn)，恰好可以作為新一代數(shù)據(jù)服務和共享平臺，將電子政務發(fā)展中遇到的問題一一解決。所以各地政府都在加速走向政務云。
這就引出了傳統(tǒng)數(shù)據(jù)中心與云數(shù)據(jù)中心的區(qū)別。
從表面上看，云是數(shù)據(jù)中心的新IT形態(tài)，云數(shù)據(jù)中心與傳統(tǒng)數(shù)據(jù)中心的建設目標是一致的，都是為政府或企業(yè)提供IT服務。
但是在運維對象和服務內(nèi)容上又所有不同：以IaaS層為例，傳統(tǒng)數(shù)據(jù)中心運維對象主要包括機房基礎設施、網(wǎng)絡及網(wǎng)絡設備、服務器及存儲等硬件相關的實體資源；而云數(shù)據(jù)中心的運維對象，除了包括傳統(tǒng)數(shù)據(jù)中心關注的實體資源之外，還要關注架設在基礎架構之上的虛擬資源，比如網(wǎng)絡資源、計算資源、存儲資源，以及虛擬化平臺本身。
換言之，云數(shù)據(jù)中心是將基礎設施（IaaS）以服務的形式提供給最終用戶，它利用虛擬化、SDN等技術將網(wǎng)絡、計算、存儲等資源池化，通過自動化技術按需為用戶分配IT資源。
無疑，云服務的需求會驅動運營商從賣資源的運營模式向賣服務、賣能力的模式轉型，這涉及到運維組織架構、資源配備和運維流程的變革，運營商找到了華為來為其提供量身定制云數(shù)據(jù)中心運維規(guī)劃設計方案，共同服務于上海政務云項目。
羅馬不是一天建成，華為如何做到抽絲剝繭？
我們知道，任何政務云項目都是既有共性，也有特定的需求，上海政務云項目絕對無法一蹴而就。這要求華為，拿出專家的精神和專業(yè)的態(tài)度，抽絲剝繭，抓到運維的關鍵。
而此刻擺在華為面前的也有很多的難題有待解決。
經(jīng)過前期詳細的調查后，華為面臨的首要難題是現(xiàn)有運維工具是否滿足云運維需求。受限于預算等原因，客戶還是希望依托現(xiàn)有工具來實現(xiàn)運維。所以，要求項目組需要對當前客戶正在使用的運維平臺的功能進行全面的了解，找出可以適配的部分進行改造和定制。其中，現(xiàn)有的運維工具和承載的業(yè)務是否可以與云平臺對接都是運維所要思考的問題。
在客觀的評估現(xiàn)有環(huán)境之后，第二個難題是：基于政務云并參考ITIL的標準和框架，制定一套上海政務云的運維組織架構、管理流程、制度規(guī)范和SOP。
但運維組織架構的設計，并不能一蹴而就。華為采取了循序漸進的方式，在前期先輸出一個標準運維組織模型，根據(jù)目前的客戶業(yè)務特點進行調整，甚至在運營初期，還會對組織架構進行精簡。同時在故障處理階段，如果初期現(xiàn)場還不具備技術能力，就把崗位職責放在后方，隨著業(yè)務量的增加，根據(jù)工作量再來細分崗位角色，最終期望達到理想高效的組織模型。
在經(jīng)過了漸進式的部署之后，事情也并沒有結束，華為還會對于已經(jīng)輸出的流程、規(guī)范和SOP，在實際運營中還會不斷的進行優(yōu)化。而由于當前的流程沒有工具承載，華為還建議客戶采用紙面件先把流程固化，在線下形成規(guī)范操作后，隨著工具和平臺的部署，再轉移到線上處理，比如在運營初期，故障量不多，運維現(xiàn)場主要通過電話、微信等方式來進行事件的溝通和傳遞，以保證效率，再通過紙質工單進行記錄和統(tǒng)計。
總體來看，華為在用一種自上而下的方式，進行了專家式的貼身服務，從初期的內(nèi)部流程梳理，團隊組建，到拿出方法論，并根據(jù)需求不斷優(yōu)化，克服重重困難，可以說是抽絲剝繭，老成持重。
以上海政務云為模板，華為已有完整的云運維方法論
其實，政務云的建設與其它云服務項目相比還是有明顯的自身特色。比如，政務云運維以核心業(yè)務保障為主，不同于互聯(lián)網(wǎng)業(yè)務的快速迭代，政務云的新業(yè)務增速比較緩慢，安全性要求高，更注重管理和績效，往往有分級管理要求，同時也關注數(shù)據(jù)的潛在價值。
以上海政務云項目為例，華為總結并輸出政務云運維的四個典型階段。
1、第一階段，是初級階段。在此階段，更側重于資產(chǎn)管理，還談不到CMDB（配置管理數(shù)據(jù)庫）的建設，運維流程也只能實現(xiàn)單一的故障處理流程，同時崗位職責上沒有專職的服務臺和管理角色。所以，首先要做好一體化監(jiān)控，將虛擬化資源池當中的計算資源、存儲資源和網(wǎng)絡資源全部監(jiān)控起來，做到資源的可視化。以此為基礎就可以及時發(fā)現(xiàn)問題并解決問題。
2、第二階段，是基礎建設階段。要在一體化監(jiān)控的基礎上建設CMDB，CMDB建設成敗會直接影響到運維的效率和成本，CMDB規(guī)劃要長遠，但部署要分層次分階段來進行。華為認為，初期的建設可以在IT資產(chǎn)項的基礎上增加邏輯關系，顆粒度不必過細，因為往往過細的顆粒度又會導致運維復雜度增高，運維成本過高，效率反而降低，所以CMDB的建設最能體現(xiàn)一個組織的運維能力。
例如，上海政務云項目本身涉及到的CI量并不是很大，而且是全新部署的模型，業(yè)務應用是逐漸增加，業(yè)務管理關系還未成規(guī)模，這給CMDB的建模和部署都留出足夠的時間和空間。由于運維組織模型還不夠成熟，一般在這個階段，運維流程往往只是側重于資源申請、發(fā)放，以及故障的受理，對于更高級的功能，要隨著運維組織成熟度的加深而不斷完善。
3、第三階段，是流程的標準化運作階段。當CMDB的建設日趨成熟，顆粒度可以滿足日常運維需求，ITIL的運維流程體系才可能真正發(fā)揮作用，資源申請、事件、問題、變更、發(fā)布也才能真正實現(xiàn)其價值。這個階段運維組織模型已經(jīng)比較成熟，業(yè)務量也會達到相當?shù)囊?guī)模，流程的標準化運作會讓運維效率，得到大大提升。
4、第四階段，是政務云運維進入自動化和智能化的終極階段。這個階段需要更多的工具支撐，一般以定制開發(fā)為主，而且需要與業(yè)務進行適配。每一個政務云運維最終都要走到這個階段，才能夠稱之為真正的落地。
去年底，權威機構IDC將中國政務云第一的位置授予了華為，顯然是非常有根據(jù)的。從這套方法論當中，我們看到了華為對政務云建設，是從客戶的實際情況出發(fā)，做到因地制宜，既不做躍進，也不徘徊不前，可以說既滿足了政務云安全、穩(wěn)定的訴求，也考慮到了運維對業(yè)務升級的要求。讓政務云落地成雨，華為做到了。
