Salesforce 2025 服務中斷：重大中斷回顧

從 Salesforce 2025 年的故障記錄中得出的最重要結論是，並沒有發生一次足以定義全年的「全球 Salesforce 故障」。相反，客戶經歷了幾種不同的故障模式：2 月份的大範圍服務中斷、6 月份跨多個雲端平台的身份驗證失敗、由供應商意外更新導致的 Heroku 平台重大事件、印第安納波利斯資料中心網路故障，以及之後僅限於特定實例或功能的故障。這種區分至關重要，因為正確的應對措施取決於故障的具體原因。

如果使用者無法登錄，刷新瀏覽器並不能解決問題。如果公共狀態頁面延遲，通用故障監控器可能無法提供完整資訊。如果 Salesforce 可用，但整合佇列卡住，CRM 本身可能看起來運作正常，但業務流程仍出現故障。 2025 年的實務經驗是將租戶特定的狀態通知、獨立監控、經過測試的手動流程以及下游系統的恢復檢查結合起來。

2025 年 Salesforce 可能面臨的主要變革有哪些？

以下事件有助於回顧分析，因為它們顯示了不同的故障模式。但這並不意味著這裡列出了 2025 年 Salesforce 的所有狀態事件。

對於 2 月和 Salesforce Trust 事件，日期、範圍和復原更新均來自 Salesforce 的事件記錄：2 月 7 日服務中斷事件、6 月 10 日跨雲端身分驗證事件、6 月 18 日印第安納波利斯事件、11 月 1 日實例事件和12 月 31 日 WhatsApp 事件。

6月10日的事件揭示了兩種不同的故障層。

6月10日尤其重要，因為「Salesforce服務中斷」可能指不只一起事件。 Salesforce的信任記錄描述了影響多個雲端平台的多因素身份驗證失敗。 Heroku隨後發布的糾正措施報告則描述了平台服務中斷，該中斷始於UTC時間06:00，原因是供應商對生產基礎設施進行了意外的系統更新。

Heroku 也承認其狀態頁面受到影響。根據Heroku 的修正措施更新，狀態頁面設計缺陷和 API 延遲導致逾時，頁面可能顯示沒有活動事件。 Heroku 表示，已採取的應對措施包括永久停止無人值守的供應商作業系統升級、鏡像審核、加強監控、快取狀態內容、制定獨立的溝通計畫以及強化事件回應流程。

對於管理員來說，這是一個非常重要的區別。狀態頁面本身並非服務，但客戶會使用它來決定是等待、故障轉移、提交支援案例或與使用者溝通。如果狀態通道與受影響平台共享過多基礎設施，則可能無法在最需要的時候提供可靠的資訊。

2025 年的紀錄為 Salesforce 客戶帶來了哪些啟示？

1. 身份驗證需要單獨的連續性計劃

即使團隊擁有完整的應用程式數據，如果登入、多因素身份驗證或關聯身份路徑發生故障，他們仍然無法正常運作。對於同時使用 Salesforce、Heroku、Commerce 和 Marketing Cloud 的企業而言，這一點尤其重要。因此，請務必記錄哪些使用者需要存取哪些系統，確定可以接收供應商更新的緊急聯絡人，並明確哪些工作可以在登入失敗的情況下繼續進行。

對於小型銷售團隊而言，這可能意味著一個臨時的手動呼叫清單和一個共享的事件日誌。而對於呼叫中心或醫療機構而言，可能需要正式的停機維護流程、經批准的唯讀匯出功能以及經過測試的升級流程。備用方案的規模應與系統被鎖定所造成的業務後果相符。

2. 一個通用的狀態頁面是不夠的

Salesforce 官方文件解釋說，「信任狀態」提供可用性和效能信息，而較新的「我的信任中心」視圖則圍繞著租戶和受支援的產品而設計。操作要點很簡單：在事件發生之前，請務必了解您的實例或租用戶識別碼。

Salesforce 也提供了訂閱「我的信任中心」訊息和通知的說明。請為必須採取行動的人員配置通知，而不僅僅是為最初建立組織的管理員配置。保留一個獨立的溝通管道，例如內部狀態頁面或已批准的訊息群組，以便即使供應商狀態網站速度慢或不可用，您的公司也能進行溝通。

3. 恢復過程不只是看到登入介面。

即使 Salesforce 報告服務已恢復，事件仍可能對業務造成影響。例如，延遲的 API 請求可能會重試兩次，排隊的訊息可能會延遲到達，或者部署失敗會導致記錄不同步。恢復後，請檢查最重要的工作流程：身份驗證、API 呼叫、計劃作業、整合佇列、電子郵件或訊息傳遞、記錄建立以及報告的新鮮度。

例如，假設一個中型支援團隊，其客服人員使用 Salesforce 案例係統，而另一個獨立的商務系統則透過整合發送更新。如果 Salesforce 在上午 10:00 恢復可用，但整合佇列中仍包含來自服務中斷期間的失敗訊息，團隊不應僅僅因為瀏覽器載入完畢就關閉該事件。正確的判斷方法是，新的案例更新和先前失敗的案例更新是否能夠完整地完成整個工作流程，而不會重複。

哪些業務連續性措施適合貴公司？

如何在2026年及以後運用這種回顧方法

首先繪製一張單頁依賴關係圖。記下您的 Salesforce 執行個體或租用戶、身分提供者、連接的雲端平台、關鍵整合、狀態訂閱以及故障期間使用的手動流程。然後為每個重要工作流程定義一個客觀的復原檢查目標。 「Salesforce 已復原」過於籠統；「新案例、出站訊息和訂單更新正在處理且無重複」則更具可測試性。

最後，審查可能影響可用性的變更：供應商更新、作業系統變更、版本發布、配置變更和實例遷移。 6 月的 Heroku 事件表明，無人值守的變更需要強有力的控制，狀態通訊本身也需要具備彈性。 6 月 18 日的事件表明，實體容量和資料中心依賴關係在雲端服務中仍然至關重要。 12 月的功能降級表明，團​​隊應該監控他們實際使用的功能，而不僅僅是平台的頂級可用性。

因此，最適當的因應措施是因地制宜的。小型組織可能只需要通知和清晰的手動檢查清單。無法暫停銷售或支援的企業需要獨立的監控、佇列感知恢復機制和成熟的停機流程。受嚴格監管的組織則需要經過測試的恢復方案、證據和治理。 2025 年 Salesforce 的故障記錄支援一個一致的結論：彈性是圍繞客戶的依賴鏈構建的，而不是圍繞單一的綠色狀態指示器構建的。

資料來源和範圍

本文回顧使用了撰寫時可用的 Salesforce Trust 事件記錄和 Salesforce 或 Heroku 文件。事件頁面可在問題解決後更新，且 Salesforce 的產品覆蓋範圍在 Trust Status 和 My Trust Center 中有所不同。對於 Salesforce 未發布詳細根本原因分析的情況，本文不作推論。