本文件著重於說明如何在規劃混合雲和多雲端策略時，套用預先定義的業務考量事項。這份文件會進一步說明「驅動因素、考量事項、策略和做法」中的指引。該文章定義並分析企業在規劃這類策略時應考量的業務考量因素。
釐清並達成共識的願景和目標
歸根究柢，混合式或多雲端策略的主要目的，就是根據各個業務用途，達成特定業務目標所需的特定業務需求和相關技術目標。如要達成這個目標，請建立結構良好的企劃書，並納入下列考量事項：
請注意，要制定能兼顧各種工作負載與需求的方案實屬不易，尤其是在複雜的 IT 環境中。此外，制定方案需要時間，而且可能造成相關人員的願景衝突。
為了避免這種情況，請先擬定願景宣言，至少要回答以下問題：
- 為了達成特定業務目標，您指定的業務用途為何？
- 為何現行的方法和運算環境無法達成業務目標？
- 使用公用雲端時，您需要著重哪些主要技術面向？
- 新做法為何以及如何改善並達成業務目標？
- 您計劃要使用混合式或多雲端設定多久的時間？
對主要業務和技術目標和驅動因素達成共識，然後取得相關利害關係人的背書，可為制定方案的後續步驟奠定基礎。如要有效地將您提出的解決方案與貴機構的整體架構願景保持一致，請與負責領導及贊助這項計畫的團隊和利益相關者保持一致。
找出並釐清其他考量重點
規劃混合式或多雲架構時，請務必找出並同意專案的架構和營運限制。
在作業方面，下列清單 (不含全部) 列出一些可能會在規劃架構時造成限制的條件：
- 分別管理及設定多個雲端，而不是建立全方位模型來管理及保護不同的雲端環境。
- 確保跨環境的驗證、授權、稽核與政策一致性。
- 在各個環境中使用一致的工具和程序，全面掌握安全性、成本和最佳化機會。
- 使用一致的規範和安全性標準，套用統一管理機制。
在架構規劃方面，最大的限制通常來自現有系統，包括：
- 應用程式之間的依附元件
- 系統間通訊的效能和延遲需求
- 依賴的硬體或作業系統在公用雲端中可能無法使用
- 授權限制
- 取決於多雲架構中所選區域是否提供必要功能
如要進一步瞭解工作負載可攜性、資料移轉和安全性方面的其他考量，請參閱「其他考量」。
設計混合式雲端和多雲端架構策略
在釐清業務和技術目標的具體內容，以及相關業務需求 (最好是明確說明並同意願景聲明) 後，您就可以制定策略來建立混合式或多雲架構。
下列流程圖概述建立這類策略的邏輯步驟。
為協助您判斷混合雲或多雲端架構的技術目標和需求，上方流程圖中的步驟會從業務需求和目標開始。實施策略的方式會因各業務用途的目標、驅動因素和技術遷移路徑而異。
請務必記住，遷移是一段持續的歷程。下圖說明遷移至 Google Cloud的階段。
本節將說明上圖中「評估」、「規劃」、「部署」和「最佳化」階段的相關指引。這項資訊會在混合雲或多雲端遷移作業的背景中顯示。您應將所有遷移作業與「遷移至 Google Cloud 」指南的遷移路徑部分中所述的指導方針和最佳做法保持一致。這些階段可能會個別套用至每個工作負載，而非一次套用至所有工作負載。在任何時間點，多個工作負載可能處於不同的階段：
評估階段
在「評估」階段，您會進行初步工作負載評估。在這個階段，請考量願景和策略規劃文件中列出的目標。決定遷移計畫時，請先列出可能因部署或遷移至公用雲端而受益的工作負載候選清單。
首先，請選擇非關鍵業務或遷移難度太高的工作負載 (對其他環境中的任何工作負載的依附元件少或沒有)，但足以做為即將進行的部署或遷移作業的參考藍圖。
理想情況下，您選取的工作負載或應用程式應屬於特定業務用途或功能，且完成後可對業務產生可衡量的影響。
如要評估及降低任何潛在的遷移風險，請進行遷移風險評估。請務必評估候選工作負載，判斷其是否適合遷移至多雲環境。這項評估作業會評估應用程式和基礎架構的各個面向，包括：
- 應用程式相容性需求 (適用於所選雲端服務供應商)
- 計費模式
- 所選雲端服務供應商提供的安全功能
- 應用程式互通性規定
執行評估作業也有助您找出多個雲端環境中的資料隱私權要求、法規遵循要求、一致性要求和解決方案。您找出的風險可能會影響您選擇遷移或操作的工作負載。
您可以使用 Google Cloud 遷移中心等多種工具，評估現有工作負載。詳情請參閱「遷移至 Google Cloud：選擇評估工具」一文。
從工作負載現代化角度來看，適配評估工具可協助評估 VM 工作負載，判斷工作負載是否適合遷移至容器以進行翻新，或是遷移至 Compute Engine。
規劃階段
在規劃階段，請從已識別的應用程式和必要的雲端工作負載著手，並執行下列工作：
- 制定優先順序的遷移策略，定義應用程式遷移波次和路徑。
- 找出適用的高階混合式雲端或多雲端應用程式架構模式。
- 選取支援所選應用程式架構模式的網路架構模式。
理想情況下，您應將雲端網路模式與登陸區設計結合。目的地設計是整體混合雲和多雲端架構的重要基礎元素。設計必須與這些模式無縫整合。請勿獨立設計到達可用區。請將這些連結模式視為到達區設計的子集。
到達區域可能包含不同的應用程式，每個應用程式都有不同的網路架構模式。此外，在這個階段，您必須決定Google Cloud 機構、專案和資源階層的設計，為混合式雲端或多雲端整合和部署作業準備雲端環境的目標區。
在這個階段中，您應考慮以下事項：
- 定義遷移和翻新方法。本指南後續章節將進一步說明遷移方法。您也可以在 Migrate to Google Cloud 的「migration types」一節中進一步瞭解這項功能。
- 運用評估與探索階段的發現結果。並與您預計要遷移的候選工作負載保持一致。接著，請擬定應用程式的遷移波次計畫。這份計畫應納入您在評估階段決定的預估資源大小需求。
- 定義所需的通訊模型，以便分散式應用程式和應用程式元件之間的通訊，符合預期的混合雲或多雲架構。
- 根據所選架構模式，決定適合的部署原型來部署工作負載，例如可用區、區域、多區域或全球。您選取的範本會成為建構特定應用程式部署架構的基礎，以滿足您的業務和技術需求。
- 決定遷移作業的可評估成功標準，並為每個遷移階段或波次設定明確的里程碑。即使技術目標是將混合式架構做為短期設定，也必須選取相關標準。
- 在應用程式以混合設定運作時，請定義應用程式服務水準協議和關鍵績效指標，特別是針對可能在多個環境中分散元件的應用程式。
詳情請參閱「關於遷移規劃」，瞭解如何規劃遷移作業，並盡可能降低相關風險。
部署階段
在部署階段，您可以開始執行遷移策略。考量到可能的需求數量，建議您採用迭代式方法。
根據您在規劃階段制定的遷移和應用程式分批作業，排定工作負載的優先順序。在混合式雲端和多雲端架構中，請先建立 Google Cloud 與其他運算環境之間的必要連線，再開始部署作業。為方便混合雲或多雲架構使用所需的通訊模型，請根據所選設計和網路連線類型，以及適用的網路模式來部署。我們建議您在整體到達網頁設計決策中採用這種做法。
此外，您必須根據定義的應用程式成功標準，測試及驗證應用程式或服務。理想情況下，這些標準應在正式版推出前，同時納入功能和負載測試 (非功能性) 的規定。
最佳化階段
在「最佳化」階段，請測試您的部署作業：完成測試後，如果應用程式或服務符合功能和效能容量預期，即可將其移至正式環境。雲端監控和可視性工具 (例如 Cloud Monitoring) 可提供應用程式和基礎架構的效能、可用性和健康狀態洞察資料，並在必要時協助您進行最佳化。
詳情請參閱「遷移至 Google Cloud：改善環境」一文。如要進一步瞭解如何為混合式或多雲端架構設計這類工具，請參閱混合式雲端和多雲端監控和記錄模式。
評估候選工作負載
選擇適合不同工作負載的運算環境，將對混合式和多雲端策略的成效造成重大影響。工作負載的放置決策應與特定業務目標一致。因此，這些決策應以特定業務用途為依據，以便產生可衡量的業務效果。不過，您不一定需要或建議從最關鍵的工作負載/應用程式開始。詳情請參閱「遷移至 Google Cloud 」指南中的「選擇要先遷移的應用程式」。
如業務和技術驅動因素一節所述，混合式雲端和多雲端架構有不同的驅動因素和考量事項。
以下列出一些因素，可協助您在混合雲或多雲架構的情況下，評估遷移用途，並評估是否有可衡量的業務效益：
- 雲端服務能夠帶來的市場差異化或創新潛力，例如使用雲端服務啟用特定業務功能，例如使用現有內部資料訓練機器學習模型的人工智慧功能。
- 應用程式可節省的總擁有成本。
- 可用性、彈性、安全性或效能的改善空間，例如在雲端中新增災難復原 (DR) 網站。
- 加快開發及發布流程的可能性，例如在雲端建構開發和測試環境。
以下因素可協助您評估遷移風險：
- 遷移作業可能造成的服務中斷影響。
- 團隊在公用雲端部署作業或新雲端服務供應商/第二家雲端服務供應商的部署作業方面，是否具備相關經驗。
- 遵守現有法令或法規限制的需求。
以下因素可協助您評估遷移的技術難度：
- 應用程式的大小、複雜度和新舊程度。
- 在不同運算環境中，相依其他應用程式和服務的數量。
- 任何第三方授權的限制。
- 對特定版本的作業系統、資料庫或其他環境設定的依賴程度。
初步評估工作負載後，您就可以開始確立工作負載的優先順序，以及定義遷移波次和方法。接著，您可以找出適用的架構模式和支援的網路模式。此步驟可能需要反覆思量，因為您的評估結果可能會隨時間變動。因此，在首次部署雲端服務後，不妨重新評估工作負載。