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