可觀察性和監視 - 模式
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 事件監視 | ✅ 事件監視專為初始結構所設計,此架構會捕捉透過非同步處理鏈與外部整合追蹤要求的關聯性識別碼 |
| 平台 | 事件監視 | ✅ 可觀察性基礎結構包含在初始衝刺時,而非在生產事件證明無法診斷後重新調整 |
| 平台 | 整合 | ✅ 已刻意放置整合檢查點,以啟用跨系統界限的要求追蹤 |
| 平台 | 平台事件 | ✅ 平台事件裝載結構化以使用交易標記和內容進行作業可視性 |
| 平台 | 自訂記錄 | ✅ 自訂記錄架構會使用完整的內容資訊 (包括使用者身分、時間戳記、持續時間和成果) 來捕捉離散事件 |
| 平台 | 度量 | ✅ 度量會彙總一段時間內的數值度量,顯示趨勢,包括 API 耗用率、Apex CPU 時間散佈,以及批次工作成功率 |
| 平台 | 散佈式追蹤 | ✅ 追蹤將同步 API 呼叫連線至非同步處理鏈、平台事件連線至訂閱者執行,以及將整合要求連線至外部系統回應 |
| 平台 | 可觀察性 | ✅ 可觀察性可讓運算子回答與系統行為相關的任意問題,而無須為每個調查部署新儀器 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 事件監視 | ⚡️ 解決方案在未經自訂記錄的情況下啟動,在生產事件無法透過平台記錄單獨進行診斷時,需要六個月後進行主要重構 |
| 平台 | 事件監視 | ⚡️ 可觀察性已改為適用於現有解決方案,這需要處理大多數元件的儀器變更,並在作業改善工作期間造成錯誤的風險 |
| 平台 | 整合 | ⚡️ 整合失敗會發生,但如果沒有全方位測量,則無法跨系統界限追蹤要求路徑 |
| 平台 | 平台事件 | ⚡️ 平台事件裝載缺少作業內容,使事件調查取決於搜尋多個系統 |
| 平台 | 自訂記錄 | ⚡️ 記錄的錄取內容不足;調查需要複製問題才能收集其他資訊 |
| 平台 | 可觀察性 | ⚡️ 預先定義的顯示面板無法回答與生產環境中系統行為相關的非預期問題 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 事件監視 | ✅ 已啟用「事件監視」以用於生產環境,此生產環境會捕捉 API 用量、登入活動、Apex 執行、SOQL 查詢、Visualforce 頁面、Lightning 頁面和報告執行 |
| 平台 | 事件監視 | ✅ 事件記錄檔案會每小時匯出至集中化記錄平台,以啟用原生平台保留以外的歷程記錄分析 |
| 平台 | 事件監視 | ✅ 外部記錄彙總可讓其他系統的企業遠程測量與關聯,以進行端對端交易追蹤 |
| 平台 | 事件監視 | ✅ 保留符合法規要求的事件記錄檔案,以進行合規性報告和長期趨勢分析 |
| 平台 | Proactive Monitoring | ✅ 系統會根據組織特定的正常營運範圍,而非接受預設值,來刻意調校 Proactive Monitoring |
| 平台 | Proactive Monitoring | ✅ Proactive Monitoring 警示會在使用者可見的事件發生前偵測 API 限制高峰、同時 Apex 失敗、SOQL 列限制方法,以及列鎖定爭用 |
| 平台 | Proactive Monitoring | ✅ 已調整的值會產生可採取動作的訊號,讓小組 Trust 並採取行動來建立持續改善的正直週期 |
| 平台 | 規模中心 | ✅ 會在解決方案穩定化期間建立「刻度中心」基準,並在每次主要版本後重新檢視 |
| 平台 | 規模中心 | ✅ Scale Center 顯示哪些作業耗用最多資源、哪些交易接近逾時值,以及最佳化投資帶來最大影響的位置 |
| 平台 | 規模中心 | ✅ 交易時間從基準提示調查增加,顯示在最新部署中導入的非意圖 N+1 查詢模式 |
| 平台 | 設定稽核追蹤 | ✅ 設定稽核追蹤可追蹤組態變更,包括權限修改、中繼資料部署和安全性設定更新,保留時間最多 180 天 |
| 平台 | 設定稽核追蹤 | ✅ 當規範或合約需求需要較長的歷程記錄時,「設定稽核追蹤」項目會匯出以保留超過 180 天 |
| 平台 | Shield | ✅ 針對包含敏感資料、需要變更歷程記錄的監管資料或重要業務資料的欄位,會選擇性啟用「欄位稽核追蹤」 |
| 平台 | Shield | ✅ 欄位稽核追蹤針對瞭解歷程值有助於作業和合規性報告的欄位提供最多 10 年的保留權 |
| 平台 | 健康檢查 | ✅「健康檢查」檢閱每季排程一次,發現結果會根據環境的風險優先順序進行補救 |
| 平台 | 健康檢查 | ✅「健康檢查」結果會受到刻意審查,而非被動接受;會記錄補償控制或不同的風險容忍 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 事件監視 | ⚡️「事件監視」已啟用,但不會匯出記錄,將調查限制為原生保留期間,並防止歷程記錄趨勢分析 |
| 平台 | 事件監視 | ⚡️ 事件記錄檔會保留在平台儲存空間中;未實作外部彙總,進而防止長期產能規劃 |
| 平台 | Proactive Monitoring | ⚡️ Proactive Monitoring 使用過敏感或過寬鬆的預設值,產生小組學習忽略的雜訊警示 |
| 平台 | Proactive Monitoring | ⚡️ 警示雜訊破壞了監視系統的Trust;小組停止回應有效的訊號 |
| 平台 | 規模中心 | ⚡️ 啟用「刻度中心」,但從未主動檢閱;效能會緩慢降低,直到使用者在數月的增量降級後抱怨為止 |
| 平台 | 規模中心 | ⚡️ 效能度量缺少基準內容;不清楚 3 秒的交易時間是一般、改善或降級 |
| 平台 | 設定稽核追蹤 | ⚡️ 未匯出「設定稽核追蹤」,保留限制會防止安全性調查或超過 180 天的合規性驗證 |
| 平台 | Shield | ⚡️ 已針對所有欄位啟用「欄位稽核追蹤」,而非選擇性地啟用,從而建立不含對應合規性值的儲存成本 |
| 平台 | 健康檢查 | ⚡️「健康檢查」結果永遠不會檢閱;安全性組態會從基準建議中漂移,而不會刻意接受 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 使用者流程 | ✅ 重要使用者流程會根據業務影響定義,並監視成功率、完成時間、捨棄點數和錯誤率的端對端 |
| 平台 | 使用者流程 | ✅ 重要流程包括產生收入的活動 (訂單提交、契約執行、機會結束)、大量活動 (登入、搜尋、記錄建立),以及規範必要的活動 (同意收集、資料主體權利履行) |
| 平台 | 使用者流程 | ✅ 流程會使用交易標記儀器,指出每個重要步驟的開始、完成、捨棄和失敗 |
| 平台 | 使用者流程 | ✅ 使用各階段平台事件 (手推車驗證、庫存檢查、付款處理、履行觸發) 進行儀表的訂單提交流程,依階段顯示成功率 |
| 平台 | 使用者流程 | ✅ 流程層級監視顯示在元件層級監視中不可見的問題,因為失敗可能會在任何轉換點發生 |
| 平台 | 使用者流程 | ✅ 當流程成功率低於可接受的值或持續時間超過延遲目標時,會觸發警示 |
| 平台 | 整合 | ✅ 整合健康監視會偵測外部系統失敗、網路問題、驗證問題和比率限制方法,再串聯至使用者面向的失敗 |
| 平台 | 整合 | ✅ 重要同步整合落在 99% 以下時的成功率監視警示 |
| 平台 | 整合 | ✅ 當在基準中不存在的新錯誤類型出現時,會出現錯誤散佈監視警示 |
| 平台 | 整合 | ✅ 同步使用者面向的通話超過 3 秒時的延遲百分位監視 (p95) 警示 |
| 平台 | 整合 | ✅ 當超過已知速率限制 80% 或 SLA 上限時,會進行輸送量監視警示 |
| 平台 | 整合 | ✅ 當任何電路開啟表示外部系統降級時,系統會警示斷電器狀態監視 |
| 平台 | 整合 | ✅ 當持續重試率超過 5% 時,會顯示可靠性問題的重試率監視警示 |
| 平台 | 整合 | ✅ 整合遠端測試路由至集中監視平台,以啟用跨系統界限的關聯性 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 使用者流程 | ⚡️ 元件會獨立監控,顯示運作狀況良好,而 12% 的使用者會捨棄重要流程,而無法看見原因 |
| 平台 | 使用者流程 | ⚡️ 元件健康狀態顯示面板會顯示綠色,而使用者無法完成重要工作流程,顯示監視結構失敗 |
| 平台 | 使用者流程 | ⚡️ 觸及多個 Apex 類別、流程、平台事件和外部整合的使用者旅程缺少端對端可視性 |
| 平台 | 使用者流程 | ⚡️ 重要業務旅程缺乏儀器;未知成功率和捨棄點 |
| 平台 | 整合 | ⚡️ 只有在串聯至使用者面向的失敗之後,才會偵測到整合失敗,而非主動偵測到 |
| 平台 | 整合 | ⚡️ 整合遠端測試在個別系統中保持隔離,進而防止跨界關聯性與根本原因分析 |
| 平台 | 整合 | ⚡️ 在完成損害後監視下游症狀的警示,而非提早發現根本原因 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | SLI | ✅ 可用性 SLI 測量時間關鍵流程從使用者觀點中成功執行的百分比 (接收預期結果,而不只是 200 狀態代碼) |
| 平台 | SLI | ✅ 延遲 SLI 測量在 p50 (中位數)、p90 (排除極端值的第 90 個百分位數)、p95 (排除極端值的第 95 個百分位數) 和 p99 (顯示最差狀況的第 99 個百分位數) 完成作業的時間 |
| 平台 | SLI | ✅ 延遲目標會因作業關鍵性和使用者期望而有所不同 (500 毫秒的搜尋感覺是立即的,輸入的相同延遲感覺是慢的) |
| 平台 | SLI | ✅ 輸送量 SLI 會測量每個時間單位的成功作業量,顯示產能利用率和成長趨勢 |
| 平台 | SLI | ✅ 與延遲結合的輸送量會顯示系統在載入增加時是否維持效能,或隨流量增加而降低效能 |
| 平台 | SLI | ✅ 錯誤率 SLI 區分錯誤類型 (使用者錯誤 (例如驗證失敗) 和系統錯誤 (例如管理員限制例外) |
| 平台 | SLO | ✅ 建立服務層級目標,並在選取結構模式之前,根據業務需求定義可接受的 SLI 值 |
| 平台 | SLO | ✅ 業務需求「銷售代表必須在 5 秒內看到機會更新」會驅動 SLO「機會詳細資料頁面載入在 3 秒內完成 (以 p95)」,這會驅動結構決策 |
| 平台 | SLO | ✅ SLO 源自業務需求並驅動結構決策,而非根據系統目前達成的目標定義 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | SLI | ⚡️ 可用性會從技術觀點 (200 個狀態代碼) 測量,而非使用者觀點 (接收預期結果) |
| 平台 | SLI | ⚡️ 僅測量中位數的延遲,而不瞭解 p95 或 p99 百分位的最差使用者體驗 |
| 平台 | SLI | ⚡️ 錯誤率 SLI 不會區分使用者錯誤與系統錯誤,會遮蔽需要不同解決方案的不同問題 |
| 平台 | SLO | ⚡️ 首先建立結構,然後將 SLO 定義為「我們目前達到的項目」,進而接受 12 秒的頁面載入,因為系統設計從未考量使用者需求 |
| 平台 | SLO | ⚡️ SLO 是以結構為導向,而非以業務為導向,並根據系統達成的項目設定目標,而非使用者需求 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 警示 | ✅ 嚴重性分類會將重要事件 (生產無法使用、資料損毀風險、安全性損毀) 立即路由至呼叫工程師的頁面 |
| 平台 | 警示 | ✅ 高嚴重性事件 (效能降低、部分中斷) 會產生通知,以在營業時間內進行提示調查 |
| 平台 | 警示 | ✅ 警告 (即將即將到來,設定漂移) 會產生每日摘要通知以主動修復 |
| 平台 | 警示 | ✅ 警示內容包括受影響的使用者計數、錯誤訊息、堆疊追蹤、最近部署、相關警示,以及相關顯示面板的連結 |
| 平台 | 警示 | ✅ 透過啟用立即嚴重性評估和調查,而不收集基本資訊,以減少確認的平均時間 |
| 平台 | 警示 | ✅ 警示分組可防止警示風暴,其中會針對單一基本問題觸發數百個相關警示 |
| 平台 | 警示 | ✅ 整合失敗會觸發一個依整合端點分組的警示,其中顯示過去 5 分鐘內 156 個失敗的要求,其中包含延遲圖、錯誤分佈和顯示面板連結 |
| 平台 | 警示 | ✅ 警示抑制可防止已知暫時狀況在預期的維護期間或自動修復期間產生警示 |
| 平台 | 警示 | ✅ 系統會在排程維護期間、部署後的前幾分鐘在快取時抑制警示,以及在重試邏輯成功時短暫失敗時抑制警示 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 警示 | ⚡️ 所有警示都會路由至相同的管道,無嚴重性分類;重要事件不會與例行警告區分 |
| 平台 | 警示 | ⚡️ 警示缺少診斷內容;通話工程師必須先透過個別查詢收集基本資訊,才能評估嚴重性 |
| 平台 | 警示 | ⚡️ 整合失敗會在 5 分鐘內產生 156 個個別警示,進而壓倒通話工程師的電話,每個警示皆相同,時間戳記除外 |
| 平台 | 警示 | ⚡️ 警示風暴無法讓回應者區分單一基本問題與數百個相關症狀 |
| 平台 | 警示 | ⚡️ 警示會在已知維護期間與暫時狀況期間觸發,產生損毀監視Trust的雜訊 |
| 平台 | 警示 | ⚡️ 來自雜亂的假陽性訊息的警示疲勞會造成小組忽略降低回應效率的通知 |