隨著云計算的廣泛采用，企業(yè)變得比以往更具活力。如今，許多公司的業(yè)務正在向云計算遷移。選擇云提供商幾乎總是確保長期供應商鎖定。無論是工程師很難對應用層進行適當?shù)某橄蠛透爬?，或者應用程序?shù)據(jù)的大小使得遷移變得困難，所以遷移到基于云計算的系統(tǒng)是一項非常具有挑戰(zhàn)性的任務。在從本地數(shù)據(jù)中心上的自托管系統(tǒng)遷移到云中時，應考慮以下挑戰(zhàn)（ydotpub）。

（1）不當?shù)某橄?/p>

在新環(huán)境中抽象失敗是向云遷移過程中面臨的最大挑戰(zhàn)之一。通常，應用程序的體系結(jié)構(gòu)取決于其下面的一些本地化API。這在大規(guī)模運行的系統(tǒng)中特別常見，因為特定的問題只能在一定的規(guī)模中才能看得見。工程團隊經(jīng)常使用一些類似黑客的程序和補丁來修復系統(tǒng)，但是黑客會在系統(tǒng)遷移過程中進行攻擊。定期代碼審核在一定程度上有助于減輕這些問題。

（2）部署過程中的差異

所有的現(xiàn)代持續(xù)集成和持續(xù)交付(CI/CD平臺都支持多個云提供商，但這還不夠。具有復雜設置和啟動過程的應用程序通常需要人工干預部署。近幾年來，這一點通過使用Puppet，Chef和Ansible等工具在很大程度上可以實現(xiàn)自動化。但是這種自動化通常與供應商特定的API聯(lián)系在一起，這些API需要配置，監(jiān)控和拆卸服務器。但是，除非工程團隊花時間自己構(gòu)建，否則這些API不適合小型的本地數(shù)據(jù)中心（ydotpub）。

（3）重新架構(gòu)

現(xiàn)代應用程序分布在多個不同區(qū)域的多個數(shù)據(jù)中心。這是遷移到基于云計算的部署的主要好處之一。企業(yè)正在逐漸從單一的應用程序基礎轉(zhuǎn)變?yōu)榛谖⒎盏姆椒?。一個本地數(shù)據(jù)中心遷移到多地點部署需要適當?shù)刂匦聵?gòu)建應用程序。這意味著除了開發(fā)新版本之外，工程團隊還必須關心現(xiàn)有的安裝情況。遷移系統(tǒng)的關鍵部分經(jīng)常會導致停機，新的部署仍然不能保證在首次運行中取得成功。建議在出現(xiàn)問題時對原有部署進行故障切換，以防出錯。大型遷移可能需要幾個月的時間才能完成，并可能需要額外的員工來完成。

（4）傳輸大量的數(shù)據(jù)

想象一下，必須將移動社交應用Instagram的業(yè)務從AWS云平臺遷移到微軟Azure云平臺上。傳輸這些海量的圖像本身就是一項艱巨的任務。認為有時最好的措施是物理運送數(shù)據(jù)，而不是將數(shù)據(jù)上傳到云計算提供商，這種行為并不瘋狂。這兩種策略都經(jīng)過多年的分析，行業(yè)仍然沒有確定哪個策略才是正確的做法。這個問題不是取決于正在遷移的系統(tǒng)的類型，因此不能通過僅僅改變架構(gòu)來緩解。一些企業(yè)從一開始就選擇使用云存儲，即使涉及到基于本地數(shù)據(jù)中心的部署。當數(shù)據(jù)不太活躍或者不需要立即處理時，這種方法特別普遍。Amazon S3存儲已經(jīng)成為許多企業(yè)多年來的可靠存儲解決方案，并且一直是這一領域的領跑者。

如今的許多企業(yè)都喜歡快速收購和出售市場型的初創(chuàng)公司。遷移到云端或從一個提供商轉(zhuǎn)換到另一個提供商是這類業(yè)務的非常普遍的任務。通常情況下，需要使用當前的一套應用程序來制作新獲得的應用程序。有時，新產(chǎn)品轉(zhuǎn)移到新的云計算提供商或從云端遷移到自我托管的設置，以利用已經(jīng)購買的合同或硬件，就像Instagram遷移到Facebook的數(shù)據(jù)中心，這實質(zhì)上形成了Facebook的私有云平臺。

無論是什么原因，遷移到基于云計算的系統(tǒng)是許多組織的必要條件。最好是以一種與供應商無關的方式編寫應用程序，并在適當?shù)牡胤竭M行適當?shù)某橄?，以便縮短可能長達幾個月的考驗過程。

企 業(yè) 上 云

企業(yè)“上云”計劃

“企業(yè)上云”是指企業(yè)通過高速互聯(lián)網(wǎng)絡，將企業(yè)的基礎系統(tǒng)、業(yè)務、平臺部署到云端，利用網(wǎng)絡便捷地獲取計算、存儲、數(shù)據(jù)、應用等服務，有利于降低企業(yè)信息化建設成本，構(gòu)建工業(yè)互聯(lián)網(wǎng)創(chuàng)新發(fā)展生態(tài)，促進實現(xiàn)制造業(yè)全過程、全產(chǎn)業(yè)鏈和產(chǎn)品全生命周期的優(yōu)化，提升制造業(yè)與互聯(lián)網(wǎng)融合發(fā)展水平。

“企業(yè)上云”步驟主要分為上云前的規(guī)劃、設計，上云的實施以及上云后的驗證和維護。具體“企業(yè)上云”流程如下：

1 上云規(guī)劃

1、信息收集

“企業(yè)上云”需要進行嚴謹細致的調(diào)研工作，需要收集硬件及網(wǎng)絡環(huán)境信息、現(xiàn)有及將來可能增加的業(yè)務各類需求、系統(tǒng)配置信息、應用系統(tǒng)信息、數(shù)據(jù)風險等。

2、需求評估

從業(yè)務需求的角度分析各業(yè)務的目前現(xiàn)狀、存在的問題、是否可以云化、業(yè)務未來的發(fā)展需求，定制對各個業(yè)務系統(tǒng)遷移的目標。

從系統(tǒng)的角度分析各系統(tǒng)的目前現(xiàn)狀，包括了主機、存儲、網(wǎng)絡及安全，分析系統(tǒng)存在的問題，根據(jù)評估結(jié)果進行規(guī)劃。

從企業(yè)自身信息化水平的角度進行分析。對于有信息化基礎并擁有信息系統(tǒng)硬件環(huán)境、維護開發(fā)隊伍的企業(yè)，可根據(jù)企業(yè)發(fā)展規(guī)劃，逐步進行新、老系統(tǒng)遷移。對于無信息化基礎企業(yè)，以企業(yè)迫切需解決問題為導向，加快相關應用上線。

3、應用分析

應用分析是成功上云，降低業(yè)務停滯時間的關鍵。根據(jù)業(yè)務的負載、特性、復雜性、關聯(lián)性分析確定并量化業(yè)務上云風險可能對業(yè)務造成的影響及損失，以確定業(yè)務上云的優(yōu)先分批范圍及上云策略。

4、風險分析

根據(jù)收集到的相關信息對目前系統(tǒng)進行業(yè)務上云的風險分析，分析各種潛在危險并針對可能發(fā)生的危險事件，采取相應措施。

5、上云策略

“企業(yè)上云”策略可遵循：統(tǒng)籌規(guī)劃、分步實施、由易而難、由簡單到復雜。一般順序：（1）獨立應用的系統(tǒng)，如郵件系統(tǒng)、合同系統(tǒng)；（2）應用堆疊的應用系統(tǒng)，如辦公OA；（3）存在業(yè)務依賴的系統(tǒng)，如CRM、ERP、MES系統(tǒng)；

2 上云設計

1、上云計劃

企業(yè)現(xiàn)有的信息系統(tǒng)分為業(yè)務高度依賴型、業(yè)務依賴型和非業(yè)務依賴型三類：

（1）7*24小時業(yè)務高度依賴的生產(chǎn)系統(tǒng)，遷移只能在線時間，遷移策略為：“在線遷移”；

（2）非7*24小時業(yè)務依賴的生產(chǎn)系統(tǒng)，遷移時可以接受一定的離線實現(xiàn)時間，遷移策略為：“離線遷移”；

（3）非業(yè)務依賴性的生產(chǎn)系統(tǒng)遷移可接受較長的離線時間，遷移策略是“分批次遷移”。

根據(jù)以上原則，綜合考慮各應用系統(tǒng)及相關設備的調(diào)研分析情況，制定出詳細的上云計劃。

2、方案設計

方案包括：上云實施方案、應用上云方案、數(shù)據(jù)同步方案、上云回退方案等。

3 上云實施

1、模擬上云

正式上云前模擬一個批次的業(yè)務遷移（非正式遷移，業(yè)務不割接）。驗證業(yè)務遷移的及時有效和正確率；針對模擬過程發(fā)現(xiàn)各類問題進行修正；改進業(yè)務遷移的流程和工作手冊，以滿足業(yè)務的實際需要。

2、系統(tǒng)測試

模擬上云完成后對模擬上云的業(yè)務進行一次系統(tǒng)測試，以確定業(yè)務遷移到云環(huán)境中后能夠滿足業(yè)務需求。

（1）性能測試，包括：上云后系統(tǒng)的應用性能測試；上云后系統(tǒng)的網(wǎng)絡性能測試；上云后系統(tǒng)軟件版本性能測試等。

（2）壓力測試，包括：對上云后系統(tǒng)進行壓力測試，并取得關鍵性能指標達到設計目標；從分支機構(gòu)發(fā)起執(zhí)行版本驗證測試及必要的壓力測試等。

（3）業(yè)務功能，包括：上云后系統(tǒng)與老系統(tǒng)的連接測試；對上云后系統(tǒng)運行批處理測試；完成數(shù)據(jù)同步后，執(zhí)行批處理測試；完成數(shù)據(jù)同步后，從分支機構(gòu)發(fā)起執(zhí)行高風險業(yè)務功能的測試等；

（4）系統(tǒng)連接性測試，包括：上云后對外圍系統(tǒng)，進行全面的連接測試；發(fā)現(xiàn)問題，提出整改目標；上云后系統(tǒng)與網(wǎng)絡的連接測試等。

3、數(shù)據(jù)備份

正式上云前，為確保業(yè)務數(shù)據(jù)的完整性、降低上云風險，需要將業(yè)務系統(tǒng)及數(shù)據(jù)進行備份，為提高抗風險能力，建議采用多種備份方式、多分備份數(shù)據(jù)的方式對業(yè)務系統(tǒng)及數(shù)據(jù)進行備份。

4、上云部署

根據(jù)確定的業(yè)務上云方案，實施業(yè)務上云；根據(jù)業(yè)務上云方案測試遷移效果，并對業(yè)務上云后的系統(tǒng)參數(shù)和性能進行調(diào)整，使之滿足業(yè)務系統(tǒng)的需要，并投入實際使用。

4 上云驗證

1、上云評估

根據(jù)確定的業(yè)務上云方案，正式實施業(yè)務上云；根據(jù)業(yè)務上云方案測試業(yè)務上云效果，并對業(yè)務上云后的系統(tǒng)參數(shù)和性能進行調(diào)整，使之滿足業(yè)務系統(tǒng)的需要，并投入實際使用。

2、業(yè)務檢查

業(yè)務正式上云后，進行一定時間的試運行，檢測業(yè)務上云后是否對業(yè)務造成影響，對出現(xiàn)的問題進行及時的解決。

3、問題優(yōu)化

根據(jù)云上系統(tǒng)監(jiān)控數(shù)據(jù)和業(yè)務系統(tǒng)發(fā)展規(guī)劃，優(yōu)化業(yè)務系統(tǒng)架構(gòu)，消除性能瓶頸和風險，保障客戶業(yè)務平穩(wěn)運行。

5 云上維護

1、運行維護

為上云企業(yè)提供全面專業(yè)的運維/運營服務，進行資源開通、輔助上云、平臺監(jiān)控、故障排查、容量管理、升級重保、健康檢查、性能報告等服務科目，可提供駐場服務、巡場服務和遠程服務三種服務類型。

2、場景培訓

針對企業(yè)客戶使用場景，幫助企業(yè)熟悉和掌握云上業(yè)務操作和云服務技術(shù)，培養(yǎng)企業(yè)使用習慣，解答企業(yè)用戶使用過程中遇到的各類問題。

覺得不錯，請點贊↓↓↓

隨著云計算的廣泛采用，企業(yè)變得比以往更具活力。如今，許多公司的業(yè)務正在向云計算遷移。選擇云提供商幾乎總是確保長期供應商鎖定。無論是工程師很難對應用層進行適當?shù)某橄蠛透爬?，或者應用程序?shù)據(jù)的大小使得遷移變得困難，所以遷移到基于云計算的系統(tǒng)是一項非常具有挑戰(zhàn)性的任務。在從本地數(shù)據(jù)中心上的自托管系統(tǒng)遷移到云中時，應考慮以下挑戰(zhàn)（ydotpub）。

（1）不當?shù)某橄?/p>

在新環(huán)境中抽象失敗是向云遷移過程中面臨的最大挑戰(zhàn)之一。通常，應用程序的體系結(jié)構(gòu)取決于其下面的一些本地化API。這在大規(guī)模運行的系統(tǒng)中特別常見，因為特定的問題只能在一定的規(guī)模中才能看得見。工程團隊經(jīng)常使用一些類似黑客的程序和補丁來修復系統(tǒng)，但是黑客會在系統(tǒng)遷移過程中進行攻擊。定期代碼審核在一定程度上有助于減輕這些問題。

（2）部署過程中的差異

所有的現(xiàn)代持續(xù)集成和持續(xù)交付(CI/CD平臺都支持多個云提供商，但這還不夠。具有復雜設置和啟動過程的應用程序通常需要人工干預部署。近幾年來，這一點通過使用Puppet，Chef和Ansible等工具在很大程度上可以實現(xiàn)自動化。但是這種自動化通常與供應商特定的API聯(lián)系在一起，這些API需要配置，監(jiān)控和拆卸服務器。但是，除非工程團隊花時間自己構(gòu)建，否則這些API不適合小型的本地數(shù)據(jù)中心（ydotpub）。

（3）重新架構(gòu)

現(xiàn)代應用程序分布在多個不同區(qū)域的多個數(shù)據(jù)中心。這是遷移到基于云計算的部署的主要好處之一。企業(yè)正在逐漸從單一的應用程序基礎轉(zhuǎn)變?yōu)榛谖⒎盏姆椒?。一個本地數(shù)據(jù)中心遷移到多地點部署需要適當?shù)刂匦聵?gòu)建應用程序。這意味著除了開發(fā)新版本之外，工程團隊還必須關心現(xiàn)有的安裝情況。遷移系統(tǒng)的關鍵部分經(jīng)常會導致停機，新的部署仍然不能保證在首次運行中取得成功。建議在出現(xiàn)問題時對原有部署進行故障切換，以防出錯。大型遷移可能需要幾個月的時間才能完成，并可能需要額外的員工來完成。

（4）傳輸大量的數(shù)據(jù)

想象一下，必須將移動社交應用Instagram的業(yè)務從AWS云平臺遷移到微軟Azure云平臺上。傳輸這些海量的圖像本身就是一項艱巨的任務。認為有時最好的措施是物理運送數(shù)據(jù)，而不是將數(shù)據(jù)上傳到云計算提供商，這種行為并不瘋狂。這兩種策略都經(jīng)過多年的分析，行業(yè)仍然沒有確定哪個策略才是正確的做法。這個問題不是取決于正在遷移的系統(tǒng)的類型，因此不能通過僅僅改變架構(gòu)來緩解。一些企業(yè)從一開始就選擇使用云存儲，即使涉及到基于本地數(shù)據(jù)中心的部署。當數(shù)據(jù)不太活躍或者不需要立即處理時，這種方法特別普遍。Amazon S3存儲已經(jīng)成為許多企業(yè)多年來的可靠存儲解決方案，并且一直是這一領域的領跑者。

如今的許多企業(yè)都喜歡快速收購和出售市場型的初創(chuàng)公司。遷移到云端或從一個提供商轉(zhuǎn)換到另一個提供商是這類業(yè)務的非常普遍的任務。通常情況下，需要使用當前的一套應用程序來制作新獲得的應用程序。有時，新產(chǎn)品轉(zhuǎn)移到新的云計算提供商或從云端遷移到自我托管的設置，以利用已經(jīng)購買的合同或硬件，就像Instagram遷移到Facebook的數(shù)據(jù)中心，這實質(zhì)上形成了Facebook的私有云平臺。

無論是什么原因，遷移到基于云計算的系統(tǒng)是許多組織的必要條件。最好是以一種與供應商無關的方式編寫應用程序，并在適當?shù)牡胤竭M行適當?shù)某橄?，以便縮短可能長達幾個月的考驗過程。