| 觸發分類/類型 | 緩解 |
|---|---|
| 人員 | 原則 |
| 程序 | 手冊、連續性計畫 |
| 技術 | 冗餘 |
| 觸發 | 緩解 | 基本 | 中繼 | 成熟 |
|---|---|---|---|---|
| 新增或離開員工的使用者存取權變更 | 服務層級契約 (SLA) 和佈建或取消佈建使用者的需求 | 根據 SLA 手動佈建和取消佈建使用者以進行手動變更。 | 根據 SLA 的排程變更,透過排程工作處理使用者變更。 | 透過 SSO/IDM 解決方案自動化使用者佈建和取消佈建。 |
| 模式 | 防模式 | |
|---|---|---|
| 風險管理 | 在您的業務中:
- 已建立的風險評估架構正在使用中。 - 風險會分類為人員、流程和技術領域。 |
在您的業務中:
- Salesforce 的風險評估架構為臨時。 - 未清楚識別風險。 |
| 在您的文件中:
- 系統會根據客戶影響來分類和評估風險嚴重性。 - 降低風險和回應計畫的優先順序。 |
在您的文件中:
- 評估風險嚴重性或種類時,不會考量客戶觀點。 - 風險降低和回應計畫會嘗試捕捉所有可想像的風險。 |
|
| 失敗緩解 | 在您的組織中:
- 失敗點觸發及其對應的緩解計畫會依人員、程序和技術分類。 - 緩解控制會立即生效、隨著時間成熟,並盡早納入自動化。 - 為了確保最佳的延展性,在將變更發佈至生產環境之前,會完成全方位測試和最佳化。 - 在業務關鍵事件之前,根據 SLA 執行規模測試和最佳化。 |
在您的組織中:
- 無法分類失敗點數的觸發。緩解措施不存在或僅臨時使用。 - 不會重新檢視或改善緩解控制。 - 自動化未用於緩解問題。 |
| 監視與可觀察性 | 在您的組織中:
- 針對檢查和異常偵測,已啟用「Proactive Monitoring」。 - 為了持續可視性,Proactive Monitoring 警示會與「規模中心」整合。 |
在您的組織中:
- 只會執行手動健康檢查,且不會進行持續監控。 |
| 模式 | 防模式 | |
|---|---|---|
| 輸送量 | 在您的設計標準中:
- 如何使用平台快取的指引遵循 平台快取最佳作法 |
在您的設計標準中:
- 如果有平台快取使用指引,則其不明確或不符合最佳作法。 |
| 在您的組織中:
- 大量化用於資料和系統作業。 - DML 或資料庫方法一律會對應 Apex 中的集合。 - 資料庫中 DML 期間用於較短 elapsedTime 的欄位受到限制。 - 所有萬用字元條件都會用於 SOSL。 - SOQL 陳述式為選擇性。 -- 他們不使用 LIKE 比較或部分文字比較。 -- 比較運算子會使用正數邏輯 (換句話說,INCLUDES 或 IN) 作為其主要邏輯或僅限邏輯。 -- = NULL 和 != NULL 用於使用時,很少一律遵循正比較運算子。 – 為了儘量減少資料載入並發揮最大效能,系統只會在 SOQL 查詢中提取所需的欄位。 -- 未使用 LIMIT 1 陳述式。 -- 不使用「所有列」關鍵字。 - 盡可能偏好非同步處理。 - 已設定平台快取分割。 |
在您的組織中:
- DML 陳述式未大量處理。 - DML 或資料庫方法會對應 Apex 中的單一記錄。 - SOSL 並不常用於萬用字元選取條件。 - SOQL 陳述式為非選擇性: -- 其中包含 LIKE 與萬用字元篩選條件。 -- 使用 !=、NOT 或 NOT IN 條件的比較會作為主要或唯一比較運算子使用。 -- 使用 = NULL 和 != NULL 條件作為主要或唯一比較運算子。 -- 使用 LIMIT 1 陳述式。 -- 使用 ALL ROWS 關鍵字。 - SOQL 會顯示在迴圈內。 - 偏好同步程序。 |
|
| 延遲 | 在您的組織中:
- 報告用於單一特定目的,且包含決策所需的最少列數與欄數。 - 篩選條件使用「equals」和「not equal to」。 - 篩選條件不包含公式欄位。 - 共用模式會盡可能簡化。 - 自訂 UI 元件使用 Lightning Web 元件 (LWC)。 - LWC 使用 Lightning Data Service 進行資料作業。 - 在 JavaScript 的用戶端處理排序和篩選清單資料。 - Salesforce Edge 已啟用。 |
在您的組織中:
- 報告可用於多種用途,或包含決策不需要的額外列與欄。 - 篩選條件使用「contains」和「does not contain」。 - 篩選條件包含公式欄位。 - 共用模式很複雜。 - 自訂 UI 元件使用的架構可能會導致呈現效率低於 LWC (例如 Aura 或 Visualforce)。 - LWC 使用 Apex 進行資料作業。 - 使用 Apex 在伺服器端處理排序和篩選清單資料。 - Salesforce Edge 未啟用。 |
| 模式 | 防模式 | |
|---|---|---|
| 資料建模 | 在您的設計標準中:
- 商業理由保證自訂物件存在的標準和指引。 |
在您的設計標準中:
- 沒有建立自訂物件的標準存在。 |
| 在資料模型中:
- 盡可能使用標準物件。 - ApexGuru 檢查是否有防模式,確認 SOQL 查詢是選擇性的,並避免結構描述使用效率低下。 - 表格會針對刻度反正規化。 |
在資料模型中:
- 您已複製標準物件。 - 表格已正規化以避免冗餘。 |
|
| 在您的業務中:
- 低程式碼產生器會瞭解 Salesforce 支援的不同欄位類型,並在選取欄位資料類型之前評估報告和加密需求。 - 決定在物件之間建立「主要 - 詳細資料」關係之前,請評估該關係的共用與資料誤差影響。 |
在您的業務中:
- 低程式碼產生器會選取資料類型,而無須評估下游報告和加密需求。 - 決定在物件之間建立「主要 - 詳細資料」關係之前,請勿評估該關係的共用與資料誤差影響。 |
|
| 資料量 | 在您的資料中:
- 沒有父系記錄具有超過 10,000 個子系記錄。 - 未將使用者指派給相同物件類型的超過 10,000 個記錄。 - 沒有例項包含指向相同記錄的對應欄位超過 10,000 個記錄。 - 大量資料載入會根據 ParentId 欄位值排序為批次。 - 為了確保批次策略不會同時損毀,規模測試用於驗證生產規模的大量負載模式。 - 大量資料載入至生產環境不會在營業時間高峰期間發生。 - 大量資料載入僅包含業務決策所需的最小資料。 |
在您的資料中:
- 存在超過 10,000 個子系記錄的記錄。 - 系統會將使用者指派給相同類型的超過 10,000 個記錄。 - 存在超過 10,000 筆記錄具有指向相同記錄之對應欄位的例項。 - 大量資料載入不會根據 ParentId 欄位值進行批次排序。 - 大量資料載入至生產環境會在營業時間高峰期間發生。 - 大量資料載入不限於業務決策所需的最少資料。 |
| 在流程與 Apex 中:
- 在資料誤差有疑慮的情況下,邏輯存在於跨多個父系記錄散佈子系記錄數目。 - 當透過整合匯入或複製記錄時,邏輯會將記錄指派給適當的人類使用者。 - 針對 Apex 集合 (例如清單和集),存在處理多個記錄的邏輯,以將查詢最小化並最佳化資料處理。 - 撰寫和部署符合可調整程式碼標準和最佳作法的有效 Apex 程式碼。 |
在流程與 Apex 中:
- 無論已指派的子系記錄數目為何,子系記錄都會隨意指派給父系記錄。 - 透過資料載入或整合建立的記錄會指派給一般「整合使用者」。 - 來自相同物件的多個遞迴 SOQL 查詢在同步交易中,進而造成高堆疊使用量。 - 開發人員撰寫 Apex 程式碼時,會導入效率低下和效能反模式。 |
|
| 在您的業務中:
- 您已記錄並實作資料歸檔和清除策略 |
在您的業務中:
- 您沒有資料歸檔和清除策略,或者您的策略已記錄但未實作 |
| 工具 | 描述 | 可用性 | 績效 | 延展性 |
|---|---|---|---|---|
| 大型物件 | 在平台上儲存及管理大量資料。 | X | ||
| 程式碼掃描器 | 掃描 Apex 程式碼以瞭解效能問題。 | X | ||
| 自訂索引 | 使用自訂索引改善查詢效能。 | X | ||
| 刪除資料 | 移除不需要的資料以改善效能。 | X | X | |
| 分部 | 分割資料以限制查詢和報告中的記錄數。 | X | ||
| 規模測試 | 測試系統效能並解譯結果。部署至生產環境之前,若要驗證延展性和效能,請使用 Playwright 或 JMeter 指令檔模擬大規模的 UI 和 API 工作量。 | X | X | |
| 規模中心 | 取得有關系統效能的自助式服務和即時洞察。尋找長時間執行的交易、例外熱點和輸出瓶頸。在開發週期中稍早診斷規模問題。 | X | X | |
| ApexGuru | 在「刻度中心」中使用此以 GenAI 為基礎的功能,以在執行階段偵測 Apex、SOQL 和測試類別的反模式。透過 ApexGuru 與 Salesforce Code Analyzer 的整合,在開發工作流程中取得 AI 強化的建議和內嵌修正。使用這些建議和修正程式可解決熱點,並改善查詢選擇性、大量處理、快取用量和測試品質。 | X | X | |
| Salesforce 程式碼分析器 | 使用 IDE、CLI 或 CI/CD 掃描程式碼,以確保程式碼符合最佳作法。透過 Salesforce Code Analyzer 與 ApexGuru 的整合,直接在開發人員工作流程中取得效能反模式的相關洞察。 | X | ||
| Salesforce Edge 網路 | 透過 Salesforce Edge 網路路由您的 我的網域,以改善下載時間和使用者體驗。 | X | ||
| Skinny 表格 | 避免在經常使用欄位的表格上加入。 | X | ||
| 主動監視 | 持續監視記錄成長、擁有權偏差和效能迴歸的異常。在規模問題變為嚴重之前警示。 | X | X |
| 資源 | 描述 | 可用性 | 績效 | 延展性 |
|---|---|---|---|---|
| 規模化挑戰需要數百萬美元 — 以下是如何讓業務展望未來 | 探索實作延展性如何促成永續成長和長期成功。 | X | X | |
| 使用「規模中心」建立及部署可調整應用程式 | 瞭解如何主動評估並解決 Salesforce 實作中的效能問題。 | |||
| 分析複雜 Salesforce 應用程式中的效能與規模熱點 | 處理您組織中的效能與延展性問題。 | X | X | |
| 應用程式不應在熱門時段的流量中驚慌 - 準備方式如下 | 瞭解成功規模測試的四個關鍵步驟。 | |||
| 已解釋 ApexGuru AI 引擎 | 瞭解 ApexGuru 如何使用自訂訓練的模型、實際組織遙測和智慧篩選,以提供精確、內容相關且可運作的洞察。 | X | X | |
| 使用 ApexGuru 最佳化應用程式和 Agentforce 的 Apex | 瞭解 ApexGuru 如何協助開發人員偵測和修正效能反模式,包括 SOQL、DML、除錯和測試效率不佳。使用 ApexGuru 作為 AI 技術支援的教練,以擴充應用程式的開發和 Agentforce 的實作。 | X | X | |
| ApexGuru 反模式 | 從 ApexGuru 偵測到的反模式官方文件庫中學習,此文件庫會針對每個主要 Salesforce 版本更新。 | X | X | |
| 使用大量資料進行部署的最佳作法 | 瞭解大量資料的流程影響。 | X | ||
| Salesforce Edge 網路的 考量事項 | 瞭解如何讓您的組織準備好使用 Salesforce Edge 網路。 | X | ||
| 設計標準範本 | 為您的組織建立設計標準。 | X | X | X |
| 資料模型設計考量事項 | 最佳化規模與維護的資料模型。 | X | X | |
| 針對企業規模設計記錄存取權 | 透過組態最佳化存取控制效能。 | X | ||
| 具有大量資料系統的基礎結構 | 瞭解支援大型資料部署之系統效能的功能。 | X | ||
| 批次管理的學習資源 | 瞭解批次管理。 | X | X | |
| Lightning Experience 效能最佳化 | 改善您組織中的 Lightning Experience 以協助您的使用者加速工作。 | X | ||
| 在 Salesforce 中管理對應誤差以避免記錄鎖定例外 | 瞭解如何將對應誤差的影響降到最低。 | X | X | |
| SOQL 與 SOSL 最佳作法 | 針對具有大量資料的部署,遵循 SOQL 與 SOSL 最佳作法。 | X | X | |
| 大規模重新對齊方式的工具 | 有效率地計畫並執行重新對齊。 | X | ||
| 使用遮蔽 | 在不同的應用程式中維護大型資料集。 | X | X |