本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

程序觀點

程序帶來一致性，但也會演進，而且由於每個專案都是獨一無二的，因此容易變更。當您重複執行程序時，您將識別差距和改進空間，以便在失敗、學習、採用和反覆運算時增加巨大的優勢。這些變更可能會導致專案和業務在未來可以利用的新想法或創新，這為成長提供了促進品質和團隊信心的促進因素。

遷移中的程序可能很複雜，因為它們跨越了先前可能尚未連結的技術和邊界。此觀點提供大型遷移特定需求的程序和指導。

為您的大型遷移做好準備

下列各節概述了確保您以明確的方向開始遷移之旅所需的核心原則，以及利益相關者對其成功至關重要的認可。

定義業務驅動因素並溝通時間表、範圍和策略

接近大型遷移到 時 AWS，您會快速發現遷移伺服器的方法有很多種。例如，您可以執行下列操作：

若要判斷正確的遷移路徑，請務必從業務驅動因素向後工作。如果您的最終目標是提高業務敏捷性，您可能會偏好第二個模式，這涉及更多層級的轉型。如果您的目標是在年底之前清空資料中心，則由於重新託管提供的速度，您可以選擇重新託管工作負載。

大型遷移通常涉及廣泛的利益相關者，包括下列項目：

識別遷移的業務驅動因素至關重要，並在文件中包含該清單，例如遷移計畫成員可存取的專案章程。此外，建立符合您目標業務成果的關鍵績效指標 (KPIs)。

例如，一位客戶想要在 12 個月內遷移 2，000 部伺服器，以實現他們清空資料中心的目標業務成果。不過，他們的安全團隊未符合此目標。結果導致數月的技術爭論是否錯過資料中心關閉日期，但進一步現代化應用程式，或最初重新託管以啟用及時的資料中心關閉，然後現代化應用程式 AWS。

定義明確的呈報路徑，以協助移除封鎖程式

大型雲端遷移計劃通常涉及廣泛的利益相關者。畢竟，您可能會變更已經在內部部署託管幾十年的應用程式。每個利益相關者都有衝突的優先順序是很常見的。

雖然所有優先順序都可能驅動價值，但計劃可能會有有限的預算和定義的目標結果。管理各種利益相關者並專注於目標業務成果可能具有挑戰性。當您將挑戰乘以遷移範圍內的數百或數千個應用程式時，此挑戰會更為複雜。此外，利益相關者可能會向具有其他優先事項的不同領導團隊報告。考慮到這一點，除了明確記錄目標業務成果之外，請務必定義明確的呈報矩陣，以協助移除封鎖程式。這可以節省大量時間，並協助讓各個團隊符合共同目標。

其中一個範例示範這是一家金融服務公司，其目標是在 12 個月內清空其主要資料中心。沒有明確的命令或呈報路徑，這會導致利益相關者制定他們所需的遷移路徑，無論時間和預算限制為何。在向 CIO 呈報之後，已設定明確的命令，並提供機制來請求必要的決策。

將不必要的變更降至最低

變更很好，但變更越多表示風險越大。當大型遷移的業務案例獲得核准時，最有可能是推動此計畫的目標業務成果，例如在特定日期之前離開資料中心。雖然技術人員通常想要重寫所有內容以充分利用 AWS 服務，但這可能不是您的業務目標。

一位客戶專注於公司整個 Web 規模基礎設施的兩年遷移 AWS。他們建立了兩週的規則作為一種機制，以防止應用程式團隊花費數月的時間重寫其應用程式。透過使用兩週規則，客戶能夠以一致的節奏維持長期遷移，此時必須移動數百個應用程式多年。如需詳細資訊，請參閱部落格文章：兩週規則：在 10 天內重構雲端的應用程式。

我們建議將不符合業務成果的任何變更降至最低。相反地，請建置機制來管理未來專案中的這些額外變更。

提早記錄end-to-end程序

在大型遷移計劃的早期階段，記錄完整的遷移程序和所有權指派。本文件對於教育所有利益相關者如何執行遷移及其角色和責任非常重要。文件也會協助您了解可能發生的問題，並在您進行遷移時提供程序的更新和反覆運算。

在開發遷移專案期間，請確保了解任何現有的程序，並清楚記錄整合點和相依性。包括需要與外部程序擁有者互動的地方，包括變更請求、服務請求、廠商支援，以及網路和防火牆支援。了解程序後，建議您在負責、負責、諮詢、告知 (RACI) 矩陣中記錄所有權，以追蹤不同的活動。若要完成程序，請識別遷移每個步驟中涉及的時間表，以建立倒數計時計劃。倒數計時計劃通常從工作負載遷移切換日期和時間向後運作。

此文件方法適用於遷移至 的多國家電公司，在不到一年的時間內 AWS 成功地離開四個資料中心。他們有六個不同的組織團隊和多個涉及的第三方，這引入了管理開銷，導致back-and-forth決策和實作延遲。 AWS Professional Services 團隊與客戶及其第三方一起識別遷移活動的關鍵程序，並與各自的擁有者一起記錄。產生的 RACI 矩陣由所有參與的團隊共用和同意。使用 RACI 矩陣和呈報矩陣，客戶減輕了造成延遲的封鎖程式和問題。然後，他們可以提前結束資料中心。

在另一個使用 RACI 和呈報矩陣的範例中，保險公司能夠在不到 4 個月內離開資料中心。客戶了解並實作共同的責任模型，並遵循詳細的 RACI 矩陣，以追蹤整個遷移期間每個程序和活動的進度。因此，客戶在實作的前 12 週能夠遷移超過 350 個伺服器。

記錄標準遷移模式和成品

將此視為建立實作的 Cookie 切入器。可重複使用的參考、文件、執行手冊和模式是擴展的關鍵。這些日誌記錄未來遷移專案可以重複使用和避免的體驗、學習、陷阱、問題和解決方案，大幅加速遷移。模式和成品也是有助於改善程序並引導未來專案的一項投資。

例如，一位客戶正在執行為期一年的遷移，其中三個不同的 SI AWS 合作夥伴正在遷移應用程式。在早期階段，每個 AWS 合作夥伴都使用自己的標準、執行手冊和成品。這會對客戶團隊造成許多壓力，因為相同的資訊可能會以不同的方式呈現給他們。在這些早期的痛苦之後，客戶建立了要在遷移中使用的所有文件和成品的集中擁有權，其中包含提交建議變更的程序。這些資產包括下列項目：

此外，這些文件和標準的任何變更都會每週傳送給所有團隊，而且每個合作夥伴都必須確認收到並遵守任何變更。這大幅改善了遷移專案的通訊和一致性，而且當另一個業務單位的個別大型遷移工作開始時，該團隊能夠採用現有的程序和文件，大幅加速成功。

為遷移中繼資料和狀態建立單一事實來源

在規劃大型遷移時，建立事實來源對於讓各種團隊保持一致並啟用資料驅動型決策至關重要。當您開始此旅程時，您可能會找到許多可使用的資料來源，例如組態管理資料庫 (CMDB)、應用程式效能監控工具、庫存清單等。

或者，您可能會發現有幾個資料來源，而且您必須建立機制來擷取所需的資料。例如，您可能需要使用探索工具來探索技術資訊，以及調查 IT 領導者以取得商業資訊。

將各種資料來源彙總到您可以用於遷移的單一資料集非常重要。然後，您可以使用單一事實來源，在實作期間追蹤遷移。例如，您可以追蹤哪些伺服器已遷移。

想要遷移所有工作負載的金融服務客戶， AWS 專注於使用已提供的資料集規劃遷移。此資料集有關鍵差距，例如業務關鍵性和相依性資訊，因此計畫開始了探索練習。

在另一個範例中，同一產業的公司根據對伺服器基礎設施庫存的out-of-date了解而進入遷移波動實作。他們很快開始看到遷移數量減少，因為資料不正確。在這種情況下，應用程式擁有者不了解，這表示他們無法及時找到測試人員。此外，資料不符合其應用程式團隊已完成的解除委任，因此伺服器在執行時並未用於商業用途。

執行大型遷移

在您建立業務成果並將策略傳達給利益相關者後，您可以繼續規劃如何將大型遷移的範圍切入永續遷移事件或波浪。下列範例提供制定波動計畫的關鍵指引。

事先規劃遷移波紋，以確保穩定的流程

規劃遷移是計畫最重要的階段之一。它會說明「如果您無法規劃，您計劃失敗」。當團隊對遷移情況變得更積極主動時，事先規劃遷移波紋可讓專案快速流動。它有助於更輕鬆地擴展專案，並隨著專案需求增加和變得複雜，改善決策和預測。提前規劃也會改善團隊適應變革的能力。

例如，一家大型金融服務客戶正在處理資料中心退出計劃。一開始，客戶以循序方式規劃遷移波，先完成一個波，再開始規劃下一個波。此方法可減少準備時間。當利益相關者收到他們的應用程式正在遷移到的通知時 AWS，他們在開始遷移之前仍然需要執行幾個步驟。這增加了對程式的重大延遲。在客戶實現這一點之後，他們實作了一個全面且以未來為重心的遷移規劃串流，其中遷移波紋是幾個月前規劃的。這為應用程式團隊提供了足夠的通知，以執行其遷移前活動，例如通知 AWS 合作夥伴、授權分析等。然後，他們可以從程式的關鍵路徑中移除這些任務。

將波動實作和波動規劃保留為個別的程序和團隊

當波動規劃和波動實作團隊是分開的，這兩個程序可以平行運作。透過通訊和協調，這可避免降低遷移速度，因為沒有足夠的伺服器或應用程式已準備好達到預期的速度。例如，遷移團隊可能需要每週遷移 30 個伺服器，但目前浪潮中只有 10 個伺服器準備就緒。此挑戰通常由下列原因造成：

請務必事先規劃波浪，並在準備和開始波浪實作之間建立緩衝區。確保波動規劃團隊和遷移團隊一起合作收集正確的資料並避免重做也很重要。

從小開始，以獲得絕佳的成果

計劃啟動小型 ，並在每次後續波動時增加遷移速度。初始波動應該是單一、小型應用程式，且少於 10 個伺服器。在後續波紋中新增其他應用程式和伺服器，以建立完整的遷移速度。優先考慮較不複雜或有風險的應用程式，並按排程提高速度，讓團隊有時間調整以一起工作並學習程序。此外，團隊可以識別和實作每個波動的程序改進，這可以大幅改善後續波的速度。

一位客戶一年遷移超過 1，300 個伺服器。從試行遷移和幾個較小的波開始，遷移團隊能夠識別多種方法來改善稍後的遷移。例如，他們先前已識別新的資料中心網路區段。他們在程序初期與其防火牆團隊合作，制定防火牆規則，以允許與遷移工具進行通訊。這有助於防止未來波紋出現不必要的延遲。此外，團隊也能夠開發指令碼，以協助在每次波動時自動化更多探索和切換程序。從小開始，有助於團隊專注於早期程序改進，並大幅提高他們的信心。

將切換時段數量降至最低

大量遷移需要有紀律的方法來推動擴展。在某些區域過於靈活是大型遷移的反模式。透過限制每週切換時段的數量，花在切換活動上的時間具有較高的值。

例如，如果切換時段太彈性，您最終可能會有 20 個切換，每個切換有 5 個伺服器。反之，您可以有兩個切換，每個切換有 50 個伺服器。由於每個切換的時間和精力都很類似，因此轉換越少，越大可減少排程的操作負擔，並限制不必要的延遲。

一家大型技術公司在合約到期前嘗試從幾個租賃的資料中心遷移。缺少過期時間會導致昂貴的短期續約期限。在遷移之前，允許應用程式團隊指定遷移排程直到最後一分鐘，包括在切換前幾天因任何原因選擇退出遷移。這導致專案早期階段發生許多延遲。通常，客戶必須在最後一分鐘與其他應用程式團隊進行交涉以填寫。客戶最終提高規劃紀律，但此早期錯誤對遷移團隊造成持續壓力。整體排程的延遲會導致某些應用程式無法及時離開資料中心。

快速失敗、套用體驗和反覆運算

每個遷移一開始都有陷阱。提早失敗有助於團隊學習、了解瓶頸，並將學到的經驗應用到更大的波浪。預期遷移中的前兩個波會緩慢，原因如下：

問題在前幾波期間很常見且預期會發生。請務必了解並與整個組織溝通，因為有些團隊可能不喜歡嘗試新事物並失敗。失敗可能會阻止團隊，並成為未來遷移的封鎖程式。確保每個人都了解初始問題是任務的一部分，鼓勵每個人嘗試失敗是成功遷移的關鍵。

一家公司計劃在 24-36 個月內遷移超過 10，000 個伺服器。為了實現該目標，他們需要每月遷移近 300 個伺服器。不過，這並不表示他們從第一天遷移了 300 個伺服器。前幾波波是學習波，以便團隊可以了解事物的運作方式，以及誰有權執行動作。他們也識別出可改善程序的整合，例如與 CMDB 和 CyberArk 整合。他們使用學習波紋來失敗、改善和再次失敗，改善程序和自動化。6 個月後，他們可以每週遷移超過 120 個伺服器。

別忘了追溯性

這是敏捷程序的重要部分。這是團隊進行溝通、調整、學習、同意和向前邁進的地方。最基本層面的回顧是回顧、討論發生的情況、判斷哪些情況順利，以及哪些需要改進。然後，可以根據這些討論來建立改進。回顧性圍繞經驗教訓的概念來包裝一些形式或程序。回溯性很重要，因為為了實現大規模遷移取得成功的規模和速度，程序、工具和團隊必須不斷發展和改進。追溯性可以在其中發揮重要作用。

在程式結束之前，不會進行傳統課程學習的工作階段，因此通常不會在下一次遷移波動開始時檢閱這些課程。在大型遷移中，學到的經驗應套用至下一波波，並且應該是波規劃程序的關鍵部分。

對於一個客戶，每週回顧會保留，以討論並記錄從切換中學到的經驗教訓。在這些工作階段中，他們發現了從程序角度或自動化進行簡化的範圍。這導致實作具有特定活動、擁有者和自動化指令碼的倒數時間排程，以將手動任務降至最低，包括在切換期間驗證第三方工具和 Amazon CloudWatch 代理程式安裝。

在另一家大型科技公司，團隊持有定期回顧，以識別先前遷移波紋的問題。這使得程序、指令碼和自動化的改進，在計畫過程中平均遷移時間減少了 40%。

其他考量

許多區域必須納入大型遷移計畫。以下各節提供有關必須考慮的其他項目的想法。

隨需清理

如果遷移的成本是預期成本的 10 倍，而且在關閉和清除用於遷移的資源之前，專案不會完成，則不會將其視為成功。此清除應該是遷移後活動的一部分。它可確保您不會將未使用的資源和服務留在環境中，而這些資源和服務會新增到成本中。遷移後清理也是防止暴露您環境的威脅和漏洞的良好安全實務。

移至 的兩個主要結果 AWS 雲端 是節省成本和安全性。保留未使用的資源可能會打敗轉移到雲端的業務目的。最常見的未清除資源包括下列項目：

在錯誤清除實務的一個範例中，SI AWS 合作夥伴未在成功遷移後移除複寫代理程式。稽核 AWS 發現已遷移的複寫伺服器和 EBS 磁碟區每月成本為 20，000 美元 (USD)。為了緩解此問題， AWS Professional Services 建立了自動化稽核程序，在仍複寫過時通知 SI AWS 合作夥伴。然後，SI AWS 合作夥伴可以對未使用和過時的執行個體採取動作。

對於未來的遷移，已採用程序來定義遷移後 Hypercare 期間 48 小時，以確保平台順利採用。然後，客戶的基礎設施團隊提交現場部署伺服器的除役請求。建議在核准解除委任請求時，會從應用程式遷移服務主控台移除個別波動的伺服器。

針對任何其他轉換實作多個階段

執行大型遷移時，請務必專注於您的核心目標，例如資料中心關閉或基礎設施轉型。在較小的遷移中，範圍凹陷可能會產生最小的影響。不過，幾天的額外工作量乘以可能的數千部伺服器，可能會為程式增加大量時間。此外，其他變更也可能需要更新支援團隊的文件、程序和訓練。

若要克服潛在的範圍模糊，您可以實作多階段遷移方法。例如，如果您的目標是清空資料中心，第 1 階段可能只包含盡可能 AWS 快地將工作負載重新託管到 。工作負載重新託管後，第 2 階段可以實作轉型活動，而不會危及目標業務成果。

例如，一位客戶計劃在 12 個月內結束資料中心。不過，其遷移涵蓋了其他轉換活動，例如推出新的應用程式效能監控工具和升級作業系統。遷移範圍內有超過 1，000 個伺服器，因此這些活動會對遷移造成重大延遲。此外，此方法需要使用新工具進行訓練。客戶稍後決定實作多階段方法，並初步專注於重新託管。這會增加其遷移速度，並降低不符合資料中心關閉日期的風險。