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