| 臨時組織 | Developer Sandbox | Developer Pro Sandbox | 複製 Sandbox 部分 | 完整 Sandbox | |
|---|---|---|---|---|---|
| 支援 組織形式 | 是 | 否 | 否 | 否 | 否 |
| 支援 來源追蹤 | 是 | 是 | 是 | 否 | 否 |
| 壽命 | 1–30 天 | 手動控制 | 手動控制 | 手動控制 | 手動控制 |
| 重新整理間隔 | 不提供 | 1 天 | 1 天 | 5 天 | 29 天 |
| 版本預覽支援 | 由開發人員控制 | 根據 Sandbox 例項 | 根據 Sandbox 例項 | 根據 Sandbox 例項 | 根據 Sandbox 例項 |
| 佈建時間 | > 5 分鐘 | 小時或天數 | 小時或天數 | 小時或天數 | 小時或天數 |
| 中繼資料決定者 | 來源控制 | 生產 | 生產 | 生產 | 生產 |
| 資料決定者 | 手動資料載入 | 手動資料載入 | 手動資料載入 | Sandbox 範本 | 生產 |
| 資料限制 | 200 MB | 200 MB | 1 GB | 5 GB | 與在生產環境中相同 |
| 工作 | 組織形狀 | 來源追蹤 | 經常重新整理 | 版本預覽支援 | 來自生產的所有中繼資料 | 來自生產的部分中繼資料 | 生產環境中的大型資料集 | 來自生產的部分資料集 | 相容環境 |
|---|---|---|---|---|---|---|---|---|---|
| 原型 | X | X | X | X | X | X | X | 臨時組織、開發人員與開發人員 Pro Sandbox | |
| 新功能調查或概念證明開發 | X | X | X | X | X | X | X | 臨時組織、開發人員與開發人員 Pro Sandbox | |
| 使用者接受度測試 | X | X | X | X | X | X | Developer、Developer Pro 和 Partial Copy Sandbox | ||
| 效能與規模測試 | X | X | X | 完整 Sandbox | |||||
| 使用者訓練 | X | X | X | X | X* | X | Developer Pro、部分複製與*Full Sandbox | ||
| *如果完成特定類型工作的必要項目,請使用資源密集性較低的環境 | |||||||||
| 模式 | 防模式 | |
|---|---|---|
| 發行管理 | 在生產環境中:
- 中繼資料顯示使用穩定版本機制,例如: -- 將中繼資料組織為解除鎖定的封裝 -- DevOps Center 已啟用並安裝 -- 透過使用來源格式的中繼資料 API 進行部署 - 部署記錄在可用歷程記錄內不會顯示失敗的部署。 - 部署歷程記錄會顯示清楚的版本步調,以及版本視窗內相當統一的部署叢集。 |
在生產環境中:
- 中繼資料表示使用以組織為基礎的發行機制,例如: -- 主動使用變更集 -- 透過中繼資料 API 進行的部署使用 package.xml 格式 - 部署記錄會在可用歷程記錄中顯示失敗部署的重複例項。 - 部署沒有可辨識的步調或顯示不平均的部署叢集,這表示有熱修復和臨時回復)。 - DevOps Center 未啟用且未安裝。 |
| 在您的藍圖和文件中:
- 版本名稱清楚。 - 功能會明確繫結至特定已命名版本。 - 版本名稱可搜尋且可探索。 - 小組可以找到並遵循明確的原則來標記具有正確版本名稱的成品、開發項目和其他工作。 - 您可以透過版本名稱來提取版本資料清單的清晰檢視。 - 系統會針對不同的開發階段,定義生成式 AI 應用程式的品質水準。 |
在您的藍圖和文件中:
- 不包含版本名稱。 - 功能未明確繫結至特定版本。 - 版本名稱為特殊使用或不存在。 - 小組以不同的方式參照物件、開發項目和其他工作。 - 無法使用版本名稱來提取版本資料清單的清晰檢視。 - 系統不會定義生成式 AI 應用程式的品質界限,或者如果已定義,則不會定義不同開發階段的品質界限。 | |
| 環境策略 | 在您的組織中:
- 採用來源驅動的開發和版本模型。 - 已針對 Developer 與 Developer Pro Sandbox 啟用來源追蹤。 - 指定環境中的中繼資料獨立於版本成品。 - 環境不會直接對應至釋出路徑。 - 變更的發行路徑取決於變更的類型 (高度風險、中度風險或低度風險)。 - 不存在擁擠的環境。 - 永遠不會直接在生產環境中進行有風險的組態變更。 - 在營業時間高峰期間不會發生發行。 - Data 360 Sandbox 用於適當測試需要 Einstein 資料庫、Knowledge 文章和非結構化資料的代理使用個案 |
在您的組織中:
- 採用以組織為基礎的開發和版本模型。 - 未針對 Developer 與 Developer Pro Sandbox 啟用來源追蹤。 - 指定環境中的中繼資料是版本成品。 - 環境會直接對應至釋出路徑。 - 無論變更類型為何,每個變更的版本路徑皆相同。 - 存在的環境過度擁塞。 - 直接在生產環境中進行有風險的組態變更。 - 發行會在營業時間高峰期間發生。 - 不會使用 Data 360 Sandbox 測試需要 Einstein 資料庫、Knowledge 文章和非結構化資料的 Agentforce 工作人員 |
| 訊號策略 | 在您的組織中:
- 小組可協同合作定義和標準化健康檢查 API 和 SLO。 - 定期審查和精簡訊號策略是死後與營運整備審查的一部分。 在生產環境中: - 會針對所有應用程式實作健康檢查。 - 應用程式會提供有關其健康狀況 (例如載入與功能) 的明確訊號。 - 應用程式的設計目的為在相依性不良時順利降級。 - 載入分割用於防止串聯失敗。 在您的設計中: - 反壓力與負載機制可防止服務遭到流量溢出。 - 系統會假設相依性最終會失敗。訊號處理常式是為了減輕失敗而建立。 |
在您的組織中:
- 小組在孤立作業中,建立不一致且不相容的健康訊號機制。 - 訊號策略是事後考量,只有在事件發生時才會處理。 在生產環境中: - 元件會無訊息表示其健康狀態的情況下無聲失敗。 - 應用程式會無限期重試對不健康服務的要求。 - 所有要求都會以相同的優先順序處理,無論其重要性為何。 - 為了找出問題,運算子僅依賴反應性措施,例如使用者抱怨或重大系統故障。 在您的設計中: - 假設所有相依性一律可供使用,且不會考慮網路分割、延遲高峰或其他常見問題。 - 應用程式接受所有傳入要求,即使應用程式載入過多,進而導致延遲增加且失敗的可能性更高 |
| 測試策略 | 在您的業務中:
- 可用性測試採用各種裝置和輔助技術。 - 模擬器用於複製類似生產的條件,以進行延展性和效能測試。 - 測試會在變更進入來源控制時自動執行。 - 應用程式開發週期中的多個間隔執行耐力、壓力、效能和規模測試,並將其視為進行中的工作。 - 當您擁有 B2C 規模應用程式、大量使用者或大量資料時,您可將刻度測試納入 QA 流程的一部分。 - 您的刻度測試專注於系統的高優先順序層面。 - 您的刻度測試具有已定義的條件。 - 您在完整 Sandbox 中執行規模測試。 - 提示工程包含人類的品質檢閱。 - Agentforce 測試中心用於強大的工作人員測試。 |
在您的業務中:
- 不會執行可用性測試,或者如果是,則會在有限的裝置上執行。 - 不會測試類似生產的使用者要求、API 流量和網路速度變化。 - 測試自動化未準備就緒。 - 耐力、壓力、效能、刻度測試視為開發階段。 - 您不會在 QA 流程中執行刻度測試,且擁有 B2C 刻度應用程式、大量使用者或大量資料。 - 您的刻度測試未排定優先順序。 - 您的刻度測試沒有正確定義的條件。 - 您在 Partial Copy 或 Developer Sandbox 中執行刻度測試。 - 提示工程不包括人類的品質檢閱。 - Agentforce 工作人員未經測試,或僅使用工作人員產生器進行臨時測試。 |
| 在您的組織中:
- 所有測試資料都會清除敏感且可識別的資料。 |
在您的組織中:
- 測試資料與生產資料相同。 | |
| 在 Apex 中:
- 資料工廠模式用於單元測試 - 用於模擬 API 回應的模擬程式與實體。 |
在 Apex 中:
- 單元測試依賴組織資料。 - 未使用粗體及粗體。 | |
| 在您的設計標準和文件中:
- 環境會依其支援的測試類型進行分類。 - 根據風險、使用個案或複雜度指定適當的測試模式。 |
在您的設計標準和文件中:
- 每個環境支援哪些測試類型並不清楚。 - 測試模式不會依風險、使用個案或複雜度分類。 |
| 事件類型 | 外觀觸發 | 復原策略 |
|---|---|---|
| 系統缺勤 | 損毀的登入或帳戶存取權的問題 | 帳戶復原原則 |
| 服務無法使用 | 啟用冗餘的備份服務;手動因應措施 | |
| 生產程式錯誤 | 最近變更 | 先前版本的部署回復或取消部署 |
| 新的無法解釋錯誤 | 手動因應措施、停用非必要功能、升級至 SME |
| 模式 | 防模式 | |
|---|---|---|
| 復原時間 | 在您的業務中:
- 系統會定期實作復原通訊協定。 - 小組瞭解他們在生產環境中擁有且負責的服務。 - 小組瞭解相關工具以支援問題的診斷。 |
在您的業務中:
- 復原通訊協定不存在或未定期執行。 - 不清楚哪些小組在生產環境中擁有並負責不同的服務。 - 小組沒有工具的指引或標準來支援問題的診斷。 |
| 在您的文件中:
- 系統會依事件類型與觸發定義及分類復原策略。 - 事件回應的結束條件包含在 SLO 中且清楚明確。 - 事件期間增加權限的啟用條件和指派邏輯已清楚明確。 - 事件回應權限集與授權會清楚列出。 - 存在疑難排解指南,協助識別和診斷常見問題。 |
在您的文件中:
- 事件回應會臨時執行。 - 不存在事件回應的結束條件。 - 未指派增強權限,或如果是,則會臨時指派權限。 - 事件回應權限集與授權未列出。 |
|
| 在您的組織中:
- 存在以工作階段為基礎的事件回應權限集,且可在復原期間指派給支援人員。 - 「設定稽核追蹤」顯示指定的復原測試人員在協議的時間登入測試環境,並遵循復原測試指令檔。 |
在您的組織中:
- 以工作階段為基礎的權限集不存在於事件回應中,否則支援人員不獲授權使用。 - 「設定稽核追蹤」顯示指定的復原測試人員未登入測試環境或未遵循復原測試指令檔 | |
| 在測試計畫中:
- 復原測試的測試指令檔存在且可重複。 - 系統會清楚列出事件模擬的環境。 |
在測試計畫中:
- 不存在用於復原測試的測試指令檔。 - 未建立事件模擬的環境。 |
|
| 能力分級 | 在您的業務中:
- 在事件發生前,會識別應警示支援複雜問題的中小型企業或利害關係人。 - 交付與支援小組之間的交談是上線的一部分。 - 如有諮詢,Salesforce 結構設計師可快速回應並協助小組專注於復原。 |
在您的業務中:
- 在事件發生之前,不會識別應警示的 SME 或利害關係人。 - 傳送小組與支援小組之間的交談不是版本流程的一部分。 - Salesforce 結構設計師會將事件回應視為其工作範圍外。 |
| 在您的文件中:
- 支援人員可以探索並閱讀指定解決方案中使用的系統和設計模式。 |
在您的文件中:
- 指定解決方案中使用的系統和設計模式無法供支援人員使用。 |
|
| 在您的組織中:
- 記錄和自訂錯誤訊息會納入整個系統的執行路徑。 |
在您的組織中: - 不使用記錄和自訂錯誤訊息。 | |
| 監視與警示 | 在您的組織中:
- 警示僅用於通知使用者需要人力介入的情況;其他失敗會記錄並進行報告。 - 警示會傳送給能夠回應警示的使用者。 - 如果可能,會在可能失敗之前傳送警示。 |
在您的組織中:
- 當發生任何類型的失敗時會傳送警示,無論是否需要後續動作。 - 將需要技術解決方案之問題的警示傳送給業務使用者。 - 警示只會針對已經發生的失敗傳送。 |
| 在您的文件中:
- 系統會根據直接和間接生成式 AI 回饋意見度量定義提示調整警示的項目條件。 |
在您的文件中:
- 沒有針對生成式 AI 應用程式觸發提示調整警示的條件定義。 |
| 模式 | 防模式 | 業務連續性 | 在您的業務中:
- 採用「復原優先」心態,專注於盡快使優先順序最高的業務功能和功能不受影響。 - 有維護排程可供檢閱 BCP 測試計畫。 |
在您的業務中:
- 「修正問題」心態是事件管理的唯一方法。 - 不會定期重新整理 BCP 測試計畫。 |
|---|---|---|
| 在您的文件中:
- 存在 BCP,其中包含在 Salesforce 無法使用時繼續處理或分級資料的步驟、觸發使用 BCP 的事件清單,以及 BCP 測試的步驟和間隔。 - BCP 包含上游和下游系統和相依性。 |
在您的文件中:
- BCP 不存在、不完整或僅包含 Salesforce。 |
|
| 在測試計畫中:
- 系統會考慮與程序和人員相關的 BCP 區域。 |
在測試計畫中:
- 不會考慮與程序和人員相關的 BCP 區域。 | |
| 技術持續性 | 在您的業務中:
- 您已評估是否需要建立有意的冗餘或錯誤系統 - 事件復原策略會盡可能自動化。 |
在您的業務中:
- 您尚未評估有關有意冗餘或停機系統的需求 - 事件復原策略完全為手動。 |
| 在您的文件中:
- BCP 會考慮小組可能需要的額外資源或中斷程序,以有效回應事件。 |
在您的文件中:
- BCP 不包含作業支援需求。 |
|
| 備份與還原 | 在您的文件中:
- 資料與中繼資料皆有備份與還原策略。 |
在您的文件中:
- 備份與還原策略不存在,或者如果存在,則不完整,僅套用至資料或僅套用至中繼資料,而非兩者。 |
| 在貴公司:
- 備份會儲存在僅授權使用者可存取的安全位置。 - 測試計畫和測試記錄顯示資料還原每年至少在完整或部分複製 Sandbox 中進行兩次測試。 |
在貴公司:
- 備份並非人類可讀。 - 備份會儲存在未經授權的業務使用者可存取的位置。 - 沒有資料還原流程,或者資料還原流程未經測試。 |
| 工具 | 描述 | 應用程式週期管理 | 事件回應 | 持續性規劃 |
|---|---|---|---|---|
| Apex 锤子測試 | 瞭解目前和新版本中的 Salesforce Apex 測試。 | X | ||
| Apex Stub API | 建立模擬架構以簡化測試。 | X | ||
| 備份與復原 | 自動產生備份以防止資料遺失。 | X | ||
| 大型物件 | 在平台上儲存及管理大量資料。 | X | ||
| 欄位歷程記錄追蹤 | 追蹤並顯示欄位歷程記錄。 | X | ||
| 取得您組織的採用與安全性洞察新視窗中的開啟連結 | 監視您組織中 Lightning Experience 的採用與使用狀況。 | X | ||
| 管理大量資料載入工作 | 使用「大量 API」建立更新或刪除大量記錄。 | X | ||
| 管理即時事件監視事件 | 管理事件監視串流和儲存空間設定。 | X | ||
| 資料與儲存資源 | 檢視您 Salesforce 組織的儲存空間限制與使用量。 | X | ||
| 監視器除錯記錄 | 監視記錄並設定標記以觸發記錄。 | X | ||
| 使用登入鑑識監視登入活動 | 識別可能表示身分詐騙的行為。 | X | ||
| 使用設定稽核追蹤監視設定變更 | 追蹤管理員最近進行的設定變更。 | X | ||
| 監視訓練歷程記錄 | 檢視使用者已參加的 Salesforce 訓練課程。 | X | ||
| 監視背景工作 | 監視您組織中的背景工作。 | X | ||
| 監視排程的工作 | 檢視報告快照、排程的 Apex 工作和顯示面板重新整理。 | X | ||
| 規模測試 | 測試系統效能並解譯結果。 | X | ||
| 主動監視 | 使用 Salesforce 監視服務將中斷降到最低。 | X | ||
| Salesforce Data Mask | 自動遮罩 Sandbox 中的資料。 | X | ||
| 系統概觀頁面 | 檢視您組織的使用狀況資料與限制。 | X | ||
| 使用 force:lightning:lint | 透過 Salesforce CLI 分析和驗證程式碼。 | X |
| 資源 | 描述 | 應用程式週期管理 | 事件回應 | 持續性規劃 |
|---|---|---|---|---|
| 效能與規模測試中的 7 個防模式 | 避免在效能和規模測試中出現常見的反模式。 | X | ||
| 分析複雜 Salesforce 應用程式中的效能與規模熱點 | 瞭解解決您組織中效能與延展性問題的方法。 | X | ||
| 建立災害復原計畫 (Trailhead) | 建立災害復原計畫。 | X | ||
| 業務連續性不僅僅是備份與還原 | 全方位檢視 BCP。 | X | ||
| 設計標準範本 | 為您的組織建立設計標準。 | X | ||
| Salesforce 中的 診斷與監視工具 | 瞭解如何改善實作的品質與效能。 | X | ||
| 業務持續性規劃的指導原則 | 檢閱有效 BCP 的基礎基本原則。 | X | ||
| 如何在 Salesforce 上規模測試 | 瞭解規模測試生命週期的五個階段。 | X | ||
| 效能測試簡介 | 瞭解如何開發效能測試方法。 | X | ||
| 監視您的組織 | 瞭解自助式服務監視選項。 | X | ||
| 測試策略範本 | 建立和自訂規模和效能測試計畫。 | X | ||
| 測試策略範本 | 確定測試策略已完成。 | X | ||
| 瞭解來源驅動的開發 (Trailhead) | 瞭解封裝開發和臨時組織。 | X |