本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
波規劃
本質上，波動計畫是一種遷移排程，它類似於其他專案規劃活動。我們建議您使用遷移波來建立可管理的群組、降低風險，以及整理這些群組的活動。
若要建立有效且高可信的遷移波動計畫，您必須取得應用程式產品組合、相關基礎設施 （運算、儲存、網路）、相依性映射和遷移策略的完整檢視。
除了商業應用程式之外，這是將軟體和基礎設施元件集合分組的形式，您也可以使用其他群組層級。波動是最高的群組層級。在波動內，您可以建立相依性群組。這種類型的子群組可以包含多個應用程式。例如，由於技術相依性，例如低延遲或其他因素，而需要同時遷移的兩個或多個應用程式。然後，該相依性群組會整體管理。可以將多個相依性群組指派給波動。接著，您可以將遷移日期指派給整個波動或波動內的個別相依性群組。遷移日期是該群組將在目前位置停止並啟用的日期和時間 AWS。
遷移波紋有多個活動。我們建議您分階段組織波動，並為每個階段設定預期的持續時間。以下階段做為範例：
-
設計：在此波動階段，確認並核准波動中每個應用程式的目標設計。
-
切換規劃：此波動階段包括建立或重複切換執行手冊，以及規劃將應用程式切換為 AWS （包括轉返案例） 所需的所有步驟。
-
預遷移：此階段包括登陸區域部署活動，例如帳戶佈建、組態、預遷移測試、遷移工具設定和資料複寫。
-
切換：此階段是實際遷移發生的時間。在此期間，應用程式會在目前位置停止、資料最後一次同步、執行業務測試，以及遷移完成。此階段包含操作交接。
-
Hypercare 或遷移後：此階段是遷移團隊可在發生問題時支援操作的一段時間。此外，可視需要套用最佳化。
-
波浪關閉：在此階段，您將檢閱指標和經驗教訓，並正式關閉波浪。
遷移波動沒有預先定義的持續時間，而且取決於工作量和複雜性。我們建議在 6 到 10 週內保留遷移波紋。需要更多時間的案例，例如，當完全重寫應用程式元件時，通常更適合在遷移波紋之外處理。
為了衡量成功和追蹤進度，波紋應與成果和業務驅動因素保持一致。這也會影響波持續時間和波包含的相依性群組。波動的完成應反映可衡量的成就。
有多種方式可組織遷移波紋。下表說明最常見的波動組織選項。這些通常是合併的。
Wave 組織類型 |
說明 |
優點 |
缺點 |
|---|---|---|---|
依遷移策略或技術堆疊 |
將具有常見遷移策略或模式的應用程式指派給波動。例如，只包含重新託管應用程式的波動。 |
每個模式或堆疊的專用團隊可以指派整個波紋。 同質活動持續時間。 |
需要對相依性進行更多分析，尤其是對遵循不同模式的應用程式。 |
依業務網域 |
為每個業務網域建立波紋。例如，訂單管理波動或付款波動。 |
共用資料通常位於指定網域內。 一致的團隊參與。 |
由於整個業務網域受到影響而增加的風險。 |
依技術能力 |
將使用一或多個功能的應用程式分組。例如，僅限運算波或運算 + 負載平衡波。 |
隨著隨時間啟用技術功能，遷移會更快開始。移除完全操作登陸區域的相依性。 |
在較晚的波紋中建立複雜空間。 |
依環境 |
波動包含一組應用程式的特定環境。例如，開發波或生產波。 |
非生產波在執行期間受益於彈性。 降低生產遷移的風險。 |
需要專注於相依性分析，以避免缺少非生產環境中不存在的相依性。 |
依業務優先順序 |
僅根據指定的優先順序條件建立群組。 |
解決業務成果。 |
通常涉及許多團隊；難以協調。 |
有關 為應用程式產品組合建立基準的章節描述了四個類別的技術相依性。這些相依性有助於建立遷移波紋和相依性群組的定義。相依性群組將由相依性的關鍵性決定。此外，還必須考慮非技術相依性。例如，應用程式發行排程、維護時段和關鍵業務日期 （例如月底或季末處理） 可能會影響波動計畫。
判斷相依性是軟式還是硬式。軟相依性是兩個或多個資產，或從資產到限制條件之間的關係，而不受元件的位置影響。例如，兩個在相同本機網路 （或相同基礎設施） 中操作的系統，可以透過將其中一個系統移至雲端，而另一個系統保留在內部部署中來分割。硬相依性是兩個或多個資產，或從資產到限制條件之間的關係，這取決於位置。例如，在相同本機網路中操作且高度依賴應用程式伺服器與資料庫伺服器之間通訊低延遲的兩個系統具有硬相依性。僅將其中一個系統移至雲端會導致無法解決的功能或效能問題。同樣地，非技術原因，例如資源可用性 （例如執行遷移的團隊） 或操作限制 （例如維護時段，其中兩個系統只能在指定時段內遷移），可能會為這些資產建立硬相依性。
若要建立遷移波動計畫，請分析相依性來判斷相依性群組，最好來自高度信任的資料來源，例如專門的探索工具。結合此資訊與您的應用程式優先順序條件和操作情況。
判斷技術相依性具有挑戰性。需要數個資料點，而且沒有任何資料來源包含所有資料點。例如，雖然您可以從探索工具取得process-to-process的通訊資訊，但很難將其分類為軟式和硬式相依性。僅從網路資料判斷延遲容錯能力也很困難。
下列技術可協助您處理判斷實際相依性的模棱兩可情況：
-
收集所有資料，如資料需求一節所述，以及您視需要考慮的任何其他資料點。
-
篩選相依性資訊 （或通訊資料），並排除共用服務，例如 Active Directory、備份和監控流量。技術共用服務往往會黏附整個範圍。
-
分類所有資訊。如果可用，請使用元件之間的網路頻率和資料傳輸量。
-
與應用程式擁有者、架構師和支援團隊會面。討論連線的類型。它們是同步還是非同步？ 他們是否知道最低延遲要求？ 什麼是關鍵連線，如果無法使用會發生什麼情況？ 您是否缺少重要的連線？ 請考慮批次處理可能會偶爾發生，並遺失在資料集中。
-
如果您的探索工具提供資料圖表，請尋找橋接大型應用程式叢集的單一應用程式。這些單一連線點有助於將資料分成較小的群組。
AWS 轉換可協助您分析相依性並執行波動規劃。
建立波動計畫
遷移一波應用程式的必要條件是應用程式產品組合資料，以及將在波中遷移之應用程式群組的詳細應用程式評估。詳細評估應包含波動中的應用程式清單、相關聯的基礎設施詳細資訊、目標設計和每個應用程式的遷移策略。
建立波動擁有權和管理是管理和追蹤波動工作、程式相依性、變更管理、問題和風險的關鍵。確保已備妥控管架構來管理計畫。
若要概述波動計畫，請從預設波動建構開始。波動中會發生什麼情況？ 定義初始輸入後，可以開始波動。一般而言，活動將是：
-
精簡切換計畫。此活動應概述遷移時必須採取的執行手冊和步驟，包括與其他內部和外部團隊的協調。
-
精簡轉返計劃。如果發生問題，必須執行哪些動作來復原應用程式？
-
準備目標基礎設施。例如，您可以建立或擴展 AWS 登陸區域 (AWS 帳戶、安全性、聯網、基礎設施服務、其他支援基礎設施）。
-
測試目標基礎設施。
-
操作遷移工具。例如，安裝複寫代理程式並開始資料傳輸。
-
執行切換計劃和 Runbook 試轉。將所有參與的團隊成員分組，並事先檢閱所有步驟。
-
監控資料複寫和基礎設施部署。
-
確認準備好在 中操作基礎設施和應用程式 AWS。
-
確認安全準備。
-
如果適用，請確認合規和法規要求 （例如，遷移前和遷移後工作負載驗證）。
-
將應用程式遷移至 AWS 並執行上線前測試。
-
提供遷移後支援一段時間，例如 3 天，此時營運團隊和遷移團隊可以完全解決問題，並套用最佳化。
-
執行遷移後審核。記錄學到的經驗，並將其納入未來的波紋。
-
透過確認操作交接並取得用於報告的指標來執行波動關閉。
這些活動所需的時間取決於範圍的複雜性、波動容量、涉及的人員以及您的獨特情況。如果可能，更小的波會比較適合，因為這樣可以降低任何延遲或遷移封鎖程式的影響。與您的團隊一起決定波動的預設持續時間。
接著，繼續分析日期，以建立空波的初始高階結構 （尚未指派應用程式）。請考慮下列問題：
-
遷移程式的總長度是多少？
-
截止日期為何？
-
是否有固定的資料中心退出日期？
-
是否有共置合約結束日期？
-
什麼是應用程式和基礎設施重新整理週期？
-
什麼是應用程式維護和發行週期？
-
是否有任何日期應該避免遷移 （例如，發行和維護週期、年底、假日、月底處理）？
基於這些考量，請將波浪繪製到計劃中。為了加速遷移程序，我們建議盡可能重疊波。重疊波波的關鍵在於定義和考慮波內發生的情況。一般而言，部署活動、目標基礎設施驗證和資料同步會在波動的前半段發生。下半部分將著重於實際遷移、測試和操作交接。這表示不同的團隊參與每個半個程序，而且您可以獲得一些效率。例如，只要參與目標基礎設施準備的團隊完成工作，就可以開始處理下一波的需求。一般而言，大多數波浪具有類似的長度和結構，以促進類似工廠的方法遷移。不過，在波動規劃過程中，可以擴展給定波動的大小，以滿足相依性或操作要求。
接著，根據已識別的相依性群組，根據可以包含的相依性群組數量來判斷波動的大小上限。波浪大小通常取決於風險偏好 （例如，可容忍多少平行變更） 和資源可用性 （例如，可使用可用資源、技能和預算執行多少平行變更）。不過，在早期規劃期間，不會受限於資源需求和可用性。包含多個相依性群組的波可以在未來的反覆運算中分解為較小的波。
確認指定波的相依性群組之後，請檢閱遷移波的資源需求。考慮根據資源需求調整波動大小 （其包含的相依性群組數量）。這可能會導致更小或更大的波。視需要反覆執行波動計畫，直到定義完所有波為止。考慮與 AWS Professional Services 或 AWS Migration Competency Partners 合作，他們可以提供專家在整個過程中為您提供協助。
管理變更
應用程式和相關基礎設施的產品組合將在遷移程式的生命週期期間變更。長時間執行的遷移計劃與正常的業務演變和變更並存。應用程式在等待遷移時不斷發展。伺服器已新增或移除，新的基礎設施已部署在內部部署。預期波動或相依性群組的範圍將需要變更。當更接近遷移日期、已識別先前未知的相依性，或庫存中包含新的伺服器時，尤其需要變更。有時候，這可能會在遷移本身時發生。
範圍變更會影響相依性群組和波紋。若要處理變更並將影響降至最低，請務必建立範圍控制機制。範圍變更控制機制需要定義範圍的單一事實來源。這可能是管理範圍的工具，或 .csv 檔案、試算表或資料庫，如遷移程式控管所定義。您必須識別變更、分析影響，並向相關利益相關者傳達變更，以便他們可以採取行動。因此，將會反覆執行波動計畫。
