摘要：不過，根據近期的一份調查問卷表示，在所有的參與者之中，只有的組織對于他們的云遷移體驗感到非常滿意。在本文中，我們將探索整個云遷移周期中的四個階段。可以肯定的是，云遷移是一項不會真正結束的任務。

軟件組織正在快速地實施云技術，但遷移始終是一個無法回避的挑戰。哪些部分是需要你密切留意的？哪些應用程序更適合于進行遷移？如何對應用程序進行重構以適用于云端？經歷了這一轉變的先行者為我們留下了什么啟示？在這一系列文章中，你將從那些在幫助企業成功地遷移至云環境方面富有經驗的專家那里獲得實用的建議。這一領域應得到高度關注，我們希望你也能夠參與這方面的討論。

如果你正準備將應用程序搬到公有云環境，那么你正趕上了這一波潮流。根據451 Research的調查顯示，在2015年整個IT界有46%的成本都是針對非本地環境的系統，并且這一數字在今后三年內有望攀上50%[1]。企業仍然將節約成本視為購買云服務的主要原因，但越來越多的組織開始將“盡早推向市場”、“更好的可用性”以及“建立新的收益流”等戰略目標作為云實施的主要動力。不過，根據近期的一份調查問卷表示，在所有的參與者之中，只有27%的組織對于他們的云遷移體驗感到非常滿意。如何將云服務引入你的IT環境，并且成功地將應用與數據遷移到新的環境，這方面顯然還存在著很大的討論空間。

在本文中，我們將探索整個云遷移周期中的四個階段。可以肯定的是，（云）遷移是一項不會“真正”結束的任務。隨著你不斷地引入新的服務以解決新的業務問題，這一過程會不斷地重新啟動，只是其技術與目的可能會有所不同。以下這份清單也許能夠幫助你踏上這一旅程，但重要的是定義一份屬于你自己的清單，以適應于你的特定情況。

第一階段：評估

沒有一種云服務能夠適用于所有組織，許多組織一上來就試圖確定一個推薦的云環境，卻并不了解這一選擇是否與組織的成熟度、文化以及應用組合相匹配。那么，有哪些問題是你和這些潛在的提供商需要首先解答的呢？

1.你是否適用于這個云環境？云服務的提供商多如繁星，并非其中每一個都適合你的特定需求。有些云環境能夠在幾秒鐘之內創建幾千臺虛擬服務器，如果你的組織正好需要這樣的能力，那自然是一個好的選擇。有些云環境能夠提供服務周到、并且質量上乘的托管服務，但這些服務未必與你的運維模式相匹配。你需要考慮對你的組織來說哪些因素是最重要的，并且積極地嘗試一些在成本允許范圍之內的云提供商。請避免盲目地選擇某個特定云領域中的“領先者”，這一選擇可能會無意間對于你成功地交付服務帶來負面的影響。

2.你對于運行能力的需求是怎樣的？根據你希望遷移的應用的類型的不同，能夠選擇的提供商也有所不同。你的應用程序組合是否由大量現代的、適應云的應用程序組成，能夠充分利用大量廉價的、臨時的服務器或容器？你是否需要一個增長速度相對緩慢的池，但它能為你提供幾百個持久的計算資源？仔細考慮你的應用特性，確保所選擇的提供商能夠滿足你對于運算能力、存儲能力以及網絡吞吐需求的上限。

3.實際的成本是多少？“云成本”并不是在價格表上可以一目了然得出的數字。確保你對實際應用場景進行了建模，并且考慮對于跨區域分發、存儲備份、帶寬消耗、API調用等需求的針對性收費。此外，別忘了將項目上線、支持計劃以及創建新環境（例如性能測試與預發布環境）等這些在本地系統中不存在的成本也列為考慮因素。

4.應用的“缺陷”在何處，這些缺陷在遷移后是否依然存在？在經過對云提供商的首輪評估后，你可能已經建立了一個已預見的、或是實際存在的缺陷列表。因此，你應當與提供商進行交流，以尋找 a) 是否有一些未來的計劃能夠彌補這些缺陷，或者 b) 是否有些可行的臨時方案能夠彌補這些缺陷。一種可能的臨時方案是對于引起這種缺陷的基礎設施或是應用模式進行重構，讓其更好地適應云提供商提定義的模型。

5.你現有的工具能否適應這一環境？如果你在同一家公司已經待了一段時間，那么很可能已經習慣于某些現有的工具（及流程）了。如果你無法輕易地讓你的工具運行在所選擇的云環境中，請確保這個供應商所支持的工具集能夠取代你現有的工具，而不會使你感到不快。

第二階段：計劃

恭喜你，你已經為一個特定的業務領域選擇了一個云提供商。但現在才是最困難的部分：對遷移進行計劃！在設定這一遷移策略時，有哪些東西是你需要著重考慮的呢？

6.這次遷移包括的應用、功能和環境是怎樣的？在理想的情況下，較好不要將最復雜的、對業務影響較大的應用放在第一次云遷移的計劃中。但不管怎樣，請確保你為所有的應用列出一份詳細的清單，并指出其中最適合你遷移到云環境的選擇（無論是策略上還是戰術上）。

7.整個應用程序架構的結構是怎樣的？你的應用程序架構很可能會在云環境中產生變化。云服務器、數據服務和網絡與本地環境的行為相比都有所不同，因此你可能要對你的引用架構以及部署流程進行一些改進，讓它們能夠適合這個全新的世界。

8.新的環境可能會帶來哪些性能瓶頸？遷移到云環境就能夠保證讓應用程序的性能得到飛躍性的提高？絕非如此。如果你將一個一體性應用放到云端，并將它的各個部分分布到多個云服務中，這種方式可能會引入意外的延遲。而如果你的應用程序還與未遷移到云環境中的本地系統有所交集，由于兩者之間的遠距離連接，也有可能會導致性能問題。云服務器提供了多種不同類型及能力的系統，請確保為你的應用程序選擇必要的CPU、內存和磁盤能力，以滿足甚至超過之前的性能水平。

9.你的混合式集成計劃是什么？如果你認為能夠一次性將整個應用組合都遷移到云端，這種想法是不切實際的，甚至可能永遠不會發生。你需要將云環境視為你的現有環境的一種邏輯延伸，在此基礎上再考慮如何將現有的數據、網絡以及認證擴展到云端。

10.你是否已經確定了第一批應用者？云遷移過程或許會產生破壞性，因此重要的是在組織中找到合適的人，他們非常樂于幫助你定義新的標準，并在這次重要的轉換過程中為整個組織提供指導。

11.用戶如何訪問這一環境？你的同事大概已經有許多要記住的密碼了，如果你還要引入一整套全新的復雜的證書，用以訪問一系列關鍵的云服務，那是他們不想看到的。可以研究一下你的云提供商所提供的單點登錄（SSO）機制，對于任何打算采用云服務的項目，都將這一點作為一個前期設計的考慮因素。

12.你如何對員工進行培訓？讓你的整個團隊深入地了解新的云服務是非常重要的。你還要考慮到所有的受眾（例如項目經理、開發者、架構師、系統管理員等等），并制訂一些培訓資料，幫助員工適應新的云環境。

13.為了充分利用新的服務，需要對內部流程進行哪些改變？現有的硬件申請、變更管理、測試以及部署等已確定的過程或許在使用云服務時會產生某種變化。如果你打算在這個更敏捷、自服務的環境中照搬現有的流程，可能會失去你原本計劃進行云遷移時所構想的各種優點。因此，對于必須改變的部分，需要進行一次坦誠的評估。

14.你如何將新的代碼、數據和配置部署到新的環境？新的云服務未必能夠配合現有的系統管理工具，如果你正在使用現代配置管理工具，例如Chef或Ansible，或許有某種擴展能夠讓它在你的目的云環境中無縫地運行。請確保你對于部署和配置流程進行一次全面的模擬，并確定需要改進的地方。

15.在遷移后對服務進行運維的計劃是什么？遷移只是應用在新的云環境中運行的起步，如果需要進一步的改動，又該如何處理？如果發生了某種問題，如何進行問題診斷？你會使用何處監控工具用于分析關鍵性能指標？仔細觀察在云環境中應用請求的整個生命周期，考慮所有可能的調整與維護操作。

16.你是否設計了某種接入策略？如果你的應用程序用戶能夠忍受在遷移過程帶來的較長的停機時間，那么你或許能夠繼續使用某種簡單但具有破壞性的接入計劃。但如果你希望將停機時間降至較低，那么你必須考慮應用某些策略，在你搭建新環境的同時與主環境始終保持同步，直到將所有訪問都轉移至新的實例為止。

17.整個財務流程如何進行？沒錯，你很可能需要為云存儲付費，那么怎樣處理這部分費用呢？是計劃對每個使用云資源的業務部門分別收費，還是選擇從共用資金中抽取一部分進行全額支付？請確保你已經仔細地考慮了整個付費流程，在支付的同時記得獲取發票。

18.你是否已經進行了一次小規模的試用，并已對以上關注點建立了相應的計劃？無論如何，不要僅僅進行了一些書面原型設計就開始進入遷移過程。你需要進行實際操作，在目標云平臺上搭建應用程序并進行試用。在試用過程中熟悉整個環境的界面、功能以及各種限制，以這種方式獲得實踐性的知識。

第三階段：遷移

在經過了適當的前期計劃之后，遷移過程本身應當是波瀾不驚的。可以肯定的是，在實際的遷移過程進行時，總是會出現各種意想不到的情況。但如果你已經能夠解答以上這些問題，那么你的團隊應當有能力處理那些意外情況。

19.你如何將應用及數據分布在云環境中？有許多方法能夠將你的應用及數據保存在云端。對于中型應用來說，你可以選擇使用簡單的copy命令，通過網絡連接傳遞數據。但對于大型數據集來說，這可能會讓你的云提供商為此收取大量的帶寬費用，還會延長數據轉移時間。在這些情況下，可以采取一些更好的方式。 (a) 將數據壓縮后拷貝到目標云環境中的某個存儲位置，之后再將其轉移到最終的目的地。(b) 將物理數據磁盤轉移至云提供商處（前提是這個云環境支持這種操作）。

20.在傳輸過程中設置了哪些安全控制手段？在遷移過程中，你可能會用到預發布服務器或臨時對象存儲庫。請確保你已經完整地考慮了數據與訪問安全方面的問題，尤其是敏感的數據。

遷移虛擬機。將完整的VM進行遷移是一種將應用遷移至云端的方式，但根據這些VM如何在本地環境網絡中設置的情況，有可能會發生意料之外的副作用，例如這些VM所在的域、它們所用的磁盤類型，以及其它各種情況。雖然將VM進行“Lift and Shift”式的整體遷移通常來說是云遷移的最簡單方式，但它的復雜性往往走出想象。此外，這種方式不會促使你重新考慮應用程序的架構，以及為了應對云環境而對應用進行重構的策略。

遷移數據。你的數據可能會遷移至某個數據即服務環境，或某種自托管的數據庫實例中。請確保你了解提供商具備哪些可用的工具，以及這些工具在數據容量或結構方面存在著哪些限制。

遷移應用。如果你的應用程序部署工具能夠原生支持指向云基礎設施、容器或應用平臺，那說明這個工具功能比較出色。但你也可能屬于尚未具備這一能力的少數派！可能需要花上一些時間對你的本地工具進行一些重新配置，才能夠將代碼部署到云端，或者你也可以試用一些新的工具，以使整個流程更順暢。

重建元數據。許多公司總是表示，他們希望獲得云端的“可移植能力”，而試圖避免“綁定”在某個特定提供商的云平臺上。這個……祝你好運吧。雖說像虛擬機或應用程序的代碼這些資源可以相對比較容易地搬到云環境中，但環境元數據往往是特定于提供商的。每個云平臺的帳戶結構、用戶、權限、策略、負載均衡器等等都是不同的。請確保你了解如何在特定的目標云平臺上建立這些支持性配置信息。

第四階段：驗證

當遷移過程結束后，必須對應用程序進行全方面驗證，以確保它完全按預期的方式運行。

21.應用是否可訪問？這種測試很簡單，但重要的是要全方面地檢查應用服務的方方面面，確保用戶能夠訪問這些服務，而且內部的組件也能夠互相通信，并且沒有出現錯誤。

22.是否所有的數據都已經正確地傳輸到云端了？通過自動化的檢查，或者在最糟糕的情況下可以采取手工檢查，以檢驗是否事務型數據以及引用數據都已經成功地傳輸至云端。如果你的數據關系非常復雜，那么一旦遷移過程出錯，有可能會造成一連串的問題。

23.管理工具能否訪問云環境？正常情況下，在計劃階段就應該對這一點進行校驗了，但現在是最后一次機會，以驗證所有的管理工具都能夠訪問云環境中的應用程序，并且能夠對其進行監控，而不出現任何問題。

總結

每一天都有新的組織在成功地實施云服務，通過將應用程序遷移至這個更敏捷的環境，為他們的IT環境引入了新的活力。而在遷移過程中，不實際的期望最有可能導致整個過程的挫折。要擺脫這種焦慮，較好的方式是對組織的目標與意愿進行詳細的評估，對于計劃中的遷移流程中的各種問題給出實踐性的回答。