雲端監視指南:制訂監視策略

當您將數位轉型帶到雲端時,請務必規劃並開發適合開發人員、營運人員和基礎結構工程師參與的有效雲端監視策略。 策略應為成長導向、定義的最少,然後反復調整;一律符合商務需求。 它的結果提供了一種敏捷式作業,以組織的能力主動監視商務相依的複雜分散式應用程式。

從哪裡開始?

若要簡化您的雲端旅程,請使用雲端採用架構的 strategizing規劃 階段。 監視會影響動機、業務成果和計畫。 包含在 strategizing 和規劃階段期間的監視、您的計畫和專案。 例如,請檢查第一個採用專案如何在 Azure 中建立早期的作業管理。 想像一下雲端作業模型的外觀,包括監視的角色。 監視是以服務為基礎的方法來提供服務,這是一項作業函式,其中監視是一項諮詢服務,以及商務和 IT 取用者的專業知識。

以下是強烈影響音效監視策略的重要區域:

  • 根據應用程式的元件及其與其他相依性的關聯性,來監視應用程式的健康情況。 從雲端服務平臺、資源、網路和應用程式開始,方法是在適用的情況下收集計量和記錄。 若為混合式雲端模型,請包括內部部署基礎結構和應用程式所依賴的其他系統。

  • 藉由模擬客戶對應用程式的一般互動,納入測量應用程式效能監視計畫中的使用者體驗。

  • 請確定安全性需求符合您組織的安全性合規性原則。

  • 將警示與視為相關且實用的事件 (例如警告和例外狀況) ,並在您的事件優先順序和緊急呈報對照表之後,將嚴重性與其重要性保持一致。

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

  • 使用現有的 ITSM 解決方案(例如補救或 ServiceNow)來定義整合計畫,以產生事件或上游監視。 判斷哪些警示應轉寄、是否需要警示擴充來支援特定的篩選需求,以及如何設定。

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

在營運管理的核心中,您的 IT 組織需要針對建立、操作和管理 IT 服務的方法,建立集中式治理和嚴格的委派。

初始策略目標

作為架構設計師或策略性規劃,您可能需要為作業管理制定早期策略,在此策略中,監視會扮演主要角色。 請考慮下列四個結果:

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

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

  3. 讓您的監視解決方案處理更有效率、更快速、更順暢、更快速且能夠快速變更。

  4. 帳戶,以瞭解您的組織將如何進行規劃,並根據雲端模型來裝載監視。 致力於在組織從 IaaS 轉換至 PaaS,然後再轉換至 SaaS 時,降低您的需求。

判斷您擁有的內容

作為管理專家,您可能會與指導委員會、架構設計人員和策略性規劃人員密切合作。 您可能會藉由評估系統管理的目前狀態來規劃您的監視策略,包括:人員、夥伴、外包、工具、複雜性、差距和風險。 評量可協助您排列一組發現問題的優先順序,並選取改善目前情況的主要機會。 也請判斷可能保留在內部部署的服務、系統和資料,做為一個重要的結果。 在理想的情況下,管理需要計畫的藍圖,但在已知的規劃範圍內會有直接的比例。 討論未知的事項是很重要的。

高層級模型

當企業判斷要移動哪些服務時,您必須謹慎投資您的資源。 在內部部署環境中,您擁有監視和大量投資的所有責任。 例如,對 SaaS 服務所做的移動,不會消除您的監視責任。 您將決定誰需要存取權、誰取得警示,以及至少需要存取分析的人員。 Azure 監視器Azure Arc 是 azure 服務,可彈性地處理所有四個雲端模型中的監視案例,而不只是 azure 內的資源。 查看常見的雲端模型,如下所示。 如果您是使用組織中 Microsoft 365 服務所提供的 Microsoft Office 應用程式,除了 Azure 資訊安全中心之外,還必須包含 Microsoft 365 的安全性和合規性監視。 這包括身分識別、端點管理,以及您公司網路以外的裝置監視。

雲端模型圖表

監視通知策略

請考慮提早監視功能如何 通知策略。 許多決策相依于早期監視資料,以建立引導有限資源並增加信心的功能藍圖。 策略也需要真實世界的輸入,以監視服務啟用。

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

  • 需要使用活動記錄和安全性監視來測量機密內容的目錄使用方式和外部共用,以通知漸進式方法來分層保護功能,並透過隱私權監控達到適當的平衡。

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

稍後在本指南中,我們將探索一些常見的監視案例,或可協助加速採用的使用案例。

制訂監視架構

定義目前與未來的系統管理架構,包括監視、:

  • 將有限的資源套用到合併監視投資。

  • 決定監視將如何協助您實現企業所需的未來服務:雲端監視可高度擴充、可復原且全球感知的雲端服務。

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

  • 找出三個維度之間的監視間距, (深度、廣度,以及橫跨健全狀況模型) 。

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

  • 引導您需要進行的混合式決策。

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

  1. 藉由收集有意義且相關的信號,深入監視。
  2. 從堆疊的最低層到應用程式,監視端對端或廣度。
  3. 從美國東部到西部的重點, (可用性、效能、安全性和持續性) 。

三側 cube 範例

一些重要問題包括:

  • 您將如何塑造安全性記錄,並保護其對安全性和新隱私控制的存取?

  • 哪些服務可以全域使用,因此可以在服務邊緣進行全域監視?

  • 網路基礎結構之間的網路連線,以及服務和應用程式端點的網路連線能力,讓我們知道它是美國或雲端提供者?

  • 安全性作業與健康情況和效能有何限制? 我們要如何提供安全性作業的健全狀況和狀態摘要,以及回溯回服務擁有者?

為了組合此架構,以下有幾個考慮:

  • 從服務資產開始到堆疊的資料流程方法:基礎結構、IoT 裝置、行動裝置和其他裝置所發出的計量和記錄資料。 管理下的所有專案( () 中的監視工具)? 向上和向外移動 (ITSM 工具、全域監視、安全性資訊和事件管理 (SIEM) 、自訂警示擴充,以及其他) 。

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

  • 經濟成本。

  • 企業將如何使用記錄和計量。 Azure 監視器將大量的記錄和時間序列資料帶入監視的效能和健全狀況,類似于安全性作業的體驗。 記錄和計量是 Azure 監視器架構中的兩個主要資料元件。 這是很重要的原因:

    1. 由於您可以建立大規模的複雜雲端服務,因此會降低您的問題管理成本,以在單一位置分析、相互關聯和判斷問題的原因,進而減少直接存取資源的需求,進而提升安全性。

    2. 類似于 SIEM,Azure 監視器會將機器資料直接從內部部署資產和 Azure 資源合併 (包括活動記錄、租使用者和訂用帳戶資料,以及來自 REST 用戶端) 的任何記錄資料,並提供簡單的查詢語言,可提供比之前更遠的資料分析。

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

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

  • 工具和套件 (資料列) : (資料行:可用性、容量、安全性、持續性和合規性) 。

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

  • IT 服務管理 (的角色會 ITSM) 整合,以觸發重大事件。

請考慮您治理計畫中的單一原則,以瞭解整個企業中的事件重要性,以驅動警示和通知。 它是您監視策略中的其中一個主要原則。 下表是事件管理優先順序模型的範例,用以標準化用於通知的事件、重要性和警示。

影響嚴重性和優先權矩陣範例

制訂計畫

作為監視專家或系統管理員,您發現雲端監視的建立速度更快且更容易建立,以節省成本的示範或價值證明。 若要克服進入示範模式的趨勢,您需要保持持續的策略,並能夠在以生產為主的監視計畫上執行。 由於策略有很多不確定性和未知,因此您不會事先知道所有的監視需求。 因此,根據企業和 IT 管理的最小可行程度,決定第一組採用計畫。 您可以參考這項功能,因為這 是開始旅程的必要 功能。 以下是可協助宣告順向動作的兩個範例計畫:

  • 方案1: 為了降低目前監視投資的多樣性和複雜性,我們將投資使用 Azure 監視器第一次建立核心功能,並將相同的技能和就緒程度套用至雲端監視的其他區域。

  • 方案2: 為了決定我們如何使用我們的身分識別、存取和整體資訊保護授權方案,我們將協助安全性和隱私權辦公室在遷移至雲端時建立使用者和內容的早期活動監視,以闡明分類標籤、資料遺失預防、加密和保留原則的相關問題。

考慮調整規模

請考慮調整您的策略,以及將監視定義和標準化 為程式碼 的人員。 您的組織應計畫使用下列工具組合來建立標準化的解決方案:

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

考慮隱私權和安全性

在 Azure 中,您將需要保護資源所發出的特定監視資料,以及在 Azure 中記錄的控制平面動作,稱為活動記錄。 此外,記錄使用者活動的特製化記錄(例如 Azure Active Directory 登入和審核記錄檔),以及整合式的 Microsoft 365 統一審核記錄,因為它們包含可能需要受到隱私權法律保護的敏感性資料。

您的監視策略應該包含下列元件:

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

考慮商務持續性

Azure 監視器會收集、編制索引及分析即時電腦和資源產生的資料,以支援您的作業並協助推動業務決策。 在罕見的情況下,整個區域內的設施可能變得無法存取 (例如,由於網路故障)。 或者,設施可能完全喪失 (例如,因為天然災害)。 藉由在雲端中依賴這些服務,您的規劃並不著重于基礎結構的復原和高可用性,而是規劃下列各項:

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

建立復原計劃,並確定其涵蓋資料還原、網路中斷、相依服務失敗和全區域服務中斷。

考慮成熟度

成熟度是您監視策略的重要考慮。 我們建議您開始使用最少、收集資料和此資訊來判斷策略。 您需要的第一個監視解決方案是確保可檢視性的解決方案,包括回應式程式,例如事件和問題管理。 在這裡,您將會:

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

  • 啟用代理程式

  • 啟用資源診斷設定

  • 啟用初始警示規則

經過一段時間後,您就能在需要測量健康情況指標的需求下,獲得 Azure 監視器功能的信賴度,因此這牽涉到將焦點集中在記錄集合、啟用和使用深入解析和度量,以及定義記錄搜尋查詢,以驅動狀況良好或狀況不良的測量和計算。

學習週期包括取得主管的監視資料和見解,以及確保取用者擁有所需的監視資料。 學習週期包括持續調整和優化初始監視計畫以進行調整、改善服務,以及通知採用計畫。

監視和控制策略

1 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 和警示來源,例如 Zabbix 或 Nagios。 部署 Azure 監視器監視代理程式,並與 System Center Operations Manager 以合作方式監視的多宿主。
4 混合式遷移 監視遷移,例如,Microsoft Exchange Server 來 Microsoft 365 Exchange Online。 Exchange Online 服務健康狀態與服務使用量、安全性與合規性,全都來自 Microsoft 365。 在遷移完成之前,使用 System Center Operations Manager 逐漸解除委任監視 exchange 內部部署。
5 永遠混合 System Center Operations Manager、Azure AD、Azure 監視器、Azure 資訊安全中心、Intune 和其他專案;適用于混合數位資產的各種工具。
6 雲端原生 Azure 監視器、Azure 原則、Azure 資訊安全中心、Microsoft 365、Azure 服務健康狀態、Azure 資源健康狀態及其他。
7 多重雲端擁有的租使用者 (合併) 集中監視許多租使用者。 Azure Lighthouse、Azure 原則、Azure 監視器和 Azure Sentinel。
8 多重雲端生態系統 集中監視不同的雲端提供者: Microsoft、Amazon、Google 和其他雲端提供者。
9 提供者 > 取用者 以雲端提供者的形式監視解決方案和服務。

制訂監視需求

當您完成此程式時,您的策略可能會在結束時顯示許多。 最後,您的思維範圍會在公司網路外部延伸至工作場所、裝置和端點,以及深入瞭解身分識別即安全性界限。 以雲端監視定義的新邊緣是一種強大的吸引人誘因,與資料中心和工作場所的思維對比。

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

主要目標 目標和結果
健全狀況和狀態監視 全面性地型會觀察、測量、學習及改善服務或元件的長期擔保,包括服務層級,其中包括服務層級:可用性、容量、效能、安全性和合規性。 狀況良好的系統、服務或元件在線上、執行良好、安全且符合規範。 健康情況監視包含記錄,且具有即時健康狀態和計量的具狀態。 它也包含著重于服務使用方式的趨勢報告、見解和趨勢。
公用程式監視 觀察、測量、學習和改善系統如何提供價值的品質或定性方面。 使用者體驗是一種監視使用案例。
安全性監控 觀察、測量、學習和改進保護,以支援網路安全性策略和功能,例如安全性作業、身分識別和存取、資訊保護、隱私權、威脅管理和合規性。 使用 Azure 資訊安全中心和 Azure Sentinel 進行監視,並 Microsoft 365。
成本監視 使用 Azure 監視器和 Azure 成本管理 + 計費作為新的主要目標,來監視使用量和預估成本。 Azure 成本管理 + 計費 API 可讓您使用多維度分析來探索成本和使用方式資料。
第三個目標 目標和結果
活動監控 針對訂用帳戶層級事件、資源、使用者和系統管理員活動、內容、資料,以及您的安全性與合規性需求 Microsoft 365 等來源,觀察、測量、學習及改善使用量、安全性和合規性,以及 Azure 和 Microsoft 365。
服務使用量 服務擁有者需要分析和見解來測量、學習及改善 Azure 和 Microsoft 365 服務的使用量, (IaaS、PaaS、SaaS) 以及服務使用方式報表、分析和見解。 請確定方案包括需要存取系統管理員入口網站、儀表板、見解和報表的人員。
服務與資源健康狀態 觀察雲端資源的健康情況,以及 Microsoft 的服務中斷和諮詢,以隨時掌握有關事件和維護的資訊。 包含資源健康狀態來監視您的資源可用性,以及在可用性變更時發出警示。
容量和效能監視 為了支援健康情況監視,您的需求可能需要更深入的深度和特製化。
變更和合規性監視 觀察、測量、學習和改進資源的設定管理,現在應該會在編寫中包含安全性,並利用 Azure 原則的充分利用,以標準化監視設定並強制執行安全性強化。 記錄資料,以篩選對資源所做的金鑰變更。
身分識別和存取監視 觀察、測量、學習和改善 Active Directory、Azure Active Directory 和身分識別管理的使用方式和安全性,無論使用者、應用程式、裝置和其他資源為何,都能整合這些使用者、應用程式、裝置和其他資源。
資訊保護 不僅 Azure 監視器,但 Azure 資訊保護視方案而定,包括在 Azure 與 Microsoft 之間開發強大資訊保護原則的關鍵流量分析。
隱私權監視 組織面臨擴充隱私權的需要,包括數位資產、資料分類和資料遺失防止的資訊保護,以降低隱私權缺口和 infractions 的風險。 Microsoft 365 資訊保護包括也可以與 Azure 監視器整合的監視功能。
威脅管理和整合威脅防護 雲端將不同的傳統安全性監視角色與健康情況監視結合在一起。 例如,整合威脅防護牽涉到監視,以加速最理想的「零信任」狀態。 整合 Azure 進階威脅防護可讓您從使用 System Center Operations Manager 進行遷移來監視 Active Directory,並整合 Active Directory 安全性相關的信號,以偵測混合式環境中的先進攻擊。

Agile 方案版本

最後,您會將監視設定或解決方案提供給生產環境。 IT Operations Manager 或監視小組負責人,請考慮使用標準、簡單的分類法來改善與取用者、經理和 IT 作業的通訊。 敏捷的 DevOps 方法可確保監視內嵌于將建立和操作雲端服務的團隊內。 雖然傳統的專案管理可運作,但它的速度不夠快,也不是由營運團隊的標準實務來接受。

請在您的策略和操作模型中納入如何傳達 (解決方案) 的監視計畫、目標和設定。 例如,您可能會如何使用 Azure Boards:

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

建立最小治理

儘早建立您打算如何治理雲端監視投資的方式。 請記住,Azure 監視器是可跨管理群組和訂用帳戶看見的 使用者服務,而且使用者可以設定範圍,以使用 Azure 角色型存取控制來限制其動作。

定義誰將在 Azure 中擁有哪些層級的存取權,以支援其角色和責任。 建議您 Reader 儘早設定監視取用者的角色存取權,然後開始控制被授與角色的人員 Contributor

首先,在您的治理架構中,識別將在 Azure 中擁有和管理資源群組的角色:

  • 監視小組或資源和資源群組的一或多個系統管理員,將具有該角色的特殊許可權存取權 Monitoring Contributor

  • 應授與角色的取用者 Monitoring Reader 可以存取 Azure 監視器中的功能,以及調查每個 Azure 資源所包含的 [監視] 區段中的問題。

  • 哪些管理員需要存取其他 Azure 讀者角色,例如 Reports Reader

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

建立就緒

在早期,請制訂準備就緒計畫,以協助您的 IT 人員採用新的技能、實務和技術,在 Azure 中進行雲端監視。 請考慮包含基本需求的監視 技能就緒指導 方針,以及監視特定的技能。

下一步