可靠性 - 災害復原模式


深入瞭解結構正確的 可靠性 → 災害復原與業務連續性

模式

要尋找的位置良好的外觀
資料備份策略✅ 使用「資料匯出服務」或專屬的備份與復原服務 (例如「專用」) 以每週或每月自動匯出。匯出頻率符合 RPO 需求。重要物件資料會在需要時匯出至外部物件儲存空間。
中繼資料備份策略✅ 所有使用 Salesforce DX 來源格式在 Git 中版本化的中繼資料。僅從來源控制部署的中繼資料變更。CI/CD 銷售管道可以從儲存庫重新建立任何環境。透過 Git 歷程記錄可使用時間點復原。
檔案備份策略✅ ContentVersion 記錄、附件和文件會依排程匯出至外部儲存空間。適用於法規保留需求的自動檔案匯出。超過業務營運需求之檔案的外部歸檔系統。
備份驗證✅ 每季將逐層細分還原至完整 Sandbox 或 Developer 環境。使用逐步指示還原執行手冊中記錄的程序。測試還原會在發生災害前驗證備份完整性和完整性。
復原測試排程✅ 每季部分還原測試 (中繼資料、特定物件、檔案子集)。包含完整環境還原的年度完整復原逐層細分。已記錄學習的經驗,並在每次測試後更新執行手冊。
第三方備份服務✅ 具有時間點還原功能的自動備份。定義 RPO/RTO 的服務層級協定。每日自動驗證備份完成。儲存在多個區域的地理冗餘備份。
自訂物件與欄位✅ 包含在已排程「資料匯出服務」執行的自訂物件,公式和累計摘要欄位值已重新計算而非匯出 (沒有儲存值可供提取),以及透過個別匯出路徑處理的檔案或附件二進位項目。在還原順序中記錄和測試的複雜欄位類型和對應關係。
檔案與附件✅ 使用檔案雙位元匯出的 ContentDocument 和 ContentVersion 物件。備份的文件庫,包括資料夾結構與權限。匯出的檔案會維護重要文件類型的版本歷程記錄。
Sandbox 重新整理策略✅ 每季重新整理至完整 Sandbox 的生產組織,以進行載入測試和災害復原驗證。作為還原程序測試使用的 Sandbox 重新整理。資料遮罩會在重新整理後套用,以在測試環境中保護敏感資料。
備份監視與警示✅ 已排程備份失敗或延遲時自動化警示。顯示備份工作成功率、完成時間和資料量趨勢的顯示面板。超過可接受延遲時段之備份失敗的呼叫升級。

反模式

要尋找的位置看起來怎麼壞
備份策略⚡️ 未設定自動備份,僅依賴平台基礎結構備份。已設定第三方備份服務,但從未測試過 - 備份可能損毀或不完整。手動 Data Loader 用於備份的匯出 (執行不一致、涵蓋範圍不完整、無自動化)。
中繼資料版本化⚡️ 透過不含來源控制的變更集部署的中繼資料變更。中繼資料歷程記錄沒有 Git 存放庫。無法及時復原 - 無法在破壞性變更後還原上次已知的良好組態。
備份驗證⚡️ 已設定備份,但從未還原至測試環境。第一次還原嘗試會在實際的災害期間發生,發現範圍不完整或封存損毀。已記錄但未由備份人員測試的備份程序。
備份範圍⚡️假設「資料匯出服務」會在公式和累計摘要欄位值從未匯出 (動態重新計算,未儲存) 且檔案或附件二進位項目需要個別處理時,從而留下只有在還原時才會發現的間隙。
復原程序⚡️ 復原執行手冊包含 2 年前結構的過期步驟。由單一專家測試的復原程序,此專家已離開公司。手動程序極為複雜,因此在壓力下執行可能會發生錯誤。
備份頻率⚡️ 當業務需求為 24 小時 RPO 時,每週備份重要交易資料。不符合業務重要性的備份頻率 - 無論重要性為何,所有資料的排程皆相同。由於缺乏監視和警示,因此缺少備份排程。
法規合規性⚡️ 備份保留時間短於法規要求。例如,HIPAA 規範文件 (原則、風險分析、BAA、違規記錄) 會在其六年保留 §164.316 之前清除,或 SOX 管理財務稽核記錄會在其七年保留前刪除。稽核期間發現的合規性缺口。
檔案儲存空間⚡️ 不使用歸檔策略儲存在 Salesforce 中的大型檔案。檔案儲存空間會成長,直到組織達到限制為止。ContentVersion 記錄沒有備份 - 組織損毀時遺失的檔案。依賴使用者來維護重要檔案的個人複本。
Sandbox 測試⚡️ 從生產環境中未重新整理完整 Sandbox - 測試環境與生產環境不同。Sandbox 生產環境中的資料量 1% 會防止實際的還原驗證。將 Sandbox 重新整理視為不便而非災害復原驗證機會。
監視⚡️ 備份工作在沒有警示的情況下無聲失敗。當需要備份時,在災害期間在幾週後發現備份失敗。沒有顯示備份工作成功趨勢的顯示面板。只有在發票抵達時,才會監視備份服務健康狀況。
加密金鑰⚡️ 將 Shield 加密資料視為安全,而不保護金鑰資料:僅輪換金鑰會保持先前資料不變,但終結租戶機密 (加密切分) 或遺失「自帶金鑰」或僅限快取金鑰資料會使加密的資料永久無法復原。金鑰管理會從復原程序中省略。
跨組織相依性⚡️ 當解決方案依賴連線的應用程式、外部整合或 SSO 時,僅備份主要組織:連線的應用程式密碼、已命名認證和 OAuth 授權,以及外部驗證權杖不會被資料與中繼資料還原保留,且必須先重新設定並重新授權,才能讓復原的組織對外部系統進行驗證。當外部 SSO 是唯一的登入路徑時,無法使用的身分提供者會封鎖即使登入完全復原的組織。

模式

要尋找的位置良好的外觀
復原時間目標 (RTO) 定義✅ 按業務能力定義的 RTO,而非整個組織的統一。重要收入作業:分鐘到 1 小時。面向客戶的服務:1-4 小時。內部工具:4-24 小時。歷程記錄報告:天數。經業務利害關係人批准的 RTO。
復原點目標 (RPO) 定義✅ 根據每個能力可接受的資料遺失定義的 RPO。財務交易:近零 RPO (秒,以事件為導向的非同步複寫)。客戶記錄:near-zero (透過 CDC 分鐘)。Analytics 資料:小時 (已排程同步化)。暫存工作流程狀態:天數 (無須複製)。
小組可用性與角色✅ 記錄所有重要角色的主要和備援人員。操作 Knowledge 沒有單一失敗點。定義主要回應、第一個備份、第二個備份的升級樹狀結構。Salesforce 無法使用時,系統可存取中維護的連絡人資訊。
通訊程序✅ 事件通訊計畫,定義通知使用者、客戶、主管的人員。在 Salesforce 外部主控的外部狀態頁面,用於在平台中斷期間進行使用者通訊。主要通訊工具無法使用時,撥打小組的 SMS 通知系統。已記錄升級時間範圍 (何時從小組升級至經理到主管)。
廠商相依性對應✅ 記錄的所有重要外部廠商,包括 Salesforce、整合合作夥伴、ISV 封裝提供者。已記錄廠商 SLA 和支援時段 (相較於僅限營業時間的 24/7)。已記錄廠商升級連絡人與程序。針對重要相依性識別的替代廠商選項。
法規通知義務✅ 每個產業 (財務服務、醫療照護、政府) 記錄的必要事件通知需求。定義以符合各法規必要時段的通知時間範圍。定義誰向哪些監管機構提出通知的責任矩陣。針對快速法規通知準備的範本。
業務影響分析✅ 依收入影響、使用者影響和法規風險排名的每個業務功能。根據業務影響排名的復原優先順序。分配給災害復原的資源,與業務重要性相對。隨著業務優先順序發展逐年檢閱的影響分析。

反模式

要尋找的位置看起來怎麼壞
RTO/RPO 定義⚡️ 「系統應是可靠的」,沒有可測量的 RTO/RPO 目標。由 IT 小組定義且沒有業務利害關係人輸入的 RTO/RPO。忽略重要性差異的所有功能之間統一目標 (「所有一切都需要 99.999% 執行時間」)。
小組整備⚡️ 單一 Salesforce 管理員知道災害復原程序,但沒有文件或備份人員。呼叫輪替包含從未執行復原程序的人員。主要回應者在災害期間無法使用 (休假、病假、離開的公司)。
通訊規劃⚡️ 無通訊計畫 - 發現在事件已經進行後需要通知使用者。Salesforce 中斷期間, Salesforce 上主控的狀態頁面無法使用。在嘗試復原時等待時數通知主管。
廠商相依性⚡️ 在發生災害前不瞭解廠商 SLA 條款,並預期提供營業時間僅限的全天候支援。沒有記錄的廠商升級連絡人。復原需要 ISV 封裝提供者,但公司不再營運。
法規需求⚡️ 不瞭解強制性違規通知法規。探索 48 小時後的 24 小時通知需求。未準備任何範本 - 規範時鐘計時事件回應期間草稿化法規通知。
復原優先順序⚡️ 嘗試在災害期間同時還原所有功能,而非排定收入關鍵作業的優先順序。在處理面向客戶的訂單系統前,花費 8 小時的時間來復原內部報告功能。
測試與逐層細分⚡️ 從未透過逐層細分測試業務連續性計畫。假設有文件程序會在沒有驗證的情況下工作。由於「缺少時間」而避免桌上型演練,儘管花數天從實際災害期間未發現的問題中復原。
Knowledge轉移⚡️ 災害復原 Knowledge 專注於一位資深結構設計師,他沒有記錄任何資料。在沒有災害復原訓練的情況下上線的新小組成員。假設每個人都知道在沒有明確訓練或訓練的情況下在災害期間要執行的動作。
假設驗證⚡️ 復原程序會假設備份在 15 分鐘內可供存取,但從冷儲存中取回備份需要 8 個小時。假設小組在 30 分鐘內可用,但未定義通話輪換或升級程序。根據從未透過測試驗證的樂觀假設估計復原時間。

模式

要尋找的位置良好的外觀
RTO 結構對齊方式✅ 結構決策符合 RTO 承諾。分鐘 RTO 需要自動停機和熱門待機。小時 RTO 需要指令檔復原和溫馨的候補。RTO 接受從冷備中手動復原的天數。避免在業務不代表複雜度時過度工程。
RPO 複寫策略✅ 複製方法符合 RPO 目標。近零 RPO:透過每個記錄儲存的平台事件 (延遲傳播秒數,至少傳送一次) 進行非同步事件串流。分鐘 RPO:變更 資料擷取 非同步複寫。小時 RPO:排程的批次 API 解壓縮。RPO 天數:固定排程的手動備份。
RTO 測試✅ 在定時條件下測試的復原程序。在災害復原逐層細分期間測量的實際 RTO。已識別並修復目標 RTO 與已達成 RTO 之間的間隙。可由備份人員 (而不只是主要專家) 達成的 RTO。
RPO 驗證✅ 復原測試期間測量的資料損失。與逐層細分期間目標相比的實際 RPO。在生產環境中持續監控複製延遲。當複製落在 RPO 承諾後時設定的警示。
特定功能 RTO/RPO✅ 不同的業務功能具有不同的 RTO/RPO 目標,反映業務重要性。電子商務訂單流程:15 分鐘 RTO、近零 RPO (正確為多組織啟用/被動)。內部Knowledge庫:8 小時 RTO、24 小時 RPO (代表從備份手動還原)。
成本效益分析✅ RTO/RPO 目標與實作成本平衡。更嚴格的目標需要以指數為單位增加的投資。已記錄業務個案,其中顯示造成停機時間成本可證明災害復原投資。年度審查會確認投資與業務價值之間持續一致。
SLA 對齊方式✅ 解決方案 RTO/RPO 目標會考量平台 SLA 基準。解決方案只能透過多組織結構,提供比平台基準更佳的 RTO。將平台功能設為基礎的實際目標。
監視復原功能✅ 持續監視備份貨幣 (備份年齡與 RPO 目標)。備份排程晚時發出警示。自動驗證復原基礎結構 (次要組織、外部儲存空間) 是否在營運。
自動與手動復原✅ 積極的 RTO 目標 (分鐘) 需要最少的人力介入的自動故障切換。「仲裁 RTO 目標 (小時)」允許使用人力初始的指令檔復原。寬鬆的 RTO 目標 (天數) 接受手動復原,並遵循記錄程序。

反模式

要尋找的位置看起來怎麼壞
不實際的目標⚡️ 承諾執行需要 4 小時的手動復原程序的 15 分鐘 RTO。不含同步複製基礎結構的承諾零 RPO。由 IT 所設定且不具有結構支援的 RTO 目標。
結構錯誤對齊⚡️ 30 分鐘的 RTO 承諾,但沒有自動故障轉換和復原程序完全為手動程序。零 RPO 承諾,但僅設定每日備份。沒有對應自動化與冗餘性的積極目標。
未測試的目標⚡️ RTO 從未透過定時的災害復原逐層細分進行驗證。假設 2 小時 RTO 可達成,但在時間限制下永不實際還原。在實際災害期間發現已記錄的 4 小時 RTO 實際需要 18 小時。
統一目標⚡️ 指派相同 RTO/RPO 的所有功能,無論業務重要性為何。專為五九可用性設計的內部批次報告系統,而收入關鍵電子商務的目標相同。大量超出非關鍵能力的投資,以及重要系統的投資不足。
忽略相依性⚡️ RTO 僅假設 Salesforce 組織還原,但解決方案取決於外部身分提供者也無法使用。RPO 假設資料備份足夠,但整合認證和組態未備份。復原時間估計值會忽略還原相依系統的時間。
複製間隙⚡️ 認可 15 分鐘的 RPO,但只針對 12 個重要物件中的 3 個設定「變更資料擷取」。已設定平台事件複寫,但未監視事件傳送延遲。複製基礎結構會損毀,且在災害之前幾週都無法偵測到。
成本忽略⚡️ 承諾五九可用性,而不瞭解實作成本。未設定成本效益分析的 RTO/RPO 目標。企業不願為已認可給客戶的目標所需的基礎結構提供資金。
靜態目標⚡️ 儘管業務成長和優先順序改變,但 5 年前定義的 RTO/RPO 從未重新評估過。隨著解決方案的演進和重要性變更,目標會保持不變。缺勤年度審查流程。
文件缺口⚡️ 結構文件中記錄但未傳達給業務專案關係人的 RTO/RPO 目標。公司不知道已認可的復原功能。當業務預期 1 小時復原時發現的缺口,但結構僅支援 24 小時 RTO。
精確率為 False⚡️ 當監視基礎結構無法達到該準確度時,請致力於「99.97% 可用性」。當基本分析為粗略估計時,以錯誤準確度定義的目標表示嚴格。
監控缺勤⚡️ 不會持續監控復原功能。備份延遲 2 天,違反 RPO 承諾但未出現警示。非接收複製更新但未設定健康檢查之已啟用/被動結構中的次要組織。
不執行規劃⚡️ 具有積極 RTO/RPO 目標的美麗災害復原計畫,但沒有自動化、測試或驗證程序。為了滿足規範而建立的計畫核取方塊,但在承諾後沒有營運實情。

模式

要尋找的位置良好的外觀
資料冗餘性✅ 平台會自動提供基礎結構備份。當業務需要更快的復原時,應用程式層級複寫會補充平台備份。Change 資料擷取 或 Platform Events 會持續將重要資料複製到次要儲存空間。複製可從基礎結構備份無法解決的邏輯損毀或組態錯誤中復原。
應用程式冗餘性✅ 無國家的應用程式邏輯,可維持個別交易失敗。無法阻止水平調整的伺服器端狀態。組態的自訂中繼資料類型和自訂設定可立即在所有應用程式伺服器之間使用。任何應用程式伺服器都可以處理任何要求,而不取決於特定伺服器狀態。
整合冗餘性✅ 斷電器模式會偵測失敗的整合。當外部系統無法使用而非封鎖使用者作業時,「平台事件」便會將要求列出。與使用者面向的功能隔離的外部系統失敗。針對重要整合識別的多個外部廠商選項,可在廠商中斷期間啟用提供者快速切換。
重要工作負載的多組織模式✅ 啟用-被動模式:主要組織提供所有流量,次要組織同步但閒置,主要區域中斷期間故障切換。啟用中模式:兩個組織均會持續提供生產流量,依地理位置或業務單位配置的使用者。僅在業務需要在平台功能之外的 RPO/RTO 時,才合理進行多組織。
多組織資料同步化✅ Change 資料擷取 可為重要資料提供近乎即時的複製 (15 分鐘 RPO)。「平台事件」提供重要交易的事件串流 (近零 RPO)。參照資料的大量 API 2.0 排程複寫 (可接受 24 小時 RPO)。在兩個組織中修改相同記錄時,針對啟用中定義的衝突解決策略。
多組織啟用/被動結構✅ 美國東部地區的主要組織提供所有生產流量。歐洲地區中透過 CDC 同步化的次要組織,但閒置。DNS 路由或驗證層會將使用者導向至已啟用的組織。當主要組織連續 10 分鐘無法使用時,自動健康檢查會觸發故障切換。
多組織啟用中結構✅ 歐洲組織的 EMEA 使用者,美國組織的 AMER 使用者 (根據使用者設定檔區域欄位)。共用參考資料 (帳戶、產品) 的雙向複寫。區域資料會保留在各自的組織中 (訂單、個案)。針對客戶主要資料,衝突解決方法會使用具有區域授權機構的最後寫入成交項目。
地理分佈✅ Hyperforce 區域資料中心可啟用地理散佈。單一區域部署,平台管理的冗餘性足以達到 99.9% 的可用性。跨區域的多組織僅針對 99.95% 以上的需求或法規資料落地要求考量。
外部系統冗餘性✅ 重要外部 API 有主要和錯誤轉換端點。主要體驗持續失敗時,斷路器會切換至錯誤轉換端點。對於重要整合,偏好地使用地理冗餘的外部服務,而非單一區域提供者。
基礎結構監視✅ Trust.salesforce.com 透過狀態 API 監視。訂閱例項特定狀態通知。解決方案會在降級期間減少非關鍵負載,以動態方式回應平台健康狀態。「規模中心」會先識別資源密集型作業,再影響冗餘容量。
錯誤轉換自動化✅ 針對積極 RTO 目標,自動化錯誤轉換優先於手動。健康檢查每 1-5 分鐘執行一次,以偵測失敗。錯誤轉換決策邏輯會避免假陽性項目 (需要持續失敗,而非暫時錯誤)。如果故障切換目的地也是不健康,則自動回復。
單一失敗點✅ 結構檢閱會識別所有失敗的單一點。針對業務影響和緩解成本評估的每個識別 SPOF。透過冗餘度緩解高影響 SPOF。使用已記錄的風險接受與復原程序接受低影響 SPOF。
測試冗餘功能✅ 排程的錯誤切換逐層級會驗證自動錯誤切換邏輯。載入中測試的備份系統 (非僅限閒置的溫暖待機)。次要組織容量會在啟用中-被動測試期間驗證處理生產負載。從每個測試學習的經驗會改善自動化和程序。

反模式

要尋找的位置看起來怎麼壞
單一失敗點⚡️ 整個解決方案取決於沒有回復的單一外部 API。自訂網域提供者為 SPOF - 如果提供者失敗,則使用者無法存取 Experience Cloud。單一整合使用者帳戶 - 若停用,則所有整合都會失敗。
未測試的冗餘性⚡️ 已設定但未測試的多組織啟用/被動結構。次要組織不同步,但未設定健康檢查。第一次失敗嘗試會在實際災害期間發生,顯示次要組織損毀或無法運作。
資料同步化缺口⚡️ 已針對 30 個重要物件中的 5 個設定 CDC 複寫的啟用中被動式多組織。發生錯誤切換,但次要組織缺少 80% 的必要資料。複製延遲監視缺勤 - 次要組織晚於主要但未出現警示 3 天。
假冗餘⚡️ 假設兩個組織實際在相同 Hyperforce 區域中主控時具有多區域結構。實際使用相同上游提供者的「冗餘」外部 API。多個整合路徑,所有路由皆會透過相同的失敗點。
狀態結構⚡️ 應用程式邏輯取決於防止水平調整的記憶體內狀態。單一應用程式伺服器會保留所有使用者工作階段狀態 - 伺服器重新啟動會將所有使用者登出。在應用程式記憶體中快取靜態資源,而非在平台快取中快取,進而在整個伺服器之間產生不一致性。
無斷路器⚡️ 外部整合失敗,且每個交易都會等候完整的 120 秒逾時。單一外部系統無法使用時,所有使用者都會受到影響。無失敗分隔 - 一個失敗的整合會降低整個平台效能。
僅手動停機⚡️ 多組織結構,僅含手動錯誤移轉程序。需要 2 小時的程序,才能在業務關閉時起始故障切換。未實作自動健康檢查。無法復原決策需要執行批准以延遲復原。
產能規劃失敗⚡️ 使用已啟用/被動結構的次要組織,規模為生產負載的 20%。發生錯誤切換,但次要組織無法處理完整的生產流量。啟用中兩個組織容量為 85% 的結構,當一個組織失敗時不會留下冗餘。
組態漂移⚡️ 主要與次要組織會隨著時間而不同,因為部署未同步化。已部署至主要,但非次要的中繼資料。錯誤檢閱會顯示執行 6 個月舊程式碼版本的次要組織。
過度工程⚡️ 具有已啟用複寫的多組織結構,適用於 5 個人使用的內部管理員工具。多組織的營運複雜度不符合業務重要性。批次報告的可用性目標為 99.999% 可接受 99%。
地理誤解⚡️假設 Hyperforce「多區域」會自動提供多組織功能。不瞭解單一組織一律在單一區域中,而多個區域需要多個組織。單一組織結構無法使用以地理位置為基礎的冗餘。
整合連接⚡️ 所有整合皆為同步,且沒有非同步回復。外部系統無法使用會封鎖使用者作業。沒有排入排列機制 - 如果外部系統暫時關閉,交易會失敗。當支援整合無法使用時,使用者無法繼續。