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