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

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

什么是云遷移？

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

云遷移是將數(shù)據(jù)中心的功能轉(zhuǎn)移到 IaaS 提供商的過程。?

“能力”是關(guān)鍵詞。企業(yè)不會遷移服務(wù)器/虛擬機(jī)/硬件/數(shù)據(jù)或其他任何東西。企業(yè)遷移其能力。

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

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

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

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

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

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

重新平臺化。我們在不重新構(gòu)建系統(tǒng)的情況下將工作負(fù)載遷移到云原生平臺。示例：將 PostgreSQL 遷移到 AWS RDS 或?qū)?Docker 容器遷移到 ECS。

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

重新設(shè)計。我們將您的應(yīng)用程序架構(gòu)更改為云原生并使用托管云服務(wù)。這還包括從頭開始重建。示例：更改您的應(yīng)用程序的代碼以將文件上傳到 S3 而不是本地存儲或?qū)?yīng)用程序容器化并遷移到 ECS。

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

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

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

遷移禁忌

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

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

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

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

為避免這種情況，定義明確的目標(biāo)并定義實現(xiàn)這些目標(biāo)的目標(biāo)狀態(tài)。如果成本是驅(qū)動因素，請進(jìn)行適當(dāng)?shù)挠嬎悴⒅贫ㄏ鄳?yīng)的計劃。當(dāng)您計劃目標(biāo)狀態(tài)時，成本優(yōu)化將是主要關(guān)注的事情。如果可用性是原因，請對其進(jìn)行衡量，定義 SLO 并關(guān)注目標(biāo)狀態(tài)下的可用性。

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

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

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

云遷移做的

執(zhí)行云就緒評估。如果一個人遷移到新地點(diǎn)，他們應(yīng)該考慮：

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

當(dāng)一家公司遷移到云端時，他們應(yīng)該提出的問題包括：

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

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

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

自動發(fā)現(xiàn)和數(shù)據(jù)收集。使用自動數(shù)據(jù)收集和分析來創(chuàng)建遷移組合。不要將您的分析基于手動創(chuàng)建的電子表格或口頭交流。讓機(jī)器收集有關(guān)庫存和使用統(tǒng)計信息的數(shù)據(jù)。您收集的數(shù)據(jù)越精確越好。在大多數(shù)情況下，AWS Migration Evaluator 服務(wù)將幫助您做到這一點(diǎn)。

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

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

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

現(xiàn)代化計劃。準(zhǔn)備現(xiàn)代化計劃和遷移計劃。遷移不是故事的結(jié)局。要在云中發(fā)揮作用，您必須進(jìn)行架構(gòu)完善的審查和現(xiàn)代化改造。第一次現(xiàn)代化可能是巨大的；這就是為什么提前計劃和安排預(yù)算和資源很重要。如果不這樣做，將導(dǎo)致運(yùn)營成本增加，而不是成本降低。

概括

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