雲端監視策略

本文是雲端監視指南 系列文章的 一部分。

當您的組織移轉至雲端環境時，請務必規劃及開發有效的監視策略，並讓開發人員、營運人員和基礎結構工程師參與。 策略應該是以成長為導向的，以最低限度定義，然後反復調整。 它應該一律符合商務需求，並產生敏捷組織，以主動監視商務相依的複雜分散式應用程式。

哪裡可以開始？

若要簡化雲端旅程，請使用 雲端採用架構的策略 和 規劃 階段。 在您的策略和規劃階段中包含所有計劃與專案的監視。

例如，檢查第一個採用專案如何在 Azure 中建立早期作業管理。 想像一下雲端作業模型需要的外觀，包括監視的角色。 監視最適合使用以服務為基礎的方法，作為作業功能，其中監視是諮詢服務，也是企業和 IT 取用者的專業知識提供者。

以下是影響健全監視策略的重要領域：

• 根據元件及其與其他相依性的關係，監視應用程式的健康情況。 從雲端服務平臺、資源、網路，以及應用程式開始，收集適用的計量和記錄。 針對混合式雲端模型，包含應用程式所依賴的內部部署基礎結構和其他系統。

• 藉由模擬客戶與應用程式的一般互動，測量應用程式效能監視計畫中終端使用者的體驗。

• 請確定安全性需求與您的組織安全性合規性政策對應。

• 排定相關和實際事件的警示優先順序，例如警告和例外狀況。 在您的事件優先順序和急迫性呈報矩陣之後，將其嚴重性與重要性保持一致。

• 只收集對企業和 IT 組織有用的、可測量且可識別的計量和記錄。

• 針對事件產生或上游監視，定義與現有 IT 服務管理 （ITSM） 解決方案的整合計畫，例如補救或 ServiceNow。 判斷應該轉送哪些警示、是否需要警示擴充以支援特定的篩選需求，以及如何設定。

• 瞭解誰需要可見度、需要查看的內容，以及如何根據其角色和責任將其視覺化。

在作業管理的核心，IT 組織必須建立集中式治理，並嚴格委派建置、操作和管理 IT 服務的方法。

初始策略目標

身為架構設計人員或策略規劃師，您可能需要制定早期營運管理原則，其中監視扮演了主要角色。 請考慮下列四個結果：

1. 在進入生產環境時管理雲端生產服務，例如網路、應用程式、安全性和虛擬基礎結構。

2. 套用有限的資源，以合理化您現有的監視工具、技能和專業知識，並使用雲端監視來降低複雜性。

3. 讓您的監視解決方案流程更有效率、更快速且更順暢地大規模地工作，而且也能夠快速變更。

4. 說明貴組織如何根據雲端模型規劃及裝載監視。 當組織從 IaaS 轉換至 PaaS，然後轉換為 SaaS 時，請努力降低您的需求。

判斷您擁有的內容

您可以與指導委員會、建築師和戰略規劃師密切合作。 您可以評估系統管理的目前狀態，包括人員、合作夥伴、外包、工具、複雜度、差距和風險，來制定監視策略。 評量可協助您排定一組發現的問題優先順序，並選取改善目前情況的主要機會。 此外，判斷可能保留在內部部署的服務、系統和資料，作為一個重要結果。 在理想情況下，管理想要計畫藍圖，但與已知的規劃範圍直接成正比。 討論未知專案很重要。

高階模型化

當企業決定要移至雲端的服務時，您需要仔細投資您的資源。 針對內部部署，您擁有監視的所有責任，並投入大量資金。 例如，針對 SaaS 服務所做的動作不會消除您的監視責任。 您將決定誰需要存取權、誰取得警示，以及至少需要存取分析的人員。 Azure 監視器 和 Azure Arc 是一項服務，可彈性地解決所有四個雲端模型的監視案例，而不只是 Azure 內的資源。 查看常見的雲端模型，如下所示。 針對 Microsoft 365 服務所提供的 Microsoft Office 應用程式lication，除了適用於雲端的 Microsoft Defender 之外，您還需要包含 Microsoft 365 的安全性與合規性 監視。 您應該包含公司網路外部的身分識別、端點管理和裝置監視。

監視通知策略

許多策略決策取決於早期監視資料，以建置功能藍圖，以引導有限的資源並增加信心。 策略也需要監視服務啟用的實際輸入。

請考慮監視在策略中扮演的角色，以累加方式保護和保護數位資產：

• 需要活動記錄和安全性監視，以測量目錄使用量和敏感性內容的外部共用，以通知累加式方法來分層保護功能，並達到與隱私權監視的正確平衡。

• 原則和基準會通知合理化目標（移轉、隨即轉移或重新架構），並改善資料與資訊可從內部部署移轉至雲端服務的信心。

本指南稍後會探索一些有助於加速採用的常見監視案例或使用案例。

制定監視架構

定義您目前和未來的架構，以監視以：

• 在資源有限時合併您的監視投資。

• 決定監視如何協助啟用您業務需求的未來服務。

• 與您將在雲端中監視的未來服務和資源一致。

• 識別健康情況模型的三個維度（深度、廣度和跨度）之間的監視差距。

• 建立支援成本效益分析的財務層面、成本和支援因素的模型。

• 引導您需要做出的混合式決策。

監視的其中一個準則是服務可見度。 若要讓服務、資產或元件完全可見，您需要平衡此原則的三端，也就是：

1. 收集有意義的相關訊號，以深入監視。
2. 從堆疊的最低層到應用程式，監視端對端或廣度。
3. 透過著重于健康情況層面的東向西部監視：可用性、效能、安全性和持續性。

一些關鍵問題包括：

• 您要如何共用安全性記錄並保護其存取權？

• 哪些服務可全域使用，因此能夠在服務邊緣進行全域監視？

• 您的網路基礎結構與服務與應用程式端點的網路連線之間的網路點為何，以指出您的系統或雲端提供者是否有問題？

• 安全性作業與健康情況和效能的界限為何？ 如何提供健康情況和狀態摘要給安全性作業，以及相反情況，回到服務擁有者？

若要組合此架構，以下是數個考慮：

• 請考慮從服務資產開始的資料流程方法，並啟動堆疊：基礎結構、IoT 裝置、行動裝置和其他裝置所發出的計量和記錄資料。 管理到監視工具的所有專案（中介層）？ 向上和向外移動（ITSM 工具、全域監視、安全性資訊和事件管理（SIEM）、自訂警示擴充和其他專案。

• 是否要繼續使用 System Center Operations Manager 或其他監視工具。

• 經濟成本。

• 企業如何使用記錄和計量。 Azure 監視器會將大量的記錄和時間序列資料帶入監視的效能和健康情況端，類似于安全性作業體驗。 記錄和計量是 Azure 監視器架構的兩個主要資料元件。 基於下列原因，它們很重要：

  1. 因為您可以建置大規模的複雜雲端服務，因此您的問題管理成本會降低。 您可以在某個位置分析、相互關聯及判斷問題的原因，進而減少直接存取資源的需求，進而改善安全性。

  2. 與 SIEM 類似，Azure 監視器會合並來自內部部署資產和 Azure 資源的機器資料，包括活動記錄、租使用者和訂用帳戶資料，以及來自 REST 用戶端的任何記錄資料。 您可以使用查詢語言來分析資料，遠遠超出之前可能的資料。

請考慮您的資料流程和工具：

• 來源和類型：遙測、追蹤、具狀態、時間序列。

• 工具和套件（資料列）：資料行：可用性、容量、安全性、持續性和合規性。

• 全域監視或最上層的角色。

• 在重大事件上觸發 ITSM 整合的角色。

請考慮治理計畫中的單一原則，以取得驅動警示和通知的事件重要性。 這是監視策略中的重要原則之一。 下表是事件管理優先順序模型的範例，可標準化用於通知的事件、重要性和警示。

制定計畫

身為監視專家或系統管理員，您已發現雲端監視更快速且更容易建立，導致成本低廉的示範或價值證明。 若要克服保持示範模式的傾向，您必須隨時掌握策略，並能夠在以生產為主的監視計畫上執行。 因為策略有很多不確定性和未知因素，因此您不會事先知道所有的監視需求。 因此，根據對企業和 IT 管理最可行的方案，決定第一組採用計畫。 您可以將這項功能稱為開始旅程 所需的功能 。 以下是兩個可協助宣告向前動作的範例計畫：

• 方案 1： 為了減少目前監視投資的多樣性和複雜性，我們會先投資使用 Azure 監視器建立核心功能，因為相同的技能和整備適用于雲端監視的其他領域。

• 方案 2： 為了決定如何使用授權方案進行身分識別、存取和整體資訊保護，我們將協助安全性和隱私權辦公室在移轉至雲端時建立使用者和內容的早期活動監視，以厘清分類標籤、資料外泄防護、加密和保留原則的問題。

考慮調整

請考慮調整您的策略，以及誰將定義和標準化 監視即程式碼 。 您的組織應該規劃使用下列工具組合來建置標準化的解決方案：

• Azure Resource Manager 範本。
• Azure 原則監視計畫定義和原則。
• GitHub 可建立腳本、程式碼和檔的原始檔控制。

考慮隱私權和安全性

在 Azure 中，您必須保護資源發出的特定監視資料，以及記錄在 Azure 中的控制平面動作，稱為活動記錄。 此外，記錄使用者活動的特殊記錄，例如 Microsoft Entra 登入和稽核記錄，如果整合，則 Microsoft 365 統一稽核記錄檔全都包含可能必須受隱私權法保護的敏感性資料。

您的監視策略應包含下列動作：

• 將非監視資料與監視資料分開。
• 限制對資源的存取。

考慮商務持續性

Azure 監視器會收集、編制索引及分析即時機器和資源產生的資料，以支援您的作業，並協助推動商務決策。 在罕見的情況下，整個區域中的設施可能會變得無法存取，例如網路失敗。 或者設施可能會完全失去，例如由於自然災害。 透過這些服務傳輸至雲端，您的規劃不會著重于基礎結構復原和高可用性。 相反地，它正在規劃：

• 從 Azure 中所有相依服務和資源擷取資料的可用性、其他雲端中的資源，以及從內部部署擷取資料。
• 深入解析、解決方案、活頁簿和其他視覺效果的資料可用性、警示、與 ITSM 和其他控制平面服務的整合，Azure 支援您的操作需求。

建立復原方案，並確定其涵蓋資料還原、網路中斷、相依服務失敗，以及全區域服務中斷。

考慮成熟度

您的監視策略將會成長和發展。 最好從收集資料開始，這有助於判斷您的策略。 您想要的第一個監視解決方案是確保可觀察性，以包含回應式程式，例如事件和問題管理。

• 建立一或多個 Log Analytics 工作區。

• 啟用代理程式。

• 啟用資源診斷設定。

• 啟用初始警示規則。

當您對 Azure 監視器功能有信心時，可以藉由擴充記錄集合、啟用和使用深入解析和計量，以及定義記錄搜尋查詢，以推動健康情況或狀況不良狀況的測量和計算，開始測量健康情況指標。

在學習週期中，您將取得主管手中的監視資料和深入解析，並確保適當的取用者擁有所需的監視資料。 學習週期包括持續調整和優化初始監視計畫，以調整、改善服務，以及通知採用計畫。

DIKW 模型通常用於學習。 動作和決策會從 資料 移至 資訊 、 知識和 智慧 。

監視是您在 Azure 中建置之服務的基礎。 您的策略可以解決新式監視的這五個專業領域，以協助您定義最低可行的監視，並取得步驟的信心。 將您的功能從反應式移至主動式，並將其觸達範圍調整為終端使用者，只是一個目標。

• 監視： 首先，您應該專注于建立監視，以觀察 Azure 服務和資源的健全狀況和狀態。 設定基本監視，然後使用 Azure 原則 和 Azure Resource Manager 範本自動執行，以建立服務及其保固的初始可見度：可用性、效能或容量、安全性和設定合規性。 例如，根據 Azure 監視器的最低可行設定、設定用於監視和診斷的資源、設定警示和深入解析。 針對事件和問題等服務工作，包括監視取用者的知識和整備程度、定義和觸發事件。 成熟度的一個指標是可以自動化多少，以減少不必要的人力成本，以手動觀察健康情況和狀態。 知道哪些服務狀況良好，與對狀況不良的服務發出警示一樣重要。

• 量值： 設定從所有資源收集計量和記錄，以監視有問題的徵兆/狀況、指出服務可用性的潛在或實際影響，或服務/應用程式的取用者的影響。 例如：

  • 在應用程式中使用功能時，是否顯示回應時間延遲、選取某個專案或沒有回應時傳回錯誤？

  • 藉由測量服務或應用程式的公用程式，確保服務符合服務合約。

• 回應： 根據已知問題的內容來觀察和測量、評估哪些限定為 Bug、自動修復，或需要根據分類為事件、問題或變更的內容來手動回應。

• 學習和改進： 透過這兩個相互依賴的專業領域，提供者和取用者會參與學習週期。 他們會透過深入解析、報表和活頁簿取用監視資料。 使用這些方法來微調和優化監視組態，以持續改善目標服務。 變更也很重要。 監視設定會隨著業務、技術、雲端提供者和其他服務的變更而變更，以發展服務保固。

為了協助您調整監視計畫與策略，請使用下表來分類更詳細發生的不同監視案例。 請記住，在 規劃階段稍早引進的五 Rs 合理化。 如果您使用 System Center Operations Manager，則可以使用混合式和雲端選項來合理化您的投資。

類型	監視目標	範例目標
1	僅限內部部署	System Center Operations Manager。 繼續監視服務、基礎結構、在擁有的資料中心內建立應用層的網路，而不需要任何雲端考慮。
2	內部部署至雲端	繼續使用 System Center Operations Manager，並套用 Microsoft 365 和 Azure 管理元件。
3	在雲端和內部部署中執行服務的內部部署至/與雲端（合作式）	使用 Azure 監視器建立初始監視。 連線 Azure 監視器至 System Center Operations Manager 或 System Center Operations Manager 受控執行個體（預覽）和警示來源，例如 Zabbix 或 Nagios。 部署 Azure 監視器監視代理程式，並與 System Center Operations Manager 合作監視。
4	混合式移轉	例如，監視 Microsoft Exchange Server 至 Microsoft 365 Exchange Online 的移轉。 Exchange Online 服務健康情況和服務使用方式、安全性和合規性，全都來自 Microsoft 365。 您可以使用 System Center Operations Manager 受控執行個體 （預覽版）。 如果您使用 System Center Operations Manager，請逐漸解除委任監視內部部署與 System Center Operations Manager 的交換，直到移轉完成為止。
5	混合式永遠	System Center Operations Manager 受控執行個體 （預覽）、Microsoft Entra ID、Azure 監視器、適用於雲端的 Microsoft Defender、Intune 等;一系列混合數位資產的工具。
6	雲端原生	Azure 監視器、Azure 原則、適用於雲端的 Microsoft Defender、Microsoft 365、Azure 服務健康狀態、Azure 資源健康狀態等。
7	多雲端擁有的租使用者 （合併）	集中監視許多租使用者。 Azure Lighthouse、Azure 原則、Azure 監視器和 Microsoft Sentinel。
8	多重雲端生態系統	集中監視不同的雲端提供者：Microsoft、Amazon、Google 等。
9	提供者 > 取用者	以雲端提供者身分監視解決方案和服務。

制定監視需求

當您完成此程式時，您的策略可能會顯示最終還有很多工作要做。 最後，監視應該延伸到公司網路到工作場所、裝置和端點，以及向外延伸至身分識別即安全性界限。 雲端監視所定義的新邊緣與資料中心和工作場所思維形成鮮明對比。

您可以使用 Azure 來逐漸管理內部部署資源的所有或部分層面，即使是保留在內部部署的服務。 您也想要根據您企業採用的雲端服務模型，來定義責任的監視界限，以符合企業雲端採用策略。 即使是以 IaaS 為基礎的服務，您也會透過 Azure 服務健康狀態取得計量、記錄、檢視和警示功能。 您可以使用資源健康情況設定 Azure 資源的可用性監視警示。 使用 SaaS 服務，例如 Microsoft 365，已提供許多服務，而且您必須設定適當的入口網站、儀表板、分析和警示存取權。 從服務的觀點來看，具有 Microsoft 365 Exchange Online 等分散式元件的大型服務有許多目標，而不只是需要觀察其健康情況和狀態。

主要目標	目標和結果
健康情況和狀態監視	全面觀察、測量、學習及改善服務或元件的長期保固，包括服務等級，並結合在一起：可用性、容量、效能、安全性和合規性。 狀況良好的系統、服務或元件在線上、執行良好、安全且符合規範。 健康情況監視包含記錄，且具有即時健康情況狀態和計量的具狀態。 它也包含以服務使用量為重點的趨勢報告、深入解析和趨勢。
公用程式監視	觀察、測量、學習及改善系統如何提供價值的品質或質化層面。 使用者體驗是監視使用案例的一種類型。
安全性監視	觀察、測量、學習及改善保護，以支援網路安全性原則和功能，例如安全性作業、身分識別和存取、資訊保護、隱私權、威脅管理和合規性。 使用 適用於雲端的 Microsoft Defender 和 Microsoft Sentinel 和 Microsoft 365 進行監視。
成本監視	使用 Azure 監視器和 Azure 成本管理 + 計費作為新的主要目標來監視使用量和預估成本。 Azure 成本管理 + 計費 API 可讓您使用多維度分析來探索成本和使用量資料。

第三專案標	目標和結果
活動監視	觀察、測量、瞭解及改善來自 Azure 活動記錄、稽核記錄和 Microsoft 365 統一稽核記錄等來源的使用、測量、瞭解及改善使用量、安全性和合規性，以取得訂用帳戶層級事件的動作、資源動作、使用者和系統管理員活動、內容、資料，以及 Azure 和 Microsoft 365 的安全性與合規性需求。
服務使用量	服務擁有者想要分析和深入解析來測量、學習及改善 Azure 和 Microsoft 365 服務（IaaS、PaaS、SaaS）與服務使用量報告、分析和深入解析的使用方式。 確定方案包含誰需要存取系統管理入口網站、儀表板、深入解析和報表。
服務和資源健康情況	觀察雲端資源的健康情況，以及 Microsoft 的服務中斷和諮詢，以隨時掌握事件和維護的相關資訊。 在監視資源可用性時包含資源健康情況，並針對可用性變更發出警示。
容量和效能監視	為了支援健康情況監視，您的需求可能需要更深入和特製化。
變更與合規性監視	觀察、測量、學習和改善資源的組態管理，這些資源現在應包含安全性，並受到良好使用Azure 原則來標準化監視組態並強制執行安全性強化的影響。 記錄資料，以篩選正在對資源進行的金鑰變更。
身分識別和存取監視	觀察、測量、瞭解及改善 Active Directory、Microsoft Entra ID 和身分識別管理的使用和安全性，以整合使用者、應用程式、裝置和其他資源，無論其位置為何。
資訊保護	Azure 資訊保護，視方案而定，包括跨 Azure 和 Microsoft 的健全資訊保護原則至關重要的流量分析。
隱私權監視	組織面臨不斷擴大的隱私權需求，包括保護數位資產、資料分類和資料外泄防護，以降低隱私權缺口和違規的風險。 Microsoft 365 資訊保護包含也可以與 Azure 監視器整合的監視功能。
威脅管理和整合式威脅防護	雲端將安全性監視的個別傳統角色與健康情況監視結合在一起。 例如，整合式威脅防護涉及監視以加速零信任的最佳狀態。 適用於身分識別的 Microsoft Defender可讓您整合 Active Directory 安全性相關訊號，以偵測混合式環境中的進階攻擊。

敏捷式解決方案版本

最後，您將將監視組態或解決方案傳遞到生產環境。 請考慮標準、簡單的分類法，以改善與取用者、經理和 IT 作業的通訊。 敏捷式 DevOps 方法可確保監視內嵌在將建置和操作雲端服務的小組內。 雖然傳統的專案管理有效，但速度不夠快，而且通常被營運小組視為標準做法。

在您的策略和作業模型中納入如何傳達監視計畫、目標和設定（解決方案）。 例如，您可以使用 Azure Boards 的方式：

敏捷式字詞	要包含的內容	範例
Epic	廣泛監視， 監視策略計畫	合併 Azure 雲端監視， 混合式雲端監視， 私人雲端監視， 建立核心監視服務
功能	個別監視， 方案和專案	監視需求， 監視取用者和提供者、 目標 工具 排程
使用者劇本和工作	最終結果是監視組態或解決方案	網路監視 （例如 ExpressRoute）， 標準化的 IaaS VM 監視（例如，適用於 VM 的 Azure 監視器、Application Insights、Azure 原則、設定、原則、報表、工作區。

建立最小治理

儘早建立您想要治理雲端監視投資的方式。 請記住，Azure 監視器是一個 租 使用者服務，可跨管理群組和訂用帳戶可見度，且 Azure 角色型存取控制可以限制使用者許可權。

定義誰將在 Azure 中擁有何種層級的存取權，以支援其角色和責任。 您應該儘早設定監視取用者的讀取者角色存取權，然後控制被授與參與者角色的人員。

首先，識別哪些角色將擁有和管理 Azure 中的資源群組，作為治理架構的一部分：

• 決定監視小組或一或多個資源和資源群組的系統管理員是否具有監視參與者角色的特殊許可權存取權。

• 選取應獲授與監視讀取者角色的取用者，以存取 Azure 監視器中的功能，並調查每個 Azure 資源隨附的監視區段內的問題。

• 選擇哪些管理員需要存取其他 Azure 讀取者角色，例如報表讀取者角色。

總而言之，您的監視取用者角色可能需要廣泛的存取權，而您的開發人員和系統管理員只需要特定 Azure 資源的角色型存取權。 作為另一項限制，請確定您免除讀取者存取機密監視資料，例如安全性、登入和使用者活動記錄。

建立整備程度

在早期，制定整備計畫，以協助 IT 人員採用 Azure 中雲端監視的新技能、做法和技術。 請考慮技能整備指引 。

下一步

雲端部署模型的監視策略