云遣返。反向云遷移。去云化（我們可能同意這個不應該流行）。

所有這些都表明，越來越多的企業正在擺脫超大規模云計算的束縛，因為它們希望重新獲得對長期高昂成本和基礎設施鎖定的控制。

無論您離開的原因是什么，將基礎設施（無論是整體還是部分）從云遷移到不同的生態系統的想法都是令人望而生畏的。但這不應該讓您望而卻步。一個聰明、深思熟慮的云退出策略考慮到云遣返的常見挑戰，將使流程更加精簡。

但這些常見的挑戰是什么？你又該如何緩解這些挑戰呢？

挑戰 1：采取分階段的方法

我們與之合作進行反向云遷移的許多客戶只想拿起他們的基礎設施并遷移它。但正如我們的游戲客戶之一、來自Gameye的 Andrew Walker所描述的那樣，基礎設施遷移“有點像試圖更換行駛中的車輛的輪子”。一次性拆下所有輪子將不可避免地導致災難。這就是為什么一個好的云退出策略不會一次性完成的原因。事實上，我們有一些客戶花了長達 18 個月的時間才完全從云中遷移出來。

當然，有些情況下這是不可能的。例如，如果你是一家匆忙建立基礎設施的初創公司，無法輕松地將其與超大規模環境分離。你需要先花時間在云端重新架構，以便分離，然后可能需要一次性提升和轉移基礎設施，然后才能進入下一個增長階段。

對于大多數可以采用分階段方法的公司來說，花時間真正了解您的基礎設施直至細節至關重要：

• 它是如何設計的？
• 集成了哪些產品？
• 您正在使用什么服務器？
• 您的每月賬單包含哪些內容？
• 哪些系統耦合如此緊密以致于無法位于不同的數據中心？

只有完成這項工作后，您才應該開始考慮替代環境。因為沒有這些知識，您就無法真正弄清楚新環境需要什么樣子，以及遷移到新平臺需要做什么。

但一般來說，為了在反向云遷移過程中盡可能減少影響，請確定基礎設施的哪一部分可能對日常運營影響最小，并首先遷移該部分。完成后，從過程中吸取教訓 - 看看哪些有效，哪些無效 - 然后進入遷移的下一階段。

在一篇詳細介紹其云退出策略的博客中，SaaS 提供商 Prerender 概述了分階段遷移的成功——“我們通過仔細規劃遷移的每個階段、在擴展之前測試每個實施階段以及在出現任何問題時輕松糾正任何錯誤來避免危險。這樣，我們可以節省服務器費用，同時將任何潛在風險降至最低?！?/p>

挑戰 2：引入新技術

超大規模云提供商因其將公司基礎設施鎖定在其平臺上的能力而臭名昭著。這意味著他們讓你很難在其他地方復制完全相同的環境 - 您可能需要聘請或外包專家來幫助你尋找或創建替代解決方案。

例如：

• 您正在使用 AWS 可擴展數據庫產品，該產品會自動為您選擇最佳實例類型。如果其他環境中沒有此產品，您將需要手動選擇正確的實例類型，但您可能不具備這樣做的知識或經驗。
• 同樣，一些超大規模云產品的設計使得您無法獲得替代解決方案的類似報價。例如，如果您曾經通過超大規模云提供商購買過平臺即服務產品，您就會知道設置和計費模型有多么復雜，以解釋每種產品的復雜性。以至于有些人通過幫助公司在超大規模云中建立環境并解讀每月賬單來獲得職業（和大量金錢）。如果您發現自己在超大規模環境中使用此類產品，我建議您聘請或與知道如何將超大規模云中的某種產品轉換為不同技術的人合作。

這里最大的收獲是要準備好探索新的設置方法甚至新技術。您可能無法在新環境中使用與超大規模相同的數據庫或應用程序。例如當 Remoby 從 AWS 遷移到我們的裸機環境時。

“總體而言，遷移過程對我們來說非常順利。我們面臨的唯一挑戰是，在 AWS 中，我們使用名為 Amazon EKS 的 k8s 即服務，并簡單地向其中添加了必要的節點，然后為我們的服務配置了 Helm 圖表。這與 servers.com 管理的 K8s 服務不太一樣，有一段時間我們準備放棄遷移的想法。幸運的是，我們設法與 servers.com 團隊合作，想出了一個解決方案，讓我們能夠快速而愉快地取得進展，” Remoby 首席技術官 Sergey Chernukhin 說。

Gameye 的 Andrew 也曾幫助游戲公司進行反向云遷移，他指出，有時“需要更改 UI，因為匹配器在另一個環境中的工作方式與在超大規模設置中不太一樣”。了解此類差異很重要，因為在這種情況下，如果游戲公司已經推出其游戲，游戲體驗可能會發生變化。

因此，在遷移后要做好對應用程序進行一些調整的準備。令人驚訝的是，即使在型號略有不同的同一供應商硬件之間移動工作負載也會導致應用程序的行為有所不同。

挑戰 3：合理規模

這與上面引入新技術的挑戰密切相關。所謂合適規模，是指當您離開超大規模環境時，您會轉移到適合您需求的服務器。這聽起來可能很明顯，但您很可能會在超大規模云中過度配置或配置不足您的生態系統。

如上所述，關鍵是要查看并充分了解與超大規模環境相關的統計數據，以便在遷移時可以選擇反映您實際需要的服務器。

如果您選擇與托管合作伙伴合作構建新環境，規劃過程應包括與該合作伙伴進行深入的概念驗證。這將使您有機會測試不同的機器設置，以確保您擁有最適合自己的機器設置。

挑戰 4：遷移數據

這也許是遷移難題中最難的部分。遷移數據可能需要幾天甚至幾周才能完成，具體取決于您的數據集有多大。對于一些公司來說，這段時間可能不是問題?；蛘吣踔量赡軟]有任何數據需要遷移，例如一些基于會話且不保留每個會話數據的游戲服務器。對于大多數其他全天候運行并使用數據庫存儲實時數據的企業來說，時間更為重要。

將數據遷移出超大規模環境主要有兩種方式。具體選擇哪種方式取決于數據集的類型和大小。

選項 1：物理備份

這涉及超大規模云提供商將您的數據上傳到磁盤，然后他們會將這些數據傳遞給您，以便您將其插入到新環境中。使用這種方法時，重要的是要記住，上傳到磁盤的數據是某個時間點的數據。假設數據在星期五上傳到磁盤，但直到星期一才添加到新環境中，那么您就丟失了兩到三天的數據。

也就是說，如果您要傳輸 TB 級甚至 PB 級的數據，它有時可能比虛擬傳輸數據更快。

選項 2：虛擬備份

顧名思義，這種方法涉及通過互聯網傳輸數據。如果數據集很大，通過互聯網傳輸數據可能比物理傳輸花費更長的時間。即使數據集較小，需要六個小時才能傳輸，您仍然有六個小時的更改在遷移過程中沒有被捕獲。然后，您需要繼續傳輸數據以覆蓋所有差異，直到您將其縮小到與客戶安排維護窗口以傳輸剩余數據的地步。

這個維護窗口點很重要。雖然我很想說，你可以在不影響客戶的情況下進行遷移，但這不現實。然而，接受這一點意味著你可以為此做好計劃，以將影響降到最低。無論你選擇哪種數據遷移路徑，都至少包括一次計劃維護，并提前向客戶明確傳達。

挑戰 5：重復成本

大多數遷移項目都遵循類似的流程。首先，您需要在新環境中啟動基礎設施，同時保留在超大規模云提供商中設置的主要生產環境。完成后，您需要將服務器上線 - 添加網絡、安裝操作系統和虛擬機管理程序（如果您在虛擬環境中）、構建應用程序堆棧并配置所有內容。

這意味著，根據您要遷移的生態系統的規模和復雜程度，您需要在一段時間內同時支付兩個基礎設施環境的費用。這是為了確保生態系統在新環境中正常運行，并讓您之前的基礎設施的遷移完全完成。

對于交易平臺FxGrow來說，“我們花了兩周時間才完全遷移到新的托管服務提供商。我們一直在向之前的托管服務提供商和新托管服務提供商付費，直到遷移完成”。他們的遷移時間框架由公司使用的關鍵應用程序 MetaTrader 5 決定，以確保在遷移期間停機時間盡可能短。

并行遷移是常態，因此，重復成本也是如此。但如果您沒有為此做好計劃，那么在遷移項目的某個階段，它當然會成為一項挑戰。為了避免這種情況，請在流程開始時就建立重復成本。當您制定遷移計劃和預算時，請在預算中列出一個項目，以說明交叉期。

如果您有需要持續正常運行時間的應用程序，請遵循 FxGrow 的示例并與該應用程序的提供商聯系，以獲取有關遷移時間的建議。

挑戰 6：識別與第三方的連接

大多數公司的基礎設施生態系統不僅由內部連接支持，還與多個第三方提供商相連。組織規模越大，多年來其發展就越有機，而且您很可能擁有您甚至不知道的第三方連接。

例如，對于大多數廣告技術提供商來說，他們的流量來自合作伙伴，因此如果他們更改其 IP 地址，他們必須通知其合作伙伴，并且可能會有一個圍繞他們轉移到新 IP 的 SLA。

作為遷移規劃過程的一部分，對所有第三方連接進行徹底審核并清晰地記錄下來。

如果您選擇與合作伙伴合作來托管您的新基礎設施環境（例如基礎設施即服務 (IaaS)提供商），他們將與您一起制定計劃，以確保每個第三方連接都成功遷移。

良好的規劃需要成為云退出戰略的核心

所有這六個挑戰都有一個首要主題——規劃。

遷移并不是公司經常做的事情。事實上，負責執行遷移的系統管理員可能多年都沒有做過遷移了。

這就是為什么成功地將云反向遷移到裸機、本地和主機托管需要您進行規劃，然后再次規劃，直到您覺得對可能出現的任何問題或突發事件都有應對措施。

無論您選擇哪條路線，都要準備好投入研究、時間和金錢來創建一個您確信會為您和您的客戶帶來最少停機時間的云退出策略。

隧道的盡頭是更大的獨立性、靈活性以及更為舒適的基礎設施賬單。