如果有一天，您被告知遷移到 AWS/GCP/Azure/任何其他云提供商怎么辦？輕描淡寫可能會帶來一些壓力，對嗎？

在我的職業生涯中，我見過不少遷移，在這篇文章中，我想分享一些想法，以幫助 DevOps 工程師、架構師、經理或任何其他可能參與此類遷移的人。我專注于遷移到 AWS 主要是因為我在這個主題上有專長并且因為它相當普遍，但我認為這些經驗適用于任何其他云提供商。對于這種情況，我將介紹從本地到云的遷移，因為這些類型的遷移（在我看來）比云到云的遷移要困難得多。我還將分享我自己對遷移的注意事項的看法。但請通過批判性思維過濾它們，并記住每個人都有自己的背景和經驗。對一個人有利的事情可能對另一個人不利。

什么是云遷移？

讓我們從定義什么是遷移開始。你怎么知道它是否是遷移？我喜歡下面的定義：

云遷移是將數據中心的功能轉移到 IaaS 提供商的過程。?

“能力”是關鍵詞。企業不會遷移服務器/虛擬機/硬件/數據或其他任何東西。企業遷移其能力。

有七種遷移策略（或七個 Rs）：重新定位、重新托管（提升和轉移）、重新平臺、重新購買、重新架構/重構、保留和退休。

例如，我曾見過一家公司正在開發一種新產品來取代現有的本地托管產品。該產品從一開始就設計為架構良好且云原生，并將托管在云中。是遷移還是綠地項目類型？從上面的定義，我們可以說這是一個遷移。這是遷移的重構策略。

如果我們購買新的 SaaS 訂閱而不是我們在本地托管的某些軟件怎么辦？這也是一種遷移：一種回購策略。

讓我們更深入地研究這七種遷移策略：

搬家。我們在本地托管一些工作負載，然后將它們按原樣遷移到云端。這在有限的情況下是可能的；當我們遷移與云無關的工作負載或平臺可能是云原生時。示例：將 Kubernetes 集群從本地遷移到云端或使用 VMware Cloud 遷移 VMware 機器。

重新托管。這也稱為提升和轉移。我們將本地虛擬機/服務器轉換為云中的虛擬機。示例：使用 CloudEndure 將本地虛擬機遷移到 EC2 實例，或創建 EC2 實例，安裝軟件并應用與本地相同的配置。

重新平臺化。我們在不重新構建系統的情況下將工作負載遷移到云原生平臺。示例：將 PostgreSQL 遷移到 AWS RDS 或將 Docker 容器遷移到 ECS。

回購。我們用 SaaS 替換了一些自定義/遺留系統。示例：用 SendGrid 替換自定義本地電子郵件系統或用 Salesforce 替換 CRM。

重新設計。我們將您的應用程序架構更改為云原生并使用托管云服務。這還包括從頭開始重建。示例：更改您的應用程序的代碼以將文件上傳到 S3 而不是本地存儲或將應用程序容器化并遷移到 ECS。

退休。如果不需要，我們決定消除一部分工作量。示例：不再需要日志服務器，因為遷移的應用程序使用 CloudWatch。

保留。我們將其留在本地。通常，這是暫時的。示例：具有大量功能和自定義功能的龐大 Oracle 數據庫由于巨大的成本而沒有遷移到 AWS。它決定將其保留在本地，直到在現代化階段被另一個解決方案取代。

我喜歡下圖，它顯示了每種遷移類型的高級階段。它可能是處理遷移的有用備忘單。

遷移禁忌

在執行遷移時，我不建議執行以下操作：

遷移太快。企業可能會想，“我們必須快速遷移到云端。讓我們現在就做升降機！最好不要馬上開始。您確定重新托管策略真的會比其他策略更快嗎？在一個實例中，我們嘗試遷移本地 VM，但沒有成功，因為機器上的操作系統很舊。某些操作系統級別的依賴項在 AWS 的硬件上不起作用。這需要大量的配置工作、自定義代碼和測試，而最初的估計是完全錯誤的。它最終證明是一個重新平臺。

評估你所擁有的，分析它，分析商業案例并思考。在這項工程工作中，我們應該靜下心來，三思而后行。

沒有明確目標的遷移。你為什么要移民？如果您無法回答問題，您可能需要找到答案或根本不遷移。我見過企業希望遷移到云以降低成本的情況。他們在沒有進行總成本分析的情況下執行了直接遷移。只有在事后他們才意識到它的成本甚至比在托管中心時還要高。此遷移可能被認為是不成功的。

為避免這種情況，定義明確的目標并定義實現這些目標的目標狀態。如果成本是驅動因素，請進行適當的計算并制定相應的計劃。當您計劃目標狀態時，成本優化將是主要關注的事情。如果可用性是原因，請對其進行衡量，定義 SLO 并關注目標狀態下的可用性。

黑盒遷移。不要將遷移的工作負載視為黑盒。了解您遷移的具體內容、它有什么技術要求、它有什么依賴關系以及它如何工作幾乎是至關重要的。該信息將使您能夠選擇正確的工作負載遷移策略。如果不這樣做，您很有可能會選擇錯誤的路徑并且結果會丟失。捕獲有關系統的信息是規劃時最重要的任務。

不要忘記架構良好的. 遷移是有壓力的。這就是為什么人們傾向于嘗試在盡可能短的時間內快速完成它，專注于唯一的事情：讓一切盡快在云中運行。他們擱置了結構良好的框架支柱。這是個錯誤; 它可能會導致一系列不同嚴重程度的負面后果。不要忽視結構良好的框架支柱，否則在潛在問題或風險已經具體化之前，您不會知道它們。

一切都使用一種策略。為所有工作負載制定一個總體計劃總是很容易的。例如，決定進行直接遷移，然后將所有內容重新托管在云中。但是，如果某些東西可以退役呢？如果可以不費吹灰之力地對某些組件進行平臺改造會怎樣？通過分析工作負載的所有組件并為每個組件確定獨特的策略，您將節省大量資源。收集數據并妥善計劃。

云遷移做的

執行云就緒評估。如果一個人遷移到新地點，他們應該考慮：

• 氣候會有所不同
• 該位置使用的語言可能不同
• 生活成本會有所不同，而且可能會更貴

當一家公司遷移到云端時，他們應該提出的問題包括：

• 我們是否考慮了所有的風險？
• 必須更改什么才能使工作負載真正起作用？
• 我們是否擁有所有工作所需的人力資源？
• 我有完成所有事情的預算嗎？

Cloud Readiness Assessment 是關于公司中不同流程的長篇訪談，用于確定公司是否已準備好在云中生活。它基于 Cloud Adoption Framework (CAF)，讓我們了解應該更改哪些內容才能成功進行遷移。AWS 有一個涵蓋所有這些的云就緒評估工具。我強烈建議您對考慮遷移的所有工作負載使用此過程。

創建一個商業案例。描述業務案例。遷移的驅動因素是什么？遷移解決了哪些問題？移民應該達到什么目標？具體一點：如果您打算降低成本，則計算總和。如果你打算提高可用性，那么定義一個明確的 SLO。這將是您遷移的第一推動力。所有其他工件都應該基于它。

自動發現和數據收集。使用自動數據收集和分析來創建遷移組合。不要將您的分析基于手動創建的電子表格或口頭交流。讓機器收集有關庫存和使用統計信息的數據。您收集的數據越精確越好。在大多數情況下，AWS Migration Evaluator 服務將幫助您做到這一點。

投資組合管理。創建要遷移的工作負載組合，對其進行分析，為每個工作負載選擇遷移策略，為試點/第一波遷移選擇一些，估計時間表并準備計劃。之后執行遷移。重復直到遷移組合為空。共享數據。讓主題專家對其進行審查。

找到了 CCoE。這是上述 CAF 的一部分。在執行遷移之前，創建一個負責制定戰略并定義云中良好生活標準的人員團隊：卓越云中心。它應該包括具有各種主題專業知識的人員，包括管理、運營、平臺、人員、財務以及在云中使用或提供服務的所有其他部門。這些人會為遷移準備一個登陸區，為登陸區準備硬政策和軟政策；為公司在云中的生活做準備。不要害怕重新審視任何政策。 隨著新因素的出現，做出改變。

良好架構的框架審查 (WAFR)。在遷移浪潮期間和之后進行架構完善的框架審查 (WAFR)。這將使你避免愚蠢的錯誤，并從技術角度對你所做的事情有一個高層次的概述。

現代化計劃。準備現代化計劃和遷移計劃。遷移不是故事的結局。要在云中發揮作用，您必須進行架構完善的審查和現代化改造。第一次現代化可能是巨大的；這就是為什么提前計劃和安排預算和資源很重要。如果不這樣做，將導致運營成本增加，而不是成本降低。

概括

如果我們想降低與遷移相關的風險并減輕壓力，我們不會倉促行事。您可能認為倉促行事會節省您的時間，其他問題會在以后得到解決，但經驗告訴我們這是錯誤的。最有可能的結果是，您將最終解決在最緊張的情況下遇到的所有問題：當您切換到新的基于云的生產環境時。不是經過深思熟慮和提前解決問題，而是在脅迫下做出選擇。此處必須應用正確的工程原理。拿起一座橋并將其從一條河流中移到另一條河流上是行不通的。遷移成功的關鍵是衡量、分析、設計和計劃。將工作負載遷移到云端很困難，但我希望這些該做的和不該做的會讓事情變得更容易。