在移轉之前設計工作負載架構
本文說明在雲端中設計工作負載的預期移轉狀態的程序和考慮。 本文檢閱在迭代過程中定義工作負載架構相關的活動。
關於 累加式合理化的文章 指出，某些架構假設是包含移轉的任何商務轉型的一部分。 本文會釐清一般假設。 它也會指出一些您可以避免的障礙，並藉由挑戰架構假設來識別加速商業價值的機會。 此用於設計架構的累加模型可協助小組更快移動，並更快取得業務成果。
基於常見假設的基礎架構設計
下列假設適用於任何移轉工作：
- 假設一個基礎設施即服務（IaaS）工作負載。 移轉工作負載主要涉及透過 IaaS 移轉，將伺服器從實體資料中心移至雲端資料中心。 此過程通常只需要最少的重新開發或重新配置。 這種方法稱作 提升與轉移 移轉。
- 讓架構保持一致。 在移轉期間對核心架構進行變更會大幅增加複雜度。 在新的平臺上偵錯已變更的系統，引進了許多難以隔離的變數。 工作負載應該只會在移轉期間進行次要變更，而且任何變更都應該經過徹底測試。
- 計劃調整資產大小。 假設很少有內部部署資產完全使用任何資源。 在移轉之前或移轉期間，資產會重設大小，以最符合實際使用量需求。 Azure Migrate 和 Modernize 等工具會根據實際使用提供大小建議。
- 擷取商務持續性和災害復原 （BCDR） 需求。 如果您已經與企業商討並針對工作負載達成服務等級協議 (SLA)，請在移轉到 Azure 後繼續使用該 SLA。 如果尚未設定 SLA，請在設計雲端中的工作負載之前先定義一個 SLA，以確保您適當地設計。
- 規劃遷移停機時間。 與無法符合 SLA 需求一樣，當您將工作負載升階至生產環境時所發生的停機時間可能會對企業造成負面影響。 有時候必須以最短停機時間轉換的解決方案需要架構變更。 開始發行規劃之前，假設已建立對停機時間需求的一般瞭解。
- 定義使用者和應用程式流量模式。 現有的解決方案可能取決於現有的網路路由模式和解決方案。 識別支援目前網路使用量所需的資源。
- 計畫避免網路衝突。 當您將資料中心合併成單一雲端提供者時，您可能會在域名系統 （DNS） 或其他網路結構中建立衝突。 在移轉期間，請務必設計以避免這些衝突，以避免雲端中裝載的生產系統中斷。
- 規劃路由表。 如果您合併網路或資料中心，請確定您的專案包含修改路由表的計劃。 請考慮跨數據中心路由需求。
登陸區域的設計架構
在雲端採用架構的 就緒階段 中，貴組織已部署共用平臺服務，作為採用 Azure landing zones 的一部分。 在 準備您的登陸區域以進行移轉中，您已備妥登陸區域以接收已移轉的工作負載。
根據此規劃，您可以假設下列移轉元件已就緒：
- 混合式連接性會將你的 Azure 網路連接到內部部署網路。
- Azure 防火牆之類的網路安全性設備會處理工作負載外部流量的檢查。
- 用來強制執行治理做法的 Azure 原則，例如記錄需求、允許的區域、不允許的服務和其他控件都處於作用中狀態。
- 在 Azure 監視器中，設定了一個用於共享記錄的 Azure 監視器記錄工作區。
- 已建立支援已加入網域的伺服器或其他身分識別需求的共用身分識別資源。
如果未建立這些移轉要件，組織應立即返回到準備階段，以解決這些需求。 如果沒有這些元件，您的移轉可能會有延遲和挫折，且較不成功。
您設計的工作負載已將訂用帳戶指派給它，理想情況下是透過 訂用帳戶的自動售貨程式。 訂用帳戶可能包含數個工作負載，或只包含一個工作負載，視您的組織如何針對工作負載完成其 資源組織而定。 如果您移轉具有許多應用程式環境的工作負載，您甚至可能根據 應用程式環境的指引有多個訂用帳戶。
設計工作負載網路架構
規劃將應用程式特定資源部署到特定訂用帳戶，並規劃為工作負載設計專用的虛擬網路。 如需詳細資訊，請參閱 設計網路架構的指引。 您應該特別專注於 區隔虛擬網路。
您的網路可能需要負載平衡器和其他應用程式傳遞資源等資源。 您可以使用 多層式架構指南 在 Azure 中規劃這些資源。
設計工作負載相依性
移轉評估工具應該可讓您執行相依性分析，例如 Azure Migrate 和現代化中的 相依性分析。 此工具可協助您識別伺服器之間的相依性。
除了規劃工作負載本身的架構之外，您可能需要考慮工作負載對工作負載相依性。 例如，某些工作負載可能需要頻繁的通訊。 若是如此，請規劃移轉波和相依性以考慮這項需求，有助於讓您的移轉成功。
您可以在 Azure 架構中心使用指引，例如 輪輻對輪輻 網路，以設計在移轉后互連工作負載的運作方式。
準備採用機密運算
具有主權需求的工作負載子集可能會導致使用機密運算。 在主權登陸區域部署中，會建立機密運算的管理群組。
在主權內容中，使用機密運算需要 Azure Key Vault 和客戶管理的金鑰作為支持服務。 如需詳細資訊，請參閱在 Microsoft Cloud for Sovereignty 中使用客戶自控密鑰加密。
更新您的初始雲端估計值
當您完成架構設計時，請重新瀏覽您的雲端估計值，以確定您仍在計劃的預算內。 當您新增負載平衡器或備份等支援服務時，成本可能會變更。 雖然您可以使用像是 Azure Migrate 和現代化中 商務案例 等工具來進行詳細的成本管理練習，但在調整架構設計時，您應該定期重新檢視預估值。
如果您熟悉傳統的 IT 採購程式，估計雲端中的資源似乎很陌生。 當您採用雲端技術時，收購會從固定的結構化資本支出模型轉向流暢的營運費用模型。 規劃移轉至雲端通常是組織或 IT 小組第一次遇到這項變更。
在傳統的資本支出模型中，IT 小組會嘗試在各種方案中結合多個工作負載的購買能力。 此方法會將可支援每個解決方案的共用IT資產集區集中。 在作業費用雲端模型中，成本可以直接歸因於個別工作負載、小組或業務單位的支援需求。 它可讓組織更直接地將成本歸因於內部客戶，以及其支援的商務目標。 這種更動態的財務管理方法通常稱為 FinOps。 雖然 FinOps 並不是僅限於 Azure 的考量，但更深入地瞭解 FinOps 仍然是有幫助的。 如需詳細資訊，請參閱 什麼是 FinOps？。
當您設計用於移轉的工作負載架構時，可以使用 定價計算機 搭配評估資訊，以了解整個工作負載的價格。
此外，在移轉工作負載之後，您應該繼續努力將工作負載成本優化。 如需組織如何成熟其成本管理技能的詳細資訊，請參閱 改善成本管理專業領域。
瞭解何時變更您的架構
移轉通常著重於維護現有的架構，並將它轉換至您的雲端平臺。 不過，有時候您可能需要重新建構工作負載，即使在遷移時也是如此。 此清單提供移轉之前可能需要進行架構變更的範例：
- 償還技術債務。 一些老化的作業負載承擔大量技術債務。 技術債務可能會導致長期挑戰，因為它會增加使用任何雲端提供者時的託管成本。 當技術債務不自然地增加裝載成本時，您應該評估替代架構。
- 改善可靠性。 標準作業基準可在雲端中提供一定程度的可靠性和復原。 某些工作負載小組可能需要較高的 SLA，這可能會導致架構變更。
- 高成本工作負載。 在移轉期間，您應該將所有資產優化，以配合實際使用量的大小調整。 某些工作負載可能需要進行架構修改，以解決特定的成本考慮。
- 效能需求。 當工作負載效能直接影響商務時，可能需要額外的架構考慮。
- 確保應用程式的安全。 安全性需求通常會集中實作，且通常會套用至組合中的所有工作負載。 某些工作負載可能會有特定的安全性需求，可能會導致架構變更。
每個準則都可作為潛在移轉障礙的指標。 在大部分情況下，您可以在移轉工作負載後，透過調整伺服器大小、新增伺服器或進行其他變更來解決要求。 不過，如果您在移轉工作負載之前需要這些準則，請從移轉波中移除工作負載，並個別評估它。
Azure Well-Architected Framework 和 Azure Well-Architected 檢視 可協助引導特定工作負載的技術擁有者考慮部署工作負載的替代選項。
接著，工作負載會分類為雲端採用方案中的重新架構或現代化工作。 由於重新架構工作負載所花費的額外時間，請將這些替代工作負載採用路徑視為與移轉程式分開。
架構檢查清單
您可以使用下列檢查清單，確定您涵蓋重要的架構考慮：
- 確認您的架構符合 SLA 的可用性、災害復原和數據復原。
- 確認您已將網路分割做法套用至您的網路設計。
- 確認您計劃進行監視和記錄擷取。
- 確認虛擬機的大小會適當地調整，以符合您需要的實際運算時間。
- 確認磁碟的大小會適當地調整，以符合您需要的實際大小和效能。
- 請確認您是否計劃好於需要時提供負載平衡服務。 這些服務可能包含 Azure Load Balancer、Azure 應用程式閘道、Azure Front Door 或 Azure 流量管理員的實例。
- 確認您已針對主權和機密運算需求進行規劃，如有需要。