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

可靠的解決方案可有效且可靠地運作。它們可供使用、一致執行,並調整規模以支援不斷成長的業務。

可靠的系統不容易出錯、會如預期運作,並及時提供結果。相反地,不可靠的系統速度緩慢、行為未如預期,或在重要時機失敗。不可靠的系統提供不準確的資訊,因此利害關係人無法 Trust 他們進行業務決策。

系統可靠性並非不變。如果未針對成長而設計,今天可靠的系統可能會變成不可靠。不可靠的系統可能需要昂貴的維護、重建或重新實作,從策略專案中轉移資金。

專注於三個原則:可用性、效能和可擴展性,以提升 Salesforce 解決方案的可靠性。Salesforce 的可擴展性產品套件提供原生功能,協助結構設計師實作可靠的作業。

可用性是測量系統營運時間的百分比。Salesforce Platform 會處理大多數的 基礎結構層級可用性問題。不過,您在平台上建立且客戶體驗的解決方案可用性是共同的責任。請務必瞭解,即使 Salesforce 的 高可用性仍是如此,服務中斷的風險永遠不會為零。

結構設計師必須針對如計畫維護或未預期的狀況等 Salesforce 服務中斷進行準備。除了服務中斷之外,請考慮如何維持高效能並隨業務成長。縮小結構選項範圍可能會導致長期可用性問題。

在建立解決方案 之前,請在設計階段考量可用性。您延後建立可用性的時間愈長,長期而言,可用性問題的實際成本愈高。若要降低潛在風險,請在測試環境中使用 Salesforce 規模測試。在該環境中,您可以在生產規模中進行測試,再於生產環境中部署程式碼。

結構設計師使用業務語言,為業務專案關係人建立技術考量,以獲得參與度並排定可用性工作的優先順序。若要降低潛在風險,請在測試環境中使用 Salesforce 規模測試。在該環境中,您可以在生產規模中進行測試,再於生產環境中部署程式碼。

您可以透過風險管理和故障減輕來架構 Salesforce 解決方案的更高可用性。

在 Salesforce 結構內容中管理風險涉及識別系統作業、其使用者 (包括員工、合作夥伴和客戶) 的潛在風險,以及您的業務流程。通常,執行風險分析的正式流程屬於專案經理的責任。身為結構設計師,請確保風險分析充分代表技術和業務專案關係人的疑慮。您也應負責根據生產量高峰熱點識別您需要進行規模測試的業務關鍵使用個案。

風險管理中的一些最大的陷阱是由於未投入足夠的時間和考量。小組通常會略過風險評估,或將解決方案進行 備份與還原 (降低資料完整性風險的重要部分) 與全方位風險評估與緩解混合。

若要評估 Salesforce 解決方案的風險,請使用下列方法:

• 使用風險評估架構。某些大型企業可能已具備相關風險矩陣。如果您有,請使用它們來決定如何分類危險、要收集的資訊類型、您需要準備哪些修復措施等等。如果您還沒有風險評估架構,請從聲譽良好的來源中尋找並使用架構。
• 從客戶的觀點評估影響嚴重性和風險種類。Proactive Monitoring and Scale Center 提供可設定的警示與顯示面板。他們會持續評估效能與延展性風險,並降低您對手動檢查清單的依賴。客戶 Trust 和認知是每個業務的關鍵。就業務影響而言,與客戶相關的問題風險通常會高於與未相關的問題相關的風險。客戶可能不會以與內部小組相同的方式思考或看見風險。如果客戶無法登入其帳戶,他們可能不關心問題的根本原因。他們最關心的是自己的立即體驗。
• 排定風險的優先順序。理想情況下,每個風險都會連結至可靠的緩解風險和回應計畫。事實上,您會在一段時間內遇到需要解決的間隙。採用「提前提供價值並重複」方法十分重要。您與您的運送與維護小組在指定的時間只能承擔足夠的工作。在 Salesforce 中,常見的運算式為「如果一切都重要,則沒有什麼都重要」。我們使用 V2MOM 來排定整個公司的工作優先順序,並將其與整個小組及每個人保持一致。(您可以在 Trailhead 上深入瞭解 V2MOM。)使用您的風險評估,讓您有機會與專案關係人合作排定優先順序並致力於最重要的風險管理工作。使用規模測試 - 測試計畫建立來識別要排定優先順序的風險,並使用規模測試降低這些風險。

使用 Proactive Monitoring 偵測早期可用性風險。它會呈現如 API 要求限制高峰、列鎖定錯誤或同時 Apex 失敗等異常,在問題升級為服務中斷之前提供可採取動作的洞察。

可用性模式和反模式顯示 Salesforce 解決方案內的正確和不良風險管理。在建立之前,使用模式驗證您的設計,或識別系統中的重新產生區域。

若要深入瞭解與風險管理相關的 Salesforce 工具,請參閱可靠性的 Salesforce 工具。

失敗點是讓系統不可靠的漏洞。成功的失敗緩解不是要找出每個潛在失敗點。而是要快速分類和排定失敗點的優先順序,以便維護和支援小組有效回應。請參閱 事件回應。

若要開發更好的失敗緩解策略:

• 根據人員、程序和技術分類失敗點的觸發。就像您在人員、流程和技術方面將風險分類一樣,請將相同的想法套用至觸發高優先順序失敗點的方式。此方法可協助您識別潛在失敗觸發,並針對其開發和組織回應。有時,您可以根據觸發分類的方式,使用類似的緩解方法來緩解看似不同的失敗觸發。

• 識別基本、中型和成熟緩解方式的外觀。建立緩解策略需要時間。定義緩解的層級,以協助您與您的小組瞭解您可以立即在何處進行控制,以及如何在一段時間內專注於工作。一律盡快尋找機會以在您的緩解措施中使用自動化。為了說明此方法在實際上呈現的外觀,此範例顯示以人員為導向的觸發,以及基本、中介和成熟層級以原則為基礎的緩解方式呈現的外觀。

除了使用結構手冊和持續性規劃外,還可使用 Proactive Monitoring。透過 Proactive Monitoring,您可以設定失敗觸發的即時警示,例如登入失敗、CPU 逾時例外或同時 API 要求錯誤。此警示方法可透過確保技術和業務專案關係人及時得到通知,以減少失敗的影響,來加強失敗緩解。

可用性的 模式和反模式會顯示 Salesforce 解決方案中的正確和不良失敗緩解方式。使用這些權限來在您建立之前驗證您的設計,或識別系統中要重新產生的位置。

若要深入瞭解失敗緩解的 Salesforce 工具,請參閱與可靠相關的 工具。

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

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

系統結構效能是測量系統處理的量 (輸出) 以及回應的速度 (延遲)。您通常會透過生產測試和監視來瞭解系統的效能。

效能高的系統會在每個預期的需求層級及時完成程序。

效能不佳會隨著延遲較高和輸送量較低,進而導致生產力降低並增加使用者挫折。修正績效問題十分緊急,因為這些問題會導致客戶失去 Trust 和財務損失。

您可以透過最佳化輸送量和延遲來改善解決方案的效能。

注意:輸出量和延遲最佳化是改善系統處理和回應性的必要層面。不過,請務必記住,整體系統效能也取決於您對規模的結構效果。您必須在設計中考量這兩個維度。

在 Salesforce 結構中,輸送量是指系統在指定時間間隔內可完成的同時要求數。針對輸送量設計並最佳化的客戶 Salesforce 解決方案在 Salesforce Platform 的內建管理員限制內運作較佳。

最佳化 Salesforce 中的輸出量從準確計算系統中的工作量並規劃其成長開始。若未針對系統所產生需求精確預測,您就無法透過系統的輸送量功能找出潛在問題。

當思考工作量時,請考量以下三個維度。

• 系統在指定時間內必須處理的交易數量
• 必須同時存取系統的 使用者人數
• 系統中交易邏輯的整體複雜 度

當考量效能時,小組有時會過於專注於運算,以及 CPU 時間上限的限制,這是平台管理員限制之一。專注於 CPU 時間的小組會忽略最佳化輸送量的其他方法。展開焦點並套用這些方法可改善 Salesforce 結構的整體輸送量和效率。這些改善將有助於減少延遲並提升整體系統效能。ApexGuru 會主動偵測輸送量限制的反模式,例如迴圈中的 SOQL、迴圈中的 DML、效率不佳的 GGD 呼叫和昂貴的方法。這些洞察可協助小組去除可限制輸送量的管理員限制風險。

若要最佳化系統中的輸送量:

• 偏好非同步處理。Salesforce Platform 使用交易內容來控制資料完整性和限制逸出程式碼。請參閱「結構基本概念」中的「結構基本概念」中的「交易」。因此,盡可能使用非同步 (非同步) 處理有助於儘量減少同步執行內容中的潛在瓶頸。請參閱 資料處理。使用非同步運算並非每種效能問題的修復方法,且在整合非同步流程時,您必須考量延遲。某些平台功能 (例如可排列的 Apex) 可能會在流量高峰期間增加延遲,因為這些功能會造成訊息等候時間較長。視您的使用個案而定,您可以決定容忍回應性可能降低,以維持或改善輸送量。在其他情況下,您可能會決定無法接受延遲增加。透過規模測試,您可以透過在完整 Sandbox 中模擬流量高峰來驗證這些權衡。在其中,您可以測量工作如何影響輸送量和延遲。
• 一律使用大量處理。在高層級上,大量處理表示針對集合執行作業。通常,討論 Salesforce 解決方案大量處理的小組會專注於針對集合簡化資料作業。請參閱 作業邏輯。不過,系統層級的大量處理不僅僅涉及資料作業。也請將某些工作 (例如呼叫或複雜計算) 視為大量處理的候選項目。適當大量處理可減少額外負擔。它會透過一個要求執行多個作業,而非透過每個作業執行一個要求。ApexGuru 會呈現如 DML 或 SOQL 之類的防大量處理模式,您可以在調整為生產環境之前修正這些模式。請參閱 大量作業。
• 使用 SOSL 進行搜尋,並將 SOQL 視為資料作業。使用過於複雜的 SOQL 陳述式可能會顯而易見,這會增加系統所需的時間,以提取記錄。SOQL 會對基本關聯式資料庫增加負擔,使處理速度變慢。使用文字或萬用字元條件時,SOSL 的效能較高。SOSL 使用平台的搜尋引擎,其已針對全文索引和通用搜尋最佳化。若要最佳化記錄提取模式,請確定您的設計標準指定何時使用 SOSL 在系統中尋找資料。也請確保它們指定如何使用 SOQL 以有效率地進行資料作業。請參閱 作業邏輯)。
• 使用平台快取和 ApexGuru。快取 Salesforce 工作階段與組織資料時,Lightning 平台快取層級提供更快的效能與更佳的可靠性。「平台快取」透過散佈快取空間來改善效能,讓某些應用程式或作業不會竊取其他應用程式的容量。ApexGuru 會偵測錯過的機會來快取重複的查詢 (例如,SOQL 結果的平台快取),進而改善大規模環境中的輸送量。

效能的 模式和反模式會顯示 Salesforce 組織中正確與不良的輸送量。使用這些選項可在您建立之前驗證您的設計,或識別進一步最佳化的機會。

若要深入瞭解 Salesforce 用於輸出最佳化的工具,請參閱可靠性的 Salesforce 工具。

延遲是指系統完成執行路徑的速度。最佳化系統的輸送量有助於改善延遲。延遲的另一個維度是認知的效能,或系統對使用者有何回應。

人員不想要等待頁面載入或程序完成。如果系統的使用者在嘗試瀏覽清單檢視、記錄頁面、報告等時經常遇到較長的載入時間,則會感到沮喪。發生此情況時,客戶或合作夥伴可能會決定將業務移至其他位置,而非處理效能不佳的系統。在內部,員工可以建立因應措施來避免依預期使用系統,這會造成安全性和資料完整性的下游問題。

認知的效能可能難以診斷。當使用者報告效能變慢時,支援小組可能無法重現問題。延遲增加通常是相互依據的較小問題組合所造成,這會導致難以診斷所認知效能問題的確切原因。

若要減少 Salesforce 系統中的延遲並改善回應性:

• 最佳化報告。確保每個報告皆提供單一特定用途。清楚識別系統中每個報告的受眾和用途。在報告中,僅包含受眾成員進行決策所需的資料量下限。移除不符合報告用途的資料欄,可減少所需的資料量,藉此改善報告效能。
• 最佳化篩選條件。有效的篩選條件可透過精確地定義從資料庫採取的列數範圍,來加速報告和清單檢視效能。一般而言,您設定篩選邏輯越具體,資料的基本查詢就越有效率。最佳化篩選的方法包括:
  • 使用「等於」和「不等於」,而非使用「包含」和「不包含」
  • 避免依公式欄位篩選
• 簡化您的共用模式。過於複雜的共用模式會使各種流程變慢,因為系統必須檢查共用與可視性模式,以判斷使用者是否可存取要顯示或處理的資料。複雜的共用計算會增加在使用者環境中執行的報告、清單檢視和自動化延遲。請參閱「共用與可視性」。
• 最佳化自訂 UI 元件。自訂建立的使用者介面 (UI) 元件可增加延遲。若要最佳化自訂 UI 元件的效能,請考慮執行下列動作。
  • 使用 Lightning Web 元件 (LWC)。LWC 架構與現代 Web 標準密切一致。在 LWC 中撰寫的自訂元件在網頁瀏覽器中更有效率地呈現,並讓開發人員能夠使用更具效能的 JavaScript 方法。務必使用 LWC,而非舊版 UI 技術,例如 Aura 或 Visualforce。
  • 使用 Lightning Data Service。Lightning Data Service 處理在元件之間建立及維護安全、高效且共用的快取。使用它可避免不必要的來回行程到伺服器取得資料,並提高整體應用程式回應性。
  • 針對清單資料使用用戶端排序和篩選。針對 LWC (偏好) 和 Aura 元件 (否則),開發人員可以使用標準 JavaScript 陣列功能來排序、篩選和選取用戶端的值,進而減少伺服器所需的行程數目。

模式和反模式顯示 Salesforce 組織中正確和不良延遲的外觀。使用這些選項可在您建立之前驗證您的設計,或識別進一步最佳化的機會。

若要深入瞭解 Salesforce 工具以最佳化延遲,請參閱可靠性的 Salesforce 工具。

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

✨ 在「模式與反模式探索器」中探索更多效能模式。

延展性是指系統在演進與成長時能一致執行的能力。可調整的系統可處理交易量大幅增加或同時存取,而不會造成基本變更。Salesforce 的平台服務專為支援應用程式擴充性而設計。請參閱 內部平台處理。不過,隨著您的組織成長,以及對您產品和服務的需求增加,您必須負責建立能夠有效執行且如預期般執行的系統。從一開始針對延展性進行結構設計,會隨著使用者流量增加而加快新功能的傳遞速度,並減少服務中斷。在設計階段早期,在將新功能部署至生產環境前,請使用「**規模測試」**來模擬預測的工作量,並驗證結構可以調整以支援工作量。

並非針對延展性設計的系統需要不斷且高成本的疑難排解、重新設計和重新設定。延展性會隨著時間產生複雜性,使整個系統的效能降低。在某些情況下,企業會發現大多數的開發和維護資源都花在解決延展性問題上,而不是在建立價值的新功能上。

有時候,公司會達到重要關鍵點。其系統的原始設計無法支援業務成長,而非預期的事件會使系統變得不穩定。使用來自 Scale Center 的洞察來提早識別延展性關鍵點。「規模中心」會呈現例外熱點、經過長時間的交易,以及隨著時間變得愈來愈嚴重的貨架瓶頸。

您可以專注於資料模型最佳化和資料量管理,進一步建立規模結構。

注意:雖然此處未討論,但測試延展性是驗證應用程式結構的重要部分。如需指引,請參閱 測試策略。

資料建模涉及建構您組織中的物件,並以讓您的使用者和自動化流程能夠盡快提取所需資料的方式彼此建立物件的關聯。採取步驟來改善輸送量可解決許多效能問題,但如果沒有最佳化的資料模型,您的努力將不會如此有效。

設計不良的資料模型的負面影響並非立即明顯;系統在資料量、程序、使用者和整合方面成長時,系統會發現其劣勢。設計良好的資料模型可讓您隨著新增和擴充需求,輕鬆持續重新設定應用程式。ApexGuru 會呈現資料存取防模式,例如非選擇性 SOQL、未使用的欄位,以及直接影響資料模型的延展性結構描述效率不佳。

若要最佳化您的資料模型:

• 使用 Salesforce 的預先建立資料模型。Salesforce 提供銷售、服務和各種產業垂直的預先建立資料模型。使用 Salesforce 提供的資料模型可確保系統中的功能僅定義一次,進而消除冗餘與孤立狀況,並在整個系統建立單一事實來源。由於您針對該單一來源使用 Salesforce 預先建立的資料模型,因此透過分析更容易瞭解應用程式資料,並使用 Salesforce 的預先建立人工智慧服務。此外,減少您必須支援的自訂項目可降低維護成本並降低技術債務。
• 選擇正確的資料類型。瞭解 Salesforce 支援的不同類型欄位及其限制。考量報告和加密需求,以避免未來需要在類型之間轉換資料。
• 選擇正確的關係。Salesforce 支援兩種物件之間的關係:主要 - 詳細資料與對應。「主要 - 詳細資料」關係提供兩個主要優點。一種是內建的累計摘要功能,其會計算和彙總子系記錄的詳細資料。另一個功能是內建的串聯刪除功能,藉此刪除父系記錄也會刪除其子系記錄。但是,在決定使用「主要 - 詳細資料」關係之前,請確保您瞭解共用和資料誤差的涵義。
• **反正規化以進行刻度。**正規化是建構資料模型的流程,以減少資料冗餘並改善資料完整性。很遺憾,正規化有時會造成規模問題。反正規化表格在規模上表現較佳,但請記得考量資料完整性和冗餘性。

模式和反模式顯示 Salesforce 組織中正確與不良資料模型最佳化的外觀。使用這些選項可在您建立之前驗證您的設計,或識別進一步最佳化的機會。

若要深入瞭解資料模型最佳化的 Salesforce 工具,請參閱可靠性的 Salesforce 工具。

資料量是根據記錄計數與大小來測量儲存在系統中的資料量。如果您的組織有數十萬名使用者、數千萬筆記錄,或數百 GB 的記錄儲存空間,則表示您有大量資料。您組織中資料量與物件之間的關係會影響延展性,且對延展性可能會造成比單獨記錄數量更大的影響。

若要改善具有大量資料組織的延展性:

• 散佈子系記錄。透過確保沒有父系有大量子系記錄,以避免父系子系資料偏差。一般建議,任何父系都不應有超過 10,000 個子系記錄。例如,在擁有許多連絡人但未使用帳戶的部署中,請考慮設定數個帳戶記錄並在其中散佈相關連絡人記錄。
• 散佈記錄的擁有權。若要避免擁有權偏差,請確保沒有任何單一使用者或排行榜擁有,也不確保單一角色或公用群組的所有成員擁有同一個物件中超過 10,000 筆記錄。「使用 dummy 使用者」的「停車」資料通常會導致擁有權偏差。如果您遇到此問題,請注意其對 共用計算的影響。如果您無法重新散佈記錄以減輕擁有權偏差,請避免將資料擁有者指派給角色。如果您組織的共用模式需要角色指派,請將資料擁有者以不同的角色放置在共用階層的頂端。請勿允許該使用者角色的頻繁或非預期的變更,因為任何變更都會因為共用重新計算而造成顯著的效能影響。將該使用者保持在可在任何共用規則中參照的公用群組之外。
• 減少 Salesforce 中的記錄資料量。Salesforce 的設計目的為提供公司客戶的單一檢視。限制 Salesforce 中的資料是最佳作法,可能會看起來反直覺。不過,單一檢視的強大功效在於讓業務使用者瞭解並對客戶資料採取行動。隨著資料量增加,與日常流程或分析無關的資料會造成數個問題。這些問題包括應用程式效能降低、資料安全性增加的風險,以及對搜尋、報告和分析的負面影響。若要避免此類問題,請針對資料模型中的每個物件定義資料生命週期,其中包含資料的時間表和分類 (隨著資料的過時與失去立即業務價值)。根據資料生命週期,實作這些程序來隨時間管理資料。
  • 資料歸檔與清除-若要盡可能將資料量保持在最低的狀態,請移除業務不需要的記錄,以協助將資料量保持在最低的狀態。使用大量 API 2.0 的實刪除功能來刪除大量資料。
  • 資料彙總 - 以與報告相容的格式建立彙總自訂物件,以摘要主要歷程記錄趨勢或摘要資料。使用 批次 Apex 填入自訂物件。然後,使用者可以根據彙總的物件記錄執行報告。
  • 資料層級。如果 Salesforce 報告或日常工作不需要大型資料集,請在不同的應用程式中維護該資料集。視需要透過 mashup、呼叫或外部物件在 Salesforce 中提供資料。

在實際上,您可能無法在發生問題時立即解決延展性問題的根本原因。因此,Salesforce 提供可協助減輕立即痛點的選項。請務必瞭解,在您的組織中啟用這些功能並非處理大量資料的可行長期結構策略。這些短期停機因應措施可協助降低受資料結構不良影響的系統延遲,但也可為您的組織增加技術負債。

規模問題的短期因應措施包括:

• 「自訂索引」索引會儲存在平台的查詢最佳化程式用來加速資料存取作業的特殊內部表格中。請參閱 多租戶索引)。平台依預設會自動索引特定類型的欄位。若要加速效能不佳的查詢,您可以連絡 Salesforce 客戶支援,以要求額外的自訂索引。使用「查詢計畫」工具判斷自訂索引是否可改善查詢的效能。
• ** Skinny 表格**。如果您需要進一步最佳化對超過 1 百萬筆記錄物件上常見欄位集的查詢,則精簡表格可提供協助。精簡表格可免除在報告或自動化中使用來自相同物件的自訂和標準欄位時發生的背景聯結。若要使用精簡表格,Salesforce 客戶支援必須為您的組織啟用這些表格。

延展性的模式和反模式顯示 Salesforce 組織中正確與不良資料量管理的外觀。使用這些選項可在您建立之前驗證您的設計,或識別進一步最佳化的機會。

若要深入瞭解用於管理資料量的 Salesforce 工具,請參閱可靠性的 Salesforce 工具。

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

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

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