建立作業管理程序

當您的企業開始在 Azure 中運作工作負載時，下一步是建立「作業管理和適用性」程序。 此程序會列舉、實作，並反覆審查及最佳化這些工作負載的作業狀態。

作業適用性審查程序可確保整個工作負載組合達成對效能、可靠性和成本的商務承諾。 此程序會同步中央 IT、雲端卓越中心和工作負載小組的工作，以大規模地提供卓越作業。

建立作業適用性審查的核心程序

建立作業適用性審查程序，以充分了解在生產環境中執行工作負載所產生的問題，以及如何補救和解決這些問題。 本文概述您的企業可用來達成此目標的概要作業適用性審查程序。

在 Microsoft 的操作適用性

Microsoft 的許多小組從一開始就參與了 Azure 平台的開發。 因此很難確保此大小和複雜度的專案品質與一致性。 您需要一個健全的程序，以定期列舉和實作基本的非功能性需求。

Microsoft 遵循的程序形成了本文中所述程序的基礎。

了解角色和作業模型

作業管理是牽涉到整個公司多個角色的廣泛專業領域。 視組織作業模型而定，這些角色可能會在矩陣化環境中運作，並在集中式和分散式作業小組之間進行數個遞交。

• 中央 IT/CCoE：此集中式技術功能負責技術組合中所有技術資產的設定、作業、治理和安全性。
• 雲端作業：此作業功能是集中式技術組織內的一項功能，可管理技術組合的健康狀態和作業。 其責任包括確保程序順暢地執行、程序中的每個相鄰角色都有必要工具，而且每個後續角色都必須負責達成此程序的期望。
• 雲端策略：提供商務知識，以找出維護各種工作負載作業需求的承諾並排列優先順序。 此角色也會將風險降低成本與業務衝擊相比較，並導出最終補救決策。
• 工作負載小組：負責不同工作負載的開發和作業，這些工作負載會對應到內部部署或雲端中的特定支援應用程式、服務和基礎結構。 該角色需要深入了解工作負載架構。

每個組織的作業模型會決定上述角色的責任和日常活動：

• 集中式作業：中央 IT 對於作業負有全責。 工作負載擁有者可能會投入作業和設定，但無權變更生產環境。 只有中央 IT 和雲端作業可以提供作業變更，以改進作業適用性。
• 分散式作業：工作負載小組對於作業負有全責，通常是透過成熟的 CI/CD 管線和 DevOps 自動化。 在此模型中，對於設定、作業、治理或安全性，沒有中央支援。 這種作業方法超出了雲端採用架構的範圍。 此作業模型應該參閱 Azure Well-Architected Framework 以取得作業指引。
• 企業作業：由雲端卓越中心負責作業。 雲端作業和工作負載小組各自分擔作業適用性特定層面的責任。

審查目標

我們使用一些計量 (可靠性、效能和成本) 來評估整個組合中的作業適用性。 這些屬性結合在一起，可讓您快速評估組合中所有資產的健康狀態和適用性。 這些計量會跨作業管理的三個層級進行評估。

• 作業基準 (或增強型基準)：在所有已部署的資產上評估作業適用性 (不論其功能為何)。 這項廣泛的作業檢視可讓您掃掠變更和重大影響，但限制是無法查看個別工作負載的架構。 作業基準應涵蓋所有部署在雲端中的資源，並具有雲端作業的標準支援。 某些環境可能需要更高層級的作業支援，以符合增強型基準的需求。
• 平台作業：評估集中式技術平台的作業適用性。 此作業檢視比較精簡，因為它會考慮平台的架構，以及解決方案的變更將如何影響作業適用性。 對中央技術平台所做的變更，可能會對支援的工作負載有廣泛的下游影響。 所有任務關鍵性平台都應該獲得中央 IT 小組的專屬支援。
• 工作負載作業：評估個別工作負載的作業適用性。 此作業檢視最精簡，應該在作業適用性改進需要變更工作負載架構時考慮使用。 工作負載作業應該遵守 Azure Well-Architected Framework 的原則。 所有具有使用中 DevOps 週期的任務關鍵性工作負載，都應該獲得工作負載小組的專屬支援。

作業適用性審查目標是定期評估所有層級的作業適用性。 然後，您可以在適當的層級套用找到的改進，以告知管理整體組合所需的變更。

作業適用性審查程序

維持企業組合效能與持續性的關鍵是實作作業適用性審查程序。

從高階觀點來看，該程序有兩個階段。 在「必要條件階段」，會建立需求並對應到支援的服務。 此階段不常發生：可能每年發生一次，或在引進新的作業時才發生。 必要條件階段的輸出會在「流程階段」中使用。 流程階段較常發生，例如每個月一次。

先決條件階段

此階段中的步驟會擷取進行定期審查組合與任何任務關鍵性工作負載的需求。

1. 找出關鍵商業作業。 根據同意的商務承諾，找出企業的任務關鍵性商業作業。 商業作業與任何支援的服務功能不同。 換句話說，商業作業代表企業必須執行並由一組 IT 服務提供支援的實際活動。

   「任務關鍵性」(或「業務關鍵」) 一詞反映出作業受阻時會對業務造成重大影響。 例如，線上零售商可能會有「讓客戶將商品加入購物車」或「處理信用卡付款」等商業作業。若任一作業失敗，客戶將無法完成交易，而且企業將無法實現銷售。

2. 將作業對應到服務。 將關鍵商業作業對應到支援的 IT 服務 (基準、平台或工作負載作業)。 您也應該找出支援關鍵商務功能所需的任何技術平台或工作負載，以將作業和服務對應到負責的小組。

3. 分析服務相依性。 大部分的商業作業都必須在多個支援的工作負載和技術平台之間進行協調。 請務必了解每組支援的資產與透過這些服務完成之任務關鍵性交易流程之間的相依性。

   另請考慮內部部署服務與 Azure 服務之間的相依性。 在購物車範例中，庫存管理服務可能會裝載於內部部署環境，並內嵌由實體倉儲的員工輸入的資料。 不過，它可能會將內部部署的資料儲存在 Azure 服務 (例如 Azure 儲存體) 或資料庫 (例如 Azure Cosmos DB) 中。

這些活動的輸出是一組作業管理的「計分卡計量」。 計分卡會測量準則，例如可靠性、效能和成本。 計分卡計量表示您預期服務達成的作業準則。

計分卡應該以有助於企業負責人、雲端作業和工作負載小組彼此進行有意義討論的簡單方式表示。 例如，針對可靠性的計分卡計量可能會根據同意 SLA 的達成以色彩標示。 綠色表示符合定義的 SLA；黃色表示不符合定義的準則，但主動實作計劃性補救；而紅色表示不符合定義的準則，而且不會有任何計畫或採取任何動作。

請務必強調這些計量應該直接反映商務承諾。

服務審查階段

服務審查階段是作業適用性審查的核心。 流程有三個步驟：

1. 監視服務計量。 使用計分卡計量來監視每個作業管理層級的效能，以確保服務達成商務承諾。 作業基準中的清查和可見度服務很重要。 如果您無法監視一組與商務承諾相關的資源，請將對應的計分卡計量視為紅色。 在此案例中，補救措施的第一個步驟是實作適當的服務監視機制。 例如，若企業預期服務的正常運作時間達 99.99%，但沒有可用的生產遙測可測量可用性，請假設您不符合該需求。

2. 規劃補救措施。 針對計量低於可接受閾值的每個商務承諾，確定適當的作業小組以完成必要的補救。 該小組負責計算補救服務的成本，以將作業提升到可接受的層級。 如果補救問題的成本大於配置給該服務的預算，則中央 IT/CCoE 應該與雲端策略小組一起審查，以評估額外的投資。

3. 實作補救措施。 在雲端作業或工作負載小組取得補救計畫的認可之後，請加以實作。 每次審查計分卡計量時，都會回報實作的狀態。

此程序會反覆進行。 中央 IT/CCoE 小組負責管理流程，並向雲端策略小組報告進度。 此小組應該定期會面，以審查現有的補救專案、展開新工作負載的基本審查，並追蹤企業的整體計分卡。 小組也應該有權在補救小組 (雲端作業或工作負載作業) 進度落後或未達標時，對其問責。

審查會議

建議您定期審查作業適用性。 中央 IT/CCoE 和雲端作業小組必須出席審查。 建議雲端策略和工作負載作業小組出席，但這是選擇性的。 在頻率方面，核心小組可能會每月會面，以調整計畫並對各個小組問責。 雲端策略和所有工作負載小組可能會每季會面，以了解狀態和計量。

您可以調整程序和會議的詳細資料來符合您的特定需求。 建議以下列考量作為起點：

• 集中式作業：工作負載小組不太可能主動參與流程，但應該包含在任何報告中以進行查看。
• 分散式作業：雲端作業小組應該與工作負載小組分享用來改善技術平台的最佳做法。 工作負載小組應該分享各自工作負載的變更，以找出可套用至技術平台和作業基準的改進。

建議的資源

• Azure Automanage. Azure Automanage 會自動監視作業基準的作業適用性，並將組合中各種不同的補救策略應用自動化。
• Azure Advisor。 Azure Advisor 會根據您的使用方式和設定來提供個人化建議，以協助將您的資源最佳化。 根據預設，此工具會在整個訂閱中提供建議，以改善作業基準。 您也可以更精確地使用它來找出技術平台或個別工作負載的改進。
• Microsoft Azure Well-Architected Framework：用來改善工作負載作業或引導分散式作業的指引。