用於雲端管理的平台特製化Platform specialization for cloud management

和增強的管理基準很像,平台特製化也是超越標準管理基準的擴充功能。Much like the enhanced management baseline, platform specialization is extension beyond the standard management baseline. 請參閱下方影像和清單,其中說明擴展管理基準的方式。See the following image and list that show the ways to expand the management baseline. 本文將說明平台特製化選項。This article addresses the platform specialization options.

超越雲端管理基準

  • 工作負載作業: 每個工作負載作業的最大投資和最高程度的復原能力。Workload operations: The largest per-workload operations investment and the highest degree of resiliency. 我們建議針對大約 20% 可帶來商業價值的工作負載進行工作負載作業。We suggest workload operations for the approximately 20% of workloads that drive business value. 此特製化通常保留給高度重要性或任務關鍵性的工作負載。This specialization is usually reserved for high criticality or mission-critical workloads.
  • 平台作業: 作業投資會分散到許多工作負載。Platform operations: Operations investment is spread across many workloads. 復原能力的改善會影響所有使用已定義平台的工作負載。Resiliency improvements affect all workloads that use the defined platform. 我們建議針對 20% 的最重要平台進行平台作業。We suggest platform operations for the approximately 20% of platforms that have the highest criticality. 此特製化通常保留給中度到高度重要性的工作負載。This specialization is usually reserved for medium to high criticality workloads.
  • 增強的管理基準: 相對最低的作業投資。Enhanced management baseline: The relatively lowest operations investment. 此特製化可稍微改善使用其他雲端原生作業工具和流程的商務承諾。This specialization slightly improves business commitments by using additional cloud-native operations tools and processes.

工作負載作業和平台作業都必須變更設計和架構方面的原則。Both workload and platform operations require changes to design and architecture principles. 這些變更需要不少時間,而且可能會導致營運費用增加。Those changes can take time and might result in increased operating expenses. 為了減少需要這類投資的工作負載數目,增強的管理基準可提供足夠的商務承諾改善。To reduce the number of workloads requiring such investments, an enhanced management baseline might provide enough of an improvement to the business commitment.

此資料表概述客戶增強的管理基準中常見的一些流程、工具和潛在影響:This table outlines a few common processes, tools, and potential effects common in customers' enhanced management baselines:

ProcessProcess 工具Tool 目的Purpose 建議的管理層級Suggested management level
改善系統設計Improve system design Microsoft Azure Well-Architected FrameworkMicrosoft Azure Well-Architected Framework 改善平台的架構設計以改善作業Improving the architectural design of the platform to improve operations N/AN/A
自動化補救Automate remediation Azure 自動化Azure Automation 使用平台專屬的自動化來回應進階平台的資料Responding to advanced platform data with platform-specific automation 平台作業Platform operations
服務類別目錄Service catalog 受控應用程式中心Managed applications center 針對符合組織標準的已核准解決方案來提供自助式目錄Providing a self-service catalog of approved solutions that meet organizational standards 平台作業Platform operations
容器效能Container performance 適用於容器的 Azure 監視器Azure Monitor for containers 容器的監視和診斷Monitoring and diagnostics of containers 平台作業Platform operations
平台即服務 (PaaS) 資料效能Platform as a service (PaaS) data performance Azure SQL 分析Azure SQL Analytics PaaS 資料庫的監視和診斷Monitoring and diagnostics for PaaS databases 平台作業Platform operations
基礎結構即服務 (IaaS) 資料效能Infrastructure as a service (IaaS) data performance SQL Server 健康情況檢查SQL Server Health Check IaaS 資料庫的監視和診斷Monitoring and diagnostics for IaaS databases 平台作業Platform operations

高階流程High-level process

要進行平台特製化作業,就必須有紀律地反覆執行下列四個流程。Platform specialization consists of a disciplined execution of the following four processes in an iterative approach. 本文後面幾節會更詳細地說明每個流程。Each process is explained in more detail in later sections of this article.

  • 改善系統設計: 改善常見系統或平台的設計,以便有效地將中斷情形降到最低。Improve system design: Improve the design of common systems or platforms to effectively minimize interruptions.
  • 自動化補救: 某些改善並不符合成本效益。Automate remediation: Some improvements aren't cost effective. 在這種情況下,將補救程序自動化並降低中斷所造成的影響,可能會是更好的做法。In such cases, it might make more sense to automate remediation and reduce the effect of interruptions.
  • 擴展解決方案: 隨著系統設計和自動化補救功能的改善,這些變更就能透過服務類別目錄擴展到整個環境。Scale the solution: As systems design and automated remediation are improved, those changes can be scaled across the environment through the service catalog.
  • 持續改善: 您可以使用不同的監視工具來探索增加的改善項目。Continuous improvement: Different monitoring tools can be used to discover incremental improvements. 這些改善項目可以在下一階段的系統設計、自動化和調整中進行處理。These improvements can be addressed in the next pass of system design, automation, and scale.

改善系統設計Improve system design

改善系統設計最能有效改善任何常見平台的作業。Improving system design is the most effective approach to improving operations of any common platform. 透過改善系統設計,不僅穩定性會增加,業務中斷的情形也會減少。Through system-design improvements, stability can increase and business interruptions can decrease. 個別系統的設計不在整個雲端採用架構中所採用環境檢視的範圍內。Design of individual systems is beyond the scope of the environment view that's taken throughout the Cloud Adoption Framework.

做為此架構的補充,Microsoft Azure Well-Architected Framework 提供引導原則來改善平台或特定工作負載的品質。As a complement to this framework, the Microsoft Azure Well-Architected Framework provides guiding tenets for improving the quality of a platform or a specific workload. 此架構的重點在於改善整個結構的五個要素:The framework focuses on improvement across five pillars of architecture excellence:

  • 成本最佳化: 管理成本以將傳遞的價值最大化。Cost optimization: Manage costs to maximize the value delivered.
  • 卓越的營運績效: 追隨讓系統在生產環境中順利運作的作業流程。Operational excellence: Follow operational processes that keep a system running in production.
  • 效能效率: 調整系統以適應負載中的變更。Performance efficiency: Scale systems to adapt to changes in load.
  • 可靠性: 設計系統以從失敗中復原並繼續運作的能力。Reliability: Design systems to recover from failures and continue to function.
  • 安全性: 保護應用程式和資料,使其免於威脅。Security: Protect applications and data from threats.

技術債務和架構瑕疵會是大部分業務中斷的原因。Technical debt and architectural flaws cause most business interruptions. 針對現有部署,您可以將系統設計改善視為對現有技術債務的償還。For existing deployments, you can view system-design improvements as payments against existing technical debt. 針對新的部署,您可以將這些改善項目視為避免發生技術債務的方式。For new deployments, you can view those improvements as avoidance of technical debt.

下一個 [自動補救] 索引標籤會示範如何解決無法或不應解決的技術債務。The following Automated remediation tab shows ways to remediate technical debt that can't or shouldn't be addressed.

深入了解 Microsoft Azure Well-Architected Framework 以改善系統設計。Learn more about the Microsoft Azure Well-Architected Framework to improve system design.

系統設計改善後,請回到本文來尋找新的改善機會,並將這些改善擴展到整個環境。As system design improves, return to this article to find new opportunities to improve and scale those improvements across your environment.

自動補救Automated remediation

有些技術債務是無法解決的。Some technical debt can't be addressed. 解決方案的成本可能太高,以至於無法修正,或可能已計畫,但專案持續時間太長。Resolution might be too expensive to correct or might be planned but have a long project duration. 業務中斷可能沒有重大的商務影響。The business interruption might not have a significant business effect. 或者,商務優先權可能是快速復原,而不是投資復原能力。Or the business priority might be to recover quickly instead of investing in resiliency.

當技術債務的解決方案不是企業想要的方式時,接下來他們通常會採用自動補救。When resolution of technical debt isn't the desired approach, automated remediation is commonly the next step. 使用 Azure 自動化和 Azure 監視器來偵測趨勢並提供自動化補救功能,是最常見的自動化補救方法。Using Azure Automation and Azure Monitor to detect trends and provide automated remediation is the most common approach to automated remediation.

如需自動補救的指引,請參閱 Azure 自動化和警示For guidance on automated remediation, see Azure Automation and alerts.

使用服務類別目錄來擴展解決方案Scale the solution with a service catalog

妥善管理的服務目錄是平台特製化和平台作業的基石。A well-managed service catalog is the cornerstone of platform specialization and platform operations. 使用目錄才能將系統設計的改善和補救方法擴展到整個環境。Use of a catalog is how improvements to systems design and remediation are scaled across an environment.

雲端平台小組和雲端自動化小組會彼此配合,來為任何環境中最常見的平台建立可重複執行的解決方案。The cloud platform team and cloud automation team align to create repeatable solutions to the most common platforms in any environment. 但是,如果未能一致地使用這些解決方案,雲端管理所要付出的成本,就會比平常所付出的基準成本再多一些。But if those solutions aren't consistently used, cloud management can provide little more than a baseline offering.

若要讓最佳化平台的採用最大化,並讓維護成本降到最低,就應該將平台新增至 Azure 服務目錄。To maximize adoption and minimize maintenance overhead of any optimized platform, you should add the platform to an Azure service catalog. 您可以透過服務目錄來部署目錄中的每個應用程式,以供內部取用,或作為市集供應項目來供外部取用者取用。You can deploy each application in the catalog for internal consumption via the service catalog or as a marketplace offering for external consumers.

如需如何發佈至服務類別目錄的指示,請參閱關於發佈至服務類別目錄的文章系列。For instructions on publishing to a service catalog, see the article series on publishing to a service catalog.

從服務類別目錄部署應用程式Deploy applications from the service catalog

  1. 在 Azure 入口網站中,移至 [受控應用程式中心 (預覽)]。In the Azure portal, go to Managed applications center (preview).
  2. 在 [瀏覽] 窗格上,選取 [服務目錄應用程式]。On the Browse pane, select Service Catalog applications.
  3. 選取 [+ 新增],從公司的服務類別目錄中選擇應用程式定義。Select + Add to choose an application definition from your company's service catalog.

系統會顯示您目前正在維護的任何受控應用程式。Any managed applications you're servicing are displayed.

管理服務類別目錄應用程式Manage service catalog applications

  1. 在 Azure 入口網站中,移至 [受控應用程式中心 (預覽)]。In the Azure portal, go to Managed applications center (preview).
  2. 在 [服務] 窗格上,選取 [服務目錄應用程式]。On the Service pane, select Service Catalog applications.

系統會顯示您目前正在維護的任何受控應用程式。Any managed applications you're servicing are displayed.

持續改善Continuous improvement

平台特製化和平台作業都仰賴採用、平台、自動化和管理小組之間的強大意見反應迴圈。Platform specialization and platform operations both depend on strong feedback loops among adoption, platform, automation, and management teams. 以資料作為這些意見反應迴圈的基礎,有助於讓每個小組做出明智的決策。Grounding those feedback loops in data helps each team make wise decisions. 若要讓平台作業實現長期的商務承諾,請務必使用集中式平台專屬的深入解析。For platform operations to achieve long-term business commitments, it's important to use insights specific to the centralized platform.

容器和 SQL Server 是兩個最常見的集中管理平台。Containers and SQL Server are the two most common centrally managed platforms. 下列文章可協助您開始在這些平台上收集用於持續改善的資料:These articles can help you get started with continuous-improvement data collection on those platforms: