套用設計原則和進階作業

前三個雲端管理專業領域描述的是管理基準。 管理基準至少應包含標準的商務承諾，以將業務中斷降到最低，並在服務中斷時加速復原。 大部分的管理基準會審慎聚焦於維護詳細目錄和可見度、作業合規性，以及保護和復原。

管理基準的目的是要建立一致的供應項目，以便為「所有」受支援的工作負載提供最低程度的商務承諾。 這個常見的可重複管理供應項目基準，可讓小組以最小的偏差來提供高度最佳化的作業管理機制。 但是，這種標準供應項目可能無法為企業提供豐富充足的承諾。

下一節中的圖表說明超越管理基準的三種方式。

管理基準應滿足組合中最低重要性工作負載 80% 所需的最低承諾用量。 基準不應套用至任務關鍵性工作負載， 也不應該套用至跨工作負載共用的通用平台。 這些工作負載需要將焦點放在設計原則和進階作業上。

進階作業選項

有三個建議的途徑可改善商務承諾、超越管理基準，如下圖所示：

增強的管理基準

如同 Azure 管理指南中所述，增強的管理基準會使用雲端原生工具來改善運作時間，並減少復原時間。 這個改善項目很重要，但不及工作負載或平台的特製化。 增強的管理基準的優點是能同時大幅減少成本和實作時間。

管理特製化

工作負載作業和平台作業方面可能需要變更設計和架構原則。 這些變更需要不少時間，而且可能會導致營運費用增加。 為了減少需要這類投資的工作負載數目，增強的管理基準可提供足夠的商務承諾改善。

如果工作負載需要更高的投資才能滿足商務承諾，則作業的特製化就是關鍵。

管理特製化的領域

特製化有兩個領域：

• 平台特製化：投資共用平台的持續營運，將投資分散到多個工作負載。
• 工作負載特製化：投資特定工作負載的持續營運，通常會保留給任務關鍵性工作負載。

集中式 IT 小組或卓越雲端中心 (CCoE)

選擇平台特製化和工作負載特製化，取決於每個工作負載的重要性和影響。 不過，這兩個選項更代表集中式 IT 小組和 CCoE 組織模型之間的文化特性。

工作負載特製化通常會觸發文化變革。 傳統的 IT 和集中式 IT 都可建立提供大規模支援的流程。 針對在管理基準、增強的基準或甚至平台作業中找到的可重複服務，更容易實現規模化支援。 工作負載特製化通常不會規模化。 這種規模不足的情況，將導致集中式的 IT 組織很難在不達到組織規模限制的情況下提供必要的支援。

另一方面，雲端卓越中心可透過目的化責任委派和選擇性集中化來調整規模。 工作負載特製化更適合搭配 CCoE 的委派責任方法。

CCoE 中角色的自然對齊如下所示：

• 雲端平台小組有助於建立可支援多個雲端採用小組的通用平台。
• 雲端自動化小組會將這些平台延伸至服務類別目錄中的可部署資產。
• 雲端管理會集中提供管理基準，並協助支援服務類別目錄的使用。
• 但是，業務單位 (企業 DevOps 團隊或雲端採用小組的形式) 將負責工作負載、管線或效能的日常作業。

針對管理的對齊領域，集中式 IT 小組和 CCoE 模型通常可以提供平台特製化，而文化變革最小。 提供工作負載特製化對於集中式 IT 團隊來說可能更複雜。

管理特製化流程

在每個特製化中，都會以嚴格、反覆的方法執行下列四個步驟。 這種方法需要雲端採用、雲端平台、雲端自動化和雲端管理專家之間相互合作，從而建立可行且明智的意見反應迴圈。

• 改善系統設計：改善常見系統 (平台) 或特定工作負載的設計，以便有效地將中斷情形降到最低。
• 自動補救：某些改善並不符合成本效益。 在這種情況下，將補救程序自動化並降低中斷所造成的影響，可能是更好的做法。
• 擴展解決方案：改善系統設計和自動化補救功能後，您就能透過服務目錄將這些變更擴展到整個環境。
• 持續改進：您可以使用各種監視工具，探索在下一階段的系統設計、自動化和規模調整中要遞增改善的項目。

改善系統設計

改善系統設計最能有效改善任何常見平台的作業。 系統設計改善有助於提高穩定性並減少業務中斷。 個別系統的設計不在整個雲端採用架構中所採用環境檢視的範圍內。

做為此架構的補充，Microsoft Azure Well-Architected Framework 提供引導原則來改善平台或特定工作負載的品質。 此架構的重點在於改善整個結構的五個要素：

• 成本最佳化： 管理成本以將傳遞的價值最大化。
• 卓越的營運績效： 追隨讓系統在生產環境中順利運作的作業流程。
• 效能效率： 調整系統以適應負載中的變更。
• 可靠性： 設計系統以從失敗中復原並繼續運作的能力。
• 安全性： 保護應用程式和資料，使其免於威脅。

大部分的業務中斷等同於某種形式的技術債務，或架構缺失。 針對現有部署，您可以將系統設計改善視為對現有技術債務的償還。 針對新部署，則可以將系統設計改善視為技術債務的迴避。 下一節將說明如何處理無法或不應解決的技術債務。

若要改善系統設計，請深入了解 Microsoft Azure Well-Architected Framework。 改善系統設計後，請回到本文來尋找新的改善機會，並將這些改善擴展到整個環境。

建議的補救方式

有些技術債務無法或不應解決。 解決方案可能需要太大的成本，所以就未矯正。 解決方案可能已完成規劃，但專案持續時間可能過長。 業務中斷可能並未大幅影響業務，或企業的優先順序是快速復原，而不是投資復原能力。

當技術債務的解決方案不是企業想要走的途徑時，接下來他們通常會想要採用自動化補救。 使用 Azure 自動化和 Azure 監視器來偵測趨勢並提供自動化補救功能，是最常見的自動化補救方法。

如需自動補救的指引，請參閱 Azure 自動化和警示。

使用服務類別目錄來擴展解決方案

妥善管理的服務類別目錄是平台特製化和平台作業的基石。 有此基石才能將系統設計的改善和補救方法擴展到整個環境。 雲端平台小組和雲端自動化小組會彼此配合，來為任何環境中最常見的平台建立可重複執行的解決方案。 然而，如果未能一致地套用這些解決方案，雲端管理所要付出的成本，就會比平常所付出的基準成本再多一些。

若要讓最佳化平台的採用最大化，並讓維護成本降到最低，就應該將平台新增至服務類別目錄。 類別目錄中的每個應用程式都可以透過服務類別目錄加以部署以供內部取用，或作為市集供應項目來供外部取用者取用。

如需如何發佈至服務類別目錄的相關資訊，請參閱發佈至服務類別目錄的文章系列。

持續改進

平台特製化和平台作業都仰賴採用、平台、自動化和管理小組之間的強大意見反應迴圈。 以資料作為這些意見反應迴圈的基礎，可讓每個小組做出明智的決策。 若要讓平台作業實現長期的商務承諾，請務必善用集中式平台專屬的深入解析。 由於容器和 SQL Server 是兩個最常見的集中管理平台，請考慮先檢閱下列文章以開始持續收集改善資料：

• 容器效能
• PaaS 資料庫效能
• IaaS 資料庫效能