可靠性

Salesforce 透過自動故障轉換和基礎結構層級彈性,在多個區域之間作業彈性基礎結構。平台會處理資料中心冗餘、網路可用性和基礎結構修補程式,並在 Trust.salesforce.com 中顯示即時平台可用性狀態。

您設計此基礎結構上執行的所有項目可靠性:在管理員限制內調整規模的資料模型、預期失敗和復原失敗的交易、偵測解決方案何時偏離可用性目標的監視,以及在發生失敗時還原業務作業的災害復原程序。

Salesforce SLA 涵蓋平台,但您擁有高於基礎結構層級之所有項目的可靠性。您負責定義並達成您自己的服務層級目標 (SLO),即您業務所需的可靠性目標。無論平台 SLA 層級為何,應用程式層級的可靠性仍由您負責。保證可用性的相同平台也會限制:管理員會限制每個租戶的資源消耗上限,讓任何單一租戶都無法降低其他租戶的平台。因此,您的解決方案必須在這些限制之內順暢地調整規模,而不只是要求更多容量。

不可靠的解決方案會產生階層式的業務影響。當商務平台無法使用時,收入流程會變慢。當內部工具在工作流程中失敗時,生產力會下降。當資料損毀或記錄遺失時,Trust 會損毀。這些問題會隨著因應措施的累積和技術債務的增加而加劇。

可靠性並非要防止所有失敗。分散式系統發生失敗。可靠性是設計預期失敗、協助包含爆炸半徑和自動還原服務的系統。可靠性需求會因業務影響而有所不同。例如,需要 99.9% 可用性的面向客戶 Experience Cloud 入口網頁涉及與容忍偶爾延遲的內部批次報告流程根本上不同的結構選擇。

可靠性與「傑出作業」密切相關聯。地址監視、事件回應和系統可用性。此重疊是意圖的,非偶然的。區別在於設計時間與執行時間。

可靠性是您在執行系統之前在系統中建立的內容,包括:

• 先前提及在管理員限制內調整規模的資料模型
• 預期失敗並復原的交易
• 包含爆炸半徑的冗餘與斷路器
• 復原目標 - 復原時間目標 (RTO) 和復原點目標 (RPO),可決定系統在發生錯誤時的行為。

可靠性是您解決方案的結構內容。

「傑出作業」是您在執行系統後操作、改善和維護系統的方式,包括:

• 降低變更風險的部署作法
• 在事件期間引導您小組的執行手冊和升級路徑
• 呈現訊號的可觀察性銷售管道
• 隨著時間改善系統的回饋意見迴圈。

「傑出作業」已實作;其為您解決方案周圍的人類與程序規範。

兩個支柱之間的共用基礎是監視與可觀察層。監視是以可靠性為考量之的設計。您應建立可觀察的系統。其會作為「傑出作業」的考量執行。小組會根據這些系統告訴您的內容採取行動。可靠性涵蓋您所內建的結構模式,例如警示值和健康狀態顯示面板。「傑出作業」涵蓋您小組回應訊號的方式,例如執行手冊和通話回應。

請考慮以下差異:可靠性說明「此系統是否能存取?」同時「傑出作業」說明「您的小組可以操作嗎?」由沒有執行手冊、不一致部署或沒有回饋意見迴圈的小組所操作的完全可靠系統,實際上仍會失敗。在營運上優秀的小組管理脆弱且設計不佳的系統,將會因無法預防的事件而遭到壓倒。兩個支柱都是必要的,且兩者都不會替代另一個支柱。

可靠性並非獨立運作。如先前章節所述,「傑出作業」是其最接近的合作夥伴。兩個支柱共用可觀察性層級,其中「可靠性」定義您在系統中建立的內容,而「傑出作業」定義您小組的作業方式。Trust 也需要可抵禦攻擊並維護資料完整性的基礎結構:如果系統可能遭到入侵,則系統不可靠。「資源最佳化」可防止管理員限制枯竭,確保平台在大規模上保持可靠性。「成本最佳化」會將可靠性投資與其提供的業務價值進行平衡。可用性目標正確地說明達成目標所需的結構複雜性。單一支柱無法在隔離中產生設計良好的解決方案 — 可靠性提供其他支柱所依賴及加強的結構基礎。

使用這些原則來引導您的架構決策以瞭解平台上的可靠性。

• **透過大量處理分配工作量。**在單一交易中處理多個記錄,而非依賴每個記錄的連續作業。大量處理會在單一交易中處理的批次之間共用管理員限制,同時遵循這些限制並最大化輸送量。以集合為基礎的 Apex 處理、具有可設定的範圍的批次工作,以及大量耗用的平台事件皆包含此原則。大量處理的解決方案會處理 200 個記錄,其中 SOQL 與 DML 陳述式的數量與一個記錄在序列處理中相同。散佈的工作量模式可提供彈性,因為沒有單一記錄失敗會影響整個批次的處理。
• **假設一切都失敗。**管理員限制、平台維護視窗和整合相依性會建立與 Salesforce 多重租戶結構相關的失敗模式。從一開始為這些平台特有的失敗設計。SOQL 查詢超出資料誤差下的列數限制。Apex CPU 時間可能會在複雜計算期間到期。外部服務速度緩慢時,可能會發生呼叫逾時。同時交易與 DML 列鎖定相符時會失敗。當檔案上載意外高峰時,儲存空間限制可能會失敗。計畫這些失敗的結構設計師可在沒有手動介入的情況下建立可靠的解決方案。這些可靠的系統會偵測到即將到來的管理員限制、透過錯誤處理包含爆炸半徑,並透過重試架構和平台事件自動復原。
• **建立自我復原系統。**設計可在沒有人力介入的情況下偵測失敗並自動復原的解決方案。「平台事件」可啟用自訂重試模式。傳送至訂閱者可以使用 EventBus.RetryableException 重試,但重新執行原始交易需要自訂結構。流程錯誤處理會將例外情況導向至復原流程。Apex 批次工作會區隔區塊失敗 (失敗的區塊不會防止其他區塊處理),以啟用部分工作完成和目標重試。在 AsyncApexJob 上使用錯誤追蹤來實作明確的重試邏輯,以進行暫時失敗復原。處理暫時失敗時,請將指數反斜線套用至這些重試模式。自復原系統會在時間離開事件期間維護可用性目標,即使當人力回應者可能無法工作時,也會減少營運負擔,同時改善恢復的平均時間。
• **首先為業務需求設計。**選取技術解決方案前,請先根據實際的業務影響定義服務層級目標。並非每個元件都需要五九可用性。將可靠性投資與業務關鍵性配對,並針對支援功能設計寬鬆降級。實際目標可啟用適當的結構選擇,並避免過度工程或傳送不足。
• **透過逐層細分驗證復原。**排程測試備份還原、故障轉換程序和事件回應手冊的災害復原逐步解說。從生產備份還原完整複製 Sandbox 以驗證復原流程。在 Sandbox 環境中導入刻意失敗,以確認您的監視偵測到問題,且自動復原執行正確。逐層細分會在實際事件揭露程序、工具和執行手冊中顯示差距。文件逐層細分結果並追蹤發現的缺口補救方式。定期測試可確保隨著解決方案的發展和小組成員資格的變更,恢復功能保持最新狀態。

瞭解 Salesforce 作業的內容可協助您將可靠性設計工作專注在 您 控制的項目上。平台可處理在傳統 IT 環境中需要專屬小組的基礎結構疑慮,例如:

• **多區域基礎結構與故障轉換:**Salesforce Hyperforce 為區域資料中心提供內部服務的自動故障切換。它也會在區域內提供多個可用性區域,以及基礎結構層級的資料複製。平台會以透明的方式處理區域內的冗餘與可用性區域散佈。
• **平台 SLA 承諾:**含合約補救措施的保證可用性層級會根據每位客戶進行協商。trust.salesforce.com 會發佈即時平台狀態與執行時間歷程記錄,但任何特定可用性保證及其補救措施都會存在於您的協商協議中。檢閱契約和目前的 Salesforce Trust 與合規文件,以瞭解適用於您組織的承諾。
• **基礎結構冗餘性:**平台會維護冗餘的伺服器、網路路徑、資料庫基礎結構和儲存系統。若硬體失敗,則在沒有客戶動作的情況下,會自動發生基礎結構層級失敗。平台備份可防止基礎結構層級資料遺失。
• **平台維護與更新:**主要平台版本提供 Salesforce 管理的舊版相容性功能和安全性修補程式。平台維護期間會在 trust.salesforce.com 上進行排程和通訊。基礎結構修補會以透明的方式進行,而無須客戶參與。
• **核心平台健康監視:**Salesforce 會監視基礎結構效能,包括資料庫回應時間、網路延遲、API Gateway 健康與儲存系統效能。平台健康狀態會顯示在 Trust.salesforce.com 中,並包含即時事件更新。透過「狀態 API」可取得例項特定狀態。

這些平台作業會建立您建立的基礎。您不管理資料中心、佈建伺服器或設計基礎結構災害復原。而是您負責您在基礎上設計和設定的內容。

「共用責任模型」會指定您擁有 Salesforce 所建立所有項目的可靠性。平台可靠性會啟用您的工作,但不會取代它。您的可靠性責任涵蓋六個相互連線的區域:

服務層級目標 (SLO) 會以可測量的數字來量化可靠性需求。SLO 會橋接業務需求與技術結構。選取技術或設計資料模型之前,請先建立定義每個重要使用者流程成功的 SLO。

SLO 通常會測量:

• 可用性 - 系統可供使用且可存取的時間百分比
• 延遲 - 完成作業所需的時間,測量為百分位數 (p50、p95、p99)
• 輸出量 - 每單位時間成功完成的作業量
• 錯誤率 - 失敗或傳回錯誤的要求百分比
• 復原時間 - 事件後還原服務所需的持續時間

針對每個業務功能而非針對每個技術元件定義 SLO。使用者面向的功能需要比管理或批次流程更嚴格的 SLO。每個 SLO 應使用可用的儀器來進行客觀測量。

服務層級契約 (SLA) 是合約承諾,會造成失敗的後果。每個客戶都會協商任何保證可用性層級及其合約補救措施。檢閱您的協議和目前的 Salesforce Trust 與合規文件,以瞭解適用於您組織的承諾。

解決方案 SLO 應比平台 SLA 更嚴格,以保留錯誤預算。如果您的平台 SLA 和解決方案 SLO 皆目標為 99.9%,則任何重大平台停機時間都會直接耗用您的錯誤預算,因此不會在相同的測量期間內保留應用程式層失敗、整合問題或計畫維護的緩衝時間。只有在累積停機時間耗用度量期間的完整錯誤預算時,才會正式違反 SLO。如果您的 SLA 和 SLO 設定為相同的目標,單一平台事件可能會完全耗盡該預算。例如,當平台提供 99.9%,則目標為解決方案 SLO 99.5%,以針對您必須解決的問題保持有意義的緩衝時間—應用程式錯誤、整合失敗和部署視窗。

服務層級指標 (SLI) 是用來評估 SLO 績效的度量。SLI 必須在物件上可測量、一致收集,並直接與使用者體驗繫結。

針對 Salesforce 解決方案,SLI 包括:

• 平台執行時間 (透過 Trust.salesforce.com)
• 透過 Experience Cloud 分析的頁面載入時間
• 透過「事件監視」的 API 回應時間 (需要「事件監視」附加元件或 Salesforce Shield)
• 透過自訂應用程式記錄的交易成功率
• 透過 AsyncApexJob 監視進行批次工作完成

較高的可用性目標會以指數方式增加複雜度與成本。請先瞭解結構涵義,再認可目標:

請避免使用任意目標,例如「一切為五九」。請改為評估每個功能停機時間的業務影響,並相應地設定目標。容忍每月 7 小時停機時間的內部批次報告需要與需要小時復原的收入關鍵訂單處理基本不同的結構。

從使用者觀點定義可靠性,而不是單獨從技術度量定義。報告執行時間為 99.9% 且經常逾時的系統無法以使用者體驗為基礎的可靠性。使用者比個別 API 執行時間更關注成功完成其工作流程。

設計反映使用者旅程而非個別 API 呼叫的 SLO。多步驟 Checkout 流程需要在可接受的時間內成功完成每個步驟。測量端對端使用者流程完成率作為主要的可靠性指標。元件可用性是必要的,但對使用者體驗的可靠性而言不足。

Salesforce Hyperforce 提供區域資料中心以啟用地理散佈。平台會在區域內處理基礎結構冗餘,包括多個可用性區域、內部服務的自動故障切換,以及基礎結構層級的資料複製。平台 SLA 會反映此基礎結構冗餘。

針對大多數解決方案,使用平台管理冗餘的單一區域部署可提供足夠的可用性。Trust Salesforce 基礎結構以取得基礎可用性,並將解決方案結構專注於應用程式層的可靠性,包括容錯整合模式、優良降級和自動復原。

跨可用性區域的區域內故障切換會自動進行,且包含在標準平台 SLA 承諾中,Salesforce 可在基礎結構層中以透明的方式管理此問題。跨區域 (區域外) 災害復原是個別付費的產品,依預設不會包含在任何標準版本中。如果您的業務連續性需求需要跨區域失敗,請在您的災害復原計畫中明確記錄此相依性,以便利害關係人瞭解包含的平台彈性與購買的跨區域 DR 功能之間的區別。

多組織結構提供最強大的隔離與地理冗餘,但會複製作業複雜度,包括資料同步化、使用者佈建、部署協調和授權成本。將多組織模式保留給業務需求明確地證明複雜性的案例。例如,針對下列情況,請考量多組織模式:

• 業務需要在平台功能之外的保證 RPO/RTO
• 法規需求需要地理資料隔離,業務連續性規劃需要完全獨立於單一區域
• 由於業務單位的自治需求,因此無法執行組織合併。

啟用-被動模式:- 主要組織在正常狀況下提供所有流量。不同區域中的次要組織會保持同步化,但會閒置。錯誤切換會在主要區域中斷期間發生。此解決方案提供最簡單的多組織模式,但不會使用次要容量。DNS 路由或使用者驗證層會將使用者導向至已啟用的組織。

啟用中模式:- 兩個組織都會持續提供生產流量。使用者會依地理位置、業務單位或工作量類型配置。「啟用」會將容量利用率最大化,但需要精密的資料同步化和使用者路由。當兩個組織中修改相同的記錄時,衝突解決十分重要。

設計適合 RPO 需求的資料同步化。「平台事件」為重要資料變更提供近乎即時的事件串流。Change 資料擷取 會為所選物件提供自動變更追蹤,但開發率最低。透過固定間隔的大量 API 2.0 排程的 API 複寫不適合時效敏感的參考資料。

將冗餘套用至資料、應用程式和整合層,以避免單點失敗。分層冗餘可確保任何單一層的失敗不會影響整體系統可用性。

• **資料冗餘性:**平台透過基礎結構備份提供資料冗餘。當業務需要比平台還原程序提供更快的復原時,請使用應用程式層級複製來補充此冗餘。使用 Change 資料擷取 或平台事件,將重要資料持續複製到次要儲存空間或外部系統。這可從基礎結構備份無法解決的邏輯損毀或組態錯誤中復原。
• **應用程式冗餘性:**設計無狀態應用程式邏輯,讓任何應用程式伺服器都能處理任何要求。避免伺服器端狀態阻止水平調整。針對必須在所有應用程式伺服器之間立即可用的組態,使用自訂中繼資料類型和自訂設定。無狀態設計可讓應用程式伺服器處理要求,而不取決於特定伺服器狀態。
• **整合冗餘性:**設計容忍暫時外部系統無法使用的整合。實作偵測失敗整合的斷路器模式。當外部系統關閉而非封鎖使用者作業時,透過「平台事件」來排入要求。這會將外部系統失敗與使用者面向的功能隔離。

使用 Trust.salesforce.com 和例項特定狀態 API 監視 Salesforce Platform 健康狀態。訂閱您例項的狀態通知,以接收事件、維護期間和效能影響的相關警示。平台健康訊號會啟用主動回應,而非反應性疑難排解。

設計回應平台健康狀態的解決方案。當平台效能降低時,請減少非重要批次處理負載。使用排程工作監視在維護期間延後背景工作。停用非必要的整合,以在事件期間保護重要使用者面對的作業。此動態負載流程可在壓力下維持重要功能的可靠性。

使用「刻度中心」識別耗用不成比例平台資源的長時間交易和作業。「刻度中心」提供交易層級可視性,讓結構設計師能夠在可靠性風險變成使用者面對的事件之前偵測。「每週刻度中心」檢閱顯示需要結構修復的模式。

在多個層級實作失敗偵測,以便在問題串聯為完整中斷之前找出問題。分層偵測提供對未偵測到失敗的深度防禦。

設計警示值,以平衡早期偵測與假陽性。當錯誤率超出值或發生持續降級時進行警示,而非在個別失敗時。單一錯誤在散佈系統中很常見。錯誤模式表示需要注意的可靠性問題。

Salesforce 管理員會限制多重租戶平台中每個租戶的資源消耗上限,因此沒有單一租戶可以降低其他租戶的效能。這些並非任意限制,而是構成解決方案設計的結構界限。設計可靠結構之前,請先瞭解管理員限制。在正常載入下定期達到管理員限制的解決方案可能會在壓力下失敗。

影響結構決策的重要管理員限制:

設計在限制內完成的交易,即使在負載高峰時也是如此。在正常情況下,將 70% 的管理員限制作為營運上限作為目標,將 30% 保留給非預期的高峰,以建立利潤。此緩衝區可容納暫時載入增加,通常不會達到硬性限制。

大量處理是 Salesforce 的基礎延展性模式。在單一交易中處理多個記錄,而非在個別記錄作業中處理。大量處理可減少管理員限制耗用,同時增加輸送量。每個 Salesforce 結構設計師都必須掌握大量處理模式,因為這些模式是所有可調整解決方案的基礎。

設計所有 Apex 觸發、批次類別和整合,以有效率地處理記錄集合。請先收集記錄識別碼,然後使用單一查詢和 DML 陳述式處理所有記錄。使用地圖和設定來進行有效率的對應,而非使用個別查詢嵌套迴圈。以集合為基礎的處理提供比逐筆記錄方法順序提升效率。

記錄觸發自動化必須處理每個觸發叫用 200 筆記錄,因為平台會以最多 200 筆記錄的批次處理觸發執行。Lightning Data Service 作業會自動批次處理,但自訂元件在執行 DML 作業時必須明確實作大量模式。

非同步處理會跨時間散佈工作,而非嘗試在單一交易的管理員限制內立即完成。當作業處理大資料量超過同步管理員限制、依賴具有變數回應時間的外部系統、可容忍延遲完成,或需要延長超過同步 CPU 限制的執行時間時,請使用非同步模式。

Salesforce 非同步功能及其結構適配:

• **批次 Apex:**以每個執行方法最多 2,000 筆記錄的區塊處理大量記錄。批次提供每個區段的專用管理員限制和失敗隔離—失敗的區段不會防止其他區段完成。這會啟用部分成功和目標重試。透過追蹤 AsyncApexJob 物件上的失敗區塊範圍,並重新建立目標批次工作,以實作暫時失敗的自訂重試邏輯。批次用於資料移轉、排程大量更新和大規模資料處理。每個組織最多可同時執行或待執行五個批次工作。其他工作會排入 Apex 彈性排隊中 (狀態為「保留」的工作最多 100 個),並在開啟時段時自動執行。
• **可排隊的 Apex:**使用鏈結功能執行非同步工作,以啟用多步驟工作流程和複雜物件參數。可排隊的 Apex 會與其他所有非同步 Apex (批次、未來和排程的 Apex) 共用每 24 小時 250,000 次執行的組織範圍 DailyAsyncApexExecutions 限制,而非保留專屬的 Queueable 特定配置。將 Queuable Apex 用於需要依序處理且有比 @future 方法更佳監視的多步驟協調流程和整合工作流程。
• **平台事件:**平台事件用於將發行者與訂閱者分離的發佈訂閱事件結構。事件從 72 小時 (3 天) 的保留期間重新執行。延長保留超過 72 小時可作為付費附加元件使用—在認可依賴延長重複執行的 SLA 義務之前,請先在最新的 Salesforce Platform 事件文件中確認目前的 上限和 GA 狀態。使用「平台事件」來進行事件驅動的自動化、跨系統整合和即時資料串流。「平台事件」提供交易階段之間的自然非同步邊界。
• **已排程 Apex:**透過 System.schedule() 使用 CRON 運算式,以固定排程執行工作。工作最多可排程為每小時執行一次,CRON 秒數和分鐘數欄位必須使用固定值,而非範圍。透過將類似的作業合併為單一「可排程」類別,讓每個組織保留最多 100 個已排程 Apex 工作。

當資料量超過實際處理限制時,即使使用大量與非同步模式,也可跨邏輯邊界分割資料,以啟用並列處理。資料分割會將大型序列作業轉換為較小的並列作業,以更快完成並保持在管理員限制之內。

• **以日期為基礎的分割:**以時間範圍處理資料,包括本月的交易或上一季的個案。將歷程記錄資料歸檔至「大型物件」或外部儲存空間,讓工作集保持可管理。大多數的交易查詢都專注於最近的資料,使以時間為基礎的分割具有自然效率。
• **記錄類型分割:**獨立處理不同的記錄類型,包括合作夥伴個案與客戶個案,或企業帳戶與 SMB 帳戶。每個類型的個別批次工作可啟用並列化。記錄類型經常與不同的業務流程相關聯,藉此實現獨立處理。
• **擁有者型分割:**依記錄擁有者散佈處理,例如獨立處理每個銷售區域的機會。當與共用模式結合時,以擁有者為基礎的分割特別有效,因為安全性會透過現有機制強制執行。以擁有者為基礎的分割可啟用處理負載的地理分佈。

根據業務成長預測未來產能需求,而非反應限制耗用。主動產能規劃可防止平台資源不足所導致的可靠性事件。

• 使用者授權 - 人數成長推動每個使用者的 API 呼叫配置和儲存權益
• 資料儲存空間 - 交易量與保留原則會推動儲存空間耗用 (指定計畫每年至少成長 10–20%)
• API 呼叫 - 整合計數和頻率推動 24 小時 API 配置 (每個新的整合模式都會增加循環耗用)
• 處理容量 - 批次工作計數與複雜性會推動非同步化處理排入和同時執行限制

使用 Proactive Monitoring 持續評估組織容量使用狀況。Proactive Monitoring 會呈現容量風險,包括 API 使用即將達到要求限制高峰、儲存空間接近限制,以及超出永續性層級的批次工作排行榜深度增加。每週產能檢閱會在業務影響發生之前,為額外授權或限制啟用採購前置時間。

在生產部署前透過載入測試驗證延展性假設。載入測試會顯示管理員限制問題、整合瓶頸,以及在少量開發測試中看不到的產能限制。使用生產規模的資料量並行測試,以在實際的條件下驗證可靠性。

• **資料量測試:**在 Full Copy Sandbox 中填入生產規模的資料量,以使用實際資料誤差、關係深度和記錄計數來驗證查詢效能。當生產達到該規模時,使用 1 千萬筆以上的記錄進行測試。隨著資料量增加,查詢最佳化程式的行為會大幅變更,這可能導致小規模測試結果出錯。
• **同時使用者測試:**模擬同時使用者載入的峰值,以驗證交易輸送量與爭用。在部署前,請使用適用於合格組織的級度測試,以模擬 Sandbox 環境中的生產工作量。同時執行會顯示在單一使用者測試中看不到的鎖定問題。
• **API 負載測試:**產生峰值 API 容量以驗證整合的延展性、速率限制處理,以及持續載入的斷路器行為。API 負載測試會顯示重試邏輯和錯誤處理是否在壓力狀況下正確運作。
• **規模測試:**規模測試是一種 Salesforce 產品,用於針對調整為符合生產容量的 Full Copy Sandbox 環境模擬生產工作量。針對 Hyperforce 上的完整複製 Sandbox 執行規模測試。您的生產例項不需要在 Hyperforce 上才能使用。您在生產組織中建立測試計畫,測試則會針對 Sandbox 執行。在主要部署之前,使用規模測試驗證管理員限制主機,非同步處理輸送量,以及在高峰負載條件下整合回應行為。

非重要元件失敗時,寬鬆降級會維護核心功能。設計系統,在失敗時將重要使用者流程優先於支援功能。並非所有功能都具有相同的業務重要性,且結構應反映這些優先順序。

定義功能重要性階層:

此階層可讓結構設計師設計降級原則,即使在部分系統失敗時仍可維持業務連續性。使用者偏好縮短功能,而非完全無法使用。

斷電器模式會在整合無法使用時防止串聯失敗。您可以偵測失敗模式並停止呼叫失敗的系統,而不是累積耗用交易時間和管理員限制的逾時。斷電器提供快速失敗,而非緩慢失敗。

斷電器會顯示:

• 已結束 - 正常運作,要求如預期流向外部系統
• 未結束 - 已超過失敗值,要求會立即失敗而不會嘗試進行外部呼叫,進而節省資源
• 半開啟 - 復原測試期間,有限的要求會在完全關閉電路前偵測外部系統以偵測復原

使用平台快取實作斷路器,以儲存可在所有交易之間存取的電路狀態。使用「平台事件」在整個組織中廣播狀態變更。中斷電路邏輯會在嘗試外部呼叫前檢查狀態,避免在已知失敗的系統上浪費呼叫限制。

散佈系統中暫時失敗是正常狀況。網路中斷、暫時服務無法使用和比率限制回應通常會在秒內解決。實作重試邏輯,在漸進式延遲後重複失敗的作業,而非立即失敗。

指數反向回應可防止重試風暴壓倒復原系統。第一次重試會在 1 秒後發生,第二次會在 2 秒後發生,第三次會在 4 秒後發生,第四次會在 8 秒後發生。無論指數成長為何,上限延遲為 30–60 秒。此反向模式可讓失敗的系統有時間復原,同時限制總重試持續時間。

將重試策略與失敗類型進行比對。

• **網路逾時:**以簡短反向方式重試 (作業可能尚未到達伺服器)
• **比率限制錯誤 (429):**在「重試後」標題值或比率限制重設時間之後重試
• **伺服器錯誤 (5xx):**請以指數反向方式重試,因為伺服器可能暫時載入過多
• **用戶端錯誤 (4xx 除 429 之外):**請勿重試;將要求修正為錯誤表示輸入無效
• **管理員限制錯誤:**請勿在相同的交易中重試;以專屬限制重新排入非同步作業,例如透過發佈非同步訂閱者在新交易限制下以反向方式重新處理的失敗事件

回復策略會在主要方法失敗時定義替代方法,以在降級狀況下繼續作業。

• **替代資料來源:**當即時 API 無法使用時,從平台快取工作階段或從組織分割取用資料。在成功作業期間預先填入快取。快取提供過時但可用的資料,對於許多使用個案而言,比完全失敗更佳。
• **預設行為:**當個人化或增強服務無法使用時套用標準業務規則。使用預設值處理,並在服務復原時標記增強。預設行為會以降低精確度的成本來維護輸送量。
• **手動流程:**自動化失敗時啟用手動作業完成。提供用於完成停滯交易的管理介面。手動回復可避免資料遺失,並在自動化降低時維持業務連續性。
• **用於重試:**在外部系統復原時,將作業儲存在平台事件中或自訂排入物件中,以供處理。具有 72 小時標準保留的平台事件重新執行可在暫時失敗後啟用訂閱者復原,而不會遺失資料。

設定所有整合呼叫的適當逾時。Salesforce 會強制執行每個交易的總呼叫時間上限為 120 秒。預算一次在單一交易中的所有呼叫,以避免在暫停連線上耗盡交易時間。

逾時設計考量事項:

• **使用者面向的同步呼叫:**使用 5–10 秒的上限可維持回應式 UI,因為使用者可能不會再等待。
• **背景非同步呼叫:**使用 30–60 秒來配合變數外部效能,而無須使用者等待
• **批次處理呼叫:**當沒有使用者等待回應時,請使用允許的 完整 120 秒
• **每個交易有多個呼叫:**預算所有呼叫的總時間,例如每個 10 秒的三個呼叫耗用 120 秒預算的 30 秒。

縮短逾時失敗的速度較快,讓回復策略能夠更快地參與。延長逾時會增加慢速但功能不佳外部系統的成功率。平衡考量事項取決於使用者是否正在等待回應,以及回復策略的可用性。

設計全方位錯誤處理,將失敗從當機轉換為受管理降級:

• **快速失敗:**驗證進入點的輸入與先決條件。在高成本作業之前,請先檢查管理員限制耗用。立即偵測失敗,而非透過多個處理層移入無效狀態。及早偵測可減少爆炸半徑並簡化除錯。
• **順利失敗:**即使作業部分失敗,仍可維護使用者功能。如果批次中 200 筆記錄中的 3 筆驗證失敗,請處理 197 筆成功記錄並報告 3 筆失敗,而非整個批次失敗。批次作業的部分成功比總失敗好。
• **資訊性失敗:**記錄交易識別碼、使用者內容、輸入參數和堆疊追蹤的錯誤。錯誤內容不足是快速事件解決的主要障礙。每個錯誤記錄都應讓回應者瞭解失敗的項目、原因和重現方式。
• **安全失敗:**確保失敗不會影響資料完整性或安全性。回復部分交易,而非將資料保持不一致狀態。請勿向一般使用者顯示內部錯誤詳細資料,因為堆疊追蹤會顯示對攻擊者有用的實作詳細資料。

「復原時間目標」會定義災害後可接受的停機時間上限。RTO 會驅動關於故障轉換自動化、備份頻率和復原測試投資的結構性決策。不同的業務能力可提供不同的 RTO 投資。由於 RTO 是您使用者直接遇到的停機時間,因此錯過的目標會轉化為長時間的中斷和客戶Trust遭到損毀。

RTO 因業務能力而有所不同:

設計災害復原結構之前,請先定義每個功能的 RTO。RTO 會打造技術選取、自動化投資和測試步調。更積極的 RTO 目標需要更大的自動化和冗餘投資。

「復原點目標」定義時間測量的最大可接受資料遺失期間。RPO 決定備份頻率、複製策略和同步化模式。更嚴格的 RPO 需要更頻繁的資料複製,進而增加複雜性和成本。由於 RPO 是您業務所吸收的資料損失,因此遺漏目標可能表示您記錄中遺失的交易和無法復原的間隙。

將 RPO 需求與成本和複雜度進行平衡。近零 RPO 需要持續資料複製,並需要大量的基礎結構投資。每日備份可提供 24 小時 RPO,且具有最低的複雜性。大多數組織都可容忍一些非財務資料資料遺失。

平台基礎結構冗餘可防止基礎結構失敗,但會複製使用者錯誤、瑕疵部署和整合瑕疵的結果,這會造成大多數資料遺失。備份存在於復原這些應用程式層失敗,而不是補償平台的可靠性。實作涵蓋資料、中繼資料和檔案的備份策略,因為每個備份策略都需要不同的備份方法:

• **資料備份:實作處理資料與中繼資料的全方位備份策略。使用原生資料匯出服務匯出重要物件資料—Enterprise、Performance 和 Unlimited Edition 每隔 7 天匯出一次;Professional 和較低版本則每隔 29 天匯出一次。匯出檔案在傳送通知電子郵件後的48 小時 (不包括週末) 之前,才會自動刪除。**設定自動下載流程,讓檔案不會永久遺失。在來源控制系統 (例如 Git) 中,使用中繼資料 API 和 Salesforce CLI (sf project retrieve) 來版本控制組織組態、自訂程式碼和陳述式自動化。將中繼資料備份視為標準 CI/CD 管道的一部分。使用專屬的備份與復原服務補充資料備份,例如時間點還原、細微記錄層級復原,以及原生匯出步調以外的保留等「專屬」。「原生資料匯出」不支援時間點還原,如果您的 RTO/RPO 需要細微的復原期間,則需要第三方工具。定期測試還原程序;從未還原的備份是未經測試的假設。
• **中繼資料備份:**版本會使用 Git 儲存庫中的 Salesforce DX 來源格式控制所有中繼資料。中繼資料版本控制會在損毀或非預期的變更後快速還原組態。每個部署都應可從來源控制重複。Git 中的中繼資料提供組態的時間點復原。
• **檔案備份:**將 ContentVersion 記錄、附件和文件匯出至外部儲存空間。Salesforce 最適用於啟用中的資料,而非長期檔案歸檔—將檔案匯出至外部儲存空間以進行法規保留。針對超出平台功能的法規保留需求實作自動檔案匯出。
• **驗證:**定期將備份還原至臨時組織或開發人員 Sandbox,以驗證程序和備份完整性。由於備份範圍不完整或封存損毀,因此未經測試的備份通常會在需要時失敗。排程每季還原驗證,以在發生災害前找出問題。除了還原驗證外,還可以監視備份的最新狀態。當最近成功的備份早於預期的步調時 (例如,當每週匯出超過 8 天後未完成時),便會發出警示。透過此驗證,靜音失敗的備份工作會立即出現,而非在下一次逐層細分時。

設計適合 RPO 和多組織需求的複寫:

• **變更資料接收 (CDC):**訂閱以變更已追蹤物件的事件。CDC 會提供已變更欄位值的建立、更新、刪除和取消刪除事件。為支援的物件 (包括標準和自訂) 提供近乎即時的複寫,並以最低的開發力進行。根據版本的每日遞送配置。
• **平台事件:**用於複製業務事件和狀態變更的自訂事件結構。與 CDC 相較,其支援自訂裝載和複雜事件結構,但需要在觸發程序或程序中明確發佈邏輯。72 小時重新執行時段標準可啟用暫時訂閱者失敗的復原。
• **已排程 API 複寫:**排程 API 複寫是透過固定排程的大量 API 2.0 進行批次解壓縮。其實作最簡單,其 RPO 等於解壓縮頻率。已排程 API 複寫適用於不需要近乎即時執行的非重要資料,例如參考資料或歷程記錄分析。
• **MuleSoft 協調複寫:**針對複雜的多系統複製主題,MuleSoft Anypoint Platform 提供協調流程、轉換和監視。其適用於在 Salesforce 和多個外部系統之間複製,這需要精密的路由和轉換邏輯。

使用排程的逐層細分來測試人員、程序和技術的災害復原:

• **平板電腦演練:**小組逐步瀏覽災害案例,討論角色和決策點,而無須實際失敗。此活動成本低,且顯示程序差異與通訊故障。定期執行桌上型電腦演練,以在工作人員變更時保持小組整備。
• 部分失敗:- 測試特定復原程序,例如從來源控制還原中繼資料、從備份服務還原資料或重新整理 Sandbox。這會驗證具有有限業務影響的技術程序。定期執行,輪替每年測試哪些程序以涵蓋所有復原功能。
• **完整錯誤逐層細分:**完整故障切換是透過生產流量截斷完成的災害復原環境。其提供最高的信任,但需要業務協調和使用者溝通。每年針對重要系統執行此逐層細分。完整的失敗逐層細分會驗證整個復原功能,包括裁切程序和使用者通訊。

記錄每次逐層細分後學到的經驗。根據發現結果更新執行手冊。復原功能會隨著小組變更和解決方案的演進而降低。將 DR 文件視為需要定期維護的即時成品,而非一次性交付。

業務連續性會延伸至技術復原以外,以涵蓋人員、流程和廠商相依性:

• **小組可用性:**記錄重要角色的升級程序和備份人員。確定作業 Knowledge 中沒有單一失敗點。主要回應者在災害期間可能無法使用,這會讓備援人員十分重要。
• **通訊程序:**定義將事件傳達給使用者、客戶和主管的方式。建立主要工具 (例如外部狀態頁面或 SMS 通知系統),包括 Salesforce 本身,無法使用時的通訊管道。
• **廠商相依性:**將重要外部廠商相依性對應至解決方案作業。記錄每個重要廠商 (包括 Salesforce、整合合作夥伴和 ISV 封裝提供者) 的升級路徑和合約 SLA。例如,瞭解哪些廠商提供全年無休的支援,以及哪些廠商僅擁有影響復原時間的營業時間支援。
• **監管義務:**識別延長中斷所觸發的通知需求。金融服務、醫療照護和政府契約通常會在特定時間範圍內要求事件通知。不合規會造成法規和法律風險,這兩者皆會造成複雜災害影響。

定義將多個訊號彙總到整體系統健康狀態的健康模型。健康模式可概略呈現作業狀態,而不需要詳細度量的分析。例如:

設計立即顯示營運狀態的健康狀態顯示面板。健康狀態會引導作業回應,包括綠色狀態下的正常作業、黃色狀態下的進階監視,以及紅色狀態下的已啟用事件回應。

平台狀態訊號 (稍早在「平台健康狀態監視」下涵蓋) 會顯示 Salesforce 基礎結構何時降級,但不會顯示您自己的解決方案執行方式。

使用解決方案特定觀察性增強這些訊號:

• 事件監視:「事件監視」包含詳細的記錄,這些記錄會捕捉 API 呼叫、頁面檢視、報告匯出、登入活動和 Apex 執行。EventLogFile 物件會以 24 小時 (每日) 或 1 小時的頻率傳送記錄 - 每小時傳送需要「事件監視」附加元件或 Salesforce Shield。保留最多可透過「設定」設定 365 天,但延長保留需要 Salesforce Shield 或「事件監視」附加元件。若沒有附加元件,則記錄檔案會保留 1 天。將事件路由至外部安全性資訊和事件管理 (SIEM) 系統,或傳送至記錄彙總平台,以進行超出原生限制的關聯、警示和保留。使用「事件監視」來偵測異常的 API 耗用模式、識別流失的 Apex 程序,以及在受監管環境中稽核資料存取。
• 刻度中心:「刻度中心」提供長時間執行作業、列鎖爭和資源密集型交易的交易層級可視性。「刻度中心」可讓結構設計師先從特定交易模式中識別可靠性風險,再導致使用者面對的事件。每週檢閱會顯示最佳化機會。
• **主動監視:**Proactive Monitoring 可持續評估組織健康狀況,並呈現效能和延展性風險。Proactive Monitoring 會提供 API 要求限制高峰、同時 Apex 執行失敗、SOQL 列限制問題和儲存空間耗用趨勢的警示。此功能適用於具有「簽章成功」 (先前稱為「簽章支援」) 權益的客戶,而非標準版本中包含的自助式功能。

從使用者觀點監視應用程式效能,而非從基礎結構觀點監視:

• **實際使用者監視 (RUM):**透過 Experience Cloud 分析或自訂儀器測量實際使用者體驗。RUM 會捕捉實際延遲,反映實際的網路條件、裝置效能和地理散佈。合成監視無法複製此變異性。
• **合成監視:**定期從多個位置執行自動化交易,以驗證可用性和效能。合成監視會在使用者回報問題之前偵測到問題。使用排程的 Apex 實作綜合監視、使用「平台事件」執行重要作業和報告結果。
• **交易追蹤:**儀器複雜的多步驟作業,用於針對每個步驟捕捉時間。接下來,識別五個步驟工作流程中導入延遲的步驟。請勿將整個流程視為黑色方塊。步驟層級時間表會顯示彙總度量中看不到的最佳化機會。

使用錯誤率、延遲百分位數和輸出來監視所有外部整合。整合失敗是可靠性事件的主要原因:

• 錯誤率 - 傳回錯誤通話的百分比 (目標: <1% 進行整合正常)
• 延遲 - 在 p50、p95、p99 測量的回應時間 (根據逾時預算設定每個整合的 SLO)
• 逾時率 - 超過設定的逾時百分比 (目標:<0.1%)
• 斷電器狀態 - 未結束狀態表示需要立即注意的持續失敗
• 針對非同步整合**,排列嚴重度** - 成長時指示處理速度落後

記錄具有要求識別碼、端點、回應碼和持續時間的所有整合呼叫。此資料可在整合失敗影響可靠性時快速進行根本原因分析。整合記錄應啟用彙總與趨勢分析。

在使用者受到影響之前設計問題的警示,以啟用主動回應:

• **可操作警示:**每個警示都有已定義的回應動作和指派的回應者。沒有明確回應的警示會造成疲勞和隱藏重要訊號。警示設計應涵蓋回應者、檢查的項目,以及其補救方式。
• **適當的緊急情況:**針對影響使用者的失敗頁面通話人員。傳送電子郵件以降低效能。將問題包含在每日摘要中,以瞭解趨勢。不相符的緊急情況會因過度升級而產生警示疲勞,或因低度升級而產生遺漏事件。
• **內容豐富的通知:**包含已切換的值、目前值、最近趨勢,以及相關顯示面板或執行手冊的連結。讓回應者無須收集內容即可立即開始診斷。每個警示應包含足夠的資訊以進行分級,而無須額外查詢。
• **風暴抑制:**當多個系統同時失敗時,請抑制冗餘警示。一個顯示整合平台失敗的警示比 50 個隱藏根本原因的個別整合失敗警示更為可採取行動。

異常偵測會識別異常模式,並可指出靜態值警示看不見的新問題:

• 量異常:交易量明顯高於或低於預期的每日模式,可能表示流程失效或使用者存取問題。
• 錯誤率異常:與上週相同時間基準相比,增加的錯誤率會在達到值超出之前逐步降級。
• 延遲異常:多日之間向上漂移的回應時間表示容量飽和或效能迴歸。
• 行為異常:異常的登入模式、非預期的 API 用量高峰,以及在排程的時間範圍外執行的批次工作可能表示可疑使用。

針對具有「簽章成功」權益的客戶,Proactive Monitoring 會提供平台級異常偵測,而不需要額外設定。為匯出至外部分析平台的自訂 SLI 補充應用程式特定異常偵測。您可以使用異常訊號來指引調查,而不是觸發立即升級,因為異常偵測的假陽性率高於值值警示。

在結構審查期間、生產部署前,並定期使用此檢查清單進行持續的可靠性評估。

可靠性目標與 SLO

• 設計開始之前,為所有重要使用者流程定義 SLO
• 建立與使用者體驗 (而不只是基礎結構度量) 繫結的可測量 SLI
• 根據業務影響分析設定實際的可用性目標,而非任意目標
• 確保解決方案 SLO 比平台 SLA 更嚴格,以提供錯誤預算
• 結構決策記錄中的文件可用性目標與原因

高可用性結構

• 資料、應用程式和整合層級的設計冗餘性
• 透過 Trust.salesforce.com 和例項狀態 API 監視平台健康狀態
• 無論平台狀態為何實作應用程式健康檢查
• 只有在業務需求明確地理由複雜時,才考量多組織結構
• 使用多組織模式的已測試執行手冊設計自動停機

延展性和產能規劃

• 在正常載入的管理員限制 70% 內完成的設計交易
• 在所有 Apex 觸發、批次類別和整合中實作大量處理模式
• 針對超過同步限制的作業使用非同步處理
• 批次所有 API 整合,而非進行個別記錄呼叫
• 在部署前,對生產規模資料量執行載入測試
• 透過 OrgLimits API 或自訂 Apex 監控容量利用率,並在耗用達到 70% 作業上限時警示
• 根據 12 個月成長期望的專案產能需求
• 依日期、記錄類型或擁有者分割大量資料,以在數量超過序列限制時啟用並列處理

錯誤容量與彈性

• 使用定義的功能重要性層級設計寬鬆降級
• 針對所有外部系統整合實作斷路器
• 對暫時失敗套用具有指數反向的重試邏輯
• 設定適用於作業類型的逾時 (5–10 個使用者面向,30–60 個非同步)
• 使用「平台快取」和以列為基礎的模式設計回復策略
• 使用足夠的診斷內容實作結構化錯誤處理

災害復原與業務連續性

• 設計前定義每個業務功能的 RTO 和 RPO
• 實作資料、中繼資料 (來源控制) 和檔案的自動備份
• 在非生產環境中每季驗證備份還原程序
• 監控備份最新狀態,並在排程備份逾期時警示
• 設計資料複寫策略以符合 RPO 需求
• 每年執行災害復原測試 (每季平板電腦)
• 記錄業務連續性程序,包括廠商升級路徑

監視與可觀察性

• 定義健康模型,彙總服務、整合、資料和產能訊號
• 訂閱 Salesforce 例項的平台狀態通知
• 實作重要 Experience Cloud 流程的實際使用者監視
• 使用錯誤率、延遲和斷電器狀態監視整合健康狀態
• 使用定義的回應程序和擁有權設計可運作的警示
• 將「事件監視」資料路由至外部平台以進行長期保留與分析
• 使用 Proactive Monitoring and Scale Center 進行持續可靠性風險評估
• 針對體積、錯誤率和延遲模式套用異常偵測,以找出靜態值遺漏的降級

分享您對良好架構的回饋意見。