作者  | 銀大偉

現(xiàn)如今，適時利用云計算提供的資源彈性伸縮能力以及托管服務(wù)已成為行業(yè)共識，是否采納和使用云對于企業(yè)而言已不再是選答題而是必答題。能否做到業(yè)務(wù)上云，即企業(yè)能否真正有效地利用云及其生態(tài)所提供的新技術(shù)和平臺來賦能業(yè)務(wù)、加速數(shù)字化轉(zhuǎn)型、提升企業(yè)的競爭力，對很多企業(yè)來說依然是一個巨大的挑戰(zhàn)。

據(jù)觀察，許多企業(yè)的業(yè)務(wù)上云旅程并不順利，甚至可以說十分艱難， 特別是在上云的系統(tǒng)規(guī)模比較大（系統(tǒng)數(shù)量在幾百甚至上千）和涉及的業(yè)務(wù)線比較多的時候。挑戰(zhàn)不僅僅來自技術(shù)層面，也來自原有的組織結(jié)構(gòu)、團隊能力和研發(fā)體系。另外，還有一些企業(yè)把云遷移作為自身業(yè)務(wù)上云的目標，這顯然是不合理的，因為這很容易導致把業(yè)務(wù)上云等同于系統(tǒng)從數(shù)據(jù)中心到云的搬遷，最終很難達成企業(yè)期望的業(yè)務(wù)上云的價值目標，例如降本增效、提升響應(yīng)力、賦能業(yè)務(wù)等。

本文將深入探討企業(yè)業(yè)務(wù)上云的驅(qū)動力和挑戰(zhàn)，以及如何有效規(guī)劃符合自身場景的業(yè)務(wù)上云策略，盡早識別風險并建立跨部門和跨團隊的協(xié)同機制，加速業(yè)務(wù)上云。

業(yè)務(wù)上云之驅(qū)動力

驅(qū)動企業(yè)實施業(yè)務(wù)上云的因素有很多，例如常見的降本增效、提升業(yè)務(wù)響應(yīng)力、通過新技術(shù)賦能數(shù)字化轉(zhuǎn)型、政策及合規(guī)等。還有一些企業(yè)在上云的過程中會對其業(yè)務(wù)架構(gòu)進行重新設(shè)計，這通常伴隨著未來數(shù)年的業(yè)務(wù)愿景和目標。

仔細分析這些驅(qū)動力可以發(fā)現(xiàn)一個隱藏的假設(shè)：簡單維持現(xiàn)狀可能并不會使企業(yè)的業(yè)務(wù)乃至競爭力變的更好，可能不變甚至變糟，這也是為什么在上文中提到如果僅僅是系統(tǒng)搬遷上云并不能幫助企業(yè)達成業(yè)務(wù)上云，因為這樣除了基礎(chǔ)設(shè)施由數(shù)據(jù)中心變?yōu)樵?，其業(yè)務(wù)模式和競爭力都沒有發(fā)生本質(zhì)的變化。因此，企業(yè)在選擇上云時，其隱藏的上云驅(qū)動力是對其競爭力的重構(gòu)，是通過業(yè)務(wù)模式和技術(shù)的變革對企業(yè)進行再造的過程。

從“The 6R's”看業(yè)務(wù)上云之挑戰(zhàn)

6R通常是企業(yè)規(guī)劃上云的首選策略，鑒于互聯(lián)網(wǎng)上已經(jīng)有很多關(guān)于6R的解釋，本文不作過多闡述，具體可以參考這里：??6 Strategies for Migrating Applications to the Cloud?? 。6R雖然可以對應(yīng)用上云的策略進行分類，但也容易帶來一些問題。例如，企業(yè)通常為了快而采用lift & shift，即把虛機打包成鏡像搬移上云。對云廠商來說，這是最符合其盈利模式的方式，但對企業(yè)來說，收益卻很有限甚至低于期望。

而且，6R還容易導致在上云過程中出現(xiàn)價值鴻溝問題。價值鴻溝（??Is Your Cloud Journey Stuck in the Value Gap???]）是Thoughtworks前首席咨詢師Gregor Hohpe提出的：

如：想要采購一些技術(shù)類產(chǎn)品或解決方案，快速產(chǎn)生高價值。然而，由于其組織結(jié)構(gòu)、流程、能力及研發(fā)體系還無法與新技術(shù)進行很好的匹配（Org Change），導致真正的干系人（例如業(yè)務(wù)側(cè)）感知到的真實價值遠遠小于期望價值（Value Gap）。而采用6R時，容易把主要關(guān)注點過早的放在技術(shù)上，而組織上需要做的變革由于多種原因被延后甚至忽略，從而凸顯了價值鴻溝。

另外，規(guī)模也是一個不得不關(guān)注的挑戰(zhàn)。業(yè)務(wù)上云通常是企業(yè)IT部門負責，IT團隊要盡可能保證業(yè)務(wù)的連續(xù)性并減少對現(xiàn)有業(yè)務(wù)的影響。在制定上云計劃及遷移策略時，由于應(yīng)用和系統(tǒng)數(shù)量龐大，這就要求IT團隊需掌握的業(yè)務(wù)上下文和管理的干系人數(shù)量也是非常大的。

因此，在保障業(yè)務(wù)的前提下，制定業(yè)務(wù)上云的策略，除了技術(shù)帶來的挑戰(zhàn)以外，還有來自如何使眾多參與方保持一致的目標，如何進行跨團隊的有效溝通，以及如何盡早識別和管理風險等多個方面。

業(yè)務(wù)上云之四大關(guān)鍵問題

為此，我們總結(jié)了業(yè)務(wù)上云需關(guān)注的四大關(guān)鍵問題，即：如何建設(shè)，如何推廣，如何遷移及如何演進。

如何建設(shè)？

如何建設(shè)的關(guān)鍵點在于如何平衡采購行業(yè)產(chǎn)品或解決方案與企業(yè)自身的需求。不可否認，行業(yè)產(chǎn)品或解決方案能夠解決一些通用問題，但每個企業(yè)自身的問題都有特殊性，這就要求該產(chǎn)品不但需要依照企業(yè)的需求進行定制化，還需要能夠與其上下游系統(tǒng)和流程集成。當采購的產(chǎn)品和解決方案較多的時候，如何管理這些定制化和集成，以及如何與自身上云計劃和策略匹配就會成為突出的問題，因為，不同產(chǎn)品提供商響應(yīng)定制化需求的效率、能力甚至是意愿都是不同。

因此，要回答如何建設(shè)，企業(yè)必須要回到自身的業(yè)務(wù)愿景、需求和場景，以此作為出發(fā)點反向構(gòu)建對于未來業(yè)務(wù)和數(shù)字化能力的訴求，再評估市場上不同的產(chǎn)品和方案，最終決定哪些需要采購，哪些需要自建。這也是構(gòu)建未來技術(shù)平臺甚至業(yè)務(wù)中臺的基礎(chǔ)。例如，在選擇云廠商及相關(guān)技術(shù)類產(chǎn)品（如相關(guān)DevOps或微服務(wù)平臺等）時，除了要對比不同選項間功能和價格外，還需要通過梳理高價值需求和場景以及自身能力訴求對備選方案進行驗證和評估。

如何推廣？

大家可能會疑惑為什么業(yè)務(wù)上云需要考慮推廣？推廣什么？推廣給誰？這些問題其實是由企業(yè)傳統(tǒng)IT在數(shù)字化轉(zhuǎn)型時代自身定位轉(zhuǎn)換所引起的。以往IT的定位主要依靠數(shù)據(jù)中心為業(yè)務(wù)方或研發(fā)團隊提供資源側(cè)的支持和運維，因此，其團隊規(guī)模有限且日常大部分時間都是處理大量的ticket。該定位導致IT本身距離業(yè)務(wù)比較遠，在企業(yè)的研發(fā)體系中也屬于偏底層或邊緣的位置。所以，通常說IT是企業(yè)的成本中心。而企業(yè)決定業(yè)務(wù)上云后，IT本身的定位也發(fā)生了很大的轉(zhuǎn)換，不但IT自身要應(yīng)對非常多新的技術(shù)和挑戰(zhàn)，還要擔負起新技術(shù)賦能者的職責，這里的賦能不但要賦能業(yè)務(wù)，也要賦能研發(fā)團隊。如果再從研發(fā)體系的視角看，IT則是從以往研發(fā)體系的邊緣向研發(fā)體系的核心移動。

既然要賦能，最好的方式就是把新技術(shù)封裝成適合企業(yè)自身需求的能力和服務(wù)提供出去，這也是為什么我們看到很多企業(yè)內(nèi)部形成了諸多技術(shù)平臺和技術(shù)服務(wù)類產(chǎn)品，甚至還劃分了不同的團隊（如：基礎(chǔ)設(shè)施團隊、平臺團隊等）。他們的職責都是通過對新技術(shù)進行封裝，降低研發(fā)團隊的學習和使用成本，從而達到賦能的目的。而IT自身的定位也從提供資源、運維和響應(yīng)ticket，變?yōu)榱颂峁﹥?nèi)部技術(shù)類平臺和產(chǎn)品。

推廣什么？推廣的主體就是企業(yè)內(nèi)部的技術(shù)類平臺和產(chǎn)品。推廣給誰？業(yè)務(wù)方的研發(fā)團隊。而推廣成功與否的度量方式也變?yōu)橐恍┝嘘P(guān)鍵指標，如：有沒有用戶，好不好用，體驗怎么樣，是否先進，SLA如何，效果怎么樣等。因此，推廣背后的根因是IT由服務(wù)型團隊向產(chǎn)品型團隊的轉(zhuǎn)換，這要求IT需具備一定的產(chǎn)品設(shè)計思維，不斷理解業(yè)務(wù)，優(yōu)化開發(fā)者體驗角度，設(shè)計高度定制化的服務(wù)。

如何遷移？

如果孤立看遷移，它僅僅是應(yīng)用的搬遷，但結(jié)合上文產(chǎn)品型團隊的定位，那么遷移的含義就完全不同了，是一種產(chǎn)品引流的方式，是一種服務(wù)，并要做到高效、標準化且可重復(fù)。

我們見過一些企業(yè)把遷移服務(wù)描述為遷移工廠和生產(chǎn)線，通過一系列操作和組裝，應(yīng)用就能完成改頭換面。但該方法可行與否是有前提的：生產(chǎn)線意味著我們對原料的加工方式已經(jīng)明確且可重復(fù)。而在企業(yè)內(nèi)部需要遷移的應(yīng)用大多都是遺留系統(tǒng)，他們可能每個都不同，架構(gòu)也比較老舊，技術(shù)與現(xiàn)代化應(yīng)用差異很大且經(jīng)過多年的修修補補，再加上業(yè)務(wù)上下文的缺失，修改很可能引起對業(yè)務(wù)不可控的風險。因此，我們常?？吹綄σ恍├吓f系統(tǒng)的改造非常困難，甚至需要數(shù)年的時間才能完成。另外，作為IT團隊，由于以前距離業(yè)務(wù)較遠，缺乏對現(xiàn)有業(yè)務(wù)應(yīng)用的全面了解，因而無法設(shè)計出有針對性的遷移方案，容易導致業(yè)務(wù)側(cè)與IT的相互拉扯，使得遷移過程更加困難。

因此，如何設(shè)計有效的遷移方案，取決于對應(yīng)用本身知識的了解程度，整個過程很難一蹴而就。但如果我們以引流的方式思考，把遷移服務(wù)類比為一個產(chǎn)品，應(yīng)用類比為用戶，那么我們可以采用市場營銷的方式來設(shè)計整個遷移策略和方案。

首先，由于應(yīng)用本身的維護和管理大多在IT側(cè)，我們可以對應(yīng)用建立一系列特征庫來進行描述，就像通過數(shù)據(jù)埋點抓取用戶數(shù)據(jù)一樣。這些特征可以是靜態(tài)的，比如：編程語言、數(shù)據(jù)庫、集成關(guān)系、中間件等；也可以是動態(tài)的，比如：業(yè)務(wù)上下游的調(diào)用關(guān)系、應(yīng)用間的依賴關(guān)系等。通過特征的建立，我們就可以依據(jù)一些規(guī)則對應(yīng)用進行分類，分類的目的是快速了解應(yīng)用并發(fā)現(xiàn)應(yīng)用間的相似性，而相似性則能夠一定程度保證對該分類設(shè)計的遷移方案能夠重用。當應(yīng)用特征的抓取被自動化后，再結(jié)合一些可視化工具和分類算法，就能夠極大的幫助IT快速制定適合的遷移方案。

如何演進？

由于業(yè)務(wù)會因為市場的變化而不斷調(diào)整，技術(shù)迭代的速度也在加快，這就要求企業(yè)內(nèi)部的平臺和技術(shù)類產(chǎn)品也能隨之不斷更新和升級。如何演進的關(guān)鍵在于：能否做到以用戶（業(yè)務(wù)方和研發(fā)團隊）為中心，應(yīng)用產(chǎn)品思維和設(shè)計思維，做到與業(yè)務(wù)共同演進。

首先，要基于業(yè)務(wù)愿景制定發(fā)展階段。通過與業(yè)務(wù)的合作，加深對業(yè)務(wù)的了解，將業(yè)務(wù)需求轉(zhuǎn)化為對平臺和產(chǎn)品的策略性需求，加入產(chǎn)品的迭代計劃。其次，逐步建立起自己的數(shù)字化運營體系。指標體系的設(shè)計可以分別從IaaS，PaaS以及SaaS的維度展開，以此為目標不斷優(yōu)化。第三，通過團隊拓撲優(yōu)化跨團隊協(xié)作。建立平臺團隊和賦能團隊，積極參與到研發(fā)活動中。從第一線觀察和了解研發(fā)團隊的痛點，并評估當前服務(wù)的功能、體驗和有效性是否能夠滿足研發(fā)團隊的要求，并將開發(fā)者體驗納入到產(chǎn)品演進中。

業(yè)務(wù)上云之云化體系全景圖

我們將上述四大問題總結(jié)為一套業(yè)務(wù)上云的體系全景圖，并以此來指導和規(guī)劃企業(yè)業(yè)務(wù)上云的策略和路線圖。

該體系從實際應(yīng)用特征數(shù)據(jù)出發(fā)，通過對應(yīng)用分類，降低應(yīng)用遷移的復(fù)雜度，使得遷移的流程、工具和方法被標準化，加速企業(yè)的數(shù)字化進程；與此同時，它也能夠幫助IT建立起一套自身的數(shù)字化運營體系，應(yīng)用產(chǎn)品思維和設(shè)計思維做到和業(yè)務(wù)共同演進。

數(shù)據(jù)驅(qū)動的應(yīng)用特征庫

應(yīng)用特征可以分為應(yīng)用的靜態(tài)特征和動態(tài)特征。靜態(tài)特征是來自開發(fā)態(tài)的數(shù)據(jù)，例如：業(yè)務(wù)領(lǐng)域，編程語言，依賴庫，數(shù)據(jù)庫，中間件，提交記錄，構(gòu)建頻率等；動態(tài)特征是來自運行時的數(shù)據(jù)，如：上下游調(diào)用關(guān)系，調(diào)用鏈路，調(diào)用頻率，耦合程度，日志等。同時，由于應(yīng)用的運維及產(chǎn)生的數(shù)據(jù)大多由IT團隊管理，因此，IT團隊便于建立一套自動化的應(yīng)用特征數(shù)據(jù)采集系統(tǒng)，做到應(yīng)用特征的實時采集和更新。應(yīng)用特征庫的建立，能夠有效幫助IT團隊彌補業(yè)務(wù)和應(yīng)用上下文不足的問題，做到有針對性的設(shè)計遷移和改造方案。

應(yīng)用分類驅(qū)動遷移策略

有了應(yīng)用特征庫，就可以采用圖數(shù)據(jù)庫，如neo4j，通過聚類算法尋找應(yīng)用間的關(guān)聯(lián)關(guān)系并可視化。識別應(yīng)用的相似性及分類就像對用戶特征進行分類一樣，特征相似的應(yīng)用意味著能夠采用相似的遷移策略和方法，也就意味著基于該類應(yīng)用的遷移方法是能夠在此類應(yīng)用中復(fù)用的。另外，不同的分類，也代表了不同的遷移難度和風險，就可以快速對應(yīng)用遷移中成本進行估算，方便制定應(yīng)對方案。

我們建議在分類中適當選取具備某些特征的應(yīng)用作為該分類的樣板間，例如：選取復(fù)雜度最高的或業(yè)務(wù)中的關(guān)鍵應(yīng)用等。在遷移初期，IT團隊應(yīng)投入資源保證該樣板間的成功遷移，并總結(jié)和提煉遷移中的實踐和經(jīng)驗。這些實踐和經(jīng)驗，一方面可復(fù)用到該分類的其他應(yīng)用，一方面可以最終升級整體遷移策略的實踐和工具，并以平臺服務(wù)的形式提供。

數(shù)字化運營指標體系

當越來越多的應(yīng)用成功遷移上云后，IT團隊應(yīng)逐步考慮建立云平臺的數(shù)字化運營指標體系。建立數(shù)字化運營指標體系的方式是把云平臺當作企業(yè)內(nèi)部的產(chǎn)品，以產(chǎn)品的視角定義平臺的服務(wù)質(zhì)量和成功標準。具體的指標建立可以考慮多個維度，也可以根據(jù)平臺不同階段來制定。如果在遷移初期，可以將服務(wù)應(yīng)用數(shù)量，資源利用率等作為指標。如果大部分應(yīng)用已經(jīng)遷移成功，就可以考慮對指標做相應(yīng)的調(diào)整，例如：開發(fā)人員的滿意度，服務(wù)的可用性等等。

數(shù)字化運營指標體系的建立是思維模式的全面轉(zhuǎn)型，這要求團隊從用戶價值出發(fā)，應(yīng)用產(chǎn)品化思維，不斷改進和提升平臺和服務(wù)的產(chǎn)品力和競爭力，最終體現(xiàn)自身價值。

總結(jié)

大規(guī)模業(yè)務(wù)上云是一個大型系統(tǒng)工程，挑戰(zhàn)不僅僅在于技術(shù)，還需協(xié)調(diào)企業(yè)內(nèi)部眾多干系人，同時還要考慮自身平臺的建設(shè)和未來的演進。IT團隊可以充分利用以往自身優(yōu)勢，通過采集和分析應(yīng)用的數(shù)據(jù)，建立符合企業(yè)的業(yè)務(wù)上云策略和平臺，展現(xiàn)企業(yè)數(shù)字化轉(zhuǎn)型中賦能者的價值。