在此閱讀我們的更新排程。

即使發生失敗,彈性解決方案仍可維持高品質的服務。如果效能降低或服務中斷,解決方案會快速且有效地復原。

解決方案的彈性以兩個關鍵品質為基礎:

• 強度:發生問題時,解決方案可承受並持續。
• 彈性:解決問題後,解決方案會回到其理想狀態或形狀。

若要為您的解決方案建立彈性,您必須針對強度與彈性進行設計,以確保在發生計畫與非計畫變化的情況下可持續性與快速復原。

在技術環境中,請將系統或解決方案視為互相相依存的元件集合,以協調以執行共用目標。每個元件都有可能失敗。這些元件中的問題,從程式碼和組態瑕疵到網路和硬體問題,可能會導致非預期的非預期行為。當一或多個元件失敗時,系統會示範彈性行為,但整體系統會繼續運作或快速返回穩定狀態。

為了改善 Salesforce 解決方案的彈性,我們建議專注於三個重要習慣。

• 應用程式生命週期管理 (ALM)—小組如何在整個生命週期中管理軟體,從計畫開始到淘汰
• 事件回應—小組如何識別、解決和防止影響系統可用性或安全性的問題
• 連續規劃—當非預定事件造成問題時,小組計畫其人員和系統如何繼續運作

應用程式週期管理 (ALM) 是一種從建立到淘汰整體管理軟體生命週期的作法。ALM 是系統彈性的基石,包含與應用程式生命週期相關的人員、程序、工具和學科。這些學科包括 DevOps 和傳送方法、可觀察性、測試策略、管治和 CI/CD。

當企業實作有效的 ALM 時,其小組會快速反應變更,且其應用程式會與不斷變化的業務需求保持一致,而不會影響穩定性或品質。

另一方面,若沒有健康的 ALM,小組在應用程式生命週期的每個階段都會面臨困難。

低 ALM 的症狀包括:

• 緩慢且容易出錯的開發週期
• 密集且難以進行的部署
• 在生產和 QA 後環境中發現的高嚴重性問題或錯誤
• 幻燈或行為不一致的 AI 工作人員
• 穩定化版本所需的頻繁回復或 hot-fix 部署

由於 ALM 會觸及解決方案的幾乎每個層面,因此為您的解決方案建立明確且有效的 ALM 作法是您結構工作的關鍵部分。

透過專注在三個關鍵領域來建立更佳的 ALM 作法。

• 發行管理—將變更規劃、排序、控制及移轉至不同的環境
• 環境策略—如何在開發和測試期間在目標環境中使用和管理應用程式的策略
• 訊號策略—重要訊號和應用程式儀器的定義,用於在降級發生前偵測和修復系統內的故障
• 測試策略—引導您規劃和執行測試的方式的原則和標準,以測量在 ALM 流程期間應用程式的成功程度

版本管理涉及規劃、排序、控制變更,以及移轉至一或多個環境。單一版本是一組計畫變更,小組同時移至目標環境。

將變更發佈至系統會對其造成風險。如果系統在變更之前處於穩定狀態,則系統會轉換為新狀態,其也會更容易受到未來變更的風險影響。如果任何未來變更觸發系統中未受控制且不穩定的狀態,則會導致重大事件。在解決方案結構中,針對彈性版本進行設計不僅僅是有效測試個別變更。這也涉及規劃如何安全地對您的系統和其使用者導入變更。

小組的工作取決於可預測且準確的版本資訊。在變更管理與啟用流程中,請清楚瞭解哪些變更會移入您的系統。在您的版本管理與啟用流程中,指定變更發佈至系統的方式及頻率。

您的業務專案關係人也會關注版本資訊,特別是與其要求的功能或錯誤修正相關的資訊。若要對您的解決方案建立 Trust 並向專案關係人展示價值,請建立一致且清楚的版本排程,並寄送穩定的版本成品。

若要為 Salesforce 建立有效的版本管理:

• 與結構與開發管理緊密一致。請確保已提前充分規劃發佈,以符合所有相關的管治論壇和控制。在開始開發之前,請先檢閱並批准 AI 委員會的所有已設定優先順序的 Agentforce 使用個案。取得由「法律與道德使用」小組檢閱的高風險 Agentforce 使用個案。使用部署檢查清單和文件來針對管治活動追蹤部署成品,例如 Agentforce Agentforce API 名稱。
• 請勿使用 以組織為基礎的開發或發行流程。此範例反映開發與發行之較舊、更有限的技術。透過 Salesforce CLI,小組現在可以採用來源驅動的開發和發行功能。
• 選擇盡可能穩定的釋出機制。此方法會完成兩個項目。首先,這會將版本時段和服務中斷的持續時間降到最低。其次,允許高度控制且可預測的版本行為。您的發行機制愈穩定,發行版本將會導入需要 hotfix 或回復的變更的可能性愈低。如果發生非預期的問題,穩定版本機制也會為支援人員或系統管理員建立更簡單的方式來執行回復。

您小組的最佳版本機制是最穩定的選項,讓您的小組具備所需技能。以下是建議的發行機制,依穩定性順序列出。它們彼此相容,因此如果最適合您的公司,請將多個相同使用。

• 解除鎖定的封裝—解除鎖定的封裝是最穩定的版本成品。透過安裝封裝部署變更是導入變更的最快且最可預測的方式。封裝使用版本化,其允許強大的變更管理和微調、系統易於管理的回復。封裝需要強大的中繼資料管理,這可協助您及早識別受管理錯誤的相依性。他們也會建立可稽核的開發管道和成品。請參閱「封裝性」。
• DevOps Center—DevOps Center 可讓具有低程式碼或專業程式碼技能集的傳送小組使用來源控制、針對變更進行協同合作,並定義常見的發行路徑。DevOps Center 與來源控制整合,並允許點選控制變更和部署。
• 使用 Salesforce CLI 進行來源驅動的開發和中繼資料部署—如果您無法使用封裝,請將 Salesforce CLI 用於來源驅動的開發和中繼資料部署。請勿使用較舊的 package.xml 格式部署中繼資料,其結構與建議的 來源格式不同。來源格式已開發以支援封裝開發、臨時組織工作流程,以及更精確的 Sandbox 變更追蹤。此格式更容易閱讀、允許更多複雜中繼資料類型與相依性的分離,並可讓您進一步控制部署資料清單。
• 命名您的版本。提供版本清楚的識別碼,以協助您的小組和專案關係人保持一致。在 Salesforce 中,每個主要版本的名稱會以「Spring」、「Summer」或「Winter」開頭,後面接著是版本的年份 (例如「Summer ’25」。如果您還沒有在公司定義和組織版本的命名慣例,請建立並使用該慣例。使用清楚的版本名稱可讓您輕鬆地在整個小組系統的規劃、開發和傳送的各個階段保持井然有序。在您的藍圖中使用版本名稱,向利害關係人清楚地傳達即將進行的變更以及何時進行的變更。在文件、變更記錄、工作描述、程式碼註解和來源控制的分支中使用版本名稱,讓您可以輕鬆追蹤和稽核開發成品。
• 在版本資料清單中,請順利管理相依性。Salesforce 中繼資料有內建的相依性。Salesforce 部署失敗的常見原因是未正確管理相依性。選擇穩定版本機制 (如先前所述) 可協助您在開發週期前期顯示受管理錯誤的相依性。解除鎖定的封裝是最穩定發行車輛的主要原因之一,是其強大的中繼資料管理,這是封裝開發和建立所需的。如果您或您的版本管理小組不瞭解 Salesforce 中繼資料類型之間的內建相依性,您將無法主動在部署與版本資料清單中發現有問題的組合。請參閱「相依性管理」。

ALM 的 模式和反模式顯示 Salesforce 組織的正確與不良版本管理外觀。使用模式在您建立之前驗證您的設計,或識別系統中需要重新設計的位置。

若要深入瞭解 Salesforce 用於發行管理的工具,請參閱彈性的 Salesforce 工具。

Salesforce 提供各種可供您在應用程式開發和測試週期期間使用的 環境。Salesforce 的有效環境策略需要瞭解如何使用環境以及良好的管理方式。在 ALM 中,開發或測試環境的實用程度取決於其對生產的忠誠度和與生產的隔離性。

良好的環境策略提供數個優點。

• 更忠於生產環境
• 更快速的環境設定與清除
• 在開發和測試中更敏捷
• 整個管道的安全性改善
• 在整個傳送階段中減少雜訊和衝突
• 更快樂的開發小組

小組經常難以實現這些優點。發揮開發環境和策略的挑戰可能來自多個來源。一個可能的來源是您小組遵循的開發模型類型。

在較舊的組織型開發方法中,每個環境都需要提供數個功能。除了您小組執行各種工作的地方外,它還需要是發行成品的來源 (亦即您想要在版本中部署的中繼資料)。由於環境無法輕鬆設定或拆除,因此環境經常過度擁塞,且在小組之間充滿中繼資料衝突,而且不會對整體 ALM 提供有意義的速度或彈性。

使用來源型開發模型會根本地改變環境與發行和發行成品之間的關係。在此模型中,來源控制項是您要釋出之中繼資料的來源。環境只是您小組執行工作的位置。

不過,遵循來源型開發模型並不僅能保證良好的環境策略。即使使用來源控制,小組仍難以設定條件來測試與外部系統的整合;依賴非來源控制的中繼資料組態,例如受管理封裝或依賴 資料的自訂等。在某些情況下,來源型模型的挑戰與組織型模型的典型挑戰類似。

若要開發有效的環境策略:

• 採用來源驅動的開發與發行模型。停止使用 以組織為基礎的開發模型。請參閱 發行管理。)您必須將您的環境從您部署的內容中取消關聯,才能建立健康環境策略和更健康的版本。
• 瞭解每個環境支援的工作類型。Salesforce 支援的環境類型有不同的功能與限制。當您設計環境策略時,請考量環境可以和無法執行的項目。請確保小組在具備所需功能的環境中進行工作。如需指引,請參閱此 Salesforce 開發環境及其功能的概觀。

請參閱此表格以瞭解哪些功能與環境可用於數個常見的開發工作。

此外,請注意,針對使用 Einstein 資料庫、Knowledge 文章和非結構化資料等功能的 Agentforce 工作人員,除非您擁有 Data 360 Sandbox,否則全面測試會受到限制。您也需要 Data 360 Sandbox 來確保準確的測試條件。

• **將環境與版本成品分離。**請勿使用 以組織為基礎的開發。將環境視為工作在固定時間內發生的位置。將環境中的中繼資料狀態視為與您的版本成品分開。如果程式碼或組態在環境中「解析」,則應認可來源控制,使其成為版本成品。

  • 環境為臨時。建立流程,以便您可以盡快建立和終結流程。
  • 成品持續不變。屬於來源控制。

• 將環境與發行路徑分離。查看需要將變更部署至特定環境的必要版本路徑很常見。通常,此方法會實作以建立 Proxy 以驗證應用程式成熟度或版本穩定性。小組也可以使用它來嘗試將其必須設定複雜測試基礎結構的環境數量降到最低。在來源型範例中,您可以更有彈性地驗證和測試變更的方式和位置。

  • 版本階段適用於版本成品,而不適用於環境。請勿建立環境只為了在特定版本階段中「收集」所有變更。這是來源控制 (尤其是分支) 的目的。使用來源控制中的分支策略來組織要部署至哪些環境的變更。視您需要執行的工作而定,您可能需要將版本中的所有中繼資料部署至環境。分支可讓您這麼做。除了某些例外,所有開發環境都必須在相關工作完成後立即重新整理或終結。確定您將在特定環境中進行的中繼資料變更 (且您想要保留) 同步至來源控制。
  • 環境僅與其忠於生產力一樣有用。最佳化您的環境設定工作流程或自動化,以便您可以盡快拆除或重新整理環境。請將阻止您執行更快、更頻繁環境重新整理的任何組態視為對 ALM 流程整體彈性的重大風險。如果您有相關的補救工作,請將其新增至您的計畫並排定優先順序。探索如何在您的系統中採用較寬鬆連接的模組化單位。它們可讓小組在臨時組織中執行更多類型的開發,並可為其他工作釋出 Sandbox 配置。不要忘記臨時組織為您在生產環境中沒有的測試功能提供的功能,因為您尚未購買或啟用臨時組織的授權。
  • 在業務使用者或一般使用者可存取的環境中,讓這些使用者專注於對其而言重要的項目。沒有一般、不區分的環境,讓許多不同的一般使用者或業務專案關係人嘗試執行 ALM 相關工作的群組。邀請特定利害關係人進入特定環境以執行特定工作。仔細評估將一般使用者或業務專案關係人放置在環境中的任何流程,其中包含的資料超過 Partial Copy Sandbox 可支援的資料。確定完成工作時需要資料量。規劃您的使用者接受度測試和早期開發週期,讓這些週期盡可能密切相同。最佳化所有測試階段,以針對您的開發小組和一般使用者啟用更快、更早的回饋意見和反覆循環。請參閱 測試策略。

• 針對不同類型的變更建立不同的版本路徑。並非所有變更都需要以相同的順序完成相同類型的 ALM 工作。讓一般使用者針對系統後端元件的小型變更執行接受測試可能不是使用時間的好方法。然而,在行動應用程式的早期開發階段期間,使用者接受度與規模測試會非常有價值。識別不同種類變更的版本路徑,例如高度風險、中度風險和低度風險。

  • **高度風險:**變更會影響客戶、合作夥伴或所有內部使用者。變更會影響安全性或整合。變更會新增複雜的新功能。
  • **中度風險:**變更會影響的內部使用者超過已定義的值。變更會影響資料模型、執行資料作業的自動化或整合。
  • **低度風險:**直接影響的值低於內部使用者的已定義值。不包含安全性的變更、資料模型或涉及資料作業或整合的自動化。

• 請勿允許擁擠的環境存在。在排定優先順序、設定範圍和排序工作方面缺乏規律,導致開發環境過度繁重,工作量過多、過多、過多。擁擠的環境會在開發小組之間造成高層級的壓力、不明確性和衝突。他們也會在開發管道內產生雜訊,並阻礙品質控制工作。除了這些負面影響之外,過度擁塞的開發環境對環境維護和安全性也構成嚴重威脅。請將過度擁塞視為 ALM 流程中潛在問題的症狀。調查任何根本原因問題並加以解決。如果您仍然面臨擁塞,您可以購買額外的 Sandbox。

ALM 的模式與反模式清單顯示 Salesforce 組織中的適當與不良環境管理外觀。使用這些選項在您建立之前驗證您的設計,或識別需要重新設計的系統區域。

若要深入瞭解環境管理的 Salesforce 工具,請參閱彈性的 Salesforce 工具。

訊號策略會定義偵測、診斷和修復失敗所需的關鍵訊號和應用程式儀器,然後再串聯至全系統降級。有效的儀器處理可將應用程式從被動失敗的受害者轉換為活躍的參與者,以其自己的彈性來偵測問題、調整其行為,並在必要時協調慷慨降級。

當應用程式實作全方位儀器時,他們能夠在壓力下自行調節、向操作員傳達健康狀態,並參與協調的復原工作。這些功能可讓系統在個別元件遇到麻煩時,維持服務品質。另一方面,若沒有適當的儀器處理,應用程式會變成黑色方塊,直到出現災難性症狀為止會無聲地失敗。小組只有在使用者回應問題後才會做出回應,且疑難排解會成為考古中的演練,而非觀察。

• 偵測應用程式內的失敗。應用程式必須自行儀器化,以偵測並回應在負載中出現的常見失敗模式。請考慮排列飽和度。當訊息的填入比處理的速度更快時,未經工具處理的應用程式會繼續接受工作,直到發生記憶體耗損或逾時的階層為止。正確儀器化的應用程式會監視排列深度、拒絕率和處理延遲,在超過值時觸發防禦回應。

• 有效處理應用程式外部的訊號:作業系統中訊號的處理代表另一個重要儀表點。應用程式必須為終止訊號 (SIGTERM、SIGINT) 註冊處理常式,才能啟用寬鬆關機。在關閉期間,正確儀器化應用程式會停止接受新工作、允許完成即時要求、清除緩衝時間、清除連線,以及取消註冊服務探索。此協調式關機可防止資料遺失,並允許載入平衡器在不中斷的情況下重新導向流量。

• **複雜失敗案例的工具:**除了這些基本模式之外,應用程式必須針對更微妙的失敗模式進行儀器操作。識別灰色失敗,其中元件在某些觀察者看起來健康,而在其他觀察者看起來失敗,需要同時建立內部與外部訊號的關聯。應用程式可能會使用其資料庫連線集區來報告成功的健康檢查,同時追蹤顯示流失降級的交易完成率。有效的儀器策略會分層多個觀察點。

  • 業務度量可追蹤應用程式特定成功指標,例如訂單完成率或搜尋結果品質。
  • 系統度量會監視資源利用率、延遲分佈和錯誤率。
  • 合成探測器會持續執行重要路徑,以在使用者遇到降級之前偵測降級。
  • 散佈式追蹤可提供跨服務界限的要求層級可視性。

這些訊號透過標準化介面公開,允許自動化系統與人類操作員評估應用程式健康狀況。此儀器本身會成為應用程式彈性策略的一部分,讓斷路器能夠根據錯誤率出差、自動刻度器能夠回應排列深度,以及操作員能夠在事件期間做出明智的決策。

ALM 的 模式和反模式顯示 Salesforce 組織中正確和不良的訊號策略呈現的外觀。使用這些選項在您建立之前驗證您的設計,或識別需要重新設計的系統區域。

若要深入瞭解訊號策略的 Salesforce 工具,請參閱彈性的 Salesforce 工具。

測試策略是一組指引原則和標準,用於規劃和執行測試,以測量 ALM 流程期間應用程式的成功與失敗。測試策略可讓參與測試的每個利害關係人持續掌握並符合指定測試的優先順序、目的和範圍。這也會協助專案小組建立有效且謹慎的測試計畫。

通常,開發人員或品質保證和測試專家會參與建立和執行特定測試。測試策略有助於確保這些人員知道指定專案需要執行的測試類型,以及要執行的順序。測試策略也有助於確保小組擁有建立整齊測試、測試計畫和成品所需的功能 (例如測試資料集、裝置和流量或網路模擬器)。

有效的測試策略可讓您清楚瞭解如何、何時、何處以及為何在各種組合和條件中執行不同的測試類型,包括單元測試、UI 測試和迴歸測試,以發現系統和任何飛行中變更將如何運作。有效的測試策略會產生測試,以向您展示系統是否符合非功能需求 (例如可擴展性、可靠性和可用性),這可能難以透過單一類型的測試來測量。

建立 Salesforce 的有效測試策略:

• 盡可能以反覆、頻繁且透過自動方式進行測試。設計並實作測試自動化,讓小組能夠針對各種工作量執行各種測試類型。協調各種測試回合,以在變更進入來源控制時自動執行。此方法可讓小組主動識別並及早處理迴歸。如果可以的話,請針對此工作使用連續整合/連續傳送 (CI/CD)。如果您沒有,請建立明確的測試計畫,讓小組以自助方式及早且經常執行測試序列。針對 Agentforce 工作人員測試,請依賴測試中心來對具有各種輸入的 AI 工作人員進行嚴格的批次測試,以確保其在不同案例之間正確運作。
• 請注意,並非每個變更都需要每種類型的測試。就像有效的發行管道能容納高、中和低風險應用程式的路徑一樣,有效的測試策略也是如此。為小組清楚概述如何為具有各種風險、使用個案或複雜性的應用程式選取並遵循適當的測試模式。請參閱「環境策略」。
• 定義可在不同環境類型中執行的測試。對生產的忠誠度是準確測試的關鍵元件,但這對於不同類型的測試而言意味著不同的項目。例如,迴歸測試在中繼資料和部分資料方面需要忠於生產環境。請務必定義指定測試集所需的生產忠誠度類型,並清楚分類哪些類型的環境可以支援適合不同測試的條件。如需符合每個環境類型之工作類型的概觀,請參閱「環境策略」。
• 使用耐用度、壓力、效能和規模測試來持續測量應用程式成熟度。這些測試顯示應用程式相對於生產層級需求的發行準備方式。針對主要新功能,請在應用程式開發週期中以數個間隔執行這些測試。將這些測試視為僅為單一開發階段或階段的一部分,而非為進行中工作的一部分,是反模式。小組最有用的是提早且經常取得有關應用程式效能的回饋意見,這有助於小組更進一步瞭解應用程式在生產層級整備前的距離或距離。能夠在變更進入生產環境前更進一步識別並解決問題,值得經常執行更複雜的測試來增加複雜性。
  • 瞭解哪些測試很重要。您可能會有固定的時間執行規模或效能測試,因此測試系統的每個面向並不實用。並非所有功能都會平均使用,且並非所有規模瓶頸都會平均影響業務。請確保您的刻度測試專注於系統中最常使用且高價值的部分。定義並瞭解驗證和改善組織規模與效能最重要的機會。
  • **瞭解「good enough」的外觀。**定義規模與效能測試的成功條件十分重要。請確保您與開發小組使用成功條件作為測試基準。此外,請確保他們會告知開發小組建立的功能需求。這些條件通常包括支援少於協議值之回應時間的特定同時使用者數目,以及您的 服務層級目標 (SLO)。定義關鍵目標條件,然後設計規模和效能測試以確保符合條件。
  • **確定您擁有適當的環境。**規模和效能測試需要對生產的特定忠誠度。您在非生產環境中的資料集、要求人口、要求率和工作量特性都應盡可能與您在生產環境中看到的內容相符。針對規模測試,您必須使用完整 Sandbox。如果您的組織沒有完整 Sandbox 供規模測試使用,則您無法執行適當的規模測試。
• 確保測試工作量可協助您測量非功能需求。請記得考量:
  • 測試資料 - 針對與生產組織隔離的資料,應執行各種測試。在 Apex 單元測試中,實作 資料工廠模式以確保程式碼產生自己的測試資料,並與環境資料隔離。您也可以建立和維護各種格式的測試資料集,以測試資料載入行為、使用以 UI 為基礎之測試的資料填入開發環境,並協助進行整合測試。所有測試資料,無論是作為外部化資料集維護或依需求透過資料工廠程式碼建立,都應清除敏感且可識別的資料。其應包含損毀、不完整和格式錯誤的資料,以支援負值和邊界單元測試行為。
  • 模擬與實作服務 - 針對整合測試,您可以使用模擬與實作服務來模擬 API 回應。Apex 支援建立模擬架構以用於 Apex 測試的 Stub API。模擬以建立可用於 Apex 測試的模擬架構。模糊與實體可協助驗證系統的資料處理行為,並減少對複雜資料工廠或外部測試資料集的依賴。模糊與虛線有時更適合用於與生產類似的流量或資料量無關的測試。
  • 裝置與輔助技術—建立具有吸引力的和可存取應用程式的關鍵部分,就是確保這些應用程式符合各種裝置與不同類型的輔助技術的使用者期望。有效執行有意義的可用性測試可能需要更多投資和不同類型的專業知識,但瞭解使用者面向應用程式發行時結構的程度至關重要。
  • 模擬器 - 當您需要複製類似生產的使用者要求、API 流量或網路速度變化時,可能需要模擬這些條件的工具。並非每個測試都需要此層級的投資。這些工具在延展性和效能測試中通常最有用。
  • AI 與工作人員測試-測試的主要目標是減少 AI 幻覺,其為令人信服且不正確的回應。確保已測試 AI 使用個案,以醒目提示由於對客戶不完整瞭解、遺漏資料、具有不完整中繼資料的欄位,以及過時資料所導致的常見問題。使用測試中心協助建立此類測試的必要測試資料。

下表顯示要在您的組織中尋找或建立的模式選項,以及要避免或鎖定修復的反模式。

✨ 在「模式與反模式探索器」中探索更多 ALM 的模式。

在安全性和網站可靠性工程 (SRE) 中,事件回應著重於小組如何識別和解決影響系統整體可用性或安全性的事件,以及小組如何處理根本原因並防止未來的問題。事件回應涉及即時和發生問題後解決問題所需的流程、工具和組織行為。

身為結構設計師,您可能不是監視解決方案上線後每日作業的人。彈性結構設計的一部分是設計復原功能,讓支援小組能夠執行第一層診斷、穩定化系統,並有效地將調查和根本原因緩解移交給開發或維護小組。每天直接支援使用者的小組可能對系統結構沒有深入的瞭解或專業知識。這些小組必須具備監視每日作業、在診斷潛在事件時從系統存取資訊,並作為影響可用性的任何問題的有效第一個回應者所需的工具和流程。

您可以專注於您的復原時間、分級能力,以及監視和警示,以改善小組在 Salesforce 解決方案中對事件的回應程度。

發生事件時,第一個優先順序必須是將系統還原為穩定營運狀態。通常,企業會認為從事件復原的唯一方法是「修正問題」。此假設是正確的,因為精確的根本原因分析和補救是您最終解決系統中重要問題的方式。然而,在危機回應的早期階段中「修正問題」並非最實用的方法。視事件的嚴重性而定,每秒的事件及其影響都可能導致公司收入或聲譽損失。

通常,嘗試診斷並解決根本原因會使系統恢復運作的努力延遲。在物流上,採用要求事件回應者解決根本原因的方法會對您公司的主題專家 (SMEs) 和支援人員造成巨大的負擔。若要尋找並修正事件期間的根本原因,則 SMEs 需要隨時瞭解每個事件,這會阻止前線面向客戶的支援人員採取行動。這也會導致小組發佈變更,進而建立更多事件。最終,此類方法會增加成本、消耗各小組的頻寬,並導致危機時的行為會損毀客戶 Trust 和品牌聲譽。

正確的事件管理模式是在第一個步驟中排定優先順序並專注於復原。將系統還原為穩定後,您可以追蹤無罪的死亡後狀況、事件調查、根本原因修復和類似活動。此作業順序可讓事件回應人員更妥善地分級、診斷和執行復原策略,並警示相關的 SME 僅在必要時提供協助。它也可讓中小型企業以較低的計時壓力來識別並修正事件的根本原因。

若要採用復原優先的心態以處理事件回應:

• 建立並達成服務層級目標 SLO。SLO 是您與專案關係人針對系統的特定非功能需求 (NFR),例如效能或執行時間,開發的標準。這些目標會在一段期間內以服務層級指標 (SLI) 測量。若沒有 SLO,與事件回應和疑難排解複雜問題相關的大部分工作可能會感到無組織且反應性,例如,提示快速動作以「為此少數報告的使用者停止此特定錯誤」。此週期通常會導致小組推送更接近事件回應的根本原因分析,因為這似乎有助於停止反應性行為。建立 SLO 和 SLI 是更有效率的入門方法。若要建立 SLO,請思考下列問題。
  • **未來 1-3 年您的系統 NFR 為何?**例如,您的 NFR 可能包含您的系統必須能夠支援的回應時間、峰值要求率和同時使用者。
  • **您希望客戶及其使用者體驗什麼?**您的 SLO 以此問題的答案為基礎,其可能是「使用者可以在 Salesforce 中快速執行報告」。
  • **您可以測量什麼,以及應該測量的期間為何?讓您的 SLI 以此問題的回答為基礎。符合先前範例的 SLI 可能是「_x% 的報告在 n 秒內 _n 載入,平均在 30 天內測量」。
• **定義並標準化復原策略。**變更回復和因應措施實作可協助讓系統再次正常運作,並將事件的影響降到最低。記錄可由支援或作業小組的適當成員執行的復原策略和通訊協定。復原策略會根據事件類型而有所不同。下表顯示將事件類型對應至復原策略的一般架構。如需識別失敗點和定義緩解策略的詳細資訊,請參閱「可用性」。

• 定義清楚結束條件。使用您的 SLO 判斷您的系統何時處於事件或影響狀態外。
• **定義事件後審查和根本原因修復的流程。**請在服務還原後花時間檢閱事件。在檢閱期間,採取一種無罪的死後方法。與利害關係人合作,專注於建立關於發生事項和發生方式的清楚事實,而不是嘗試將錯誤或責任指派給個人。使用不同的檢閱格式來檢查如何在長期內解決問題。
  • 動作後審查專注於事件的回應。評估是否有適當的回應流程和策略很有用。
  • 根本原因分析專注於事件的根本原因。這可協助識別導致事件的系統設計和實作中任何錯誤或問題。
• 定期實作協議的復原通訊協定。實作復原通訊協定,以確保每個人都瞭解如何妥善處理事件。使用 Sandbox 和測試環境,為小組提供練習事件模擬和復原的空間。也請練習事件後審查。執行所有這些作法可讓復原成為您工程和支援文化的一部分。

事件回應的 模式和反模式會顯示在 Salesforce 解決方案中優先處理復原的結構。使用這些選項在您建立之前驗證您的設計,或識別需要重新設計的系統區域。

若要深入瞭解可協助修復時間的 Salesforce 工具,請參閱 Salesforce 彈性工具。

在技術環境中,分級涉及為問題和支援要求指派種類和嚴重性層級。無論您的解決方案計畫程度如何,使用者支援問題和要求都會發生。這些問題可能來自缺乏足夠的訓練或變更管理、UI/UX 缺口、非預期的一般使用者行為,以及未被 監視或警示抓到的緊急系統問題。

支援和作業小組必須能夠有效率地調查使用者支援查詢並快速診斷。將問題分級以篩選出較不嚴重的疑慮,並快速找出重要的系統事件是這些小組的關鍵能力。排序不良會使所有層級的使用者支援速度變慢、延長重大事件,並增加客戶和業務進一步中斷的風險。

雖然您可能不參與日常作業和支援,但身為結構設計師,您有責任協助確保您的支援和作業小組能夠有效地在 Salesforce 平台上建立的任何解決方案中分級問題。

若要讓小組有效地分級 Salesforce 解決方案中的問題:

• 確保支援小組可存取實用資訊。
  • 記錄您的系統和設計模式。確保解決方案的可讀性和一致性是讓支援人員瞭解負責支援的系統的重要部分。在您的文件中,請考量小組如何尋找有關如何排定系統不同部分問題或事件優先順序的資訊。此外,請確保小組可以根據影響區域快速取得有關復原策略的技術資訊。針對常見 Agentforce 問題 (例如主題分類和動作選取) 提供相關的疑難排解指南,可協助小組快速分級與權限或組態相關的問題。
  • 設計時請謹記除錯。支援小組和組織管理員必須啟用除錯和診斷,才能在各種環境中正確地分級使用者問題。除錯易用模式的範例包括將記錄和自訂錯誤訊息納入整個系統的執行路徑。透過如事件記錄和工作人員產生器的推理檢視等工具,啟用常見 Agentforce 除錯方法的支援小組。
  • 識別事件的 SME 和利害關係人。建立應可支援事件復原的相關 SME 或利害關係人清單,以及應在事件後分析期間參與的利害關係人清單。
  • 謹慎處理手續。確保在上線過程中,每個解決方案轉送給支援或作業小組的品質。為支援人員提供訓練,以逐步完成相關的系統結構和模擬事件回應逐步解說。請思考事件後處理,包括小組應如何記錄記錄或個案備註未獲取的資訊,以及事件回應者如何貢獻至根本原因調查或針對任何補救措施執行使用者接受度測試。
• 若您被諮詢,請讓所有人專注於復原作為首要考量。
  • 快速回應快速回應任何使用者支援要求、監視通知和您收到的警示。
  • **協助區分症狀與問題。**工作以判斷是否有需要處理的實際系統事件。嘗試識別具有實際問題的元件。協助確保遵循協議的 復原策略,以快速將系統從事件狀態中移出。
• 針對支援重要使用個案的 Agentforce 工作人員,請確保已具備可行且相關的因應措施,並可在短時間內開啟作為冗餘措施。範例包括切換至手動處理或重新導向至相關文件以手動檢閱。

事件回應的模式和反模式顯示如何在 Salesforce 解決方案中進行有效分級的結構。使用這些選項在您建立之前驗證您的設計,或識別需要重新設計的系統區域。

若要深入瞭解 Salesforce 工具以協助分級,請參閱 Salesforce 工具以提高彈性。

監視和 警示是網站可靠性工程中廣泛使用的詞彙。在系統彈性的情況下,監視會持續評估系統的目前狀態,而警示會自動通知利害關係人關於關於系統狀態的潛在疑慮。有效的監視與警示是將系統規模與成長與支援人員規模與成長分離的重要部分。

Salesforce 提供各種內建功能,可監視系統中的行為。Salesforce 也提供附加元件或作為 Salesforce Shield 一部分的 即時事件監視。在任何 Salesforce 解決方案中,針對監視與警示所建立的設計提供:

• 自動事件回應的功能
• 在正確的時間將相關資訊提供給正確的使用者
• 清除歷程記錄檢視和趨勢分析的資訊

若要設計 Salesforce 解決方案內的有效監視與警示:

• 優先處理自動化。雖然通知使用者有關重要狀態變更是保持系統穩定和作業的關鍵部分,但在理想的結構中,系統會盡可能自行修正問題,並僅針對緊急且無法復原的問題傳送警示。即使沒有自我修正功能,自動化也可以讓您的警示和報告更有用。
  • 從 Salesforce 已提供的內容開始。Salesforce Platform 提供相關的記錄和 API,可讓您監視解決方案在管理員限制中執行的作業。此外,平台會針對管理員限制違規和類似問題傳送警示。使用這些記錄和警示作為探索如何更完全自動化系統自助復原、事件報告和警示的基礎。例如,您可能會實作監視記錄的自動化,然後在記錄特定類型的事件時採取復原動作。
  • 以可預測的方式對系統狀態的變更進行分類。針對您要監視和報告的主要狀態建立具體且有意義的種類。將這些種類與您定義的種類保持一致,以管理您應用程式元件中的狀態。針對您處理狀態變更資訊的方式,採用以 API 為導向的心態。一致的訊息格式和狀態種類可簡化自動化、報告和警示。
  • 讓自動化邏輯與系統的其他部分保持一致。如果您已建立適當的自動化 錯誤處理方式,您可以將這些模式延伸至分類狀態變更和使用自動化回應的方式。針對視為可復原的狀態變更,您可以自動化重試行為。針對視為嚴重或致命的狀態變更,將警示自動傳送給使用者。
• 避免產生雜訊。當使用者收到太多警示時,尤其是不需要採取任何動作的警示時,他們會開始停用或忽略所有警示。此情況會破壞建立 實用警示的任何努力。若要進一步確定接收警示的人員範圍、觸發它們的原因以及觸發它們的時間,請考慮進行下列動作。
  • 建立利害關係人地圖。若要確保您的系統在正確的時間將正確的警示傳送給正確的利害關係人,請先識別並分類您的利害關係人群組。
  • 根據使用者權限路由訊息。僅將警示傳送給具有回應能力和權限的收件者。業務使用者可能會受益於可透過修正其擁有存取權之記錄中的問題來修正之問題的相關警示。如果問題需要更積極的技術回應,則警示應導向至支援人員。
  • 讓預期回應清楚明確。僅在需要人力介入的情況下傳送警示。結構化訊息以清楚指出要從收件者採取的動作。如果您傳送警示給利害關係人以取得可視性,且他們不需要採取任何動作,請在他們收到的訊息版本中明確說明。
  • 讓警示及時且相關。作為回應已發生且仍需要補救的失敗而傳送的警示) 不如有關潛在失敗的警示有幫助。理想情況下,支援人員會在系統中出現問題狀況時立即收到警示,以便在問題對業務營運造成負面影響之前分級問題。

模式和反模式清單顯示如何在 Salesforce 解決方案中進行有效監視和警示的結構。使用這些選項在您建立之前驗證您的設計,或識別需要重新設計的系統區域。

若要深入瞭解用於監視和警示的 Salesforce 工具,請參閱彈性的 Salesforce 工具。

此表格顯示要在您的組織中尋找或建立的模式選項,以及要避免或鎖定修復的反模式。

✨ 在「模式與反模式探索器」中探索更多事件回應的模式。

業務彈性的一個關鍵是持續性規劃,其著重於如何讓人員和系統透過因非預定事件造成的問題運作。業務連續性計畫 (BCP) 會以人員為導向的方式檢視如何讓流程在危機中繼續進行。持續性計畫的技術層面包含在 BCP 的災害復原部分中。請參閱 技術持續性。

若沒有適當的連續性計畫,您的組織現在可能會知道如何在危機或系統中斷期間採取動作,因此完全無法採取動作。無效的持續性計畫會對客戶、利害關係人和業務造成災難。在發生不良事件後,每個沒有維護或復原重要流程的時刻都會造成財務損害、聲譽損害、員工安全,甚至是法規合規性的風險。

您可以將精力專注在三個區域中,以在系統中建立更佳的連續性計畫:定義 Salesforce 的業務連續性、規劃技術連續性,以及建立備份與還原功能。

您的公司可能已具備 BCP。如果是,請確定其中包含 Salesforce。如果貴公司沒有 BCP,請與您的專案關係人合作建立一個涵蓋您 Salesforce 組織的專案。

Salesforce 經常被視為在許多業務部門中客戶資料和重要業務流程的事實來源。因此,Salesforce 在 BCP 中扮演的角色可能與其他系統扮演的角色不同。Salesforce 可能會參與許多高優先順序的復原區域。

若要為 Salesforce 系統建立相關的業務連續性計畫:

• 澄清復原的優先順序。如同一般的 事件回應方法,復原在危機時必須是系統的首要任務。許多關鍵業務的服務都會在 Salesforce 中和 Salesforce 中執行。您必須協助利害關係人識別復原各種業務功能和功能的正確優先順序。一般架構可以是:
  • 穩定化重要的業務基礎結構。
  • 穩定化客戶服務。
  • 穩定化員工和合作夥伴服務。
• 在您的 BCP 中考量您的生態系統。Salesforce 並非您環境中的唯一系統。請確保您在與 Salesforce 整合的系統、從 AppExchange 廠商安裝的解決方案,以及任何其他連線至 Salesforce 中資料或程序的系統中,識別 BCP 中的間隙。如果您的交付能力取決於廠商,請詢問這些廠商有關其連續性計畫。評估其功能並規劃如何讓系統保持可用。
• 將 BCP 疑慮整合到測試策略中。為您的 BCP 建立測試計畫並執行。測試與流程或人員相關的 BCP 區域 (通常會被忽略) 特別重要。將 BCP 的相關項目納入您的整體 ALM 測試策略。建立並遵循維護排程來檢閱測試,並確保計畫處於最新狀態。

連續性規劃的 模式和反模式顯示 Salesforce 解決方案中正確與不良的連續性規劃外觀。使用這些選項在您建立之前驗證您的設計,或識別系統中需要重新設計的位置。

若要深入瞭解用於定義業務連續性的 Salesforce 工具,請參閱彈性的 Salesforce 工具。

技術連續性的目標是確保系統中元件的問題不會阻止企業維護重要的作業。Salesforce 會優先將服務維持在最高層級的可用性,並提供有關任何問題的透明資訊。您可以在 trust.salesforce.com 查看 Salesforce 系統效能與問題的即時資訊。身為 Salesforce 上的結構設計師,您的解決方案可從 Salesforce 在整個平台上提供的網站可靠性、安全性和效能功能中獲益。

不過,Salesforce 解決方案的整體連續性會超出 Salesforce 所提供的內建服務。從結構角度來看,Salesforce 技術持續性規劃必須先詢問與回答 Salesforce 如何適應您大企業的問題。哪些類型的系統可以與 Salesforce 整合?外部系統如何依賴 Salesforce 中的程序或資訊?在您的 Salesforce 組織中,哪些程序或功能依賴 AppExchange 解決方案?您的使用者是否透過第三方身分識別服務或 SSO 存取 Salesforce?

若要在您的 Salesforce 系統中建立更佳的技術連續性:

• **評估您的基礎結構。**技術中斷或問題的最常見補救策略是建立可在事件發生期間回復的冗餘服務或系統。在 Salesforce 中,我們有刻意冗餘的結構,這表示我們在不同的實體位置中維護客戶系統和服務的複本。我們使用數種災害復原技術,包括網站切換,這可讓我們視需要將使用者流量從一個資料中心導向至另一個資料中心。若要找出您可能需要建立刻意冗餘的位置,請詢問自己下列問題。
  • [X] 服務服務中斷期間會發生什麼狀況?我們可以從該服務切換至另一個服務嗎?
  • 還原 [X] 需要多長時間?對客戶的影響為何?對我們的合作夥伴有何影響?對內部小組的影響為何?
  • 備份及其頻率為何?備份是否可以提供支援業務所需的資料?
  • 我們是否依賴廠商?其 BCP 計畫為何?
• **提供作業支援。**作業支援旨在讓小組盡快備份並執行。請思考您的系統如何處理產能需求大幅增加,以及因非預期變更 (包括產業範圍、區域範圍或全球變更) 的需求。確定您的 BCP 會考慮「網站可靠性工程」(SRE) 或支援小組可能需要的額外資源或斷眼流程,以有效回應事件。有關作業支援的問題包括:
  • 在中斷狀況下,我們的技術小組是否擁有繼續工作所需的工具?我們是否已模擬中斷以驗證計畫或識別間隙?
  • 如果災害位於特定區域,我們是否有該區域的涵蓋範圍計畫?
  • 我們的客戶是否為全球客戶?他們是否全天候營業?
  • 我們是否有適當的監控和警示,以在失敗時通知適當的個人?
• **自動化並測試復原策略。**修復問題後,識別問題發生的位置以及修正方式。如果您可以,請根據補救措施自動化復原策略並調整任何流程問題。許多公司會為服務子集排程事件模擬,以測試系統彈性。例如,模擬系統管理員帳戶遭到鎖定或入侵,或模擬 AppExchange 提供者的中斷或問題。請參閱 事件回應。) 有關測試和自動化如何協助您更快還原服務的問題包括:
  • 我們排程並執行事件模擬的頻率為何?
  • 我們知道將服務還原為穩定狀態所需的時間為何?
  • 我們是否有穩定的遞送流程?
  • 我們知道我們可以在何處自動化錯誤轉換和復原嗎?

處理事件後審查中的任何項目,就像其他開發項目一樣。將其新增至您的規劃系統,讓您可以排定其優先順序並處理。

連續性計畫的 模式和反模式顯示 Salesforce 解決方案中正確與不良技術連續性計畫的外觀。使用這些選項在您建立之前驗證您的設計,或識別系統中需要重新設計的位置。

若要深入瞭解適用於技術連續性規劃的 Salesforce 工具,請參閱彈性的 Salesforce 工具。

還原資料或中繼資料的備份副本有助於將您的組織恢復為其最後已知穩定狀態。它也可以在災難性系統失敗或服務中斷期間提供故障切換系統。定期備份您的資料和中繼資料,並將加密的備份複本儲存在安全的位置,可為您的結構增加額外的彈性。

若沒有備份與還原策略,當生產資料和中繼資料遭到惡意損毀、瑕疵不小心進入生產環境時,或當大量資料載入時發生故障損毀生產資料時,您便無法還原生產資料和中繼資料的清除版本。以下任一情況可能會造成業務關鍵生產資料損毀或甚至永久遺失。除了持續性規劃外,設定備份與還原技術還提供許多優點,包括協助制定策略來減少大量資料,並遵循與合規性相關的保留原則。

若要協助確保 Salesforce 解決方案中備份與還原策略的連續性:

• **開始.**擁有正確備份與還原策略的第一步,就是先擁有策略。即使是對您組織所有資料和中繼資料進行夜間備份等簡單的動作,也可讓貴公司在災害期間免於遺失重要資訊或功能。
• **限制備份的存取權。**系統管理員是唯一能夠存取資料備份複本的使用者。該存取權限制會讓業務使用者無法在未獲授權在貴組織中檢視的備份複本中檢視記錄。
• **定期測試還原流程。**無論您實作的備份與還原策略為何,請定期在「完整複製」或「部分複製」Sandbox 中測試還原流程,以確保在您需要時正確運作。
• **讓備份與還原策略與資料歸檔策略保持一致。**決定當記錄歸檔或從系統清除時,備份或歸檔應發生的狀況。請參閱 資料量)。

如果您的資料量這麼大,完整備份在下一個備份開始執行之前沒有時間完成,您可能需要更精確的備份策略。如果您組織的資料變更頻繁,因此更新對您的組織至關重要,您可能也需要更精確的備份策略。

若要讓備份策略更精確:

• 將備份範圍縮小至特定物件。此策略涉及在不同時間間隔備份不同物件的記錄。請記住,子系物件必須與其父系物件相同的時間間隔備份,才能維持資料的一致性。
• 時間箱 部分備份。此策略涉及區分完整備份 (所有資料和中繼資料) 和部分備份 (僅限自上次備份後新增或變更的中繼資料和記錄)。

* 請勿停止執行完整備份。請務必注意,即使資料量導致執行時間過長,您絕不應該完全去除完整備份。針對大量資料,請規劃定期但不常進行的完整備份 (例如每週備份)。也請規劃更頻繁的部分或物件特定備份 (例如,每晚備份或每 X 個小時備份)。此方法可讓您彈性重建最完整且準確的資料集,以用於還原流程中。*

連續性規劃的 模式和反模式會顯示 Salesforce 解決方案中正確與不良的備份與還原功能外觀。使用這些選項在您建立之前驗證您的設計,或識別系統中需要重新設計的位置。

Salesforce Backup and Recovery 是一種整合的 Salesforce 解決方案,其中包含「自助式復原」,可保護重要資料免受遺失或損毀。我們高度安全、易於設定且隨時可用的解決方案可確保業務連續性與資料彈性,並簡化合規性。

使用 Salesforce Backup 與 Recovery 可防止資料遺失、快速從資料事件復原,並簡化您的整體資料管理策略。您可以針對高價值和受監管的資料建立備份原則,並按幾下滑鼠來還原該資料。

自動每日備份可保護您所有的關鍵組織資料,包括中繼資料、Sandbox、受管理封裝資料、檔案附件等。視需要頻繁執行備份,以符合復原點目標 (RPO) 目標並保護您的部署。備份一律可供存取,並以安全且合規的方式儲存。「持續資料保護」也適用於更敏感或交易性的資料,可加速復原快速變化的重要資訊。

透過直接傳送至電子郵件的主動警示來偵測異常的資料活動、資料遺失和損毀。接收即時警示以識別統計極端值,或建立通知您異常資料活動的規則,協助您比以往更快地偵測事件。

Salesforce Backup 與 Recovery 透過提供更改的細微可視性,可快速識別及還原受影響的資料來加速復原。如視覺圖形等工具會醒目提示不想要的變更,而易於使用的復原功能可精確還原受影響的物件、欄位和記錄。

我們的工具可讓您使用備份進行分析、稽核和合規性,提供可搜尋的歷程記錄資料、開啟搜尋功能以瞭解過去資料的可視性,以及匯出外部分析或倉庫的功能。這會重新使用備份,而不需要額外的 Salesforce API。

「備份與復原」提供單一主控台,以合併所有備份、管理、作業與合規性。此主控台可讓您存取、管理、自訂和監視所有生產組織和 Sandbox 的備份。透過此功能,您也可以執行資料主題要求以確保備份資料合規性,並擁有自訂備份排程、頻率和保留原則的完整控制權。

• 減少資料事件的影響。Salesforce Backup and Recovery 可讓使用者將受影響的記錄回復為其事件前狀態,藉此協助緩解資料事件 (例如網路攻擊或惡意內部或外部活動)。「備份與復原」的匯出功能可保證持續存取與使用者重要資料的可用性。
• 防止永久資料遺失。人力錯誤仍是資料遺失的主要原因。「備份與復原」提供這些錯誤的精確快速解決方案。
• 更輕鬆地符合資料合規性和法律需求。Salesforce Backup and Recovery 支援共用責任模型,啟用備份資料中大量忘記或資料修正的自助式服務功能。

若要深入瞭解用於備份與還原的 Salesforce 工具,請參閱彈性的 Salesforce 工具。

此表格顯示要在您的組織中尋找或建立的模式選項,以及要避免或鎖定修復的反模式。

✨ 在「模式與反模式探索器」中探索更多連續性規劃的模式。

協助我們讓 Salesforce Well-Architected 與您相關;進行我們的調查以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。