可用性與效能模式


深入瞭解結構正確的 可靠性 → 高可用性結構

模式

要尋找的位置良好的外觀
業務影響分析✅ 每個業務能力定義的 SLO (例如「機會結束流程:99.9% 可用性、p95 延遲低於 2 秒」),而非每個技術元件
使用者流程文件✅ 每個重要使用者流程都有可測量的 SLO,涵蓋與實際使用者體驗繫結的可用性、延遲、輸出、錯誤率和復原時間
結構決策記錄✅ 根據具有已記錄邏輯的業務停機時間影響分析 (例如,內部批次報告 99% 與收入關鍵訂單處理 99.95%) 的可用性目標
SLO 規格✅ 考慮結構複雜度的實際目標 (99% = 標準平台功能、99.5% = 基本冗餘和啟用中監視、99.9% = 多區域認知和自動故障切換、99.95% = 啟用中模式和混沌測試、99.99% = 多組織結構)
平台文件✅ 解決方案 SLO 比平台 SLA 較不嚴格 (例如,平台 99.9% SLA → 解決方案 99.5% SLO),提供應用程式層失敗的錯誤預算
監視組態✅ 可透過平台儀器進行客觀測量的服務層級指標 (SLI):Trust.salesforce.com 執行時間、Experience Cloud 分析、事件監視 API 回應時間、AsyncApexJob 完成
使用者體驗度量✅ SLO 會反映完整的使用者旅程 (例如「個案提交流程:p95 使用者的 5 個步驟全部在 8 秒內完成。」非個別 API 執行時間

反模式

要尋找的位置看起來怎麼壞
結構文件⚡️ 「系統應快速且可靠」(無法測量,無法推動結構決策)
SLO 規格⚡️「所有項目都需要 99.999% 執行時間」(忽略收入作業與內部管理工具之間業務關鍵性差異的不合理成本)
監視策略⚡️ 作為主要 SLI 的基礎結構 CPU 監視 (平台度量結構設計師無法採取動作,不會反映使用者面向的體驗)
平台產能規劃⚡️ 解決方案 SLO 與平台 SLA 完全符合 99.9% (應用程式層問題、整合失敗或計畫維護沒有錯誤預算)
SLO 文件⚡️ 針對每個技術元件而非針對使用者面向的業務功能定義的 SLO (元件可用性為必要但對使用者體驗的可靠性而言不足)

模式

要尋找的位置良好的外觀
區域部署策略✅ 使用平台管理 Hyperforce 冗餘 (多個可用性區域、自動基礎結構故障切換) 的單一區域部署,可為大多數解決方案提供 99.9% 的 SLO
多組織結構✅ 僅在業務需要在平台功能之外的保證 RPO/RTO、監管地理資料隔離或完全區域獨立 (具有資料同步的啟用中-被動或啟用中-啟用) 時,才能使用多組織模式
資料複寫✅ 變更重要資料資料 (近乎即時 RPO、分鐘數)、近乎即時業務事件的平台事件、排程參考資料的大量 API 2.0 解壓縮 (24 小時 RPO)
平台健康監視✅ 訂閱 Trust.salesforce.com 狀態通知和例項特定狀態 API,以主動回應事件、維護時段和效能影響
動態載入管理✅ 解決方案在降級期間減少非關鍵批次處理,並在維護期間延後背景工作,以回應平台健康狀態
刻度中心用量✅ 每週「規模中心」檢閱可識別耗用非比例資源的長時間交易和作業,進而在影響使用者之前啟用結構修復
失敗偵測圖層✅ 多層級偵測:透過狀態 API 的平台失敗、透過逾時監視的整合失敗、透過例外記錄的應用程式失敗、透過延遲百分位的效能降級、透過 Proactive Monitoring 的容量警告
警示值✅ 警示會在錯誤率模式 (例如 60 秒內有 5 個 API 逾時) 或持續降級時觸發,而非分散式系統中正常的個別失敗

反模式

要尋找的位置看起來怎麼壞
多組織設計⚡️ 實作「即時」的多組織結構,無須具備文件化業務需求,以證明資料同步化、使用者提供、部署協調的作業複雜性
平台健康監視⚡️ 忽略 Trust.salesforce.com 狀態通知,在使用者報告失敗時探索維護期間 (反應式而非主動回應)
偵測失敗⚡️ 警示每個個別錯誤,無論速率為何 (產生警示疲勞以遮蔽重要訊號);單一 API 逾時會觸發分頁錯過 (對一般散佈系統行為的過度反應)
資料複寫⚡️ 沒有整合特定監視,只有在使用者報告封鎖的作業 (缺少外部系統健康狀況的可視性) 時才會發現整合失敗
冗餘策略⚡️ 對外部增強服務進行的同步呼叫,無逾時或回復 (當外部服務速度緩慢或無法使用時,使用者遭到封鎖)

模式

要尋找的位置良好的外觀
實際使用者監視 (RUM)✅ 透過反映實際網路條件、裝置效能、地理散佈的 Experience Cloud 分析或自訂儀器測量的實際使用者延遲
合成監視✅ 來自多個位置的自動交易,在使用者回報問題前驗證可用性和效能 (例如,從 3 個區域每 15 分鐘提交一次訂單)
交易追蹤✅ 使用每個步驟的計時工具來識別瓶頸的多步驟作業 (例如步驟 3 會針對總延遲的 70% 處理驗證呼叫帳戶)
查詢最佳化✅ 具有索引篩選條件的選擇性查詢、減少來回行程的關係查詢、使用生產規模資料量的查詢最佳化工具考量事項 (具有 10 萬筆以上記錄的行為會大幅變更)
平台快取利用率✅ 提供經常存取參考資料的工作階段或組織快取分割,在成功作業期間預先填入,當即時 API 無法使用時提供過時但可用的資料
逾時組態✅ 使用者面向的同步呼叫 5-10 秒 (回應式 UI)、背景非同步呼叫 30-60 秒 (變數外部效能)、批次處理 120 秒 (無使用者等待);每個交易的多個呼叫總預算
整合延遲監視✅ 每個與每個端點 SLO 整合的每個延遲百分位數 p50/p95/p99;延遲異常 (回應時間向上漂移) 表示在完成失敗之前產能飽和

反模式

要尋找的位置看起來怎麼壞
監視策略⚡️ 僅監視基礎結構度量 (伺服器 CPU、網路頻寬),而不使用面向流程測量 (度量不會反映實際使用者體驗)
快取策略⚡️ 對於經常存取的參考資料沒有平台快取利用率 (針對相同資料重複查詢會增加延遲並耗用 SOQL 限制)
逾時組態⚡️ 具有 120 秒逾時的同步流程呼叫,讓使用者盯著載入的旋轉器 2 分鐘 (應使用 5-10 秒逾時來回復)
效能測試⚡️ 少量資料的小規模測試 (查詢最佳化程式的行為會在超過 10 百萬筆記錄中大幅變更,使小規模結果造成誤導)
整合設計⚡️ 沒有多步驟工作流程的交易層級追蹤 (彙總度量中看不到瓶頸步驟)

模式

要尋找的位置良好的外觀
水平調整模式✅ 跨多個資源散佈的工作量:大量處理會處理每個交易的多個記錄、非同步處理會跨時間散佈工作、資料分割會跨界限散佈負載
批次處理組態✅ 最佳的批次大小平衡輸送量與管理員限制 (每個批次 Apex 執行 2,000 個記錄、每個觸發叫用 200 個記錄、每個複合 API 呼叫 25 個要求)
API 比率管理✅ 整合批次和快取可減少 API 耗用、依版本監視 24 小時 API 配置、產能規劃會在耗用前新增授權或限制增加
同時執行✅ 分割資料的並行批次工作 (5 個區域累計批次同時執行),平台事件訂閱者同時處理串流
下列深度監視✅ 針對非同步整合,排行榜深度趨勢表示需要產能增加或輸出最佳化的處理速度落後
體積異常偵測✅ 交易量明顯高於/低於預期的模式可能表示需要調查和節流的流程流失

反模式

要尋找的位置看起來怎麼壞
批次處理⚡️ 當資料量需要分割並行執行時,依序處理所有記錄 (以日期為基礎、以記錄類型為基礎或以擁有者為基礎的分割會啟用同時處理)
API 耗用⚡️ 整合模式在沒有產能規劃的情況下可增加 25% 的 API 耗用量 (突然的「API 超過限制」錯誤會影響使用者)
查詢監視⚡️ 未監視非同步整合到列深度 (處理落後於生產率且沒有可視性)
管理員限制管理⚡️ 處理大量處理的同步作業達到堆疊大小或 CPU 時間限制 (應移至具有專用限制的非同步處理)

模式

要尋找的位置良好的外觀
功能重要性階層✅ 定義的層級:重要 (收入/合規性、永不降級)、重要 (核心工作流程,僅在重大事件期間降級)、支援 (增強型體驗、整合失敗期間停用)、選擇性 (可用,在高負載期間停用)
斷電器實作✅ 電路狀態 (已結束 = 正常、未結束 = 失敗立即達到達度,半開啟 = 復原偵測);平台快取會儲存狀態,平台事件會廣播變更;會在連續失敗後開啟 (例如發生 10 個失敗)
重試邏輯✅ 暫時失敗 (1s、2s、4s、8s、cap at 30-60s) 的指數反向回應;使用反向回應重試網路逾時和 5xx 錯誤,在「重試後」標題之後重試 429 比率限制;切勿在相同交易中重試用戶端 4xx 錯誤或管理員限制錯誤
回復策略✅ 替代資料來源 (當即時 API 無法使用時的平台快取)、預設行為 (個人化服務關閉時的標準規則)、手動程序 (停滯交易的管理員介面)、重試排隊 (具有 72 小時重試的平台事件)
錯誤處理結構✅ 快速失敗 (在輸入時驗證輸入)、順暢失敗 (在 3 個失敗驗證時處理 200 筆記錄中的 197 筆記錄)、資訊性失敗 (使用交易識別碼記錄、使用者內容、堆疊追蹤)、安全失敗 (回復部分交易,請勿向使用者公開內部資料)
復原自動化✅ 平台監視會觸發自動復原:非同步重試機制、無法處理的無效信紙,以及可在無手動介入的情況下快速復原的自我修復工作流程

反模式

要尋找的位置看起來怎麼壞
整合相依性⚡️ 當外部地址驗證服務關閉時,訂單提交會完全失敗 (支援功能封鎖關鍵流程;手動檢閱應妥善降級)
斷電策略⚡️ 外部呼叫上沒有斷電器,這會造成每個交易在外部系統關閉時等候 120 秒的逾時 (所有使用者都受到一個失敗的整合影響)
重試邏輯⚡️ 在相同的交易內容中立即重試 Apex CPU 限制超過錯誤 (將再次失敗;應重新排入為具有專用限制的非同步作業)
重試邏輯⚡️ 無限期重試直到成功 (無限迴圈風險,交易永不完成;應限制重試次數上限)
錯誤處理⚡️ 嘗試捕捉區塊吞噬例外,無記錄 (操作員無法看見無法診斷和修復的失敗)
錯誤處理⚡️ 在 Lightning 頁面中顯示對一般使用者的堆疊追蹤 (安全性風險顯示實作詳細資料、使用者體驗不佳)
回復策略⚡️ 稅額計算服務無法封鎖所有訂單提交 (沒有回復的關鍵功能;應排入手動處理或使用預設費率)

模式

要尋找的位置良好的外觀
健康模式✅ 彙總健康狀態:服務狀況 (交易成功率 >99.5% 綠色、98-99.5% 黃色、<98% 紅色)、整合狀況 (全部回應綠色、降級黃色、開啟中斷器紅色)、資料狀況 (同步電流綠色、後端黃色、過時/失敗的紅色)、產能狀態 (<70% 綠色、70-85% 黃色、>85% 紅色)
事件監視✅ EventLogFile 物件,其 24 小時/1 小時傳送路由至外部 SIEM 以保留超出原生保留限制; 會捕捉 API 呼叫、頁面檢視、報告匯出、登入活動、Apex 執行
Proactive Monitoring警示✅ 持續評估會呈現 API 要求限制高峰 (75% 值觸發調查)、同時 Apex 執行失敗、SOQL 列數限制問題、儲存空間耗用趨勢
整合健康狀態顯示面板✅ 各整合度量:錯誤率 (<1% 目標)、延遲 p50/p95/p99 與 SLO、逾時率 (<0.1% 目標)、斷路器狀態、非同步排行榜深度;具有要求識別碼、端點、回應碼、持續時間的結構化記錄
可操作警示設計✅ 每個警示都會定義回應者、他們檢查的內容、他們的補救方式;包括已跨過的值、目前值、最近趨勢、顯示面板連結、執行手冊連結;與緊急程度比對的嚴重性 (使用者影響的關鍵頁面呼叫,趨勢疑慮的警告電子郵件)
異常偵測✅ 量異常 (300% 為一般負載)、錯誤率異常 (2% 與 0.5% 相較於通常,即使低於 5% 位值),延遲漂移 (漸進式上升趨勢)、行為異常 (異常的登入模式、排程外的批次工作);用於引導調查而非觸發立即升級

反模式

要尋找的位置看起來怎麼壞
事件監視⚡️「事件監視」已啟用,但從未匯出 (原生保留不足以用於趨勢分析,歷程記錄資料遺失)
警示設計⚡️ 出現「錯誤」的警示訊息,沒有上下文的上限或回應動作 (會產生警示疲勞,運算子無法有效地分級)
警示嚴重性⚡️ 將所有異常視為嚴重警示 (高假陽性率會造成警示疲勞,導致遺漏重要警示)
健康監視⚡️ 沒有彙總健康狀況模型,運算子因個別技術度量而疲勞,缺少跨系統模式
整合監視⚡️ 沒有整合特定錯誤率、延遲或斷電器狀態追蹤 (透過使用者報告反應地發現的整合失敗)
容量監視⚡️ 沒有 Proactive Monitoring 或 Scale Center 審查 (資源密集型交易的可靠性風險在生產影響之前不會被偵測到)

如需內嵌範例和詳細指引,請參閱「可靠性」支柱,或瀏覽「模式和反模式」探索器。