合併的建議
適用於此 Azure 架構完善的架構成本優化檢查清單建議：
| CO：14 | 合併資源和責任。 在工作負載中，判斷合併資源並增加密度的方式。 在工作負載外部，使用現有的集中式資源和服務，以便合併工作負載責任。 |
|---|
本指南說明合併資源與責任的建議，以將工作負載成本優化。 合併資源是一項細微的任務，與單純消除浪費不同。 合併牽涉到合併工作負載的元件，例如伺服器、資料庫、應用程式和責任。
匯總可減少備援資源和授權，並增加密度。 尋找合併工作負載責任的機會。 使用集中式資源或小組將成本優化。 如果您未使用共用資源並優化規模經濟來合併資源和責任，您可能會錯過節省成本的機會。
定義
| 詞彙 | 定義 |
|---|---|
| 集中式資源 | 多個元件使用的共享資源，而不是每個元件都有自己的專用資源。 |
| 變更控制件 | 管理及實作變更的結構化方法。 |
| 合併 | 結合元件以達到最佳工作負載需求的動作。 |
| 資源密度 | 資源內邏輯區隔的量值。 密度增加通常等同於較高的使用率，因為不同元件、取用者或環境的組合。 |
關鍵設計策略
合併的主要目標是最佳化，而不是縮減。 合併牽涉到重新建構工作負載、資源和小組角色，以達到最大的成本效益。 與優化元件成本不同，匯總是需要仔細考慮的程式。
幾乎所有匯總工作都有取捨和潛在風險，但可以大幅降低成本。 請務必分析潛在優點和相關取捨。 所有合併原則都遵循下列步驟：
評定：執行徹底的評估，以識別合併可能有利的領域。
識別和評估：找出並評估潛在的合併目標，以判斷潛在的成本效益和取捨是否證明合併工作合理。
通訊和實作：如果您判斷合併是有益的，請宣佈即將進行的變更並加以套用。
合併資源
合併資源牽涉到在工作負載內合併資源。 您可以共置功能或取用者。 例如，您可以將三部網頁伺服器合併成單一伺服器，或將三個資料庫合併成單一資料庫伺服器。 您可以將多個防火牆合併為多個環境提供服務的單一防火牆。
目標是增加資源密度，讓您可以最大化每個資源的成本效益。 展開資源的使用，並將資源備援降至最低。
您可以合併的常見服務類型包括應用程式平臺、資料庫、網路設備、閘道，以及分散式阻斷服務 （DDoS） 保護。 若要合併工作負載內的資源，請考慮下列建議：
評估工作負載資源。 評估現有的工作負載及其資源使用率。 分析 CPU 使用量、記憶體使用量、記憶體容量和網路頻寬等因素。 識別合併可能有幫助的區域。 合併可能涉及優化資源配置、排除備援或使用量過低的資源，或重新設定工作負載以更有效率地執行。 請考慮工作負載相依性、效能需求和延展性等因素。
識別匯總目標。 選擇要合併的資源。 它可以是現有的資源，或是在工作負載內建立的新資源。 識別您可能用於匯總的現有資源。 例如，您可能有伺服器可以容納部分工作負載元件。 如果沒有現有的資源符合匯總需求，或合併新資源更有利，請考慮建立新的資源。
評估匯總可行性。 確保功能和技術需求，例如CPU、記憶體和成長，支持匯總。 避免危害效能、可靠性和安全性等需求。 例如，請勿建立不想要的跨區域相依性，或跨生產環境合併資源。
預估成本。 判斷合併的工作和潛在併發症。 您應該計算成本，包括資源、授權和營運費用。 請考慮影響，例如因合併而導致資源監視的潛在挑戰。
與您的小組溝通與協調。 請確定您通知所有項目關係人即將進行的變更，以及他們需要採取的必要動作。 與小組協調以避免衝突，並確保順利實作。
風險：考慮資源密度的影響，例如雜訊鄰近、縮放單位效果，以及減少備援。 對於任務關鍵性與業務關鍵性工作負載流程而言，資源匯總通常太有風險。
取捨：
資源匯總可減少隔離，而且可以在工作負載中建立嘈雜的鄰近案例。 尋找其他方法來實作邏輯隔離並增加裝載環境的容量。 例如，如果防火牆支援多個工作負載，請增加防火牆容量。
合併可消除分割，並可增加安全性風險，讓攻擊者更容易水平移動。 這也使得一些合規性標準難以達到。 排定合規性的優先順序超過合併。
資源合併會導致較少的備援。 請仔細規劃，以確保您在工作負載中具有適當的可靠性。
合併責任
合併工作負載責任的目標是減少工作負載小組的責任。 這是一項策略性成本優化工作，需要工作負載小組外部的組織意識和共同作業。
有兩個主要方式可以合併工作負載小組的責任。 您可以使用外部共用或集中式資源，而不是在工作負載環境中執行該資源。 您也可以將工作負載責任卸除給組織中的其他小組，因此您的小組不會直接負責這些工作或人員。
使用外部集中式資源
外部集中式資源是指工作負載環境外部的共享資源。 例如，組織可能有可處理多個工作負載的集中式閘道。 外部集中式資源的目標是將重複和額外負荷降至最低。 您可以使用共用資源來將成本優化，而不是為您的工作負載使用專用資源。 請考量下列建議事項：
評估工作負載資源。 評估工作負載的目前狀態，並找出合併可能有幫助的區域。
尋找外部商機。 調查貴組織是否有預先存在的集中式資源。 這些資源可能是您工作負載的潛在解決方案。 例如，您可以使用共用的安全性資訊和事件管理 （SIEM），而不是設定獨立的 SIEM 工具。
請考慮變更控制件。 瞭解管理集中式資源變更的程式。 請考慮核准工作流程、測試通訊協定和部署方法。 如果您減少對資源修改的控制，請分析潛在的挑戰。
預估成本。 在實作集中式資源之前，請清楚量化與轉換相關聯的成本的預期節省。 根據風險權衡節省成本的好處，以做出明智的決策。
與您的小組溝通與協調。 建立小組之間持續意見反應的機制，以解決疑慮、改善共同作業和精簡程式。
記錄和追蹤變更。 維護所有已核准變更的詳細檔，包括其範圍、實作步驟，以及相關聯的風險或問題。 使用集中式系統或變更管理工具來追蹤和監視整個生命週期中的變更狀態。
將責任卸除給外部小組
將工作負載責任卸除給外部小組是指使用執行安全性作業小組等特製化服務的專家集中式小組。 您可以將責任卸除給現有的小組，以協助將成本優化，並委派特定功能的專業知識。
評估小組技能。 評估小組目前的技能集。 識別集中式小組將成本優化所在的技能差距或區域。
尋找可用的商機。 探索您的組織是否有可用的服務，例如安全性作業小組的服務。 請確定集中式小組可以配合新增的責任，而不會影響品質。
請考慮變更控制件。 熟悉集中式小組如何處理變更，例如核准工作流程、測試通訊協定和部署策略。 如果您不太直接控制這些函式，請判斷可能發生的潛在挑戰。
與您的小組溝通與協調。 請確定小組熟悉彼此的流程、工具和期望。 請考慮階段式轉換或試驗期，以簡化班次，並儘早找出潛在的挑戰。
記錄和追蹤變更。 維護所有已核准變更的詳細檔，包括其範圍、實作步驟，以及相關聯的風險或問題。 使用集中式系統或變更管理工具來追蹤和監視整個生命週期中的變更狀態。
Azure 便利化
密度支援：許多 Azure 服務支援增加的資源密度。 下表顯示這些服務的取樣。
| Azure 服務 | 分割控件 |
|---|---|
| Azure Front Door | 客戶網域和 URL 路徑 |
| Azure 防火牆 | 網路和應用程式規則 |
| Azure 應用程式閘道 | 接聽程式、URL 路徑型路由 |
| API 管理 | API 原則 |
| Azure Kubernetes Service (AKS) | 命名空間、節點集區 |
| Azure App Service | App Service 方案上的多個 Web 應用程式和 API |
| Azure SQL Database | 伺服器上的多個資料庫 |
資源可觀察性：Azure 監視器提供集中式平臺，可監視和管理 Azure 資源的效能和健康情況。 您可以收集和分析遙測數據、設定警示，以及深入瞭解資源使用率和匯總機會。
Log Analytics 提供集中式記錄管理和分析。 您可以從各種 Azure 資源收集、分析和可視化記錄數據，以協助識別問題、疑難解答問題，以及取得作業見解。
相關連結
成本優化檢查清單
請參閱一組完整的建議。