編者的話：邱洋，品高云（BingoCloud）的產品總監，國內首個商用云操作系統BingoCloudOS 云操作系統由他的團隊創建，從2008年開始，他見證了品高云從零到現在的過程?，F在是品高云正式商用的第七個年頭，他筆下的“品高云七年”是怎樣的？

上回給大家分享了《品高云七年 | 第三部（下）：生產運行支撐到底對云有什么需求》（點擊閱讀），今天為大家帶來第四部：集團云的發展在于可持續運營。

邱洋 品高云產品總監

“品高云七年系列”第四部

集團云的發展在于可持續運營

01

概述

隨著云平臺中支撐的應用越來越多，企業IT系統的開發、測試、生產運維等工作的敏捷度提升明顯（一般會在100%以上），但此時在CEO的眼里，云平臺始終是個花錢的IT應用。而一個IT應用到底產生了多少收益？是否值得持續投入？在企業中往往都缺乏客觀的參考依據。

另一方面，對于集團性公司來說，往往需要通盤考慮IT建設的規范化，如果總部或某分支機構建設了一套IT系統，倘若效果明顯就會在集團內推廣。而這又可能帶來“縣官不如現管”、“水土不服”、“虎頭蛇尾”等問題。而對于云平臺這種與ERP系統平級的戰略性IT系統來講，只有能持續地產生正向的反饋效果，才能給企業信心和更加深入的方向。

要解決上述問題，必須升級企業IT管理思路，將IT部門的定位從成本中心向利潤運營中心轉變。通過對中國醫藥、招商局、騰訊、招商銀行等集團型云客戶；以及廣州政務云、地鐵軌交云等行業云案例的思路分析，發現客戶的云平臺建設應該在五化上下功夫，包括：集約化、標準化、顯性化、流程化和藍圖化。

02

資源管理集約化

集團性企業往往擁有大量的IT資產，這些資產分布在總部機房、分支機構、運營商IDC機房等。通過云平臺的建設，應該將這些資源統一納入管理，進入企業的CMDB（配置管理數據庫）中。跟傳統建設CMDB需要大量探針和手工的工作不同，由于所有資源被云平臺統一調度，因此無論在事前（如上架/準備資源）、事中（如運維/監控資源）、事后（如排障/變更資源）所產生的信息都可以自動更新到CMDB中。

某銀行客戶全云資產監控大圖（虛擬數據）

近年來由于企業IT系統外延、互聯網化、移動化等趨勢明顯，公有云也逐漸在大型企業中開始使用，但是對于企業來講有些問題始終如鯁在喉，他們是：

公有云和私有云的架構往往不同，如何進行統一的管理？

一般公有云中講服務（如彈性云主機、虛擬私有云等），而私有云中主要講各種云技術（如虛擬機、SDN等）。如要將兩者有機地調度起來實現互聯互通甚至無縫遷移，首先需要讓兩者擁有平等溝通的機制——開放標準的API；然后將公/私云技術統一用云服務能力來描述（如彈性服務器、彈性硬盤等）；最后通過上層自助服務平臺統一進行服務的申請和管理。

在統一平臺中交付公有云和私有云資源

如何避免公有云“服務鎖定”？

從商業利益的角度考慮，商家永遠希望鎖定客戶，而企業一定不希望這樣。 就像外出吃飯一樣，我們不可能永遠在一個餐廳吃飯，因為會吃膩、服務下降、有更好吃的餐廳等。

而云中存放的往往是客戶的業務應用、業務數據，甚至操作習慣，更容易鎖定用戶。這時就要小心了，一般的云主機、云硬盤等還好遷移，而對于高級的服務，如RDS、中間件服務、大數據處理、非關系數據庫等一旦使用之后很難解套，運維過程變為黑盒且不可控，后面隱藏著巨大的遷移成本和安全風險。

因此，建議企業以自己的技術路線為前提，將公有云作為一個額外的資源池使用，只使用其基本的服務（如云主機、云硬盤等），而其他高級服務（如RDS、容器服務等）可以考慮利用私有云的自動化部署、云編排等能力按需構建，這樣的能力使得云服務的能力始終掌控在企業手里，而在運維層面可以做到足夠透明，在異構的公有云之間遷移也將變得更加“輕松”。

企業應用眾多哪些業務適合公有云？

從品高云的客戶中了解到，大型企業的IT應用系統是以百計的，有些甚至上千，而這些應用哪些適合遷移到公有云，哪些又不適合，企業往往很難決策，一旦方向失敗很有可能直接影響業務上線后的正常運行。

單純從應用是否有互聯網訪問一個維度來判斷，是不準確的。例如某制藥企業的ERP系統，雖然有開放接口給互聯網電商訪問的功能，但是卻不一定適合放在公有云中，因為這個系統同時也被內部財務部門使用。

針對這種情況，品高依據13年的大型企業IT建設與顧問經驗，總結出一套云應用部署規劃方法論，并在國藥、廣鐵等客戶的實際應用得到了良好的反饋。例如：我們建議企業分別在彈性、安全性、生命周期、面向群體、系統類型等5個維度上進行評估打分，并最終得到企業的應用部署分析象限圖（哪些適合公有云、哪些必須私有云，哪些甚至可以混合部署）從而輔助客戶進行決策。

某客戶應用部署建議象限圖

企業本地應用如何向公有云遷移？

針對這個問題沒有標準答案，但是建議企業選擇那些同時擁有公有云和私有云建設運營經驗，以及在實際案例中至少遷移超過1000臺以上服務器規模的廠商來進行入圍考慮。

另一方面，為了更好規避系統遷移失敗風險，整個過程需要設計完善的方案。建議從規劃（包括信息搜集、遷移評估、關聯分析、風險分析、遷移策略制定）、詳細設計（包括遷移方案制定、計劃制定、風險應對計劃）、實施執行（包括預遷移、驗證測試、正式遷移、正式切換、遷移報告）以及后續管理（包括業務遷移監控、遷移優化）等4個階段制定相應方案。

應用遷移流程階段示意圖

03

服務內容標準化

當企業開始資源“大集中”，并能有條不紊的管理之后，接下來的問題是：資源畢竟有限，眾多IT需求是否都要滿足？此時企業會針對自身的IT水平制定標準服務目錄和對應的SLA。前者說明能做什么，后者則描述做到什么程度。

針對服務水平我很佩服麥當勞，無論任何一家麥當勞，菜單一致，出品時間一致，口感也幾乎相同，在這種情況下客戶的滿意度往往是最高的（因為想要和得到的內容永遠一致）。

通常成熟企業的IT服務管理，會參考類似ITIL的最佳實踐，但是由于技術的限制，雖然都有完善的監督和流程機制，但由于執行層大多是“人工”，這就為IT服務帶來了不可控風險，致使制定的SLA難以完成，或者不敢制定太高的SLA，這勢必阻礙企業IT的進步發展。要改善這一窘境，應該更多將服務交給“ 機器人”去執行，利用其一絲不茍的特性并配以監督機制，可以使得SLA可以更好的得到保障。

云平臺提供了眾多的自動化功能，可以很好地提升企業的SLA。但跟傳統網管和虛擬化軟件由管理員來具體操作不同，云平臺應該提供重要組件“自助服務平臺”，將自動化功能以云服務目錄形式提供，服務菜單上可能會有如：云主機服務、數據庫服務、負載均衡服務、應用部署服務等供需求者選擇。需求者在云服務目錄中直接提交需求后，少則幾秒鐘，多則幾十分鐘，就可以看到服務的結果。

就像麥當勞菜單也會區分清真和普通客戶一樣，隨著企業IT運營水平的不斷提高，相信會有更多IT服務被創新出來，此時就要針對業務部門、分支機構的特點進行分析，有針對性地提供服務目錄，例如：生產保障部門往往需要集群服務維系可靠性，而研發部門往往單機就可以滿足需求；集團總部可能需要網盤/郵件/移動中間件這種規范層面的服務，而子公司則可能需要廣告投放、工程項目管理這樣的業務服務能力。

相信在這樣標準的架構下，每個企業員工在獲取IT服務的體驗，就像去麥當勞一樣，從服務菜單中選擇想要的IT服務，之后片刻就可以獲得。

某客戶的自助云服務目錄－－區分開發/測試/生產不同

04

服務能力顯性化

傳統管理思路下，IT建設采用計劃模式（當年做次年的），也就是說IT系統的效果最快也是在第二年才看到效果，更不用說很多所謂效果是拍腦袋和依據以往經驗推斷出來的，總體來講就是IT究竟創造了多少價值，缺乏有效的衡量標準。

云平臺的一個重要能力體現就是“可量化”（參考NIST定義云的5個特征）。每個用戶在云平臺中享受的服務、使用的資源都被記錄下來，并且按照一定的規則轉換為價值，一般常用的規則有代幣衡量、資源衡量這兩種方法：

代幣衡量：通過將資源的最小單位如每CPU、每G內存、每T硬盤、每個軟件license、每個軟件用戶等設置一個代幣單價（如金幣、豆豆等），然后再配以時長或區間模式進行計算，最終得到某用戶消費的代幣總額。某種情況下這個代幣可以和錢是1：1的關系（因為企業采用外包形式一樣要付出成本的），這樣就直觀地表現出IT服務所創造的價值，之后再通過跟企業每年的IT實際投入做對比，在運作良好的情況下，IT部門甚至可以體現“利潤中心”的價值（產出大于投入）。

在云平臺中設定資源價值

資源衡量：通過將資源（如CPU，內存，硬盤空間等）以配額形式發放給分支機構，分支機構在年初提資源打包預算申請，公司不再直接給予金錢，而是資源配額。通過合理預測和量化實際使用率（往往初期估算的資源投入都是滿負荷的情況，發生的概率很低，就算發生也可以用資源池中其他低負荷資源）就不必為每個分支機構真實購買所有資源 。在年尾時可以將IT實際的投入和預算對比，在運作良好的情況下，可以體現IT部門節省大批資金的價值。

某客戶內部IT營收情況圖

05

工作過程流程化

跟互聯網公有云的模式不同，往往由于企業部門眾多，企業為了更好地規范權責關系，勢必對工作的流程有一定的要求，有些復雜的流程可能還要跨部門跨組織進行審批，但這并不是說明審批就和云計算的自助模式水火不容，品高云通過對現有客戶實際使用情況的總結，發現企業可以按照云平臺用戶范圍的逐步擴大而應用不同的云服務流程：

不需要流程：如只在IT運維部門內部使用，因為都是管理員在操作。此時如果企業有自己的ITIL系統或OA系統，可以繼續使用。

一站審批：如在整個IT部門使用，各團隊被分配配額自助申請資源，由平臺管理員依據可用物理資源現狀做統一審批（按優先級）。

配額審批：一般用于事業部制單一企業使用，各需求部門在年初需要時向IT部門統一申請項目配額，之后可以按需自助申請云服務。

多級靈活審批：一般用于集團多分支企業使用，各需求組織一開始跟總部申請統一配額，之后在實際使用時組織內部門向自己上級發起申請，審批通過后就可以使用云服務。

ITIL售后流程：一般單一企業以上部署了云服務時使用，各級組織用戶對IT服務的建議、問題以及對故障的申報等工作，應該有標準的支撐流程，可以參考ITIL流程。這一流程既可以在云平臺中實現，也可以對接企業現有ITIL系統實現。

　　06

實施步驟藍圖化

由于集團型企業的IT部門必須運營在嚴格的規章制度、方針指引和過程管控之下，同時由于企業的業務目標、管理思路和信息化建設成熟度迥異，對于貼身的個性化服務、服務的延續性、信息安全等都有比較高的訴求，因此，企業實施云計算的過程也更加復雜和多樣化：【縱向技術層面】需要從應用到平臺到最后的基礎設施進行綜合的考慮和規劃?！緳M向管理層面】還需要考慮組織架構的變化、原有應用程序的遷移、原有應用程序架構的改變等，用以適應云計算環境下的應用開發、部署、運行和運維。因此，如何確定企業內云計算的戰略和部署，就變得尤其重要。

企業云運營邏輯架構

對于集團企業來說，由于內部IT的復雜性，因此企業內部署云不太可能一步到位，應該是個漸進的過程，通常來說包括數據中心集中整合、服務提供與自動化、應用云化、服務化運營四個階段。

第一步 數據中心的整合集中、標準化和優化

通過整合、集中和標準化，簡化對現有IT基礎設施的管理，降低成本和管理難度，這是企業IT平臺設施環境降低復雜性和成本的第一步。

這一過程將企業分散的硬件設備資源進行了物理集中，形成了規?；臄祿行幕A設施。尤其對一些大型企業或者集團企業，通過規劃、管理以及標準化等措施，把分散在各部門、分子公司的數據中心資源進行資產盤點，根據企業的業務需求和管理需求，重新規劃數據中心的區域劃分和容災策略，逐步進行舊有資源的遷移和新購資源的整合集中機制，最終建立基于云計算的數據中心基礎架構。

在數據中心新的規劃過程中，企業將建立自己的標準和新的IT業務服務的規范，用以指引既有的業務擴展或者新業務的上線部署，從而解決IT資源分散管理和容災的相關問題。

第二步 服務提供與自動化

對于企業IT部門來說，企業云將其職責轉化為運營中心，信息化部門負責服務的規劃、設計、優化等，具體的服務交付、運維工作交由云平臺來完成。

在服務規劃設計的過程中，IT部門需要重點關注如下方面：

云平臺服務規劃示例

第三步 應用遷移云化

當企業在建立了統一管理的數據中心并能提供服務后，需要根據應用的重要程度、安全級別、使用對象、生命周期等，規劃傳統部署在物理機上的業務平臺和企業應用向云中遷移的藍圖。

遷移的策略應以業務需求為導向、總體擁有成本降低為目標、安全可靠有效運行為準則，遵循以下原則：

由表及里，先易后難，優先遷移關聯應用較少，比較容易遷移恢復業務的應用系統。

先普通、后核心，從非核心應用入手，逐步向企業平臺應用及核心應用演進，遷移過程中，可以先試點整合，再小規模遷移，最后進行全面應用遷移階段。

選擇非業務繁忙時段實施遷移，如夜晚、節假日等。

基于上述原則，企業現有的應用遷移流程分為如下四個階段：前期遷移規劃、設計遷移過程，實施遷移，后續應用管理。

某集團客戶應用遷移要點制定示例

第四步 運營服務化

云計算到最后的轉型階段，就是一切皆服務，動態的基礎架構、企業級的平臺服務、企業內的各種應用、關鍵行業的業務流程、軟件、信息、商業應用套件和解決方案都可以成為服務。因此，企業IT部門，主要精力在于梳理服務目錄，并提供可視化、安全性和自動化的平臺管理，專注于服務的提供和業務的運營，從而實現企業新的IT藍圖：IT資源能夠彈性擴展，IT服務可以按需、自助獲取。在提升業務敏捷性的同時，進一步大幅降低成本。對于部分企業，通過云計算的實施，還可能創造出新的商務模式，為更多的客戶提供服務。在這個步驟，IT部門應考慮如下幾個方面：

某集團服務化運營要點制定示例

PS：以上藍圖內容摘選自品高云與國藥集團聯合發布的《企業云計算演進策略與實踐報告2015》白皮書，如有需要可與品高云客服聯系：4008-300-246

企業云計算演進策略與實踐報告2015封面

07

總結

當企業真正開始實行集約化、標準化、顯性化、流程化和藍圖化的云模式管理時，就說明了企業已經邁入運營式IT管理階段，IT部門的定位也從成本中心向利潤運營中心轉變，在這個階段企業的信息技術能力和能動性將充分發揮，所獲得的數據信息也將開始爆炸式增長，視角也將變得逐漸開闊，如果說之前的IT都在依靠經驗和顧問進行規劃的話，那么這個階段就可以真正依據“大數據”的力量，做出對未來的需求的預測，從而做到運籌帷幄、決勝N年之前。

 

　　“品高云七年”系列第四部已經完結，你期待第五部嗎？