# architect 結構良好 (well-architected) - Full Documentation > [在此](/docs/architect/zh-tw/well-architected/guide/contributors)閱讀我們的更新排程。 ## 簡介 「受**信任」**的 Salesforce 解決方案可保護企業和利害關係人。針對「**信任」**而設計良好的解決方案安全、合規且可靠。 **安全**解決方案可控制存取並保護資料。
**符合**法律與道德指導方針的解決方案。
**可靠**的解決方案可有效率且可靠地運作。
建立「**信任的**」解決方案需要謹慎規劃。您需要瞭解解決方案提供的業務和/或行業內容。業務的整體風險容忍度為何?什麼類型的資料會進入和移出系統?Salesforce 會以專門的安全性、合規性或道德考量事項,作為記錄或資料儲存點的系統使用嗎?相關的法規與規範標準為何?是否有額外的公司特定標準?Salesforce 是否為業務關鍵系統?您是否需要考慮流量或系統用量的季節性或情況性高峰? 若要找到「**信任的**」解決方案,您必須與整個業務的利害關係人合作。您必須清楚檢視需要存取解決方案的使用者和系統類型,以及完成工作所需的資料和權限。您需要瞭解法律與行業需求,以及內部原則與標準。您需要與開發和維護小組合作,以確保功能可供存取,並公平地為使用者提供服務。即使發生中斷或快速成長,您仍需要計畫解決方案的可用性和效能。針對結構正確的解決方案,沒有什麼比「**信任」更為重要**。 下列幾節提供更多關於「**信任」**解決方案結構核心考量事項的深入指引。 ## 信任的概觀
安全
安全系統可保護業務、利害關係人和資料。安全結構可確保只有經過批准的使用者才能取得存取權、限制使用者對完成工作所需項目的存取權,並保護系統中的資料免受入侵。
組織安全性 工作階段安全性 資料安全性
驗證
授權
工作階段管理
裝置存取權
威脅偵測和回應
共用與可視性
加密的使用
符合
符合的解決方案遵循法律與道德指導方針。合規性結構遵循法律法規和產業標準、遵守道德原則,並公平地為所有使用者提供服務。
法律符合度 道德標準 無障礙
資料隱私權
本地化
公司原則
人工智慧
資料項目
瀏覽
可靠
可靠的解決方案可在各種條件下有效率且可靠地運作。可靠的結構在使用者期望的時間和地點可供使用、一致執行,並與業務一起調整規模。
可用性 效能 延展性
風險管理
失敗緩解
輸出
延遲性
資料建模
資料量
> [在此](/docs/architect/zh-tw/well-architected/guide/contributors)閱讀我們的更新排程。 ## 簡介 系統可透過讓使用者輕鬆存取和使用應用程式,讓使用者感到自己完成了更高品質的工作,並讓使用者想要在系統中使用應用程式,來示範吸引人的行為。 提供吸引人的行為對業務很重要,因為它直接與使用者採用以及整體工作人員和客戶滿意度相關聯。參與行為也有助於減少支援要求,並有助於提高使用者的功能要求品質。 建立吸引行為的其中一個挑戰是難以單獨透過目標度量來測量。而是由使用者的主觀體驗所衡量;使用者認為參與應用程式提供真正的價值。參與應用程式可供 [存取](/docs/architect/zh-tw/well-architected/guide/compliant#無障礙)、非滲透且易於瞭解。他們需要最少數量的上線和訓練。他們會使用明確的方法來主動防止使用者發生錯誤。 另一個挑戰是參與目標通常會隨著您系統中不同類型的使用者互動而有所不同。例如,您可以針對管理個案的內部使用者有一組目標,針對透過網站表單提交資訊的外部使用者有一組目標。若要設計吸引人的系統,您必須仔細考量您嘗試建立的參與類型,以及使用者想要參與的原因,再開始組合功能和頁面。 與使用者體驗 (UX) 設計師合作,可協助您在提供吸引人的應用程式時做出更有效的決策。從結構角度來看,使用者採用與保留是健康系統的重要元件。參與結構可降低使用者快速完成程序或略過步驟,以避免在不喜歡使用的系統中花費時間所導致的資料品質問題的可能性。針對對外開放的系統,引人注目的結構可以增加收入和客戶保留,因為發現系統更容易使用的客戶會選擇與您的組織進行更多業務往來。 您可以透過專注於提供簡化且實用的體驗,來建立更具吸引力的應用程式。 ## 已簡化 簡化的應用程式易於瀏覽、清楚呈現資訊和資料輸入工作,並調整以符合各種尺寸規格。簡化的應用程式也具有使用者已在其他常用應用程式中習慣的體驗模式。例如,大多數的網頁瀏覽器會在使用者以滑鼠右鍵按一下連結時,將「在新索引標籤中開啟」顯示為首選項。包含索引標籤的簡化應用程式會遵循相同的模式。 應用程式體驗效率不佳的影響可能遠遠超出個別應用程式。應用程式體驗不佳會破壞使用者的 Trust。隨著更多類型的業務關鍵應用程式和面向客戶的應用程式移至數位管道,這可能會讓公司失去關鍵利害關係人的忠誠度。 您可以更有意圖地處理應用程式複雜性、尺寸設計和尺寸規格,藉此更簡化您的應用程式。 ### 應用程式複雜性 將應用程式複雜性降到最低表示使用者只會看見相關功能表項目、索引標籤和瀏覽控制項。您必須在使用者群組、使用者權限和正確的應用程式體驗之間建立對應。使用這些對應以瞭解要向指定使用者呈現的應用程式體驗,然後確保您的應用程式具有提供該體驗所需的邏輯控制項。 呈現使用者過於複雜的應用程式會造成各種不良體驗: - 使用者經常會看見不必要或不相關的索引標籤、瀏覽至空白畫面,以及遇到停用或封鎖的連結。 - 如「如果您的角色為 X,請忽略此索引標籤」等不必要或不實用的指示會顯示在訓練和啟用資料中。 - 混亂的瀏覽功能表會迫使使用者花費額外的時間尋找完成工作所需的項目。 這些不良體驗會導致低的採用率和滿意度。 決定正確的應用程式複雜度層級時,請考量下列事項: - 根據使用者需要執行的工作優先順序,組織功能表、索引標籤和其他瀏覽控制項。 - 避免導入使用者必須僅學習才能使用您應用程式的新行為。 - 請勿移除可讓使用者自訂其使用者介面層面的功能存取權。 - 使用權限集提供展開或減少的瀏覽選項。 - 簡化 Lightning 頁面啟用 [指派](https://help.salesforce.com/s/articleView?id=sf.lightning_page_getting_into_salesforce1.htm)。最小化每個應用程式啟用中的 Lightning 頁數。使用動態表單、權限集和條件化呈現,將項目新增至應用程式中的 Lightning 頁面。請進行此操作,而非維護多個 Lightning 頁面 (由設定檔啟用和指派)。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/engaging#簡化應用程式模式和反模式)清單顯示 Salesforce 組織中應用程式複雜性管理的適當 (和不良) 外觀。您可以使用這些項目來驗證或改善應用程式設計。 若要深入瞭解可協助您管理應用程式複雜性的 Salesforce 工具,請參閱與參與相關的 [工具](/docs/architect/zh-tw/well-architected/guide/engaging#與參與相關的工具)。 ### 表單 簡化表單可將資訊組織為邏輯序列、支援快速資料輸入,並將必要步驟最小化。它們也允許使用 [有用的](/docs/architect/zh-tw/well-architected/guide/engaging#實用)用戶端資料驗證訊息,並避免重複的表單提交週期。 設計表單時,請考量下列事項: - **將相關欄位分組在一起**。與流程或資料項目工作中相同步驟相關的群組欄位。去除與現有工作不直接相關的欄位。 - **提早進行資料輸入和驗證**。需要使用者輸入資料的欄位應提前顯示在表單上。最佳作法是盡快在欄位層級呈現資料格式化或遺漏資料的問題 (亦即在使用者嘗試瀏覽至下一個步驟或提交表單之前)。此外,請避免在使用者有機會將資料輸入欄位之前顯示欄位級錯誤。 - **最小化資料輸入工作**。盡可能預先填入或自動填寫盡可能多的欄位,以儘量減少資料輸入錯誤並提升效率。僅要求使用者輸入重要或重要資料。去除與現有業務流程無關的任何資料輸入。盡可能使用選項清單,而非任意格式的文字欄位,以強制選取有效選項並減少相同回答的變化。 - **將提交至伺服器最小化**。請勿讓多步驟表單多次將資料提交至伺服器。確保所有自訂 [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.apex_result_caching) 或 [Aura](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_storable_actions.htm) 元件都使用用戶端快取來處理瀏覽或分頁動作。(Salesforce Lightning Experience 和 Salesforce 行動應用程式預設使用用戶端快取。)設計表單,讓使用者僅將資料提交至伺服器一次。提交表單前,在用戶端驗證使用者輸入。這可儘量減少非預期的使用者提交、防止重複或雜亂的交易在後端耗用頻寬,並協助您針對更好的 [資料處理進行](/docs/architect/zh-tw/well-architected/guide/automated#資料處理)設計。 - **管理表單狀態**。用戶端快取不僅有助於如瀏覽和分頁等行為,還有助於儘量減少連線問題造成的資料遺失。有效管理狀態也意味著應用程式可以適當協調資料提交至伺服器,並防止重複交易,並根據伺服器端動作的狀態向使用者顯示相關且及時的訊息。簡化表單只會提交資料作業一次,且不需要使用者等待在伺服器上長時間執行作業完成。 - **遵循無障礙標準**。若要將應用程式的受眾最大化,並協助確保其能包含所有客戶,請在表單設計中強制執行[無障礙功能](/docs/architect/zh-tw/well-architected/guide/compliant#無障礙)標準。 簡化表單有助於提高應用程式中的[資料完整性](/docs/architect/zh-tw/well-architected/guide/automated#資料完整性),以及應用程式對使用者有何[幫助](/docs/architect/zh-tw/well-architected/guide/engaging#實用)。他們也可以減少支援票證和要求,因為使用者能夠更完善地解決錯誤,並清楚瞭解其表單提交的狀態。此外,簡化表單可讓使用者快速且有效地輸入資料,並確保使用者無須等待執行較長的程序完成以執行進一步工作。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/engaging#簡化應用程式模式和反模式)清單顯示 Salesforce 組織中正確 (和不良) 的表單設計外觀。您可以使用這些項目來驗證或改善表單設計。 若要深入瞭解可協助您建立更簡化的表單的 Salesforce 工具,請參閱參與相關的 [工具](/docs/architect/zh-tw/well-architected/guide/engaging#與參與相關的工具)。如需為使用個案選擇正確表單工具的更具體指引,請參閱使用 Salesforce 建立表單的 [結構設計師決策指南](/docs/architect/zh-tw/decision-guides/guide/build-forms#重要道具)。 ### 尺寸規格 參與應用程式適應不同的裝置和互動類型或尺寸規格。根據裝置類型,不同類型的使用者互動會更容易 (或更難),表單和欄位的可讀性也會改變。請記住,除了畫面尺寸之外,尺寸規格也會參照使用者與畫面互動的方式。裝置數量越來越多,現在有觸控螢幕,而某些使用者也可能使用特殊裝置來進行[無障礙](/docs/architect/zh-tw/well-architected/guide/compliant#無障礙)操作。設計表單時,請務必考量下列因素。 無法考慮尺寸規格變化會導致各種問題,包括: - 資料品質不佳 - 無法使用的應用程式介面 - 支援工作人員的更多疑難排解或「代表訂購」工作階段 - 使用者採用不佳、作用中使用者數量少,且應用程式「捨棄」率高 若要針對 Salesforce 應用程式中尺寸規格之間的互通性設計,請考量下列事項: - **識別每個應用程式**支援的尺寸規格。 - **識別輸入方法和使用者的無障礙需求**。請參閱「[無障礙」,](/docs/architect/zh-tw/well-architected/guide/compliant#無障礙)以取得詳細資訊。 - **盡可能使用 [標準功能](/docs/architect/zh-tw/well-architected/guide/intentional#標準與自訂功能),在裝置之間提供自適應體驗**。 - 依預設,Salesforce 提供的 [Lightning 頁面範本](https://help.salesforce.com/s/articleView?id=sf.lightning_page_templates.htm&type=5)支援不同的尺寸規格。如果您選擇使用 Aura 開發自訂 Lightning 頁面範本,則開發人員必須將尺寸規格資訊納入元件設計檔案。 - Salesforce 提供的 [標準頁面元件](https://help.salesforce.com/s/articleView?id=sf.lightning_page_components.htm&type=5)會為您處理跨支援尺寸規格的呈現。如果您使用 LWC 或 Aura 建立自訂元件,開發人員將需要處理寬度認知 ([Aura](https://developer.salesforce.com/docs/atlas.en-us.238.0.lightning.meta/lightning/components_config_for_app_builder_width_aware.htm?q=width) 和 [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_width_aware) 之間有實作差異),並宣告其元件的設計檔案中支援尺寸規格。 - **遵循指引以在所有裝置上使用簡化[表單](/docs/architect/zh-tw/well-architected/guide/engaging#表單)**。 - **針對關鍵尺寸規格建立測試計畫 (以及良好的測試)**。理想情況下,您會針對所有應用程式測試所有裝置和尺寸規格。然而,針對尺寸規格測試設定正確的裝置 (或裝置模擬器) 可能是一項重大投資。如果您知道某個應用程式或一組應用程式將在行動裝置或平板電腦上擁有大量使用者,請在行動裝置和平板電腦尺寸規格上為這些應用程式排定準確測試的優先順序。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/engaging#簡化應用程式模式和反模式)清單顯示 Salesforce 組織中正確 (與不良) 尺寸的認知。您可以在建立之前使用這些頁面來驗證您的設計,或識別需要重新設計的頁面。 若要深入瞭解有效尺寸規格設計的 Salesforce 工具,請參閱參與相關的 [工具](/docs/architect/zh-tw/well-architected/guide/engaging#與參與相關的工具)。 ### 簡化應用程式模式和反模式 下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/easy-streamlined)探索更多簡化應用程式的模式。
模式 防模式
應用程式複雜性 在您的組織中:
- 應用程式在管理員提供的預設組態中有少於 10 個索引標籤
- 沒有任何應用程式的「停用此應用程式中瀏覽項目的一般使用者個人化」設定為 true
在您的組織中:
- 應用程式在管理員提供的預設組態中常有 10 個以上的索引標籤
- 許多應用程式的「停用此應用程式中使用者瀏覽項目的個人化」設定為 true,或在組織範圍內停用自訂瀏覽項目的權限
表單 在您的應用程式中:
- 欄位會遵循邏輯分組
- 資料輸入欄位會一起顯示,以五個或更少的群組顯示
- 在使用者離開或提交資料前,資料輸入錯誤會明確且顯示在欄位層級
- 分頁控制會啟用步驟之間的移動
- 資料提交發生一次
- 動作和瀏覽的標籤清楚
- 提供及時且視覺化的回饋意見以確認使用者動作,例如按一下按鈕
- 瀏覽按鈕 (例如「前往」、「下一步」和「返回」) 會一致地放置在整個 UI 中
在您的應用程式中:
- 未依邏輯將資料輸入欄位分組,因此使用者填寫表單需要大量內容切換
- 資料輸入錯誤包含僅能由瞭解系統內部運作的人員解譯的密碼資訊
- 只有在按一下表單的提交按鈕時,才會顯示資料輸入錯誤
- 未清楚定義步驟和分組,導致難以瀏覽
- 在整個資料輸入流程中多次發生資料提交
- 動作與瀏覽的標籤會讓不熟悉基本系統功能的使用者感到困惑
- 未提供使用者動作的視覺確認
- 瀏覽按鈕會顯示在整個 UI 中的任意位置
在您的表單邏輯中:
- 欄位會盡可能預先填入或自動完成
- 使用者不需要等待長時間執行的伺服器端動作完成
- 自訂元件針對不涉及資料作業的伺服器型動作使用 cacheable=true
- 資料作業執行一次
- 在 LWC @wire 轉接器中,處理所有不涉及資料作業的動作
在您的表單邏輯中:
- 可預先填入或自動完成的欄位需要手動輸入
- 使用者必須在提交流程期間停止工作,才能等待伺服器端動作完成
- 自訂元件集 cacheable=false
尺寸規格 在您的組織中:
- Salesforce 提供的 Lightning 頁面範本會用於所有或大多數的頁面
- 在 Aura 元件設計檔案中,自訂 Lightning 頁面範本使用 design:supportedFormFactors 和 design:supportedFormFactor
- 在應用程式產生器中提供的自訂 LWC 或 Aura 元件會在各自的設計檔案中宣告支援的尺寸規格,並實作感知寬度的樣式模式
在您的組織中:
- Classic 仍啟用
- 自訂 Lightning 頁面範本在 Aura 元件設計檔案中未統一使用 design:supportedFormFactors 和 design:supportedFormFactor
- 在應用程式產生器中提供的自訂 LWC 或 Aura 元件不會一致在各自的設計檔案中宣告支援的尺寸規格
- 在自訂 LWC 或 Aura 元件中,Salesforce 提供的介面不會實作寬度認知樣式
- 在自訂 LWC 或 Aura 元件中,不同尺寸的樣式完全由硬式編碼的 CSS px 或 % 值所驅動
桌面版:
- 資料輸入欄位和瀏覽控制項適合畫面,且可以依預期與其互動
- 記錄和應用程式頁面會根據頁面啟用指派規則正確顯示
桌面版:
- 資料輸入欄位和瀏覽控制項不會顯示在畫面上的預期位置
- 與資料輸入欄位和瀏覽控制項的互動不符合必要行為
- 缺少頁面啟用指派規則表示所有使用者都會看見相同的記錄和應用程式頁面
在行動裝置與平板電腦上:
- 資料輸入與瀏覽控制會正確顯示
- 使用者可以輕鬆地輸入資料
- 顯示針對較小的尺寸規格最佳化的行動瀏覽功能表
- 精簡版面配置會顯示在記錄層級
在行動裝置與平板電腦上:
- 資料輸入與瀏覽控制不會一致或正確地呈現
- 使用者無法輕鬆輸入資料
- 行動瀏覽功能表與桌面瀏覽不同
- 未在記錄層級設定精簡版面配置
## 實用 實用的應用程式可讓使用者感到更有能力且更有效,並減少分心或中斷。 實用的應用程式可協助維護 [資料完整性,](/docs/architect/zh-tw/well-architected/guide/automated#資料完整性)方法是減輕手動錯誤的發生,並在使用者需要時提供回饋意見。它們可協助使用者瞭解他們現在和下次需要專注的動作,並提供相關資訊以協助使用者更快解決自己的問題。它們可提供使用者動作與有意義影響或成就之間的明確連結。 您可以使用三個關鍵習慣建立更實用的應用程式:通知與訊息、應用程式內導覽,以及認可與獎勵。 ### 通知與訊息 通知與訊息可協助使用者掌握狀況。 設計良好的通知和傳訊系統可提供使用者及時做出重要決策所需的資訊,藉此提升參與度和生產力。設計不良的通知和傳訊系統 (呈現無關且不及時的訊息) 會產生相反的效果。內部使用者會快速停用或忽略通知,導致他們忽略可能影響重要業務流程的合法訊息。客戶或其他外部使用者很厭倦無意義的通知,可能會決定一併停止使用您的系統。 決定應用程式如何處理傳送通知和訊息給使用者時,請考量下列事項: - **針對錯誤,請使用通知和訊息作為最後手段**。使用後端處理設計系統中的 [錯誤處理](/docs/architect/zh-tw/well-architected/guide/automated#錯誤處理),此處理可在沒有人力介入的情況下修正特定類型的錯誤。僅傳送關於無法完成工作之重大錯誤的訊息給使用者。同樣地,當業務使用者可以 (且需要) 自行採取一些糾正動作時,只會傳送錯誤訊息。其他錯誤訊息或詳細資料可透過報告提供,並/或使用非同步方法傳送給技術支援人員以進一步追蹤。 - **根據相關性、緊急性和時機性選擇訊息類型**。不同類型的訊息具有不同的封鎖或中斷行為層級。通知是訊息的「封鎖」類型,因為它們需要使用者在能夠繼續工作之前予以確認。與錯誤訊息一樣,應謹慎使用通知。快顯通知是[非封鎖](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_toast)的,可有不同的持續性行為,並支援不同類型的訊息使用個案。最不明顯的訊息是[應用程式內通知](https://help.salesforce.com/s/articleView?id=sf.notif_builder.htm&type=5)或電子郵件。這些最適合用於提供使用者可在其選擇時處理的資訊。 - **考量接下來需要發生的狀況**。雖然某些通知具有資訊性 (例如成功訊息),但其他通知可能需要使用者採取某種類型的動作。設計通知時,請務必考量通知本身,以及使用者可能需要採取動作的任何其他資訊。包含使用者可在所有可操作通知中找到其他資訊或完成後續追蹤步驟的明確指示或連結。 - **專注於可讀性**。請確保您清楚地傳達每個通知的目的,以及使用者在回應中需要採取的後續步驟。對於不熟悉基本系統內部運作的業務使用者來說,訊息應該可以理解。建立訊息時,請遵循 [無障礙標準](/docs/architect/zh-tw/well-architected/guide/compliant#無障礙),並確保訊息已本地化,以支援可能顯示訊息所在區域中的使用者。 在您的 [設計標準中](/docs/architect/zh-tw/well-architected/guide/intentional#設計標準)包含何時使用通知或不同類型錯誤的模式,以協助確保應用程式產生器遵循一致的作法。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/engaging#實用的應用程式模式與防模式)清單顯示 Salesforce 組織中正確 (與不良) 的通知與傳訊外觀。您可以在建立之前使用這些功能來驗證您的設計,或識別需要重新設計的用途。 若要深入瞭解通知和傳訊的 Salesforce 工具,請參閱參與相關的 [工具](/docs/architect/zh-tw/well-architected/guide/engaging#與參與相關的工具)。 ### 應用程式內導覽 應用程式內導覽可以是消除複雜工作流程神秘性的強大方法 (雖然您應該先確定您已將其[最佳化](/docs/architect/zh-tw/well-architected/guide/automated#流程設計)),或協助引導新工作人員。這是以自動化且可調整的方式導入流程變更、醒目提示新功能或散佈訓練的絕佳方法。不過,如果未仔細實作,則應用程式內導覽可能會過度使用。頻繁的快顯視窗或警示可能會為使用者造成大量的雜訊和中斷,進而導致生產力損失。應用程式內導覽也可能會過度使用,導致版本與變更管理流程變得較繁琐 (特別是簡單功能)。最終,應用程式內導覽的過度使用與過低使用都會導致對業務造成許多風險的問題,包括: - 資料完整性降低 - 使用者錯誤增加 - 使用者挫折度較高且使用者滿意度較低 - 使用者生產力降低 請記住,您可能想要在不同情況下以不同的方式使用應用程式內導覽,因為使用者的心態將會決定指引的程度為「過多」與「不足」。首次導入新系統的使用者,可能需要傳訊的頻率比僅僅要在熟悉系統中瞭解新功能的使用者更高。 以下是建立有效應用程式內導覽的一些關鍵: - **開發設計標準**。請務必記住,過度接觸應用程式內導覽會造成使用者開始定期關閉或忽略訊息。此時應用程式內導覽會變成麻煩,而非資源。定義 [設計標準](/docs/architect/zh-tw/well-architected/guide/intentional#設計標準)以清楚說明使用提示、逐步解說、欄位級說明文字、驗證訊息、路徑、畫面流程等的時機。 - **建立指引實作的優先順序系統**。並非應實作應用程式內導覽的每個使用個案。請考量下列要排定優先順序的問題。您在哪裡可以使用更好的欄位名稱、按鈕上更明確的標籤、更好的[格式設計](/docs/architect/zh-tw/well-architected/guide/engaging#表單)和[流程最佳化](/docs/architect/zh-tw/well-architected/guide/automated#流程設計)來建立更直覺的工作流程?在哪裡可以將更實用的文字或連結新增至路徑?應用程式內導覽會有什麼[業務成本影響](/docs/architect/zh-tw/resources/guide/kpi-spreadsheet-template)?您想向使用者傳送訊息的頻率為何?此外,請確保任何實作都包含在您的[藍圖上](/docs/architect/zh-tw/well-architected/guide/intentional#路線圖),讓所有利害關係人都能看見。 - **將使用者對應至啟用中 (和建議的) 應用程式內導覽**。將使用者對應至應用程式內導覽可協助您識別並防止因為使用者顯示的應用程式內導覽過多而導致「實用性過多」。這通常是由於小組對其特定使用個案的考量過於窄窄,因此會產生隔離開發。針對大型組織,對使用者將會接觸的內容維護整體檢視特別重要。在您的藍圖上包含指引實作也有幫助。 - **收集並使用回饋意見以改善**。檢閱應用程式內導覽用量的資料,並使用該資料判斷應用程式內導覽部署的效率。請務必為使用者提供方式來同時提供開放式回饋意見,以協助指引產生器。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/engaging#實用的應用程式模式與防模式)清單顯示 Salesforce 組織中適當 (與不良) 的應用程式內導覽外觀。您可以在建立之前使用這些項目來驗證設計,並識別需要重新設計的實作。 若要深入瞭解 Salesforce 工具以用於應用程式內導覽,請參閱與參與相關的 [工具](/docs/architect/zh-tw/well-architected/guide/engaging#與參與相關的工具)。 ### 認可與獎勵 將認可與獎勵建立在應用程式中,可協助使用該應用程式的個人更熟悉其工作的影響,並進一步瞭解其貢獻、生產力與績效的價值。這也是發揮忠誠度與參與的強大方法。 不針對認可或獎勵應用程式體驗而設計,會造成各種問題,包括: - 難以瞭解進度或速度的使用者 - 對目標進度或未完成工作的困惑 - 更不具生產力的使用者,無法看見其工作與「全貌」之間的連結 - 浪費在手動、低層級目標報告上的管理時間 獎勵應用程式體驗可能難以設計和提供,因為這些體驗取決於公司文化、原則和標準,以及個別使用者的內容和偏好設定。可幫助桌上型電腦使用者感受到滿意或欣賞的時刻的功能,可能會對行動裝置上的使用者或嘗試從雜亂且忙碌的住家辦公室工作的使用者造成刺激。使用應用程式處理私人或高敏感性資訊的人員可能不喜歡透過碎紙慶祝或徽章的方式進行里程碑的溝通。相反地,散佈式銷售小組可能會將此類遊戲化視為適當的應用程式體驗。最終,您選擇的實作模式最適合透過在小組中與使用者體驗 (UX) 設計師合作來決定。 當涉及結構時,識別應用程式如何以及何處可實作功能,以協助使用者感到受到認可和獎勵很重要。瞭解這些功能如何以及在何處讓應用程式變得較不[可重複使用](/docs/architect/zh-tw/well-architected/guide/composable)或無法提供[真實業務價值](/docs/architect/zh-tw/well-architected/guide/automated#業務價值)也是關鍵。 以下是在 Salesforce 應用程式中評估認可與獎勵時必須考量的一些問題: - **使用者可以如何以及何處查看自己的進度以及整體小組的統計資料?**報告很重要,但通常會包含可能遺漏日常工作內容的摘要資料。您可以使用如 Lightning 應用程式產生器等工具,在應用程式內容內的記錄畫面上內嵌圖表或顯示面板,協助使用者瞭解其日常工作中的影響或進度。 - **如何辨識使用者?**這可能會因小組或個人偏好設定而有所不同。在某些情況下,上司可能想要查看有關使用者進度的訊息,以便與較大的群組共用這些訊息。認可也可以是協助員工士氣的額外益處。在其他情況下,使用者可能只希望是唯一收到特定工作或專案進度通知的人員。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/engaging#實用的應用程式模式與防模式)清單顯示 Salesforce 組織中正確 (與不良) 的認可與獎勵外觀。您可以在建立之前使用這些項目來驗證設計,並識別需要重新設計的實作。 若要深入瞭解認可和獎勵的 Salesforce 工具,請參閱與參與相關的 [工具](/docs/architect/zh-tw/well-architected/guide/engaging#與參與相關的工具)。 ### 實用的應用程式模式與防模式 下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/easy-helpful)探索更多有用的應用程式模式。
模式 防模式
通知與訊息 您的設計標準包括:
- 通知、快顯和通知的已批准使用個案
- 整理變體和通知的設計模式
- 錯誤傳訊的設計模式
如果已定義設計標準,則不會解決錯誤與通知
在您的組織中:
- 通知是主要的傳訊格式
- 快顯訊息使用變體
- 「模式」設為「貼近」的快顯訊息不存在
- 通知很少使用 (若有)
- 生成回應一律可識別使用的資料來源
- 機器人在第一次與使用者互動前清楚識別自己
- 在第一次互動之前,會向使用者顯示與生成式 AI 相關聯風險的免責聲明
- AI 免責聲明為使用者清楚且易懂的語言
在您的組織中:
- 電子郵件是主要的傳訊格式
- 對於訊息類型沒有一致的方法
- 快顯訊息不會一直使用變體
- 使用設定為「粘疊」之 模式的快顯訊息
- 特別使用通知
- 生成回應不會識別使用的資料來源
- 在第一次與使用者互動之前,機器人無法清楚識別自己
- 不會向使用者顯示生成式 AI 風險的免責聲明
- AI 免責聲明不使用使用者易懂的明確語言
在您的應用程式中:
- 沒有直接傳送生成回應給一般使用者,沒有人類參與的點數
在您的應用程式中:
- 生成回應會直接傳送給一般使用者,但沒有人類參與的點數
另請參閱:錯誤處理
應用程式內導覽 您的設計標準和文件包括:
- 應用程式內導覽的已批准使用個案
- 提示與逐步解說的設計模式
- 清晰的使用者矩陣、應用程式和已啟用的應用程式內導覽
如果存在設計標準和文件,則會:
- 請勿處理應用程式內導覽
- 請勿包含顯示使用者、應用程式、已啟用應用程式內導覽的明確矩陣
在您的組織中:
- 「應用程式內導覽之間延遲」設定使用預設值或比 Salesforce 所提供預設 (24 小時) 期間長的自訂值
- 沒有任何應用程式擁有多個啟用的逐步解說
- 沒有逐步解說具有大於 10 的「顯示時間」設定
- 未針對「任何頁面、任何應用程式」或「此頁面、任何應用程式」啟用提示
在您的組織中:
- 「應用程式內導覽之間延遲」設定為短於 Salesforce 所提供預設 (24 小時) 的期間
- 應用程式擁有多個啟用的逐步解說
- 許多逐步解說的「顯示時間」設定大於 10 (有些逐步解說的最大值為 30)
- 會臨時啟用提示,許多提示具有「任何頁面、任何應用程式」或「此頁面、任何應用程式」設定
認可與獎勵 在您的組織中:
- 應用程式使用內嵌分析向使用者顯示相關的目標進度與生產力統計資料
- 只有在使用者同意的情況下才會啟用路徑慶祝
- 通知與傳訊包含使用者辨識,並反映使用者偏好設定,以設計通知對象及觸發通知的項目
在您的組織中:
- 與目標進度和生產力統計資料相關的分析僅適用於報告或經理顯示面板
- 啟用路徑慶祝,而無須檢查使用者同意
- 通知和傳訊不包含任何類型的使用者識別,或不反映使用者的偏好設定,並感到雜訊或煩惱
## 與參與相關的工具
工具描述已簡化實用
啟用 Lightning 應用程式頁面管理頁面可用性、命名、可視性和定位X
採用顯示面板檢閱登入歷程記錄、功能採用與生產力XX
警示在工作階段中保留警示,並且在沒有使用者起始的情況下顯示警示X
用戶端快取 Apex 方法結果使用快取的用戶端資料評估效能X
動態表單僅向使用者顯示必要欄位和頁面區段X
參與洞察監視最近使用者活動並視需要採取行動XX
應用程式內導覽 使用提示和逐步解說進行訓練和上線X
學習路徑個人化使用者學習體驗X
Lightning 應用程式產生器無須程式碼即可建立自訂行動和 Lightning 頁面X
Lightning 資料服務快取和共用元件之間的資料X
VS 程式碼的 Lightning 設計系統驗證程式根據 SLDS 指導方針驗證標記XX
Lightning 頁面範本針對不同的尺寸規格建立 Lightning 頁面X
對應篩選篩選對應、主要 - 詳細資料和階層關係的值X
管理多重貨幣在交易中使用多重貨幣X
傳訊 傳送 SMS、Facebook Messenger 或 WhatsApp 訊息X
Mobile Publisher建立 Lightning 應用程式和 Experience Cloud 網站的行動版本X
行動就緒元件建立在行動體驗中表現良好的元件X
多國語言網站建立網站的不同語言版本XX
通知產生器建立自訂通知以呈現資訊X
路徑引導使用者完成業務流程並慶祝成功XX
平台快取快取資料時改善效能與可靠性X
在 Lightning 應用程式產生器中預覽行動應用程式頁面在行動裝置上預覽記錄和應用程式頁面X
提示警示使用者系統相關問題與更新X
認可徽章認可並慶祝使用者成就X
使用 WDC 辨識贊同技能並表示感謝X
記錄類型個人化業務流程、選項清單值和版面配置XX
聲譽概觀認可參與與Knowledge共用X
限制規則防止使用者存取可能包含不必要資料的記錄X
標準頁面元件瞭解標準 Salesforce Lightning 元件X
翻譯管理全域使用者的翻譯XX
驗證規則儲存之前,確認資料符合指定的標準X
## 與參與相關的資源
資源描述已簡化實用
建築師建立表單指南評估表單設計考量事項並選取最佳工具X
針對不同的尺寸規格設定元件設定元件以在桌上型電腦和手機中呈現X
自訂說明內容為您的獨特實作量身打造說明內容 X
預設欄位值定義預設、動態或靜態欄位值X
設計原則建立符合最佳作法的使用者介面XX
設計標準範本為您的組織建立設計標準XX
設計測試技能 (Trailhead)計畫驗證和測試設計的方法XX
應用程式內回饋意見原則檢閱指導方針以從系統收集回饋意見XX
Lightning Design System Android 靜態程式庫使用 Lightning 頁面的外觀和操作建立原生 Android 應用程式X
Lightning Design System iOS 靜態程式庫使用 Lightning 頁面的外觀和操作建立原生 iOS 應用程式X
傳訊指導方針傳達相關資訊並建立愉快的時刻X
傳訊類型根據使用者互動瞭解不同的傳訊類型X
瀏覽指導方針協助使用者在頁面之間移動,並在應用程式中定位自己X
網頁無障礙測試 (Trailhead)使用自動與手動測試來確保無障礙XX
使用者參與指導方針檢閱上線、採用、協助和學習的原則XX
## 告訴我們您的想法 協助我們讓 Salesforce Well-Architected 與您相關;進行我們的[調查](https://sfdc.co/bxNtvh)以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。 > [在此](/docs/architect/zh-tw/well-architected/guide/contributors)閱讀我們的更新排程。 ## 簡介 可組合解決方案可快速調整且更穩定。建構為可組合的系統會以有意義的單位 (或建構區塊) 建立,這些單元可以彼此順暢運作,且可以輕鬆地交換為不在服務中。將可組合性建立在系統中,可讓您透過重新建構或重新組合系統的個別單位來導入新功能或移除技術債務。可組合性可啟用更快、更可預測的傳送週期和發行,因為小組可以透過更少的變更專注於建立和提供有意義的功能。 可組合系統可讓企業更快速且更穩定地適應,無論是業務內部或由外部因素所導致的刺激。可組合性可協助系統提高[彈性](/docs/architect/zh-tw/well-architected/guide/resilient),並有助於使解決方案和結構模式更具[意圖](/docs/architect/zh-tw/well-architected/guide/intentional)。 您可以透過建立三個關鍵習慣,讓 Salesforce 解決方案更容易組合:關注分隔、互通性和封裝性。您可以在下方以兩種方式查看這些習慣的關係:針對可組合系統中的單一單位,以及可組合系統中的多個單位。 單一可組合單元: 此圖顯示可組合中主題如何透過三個巢狀卡片產生關係。 最內部的卡片是功能單位,下一層是互通性,外層是可封裝性。 可組合系統: 此圖顯示可組合中主題如何透過三個巢狀卡片產生關係。 最內部的卡片是功能單位,下一層是互通性,外層是可封裝性。 ## 分離疑慮 軟體工程和系統結構的一個基本概念,*關注分隔*需要在可分割成模組單位的大型系統內識別各種關注。若要在系統內強大區分關注,則需要在整個系統中為應用程式邏輯和功能建立有意義的單位。較小的單位可讓應用程式傳送與維護小組更輕鬆地瞭解如何和何處進行變更,同時對較大系統造成最少的中斷。較小的單位也可讓您更清楚瞭解處理[技術債務時](/docs/architect/zh-tw/well-architected/guide/intentional#技術債務)要專注的工作方式和位置,並為系統的整體[可讀性](/docs/architect/zh-tw/well-architected/guide/intentional#可讀性)做出貢獻。 您可以透過引導業務能力與管理狀態,在 Salesforce 組織中建立更完善的關注分隔。 ### 功能單位 針對 Salesforce 系統,區隔疑慮的最佳方法是套用以業務為導向的觀點,以識別和組織系統內的模組化單位 (或功能)。這與以工程為中心的檢視不同,其會根據其技術功能來識別單位。分隔關注的業務導向透視圖需要根據其為公司和業務使用者提供的服務,在系統中組織程式碼和自訂項目。採取此方法並不意味著忽略系統中冗餘或重複技術功能的潛力。相反地,這表示技術服務會明確對應至對業務而言最終為透明的組織原則。 以業務功能為導向,可協助確保業務分析與探索小組與遞送小組之間的轉移盡可能簡單。如果應用程式產生器不知道其工作單位在何處對應至您的可組合結構,則表示您處於混亂狀態,而非可組合應用程式橫向。公司所需的結束狀態與組織內模組化單位之間不清楚的對應也會增加開發小組或廠商將冗餘功能建立到系統中的可能性。 請考量下列事項以將功能單位引導至業務能力: - **從待完成的工作開始**。專注於使用者和業務本身的待完成工作 (JTBD)。由 Tony Ulwick 領導,JTBD 方法著重於瞭解人員使用產品或服務嘗試完成的「工作」或「真實目的」。這是比使用者角色相關工作或業務流程中個別步驟更高的抽象層級。例如,如重複檢查和地址驗證等工作可能屬於「建立客戶單一檢視」的較高層級功能。在您清楚瞭解這些高階業務功能後,可以開始將系統的部分對應至這些功能。 - **指向功能,而非報告結構**。業務單位的內部階層並非要完成有意義的功能或工作的 Proxy。您業務的內部階層對流程和小組結構 (不包括預算) 具有重大影響。這些是重要的物流考量事項。但業務的功能需求運作的抽象程度高於物流。如果您要建立一個模組來提供報告結構,而非更高階的函數,請注意,您可能必須採取其他步驟來識別該模組與業務功能之間的關係。 - **重複**。從與公司合作開始,以找出哪些功能可以用於最低可行產品 (MVP)。當您識別功能時,請開始建立該 MVP。當您建立時,請識別您正在建立的功能單位中關鍵的程序、中繼資料和 [事件或訊息](/docs/architect/zh-tw/well-architected/guide/composable#傳訊和事件)。識別任何屬於外部相依性的程序、中繼資料和事件或訊息。隨著設計更具功能的單位,請實作 [API 管理](/docs/architect/zh-tw/well-architected/guide/composable#api-管理)和 [相依性管理](/docs/architect/zh-tw/well-architected/guide/composable#相依性管理),以建立相互相容的單位 (而非建立隔離單位)。 以下的[模式與反模式](/docs/architect/zh-tw/well-architected/guide/composable#關注模式與反模式的分隔)清單顯示 Salesforce 解決方案中對業務功能的正確 (和不良) 方向呈現的外觀。您可以使用這些功能在建立之前驗證您的設計,或識別需要重新設計的系統區域。 若要深入瞭解 Salesforce 提供的工具,以協助您進一步掌握業務功能,請參閱與可編輯功能相關的 [工具](/docs/architect/zh-tw/well-architected/guide/composable#與可編譯相關的工具)。 ### 州/省管理 州/省管理專注於整個系統在不同時間點的資訊移動。有效的狀態管理可讓應用程式處理複雜的資料流程或互動,其中最少有非預定或未確定成果。在模組化 Salesforce 組織中管理狀態意味著建立單位內和單位之間邏輯流程的明確路徑,以及針對非預定執行行為建立豐富的路徑。州/省管理可讓您從模組化 Salesforce 應用程式單元中建立一致的邏輯串流。在大多數的情況下,這需要可[互通性](/docs/architect/zh-tw/well-architected/guide/composable#互通性)來建構單位之間的資訊流程。 跨寬鬆連接單位管理狀態的困難通常會導致 Salesforce 中的單一應用程式開發。您可以在大型「單一流程」中看見,這是在嘗試在單一流程中協調複雜流程時建立的。另一個範例是大量 Apex 類別,可透過 *Spaghetti 程式碼*協調複雜程序,或一系列長的單一方法。這些類型的應用程式結構會使重新設定和除錯變得難以執行,並增加新小組成員或廠商的上線時間。它們也會降低提供給業務之應用程式的價值,因為功能無法重複使用。 請考量下列事項來管理整個模組化 Salesforce 組織的狀態: - **決定何時使用狀態模式與無狀態模式**。狀態模式會在整個執行路徑中保留資訊,無狀態模式則不會。在寬鬆連接的系統中,無狀態模式可讓元件更快速地重新產生,並減少副作用。不過,無狀態模式不適用於所有使用個案。如果您要建立資料作業的元件,則狀態模式有助於確保整個系統的資料完整性和一致性。如果您的元件符合下列任一條件,請使用狀態模式: - 瞭解在較大執行路徑內的放置位置對元件行為至關重要 - 元件的行為必須根據下游動作的結果變更 (例如,它需要根據下游元件的回復/錯誤/成功訊息變更執行) - 元件需要等待外部或下游系統的回應,才能完成其工作 - **為狀態資訊建立有意義的種類**。*狀態*是一個不明確的詞彙,可套用至 Salesforce 組織內 (及外部) 中如此深厚且廣泛的資訊陣列,這詞彙本身幾乎沒有意義。因此,建立狀態模式的必要第一步是為系統中最重要的狀態執行路徑 (或狀態行為類型) 建立具有*意義的*種類。考量一些種類: - 瀏覽與表單 - 資料庫作業 - 批次和大量作業 - 錯誤 - **以資料 [庫交易](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#資料庫操作)定義資料相關狀態**。平台的內建行為會限定 Salesforce 中大多數資料的州考量事項。請勿嘗試對此行為進行管理或排除。為其設計與使用。設計最小化或消除散佈交易邏輯的解決方案。(如需詳細資料,請參閱 [資料處理](/docs/architect/zh-tw/well-architected/guide/automated#資料處理))。 - **識別在 (及跨) 功能單位中發生的狀態**。當您將功能單位組合至較大的系統時,請注意當您混合無狀態與狀態元件行為時,並避免組合可能在處理中產生無限迴圈或間隙。 - **定義轉介**。考慮元件會使用哪些[傳訊或撤銷](/docs/architect/zh-tw/well-architected/guide/composable#傳訊和事件)模式將狀態相關資料傳輸至系統的其他部分。確定您正在建立交易認知並在元件中進行[處理](/docs/architect/zh-tw/well-architected/guide/automated#資料處理)。請勿在您的轉送中包含任何散佈的交易邏輯。 - **建立流程圖與狀態之間的對應**。流程圖詳細說明在不同時間點透過系統移動資訊的步驟。狀態圖顯示資訊 (狀態) 中的實際變更。使用「[Salesforce 圖表」](/docs/architect/zh-tw/reference-diagrams/guide/kit-of-parts) 形狀的中繼資料頁尾部分,在流程的每個步驟之內捕捉資訊的變更狀態。如果您將流程圖與狀態圖分開,請務必將其連結。此概念在設計和實作期間,不應混淆於將流程或系統橫向的目前狀態和未來狀態記錄,因為這與系統中移動的資訊無關。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/composable#關注模式與反模式的分隔)清單顯示 Salesforce 解決方案內的適當 (與不良) 狀態管理外觀。您可以在建立之前使用這些項目來驗證您的設計,或識別系統中需要重新設計的位置。 若要深入瞭解用於管理狀態的 Salesforce 工具,請參閱與可編譯相關的 [工具](/docs/architect/zh-tw/well-architected/guide/composable#與可編譯相關的工具)。 ### 關注模式與反模式的分隔 下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/adaptable-separation-of-concerns)探索更多關注分隔的模式。
模式 防模式
功能單位 在您的設計標準中:
- 命名慣例說明如何標記功能單位
- 存在所有目前定義的功能單位清單 (以及相關命名慣例)
- 已存在建議功能單位新增或變更的標準
在您的設計標準中:
- 設計標準不存在或不處理功能單位和使用個案
在您的文件中:
- 系統橫向圖清楚顯示組織中的功能單位
- 所有文件和實作圖表都清楚顯示元件的功能單位
- 個別元件的文件包含元件的功能單位對應
- 功能單位內的所有元件皆可搜尋且易於尋找
在您的文件中:
- 元件文件不存在
- 元件文件描述元件所屬的功能單位,但它是該功能單位的定義唯一顯示的位置
- 您無法搜尋特定功能單位,且/或搜尋無法識別功能單位內的所有元件
在您的組織中:
- 可快速識別指定中繼資料的功能單位對齊方式 (例如流程、Apex 類別或 Lightning 頁面)
- 功能單位以業務易用的詞彙標記
在您的組織中:
- 無法識別任何中繼資料的功能單位對齊方式
- 功能單位資訊不一致或不準確
- 功能單位資訊會以針對業務使用者沒有意義的工程專注詞彙標記
州/省管理 在您的設計標準中:
- 狀態與無狀態設計的使用個案很明確
- 無狀態通訊的已批准模式存在
- 存在狀態通訊的已批准模式
- 清除狀態存在的種類
在您的設計標準中:
- 設計標準不存在或不處理狀態/無狀態模式和使用個案
在您的文件中:
- 處理狀態和/或無狀態通訊的每個元件都會指出已實作的模式
- 您可以搜尋並尋找已實作特定州/省模式的所有元件
- 流程與互動圖表提供關於狀態種類和處理的詳細資料
在您的文件中:
- 元件文件不存在
- 元件文件描述實作的狀態/無狀態模式,但這是定義唯一顯示的位置
- 無法搜尋特定模式,且/或搜尋無法協助識別使用該模式的所有元件
在 Apex 中:
- 儲存點與回復行為會用於所有資料作業
在 Apex 中:
- 不使用 Savepoints 和回復行為
在流程中:
- 使用錯誤路徑和「回復記錄」元素
在流程中:
- 未使用「回復記錄」元素
## 互通性 在針對互通性所設計的系統中,元件可以交換資訊並有效運作。互通性是使模組化系統可組合而非隔離的關鍵。在[寬鬆連接](/docs/architect/zh-tw/well-architected/guide/composable#寬鬆配對)的系統中,難以達成互通性。您需要為一致的整合方法建立標準,這不會損害單位之間的獨立性和整體系統中的整體[關注分隔](/docs/architect/zh-tw/well-architected/guide/composable#分離疑慮)。 互通性也會影響使用者體驗的品質。您的使用者預期在一個區域中建立的資料 (例如訂單資訊) 可在另一個區域中使用 (例如行銷活動),而您的產生器預期,如果他們學習如何執行某些動作 (例如建立流程或驗證 API),則在繼續進行下一個問題時,他們會發現熟悉的技術可用。無法針對互通性設計,會導致結構冗餘、資料複製、流程效率不佳,以及開發和支援成本增加。 您可以透過傳訊和事件,以及透過 API 管理,在模組化系統中建立互通性。 ### 傳訊和事件 訊息與事件是您在整個系統中啟用元件以傳送和接收資訊的兩種方式。在他們可攜帶的內容方面,事件與訊息類似。重要差異是寄件者的行為。傳送 *訊息*的元件通常會將資料傳送至特定目的地,並等待來自收件者的某種回應。相反地,當發生某些情況時,元件會發出一個 _事件_。沒有特定目的地,也沒有回應的預期。這些行為差異支援不同的通訊模式。訊息支援狀態通訊模式,而事件支援無狀態通訊模式。(如需有關此區別的詳細資訊,請參閱 [州管理](/docs/architect/zh-tw/well-architected/guide/composable#州省管理)。) 在通訊協定上讓小組保持一致,並使用個案進行傳訊和事件處理十分重要。不明確的標準可能會導致整個系統混合模式,進而導致: - 將錯誤的模式套用至特定使用個案的效能與延展性問題 - 不一致的處理,讓一般使用者看起來系統不穩定 - 更長的疑難排解時間與更複雜的維護流程 設計訊息和事件時,請考量下列事項,以在您的 Salesforce 組織內建立更寬鬆的連接結構: - **識別同步和非同步使用個案**。撤銷允許在整個系統中進行寬鬆連接、無狀態和非同步的通訊。「傳訊」允許更嚴格控制的狀態和同步的通訊模式。決定何時使用訊息或事件時,您需要決定您的通訊是否需要同步 (且可能會封鎖) 與非同步且非封鎖。 - **仔細定義資料結構**。元件在元件之間傳遞的資訊結構是保持寬鬆連接系統可管理且一致性的重要部分。(如需詳細資訊,請參閱 [API 管理](/docs/architect/zh-tw/well-architected/guide/composable#api-管理)。)設計訊息或事件時,關鍵考量事項是資訊結構可能需要變更的頻率。一旦在系統中定義並實作訊息或事件結構後,可能會難以處理更新,特別是當事件或訊息已用於將資訊傳送至外部系統時。 - **大小正確的訊息**。一般而言,最佳作法是將訊息大小保持小。但是,訊息*大小*與訊息*量*之間也有平衡動作。系統可以更快處理較少量的資料。由於收件者必須解壓縮包裝、解譯並決定要如何處理收到的資訊,因此處理動作會帶來額外的負擔。這些步驟可能需要很少的時間完成,但可能會對大規模的系統產生負擔。避免設計需要系統中的元件來連續處理許多小訊息,以完成工作。若要正確調整訊息大小,請考慮針對下游元件所需的最小資料設計,以成功處理已傳送的資訊並採取行動,而不考慮每個下游元件都能夠要求或處理許多後續訊息。 - **設計可擴展性**。寬鬆的元件可讓您更輕鬆地調整結構。去除跨元件相依性可讓小組致力於改善任何個別元件的效能或延展性,並對其他元件造成最小影響。不過,寬鬆連接的元件也會在大規模的結構中帶來顯著的複雜度 (尤其是當涉及到 [管理狀態](/docs/architect/zh-tw/well-architected/guide/composable#州省管理)時)。針對有效的使用者體驗或資料完整性原因,識別需要更緊密地配對邏輯或相依性的程序,而不要嘗試將非同步/以事件為基礎的模式導入這些程序。改用以同步化/訊息為基礎的模式和正確的錯誤處理。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/composable#互通性模式與防模式)清單顯示 Salesforce 解決方案內的正確 (與不良) 傳訊與事件外觀。您可以在建立之前使用這些項目來驗證您的設計,或識別系統中需要重新設計的位置。 若要深入瞭解 Salesforce 傳訊和撤銷工具,請參閱與可編譯相關的 [工具](/docs/architect/zh-tw/well-architected/guide/composable#與可編譯相關的工具)。如需為指定的使用個案選擇事件模式或工具的詳細資訊,請參閱使用 Salesforce 進行事件驅動結構的 [結構設計師指南](/docs/architect/zh-tw/decision-guides/guide/event-driven#key-takeaways)。 ### API 管理 在 Salesforce 解決方案內建立適當的應用程式程式設計介面 (API) 管理,可讓系統的個別元件遵循可預測的通訊模式。Salesforce 提供內建的安全 API,用於與 Salesforce 外部系統通訊。(如需 Salesforce Platform API 的詳細資訊,請參閱 [結構基本概念](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#平台-api)。) Salesforce 解決方案中的有效 API 管理是建立真正可組合結構的關鍵。它可讓 Salesforce 組織內部的元件有效率地傳送和接收資訊。其也可讓解決方案產生器遵循明確的通訊協定,以瞭解其建立的元件如何與系統中的其他元件通訊,並協助其及早識別不良的實作。此外,其可讓解決方案產生器更專注於他們正在建立或重新建立的特定元件,進而提升生產力與品質。 企業層級的 API 管理是個別的主題,最適用於全方位的 API 管理工具。(如需有關此主題的更多 MuleSoft 觀點,請參閱「[什麼是 API 管理?」](https://www.mulesoft.com/resources/api/what-is-api-management#:~:text=API%20management%20is%20the%20process,create%20are%20consumable%20and%20secure.)) 請考量下列事項以在您的 Salesforce 解決方案內建立 API 管理功能: - **將 API 視為通訊的可*預測*模式或契約**。輸入或輸出變數的資料類型、變數名稱、應 (或不應) 以指定模式顯示的資訊—這是有效 API 管理的關鍵。這些定義應顯示在您的設計標準中,且小組應能夠透過您的文件瞭解這些定義如何在系統的特定部分中實作。檢視難以將新開發變更合併至整合環境的難題之一,就是將這些難題視為 API 通訊實作不良的證據 (或可能完全沒有 API 定義)。 - **不要將您對 API 的思考限制為只撰寫程式碼**。在此情況下定義 API 的因素是訊息結構與變數在該訊息中的一致性。只要維持該一致性,API 即可在程式碼中以及陳述性自訂中 (例如模組式自動啟動 (或平台事件觸發) 流程,或甚至流程範本中進行實作。讓您的決定以程式碼與流程中要定義的內容為基礎,而不是以 API 實作為基礎,而是以 [封裝可用性](/docs/architect/zh-tw/well-architected/guide/composable#可封裝性)和 [可測試性](/docs/architect/zh-tw/well-architected/guide/resilient#應用程式週期管理)為基礎。 - **讓生命週期與版本化保持簡單**。如同應用程式開發的所有部分,API 都有生命週期:定義、建立、測試、部署和維護 (包括淘汰)。Salesforce Platform API 會在一個行事曆年度內發行數個版本,因為平台的發行週期快速。(您可以在 Salesforce [結構基本概念](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#平台-api)中深入瞭解此行為。)這表示平台 API 的生命週期相當複雜,因為特定 API 的多個版本必須維護且可供 Salesforce 客戶使用。此級別的複雜度適用於 PaaS 使用個案,但對於平台上的解決方案結構而言,這可能是不必要的複雜度 (請參閱:[可讀性反模式](/docs/architect/zh-tw/well-architected/guide/intentional#可讀性模式與反模式))。專注於為 API 定義清楚的目的 (例如,錯誤處理),並清除基準定義。盡量只有一個版本的每個 API。 - **讓您的 API 可供探索、存取和管理**。[記錄您的 API](/docs/architect/zh-tw/well-architected/guide/intentional#設計標準),讓潛在客戶可以輕鬆找到可用的 API 以與其連線。API 必須以流暢運作方式作為整合的 [功能](/docs/architect/zh-tw/well-architected/guide/composable#功能單位)一部分。 - **重複**。專注於一次僅定義和實作一個內部 API。如此一來,您就可以專注於快速重複 API 定義、尋找適合您*的一個*支援版本的表單,並從實作經驗中建立最佳作法。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/composable#互通性模式與防模式)清單顯示 Salesforce 解決方案內的適當 (與不良) API 管理外觀。您可以使用這些功能在建立之前驗證您的設計,或識別需要重新設計的系統區域。 若要深入瞭解 Salesforce 提供的工具,以協助您建立更大的互通性,請參閱與可編輯功能相關的 [工具](/docs/architect/zh-tw/well-architected/guide/composable#與可編譯相關的工具)。 ### 互通性模式與防模式 下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/adaptable-interoperability)探索更多可互通性的模式。
模式 防模式
傳訊和事件 在您的設計標準中:
- 使用同步模式 (傳訊) 和非同步模式 (事件) 的時機存在明確的標準
- 事件與訊息結構存在明確的標準
在您的設計標準中:
- 設計標準不存在,或缺乏同步與非同步模式的明確標準,以及訊息或事件結構的明確標準
在您的組織中:
- 會清楚標記用於內部系統傳訊的平台事件
- Salesforce 流程工具參照全系統傳訊或事件服務
- 流程和程式碼中會顯示一致的傳訊和事件模式
在您的組織中:
- 用於內部系統傳訊的平台事件未清楚標記或不存在
- 傳訊和事件模式的不同策略會顯示在流程和程式碼之間
在 Apex 或 LWC 中:
- 範圍限制自訂事件定義 (系統範圍的事件或訊息不會以程式碼定義)
- Apex 中的全系統傳訊或結束服務會以可在 Salesforce 流程工具中使用的方式註釋
在 Apex 或 LWC 中:
- 在 Apex 或 JavaScript 中定義全系統訊息和/或事件結構
- 在 Apex 中定義的全系統事件或訊息結構無法在如流程等工具中使用
API 管理 在您的設計標準中:
- 已存在可供跨元件通訊 (亦即 API) 的明確通訊協定
- 通訊協定/API 概述在邏輯群組中,讓產生器可以搜尋和尋找
- 通訊協定/API 定義變數資料類型、變數名稱、必要或選用項目,並提供使用時機的明確描述
在您的設計標準中:
- 設計標準不存在或不定義 API 和使用個案
在您的文件中:
- 每個元件的文件會清楚列出已實作的 API/通訊通訊協定
- 您可以搜尋特定的 API 或通訊協定,並識別實作的元件
在您的文件中:
- 元件文件不存在
- 元件文件描述在元件內實作的 API,但這是 API 定義唯一顯示的位置
- 無法搜尋特定的 API 或通訊協定,且/或搜尋無法識別已實作 API 或通訊協定的元件
在您的組織中:
- 使用自訂中繼資料類型定義內部通訊的 API 訊息格式和變數
- 透過平台事件定義內部通訊的 API 訊息格式和變數
- 程式碼和陳述式自訂項目會參照適當的自訂中繼資料類型 (或平台事件),以傳送或接收資訊
在您的組織中:
- 系統元件之間的通訊 (程式碼和陳述性自訂項目) 為臨時
- API 專為 Salesforce 與外部系統之間的通訊而定義
## 可封裝性 在 Salesforce 組織中建立封裝性表示組織中的功能來自可獨立且可靠地作為封裝開發和部署的單位。理想情況下,這些單位會定義為 [第二代](https://developer.salesforce.com/docs/atlas.en-us.218.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_plan_pkg_types.htm)封裝類型 (ISV 的解除鎖定封裝或受管理封裝)。注意:由於設計良好的解決方案只會使用這些封裝類型,因此此處不會涵蓋第一代受管理封裝。 在 Salesforce 組織中定義[關注分隔](/docs/architect/zh-tw/well-architected/guide/composable#分離疑慮)並建立功能單位是一件事。若要夠清楚地解析和管理相依性,以成功將這些單位版本化為封裝成品,則是另一個事項。若要達到該等級的穩定性和中繼資料隔離,則需要高層級的 DevOps (和結構) 成熟度。其也可加速開發時間、改善應用程式產生器體驗,並為版本與版本管理帶來可預測性和控制能力。並非每個組織都能夠支援定義、維護和開發有效封裝所需的基礎結構。但實現封裝性應該是幾乎每個 Salesforce 組織的最終目標。 您可以透過專注於寬鬆配對和相依性管理,在 Salesforce 解決方案中建立封裝性。 ### 寬鬆配對 在寬鬆連接的系統中,個別組件不會彼此緊密繫結。可組合系統的許多優點來自於寬鬆連接。在可封裝的系統中,實現封裝 (與安裝組織) 之間的寬鬆連接可讓您擁有正確定義的封裝,並為使用封裝的小組提供更具生產力的開發週期。 在 Salesforce Platform 上,您可以建立[緊密連接至特定組織](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_org_dependent.htm)的封裝。此功能對於定義功能單位,並針對在組織中正確[分隔疑慮](/docs/architect/zh-tw/well-architected/guide/composable#分離疑慮)進行實驗很有幫助,因為您在封裝成熟度中取得進度。不過,如果您選擇此方法,您將會意識到真正可封裝中繼資料的幾個優點,包括來源驅動的開發、使用版本化和成品穩定性的能力。相反地,您可能會繼續遇到緊密連接系統的缺點,包括: - 造成中斷和效能問題的單一失敗點 - 緩慢且無法預測的部署 - 困難、複雜的除錯和疑難排解週期 - 具有 [規模](/docs/architect/zh-tw/well-architected/guide/reliable#延展性)與 [效能](/docs/architect/zh-tw/well-architected/guide/reliable#績效)的問題 任何可封裝 Salesforce 系統的最終目標為寬鬆配對的封裝。 當您將 Salesforce 中繼資料分成有效封裝時,請考量下列事項: - **哪些自訂項目是資料與中繼資料**。當涉及封裝性時,Salesforce Platform 會以不同的方式處理資料與中繼資料。請務必瞭解貴組織中哪些功能是 [中繼資料或資料](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#中繼資料與資料)。您無法在任何封裝單位中包含資料。當您決定要從何處開始將功能解壓縮至封裝單元時,您的小組將需要決定儲存為資料的自訂項目是否應完全從封裝中排除,或重新定義為以中繼資料為基礎的實作。 - **封裝會如何影響小組**。Salesforce 封裝的物流實際現實是,生產和發行封裝版本的大部分工作都需要具備 Salesforce CLI 和/或 CI/CD 技術的技能。這表示低程式碼和程式設計自訂項目都需要能夠使用封裝相關 DevOps 技術的人員花費時間和注意。根據您的小組管理功能傳送的方式,封裝採用可能會對整個組織的不同小組造成明顯的緩慢或封鎖。您必須識別小組是否能夠透過封裝管理功能傳送,並制定計畫以解決任何技能或員工缺口。解決方案可能包括針對開發環境採用配對的程式設計或實作 CI/CD 工作。 - **封裝如何改變環境策略**。在封裝驅動的開發生命週期中,應在 [臨時組織中](https://developer.salesforce.com/docs/atlas.en-us.238.0.sfdx_setup.meta/sfdx_setup/sfdx_setup_next_steps.htm?q=scratch%20org)提早完成工作。這些暫時的來源驅動開發環境允許更快速、更反覆的週期。它們也支援對開發小組進行更精確的環境存取控制,並與生產環境有更大的隔離。您的封裝對僅存在於 Sandbox 或生產環境中未封裝中繼資料或資料的相依性愈多,小組實際使用臨時組織的可能性愈低。您可以[在 Sandbox 中啟用來源追蹤](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_source_tracking_sandboxes.htm),以允許在非臨時組織環境中使用來源驅動的開發模式,但您的開發小組不會從臨時組織的速度和反覆速度中獲益。 - **封裝版本與版本之間的關係**。計畫開發封裝版本化的發生頻率和階段。封裝版本要求限制為 24 小時輪動 (每個組織)。作為一般最佳作法,只有在您確信沒有任何封裝內容需要變更時,才能版本封裝。在理想情況下,您會在品質保證流程完成後佈建封裝版本。請勿讓開發小組使用封裝建立要求的成功或失敗,作為他們定義封裝邊界程度的「測試」。有方法可以這麼做,而無須嘗試版本化封裝成品。 - **理想端狀態應支援的項目**。理想的封裝策略可讓控制的穩定 Salesforce 版本快速開發和交付。在整個組織中定義過多封裝可能會為開發小組產生新種類型的複雜性和瓶頸。過度模組化組織也會造成版本變慢且難以執行。從建立並發行數個版本的單一有意義的封裝開始。逐步衍生追蹤封裝。當您的版本步調適合您的業務時,請停止導入封裝。如果業務需要變更或版本品質下降,則反射器封裝會隨著時間變化。理想封裝端狀態為主觀。 無論您決定定義封裝的方式為何,只會透過有效的[相依性管理](/docs/architect/zh-tw/well-architected/guide/composable#相依性管理),成功版本寬鬆的封裝。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/composable#封裝性模式與反模式)清單顯示 Salesforce 封裝的適當 (與不良) 寬鬆配對外觀。您可以使用這些功能在建立之前驗證您的設計,或識別需要重新設計的系統區域。 若要深入瞭解 Salesforce 工具以協助您建立更多可封裝性的資訊,請參閱與可編輯相關的 [工具](/docs/architect/zh-tw/well-architected/guide/composable#與可編譯相關的工具)。 ### 相依性管理 在 Salesforce 解決方案的內容中,相依性管理表示識別並建構封裝中中繼資料與安裝封裝之組織中繼資料之間的關係。相依性管理是開發穩定封裝成品的重要部分。 相依性可能會與建立完美分隔且[寬鬆連接](/docs/architect/zh-tw/well-architected/guide/composable#寬鬆配對)的功能單位的努力有關。在理想的工程狀態中,寬鬆連接的系統沒有單位之間的相依性。然而,在現實世界中,去除所有相依性並不實際。 通常,使系統可[讀取](/docs/architect/zh-tw/well-architected/guide/intentional#可讀性)與使用易於業務使用的[功能單位](/docs/architect/zh-tw/well-architected/guide/composable#功能單位)之間的平衡需要在系統中單位的完美隔離方面進行權衡。更實際的說法是,Salesforce Platform [標準功能](/docs/architect/zh-tw/well-architected/guide/intentional#標準與自訂功能)所提供的核心服務會為任何 Salesforce 解決方案建立關鍵的正面相依性。許多內建的延展性、效能和安全性優點都來自於其與平台的整合程度。設計可封裝的 Salesforce 解決方案時,請務必記住,封裝相依性本身並非壞。不良的相依性管理*是*不良的。 使用 Salesforce 封裝有效管理相依性表示開發和維護小組可以: - 更快速地上線至新專案,且擁有有限的環境存取權 - 快速開發和測試變更 - 瞭解應如何在較小的特定承諾中提供複雜功能 - 控制版本步調,並減少系統維護/版本中斷期間 - 在任何環境中可預測回復不良變更 使用 Salesforce 管理相依性的技巧相當簡單: - 使用 [傳訊和撤銷](/docs/architect/zh-tw/well-architected/guide/composable#傳訊和事件)來處理元件之間的狀態或未狀態資訊寬鬆轉移。 - 使用自訂中繼資料類型來提供動態執行階段資訊,並支援相依性插入模式。 - 讓 Apex 開發人員使用 [抽象或虛擬類別](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_extending.htm)。 最後,您必須決定您組織中允許跨陳述式與程式設計開發的設計模式。最重要的考量事項 (在結構上) 是定義您要新增更多工程複雜度以減少相依性的位置,以及您需要容忍更多相依性以簡化應用程式產生器工作流程的位置。 當您在封裝中建立相依性管理策略時,請考量封裝單位的兩個主要組織原則:水平與垂直。 - **水平界限**。在水平範例中,多個封裝可能需要的功能會摘要為水平層。水平層則會成為常見功能的來源,且透過已宣告的相依性存取。將封裝之間的冗餘功能最小化優先於將相依性最小化。 - **垂直邊界**。垂直範例可最大化系統部分之間的隔離與寬鬆連接。共用功能受到限制,且類似的工作可能會顯示在單位之間。相依性嚴格限制,以最大化封裝單位之間的隔離。 請注意,這不是其中一項或一項決策。您可以視需要混合垂直與水平範例。通常,開始封裝的最快方法是建立水平服務層。隨著封裝採用的規模和複雜度增加,抽取更多垂直單位有助於簡化複雜的環境設定流程或開發人員上線。 例如,具有兩個功能單位 (A 和 B) 的系統可以使用垂直、水平和垂直水平混合式範例中所排列封裝相依性來結構。 此圖顯示兩個封裝 (A 和 B),建立以沒有共用相依性 (垂直配量),建立以擁有許多共同服務 (水平) 和每個服務的混合 (混合)。 無論您選擇的封裝組織模式為何,都有一些絕對值需要記住: - **請勿在封裝之間重複中繼資料**。多個封裝所需的中繼資料應摘要為宣告為相依性的一或多個封裝。 - **使用 Salesforce Platform 中繼資料** 的內建相依性。針對應用程式產生器,Salesforce Platform 提供的內建服務提供大量可快速設定的功能。許多服務都有內建的相依性,難以抽象化為低層級的功能單位。針對指定的中繼資料類型,您需要瞭解其在內建相依性[範圍](https://developer.salesforce.com/blogs/2018/06/lets-talk-deployment-and-reasons-why-they-succeed-or-fail)中的所在位置,並使用此瞭解來[定義封裝相依性鏈結](https://developer.salesforce.com/blogs/2018/06/working-with-modular-development-and-unlocked-packages-part-2)。請勿透過嘗試強制將寬鬆連接至具有許多內建相依性的標準平台功能來開始封裝採用。當您達到較高層級的功能時,這會增加複雜度 (非值)。這也是落在 [標準與自訂](/docs/architect/zh-tw/well-architected/guide/intentional#標準與自訂功能) [反模式](/docs/architect/zh-tw/well-architected/guide/intentional#維護模式與反模式)中的另一個方法。從底部 (最少相依性) 封裝中繼資料,並隨著時間迭代。 - **監視您的相依性鏈**。避免建立將需要開發人員一次將變更分割成許多不同封裝的封裝相依性鏈。 - **思考來源控制的意義為何**。在來源控制中管理封裝的方式有兩種基本方式。第一個為單一單一封裝,其中封裝在資料夾內隔離。\_\_第二個為具有封裝隔離在自己儲存庫中的多個儲存庫。長期管理每種類型的來源策略都有複雜性。在開發人員上線方面,垂直邊界在多個存放庫範例中更有效率。水平邊界在單一空間中更容易理解。同樣地,您可以隨著結構成熟而混合與比對策略。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/composable#封裝性模式與反模式)清單顯示 Salesforce 封裝的正確 (與不良) 相依性管理外觀。您可以使用這些功能在建立之前驗證您的設計,或識別需要重新設計的系統區域。 若要深入瞭解 Salesforce 用於相依性管理的工具,請參閱與可編譯相關的 [工具](/docs/architect/zh-tw/well-architected/guide/composable#與可編譯相關的工具)。 ### 封裝性模式與反模式 下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/adaptable-packageability)探索更多可封裝的模式。
模式 防模式
寬連接器 在您的設計標準中:
- 命名慣例說明如何標記封裝單位
- 您可以搜尋並尋找所有目前定義的封裝單位清單 (以及相關的命名慣例)
- 已存在建議封裝單位新增或變更的標準
- (選用) 自訂設定的所有已批准使用個案都會清楚列出 (若有)
在您的設計標準中:
- 設計標準不存在或不處理封裝單位和使用個案
在您的組織中:
- 自訂中繼資料類型提供程式碼和陳述式自訂的動態執行階段資訊
- 沒有任何自訂設定,或有少數自訂設定,且沒有與封裝功能相關的自訂設定
- 沒有任何自訂物件可提供程式碼或陳述式自訂的動態執行階段資訊
在您的組織中:
- 使用自訂設定
- 自訂物件存在以提供動態執行階段資訊,以用於程式碼或陳述式自訂
- 未使用 (或未一致使用) 自訂中繼資料類型來提供動態的程式碼和陳述式自訂資訊
在 Apex 中:
- 使用抽象或虛擬 Apex 類別定義通用服務和板碼
- 根據動態、執行階段資訊參照適當自訂中繼資料類型的方法
在 Apex 中:
- 一般服務與锅板代碼與其他類別不易區分
- 類別與方法之間的內部參照難以遵循,且在整個程式碼庫中不一致
- 方法不使用一致的方法來存取動態、執行階段資訊,或方法查詢自訂物件以取得執行階段行為資訊,或程式碼參照自訂設定
在來源控制與開發環境中:
- package.xml 檔案只會顯示在早期階段或概念證明專案資訊清單中
在來源控制與開發環境中:
- package.xml 檔案用於控制中繼資料部署
在封裝中:
- 組織相依解除鎖定的封裝僅用於早期階段或概念證明實驗
- 在生產或 Sandbox 中未定義未受管理的封裝
在封裝中:
- 所有封裝皆為組織相依的已解除鎖定封裝
- 在生產或 Sandbox 中定義未受管理的封裝
相依性管理 在您的設計標準中:
- 已存在宣告相依性的標準
- 已存在導入或修改相依性的標準
在您的設計標準中:
- 設計標準不存在或不處理如何宣告相依性
在來源控制:
- 已解除鎖定的封裝版本使用別名符號 (最新版本) 以在 sfdx-project.json 資訊清單中宣告相依性
- 開發人員可以從來源控制建立臨時組織並成功部署封裝中繼資料
在來源控制:
- 在 sfdx-project.json 資訊清單中明確宣告解除鎖定的封裝版本 (沒有 最新別名)
- 開發人員無法使用來源控制來成功使用臨時組織
在您的封裝中:
- 封裝之間沒有重複的中繼資料
- 針對封裝開發,所有早期階段開發工作都會在臨時組織中發生
在您的封裝中:
- 透過在不同封裝中重複中繼資料來略過相依性
- 早期封裝開發會在開發人員 Sandbox 中發生,或早期封裝開發無法在臨時組織中發生
另請參閱:寬連接器
## 與可編譯相關的工具
工具描述分離疑慮互通性可封裝性
Apex REST Web 服務透過 REST 向外部應用程式公開您的 Apex 類別和方法X
Apex SOAP Web 服務透過 SOAP 向外部應用程式公開您的 Apex 類別與方法X
變更資料取取發佈變更至 Salesforce 記錄X
自訂中繼資料類型定義可重複使用、可自訂、可封裝的功能X
裝飾以 API 形式公開函數或內容XX
Dev Hub管理臨時組織、第二代封裝和 Einstein 功能。XXX
一般事件 (舊版)*傳送未繫結至 Salesforce 資料變更的自訂事件X
Lightning 資料服務快取和共用元件之間的資料XX
中繼資料 API在 Salesforce 環境之間部署自訂項目X
中繼資料涵蓋範圍報告決定多個管道的支援中繼資料涵蓋範圍 X
MuleSoft Composer使用點擊而非程式碼建立資料的流程自動化X
輸出訊息當欄位值更新時,將訊息傳送至外部端點X
平台事件 傳送安全且可調整的訊息,其中包含近乎即時事件資料X
Pub/Sub API訂閱平台事件、變更資料擷取或即時事件監視X
PushTopic 事件 (舊版)*傳送和接收符合使用者定義 SOQL 查詢的變更通知X
Salesforce CLI使用您的 Salesforce 組織時開發和建立自動化X
Salesforce 圖表建立圖表以顯示業務功能與技術詳細資料X
Visual Studio Code 的 Salesforce 擴充功能 (展開型)Salesforce 開發的正式 VS 程式碼擴充X
臨時組織將 Salesforce 程式碼與中繼資料部署至可處理組織X
第二代受管理封裝開發和散佈 AppExchange 的應用程式X
Tooling API建立 Lightning 平台應用程式的自訂開發工具或應用程式X
解除鎖定的封裝組織中繼資料、封裝應用程式或擴充 AppExchange 應用程式X
*Salesforce 將在目前的功能中繼續支援 PushTopic 和一般事件,但不打算進一步投資此技術。
## 與可組合相關的資源
資源描述分離疑慮互通性可封裝性
數位整合的原始觀點針對連線概念開發通用語言X
使用 Salesforce 套用網域驅動的設計讓您的解決方案與業務功能有關X
第二代封裝的最佳作法瞭解 2GP 封裝模式與作法X
受管理封裝中可用的元件瞭解受管理封裝中繼資料元件X
設計標準範本為您的組織建立設計標準XXX
事件驅動的結構決策指南比較以事件為導向的結構模式與工具X
事件反模式識別使用事件時要避免的反模式X
如何設計訊息驅動和事件驅動的 API瞭解 MuleSoft 開發指南中的差異XX
瞭解待完成工作的架構在 Trailhead 上探索 JTBDX
在 B2C Commerce 中管理全域狀態輕鬆在元件之間傳遞資料以維持狀態X
傳訊指導方針傳達相關資訊並建立愉快的時刻X
傳訊類型依使用者互動的性質瞭解不同的傳訊類型X
中繼資料類型瞭解 Salesforce 組織中不同類型的中繼資料XX
行動應用程式通知類型瞭解 Salesforce 行動應用程式的通知類型X
最佳化檢視狀態維護 Visualforce 頁面中的狀態X
Salesforce 開發人員體驗 (DX)在 Lightning 平台上管理與開發應用程式XXX
不支援的中繼資料類型識別中繼資料 API 中無法使用的元件X
## 告訴我們您的想法 協助我們讓 Salesforce Well-Architected 與您相關;進行我們的[調查](https://sfdc.co/bxNtvh)以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。 > [在此](/docs/architect/zh-tw/well-architected/guide/contributors)閱讀我們的更新排程。 ## 簡介 可 **調整**的 Salesforce 解決方案會隨業務進展。針對「可**調整**」而設計良好的解決方案,其彈性且可組合。 **彈性的**解決方案可以順利處理變更。
**可組合**解決方案可快速調整且更穩定。 業務變更的需求可能來自許多來源:客戶要求、市場或產業中斷,或數位轉型機會。有時候變更很小。有時候,變更會很深刻。在最深刻的層級上,變更可能需要企業重新思考並切換其作業的核心原因,並重新評估其客戶提供的內容、方式和位置。可**適應的**結構不僅有助於企業在中斷狀況下生存和復原,還能為企業在深度變化的時代創新和茁壯發展。 建立可 **適應**的系統需要深度創意精確的結構設計思維。您必須先精確地瞭解業務的短期與長期軌道。當您評估個別實作詳細資料時,必須考量多個維度和詳細資料層級的影響。您必須考量人員、流程和技術。您必須同時預估對目前狀態和任何未來狀態的巨集和微層級影響。 下列幾節提供更多關於 **可調整**解決方案結構的每個核心行為的深入指引。 ## 可調整概觀
彈性
彈性解決方案能順利處理變更。彈性結構可以以可預測的方式快速返回預期的行為和作業。
應用程式週期管理 事件回應 連續性規劃
版本管理
環境策略
測試策略
復原時間
能夠分級
監視與警示
業務連續性
技術持續性
可組合
可組合解決方案可快速調整且更穩定。可組合結構內建在相互順暢運作的單位中,且可切換為不在服務中。
關注分隔 互通性 可封裝性
功能單位
州/省管理
傳訊和事件
API 管理
寬鬆配對
相依性管理
> [在此](/docs/architect/zh-tw/well-architected/guide/contributors)閱讀我們的更新排程。 ## 簡介 可靠的解決方案可有效且可靠地運作。它們可供使用、一致執行,並調整規模以支援不斷成長的業務。 可靠的系統不容易出錯、會如預期運作,並及時提供結果。相反地,不可靠的系統速度緩慢、行為未如預期,或在重要時機失敗。不可靠的系統提供不準確的資訊,因此利害關係人無法 Trust 他們進行業務決策。 系統可靠性並非不變。如果未針對成長而設計,今天可靠的系統可能會變成不可靠。不可靠的系統可能需要昂貴的維護、重建或重新實作,從策略專案中轉移資金。 專注於三個原則:[可用性](/docs/architect/zh-tw/well-architected/guide/reliable#可用性)、[效能](/docs/architect/zh-tw/well-architected/guide/reliable#績效)和[可擴展性](/docs/architect/zh-tw/well-architected/guide/reliable#延展性),以提升 Salesforce 解決方案的可靠性。[Salesforce 的可擴展性產品套件](https://www.salesforce.com/platform/application-scaling-performance-testing/)提供原生功能,協助結構設計師實作可靠的作業。 ## 可用性 可用性是測量系統營運時間的百分比。Salesforce Platform 會處理大多數的 [基礎結構層級](https://trust.salesforce.com/)可用性問題。不過,您在平台上建立且客戶體驗的解決方案可用性是共同的責任。請務必瞭解,即使 Salesforce 的 [高可用性](https://trust.salesforce.com/en/#systemStatus)仍是如此,服務中斷的風險永遠不會為零。 結構設計師必須針對如計畫維護或未預期的狀況等 Salesforce 服務中斷進行準備。除了服務中斷之外,請考慮如何維持高效能並隨業務成長。縮小結構選項範圍可能會導致長期可用性問題。 在建立解決方案 _之前_,請在設計階段考量可用性。您延後建立可用性的時間愈長,長期而言,可用性問題的實際成本愈高。若要降低潛在風險,請在測試環境中使用 Salesforce 規模測試。在該環境中,您可以在生產規模中進行測試,再於生產環境中部署程式碼。 結構設計師使用業務語言,為業務專案關係人建立技術考量,以獲得參與度並排定可用性工作的優先順序。若要降低潛在風險,請在測試環境中使用 Salesforce 規模測試。在該環境中,您可以在生產規模中進行測試,再於生產環境中部署程式碼。 您可以透過[風險管理](/docs/architect/zh-tw/well-architected/guide/reliable#風險管理)和[故障減輕](/docs/architect/zh-tw/well-architected/guide/reliable#失敗緩解)來架構 Salesforce 解決方案的更高可用性。 ### 風險管理 在 Salesforce 結構內容中管理風險涉及識別系統作業、其使用者 (包括員工、合作夥伴和客戶) 的潛在風險,以及您的業務流程。通常,執行風險分析的正式流程屬於專案經理的責任。身為結構設計師,請確保風險分析充分代表技術和業務專案關係人的疑慮。您也應負責根據生產量高峰熱點識別您需要進行規模測試的業務關鍵使用個案。 風險管理中的一些最大的陷阱是由於未投入足夠的時間和考量。小組通常會略過風險評估,或將解決方案進行 [備份與還原](/docs/architect/zh-tw/well-architected/guide/resilient#建立備份與還原功能) (降低資料完整性風險的重要部分) 與全方位風險評估與緩解混合。 若要評估 Salesforce 解決方案的風險,請使用下列方法: - **使用風險評估架構**。某些大型企業可能已具備相關風險矩陣。如果您有,請使用它們來決定如何分類危險、要收集的資訊類型、您需要準備哪些修復措施等等。如果您還沒有風險評估架構,請從聲譽良好的來源中尋找並使用架構。 - 從客戶的觀點**評估影響嚴重性和風險種類**。Proactive Monitoring and Scale Center 提供可設定的警示與顯示面板。他們會持續評估效能與延展性風險,並降低您對手動檢查清單的依賴。客戶 Trust 和認知是每個業務的關鍵。就業務影響而言,與客戶相關的問題風險通常會高於與未相關的問題相關的風險。客戶可能不會以與內部小組相同的方式思考或看見風險。如果客戶無法登入其帳戶,他們可能不關心問題的根本原因。他們最關心的是自己的立即體驗。 - **排定風險的優先順序**。理想情況下,每個風險都會連結至可靠的緩解風險和回應計畫。事實上,您會在一段時間內遇到需要解決的間隙。採用「提前提供價值並重複」方法十分重要。您與您的運送與維護小組在指定的時間只能承擔足夠的工作。在 Salesforce 中,常見的運算式為「如果一切都重要,則沒有什麼都重要」。我們使用 V2MOM 來排定整個公司的工作優先順序,並將其與整個小組及每個人保持一致。(您可以在 Trailhead 上[深入瞭解 V2MOM](https://trailhead.salesforce.com/content/learn/modules/manage_the_sfdc_organizational_alignment_v2mom/msfw_oav2m_writing_a_v2mom)。)使用您的風險評估,讓您有機會與專案關係人合作排定優先順序並致力於最重要的風險管理工作。使用規模測試 - 測試計畫建立來識別要排定優先順序的風險,並使用規模測試降低這些風險。 使用 Proactive Monitoring 偵測早期可用性風險。它會呈現如 API 要求限制高峰、列鎖定錯誤或同時 Apex 失敗等異常,在問題升級為服務中斷之前提供可採取動作的洞察。 可用性[模式和反模式](/docs/architect/zh-tw/well-architected/guide/reliable#可用性模式和反模式)顯示 Salesforce 解決方案內的正確和不良風險管理。在建立之前,使用模式驗證您的設計,或識別系統中的重新產生區域。 若要深入瞭解與風險管理相關的 Salesforce 工具,請參閱可靠性的 [Salesforce 工具](/docs/architect/zh-tw/well-architected/guide/reliable#可靠性的-salesforce-工具)。 ### 失敗緩解 失敗點是讓系統不可靠的漏洞。成功的失敗緩解不是要找出每個潛在失敗點。而是要快速分類和排定失敗點的優先順序,以便維護和支援小組有效回應。請參閱 [事件回應](/docs/architect/zh-tw/well-architected/guide/resilient#事件回應)。 若要開發更好的失敗緩解策略: - **根據人員、程序和技術分類失敗點的觸發**。就像您在人員、流程和技術方面將風險分類一樣,請將相同的想法套用至觸發高優先順序失敗點的方式。此方法可協助您識別潛在失敗觸發,並針對其開發和組織回應。有時,您可以根據觸發分類的方式,使用類似的緩解方法來緩解看似不同的失敗觸發。
觸發分類/類型 緩解
人員 原則
程序 手冊、連續性計畫
技術 冗餘
- **識別基本、中型和成熟緩解方式的外觀**。建立緩解策略需要時間。定義緩解的層級,以協助您與您的小組瞭解您可以立即在何處進行控制,以及如何在一段時間內專注於工作。一律盡快尋找機會以在您的緩解措施中使用自動化。為了說明此方法在實際上呈現的外觀,此範例顯示以人員為導向的觸發,以及基本、中介和成熟層級以原則為基礎的緩解方式呈現的外觀。
觸發 緩解 基本 中繼 成熟
新增或離開員工的使用者存取權變更 服務層級契約 (SLA) 和佈建或取消佈建使用者的需求 根據 SLA 手動佈建和取消佈建使用者以進行手動變更。 根據 SLA 的排程變更,透過排程工作處理使用者變更。 透過 SSO/IDM 解決方案自動化使用者佈建和取消佈建。
除了使用結構手冊和持續性規劃外,還可使用 Proactive Monitoring。透過 Proactive Monitoring,您可以設定失敗觸發的即時警示,例如登入失敗、CPU 逾時例外或同時 API 要求錯誤。此警示方法可透過確保技術和業務專案關係人及時得到通知,以減少失敗的影響,來加強失敗緩解。 可用性的 [模式和反模式](/docs/architect/zh-tw/well-architected/guide/reliable#可用性模式和反模式)會顯示 Salesforce 解決方案中的正確和不良失敗緩解方式。使用這些權限來在您建立之前驗證您的設計,或識別系統中要重新產生的位置。 若要深入瞭解失敗緩解的 Salesforce 工具,請參閱與可靠相關的 [工具](/docs/architect/zh-tw/well-architected/guide/reliable#可靠性的-salesforce-工具)。 ### 可用性模式和反模式 此表格顯示要在您的組織中尋找或建立的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/trusted-availability)探索更多可用性的模式。
模式 防模式
風險管理 在您的業務中:
- 已建立的風險評估架構正在使用中。
- 風險會分類為人員、流程和技術領域。
在您的業務中:
- Salesforce 的風險評估架構為臨時。
- 未清楚識別風險。
在您的文件中:
- 系統會根據客戶影響來分類和評估風險嚴重性。
- 降低風險和回應計畫的優先順序。
在您的文件中:
- 評估風險嚴重性或種類時,不會考量客戶觀點。
- 風險降低和回應計畫會嘗試捕捉所有可想像的風險。
失敗緩解 在您的組織中:
- 失敗點觸發及其對應的緩解計畫會依人員、程序和技術分類。
- 緩解控制會立即生效、隨著時間成熟,並盡早納入自動化。
- 為了確保最佳的延展性,在將變更發佈至生產環境之前,會完成全方位測試和最佳化。
- 在業務關鍵事件之前,根據 SLA 執行規模測試和最佳化。
在您的組織中:
- 無法分類失敗點數的觸發。緩解措施不存在或僅臨時使用。
- 不會重新檢視或改善緩解控制。
- 自動化未用於緩解問題。
監視與可觀察性 在您的組織中:
- 針對檢查和異常偵測,已啟用「Proactive Monitoring」。
- 為了持續可視性,Proactive Monitoring 警示會與「規模中心」整合。
在您的組織中:
- 只會執行手動健康檢查,且不會進行持續監控。
## 績效 系統結構效能是測量系統處理的量 (輸出) 以及回應的速度 (延遲)。您通常會透過生產測試和監視來瞭解系統的效能。 效能高的系統會在每個預期的需求層級及時完成程序。 效能不佳會隨著延遲較高和輸送量較低,進而導致生產力降低並增加使用者挫折。修正績效問題十分緊急,因為這些問題會導致客戶失去 Trust 和財務損失。 您可以透過最佳化輸送量和延遲來改善解決方案的效能。 > 注意:輸出量和延遲最佳化是改善系統處理和回應性的必要層面。不過,請務必記住,整體系統效能也取決於您對[規模](/docs/architect/zh-tw/well-architected/guide/reliable#延展性)的結構效果。您必須在設計中考量這兩個維度。 ### 輸出 在 Salesforce 結構中,輸送量是指系統在指定時間間隔內可完成的同時要求數。針對輸送量設計並最佳化的客戶 Salesforce 解決方案在 Salesforce Platform 的內建[管理員限制](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)內運作較佳。 最佳化 Salesforce 中的輸出量從準確計算系統中的工作量並規劃其成長開始。若未針對系統所產生需求精確預測,您就無法透過系統的輸送量功能找出潛在問題。 當思考工作量時,請考量以下三個維度。 - 系統在指定時間內必須處理的**交易數量** - 必須同時存取系統的 **使用者人數** - **系統中交易邏輯的整體複雜** 度 當考量效能時,小組有時會過於專注於運算,以及 CPU 時間上限的限制,這是平台管理員限制之一。專注於 CPU 時間的小組會忽略最佳化輸送量的其他方法。展開焦點並套用這些方法可改善 Salesforce 結構的整體輸送量和效率。這些改善將有助於減少延遲並提升整體系統效能。ApexGuru 會主動偵測輸送量限制的反模式,例如迴圈中的 SOQL、迴圈中的 DML、效率不佳的 GGD 呼叫和昂貴的方法。這些洞察可協助小組去除可限制輸送量的管理員限制風險。 若要最佳化系統中的輸送量: - **偏好非同步處理**。Salesforce Platform 使用交易內容來控制資料完整性和限制逸出程式碼。請參閱「結構基本概念」中的「結構基本概念」中的「[交易」](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#交易)。因此,盡可能使用非同步 (非同步) 處理有助於儘量減少同步執行內容中的潛在瓶頸。請參閱 [資料處理](/docs/architect/zh-tw/well-architected/guide/automated#資料處理)。使用非同步運算並非每種效能問題的修復方法,且在整合非同步流程時,您必須考量延遲。某些平台功能 (例如可排列的 Apex) 可能會在流量高峰期間增加延遲,因為這些功能會造成訊息等候時間較長。視您的使用個案而定,您可以決定容忍回應性可能降低,以維持或改善輸送量。在其他情況下,您可能會決定無法接受延遲增加。透過規模測試,您可以透過在完整 Sandbox 中模擬流量高峰來驗證這些權衡。在其中,您可以測量工作如何影響輸送量和延遲。 - **一律使用大量處理**。在高層級上,大量處理表示針對集合執行作業。通常,討論 Salesforce 解決方案大量處理的小組會專注於針對集合簡化資料作業。請參閱 [作業邏輯](/docs/architect/zh-tw/well-architected/guide/automated#作業邏輯)。不過,系統層級的大量處理不僅僅涉及資料作業。也請將某些工作 (例如呼叫或複雜計算) 視為大量處理的候選項目。適當大量處理可減少額外負擔。它會透過一個要求執行多個作業,而非透過每個作業執行一個要求。ApexGuru 會呈現如 [DML 或 SOQL](https://help.salesforce.com/s/articleView?language=en_US&id=xcloud.apexguru_antipatterns.htm&type=5) 之類的防大量處理模式,您可以在調整為生產環境之前修正這些模式。請參閱 [大量作業](/docs/architect/zh-tw/fundamentals/guide/platform-multitenant-architecture#大量作業)。 - **使用 SOSL 進行搜尋,並將 SOQL 視為資料作業**。使用過於複雜的 SOQL 陳述式可能會顯而易見,這會增加系統所需的時間,以提取記錄。SOQL 會對[基本關聯式資料庫](/docs/architect/zh-tw/fundamentals/guide/platform-multitenant-architecture#平台資料層)增加負擔,使處理速度變慢。使用文字或萬用字元條件時,SOSL 的效能較高。SOSL 使用平台的搜尋引擎,其已針對全文索引和通用搜尋最佳化。若要最佳化記錄提取模式,請確定您的設計標準指定何時使用 SOSL 在系統中尋找資料。也請確保它們指定如何使用 SOQL 以有效率地進行資料作業。請參閱 [作業邏輯](/docs/architect/zh-tw/well-architected/guide/automated#作業邏輯))。 - **使用平台快取和 ApexGuru**。快取 Salesforce 工作階段與組織資料時,[Lightning 平台快取](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_namespace_overview.htm)層級提供更快的效能與更佳的可靠性。「平台快取」透過散佈快取空間來改善效能,讓某些應用程式或作業不會竊取其他應用程式的容量。ApexGuru 會偵測錯過的機會來快取重複的查詢 (例如,[SOQL 結果的平台快取](https://help.salesforce.com/s/articleView?id=xcloud.apexguru_antipattern_soql_without_platform_cache.htm&type=5)),進而改善大規模環境中的輸送量。 效能的 [模式和反模式](/docs/architect/zh-tw/well-architected/guide/reliable#效能模式與反模式)會顯示 Salesforce 組織中正確與不良的輸送量。使用這些選項可在您建立之前驗證您的設計,或識別進一步最佳化的機會。 若要深入瞭解 Salesforce 用於輸出最佳化的工具,請參閱可靠性的 [Salesforce 工具](/docs/architect/zh-tw/well-architected/guide/reliable#可靠性的-salesforce-工具)。 ### 延遲性 延遲是指系統完成執行路徑的速度。最佳化系統的輸送量有助於改善延遲。延遲的另一個維度是認知的效能,或系統對使用者有何回應。 人員不想要等待頁面載入或程序完成。如果系統的使用者在嘗試瀏覽清單檢視、記錄頁面、報告等時經常遇到較長的載入時間,則會感到沮喪。發生此情況時,客戶或合作夥伴可能會決定將業務移至其他位置,而非處理效能不佳的系統。在內部,員工可以建立因應措施來避免依預期使用系統,這會造成安全性和資料完整性的下游問題。 認知的效能可能難以診斷。當使用者報告效能變慢時,支援小組可能無法重現問題。延遲增加通常是相互依據的較小問題組合所造成,這會導致難以診斷所認知效能問題的確切原因。 若要減少 Salesforce 系統中的延遲並改善回應性: - **最佳化報告**。確保每個報告皆提供單一特定用途。清楚識別系統中每個報告的受眾和用途。在報告中,僅包含受眾成員進行決策所需的資料量下限。移除不符合報告用途的資料欄,可減少所需的資料量,藉此改善報告效能。 - **最佳化篩選條件**。有效的篩選條件可透過精確地定義從資料庫採取的列數範圍,來加速報告和清單檢視效能。一般而言,您設定篩選邏輯越具體,資料的基本查詢就越有效率。最佳化篩選的方法包括: - 使用「等於」和「不等於」,而非使用「包含」和「不包含」 - 避免依公式欄位篩選 - **簡化您的共用模式**。過於複雜的共用模式會使各種流程變慢,因為系統必須檢查共用與可視性模式,以判斷使用者是否可存取要顯示或處理的資料。複雜的共用計算會增加在使用者環境中執行的報告、清單檢視和自動化延遲。請參閱「[共用與可視性](/docs/architect/zh-tw/well-architected/guide/secure#共用與可視性)」。 - **最佳化自訂 UI 元件**。自訂建立的使用者介面 (UI) 元件可增加延遲。若要最佳化自訂 UI 元件的效能,請考慮執行下列動作。 - **使用 Lightning Web 元件 (LWC)**。LWC 架構與現代 Web 標準密切一致。在 LWC 中撰寫的自訂元件在網頁瀏覽器中更有效率地呈現,並讓開發人員能夠使用更具效能的 JavaScript 方法。務必使用 LWC,而非舊版 UI 技術,例如 Aura 或 Visualforce。 - **使用 Lightning Data Service**。Lightning Data Service 處理在元件之間建立及維護安全、高效且共用的快取。使用它可避免不必要的來回行程到伺服器取得資料,並提高整體應用程式回應性。 - **針對清單資料使用用戶端排序和篩選**。針對 LWC (偏好) 和 Aura 元件 (否則),開發人員可以使用標準 JavaScript 陣列功能來排序、篩選和選取用戶端的值,進而減少伺服器所需的行程數目。 [模式和反模式](/docs/architect/zh-tw/well-architected/guide/reliable#效能模式與反模式)顯示 Salesforce 組織中正確和不良延遲的外觀。使用這些選項可在您建立之前驗證您的設計,或識別進一步最佳化的機會。 若要深入瞭解 Salesforce 工具以最佳化延遲,請參閱可靠性的 [Salesforce 工具](/docs/architect/zh-tw/well-architected/guide/reliable#可靠性的-salesforce-工具)。 ### 效能模式與反模式 此表格顯示要在您的組織中尋找或建立的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/trusted-performance)探索更多效能模式。
模式 防模式
輸送量 在您的設計標準中:
- 如何使用平台快取的指引遵循 平台快取最佳作法
在您的設計標準中:
- 如果有平台快取使用指引,則其不明確或不符合最佳作法。
在您的組織中:
- 大量化用於資料和系統作業。
- DML 或資料庫方法一律會對應 Apex 中的集合。
- 資料庫中 DML 期間用於較短 elapsedTime 的欄位受到限制。
- 所有萬用字元條件都會用於 SOSL。
- SOQL 陳述式為選擇性。
-- 他們不使用 LIKE 比較或部分文字比較。
-- 比較運算子會使用正數邏輯 (換句話說,INCLUDES 或 IN) 作為其主要邏輯或僅限邏輯。
-- = NULL 和 != NULL 用於使用時,很少一律遵循正比較運算子。
– 為了儘量減少資料載入並發揮最大效能,系統只會在 SOQL 查詢中提取所需的欄位。
-- 未使用 LIMIT 1 陳述式。
-- 不使用「所有列」關鍵字。
- 盡可能偏好非同步處理。
- 已設定平台快取分割。
在您的組織中:
- DML 陳述式未大量處理。
- DML 或資料庫方法會對應 Apex 中的單一記錄。
- SOSL 並不常用於萬用字元選取條件。
- SOQL 陳述式為非選擇性:
-- 其中包含 LIKE 與萬用字元篩選條件。
-- 使用 !=、NOT 或 NOT IN 條件的比較會作為主要或唯一比較運算子使用。
-- 使用 = NULL 和 != NULL 條件作為主要或唯一比較運算子。
-- 使用 LIMIT 1 陳述式。
-- 使用 ALL ROWS 關鍵字。
- SOQL 會顯示在迴圈內。
- 偏好同步程序。
延遲 在您的組織中:
- 報告用於單一特定目的,且包含決策所需的最少列數與欄數。
- 篩選條件使用「equals」和「not equal to」。
- 篩選條件不包含公式欄位。
- 共用模式會盡可能簡化。
- 自訂 UI 元件使用 Lightning Web 元件 (LWC)。
- LWC 使用 Lightning Data Service 進行資料作業。
- 在 JavaScript 的用戶端處理排序和篩選清單資料。
- Salesforce Edge 已啟用。
在您的組織中:
- 報告可用於多種用途,或包含決策不需要的額外列與欄。
- 篩選條件使用「contains」和「does not contain」。
- 篩選條件包含公式欄位。
- 共用模式很複雜。
- 自訂 UI 元件使用的架構可能會導致呈現效率低於 LWC (例如 Aura 或 Visualforce)。
- LWC 使用 Apex 進行資料作業。
- 使用 Apex 在伺服器端處理排序和篩選清單資料。
- Salesforce Edge 未啟用。
## 延展性 延展性是指系統在演進與成長時能一致執行的能力。可調整的系統可處理交易量大幅增加或同時存取,而不會造成基本變更。Salesforce 的平台服務專為支援應用程式擴充性而設計。請參閱 [內部平台處理](/docs/architect/zh-tw/fundamentals/guide/platform-multitenant-architecture#內部平台處理)。不過,隨著您的組織成長,以及對您產品和服務的需求增加,您必須負責建立能夠有效執行且如預期般執行的系統。從一開始針對延展性進行結構設計,會隨著使用者流量增加而加快新功能的傳遞速度,並減少服務中斷。在設計階段早期,在將新功能部署至生產環境前,請使用「**規模測試」**來模擬預測的工作量,並驗證結構可以調整以支援工作量。 並非針對延展性設計的系統需要不斷且高成本的疑難排解、重新設計和重新設定。延展性會隨著時間產生複雜性,使整個系統的效能降低。在某些情況下,企業會發現大多數的開發和維護資源都花在解決延展性問題上,而不是在建立價值的新功能上。 有時候,公司會達到重要關鍵點。其系統的原始設計無法支援業務成長,而非預期的事件會使系統變得不穩定。使用來自 **Scale Center 的**洞察來提早識別延展性關鍵點。「規模中心」會呈現例外熱點、經過長時間的交易,以及隨著時間變得愈來愈嚴重的貨架瓶頸。 您可以專注於資料模型最佳化和資料量管理,進一步建立規模結構。 _注意:雖然此處未討論,但測試延展性是驗證應用程式結構的重要部分。如需指引,請參閱 [測試策略](/docs/architect/zh-tw/well-architected/guide/resilient#測試策略)。_ ### 資料建模 資料建模涉及建構您組織中的物件,並以讓您的使用者和自動化流程能夠盡快提取所需資料的方式彼此建立物件的關聯。採取步驟來[改善輸送量](/docs/architect/zh-tw/well-architected/guide/reliable#輸出)可解決許多效能問題,但如果沒有最佳化的資料模型,您的努力將不會如此有效。 設計不良的資料模型的負面影響並非立即明顯;系統在資料量、程序、使用者和整合方面成長時,系統會發現其劣勢。設計良好的資料模型可讓您隨著新增和擴充需求,輕鬆持續重新設定應用程式。**ApexGuru** 會呈現資料存取防模式,例如非選擇性 SOQL、未使用的欄位,以及直接影響資料模型的延展性結構描述效率不佳。 若要最佳化您的資料模型: - **使用 Salesforce** 的預先建立資料模型。Salesforce 提供銷售、服務和各種產業垂直的預先建立資料模型。使用 Salesforce 提供的資料模型可確保系統中的功能僅定義一次,進而消除冗餘與孤立狀況,並在整個系統建立單一事實來源。由於您針對該單一來源使用 Salesforce 預先建立的資料模型,因此透過分析更容易瞭解應用程式資料,並使用 Salesforce 的預先建立人工智慧服務。此外,減少您必須支援的自訂項目可降低維護成本並降低技術債務。 - **選擇正確的資料類型**。瞭解 Salesforce 支援的不同類型欄位及其限制。考量報告和加密需求,以避免未來需要在類型之間轉換資料。 - **選擇正確的關係**。Salesforce 支援兩種物件之間的關係:主要 - 詳細資料與對應。「主要 - 詳細資料」關係提供兩個主要優點。一種是內建的累計摘要功能,其會計算和彙總子系記錄的詳細資料。另一個功能是內建的串聯刪除功能,藉此刪除父系記錄也會刪除其子系記錄。但是,在決定使用「主要 - 詳細資料」關係之前,請確保您瞭解共用和資料誤差的[涵義](/docs/architect/zh-tw/well-architected/guide/reliable#資料量)。 - **反正規化以進行刻度。**正規化是建構資料模型的流程,以減少資料冗餘並改善資料完整性。很遺憾,正規化有時會造成規模問題。反正規化表格在規模上表現較佳,但請記得考量資料完整性和冗餘性。 [模式和反模式](/docs/architect/zh-tw/well-architected/guide/reliable#延展模式與防範模式)顯示 Salesforce 組織中正確與不良資料模型最佳化的外觀。使用這些選項可在您建立之前驗證您的設計,或識別進一步最佳化的機會。 若要深入瞭解資料模型最佳化的 Salesforce 工具,請參閱可靠性的 [Salesforce 工具](/docs/architect/zh-tw/well-architected/guide/reliable#可靠性的-salesforce-工具)。 ### 資料量 資料量是根據記錄計數與大小來測量儲存在系統中的資料量。如果您的組織有數十萬名使用者、數千萬筆記錄,或數百 GB 的記錄儲存空間,則表示您有大量資料。您組織中資料量與物件之間的關係會影響延展性,且對延展性可能會造成比單獨記錄數量更大的影響。 若要改善具有大量資料組織的延展性: - **散佈子系記錄**。透過確保沒有父系有大量子系記錄,以避免父系子系資料偏差。一般建議,任何父系都不應有超過 10,000 個子系記錄。例如,在擁有許多連絡人但未使用帳戶的部署中,請考慮設定數個帳戶記錄並在其中散佈相關連絡人記錄。 - **散佈記錄的擁有權**。若要避免擁有權偏差,請確保沒有任何單一使用者或排行榜擁有,也不確保單一角色或公用群組的所有成員擁有同一個物件中超過 10,000 筆記錄。「使用 dummy 使用者」的「停車」資料通常會導致擁有權偏差。如果您遇到此問題,請注意其對 [共用計算](/docs/architect/zh-tw/well-architected/guide/reliable#延遲性)的影響。如果您無法重新散佈記錄以減輕擁有權偏差,請避免將資料擁有者指派給角色。如果您組織的共用模式需要角色指派,請將資料擁有者以不同的角色放置在共用階層的頂端。請勿允許該使用者角色的頻繁或非預期的變更,因為任何變更都會因為共用重新計算而造成顯著的效能影響。將該使用者保持在可在任何共用規則中參照的公用群組之外。 - **減少 Salesforce 中的記錄資料量**。Salesforce 的設計目的為提供公司客戶的單一檢視。限制 Salesforce 中的資料是最佳作法,可能會看起來反直覺。不過,單一檢視的強大功效在於讓業務使用者瞭解並對客戶資料採取行動。隨著資料量增加,與日常流程或分析無關的資料會造成數個問題。這些問題包括應用程式效能降低、資料安全性增加的風險,以及對搜尋、報告和分析的負面影響。若要避免此類問題,請針對資料模型中的每個物件定義資料生命週期,其中包含資料的時間表和分類 (隨著資料的過時與失去立即業務價值)。根據資料生命週期,實作這些程序來隨時間管理資料。 - **資料歸檔與清除**-若要盡可能將資料量保持在最低的狀態,請移除業務不需要的記錄,以協助將資料量保持在最低的狀態。使用大量 API 2.0 的實刪除功能來刪除大量資料。 - **資料彙總 -** 以與報告相容的格式建立彙總自訂物件,以摘要主要歷程記錄趨勢或摘要資料。使用 [批次 Apex](/docs/architect/zh-tw/well-architected/guide/reliable#輸出) 填入自訂物件。然後,使用者可以根據彙總的物件記錄執行報告。 - **資料層級**。如果 Salesforce 報告或日常工作不需要大型資料集,請在不同的應用程式中維護該資料集。視需要透過 mashup、呼叫或外部物件在 Salesforce 中提供資料。 在實際上,您可能無法在發生問題時立即解決延展性問題的根本原因。因此,Salesforce 提供可協助減輕立即痛點的選項。請務必瞭解,在您的組織中啟用這些功能並非處理大量資料的可行長期結構策略。這些短期停機因應措施可協助降低受資料結構不良影響的系統延遲,但也可為您的組織增加技術負債。 規模問題的短期因應措施包括: - 「**自訂索引**」索引會儲存在平台的查詢最佳化程式用來加速資料存取作業的特殊內部表格中。請參閱 [多租戶索引](/docs/architect/zh-tw/fundamentals/guide/platform-multitenant-architecture#索引))。平台依預設會自動索引特定類型的欄位。若要加速效能不佳的查詢,您可以連絡 Salesforce 客戶支援,以要求額外的自訂索引。使用「查詢計畫」工具判斷自訂索引是否可改善查詢的效能。 - ** Skinny 表格**。如果您需要進一步最佳化對超過 1 百萬筆記錄物件上常見欄位集的查詢,則精簡表格可提供協助。精簡表格可免除在報告或自動化中使用來自相同物件的自訂和標準欄位時發生的[背景聯結](https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_skinny_tables.htm)。若要使用精簡表格,Salesforce 客戶支援必須為您的組織啟用這些表格。 延展性的[模式和反模式](/docs/architect/zh-tw/well-architected/guide/reliable#延展模式與防範模式)顯示 Salesforce 組織中正確與不良資料量管理的外觀。使用這些選項可在您建立之前驗證您的設計,或識別進一步最佳化的機會。 若要深入瞭解用於管理資料量的 Salesforce 工具,請參閱可靠性的 [Salesforce 工具](/docs/architect/zh-tw/well-architected/guide/reliable#可靠性的-salesforce-工具)。 ### 延展模式與防範模式 這會顯示要在您的組織中尋找或建立的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/trusted-scalability)探索更多可調整的模式。
模式 防模式
資料建模 在您的設計標準中:
- 商業理由保證自訂物件存在的標準和指引。
在您的設計標準中:
- 沒有建立自訂物件的標準存在。
在資料模型中:
- 盡可能使用標準物件。
- ApexGuru 檢查是否有防模式,確認 SOQL 查詢是選擇性的,並避免結構描述使用效率低下。
- 表格會針對刻度反正規化。
在資料模型中:
- 您已複製標準物件。
- 表格已正規化以避免冗餘。
在您的業務中:
- 低程式碼產生器會瞭解 Salesforce 支援的不同欄位類型,並在選取欄位資料類型之前評估報告和加密需求。
- 決定在物件之間建立「主要 - 詳細資料」關係之前,請評估該關係的共用與資料誤差影響。
在您的業務中:
- 低程式碼產生器會選取資料類型,而無須評估下游報告和加密需求。
- 決定在物件之間建立「主要 - 詳細資料」關係之前,請勿評估該關係的共用與資料誤差影響。
資料量 在您的資料中:
- 沒有父系記錄具有超過 10,000 個子系記錄。
- 未將使用者指派給相同物件類型的超過 10,000 個記錄。
- 沒有例項包含指向相同記錄的對應欄位超過 10,000 個記錄。
- 大量資料載入會根據 ParentId 欄位值排序為批次。
- 為了確保批次策略不會同時損毀,規模測試用於驗證生產規模的大量負載模式。
- 大量資料載入至生產環境不會在營業時間高峰期間發生。
- 大量資料載入僅包含業務決策所需的最小資料。
在您的資料中:
- 存在超過 10,000 個子系記錄的記錄。
- 系統會將使用者指派給相同類型的超過 10,000 個記錄。
- 存在超過 10,000 筆記錄具有指向相同記錄之對應欄位的例項。
- 大量資料載入不會根據 ParentId 欄位值進行批次排序。
- 大量資料載入至生產環境會在營業時間高峰期間發生。
- 大量資料載入不限於業務決策所需的最少資料。
在流程與 Apex 中:
- 在資料誤差有疑慮的情況下,邏輯存在於跨多個父系記錄散佈子系記錄數目。
- 當透過整合匯入或複製記錄時,邏輯會將記錄指派給適當的人類使用者。
- 針對 Apex 集合 (例如清單和集),存在處理多個記錄的邏輯,以將查詢最小化並最佳化資料處理。
- 撰寫和部署符合可調整程式碼標準和最佳作法的有效 Apex 程式碼。
在流程與 Apex 中:
- 無論已指派的子系記錄數目為何,子系記錄都會隨意指派給父系記錄。
- 透過資料載入或整合建立的記錄會指派給一般「整合使用者」。
- 來自相同物件的多個遞迴 SOQL 查詢在同步交易中,進而造成高堆疊使用量。
- 開發人員撰寫 Apex 程式碼時,會導入效率低下和效能反模式。
在您的業務中:
- 您已記錄並實作資料歸檔和清除策略
在您的業務中:
- 您沒有資料歸檔和清除策略,或者您的策略已記錄但未實作
## 可靠性的 Salesforce 工具
工具描述可用性績效延展性
大型物件 在平台上儲存及管理大量資料。 X
程式碼掃描器 掃描 Apex 程式碼以瞭解效能問題。 X
自訂索引 使用自訂索引改善查詢效能。 X
刪除資料 移除不需要的資料以改善效能。 X X
分部 分割資料以限制查詢和報告中的記錄數。 X
規模測試 測試系統效能並解譯結果。部署至生產環境之前,若要驗證延展性和效能,請使用 Playwright 或 JMeter 指令檔模擬大規模的 UI 和 API 工作量。 X X
規模中心 取得有關系統效能的自助式服務和即時洞察。尋找長時間執行的交易、例外熱點和輸出瓶頸。在開發週期中稍早診斷規模問題。 X X
ApexGuru 在「刻度中心」中使用此以 GenAI 為基礎的功能,以在執行階段偵測 Apex、SOQL 和測試類別的反模式。透過 ApexGuru 與 Salesforce Code Analyzer 的整合,在開發工作流程中取得 AI 強化的建議和內嵌修正。使用這些建議和修正程式可解決熱點,並改善查詢選擇性、大量處理、快取用量和測試品質。 X X
Salesforce 程式碼分析器 使用 IDE、CLI 或 CI/CD 掃描程式碼,以確保程式碼符合最佳作法。透過 Salesforce Code Analyzer 與 ApexGuru 的整合,直接在開發人員工作流程中取得效能反模式的相關洞察。 X
Salesforce Edge 網路 透過 Salesforce Edge 網路路由您的 我的網域,以改善下載時間和使用者體驗。 X
Skinny 表格 避免在經常使用欄位的表格上加入。 X
主動監視 持續監視記錄成長、擁有權偏差和效能迴歸的異常。在規模問題變為嚴重之前警示。 X X
## 可靠性的 Salesforce 資源
資源描述可用性績效延展性
規模化挑戰需要數百萬美元 — 以下是如何讓業務展望未來 探索實作延展性如何促成永續成長和長期成功。 X X
使用「規模中心」建立及部署可調整應用程式 瞭解如何主動評估並解決 Salesforce 實作中的效能問題。
分析複雜 Salesforce 應用程式中的效能與規模熱點 處理您組織中的效能與延展性問題。 X X
應用程式不應在熱門時段的流量中驚慌 - 準備方式如下 瞭解成功規模測試的四個關鍵步驟。
已解釋 ApexGuru AI 引擎 瞭解 ApexGuru 如何使用自訂訓練的模型、實際組織遙測和智慧篩選,以提供精確、內容相關且可運作的洞察。 X X
使用 ApexGuru 最佳化應用程式和 Agentforce 的 Apex 瞭解 ApexGuru 如何協助開發人員偵測和修正效能反模式,包括 SOQL、DML、除錯和測試效率不佳。使用 ApexGuru 作為 AI 技術支援的教練,以擴充應用程式的開發和 Agentforce 的實作。 X X
ApexGuru 反模式 從 ApexGuru 偵測到的反模式官方文件庫中學習,此文件庫會針對每個主要 Salesforce 版本更新。 X X
使用大量資料進行部署的最佳作法 瞭解大量資料的流程影響。 X
Salesforce Edge 網路的 考量事項 瞭解如何讓您的組織準備好使用 Salesforce Edge 網路。 X
設計標準範本 為您的組織建立設計標準。 X X X
資料模型設計考量事項 最佳化規模與維護的資料模型。 X X
針對企業規模設計記錄存取權 透過組態最佳化存取控制效能。 X
具有大量資料系統的基礎結構 瞭解支援大型資料部署之系統效能的功能。 X
批次管理的學習資源 瞭解批次管理。 X X
Lightning Experience 效能最佳化 改善您組織中的 Lightning Experience 以協助您的使用者加速工作。 X
在 Salesforce 中管理對應誤差以避免記錄鎖定例外 瞭解如何將對應誤差的影響降到最低。 X X
SOQL 與 SOSL 最佳作法 針對具有大量資料的部署,遵循 SOQL 與 SOSL 最佳作法。 X X
大規模重新對齊方式的工具 有效率地計畫並執行重新對齊。 X
使用遮蔽 在不同的應用程式中維護大型資料集。 X X
## 告訴我們您的想法 協助我們讓 Salesforce Well-Architected 與您相關;進行我們的[調查](https://sfdc.co/bxNtvh)以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。 > [在此](/docs/architect/zh-tw/well-architected/guide/contributors)閱讀我們的更新排程。 法律免責聲明:此文件僅散佈為資訊用途,不構成法律建議,不應作為此類建議使用。 ## 簡介 合規性系統的設計目的為遵循適用的法律與道德指導方針,其符合度既可測量又可稽核。藉由將資料存取權限限制為已授權的個人,以達成預期的目的,遵循相關法律法規,並確保所有已授權的使用者均能存取。 主動措施對於防止和偵測違規而言至關重要。對法規和標準的反應性方法可能會破壞客戶的 Trust,特別是當變更只會因應客戶的要求或抱怨而發生。這類的抱怨會損害您組織的品牌和聲譽,並導致收入損失。 您可以透過專注於三個關鍵習慣來在 Salesforce 解決方案中建立合規性:法律符合度、道德標準和無障礙功能。 ## 法律符合度 遵循法律要求涉及遵循地區法律和產業法規。身為結構設計師,當您組織的法律團隊或第三方稽核員決定了特定合規性需求後,您有責任瞭解這些需求,並在設計流程中主動識別並標記潛在合規性問題,以降低罰款和訴訟的風險。 您可以透過資料隱私權與本地化改善 Salesforce 解決方案的法律符合度。 ### 資料隱私權 資料隱私權涵蓋您的解決方案如何收集、儲存和處理個人可識別資訊 (PII),以及相關法規和個人控制其個人資料存取權的能力。遵循這些法規可能需要更新您的[共用與可視性模型](/docs/architect/zh-tw/well-architected/guide/secure#共用與可視性)、修改中繼資料組態以限制存取、實作欄位級加密、監視記錄和事件、建立自動化以根據要求匯出或刪除客戶的資料,以及開發管理自動化和 AI 中資料使用的原則。 不遵循資料隱私權法規可能會導致嚴重的罰款和訴訟。此外,由於控制權不足或安全性缺口而揭露利害關係人資料,可能會導致收入遺失和客戶 Trust 損毀。 當您努力確保符合資料隱私權需求時,請考量下列事項: - **諮詢監管專家**。與您的法律小組或第三方稽核員合作,評估適用於您業務的產業特定合規性法規。例如,醫療照護公司必須遵循「健康保險流通與責任法」(HIPAA)。 - **分類您的資料**。資料分類可協助專案小組瞭解貴組織中各種資料元素何時可或無法使用。它也讓您的企業能夠對資料管理原則合規性進行[報告](https://help.salesforce.com/s/articleView?id=sf.data_classification_report.htm&type=5)。透過指定[欄位層級](https://help.salesforce.com/s/articleView?id=sf.data_classification_intro.htm&type=5)的適用法規來分類您組織中的資料,以瞭解擁有者是誰、敏感度層級,以及欄位是否正在使用中。 在分類流程期間,請務必考量資料模型中的所有欄位可能會如何使用,而不是僅考量一目瞭然這些欄位很敏感的欄位。在某些情況下,看似不連續的欄位如果用於錯誤的內容,就會變成敏感欄位。例如,美國的郵遞區號可以是競爭的代理,因此如果用於預測模式,可能會無意中增加偏見或造成傷害。名稱可用來預估性別、來源國家、種族、宗教,甚至是年齡,因為受歡迎的名稱往往會從一代變更。在您的文件中包含所有欄位的分類,以及任何相關聯 AI 功能將如何使用這些欄位的明確描述。 使用如 [資料偵測](https://help.salesforce.com/s/articleView?id=sf.einstein_data_detect.htm&type=5) 等工具來識別組織內的敏感資料。如果欄位分類為敏感,或如果您知道哪些欄位是敏感的,則如 Einstein 內容選取等工具也會識別具有 [高度關聯](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.mc_pb_manage_einstein_content_selection_attributes_and_bias.htm)的欄位,因此可以是這些敏感欄位的代理。 - **建立資料管理的最佳作法**。確保所有相關文件皆已完成、處於最新狀態且集中儲存,使其可供所有利害關係人輕鬆使用。這將為您的組織新增一層保護,避免法律責任,同時維持對客戶和合作夥伴的 Trust。例如,資料字典會記錄儲存在您系統中所有資料元素的物件和欄位級定義和分類、設計文件包含您建立以遵循法規的任何自動化的詳細資料,以及安全性矩陣概述資料使用者可存取的內容。重要的是,此全方位文件會成為「取得增強產生」(RAG) 的權威來源,直接將 Agentforce 等代理程式系統奠基於經過驗證且符合的作業環境中,從而避免產生不一致或虛擬的輸出。 以下的[模式與反模式](/docs/architect/zh-tw/well-architected/guide/compliant#法律符合度模式與反模式)清單顯示 Salesforce 解決方案內的正確 (與不良) 資料隱私權管理外觀。使用這些功能可在您建立之前驗證您的設計,或識別需要重新設計的系統區域。 若要深入瞭解資料隱私權的 Salesforce 工具,請參閱符合[相關的工具](/docs/architect/zh-tw/well-architected/guide/compliant#符合的相關工具)。 ### 本地化 本地化是指調整產品以符合特定語言、文化和所需的本地美感。這也包括適應區域特定的法規,例如資料落地法規,這些法規會因國家/地區甚至城市而有所不同。因此,您的系統可能需要滿足多個法規架構,端視客戶的所在位置以及貴公司將產品和服務推向市場的方式而定。 除了資料隱私權法律的變化以外,許多國家也正在制定資料落地法律。資料落地法律至少需要將與國家/地區公民相關的所有資料實際儲存在該國家/地區的邊界內。某些法律進一步,要求在本機儲存公民可能可存取的所有資料 (包括與產品和服務相關的資料)。在某些情況下,法規要求只有該國家或地區的其他公民才能維護公民資料。 不合規可能會導致大額罰款和訴訟。例如,歐盟的資料保護主管機關可能會處以最高 €20 百萬或全球收入 4% 的罰款,視何者較高。在美國,加州檢察長辦公室可針對有意與無意的違規要求嚴重懲罰。 請考量下列事項以進一步管理本地化與資料落地需求: - **諮詢監管專家**。與您的法律小組或第三方稽核員合作,評估您業務營運區域中的法律,以判斷哪些法律適用。範例包括歐盟通用資料保護規則 (GDPR) 和歐盟 AI 法,以及加州消費者隱私法 (CCPA)。 - **在本機儲存資料**。確保區域特有的資料會保留在其獨立的組織中。使用 Salesforce 的公用雲端基底 [Hyperforce](https://help.salesforce.com/s/articleView?id=000356459&type=1) 在特定區域中主控您的組織。 - **避免資料複寫**。本機資料儲存表示資料儲存在國家/地區的*靜態位置*;當然,當資料透過標準介面傳輸至國家/地區以外時,可能會發生合規性問題。例如,在本機建立和維護記錄,但將記錄複製到其他國家/地區的資料倉庫進行報告,會違反資料落地法律。如果您為具有跨區域報告需求的全球企業工作,請先彙總儲存資料所在國家內的資料、移除所有可能識別與其相關聯之公民的資訊,然後僅複製彙總資訊。此方法可能需要您向利害關係人傳達報告限制,讓他們知道雖然在國家或地區層級會有更精確的資料,但只有摘要資料會在全域提供。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/compliant#法律符合度模式與反模式)清單顯示 Salesforce 解決方案內的正確 (與不良) 本地化與資料落地處理流程呈現的外觀。使用這些功能在您建立之前驗證您的設計,或識別需要重新設計的區域。 若要深入瞭解本地化的 Salesforce 工具,請參閱符合[相關的工具](/docs/architect/zh-tw/well-architected/guide/compliant#符合的相關工具)。 ### 法律符合度模式與反模式 下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/trusted-legal-adherence)探索更多符合法律的模式。
模式 防模式
資料隱私權 在您的文件中:
- 您擁有包含欄位層級名稱、描述和分類的最新資料字典
- 您擁有可識別哪些使用者可存取哪些資料的最新安全性矩陣
- 您擁有最新的設計文件,包括針對建立以滿足法規需求的任何自動化的標準和圖表
在您的文件中:
- 資料字典不存在或尚未保持最新狀態
- 共用與可視性文件不存在或尚未保持最新狀態
- 針對解決法規需求的自動化設計標準、圖表和文件不存在或尚未保持最新狀態
在您的組織中:
- 所有包含敏感資訊或受資料隱私權法規約束的物件和欄位都已設定「合規性種類」、「資料擁有者」、「資料敏感度等級」和「欄位用量」
在您的組織中:
- 包含敏感資訊或受資料隱私權法規約束的物件和欄位缺少「合規性種類」、「資料擁有者」、「資料敏感度等級」或「欄位用量」的組態
本地化 在您的文件中:
- 您擁有概述資料儲存和維護位置的組織策略,以符合所有適用的資料落地需求
- 您擁有整合策略,此策略概述跨境複製資料的可接受案例與流程
- 您擁有概述報告和顯示面板在區域、國家和全球層級可包含的細微性層級分析策略
在您的文件中:
- 您沒有組織策略,或者您的組織策略未滿足資料當地語系化與落地需求
- 您沒有整合策略,或者您的整合策略未滿足資料當地語系化與落地需求
- 您沒有分析策略,或者您的分析策略未滿足資料當地語系化與落地需求
## 道德標準 在業務環境中,道德標準是公司和個人從以價值為基礎或道德觀點進行行為的方式的原則。在 Salesforce,[我們的核心價值](https://trailhead.salesforce.com/content/learn/modules/salesforce-culture-and-values/explore-salesforce-culture-and-values)會引導我們作為公司和員工所做的一切。我們也有 [道德使用原則](https://www.salesforce.com/company/intentional-innovation/ethical-use-policy/)小組,可協助確保客戶以道德方式使用我們的軟體。我們的「[可接受使用原則」(AUP)](https://sfdc.co/AUP) 和「[AI 可接受使用原則」(AI AUP)](http://sfdc.co/AI-Policy) 是我們核心價值的延伸,在使用情況出現問題時有助於引導我們的決策。 您的組織可能有額外的一組原則,其範圍超出僅限遵循當地法規。這些原則可採取各種形式,包括遵循其他區域的法規、拒絕與特定組織或市場進行業務往來,或監視員工-客戶互動以防止歧視或偏見行為。若要維護這些原則,您可能需要更新設計標準或系統組態,以確保符合[法律](/docs/architect/zh-tw/well-architected/guide/compliant#法律符合度)要求。 若要促進 Salesforce 解決方案中更符合道德標準,請符合公司原則並評估您對人工智慧的使用。 ### 公司原則 公司原則是指南,定義業務的各個層面 (包括人員、流程和技術) 應如何運作。客戶偏好與他們 Trust 的組織進行業務往來。大多數的公司原則都設計為反映此原則。如果您的系統建立不符合您所述原則的使用者體驗,則客戶 Trust 會快速損毀。 有效的政策自然來自於[道德文化](https://www.salesforce.com/blog/new-research-ethical-leadership-business/)。每個員工 (從工程和設計到資料科學、行銷和銷售) 都必須接受道德使用的責任教育。在這種文化中,員工會看到明確的獎勵結構來獎勵道德行為,以及明確且一致的不道德行為後果。 請考量下列事項,以確保您組織的原則會反映在您的設計中: - **注意非預期的後果**。身為結構設計師,您有責任預期解決方案的潛在影響及其使用方式。不要陷入只考量或測試快樂路徑的陷阱。請改用您在測試邊緣個案和評估權衡方面的專業知識,以徹底考量解決方案的道德涵義。請思考每個人都會受到產品影響,特別是呈現性不足、邊緣化或易受影響的人員。評估某人或某些人可能與您的解決方案互動並造成非預期的後果的方式。使用「[建立意圖」工具組](http://sfdc.co/BuildwithIntention)來設計並謹記包容性。 - 將**道德內嵌在您公司的可接受使用原則中**。請與您的法律小組或第三方合作,在您的可接受使用原則中包含道德,以確保解決方案的使用符合您公司的價值。您的文件應包含關於您的解決方案支援貴組織哪些值與原則的資訊,無論是使用低程式碼或專業程式碼工具開發。發佈可接受的使用原則,以顯示您對與員工和客戶建立 Trust 的承諾。 - **使用無障礙語言**。瞭解人員體驗解決方案的不同方式,並在使用者介面、程式碼和文件中[限定語言](https://www.salesforce.com/news/stories/salesforce-updates-technical-language-in-ongoing-effort-to-address-implicit-bias/),以更準確地反映包容性。首先識別並移除獨占語言,然後認可瞭解可能導致排除的習慣或作法類型。 下方的[模式與反模式](/docs/architect/zh-tw/well-architected/guide/compliant#道德標準模式與反模式)清單顯示 Salesforce 解決方案中符合公司原則的適當 (和不良) 程度。使用這些功能在您建立之前驗證您的設計,或識別系統中需要重新設計的區域。 若要深入瞭解 Salesforce 工具以讓設計與公司原則保持一致,請參閱符合[相關的工具](/docs/architect/zh-tw/well-architected/guide/compliant#符合的相關工具)。 ### 人工智慧 人工智慧使用運算系統來執行通常需要人類智慧的工作,例如推理、認知和決策。Salesforce 平台 AI 功能涵蓋預測、生成和代理技術,提供全方位的工具套件來增強客戶體驗和業務營運: - **預測 AI** 會分析歷史資料並預測未來成果,例如銷售趨勢或客戶流失。Einstein AI 會透過分析資料中的模式來提供這些洞察,以提供建議並預估業務成果。 - **生成式 AI** 專注於利用大型語言模型來建立新內容。Einstein GPT 是與您的 CRM 資料搭配使用的核心元件,可產生個人化內容,例如電子郵件、聊天回應和客戶通訊。 - **工作人員 AI** 能夠讓工作人員自主思考並採取行動以達成特定目標,進一步提升 AI。Agentforce 是建立這些智慧工作人員的平台,可自動化複雜的業務流程,例如解決客戶個案或最佳化行銷活動。這些工作人員可以透過 Data 360 與資料即時互動,並利用現有的工作流程和 API。所有這些 AI 功能均受 Einstein Trust 層保護,以確保使用道德。 大多數 Einstein AI 的核心演算法無法設定,但針對某些功能,客戶可以使用自己的資料來微調模型,如文件中所述。此外,您可以透過「取得增強型奠基」(RAG) 將 AI 模型奠基在自己的 CRM、Knowledge 庫文章和其他文件中,讓輸出更為適合您的組織、客戶和使用個案。不過,如果您的基本資料有偏見或誤差,您的輸出也可能會變成偏見且不準確。偏差的範例是不要將特定種族、性別或族裔的成員包含在您的連絡人清單中,即使您的客戶群是多元化且包含該群組的成員。如需詳細資訊,請參閱 Salesforce [負責建立 AI Trailhead 模組](https://trailhead.salesforce.com/en/content/learn/modules/responsible-creation-of-artificial-intelligence)、[瞭解信任代理 AI Trailhead](https://trailhead.salesforce.com/content/learn/modules/trusted-agentic-ai)、[AI 道德成熟度模型](https://www.salesforceairesearch.com/static/ethics/EthicalAIMaturityModel.pdf)、Salesforce 的 [信任 AI 原則](https://www.salesforceairesearch.com/trusted-ai)、[負責產生 AI 原則](https://www.salesforce.com/news/stories/generative-ai-guidelines/),以及 [負責代理 AI 原則](https://www.salesforce.com/news/stories/responsible-agentic-ai-guidelines/)。 不考慮適用的法律法規和您公司自己的道德標準可能會導致 AI 中的偏見,導致訴訟、收入損失、客戶 Trust 問題,以及對您公司的公眾形象造成損害。 以下是負責任且有道德地使用 AI 的考量事項: - **檢查資料集與文件**。確保您的資料集代表您 AI 功能會影響的每個人。這可能需要使用者研究來瞭解他們是誰,並確認您的資料準確地呈現他們,以減輕任何潛在偏見。檢閱 CRM 資料、Knowledge 文章和您建立模型的任何其他文件,以確保其為最新、準確且完整,也是非常重要的。將模型奠基在大量資料中並不有幫助,如果資料是舊、矛盾或不完整,則可能會導致幻覺。 - **[控制人類](https://www.salesforce.com/news/stories/human-at-the-helm/)**。您不希望人類介入每個個別 AI 互動,而是讓員工專注在最需要關注的嚴重判斷項目。測試您的 AI 系統,直到您確信其可以負擔更多責任並監視成果,以確保其繼續準確且有效地工作為止。並確保您的 AI 系統或工作人員已指示針對高風險使用個案及 AI 的信賴層級低時,將其升級為人類。 - **排定模型輸出與成果**的安全性優先順序。執行偏差、可解釋性和穩定性[評估](https://www.salesforce.com/news/stories/developing-ethical-ai/),以及 [道德紅色團隊](https://www.salesforce.com/blog/red-teaming-ai/)。透過工作人員針對用於訓練的資料中任何個人身分識別資訊 (PII) 的回應和動作,來排定隱私保護的優先順序,並建立護欄以避免其他傷害。如果您在測試時發現有害結果,請將指示新增至系統提示和重新測試。您可能還需要改善您用於取得增強型產生 (RAG) 的資料品質或代表性。 - **為法規做好準備**。除了對 AI 的道德考量之外,許多政府已通過或正在通過法律,以規範在其管轄範圍內營運的組織使用 AI。此法律可能包含發佈模型卡的需求,其中說明 AI 解決方案的建立與運作方式。在實作以人工智慧為基礎的解決方案之前,請先瞭解哪些類型的 AI 相關功能在系統使用的區域中可以接受或不接受,並對策略進行任何必要的調整。您可能需要停用某些區域中的某些功能,以遵循當地法規;若是,請確保您的系統可以繼續運作,但沒有這些功能。當客戶或使用者與 AI 系統互動時,許多管轄區也需要透明度。 - **監視您組織的 AI 模型**。受影響的使用者應知道 AI 何時已使用,並有機會輕鬆報告損害並要求補救。請務必注意,僅報告可能無法判斷您的 AI 功能是否會對使用者造成傷害。持續監視您的模型是否有資料漂移、公平/偏差分數的變化、準確性和穩定性。確定您已具備計畫來[處理品質警示](https://help.salesforce.com/s/articleView?id=sf.bi_edd_quality_alert.htm&type=5),並在發現負面影響時快速回應。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/compliant#道德標準模式與反模式)清單顯示 Salesforce 解決方案內的適當 (與不良) AI 設計外觀。使用這些功能可在您建立之前驗證您的設計,或識別需要重新設計的系統區域。 若要深入瞭解實作更為道德 AI 原則的 Salesforce 工具,請參閱符合[相關的工具](/docs/architect/zh-tw/well-architected/guide/compliant#符合的相關工具)。 ### 道德標準模式與反模式 下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/trusted-ethical-standards)探索更多道德標準的模式。
模式 防模式
公司原則 在您的設計標準中:
- 標準包含受到公司原則影響之區域的明確指引
在您的設計標準中:
- 設計標準不存在或不提供關於受公司原則約束之區域的明確指引
在您的文件中:
- 組態和自訂的文件包含對支援公司值的參照
在您的文件中:
- 組態和自訂的文件未參照公司值或原則
在您的組織中:
- 所有受公司原則相關合規性的物件和欄位都已設定「合規性種類」、「資料擁有者」、「資料敏感度等級」和「欄位用量」
在您的組織中:
- 物件及受公司原則相關合規性的物件缺少「合規性種類」、「資料擁有者」、「資料敏感度等級」或「欄位用量」的組態
人工智慧 在您的設計標準中:
- AI 應用程式的原則和已批准使用個案清楚且容易找到
- 確保用於 RAG 的資料和文件具有代表性、完整、準確且處於最新狀態。尋找可能存在於資料集或文件中的偏差、有毒和其他有害內容
- 生成回應一律識別 AI 模型所使用的資料來源
- 已記錄可/無法用於提示工程的資料集
- 使用者可以清楚識別機器人和生成式 AI 回應
- 清楚定義生成式 AI 何時及如何使用免責聲明的標準
- 清楚說明如何記錄存在 AI 解決方案設計中人類參與點的需求
- 已存在記錄 AI 解決方案設計中直接與間接回饋意見路徑的標準
- 清楚定義使用者必須識別 AI 的點數
- 管理人類,特別是在受監管或高風險使用個案中
在您的設計標準中:
- 設計標準不存在或不包含 AI 應用程式的明確原則和已批准使用個案
- 生成回應不會識別 AI 模型使用的資料來源
- 未記錄用於提示工程的資料集
- 使用者無法識別機器人和生成式 AI 回應
- 遺失有關生成回應的免責聲明
- 不存在記錄 AI 解決方案設計中人類參與點的需求
- 不存在記錄 AI 解決方案設計直接與間接回饋意見路徑的標準
- 設計標準無法指出必須向使用者識別 AI 的點
在您的文件中:
- 涉及 AI 功能的組態和自訂文件包含所有程序邏輯的完整描述,並儲存在由法律小組或稽核員可存取的集中位置中
- 您建立或帶入 Salesforce 的模型會清楚記錄,包括任何適用的資料區段
- 系統會完整記錄對話邏輯和工作人員對話
- 已有程序可監視您組織的 AI 模型,以瞭解資料漂移、公平性和偏差分數的變更、準確性和穩定性
- 系統會針對用於所有 AI 流程的訓練、評估和測試資料維護描述
- 系統會維護任何 AI 相關資料清除的描述,以及偏差測試、相關聯的結果和效能/準確度分數 (例如 F1 分數)
在您的文件中:
- 涉及 AI 功能的組態和自訂文件遺失、不完整或儲存在無法存取的位置
- 在您的組織中實作 AI 模型或系統時,沒有其模型的文件
- 在您的組織中實作工作人員,沒有訊息和交談流程的文件
- 不存在或未記錄 AI 監視流程
- 關於所有 AI 流程所使用訓練、評估和測試資料的資訊不明確或無法使用
- 有關 AI 相關資料清除、偏差測試和結果的資訊不明確或無法使用
## 無障礙 技術中的*無障礙*是指針對具有不同能力的人員,系統或解決方案的可用性。在某些地點和產業中,設計適用於所有使用者的系統,無論能力為何都是法律要求。除了法律需求之外,建立無障礙系統有助於您的組織培養並增強利害關係人的 Trust。針對面向客戶的應用程式,這甚至會增加收入,因為客戶可能選擇使用您的系統,而非較不容易存取的替代方案。 Salesforce 會發佈「[無障礙合規性報告」(ACR)](https://www.salesforce.com/company/legal/508_accessibility/),這是業界標準文件,詳細說明我們的軟體如何符合無障礙標準。我們的大多數以 UI 為基礎的控制項,包括 Lightning Web 元件和 Experience Cloud 範本,都專為遵循這些標準而設計。雖然我們的基準無障礙功能可能適用於許多企業,但在開始任何專案前,請務必先檢閱我們的 ACR 與版本注意事項。這將協助您識別並記錄超出我們標準的任何額外無障礙需求,端視您產品或服務的上市方式而定。 您可以透過專注於資料輸入和瀏覽的兩個關鍵區域來改善系統的存取能力。 ### 資料項目 資料輸入活動會在使用者需要將資訊輸入至欄位、表單或使用者介面的其他部分時發生。雖然鍵盤與滑鼠是最常見的輸入方法,但某些使用者可能依賴語音轉文字或類似裝置。此外,您的使用者可能會以不同的語言通訊。 未針對無障礙設計的解決方案可能會排除具有特定身心障礙的個人與其互動。 設計無障礙功能時,請考量下列事項: - **您使用者偏好的語言**。視您的業務營運地點而定,您可以決定為系統設定單一標準語言,或想要提供多國語言功能。如果以多種語言顯示文字,您的設計標準應包含需要翻譯的欄位標籤清單和其他 UI 元素 (例如通知和錯誤訊息)。與原生發言者互動以檢閱翻譯的準確性和意義。將 Salesforce [翻譯功能](https://help.salesforce.com/s/articleView?id=sf.workbench_overview.htm&type=5)用於即時中繼資料和資料翻譯,並全面測試所有多國語言功能。 - **將使用的輸入裝置類型**。在您的設計標準中,列出可用於在標準鍵盤與滑鼠以外資料輸入的任何工具。在測試計畫中包含無障礙測試,並確定所有輸入都使用多種類型的輸入裝置進行測試。 - **表單的可用性**。確保表單包含可見的標籤、提供實用的錯誤訊息、引導使用者完成、通知使用者其進度,並讓他們檢閱、確認和編輯其輸入。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/compliant#無障礙模式與反模式)清單顯示當正確 (且不正確) 針對 Salesforce 解決方案內的無障礙功能設計時,資料輸入的外觀如何。使用這些功能在您建立之前驗證您的設計,或識別系統中需要重新設計的區域。 若要深入瞭解可建立更無障礙資料項目的 Salesforce 工具,請參閱符合[相關的工具](/docs/architect/zh-tw/well-architected/guide/compliant#符合的相關工具)。 ### 瀏覽 瀏覽涉及使用者在畫面中的畫面和欄位之間移動焦點。使用者可能需要透過各種方式瀏覽系統中的各種 UI 元素,包括透過點擊和按鍵,同時依賴其視覺、聽覺和觸控。確保您的設計標準包含您計畫支援的瀏覽裝置清單。實作小組應在測試時參照此清單,以確保已考慮所有瀏覽的可能性。 設計無障礙瀏覽時,請考量下列問題及其回答: - **使用者要如何瀏覽您的解決方案?**在您的設計標準中,列出可用於在標準鍵盤與滑鼠以外瀏覽的任何裝置。 - **您的瀏覽是否一致?**建立瀏覽控制項的設計標準,以確保整個系統的一致性。瀏覽路徑在整個系統中應類似。不一致的瀏覽,例如一個畫面右下角的藍色「下一步」按鈕,以及下一個畫面中間的綠色「下一步」按鈕,對某些使用者來說可能會造成輕微的煩惱,但可能會讓身心障礙的使用者無法使用應用程式。 - **您的測試是否考量無障礙功能?**在測試計畫中包含無障礙測試,並確定使用多種類型的輸入裝置測試所有瀏覽流程。 - **鍵盤焦點是否一直可見?**一律以視覺化方式顯示鍵盤焦點的目前狀態,以協助依賴鍵盤的使用者瀏覽。 - **瀏覽是否依賴色彩?**避免僅使用色彩來呈現資訊或要求動作。遵循 [網頁內容無障礙指導方針 (WCAG) 2.0](https://www.w3.org/TR/WCAG20/#visual-audio-contrast) 以正確使用色彩來傳達意義,並套用正確的對比層級。 - **您的設計是否經過檢閱?**定期執行檢閱以確保您的使用者介面一致且易於瞭解。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/compliant#無障礙模式與反模式)清單顯示當瀏覽適當 (且不適當) 針對 Salesforce 解決方案內的無障礙功能所設計時,瀏覽會如何。使用這些功能可在您建立之前驗證您的設計,或識別需要重新設計的系統區域。 若要深入瞭解可建立更無障礙瀏覽的 Salesforce 工具,請參閱符合[相關的工具](/docs/architect/zh-tw/well-architected/guide/compliant#符合的相關工具)。 ### 無障礙模式與反模式 下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/trusted-accessibility)探索更多無障礙模式。
模式 防模式
資料項目 在您的設計標準中:
- 會列出標準鍵盤與滑鼠以外可用於資料輸入的所有裝置
- 系統會列出文字值及其所有支援語言的翻譯
在您的設計標準中:
- 僅列出可用於在標準鍵盤與滑鼠以外輸入資料的部分裝置,或未列出任何裝置
- 系統會列出支援的語言以及要翻譯的 UI 元素
在測試計畫中:
- 測試步驟包括使用多種類型的輸入裝置來輸入資料
- 測試步驟包含多國語言的資料輸入
在測試計畫中:
- 不包含無障礙測試,或針對無障礙資料項目進行臨時測試
在您的組織中:
- 支援語言的翻譯會儲存在翻譯工作台中
在您的組織中:
- 翻譯會儲存在自訂標籤中
瀏覽 在您的設計標準中:
- 會清楚列出可用於瀏覽的所有裝置 (不只是標準鍵盤與滑鼠)
- UI/UX 標準指定所有瀏覽控制項的類型和樣式
- 系統會清楚列出批准傳達意義或狀態的視覺提示類型,且色彩不是主要提示
在您的設計標準中:
- 設計標準不存在或不考慮瀏覽控制項的無障礙需求
- 瀏覽的 UI/UX 標準不一致
- 意義或狀態的視覺提示依賴色彩,或者沒有明確的視覺提示清單供產生器使用
在測試計畫中:
- 測試步驟包括使用多種類型的輸入裝置來瀏覽
- 測試計畫包括使用 UI/UX 測試以確保一致的瀏覽路徑
在測試計畫中:
- 不包含無障礙測試,或臨時執行無障礙瀏覽的測試
## 符合的相關工具
工具描述法律符合度道德標準無障礙
Agentforce Analytics深入瞭解工作人員的表現X
Agentforce 測試中心執行最多 10 個測試工作,每個測試最多 1,000 個測試個案,因此您可以快速建立和評估多個案例。X
引文引號可協助您識別產生回應中潛在的錯誤或幻覺,進而提高使用 AI 工具的信心。X
同意 API追蹤客戶同意偏好設定X
同意事件串流針對同意或連絡人資訊的變更傳送通知X
同意管理物件管理客戶隱私權與同意偏好設定X
資料存取與可攜性依要求匯出客戶相關資料X
資料分類記錄物件欄位的金鑰合規性與稽核資訊X
Data 360 報告監視工作人員指示的符合度X
資料刪除刪除資料以遵循法律法規X
資料隱私權偏好設定儲存客戶資料隱私權偏好設定XX
資料翻譯翻譯呈現給使用者的資料XX
資料偵測將種類和敏感度層級與實際資料保持一致X
Data 360 探索器管理資料科學家的專案和物件權限XX
Einstein Data PrismaSalesforce 中生成式 AI 應用程式的奠基解決方案,可改善使用其奠基功能的 AI 解決方案準確度X
Einstein Trust 圖層專為保護資料隱私權、增強 AI 準確性,以及促進在整個 Salesforce 生態系統中負責使用 AI 的功能、流程和原則集合X
增強型事件記錄事件記錄會在工作人員工作階段中的事件和使用者訊息中,以檢閱「指示符合度」、測試和疑難排解您的工作人員。X
Files Connect從 Salesforce 瀏覽、搜尋和共用外部檔案X
Hyperforce遵循本機資料儲存空間需求X
中繼資料翻譯翻譯語言以本地化應用程式XX
可攜性 API編譯可攜性原則中識別的客戶資料XX
偏好設定中心收集客戶通訊偏好設定XX
隱私權中心滿足客戶要求與資料隱私權法律XX
限制資料處理限制個人資料處理方法XX
被遺忘權根據要求刪除個別客戶資料X
Salesforce 檔案以私人方式共用與儲存檔案X
Security Center檢視多個組織的安全性和隱私權設定X
Shield Platform Encryption加密靜態與傳輸中的資料X
翻譯工作台維護中繼資料和資料標籤的已翻譯值XX
## 符合的相關資源
資源描述法律符合度道德標準無障礙
負責任 AI 設計的 5 個原則以道德的方式設計人工智慧 (AI) 功能X
無障礙基本概念 (Trailhead)瞭解無障礙為何重要X
無障礙合規報告 (ACR)瞭解 Salesforce 如何符合無障礙標準X
無障礙概觀瞭解 Salesforce Lightning 中的無障礙功能X
AI 道德成熟度模型開發藍圖以操作道德原則X
AI Red Teaming:Trust 的測試瞭解 Salesforce 的「道德駭客」如何透過紅色團隊來開發「負責 AI」。X
自動化對手:為 Red Teaming AI 設計可調整架構瞭解 Salesforce 如何自動化對手提示產生和回應驗證,Fuzzai 可協助保護 AI 互動的安全,同時減少人類對有害內容的曝光。X
對話設計的最佳作法設計聊天機器人時遵循最佳作法XX
永續設計的最佳作法 (Trailhead)將永續性納入您的設計中X
同意管理追蹤並遵循同意與選擇退出要求X
Einstein 的資料原則控制 Einstein 功能中的資料使用XX
設計標準範本為您的組織建立設計標準XXX
道德黑客作法證明成功建立信任的 AI 產品瞭解 Salesforce 如何使用 紅色團隊作法來透過測試惡意使用、有意的完整性攻擊、良性濫用,以及識別負責的 AI 問題來改善 AI 產品的安全性。X
道德領導與業務技術、平等與道德的洞察X
道德使用原則探索有關合乎道德使用產品與服務的 Salesforce 原則X
依設計的道德 (Trailhead)將道德設計納入技術開發X
探索 Salesforce 的文化與價值 (Trailhead)探索 Salesforce 的核心值XX
遵循無障礙行動設計指導方針遵循最佳作法讓您的設計可供存取XX
開始使用網路無障礙功能 (Trailhead)瞭解如何讓網站和應用程式可供存取的基本概念X
Salesforce 如何建立可複製的 Red Teaming 基礎結構設計、實作和執行敵對測試時建議的四個元件X
如何執行後續掃描工作坊考量創新時的所有可能成果X
實作資料保護與隱私權評估資料保護與隱私權需求X
包容式設計 (Trailhead)透過包容式設計原則促進創新XX
KPI 試算表範本設定您組織的主要績效指標 (KPI)X
法律資訊探索 Salesforce 的法律資訊中心X
LWC Cookie 同意模組在 Experience Cloud 網站中控制使用者 Cookie 存取權XX
隱私概觀依區域和產業瞭解資料隱私權X
促進負責且有道德的工作人員瞭解如何實作道德紅組和測試策略,並為您的組織開發指導原則和標準。X
負責工作人員 AI 指導方針X
負責建立 AI Trailhead 模組瞭解如何從您的資料和演算法中移除偏差,以建立貴公司的道德 AI 系統。X
負責生成式 AI 指導方針我們建立了我們的信任 AI 原則,並使用一組新的指導方針,專注於負責任開發和實作生成式 AI。X
Salesforce 合規性認證檢閱 Salesforce 的合規性認證和證明X
永續設計 (Trailhead)強化公司與社會之間的關係X
網頁無障礙測試 (Trailhead)使用自動與手動測試來確保無障礙X
信任的工作人員 AI瞭解 Agentforce 如何使用保護措施和負責 AI 原則來建立道德 AI。x
## 告訴我們您的想法 協助我們讓 Salesforce Well-Architected 與您相關;進行我們的[調查](https://sfdc.co/bxNtvh)以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。 > [在此](/docs/architect/zh-tw/well-architected/guide/contributors)閱讀我們的更新排程。 ## 簡介 安全系統可保護組織的利害關係人和資料。安全結構會驗證使用者身分、將資料存取權限制為僅限必要資訊,並防止資料遭到入侵。 Salesforce 優先處理客戶 Trust 和資料安全性。Salesforce Platform 可確保隱私權與安全性。[Salesforce Trust](https://trust.salesforce.com/) 提供即時系統效能與安全性資訊。 保護您的組織和客戶資料是建立安全 Salesforce 解決方案的基礎。身為 Salesforce 結構設計師,您可以利用 Salesforce 的內建安全性功能來負責保護組織和客戶資料的安全。當做出這些決策時,請考量地理分佈、行業、公司營運程序和客戶資料類型。 您可以透過專注於三個區域,讓解決方案更安全:組織安全性、工作階段安全性和資料安全性。 ## 組織安全性 組織安全性可保護系統免受未經授權的存取,方法是確保只有已驗證且已授權的使用者可以存取系統,而且只能存取必要的功能和資料。 您有問題的組織安全性跡象包括: - 啟用或停用使用者的特殊流程 - 更新使用者或系統角色變更授權的不明確步驟 - 依賴個人的機構 Knowledge 進行正確的使用者安全性指派 - 與已建立安全性架構或產業最佳作法不一致 - 缺少結構化資料管理架構與支援原則 您可以專注於驗證和授權,為您的 Salesforce 組織建立更佳的組織安全性控制。 ### 驗證 驗證對於安全性和存取管理而言至關重要,因為驗證嘗試存取您系統的使用者身分。這適用於人類使用者 (員工、客戶) 和自動使用者 (外部系統、整合),且每個使用者類型都需要特定的驗證方式。若要確保您組織中所有 Salesforce 進入點的安全存取權,您必須設定各種驗證方法。 在 Salesforce 中建立安全驗證流程: - **根據個人建立 Salesforce 使用者,而非角色**。當每個使用者帳戶與存取平台的單一人對應時,Salesforce 的內建稽核功能最有效。使用共用使用者帳戶會破壞這些稽核的成效、導致額外的安全性漏洞、升級帳戶缺口的潛在影響,並讓您建立有效授權方式變得複雜。這包括整合使用者的使用者帳戶。 - **以 UI 為基礎的安全存取情況**。大多數的人類使用者對於 Salesforce 組織都需要某種 UI 型存取權 (通常稱為登入存取權)。Salesforce 為這些登入情況提供數層的保護,包括: - **密碼原則.**網路罪犯通常會鎖定使用者名稱和密碼,以取得未經授權的應用程式存取權。雖然設定 [密碼原則](https://help.salesforce.com/s/articleView?id=sf.admin_password.htm&type=5)是保護登入存取權的基本步驟,但請務必注意,這一點並不夠,因為 Salesforce 允許每位使用者覆寫這些原則。 - **多因素驗證 (MFA)**。針對所有以 UI 為基礎的使用者登入,Salesforce [需要 MFA](https://help.salesforce.com/s/articleView?id=000352937&type=1)。MFA 透過要求使用者在成功輸入使用者名稱和密碼後,提供額外形式的識別碼或因素,為抵禦認證洩漏和暴力攻擊提供重要的防護。此額外因素通常會採用實體形式,例如行動裝置、安全性金鑰或生物識別標記。 - **單一登入 (SSO)**。在 SSO 案例中,使用者在組織的應用程式中只會使用一組認證。系統的存取權會從集中位置佈建和管理,進而改善安全性。Salesforce 可在 [SSO 案例中](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5)作為服務提供者或身分提供者。請務必允許部分或所有管理員直接登入 Salesforce,讓他們可以解決 SSO 實作的中斷或問題。 - **登入後步驟。**針對某些使用個案,您可能需要使用者在存取系統之前完成其他步驟。自訂登入流程可實作以引導使用者完成這些額外的流程步驟。範例包括: - 接受條款與條件 - 使用 [登入探索和無密碼登入情況](https://help.salesforce.com/s/articleView?id=sf.external_identity_passwordless_login_use_cases.htm&type=5) - 限制每個使用者的同時 Salesforce 工作階段數目,以降低以工作階段為基礎之攻擊的可能性 (請參閱 [工作階段安全性](/docs/architect/zh-tw/well-architected/guide/secure#工作階段安全性))。 - 連線至地理柵欄服務 - **以 API 為基礎的安全存取情況**。任何使用者都可以要求 Salesforce 組織的 API 型存取權。Salesforce 為以 API 為基礎的案例提供數層的保護,包括: - **API 存取控制**。若沒有 [API 存取控制](https://help.salesforce.com/s/articleView?id=sf.security_api_access_control_about.htm&type=5),任何擁有有效認證集的使用者都可以利用任何應用程式與您的組織連線,即使未在組織中部署連線的應用程式也是如此。資料存取控制仍會強制執行,但使用者可以透過無法控制的方式存取資訊。例如,應用程式可以用來下載大量資料,甚至上載損毀的資訊,而無須系統管理員的批准。 - **僅 API 權限**。您可以在 Salesforce 中設定「僅 API」使用者權限。將此權限集作為權限集的一部分指派給任何自動或[整合使用者](https://help.salesforce.com/s/articleView?language=en_US&id=sf.integration_user.htm)角色,以完全封鎖以 UI 為基礎的存取。 - **憑證與金鑰**。[憑證與金鑰](https://help.salesforce.com/s/articleView?id=sf.security_keys_about.htm&type=5)可讓 Salesforce 驗證要求來自授權公司或公司。如果您要將 [SSO 與 Salesforce](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5) 搭配使用,則需要設定憑證與金鑰。 - **連線的應用程式**。在 Salesforce 中設定 [連線的應用程式](https://help.salesforce.com/s/articleView?id=sf.connected_app_overview.htm&type=5)可讓您在單一定義中控制外部系統對 Salesforce 的存取權,包括必要的驗證通訊協定、授權範圍和工作階段行為。 - **已命名認證**。[已命名認證](https://help.salesforce.com/s/articleView?id=sf.named_credentials_define.htm&type=5)可讓您在 Salesforce 內的單一定義中控制外部存取點和驗證通訊協定。使用這些功能可安全地定義和管理來自 Apex、外部服務和 Salesforce Connect 資料來源的呼叫驗證。 - **Agentforce Agent 使用者驗證**。以 Salesforce 為基礎的 Agentforce 工作人員會使用具有可管理權限的工作人員使用者物件,如同實際使用者的權限。設定工作人員時,請謹慎將存取權與工作人員所扮演的角色保持一致,將資料存取權僅限於提供一般使用者所需的資料。同樣重要,工作人員可以使用公用與私人動作來設定。針對私人動作,請驗證並驗證一般使用者,將其對應至工作人員內容。這可讓工作人員在一般使用者的存取控制內模擬和操作,同時維持安全性和 Trust。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/secure#組織安全性模式與反模式)清單顯示 Salesforce 組織中的正確 (和不良) 驗證結構外觀。在您建立之前,請使用這些項目來驗證您的設計,或找出進一步改善的機會。 若要深入瞭解 Salesforce 提供的驗證工具,請參閱與安全相關的 [工具](/docs/architect/zh-tw/well-architected/guide/secure#與安全相關的工具)。 ### 授權 授權會定義使用者可存取的功能、功能和資料,以及使用者可在資源經過[驗證後](/docs/architect/zh-tw/well-architected/guide/secure#驗證)透過這些資源執行的動作。授權控制項不僅適用於人類使用者,也需要針對 Agentforce 工作人員使用者量身打造,特別是提供服務給未經驗證使用者的工作人員。 雖然限制可以驗證至您組織的人員是重要的第一個步驟,但將強式驗證與強大的授權配對同樣重要。若沒有適當的授權控制,使用者可能會以對您的業務和利害關係人有害的方式建立、編輯和刪除記錄或存取系統功能。授權控制不足也會使系統難以使用。透過控制使用者可在系統中執行的動作,您可以培養更高的 Trust 層級,同時保護您的系統和使用者。 若要建立 Salesforce 的安全授權配置: - **遵循最低權限原則**。透過僅將工作所需的權限指派給使用者,以採用最低權限原則 (PoLP)。若要遵循此原則,請設計細微與模組權限集。這可透過權限集群組進行精密的存取控制,讓權限精確管理,包括[靜音](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_muting.htm&type=5)、[設定到期日期](https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_permissions_assn_expiration.htm&type=5&release=238)等功能。讓系統的 [功能單位](/docs/architect/zh-tw/well-architected/guide/composable#功能單位)與業務功能保持一致,以定義細微的權限和有效的權限集群組。請記住,權限適用於 Salesforce 中的 *中繼資料*存取。如需為 Salesforce _資料_ 存取權設定 PoLP 的詳細資料,請參閱 [共用與可視性](/docs/architect/zh-tw/well-architected/guide/secure#共用與可視性)。 - **以角色 (而非個人**) 來思考使用者存取權。以個別使用者的角度思考授權 (或一般安全性) 將不會讓您的系統調整規模並演進。請改為為代表使用者群組的角色設計與管理角色。安全 Salesforce 解決方案使用個人進行驗證,使用角色進行授權。透過為不同的角色定義安全性組態,您可以精確地控制安全性模型中的存取權與權限,進而在長期內減少重構的需求。包含您在 [設計標準和文件](/docs/architect/zh-tw/well-architected/guide/intentional#可讀性)中定義的安全性角色。 - **使用權限集和權限集群組控制使用者對中繼資料的存取權**。權限集和權限集群組會管理使用者可以存取哪些中繼資料,以及他們可以對該中繼資料執行的動作。若要深入瞭解 Salesforce 中繼資料,請參閱 [中繼資料與資料](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#中繼資料與資料)。透過權限集和權限集群組設定應用程式指派、功能授權啟用、受管理封裝存取、系統權限、[CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm) 存取權,以及欄位級存取。在您的 [設計標準和文件中](/docs/architect/zh-tw/well-architected/guide/intentional#可讀性)包含此存取權。 - **使用組織範圍預設值 (OWD) 和共用來控制使用者的資料存取權**。[資料與中繼資料](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#中繼資料與資料)是 Salesforce 中的獨立實體,每個實體都需要個別的存取控制。使用 OWD 和內建共用工具來設定 Salesforce 資料 (個別記錄、檔案和文件) 的存取權。如需詳細資料,請參閱 [資料安全性](/docs/architect/zh-tw/well-architected/guide/secure#資料安全性)。 - **使用 OAuth 範圍控制連線應用程式的存取權**。設定連線的應用程式時,您可以定義應用程式使用者將擁有 Salesforce 資源的 [範圍](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US)或存取權限。如需管理 OAuth 權杖的詳細資訊,請參閱 [工作階段管理](/docs/architect/zh-tw/well-architected/guide/secure#工作階段管理)。 - **為每個整合建立一個 Salesforce 使用者**。若要遵循最低權限原則,請為每個整合建立唯一的 Salesforce [整合使用者](https://help.salesforce.com/s/articleView?id=sf.integration_user.htm)。這可讓您指派特定資料存取權、改善對作業的控制、確保交易可追溯性,並將潛在安全性缺口的影響降到最低。 - **針對所有工作人員使用者實作具有 PoLP 的唯一帳戶**。每個 Agentforce 工作人員使用者應是唯一的,且不得在多個工作人員之間重複使用。這些帳戶的權限必須嚴格遵循最低權限原則。請記住,工作人員使用者執行的「動作」可能會在 Salesforce 內的高度安全性環境中作業,或針對不遵循 Salesforce 存取控制項的外部系統作業。這可能會導致「動作」存取或向使用者顯示敏感資訊。 - **最小化使用設定檔,並將任何存取控制移轉至設定檔之外**。設定檔能夠限制存取舊版 Salesforce Classic 使用者介面的[登入 IP 範圍](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm&type=5)、[登入時間](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5)和特定功能 (尤其是預設記錄類型和版面配置指派)。設定檔中目前的任何其他功能應移轉至 [權限集和權限集群組](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_create_with_perm_sets.htm)中的相等功能。您設定檔中繫結至 Salesforce Classic UI 功能的功能應以修復為目標。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/secure#組織安全性模式與反模式)清單顯示 Salesforce 組織中正確 (和不良) 的授權作法外觀。在您建立之前,請使用這些項目來驗證您的設計,或找出進一步改善的機會。 若要深入瞭解 Salesforce 提供的授權工具,請參閱與安全相關的 [工具](/docs/architect/zh-tw/well-architected/guide/secure#與安全相關的工具)。 ### 組織安全性模式與反模式 此表格顯示要在您的組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/trusted-organizational-security)探索更多組織安全性的模式。
模式 防模式
驗證 在您的設計標準和文件中:
- 已批准的安全性角色已清楚定義並列出
- 在安全性矩陣中存在的安全性角色與允許的驗證結構描述 (UI、API) 之間的對應
如果存在設計標準和文件,則會:
- 不包含安全性角色
- 請勿包含安全性角色和允許驗證方式的安全性矩陣與清楚對應
在您的組織中:
- 登入組態符合 Salesforce MFA 檢查
- 登入 Salesforce 的使用者與實體之間的關係為 1:1 (無共用使用者)
- API 存取控制可防止使用者透過未經授權的連線應用程式進行驗證
- 如果 SSO 已啟用,則批准的管理員使用者擁有直接登入存取權
在您的組織中:
- 登入組態不符合 Salesforce MFA 檢查
- 登入 Salesforce 的使用者與實體之間的關係不是 1:1 (共有使用者帳戶)
- 如果使用者從防火牆後面存取 Salesforce,防火牆會使用硬式編碼 IP 位址來保護對 Salesforce 的通訊。
- 未啟用「API 存取控制」
- 如果 SSO 已啟用,則沒有任何經批准的管理員使用者擁有直接登入存取權
在 LWC 中,Apex,Aura:
- 執行驗證的方法會使用已命名認證來處理使用者名稱/密碼流程
- 使用者名稱或密碼不會以可讀的程式碼顯示 (沒有硬式編碼值或字串)
- 如果存在自訂登入流程,則所有相關的自訂程式碼都會使用適當的 SessionManagement 方法
在 LWC 中,Apex,Aura:
- 驗證為臨時處理
- 使用者名稱和密碼會顯示在程式碼中
授權 在您的設計標準和文件中:
- 擁有 Salesforce 存取權的每個使用者和系統都會對應至安全性矩陣中的一或多個角色
- 安全性矩陣會清楚列出中繼資料權限和指派的使用者角色
- 會清楚列出授與增強權限的使用個案,包括:
-- 修改所有資料權限
-- 檢視所有資料權限
如果存在設計標準和文件,則會:
- 不包含安全性矩陣
- 未清楚列出權限
- 請勿清楚列出授與增強權限的使用個案
在您的組織中:
- 權限集和權限集群組用於控制中繼資料的存取權
- 符合業務功能的權限集和權限集群組
- 指派給使用者遵循安全性矩陣定義的權限
- 設定檔最少使用,僅用於控制登入 IP 範圍和登入時間
- 針對每個整合設定唯一的僅 API 整合使用者
在您的組織中:
- 權限集群組未設定為允許根據業務功能存取
- 權限集已臨時設定
- 權限集是冗餘的或重複的;難以瞭解清晰的功能邏輯和設定之間的差異
- 指派給使用者的權限不會遵循安全性矩陣定義
- 設定檔包含中繼資料的存取控制
- 僅 API 使用者未設定或在多個整合之間共用
在 Apex 中:
- 資料庫作業會適當執行欄位和物件級存取檢查,包括:
-- DML 與資料庫 DML 陳述式宣告資料作業 AND/OR 的 使用者或系統模式
-- DML 與資料庫 DML 陳述式在資料作業之前使用 stripInaccessible 方法
-- SOQL 和 SOSL 陳述式使用 具有 USER_MODE 和 具有 SYSTEM_MODE 關鍵字 AND/OR
-- stripInaccessible 方法用於篩選查詢和子查詢結果
-- sObject 描述結果方法 (亦即 isAccessible、isCreateable、isUpdateable 和/或 isDeletable) 會很少使用
在 Apex 中:
- 在預設系統模式中執行 DML、資料庫類別方法、SOQL 和 SOSL
- 資料庫作業無法適當執行存取檢查,包括:
-- DML 或資料庫類別方法僅使用 isAccessible、isCreateable、isUpdateable 和/或 isDeletable 檢查以取得 sObject 和欄位級存取權
-- SOQL 查詢只會將 SECURITY_ENFORCED 關鍵字用於存取限制
在流程中(流程設計的安全性考量事項):
- 流程會使用盡可能嚴格的「執行內容」,理想是使用者模式
- 子流程執行安全性敏感或特權資料存取,以將執行內容最小化
- 限制在記錄觸發流程中執行的邏輯
- 驗證流程輸入,以確保只會將允許的裝載傳遞為輸入
在流程中:
- 流程會在「系統模式」或「不共用的系統模式」中執行,無論流程執行的動作為何
- 所有流程邏輯都會在單一的大型流程中執行
- 未驗證流程輸入,且會在未驗證的情況下傳送給消費者
## 工作階段安全性 工作階段是一系列在一段期間內與使用者相關聯的要求和回應。當使用者成功驗證至 Salesforce 時,會起始工作階段。[工作階段安全性](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.security_overview_sessions.htm)是透過阻止工作階段干擾或劫持來設定系統以防止未經授權的存取和資料缺口的作法。 您系統中的所有使用者活動都會在工作階段內容中發生,因此考慮工作階段的起始方式、在工作階段期間可能發生的內容、使用者將 (且應) 使用的裝置,以及偵測和回應可疑或異常工作階段行為的方式十分重要。 您可以在 Salesforce 中建立工作階段安全性,方法是專注於三個關鍵:工作階段管理、裝置存取,以及威脅偵測和回應。 ### 工作階段管理 工作階段會在使用者成功驗證並取得 Salesforce 的存取權時起始。這些工作階段可讓平台將特定要求和回應與該特定使用者相關聯。 HTTPS 通訊協定可協助前端用戶端與 Salesforce Platform 之間的通訊。用戶端可以包含瀏覽器、行動應用程式、本機應用程式等。HTTPS 是無狀態通訊協定,這表示每個通訊都是離散的,與任何先前或未來通訊無關。 此無狀態方法可加速網路通訊,並排除因封裝之間中斷連結所導致的錯誤。不過,網頁應用程式仍需要追蹤每個使用者身分和其他在多個要求與回應互動之間相關資訊的方式。Salesforce 與大多數 Web 應用程式一樣,使用工作階段和 [權杖](https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_tokens_scopes.htm&type=5)來完成此作業。 - **工作階段**可讓 Salesforce 將要求與回應與使用者相關聯。使用者驗證後,平台會將工作階段識別碼傳回用戶端應用程式,其中包含此識別碼與任何使用者要求 (例如瀏覽、搜尋和提交資料)。 - **權杖**可讓使用者和連線的應用程式驗證其身分一次,然後再使用唯一的存取權杖。權杖的留存時間有限,僅提供特定資源的存取權 (如需設定存取層級的詳細資訊,請參閱 [授權](/docs/architect/zh-tw/well-architected/guide/secure#授權))。權杖允許存取授權的資源,而不需要使用者登入。 如果未正確保護工作階段和權杖,則惡意執行動作的使用者可能會干擾工作階段並模仿使用者或在您的系統中執行惡意程式碼。 若要建立 Salesforce 的安全工作階段管理: - **瞭解 Salesforce 如何分類工作階段類型**。識別已批准的 [工作階段類型](https://help.salesforce.com/s/articleView?id=sf.security_session_types.htm&type=5) 並對應至安全性使用者角色,並在您的文件中記錄這些類型。 - **控制工作階段發生的方式,以及工作階段流量的移至何處**。在您識別允許各種使用者角色啟動的工作階段類型後,請設定控制,以封鎖源自未批准來源或內容的工作階段。Salesforce 提供數種控制工作階段來源和流量的方法,包括: - **內建工作階段保護**。Salesforce 會自動針對以工作階段為基礎的惡意活動啟用組織範圍保護,包括跨網站指令檔、跨網站要求偽造、[內容探索](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing)、[點閱劫持](https://owasp.org/www-community/attacks/Clickjacking)等。這些保護絕不應停用;某些無法停用。 - **網域和 IP 範圍**。所有 Salesforce 組織預設已啟用「[我的網域](https://help.salesforce.com/s/articleView?id=sf.domain_name_overview.htm&type=5)」,這會為 Salesforce 存取建立公司特定的子網域。您可以透過「我的網域」自訂或變更與組織相關聯的名稱。此外,Salesforce 支援 Experience Cloud 網站和其他應用程式頁面的其他[網域組態](https://help.salesforce.com/s/articleView?id=sf.domain_mgmt_overview.htm&type=5)。注意:如果您的使用者需要從公司防火牆後方存取 Salesforce,請將[必要網域](https://help.salesforce.com/s/articleView?id=sf.setup_domains.htm&type=5)新增至防火牆允許清單。您可以設定 [登入 IP 範圍](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/users_profiles_epui_login_ip_ranges_edit.htm)和 [信任的 IP 範圍](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm),以控制 Salesforce 的輸入登入和工作階段要求。 - **登入時間**。如果某些使用者角色已設定工作時間,您可以限制其在定義的[登入時間](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5)外存取 Salesforce 的能力。 - **控制需要新增工作階段層級安全性的活動**。依預設,工作階段可以有兩種[安全性層級](https://help.salesforce.com/s/articleView?id=sf.security_overview_sessions.htm&type=5):標準和高度保證。使用這些安全性層級可控制使用者如何可以或無法執行活動,例如存取報告和顯示面板,或管理 Salesforce 組織中的安全性組態。工作階段級安全性原則可能需要使用者建立執行作業的 [高度保證工作階段](https://help.salesforce.com/s/articleView?id=sf.security_auth_require_ha_session.htm&type=5),或禁止使用者執行任何敏感作業。 - **控制需要新增以工作階段為基礎權限**的活動。Salesforce 支援以 [工作階段為基礎的權限](https://help.salesforce.com/s/articleView?id=sf.perm_sets_session_use.htm&type=5)啟用,以暫時允許使用者在特定工作階段期間提高授權或存取權限。您可以透過流程或 Salesforce API 啟用和停用以工作階段為基礎的權限。 - **透過逾時管理未啟用的使用者工作階段**。結束未啟用的工作階段是管理工作階段安全性的關鍵部分。例如,當使用者在瀏覽器索引標籤中開啟 Salesforce 工作階段,但在其他應用程式中主動工作時,或當使用者的行動裝置登入 Salesforce 但未受監視時,這有助於保護您的系統。Salesforce 的預設工作階段閒置時間逾時為兩小時。您可以增加或減少工作階段閒置逾時層級,但增加逾時應只在具有吸引力且經過完整記錄的理由的情況下完成。 - **透過權杖組態管理連線的應用程式工作階段。**當您設定連線的應用程式時,您也會定義要授與透過連線應用程式存取 Salesforce 的使用者之範圍或授權層級。此範圍會透過已連線應用程式使用者成功驗證後發出的 [OAuth 權杖](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US),在工作階段層級強制執行。您可以控制權杖在 [權杖重新整理原則](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US)中應持續多久。組織管理員可以視需要手動撤銷每位使用者和每個組織的權杖。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/secure#工作階段安全性模式與防模式)清單顯示 Salesforce 組織中適當 (與不良) 工作階段管理的外觀。在您建立之前,請使用這些項目來驗證您的設計,或找出進一步改善的機會。 若要深入瞭解 Salesforce 提供的工作階段管理工具,請參閱與安全相關的 [工具](/docs/architect/zh-tw/well-architected/guide/secure#與安全相關的工具)。 ### 裝置存取權 在目前的內容中,*裝置*是個人將用來存取 Salesforce 的任何電子設備,例如桌上型工作站、筆記型電腦、平板電腦或行動電話。 可攜式裝置可讓使用者從任何位置彈性存取 Salesforce。不過,此便利性可能會為惡意執行動作使用者導入額外的攻擊向量。這些威脅向量範圍可從簡單的策略 (例如在公用地方衝浪以竊取認證) 到更複雜的方法 (例如在裝置上安裝惡意軟體或建立虛假的公用 Wi-Fi 網路來攔截資料傳輸)。因此,保護裝置 (尤其是可攜式裝置) 對於整體系統安全性而言至關重要。 若要保護 Salesforce 的裝置存取權: - **使用 Salesforce 提供的行動應用程式解決方案**。讓行動裝置上需要存取 Salesforce 的使用者使用 iOS 和 Android 可用的正式 [Salesforce 應用程式](https://help.salesforce.com/s/articleView?id=sf.mobile_security.htm&type=5)。如果業務需求需要自訂行動解決方案,您應該使用 [Salesforce Mobile SDK](https://developer.salesforce.com/docs/atlas.en-us.mobile_sdk.meta/mobile_sdk/intro.htm),其提供安全驗證和授權的方法。 - **將行動裝置用量設計至工作階段管理**。工作階段安全性層級、工作階段逾時和其他工作階段內容控制應考量行動裝置上使用者的任何預期存取權。考慮應允許哪些裝置存取 Salesforce,以及哪些使用者應擁有行動工作階段的存取權。在您的安全性角色文件中包含行動存取標準。如需此主題的詳細資訊,請參閱 [工作階段管理](/docs/architect/zh-tw/well-architected/guide/secure#工作階段管理)。 - **使用行動裝置管理 (MDM) 技術補充裝置級安全性。**iOS 和 Android 版的 Salesforce 應用程式與許多受歡迎的 MDM 套件 [相容](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mdm.htm&type=5)。您可以透過偏好的 MDM 解決方案,在使用者裝置上為 Salesforce 應用程式設定其他存取控制。 - **使用行動應用程式管理 (MAM) 技術補充應用程式級安全性**。MAM 技術支援行動裝置上的應用程式層級控制。Salesforce 為 Salesforce 行動應用程式提供付費的 [MAM 附加元件](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mam_overview.htm&type=5)。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/secure#工作階段安全性模式與防模式)清單顯示 Salesforce 組織中裝置管理的適當 (和不良) 樣子。在您建立之前,請使用這些項目來驗證您的設計,或找出進一步改善的機會。 若要深入瞭解 Salesforce 提供的裝置管理工具,請參閱與安全相關的 [工具](/docs/architect/zh-tw/well-architected/guide/secure#與安全相關的工具)。 ### 威脅偵測和回應 威脅偵測是在系統中識別可能表示惡意活動之行為模式的程序。這可能包含超出平均值的資料量,或使用者在短於平均值的期間內,修改包含數筆記錄上敏感資料的欄位。對威脅的回應可包含自動工作階段到期、警示和其他通知。 威脅偵測的目標是盡快識別潛在問題並對其做出回應。根據即時威脅偵測採取行動可停止追蹤惡意行為。Salesforce 提供附加元件或作為 [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) 一部分的 [即時事件監視](https://help.salesforce.com/s/articleView?id=sf.real_time_event_monitoring_overview.htm&type=5)。如果您有高度敏感的應用程式或需要強大的即時威脅偵測和回應功能,請使用下列其中一個解決方案。 若要為您的 Salesforce 解決方案建立有效的威脅偵測和回應策略: - **使用內建稽核功能**。Salesforce 提供各種各樣的[內建工具](https://help.salesforce.com/s/articleView?id=sf.monitoring_admin.htm&type=5),以協助追蹤和稽核對您組織的變更。例如,[設定稽核追蹤](https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5)可讓您檢視管理動作的稽核歷程記錄。Salesforce 預設會在有限的期間內追蹤欄位級變更,但您可以啟用「[欄位歷程記錄追蹤」,](https://help.salesforce.com/s/articleView?id=sf.tracking_field_history.htm&type=5)以在 UI 中顯示最多 18 個月的欄位變更,並透過 API 顯示最多 24 個月的欄位變更。此外,您可以啟用「[欄位稽核追蹤」,](https://help.salesforce.com/s/articleView?id=sf.field_audit_trail.htm&type=5)無限期保留欄位級變更的稽核歷程記錄 (直到您手動刪除資料為止)。 - **建立定期稽核審查**。稽核對於識別即時威脅偵測可能會遺漏的異常變更而言至關重要。請思考一下,具有合法存取權的使用者會持續在延長期間內每天刪除少量記錄的情境。由於此使用者擁有有效的登入認證、有適當的權限來刪除記錄,且未一次刪除大量記錄,因此不會將活動偵測為即時威脅。然而,檢閱使用者活動報告的稽核小組會明確識別一段時間內單一使用者過度刪除記錄的趨勢,使其更容易處理。作為您[的管治原則](/docs/architect/zh-tw/well-architected/guide/intentional#監管)的一部分,請建立定期間隔以稽核登入歷程記錄、使用者工作階段活動和連線的應用程式用量。 - **開發威脅回應策略並將其包含在您的安全性原則中**。建立涵蓋以下項目的威脅回應策略: - 威脅回應類型定義 (例如警示和自動化),以及任何應涉及的利害關係人[群組](/docs/architect/zh-tw/well-architected/guide/resilient#事件回應)。如需設計訊息或警示的詳細資訊,請參閱 [錯誤與通知](/docs/architect/zh-tw/well-architected/guide/engaging#通知與訊息)。 - 可視為威脅的即時變更或活動特定種類,以及每個事件的相關聯回應類型 - 所有自動化威脅回應 (例如撤銷權杖、結束工作階段、停用使用者帳戶或封鎖資源的存取權) 和自動化觸發的清單 「事件監視」透過啟用即時威脅偵測和回應,提供強制執行此原則所需的資料。「交易安全性」會套用貴公司的原則驅動動作,而事件類型支援隨時間監視使用者和應用程式存取權。 Salesforce 的原生威脅偵測服務使用統計和機器學習模型來識別可疑行為。此服務會產生特定事件,以防網路攻擊和可疑資料存取。 「交易安全性」可進一步提升安全性,因為其提供一個架構,可攔截組織中發生的關鍵事件,並套用貴公司的原則驅動動動作。這會將「事件監視」從記錄工具轉換為自動安全性防禦的重要元件。 下方的[模式與防模式](/docs/architect/zh-tw/well-architected/guide/secure#工作階段安全性模式與防模式)清單顯示 Salesforce 組織中的正確 (與不良) 威脅偵測和回應外觀。在您建立之前,請使用這些項目來驗證您的設計,或找出進一步改善的機會。 若要深入瞭解 Salesforce 提供的威脅偵測、警示和回應自動化工具,請參閱與安全相關的 [工具](/docs/architect/zh-tw/well-architected/guide/secure#與安全相關的工具)。 ### 工作階段安全性模式與防模式 此表格顯示要在您的組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/trusted-session-security)探索更多工作階段安全性的模式。
模式 防模式
工作階段管理 在您的設計標準和文件中:
- 安全性角色會清楚列出每個角色已批准的工作階段類型與逾時/持續時間設定
- 已指定登入時間 (或識別為非必要)
- 需要高度工作階段級安全性或權限的作業會清楚且可探索
- 連線應用程式範圍和權杖管理原則清楚且可探索
在您的設計標準和文件中:
- 安全性角色不存在或缺少工作階段類型和逾時/持續時間設定的相關資訊
- 安全性原則不包含連線應用程式範圍或權杖管理的相關資訊
在您的組織中:
- 工作階段稽核顯示使用者僅透過預期的工作階段類型存取 Salesforce
- 有「僅 API 使用者」存取權的明確且已啟用權限集 (且「僅 API」權限集為 TRUE),且已指派所有整合與自動化使用者
- 如果使用者從防火牆後方存取 Salesforce,防火牆會使用所需網域的允許清單,而非 IP 位址,以保護對 Salesforce 的通訊安全。
- 未啟用工作階段逾時間隔不超過預設值 (2 小時)
- 已啟用下列所有設定:
-- 「設定」頁面的點閱綁架保護
-- 非「設定」Salesforce 頁面的點閱綁架保護
-- 跨網站要求偽造 (CSRF) 保護
-- 跨網站指令檔 (XSS) 保護
-- 啟用內容探查保護
-- 查閱者 URL 保護
-- 在使用者重新導向至 Salesforce 之外之前警告使用者
在您的組織中:
- 沒有一般工作階段稽核
- 沒有使用者應擁有的工作階段類型定義
- 「僅 API」權限不明確或缺少於整合與自動化使用者
- 如果使用者從防火牆後面存取 Salesforce,防火牆會使用硬式編碼 IP 位址來保護對 Salesforce 的通訊。
- 未啟用工作階段逾時間隔超出預設值 (2 小時)
- 停用下列任一設定:
-- 「設定」頁面的點閱綁架保護
-- 非「設定」Salesforce 頁面的點閱綁架保護
-- 跨網站要求偽造 (CSRF) 保護
-- 跨網站指令檔 (XSS) 保護
-- 啟用內容探查保護
-- 查閱者 URL 保護
-- 在使用者重新導向至 Salesforce 之外之前警告使用者
在 LWC 中,Apex,Aura:
- 如果存在自訂登入流程,所有相關的自訂程式碼都會使用適當的 SessionManagement 方法來指派工作階段級安全性
在 LWC 中,Apex,Aura:
- 如果存在自訂登入流程,則沒有指派工作階段層級安全性的邏輯
裝置存取權 在您的設計標準和文件中:
- 裝置原則清楚且可探索
- 安全性角色會清楚對應至適當的裝置用量與原則
在您的設計標準和文件中:
- 安全性原則不存在或不包含裝置存取的相關資訊
在您的組織中:
- 閒置後,Salesforce 行動連線應用程式組態需要 PIN/密碼解除鎖定
- 如果業務需求需要嚴格控制可存取 Salesforce 行動裝置的使用者,則會啟用「API 存取控制」,並將權限集指派給 Salesforce 行動應用程式的所有使用者
在您的組織中:
- 未將 Salesforce 行動連線應用程式設定為需要 PIN/密碼解除鎖定以進行閒置
– 業務需求需要嚴格控制可存取 Salesforce 行動裝置的使用者,但未啟用「API 存取控制」或無法使用權限集來控制對 Salesforce 行動應用程式的存取權
威脅偵測和回應 在您的設計標準和文件中:
- 安全性原則包含應觸發回應的事件清單以及適當的回應類型
- 已為資料模型中的所有物件指定稽核層級
- 系統會記錄檢閱 Salesforce 中可用記錄的步驟
- 系統會清楚記錄所有自動回應
在您的設計標準和文件中:
- 安全性原則不存在或不包含威脅偵測和警示的相關資訊
- 自動回應的文件不存在或不明確
在貴公司內:
- 稽核資料可在業務專案關係人可瞭解和存取的報告中使用
- 定期檢閱稽核歷程記錄和報告。
在貴公司內:
- 稽核資料僅可透過需要主題專業知識的記錄檔存取與解譯
- 沒有可檢閱稽核資訊的流程
在您的組織中:
- 如果偵測到異常使用狀況,自動化功能已準備就緒,可透過停用使用者帳戶或即時封鎖對資源的存取來回應威脅
- 通知和警示設定為通知適當的使用者有關異常活動
- 欄位歷程記錄追蹤已針對包含私人或敏感資料的所有欄位啟用
在您的組織中:
- 沒有自動化功能可回應威脅
- 通知和警示未設定為通知適當的使用者有關異常活動,或者存在與異常活動相關的一些通知和警示,但這些通知是臨時的
- 針對包含私人或敏感資料的欄位,未持續啟用欄位歷程記錄追蹤
## 資料安全性 資料安全性是保護資料免受未經授權存取、損毀或非預期刪除的作法。資料安全性涉及在傳輸和靜態時保護資料。 強大的資料安全性可將未經授權存取系統的風險和潛在損害降到最低。資料安全性不足會讓系統容易受到資料缺口影響,這會對客戶和您的公司造成嚴重影響。因此,保護資料是建立安全結構的基礎。 改善資料安全性從清楚瞭解 Salesforce 內所視為資料的內容及其分類開始。儲存在 Salesforce 組織中的個別記錄、檔案和文件是其資料。如需有關中繼資料與資料之間區別的詳細資訊,請參閱「[Salesforce 結構基本概念](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#中繼資料與資料)」。 您可以專注於共用與可視性,以及使用加密,以在 Salesforce 解決方案中建立更強大的資料安全性。 > 注意:針對資料安全設計時,請務必考慮到[資料隱私權](/docs/architect/zh-tw/well-architected/guide/compliant#資料隱私權)以及[歸檔與清除](/docs/architect/zh-tw/well-architected/guide/resilient#持續性規劃),因為這兩個概念都會影響解決方案的整體資料安全性。 ### 資料分類 根據敏感度識別和分類儲存在 Salesforce 平台中的所有資料 (例如公用、內部、機密、受限制)。定義明確的 **資料分類原則,其中**概述應如何處理和保護每個資料類型。實作適當的安全性控制,例如欄位級安全性、加密和資料遮蔽,以強制執行原則,並保護敏感資料免受未經授權的存取或曝光。定期檢閱並稽核這些分類和控制,以確保其與業務與合規性需求保持一致。 ### 共用與可視性 共用與可視性涉及設定系統以控制使用者在 Salesforce 內存取資料的方式。請務必注意,共用與可視性可控制使用者可存取的個別記錄,但這些設定本身並不會最終控制使用者可對特定記錄執行的動作,或可看見該記錄內的特定欄位。透過可在個別物件和欄位層級為使用者設定的中繼資料存取控制,將執行資料作業 (例如 [CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm)) 的權限指派給使用者。如需此項目的詳細資訊,請參閱 [授權](/docs/architect/zh-tw/well-architected/guide/secure#授權)。 Agentforce 動作可向已驗證與匿名使用者公開資料,這些使用者通常沒有直接存取權。建立 Agentforce 工作人員時,請仔細考量並記錄指派給工作人員的所有「動作」。針對每個「動作」,您必須瞭解: - 「動作」可以存取的資料。 - 「動作」執行的安全性內容為何。 - 「動作」是否具有可將敏感或受限制資料納入「工作人員」工作階段的 Knowledge retrieve 或其他功能。 若要在 Salesforce 中設定有效的共用與可視性: - **針對有意義的工作功能設計存取權**。建立安全性矩陣,將您的[使用者角色](/docs/architect/zh-tw/well-architected/guide/secure#驗證)對應至他們要執行的業務功能。使用此 [範本](/docs/architect/zh-tw/resources/guide/security-policy-template)作為設計共用與可視性的基礎。如需識別有意義業務功能的詳細資訊,請參閱[功能單位](/docs/architect/zh-tw/well-architected/guide/composable#功能單位)。 - **選擇要套用最低權限原則**的最簡單路徑。當您在設計共用與可視性方式時套用最低權限[原則時](/docs/architect/zh-tw/well-architected/guide/secure#授權),請以最直接的方式進行。避免過度設計資料限制和共用方式,這會導致系統維護、延展性和適應性發生下游問題。相反地,您可以利用 Salesforce 中的[彈性、分層的資料共用](https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/sharing_architecture.pdf)來設定使用者在資料層級存取的細微規則。 - **將 _內部_ 組織範圍預設值 (OWD) 設定為「公用唯讀」,除非您的公司處理敏感資料,否則請使用「專用**」。OWD 可控制使用者在資料層級擁有的「最少」權限層級。您無法限制低於 OWD 層級的存取權。雖然「私人 OWD」在每個使用個案中都看起來很理想,但業務中的使用者通常會因複雜的共用方式而不小心複製更具權限的 OWD。此外,「私人 OWD」會造成使用者建立重複的資料。共用計算 (和重新計算) 可能需要大量的時間完成,端視資料量和父系子系或擁有權偏差而定—私人 OWD 會加強此情況。請務必注意,OVD 不會控制 CRUD 權限和欄位級可視性。只有在業務需求正確時才選擇「專用 OWD」,這類理由通常與[合規性](/docs/architect/zh-tw/well-architected/guide/compliant)相關。 - **除非您有強大的商業理由允許更大的存取權**,否則將「*外部*組織範圍預設值 (OWD)」設定為「專用」。[外部 OWD](https://help.salesforce.com/s/articleView?id=sf.security_owd_external.htm&type=5) 適用於從 Experience Cloud 網站、入口網頁等存取 Salesforce 資料的使用者。這可讓您為內部與外部使用者設定個別的 OWD 基準,以允許不同類型的「最少」權限。請一律將外部使用者的 OWD 設定為「專用」,因此,較開放層級的例外情況必須明確地由業務需求所證明。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/secure#資料安全性模式與防模式)清單顯示 Salesforce 組織中的正確 (與不良) 共用與可視性。在您建立之前,請使用這些項目來驗證您的設計,或找出進一步改善的機會。 若要深入瞭解 Salesforce 的共用與可視性工具,請參閱與安全相關的 [工具](/docs/architect/zh-tw/well-architected/guide/secure#與安全相關的工具)。 ### 加密的使用 加密會將可讀資料轉換為無法解碼的編碼格式。加密資料可透過金鑰解密或翻譯回原始格式。因此,加密是保護靜態與傳輸資料安全最有效的方法之一,可確保即使未經授權者存取資料,資料仍無法閱讀。 若要設計適當使用 Salesforce 解決方案中的加密: - **一律適當地加密傳輸中的資料**。Salesforce 針對在 [Salesforce 支援的瀏覽器](https://help.salesforce.com/s/articleView?id=sf.getstart_browser_overview.htm&type=5)中進行的所有工作階段[採用「傳輸層安全性」(TLS)](https://help.salesforce.com/s/articleView?id=sf.security_overview_infrastructure.htm&type=5),並要求使用 HTTPS 的撥出通話符合特定安全性標準。平台 API 預設也會使用 HTTPS。此外,Salesforce Experience Cloud 網站或入口網頁與其相關 Salesforce 組織之間傳送的資料 [預設](https://help.salesforce.com/s/articleView?id=xcloud.security_pe_platform_encryption_faq.htm&type=5)為在傳輸中加密。如果您使用 Salesforce 的[內建電子郵件服務](https://help.salesforce.com/s/articleView?id=sf.emailadmin_send_email_from_salesforce_overview.htm&type=5),則 Salesforce 用於 [傳送和嘗試傳送電子郵件](https://help.salesforce.com/s/articleView?id=sf.emailadmin_deliverability.htm&type=5)的傳輸層安全性 (TLS) 有預設層級。您至少應確保組織設定不低於預設設定,除非您有明確的業務理由。根據資料的分類和敏感度,請考慮利用透過 AWS Direct Connect 或 Salesforce Private Connect 與 Salesforce 的私人網路連線。這可確保您的資料不會周遊公用網際網路,而是會安全地透過私人網路連線來存取與整合使用者。 - **如果業務需要,請加密靜態資料**。Salesforce 提供不同的方式來加密靜態資料。 - **Hyperforce**。在使用 [Hyperforce](/docs/architect/zh-tw/fundamentals/guide/platform-multitenant-architecture#hyperforce) 的組織中,系統會靜態加密資料。您的組織加密由 Salesforce 管理。您無法建立 (或終結) 您自己的加密金鑰。 - **Salesforce Shield**。[Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) 可讓您加密 Salesforce 組織中其他層級的靜態資料,包括應用程式和資料庫層級。透過 Shield,您可以擁有租戶加密金鑰的完整管理功能,包括強大的「自帶金鑰」(BYOK) 選項。您也可以加密非結構化資料 (包括檔案、附件、搜尋索引和事件)。以 Hyperforce 為基礎的例項提供使用外部金鑰管理員的選項,可讓您自帶 AWS KMS。透過此功能,您可以完全控制用於加密和解密儲存在 Salesforce 中之資料的 KMS 內加密金鑰,進而增強安全性並符合您組織的合規性需求。 下方的[模式與反模式](/docs/architect/zh-tw/well-architected/guide/secure#資料安全性模式與防模式)清單顯示在 Salesforce 組織中正確 (和不良) 使用加密的外觀。在您建立之前,請使用這些項目來驗證您的設計,或找出進一步改善的機會。 若要深入瞭解 Salesforce 提供的加密工具,請參閱與安全性相關的 [工具](/docs/architect/zh-tw/well-architected/guide/secure#與安全相關的工具)。 ### 資料安全性模式與防模式 此表格顯示要在您的組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/trusted-data-security)探索更多資料安全模式。
模式 防模式
共用與可視性 在您的設計標準和文件中:
- 安全性矩陣概述每個使用者角色獲授權存取的資料
- 外部使用者和內部使用者會使用不同的資料存取標準 (若適用)
在您的設計標準和文件中:
- 設計標準與文件不存在或不包含安全性矩陣
- 如果安全性矩陣存在,則不會概述使用者角色的資料存取權
在您的組織中:
- 由於合規性需求,內部使用者的組織範圍預設值 (OWD) 為「公用讀取」,而內部使用者的 OWD 為「專用」,
- 外部使用者的 OWD 為專用
- 生成式 AI 僅會在使用者模式中運作,或為系統存取所選取的使用具有明確的業務理由
在您的組織中:
- 內部使用者的 OWD 設定為「專用」,但沒有業務理由,或內部使用者的 OWD 設定為「公用讀/寫」
- 外部使用者的 OWD 設定為「專用」以外的任何項目,無須業務理由
- 生成式 AI 在系統模式中運作,沒有業務理由
在 Apex 中:
- 所有程式碼存取資料 (SOQL/SOSL) 或執行資料作業 (DML/資料庫類別方法) 使用 共 用關鍵字
在 Apex 中:
- 共用共用關鍵字使用不一致
使用加密 在您的設計標準和文件中:
- 在傳輸和 (如有需要) 靜態時使用資料加密的個案明確且可探索
- 已批准的加密通訊協定會清楚列出
- 程式碼文件會清楚指出使用加密的位置以及使用哪些通訊協定
在您的設計標準和文件中:
- 批准的加密通訊協定不明確或未列出
- 未記錄程式碼,或文件不清楚在程式碼中使用加密的位置與方式
在您的組織中:
- 如果偵測到安全性風險需要更高的靜態資料保護,則 Hyperforce 或 Salesforce Shield 會提供靜態加密
在您的組織中:
- 業務需求需要更大的靜態資料保護,但不使用 Hyperforce 或 Salesforce Shield
在 Apex 中:
- 如果業務需求在傳輸中需要更高的資料保護,則整合涉及的所有程式碼都會使用 Crypto Class 方法執行邏輯,以在傳輸前加密資料,或在接收時解密資料
在 Apex 中:
- 業務需求在傳輸時需要更高的資料保護,但整合中涉及的程式碼會執行邏輯,而不會在傳輸前或收到時加密資料,或者會臨時使用「加密類別」方法
## 與安全相關的工具
工具描述組織安全性工作階段安全性資料安全性
Apex 加密類別在 Apex 中加密與解密資料X
API 存取控制管理 Salesforce API 和連線的應用程式存取權X XX
API 異常事件追蹤使用者進行 API 呼叫的異常X
瀏覽器安全性設定保護敏感資料並監視 SSL 憑證X
以憑證為基礎的驗證使用唯一數位憑證驗證個人XX
憑證與金鑰從 Salesforce 確認對外部網站的要求XX
程式碼掃描器掃描 Apex 程式碼以瞭解安全性漏洞XX
連線的應用程式透過 API 和標準通訊協定整合XX
認證填充事件追蹤使用竊取使用者認證的嘗試登入X
CSP 信任網站防止程式碼插入式攻擊 (例如跨網站指令檔)X
自訂登入流程控制使用者的登入業務流程X
客戶身分控制網站和應用程式登入和驗證X
Data Mask在 Sandbox 中自動遮罩敏感資料X
除錯記錄追蹤組織中發生的事件X
委派管理將有限的管理權限指派給非管理員使用者XX
裝置啟用驗證來自不受信任瀏覽器、裝置或 IP 範圍的登入X
增強型交易安全性攔截事件、監視和控制使用者活動X
欄位存取權在欄位級控制資料存取X
欄位稽核追蹤定義保留已歸檔欄位歷程記錄資料的原則X
欄位歷程記錄追蹤追蹤與顯示欄位歷程記錄X
Frontdoor.jsp允許存取現有工作階段識別碼和伺服器 URLX
Heroku ConnectHeroku 與 Salesforce 之間的雙向同步化X
Heroku Shield建立 HIPAA 或 PCI 規範的應用程式X
高度保證工作階段安全性針對敏感性作業要求額外安全性X
Identity Connect將使用者記錄對應至 Active Directory 帳戶X
身分驗證歷程記錄稽核使用者身分驗證嘗試X
整合使用者授權僅透過 API 授與資料與功能的存取權。XX
Lightning Login避免密碼變弱或忘記及帳戶遭到鎖定X
登入存取權允許支援使用者以另一位使用者的身分登入X
登入鑑識識別可能表示身分詐騙的行為X
登入歷程記錄監視組織和 Experience Cloud 網站登入嘗試X
行動裝置追蹤追蹤與監視行動裝置對您組織的存取權X
Mobile SDK在獨立行動應用程式內連線至 Salesforce PlatformXXX
監視使用者權限 (Shield)權限集與權限集群組變更XX
多因素驗證需要兩個以上的驗證方法才能登入XX
共同驗證強制執行 SSL 或 TLS 共同驗證
我的網域設定登入頁面與原則、SSO 和社交登入X
已命名認證指定端點 URL 和驗證參數X
OAuth 授權透過權杖交換授權用戶端應用程式存取 X
密碼原則設定密碼歷程記錄、長度和複雜度X
權限集指派到期設定權限集和權限集群組指派的到期XX
權限集事件監視對權限集和權限集群組所做的變更XX
權限集群組配套權限集以支援複雜的存取需求X
權限集控制使用者存取中繼資料、功能和應用程式的方式X
私人連線保護 Salesforce 與 Amazon Web Services 之間的安全整合X
設定檔控制登入 IP 範圍和登入時間X
即時事件監視在 Salesforce 中監視與偵測標準事件 X
遠端網站設定針對 Apex 或 JavaScript 呼叫註冊外部網站X
報告異常事件追蹤使用者執行或匯出報告的異常X
限制規則防止使用者存取不必要的記錄X
Salesforce 程式碼分析器透過 IDE、CLI 或 CI/CD 掃描程式碼,以確保程式碼符合最佳作法XX
範圍規則控制使用者可以看到的預設記錄X
Security Center檢視所有組織的安全性設定,並針對狀態變更設定警示XX
安全健康檢查識別安全性設定中的漏洞X
工作階段劫持事件透過竊取的工作階段識別碼識別未經授權的存取X
工作階段管理類別自訂已啟用工作階段的安全性設定X
工作階段安全性設定設定工作階段以防範惡意攻擊X
設定稽核追蹤追蹤管理員最近進行的設定變更X
共用設定在記錄層級控制資料存取X
Shield Platform Encryption加密靜態與傳輸中的敏感資料X
單一登入透過單一登入提供多個應用程式的存取權XX
跨網域身分管理系統 (SCIM)透過 REST API 管理跨系統的身分X
威脅偵測使用統計資料和機器學習來偵測威脅X
信任的 IP 範圍定義不需要額外驗證的 IP 位址X
使用者存取報告取得使用者物件、記錄和權限存取權的統一檢視XX
## 與安全相關的資源
資源描述組織安全性工作階段安全性資料安全性
共用結構指南深入瞭解存取工具、共用模式和使用個案X
設計標準範本為您的組織建立設計標準XXX
如何建立使用者安全性模型進一步瞭解使用者安全性模型XX
如何在 Salesforce 中實作最低權限原則瞭解如何在 Salesforce 中套用 PoLP 資料存取控制XX
監視使用者工作階段檢閱啟用的工作階段並結束可疑工作階段X
多因素驗證從 Salesforce 存取正式 MFA 資源X
權限集群組 (Trailhead)使用權限集群組進行操作XX
REST API 結構瞭解 REST API 詞彙與概念XXX
安全性與 SOAP API瞭解 SOAP API 詞彙與概念XXX
API 和內部系統使用者的安全性最佳作法由 API 使用者和安全內部系統使用者安全地存取 SalesforceX
安全性實作指南全方位瞭解 Salesforce 安全性XXX
安全性原則範本為您的組織設定安全性原則XXX
工作階段類型識別用於存取您組織的工作階段類型X
威脅建模基礎知識 (Trailhead)瞭解安全性威脅以及如何防止。X
## 告訴我們您的想法 協助我們讓 Salesforce Well-Architected 與您相關;進行我們的[調查](https://sfdc.co/bxNtvh)以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。 ## 簡介 Salesforce Well-Architected 代表來自 Salesforce 和整個生態系統的專家指引和最佳作法。感謝您對資源和 Knowledge 提供良好的架構。 我們每年會更新「良好結構描述」文件兩次。我們會在下一個維護期間,宣布如何貢獻至 Well-Architected。 您可以隨時提供對「Well-Architected」的回饋意見[](https://sfdc.co/bxNtvh)。 ## 告訴我們您的想法 協助我們讓 Salesforce Well-Architected 與您相關;進行我們的[調查](https://sfdc.co/bxNtvh)以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。 > [在此](/docs/architect/zh-tw/well-architected/guide/contributors)閱讀我們的更新排程。 ## 簡介 即使發生失敗,彈性解決方案仍可維持高品質的服務。如果效能降低或服務中斷,解決方案會快速且有效地復原。 解決方案的彈性以兩個關鍵品質為基礎: - **強度**:發生問題時,解決方案可承受並持續。 - **彈性**:解決問題後,解決方案會回到其理想狀態或形狀。 若要為您的解決方案建立彈性,您必須針對強度與彈性進行設計,以確保在發生計畫與非計畫變化的情況下可持續性與快速復原。 在技術環境中,請將系統或解決方案視為互相相依存的元件集合,以協調以執行共用目標。每個元件都有可能失敗。這些元件中的問題,從程式碼和組態瑕疵到網路和硬體問題,可能會導致非預期的非預期行為。當一或多個元件失敗時,系統會示範彈性行為,但整體系統會繼續運作或快速返回穩定狀態。 為了改善 Salesforce 解決方案的彈性,我們建議專注於三個重要習慣。 - [**應用程式生命週期管理 (ALM)**](/docs/architect/zh-tw/well-architected/guide/resilient#應用程式週期管理)—小組如何在整個生命週期中管理軟體,從計畫開始到淘汰 - [**事件回應**](/docs/architect/zh-tw/well-architected/guide/resilient#事件回應)—小組如何識別、解決和防止影響系統可用性或安全性的問題 - [**連續規劃**](/docs/architect/zh-tw/well-architected/guide/resilient#持續性規劃)—當非預定事件造成問題時,小組計畫其人員和系統如何繼續運作 ## 應用程式週期管理 應用程式週期管理 (ALM) 是一種從建立到淘汰整體管理軟體生命週期的作法。ALM 是系統彈性的基石,包含與應用程式生命週期相關的人員、程序、工具和學科。這些學科包括 DevOps 和傳送方法、可觀察性、測試策略、管治和 CI/CD。 當企業實作有效的 ALM 時,其小組會快速反應變更,且其應用程式會與不斷變化的業務需求保持一致,而不會影響穩定性或品質。 另一方面,若沒有健康的 ALM,小組在應用程式生命週期的每個階段都會面臨困難。 低 ALM 的症狀包括: - 緩慢且容易出錯的開發週期 - 密集且難以進行的部署 - 在生產和 QA 後環境中發現的高嚴重性問題或錯誤 - 幻燈或行為不一致的 AI 工作人員 - 穩定化版本所需的頻繁回復或 hot-fix 部署 由於 ALM 會觸及解決方案的幾乎每個層面,因此為您的解決方案建立明確且有效的 ALM 作法是您結構工作的關鍵部分。 透過專注在三個關鍵領域來建立更佳的 ALM 作法。 - [**發行管理**](/docs/architect/zh-tw/well-architected/guide/resilient#版本管理)—將變更規劃、排序、控制及移轉至不同的環境 - [**環境策略**](/docs/architect/zh-tw/well-architected/guide/resilient#環境策略)—如何在開發和測試期間在目標環境中使用和管理應用程式的策略 - [**訊號策略**](/docs/architect/zh-tw/well-architected/guide/resilient#訊號策略)—重要訊號和應用程式儀器的定義,用於在降級發生前偵測和修復系統內的故障 - [**測試策略**](/docs/architect/zh-tw/well-architected/guide/resilient#測試策略)—引導您規劃和執行測試的方式的原則和標準,以測量在 ALM 流程期間應用程式的成功程度 ### 版本管理 版本管理涉及規劃、排序、控制變更,以及移轉至一或多個環境。單一版本是一組計畫變更,小組同時移至目標環境。 將變更發佈至系統會對其造成風險。如果系統在變更之前處於穩定狀態,則系統會轉換為新狀態,其也會更容易受到未來變更的風險影響。如果任何未來變更觸發系統中未受控制且不穩定的狀態,則會導致重大事件。在解決方案結構中,針對彈性版本進行設計不僅僅是[有效測試個別變更](/docs/architect/zh-tw/well-architected/guide/resilient#測試策略)。這也涉及規劃如何安全地對您的系統和其使用者導入變更。 小組的工作取決於可預測且準確的版本資訊。在變更管理與啟用流程中,請清楚瞭解哪些變更會移入您的系統。在您的版本管理與啟用流程中,指定變更發佈至系統的方式及頻率。 您的業務專案關係人也會關注版本資訊,特別是與其要求的功能或錯誤修正相關的資訊。若要對您的解決方案建立 Trust 並向專案關係人展示價值,請建立一致且清楚的版本排程,並寄送穩定的版本成品。 若要為 Salesforce 建立有效的版本管理: - **與結構與開發管理緊密一致**。請確保已提前充分規劃發佈,以符合所有相關的管治論壇和控制。在開始開發之前,請先檢閱並批准 AI 委員會的所有已設定優先順序的 Agentforce 使用個案。取得由「法律與道德使用」小組檢閱的高風險 Agentforce 使用個案。使用部署檢查清單和文件來針對管治活動追蹤部署成品,例如 Agentforce Agentforce API 名稱。 - **請勿使用 [以組織為基礎的開發或發行流程](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)**。此範例反映開發與發行之較舊、更有限的技術。透過 Salesforce CLI,小組現在可以採用來源驅動的開發和發行功能。 - **選擇盡可能穩定的釋出機制**。此方法會完成兩個項目。首先,這會將版本時段和服務中斷的持續時間降到最低。其次,允許高度控制且可預測的版本行為。您的發行機制愈穩定,發行版本將會導入需要 hotfix 或回復的變更的可能性愈低。如果發生非預期的問題,穩定版本機制也會為支援人員或系統管理員建立更簡單的方式來執行回復。 您小組的最佳版本機制是最穩定的選項,讓您的小組具備所需技能。以下是建議的發行機制,依穩定性順序列出。它們彼此相容,因此如果最適合您的公司,請將多個相同使用。 - [**解除鎖定的封裝**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm)—解除鎖定的封裝是最穩定的版本成品。透過安裝封裝部署變更是導入變更的最快且最可預測的方式。封裝使用版本化,其允許強大的變更管理和微調、系統易於管理的回復。封裝需要強大的中繼資料管理,這可協助您及早識別受管理錯誤的相依性。他們也會建立可稽核的開發管道和成品。請參閱「[封裝性](/docs/architect/zh-tw/well-architected/guide/composable#可封裝性)」。 - [**DevOps Center**](https://help.salesforce.com/s/articleView?id=sf.devops_center_overview.htm&type=5)—DevOps Center 可讓具有低程式碼或專業程式碼技能集的傳送小組使用來源控制、針對變更進行協同合作,並定義常見的發行路徑。DevOps Center 與來源控制整合,並允許點選控制變更和部署。 - **使用 [Salesforce CLI](https://developer.salesforce.com/tools/sfdxcli) 進行來源驅動的開發和中繼資料部署**—如果您無法使用封裝,請將 Salesforce CLI 用於來源驅動的開發和中繼資料部署。請勿使用較舊的 package.xml 格式部署中繼資料,其結構與建議的 [來源格式](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm)不同。來源格式已開發以支援封裝開發、臨時組織工作流程,以及更精確的 Sandbox 變更追蹤。此格式更容易閱讀、允許更多複雜中繼資料類型與相依性的分離,並可讓您進一步控制部署資料清單。 - **命名您的版本**。提供版本清楚的識別碼,以協助您的小組和專案關係人保持一致。在 Salesforce 中,每個主要版本的名稱會以「Spring」、「Summer」或「Winter」開頭,後面接著是版本的年份 (例如「Summer ’25」。如果您還沒有在公司定義和組織版本的命名慣例,請建立並使用該慣例。使用清楚的版本名稱可讓您輕鬆地在整個小組系統的規劃、開發和傳送的各個階段保持井然有序。在您的[藍圖中](/docs/architect/zh-tw/well-architected/guide/intentional#路線圖)使用版本名稱,向利害關係人清楚地傳達即將進行的變更以及何時進行的變更。在文件、變更記錄、工作描述、程式碼註解和來源控制的分支中使用版本名稱,讓您可以輕鬆追蹤和稽核開發成品。 - **在版本資料清單中,請順利管理相依性**。Salesforce 中繼資料有內建的相依性。Salesforce 部署失敗的常見原因是未正確管理相依性。選擇穩定版本機制 (如先前所述) 可協助您在開發週期前期顯示受管理錯誤的相依性。解除鎖定的封裝是最穩定發行車輛的主要原因之一,是其強大的中繼資料管理,這是封裝開發和建立所需的。如果您或您的版本管理小組不瞭解 Salesforce 中繼資料類型之間的內建相依性,您將無法主動在部署與版本資料清單中發現有問題的組合。請參閱「[相依性管理](/docs/architect/zh-tw/well-architected/guide/composable#相依性管理)」。 ALM 的 [模式和反模式](/docs/architect/zh-tw/well-architected/guide/resilient#alm-模式與反模式)顯示 Salesforce 組織的正確與不良版本管理外觀。使用模式在您建立之前驗證您的設計,或識別系統中需要重新設計的位置。 若要深入瞭解 Salesforce 用於發行管理的工具,請參閱彈性的 [Salesforce 工具](/docs/architect/zh-tw/well-architected/guide/resilient#彈性-salesforce-工具)。 ### 環境策略 Salesforce 提供各種可供您在應用程式開發和測試週期期間使用的 [環境](https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm&type=5)。Salesforce 的有效環境策略需要瞭解如何使用環境以及良好的管理方式。在 ALM 中,開發或測試環境的實用程度取決於其對生產的忠誠度和與生產的隔離性。 良好的環境策略提供數個優點。 - 更忠於生產環境 - 更快速的環境設定與清除 - 在開發和測試中更敏捷 - 整個管道的安全性改善 - 在整個傳送階段中減少雜訊和衝突 - 更快樂的開發小組 小組經常難以實現這些優點。發揮開發環境和策略的挑戰可能來自多個來源。一個可能的來源是您小組遵循的開發模型類型。 在較舊的組織型開發方法中,每個環境都需要提供數個功能。除了您小組執行各種工作的地方外,它還需要是發行成品的來源 (亦即您想要在版本中部署的中繼資料)。由於環境無法輕鬆設定或拆除,因此環境經常過度擁塞,且在小組之間充滿中繼資料衝突,而且不會對整體 ALM 提供有意義的速度或彈性。 使用來源型開發模型會根本地改變環境與發行和發行成品之間的關係。在此模型中,來源控制項是您要釋出之中繼資料的來源。環境只是您小組執行工作的位置。 不過,遵循來源型開發模型並不僅能保證良好的環境策略。即使使用來源控制,小組仍難以設定條件來測試與外部系統的整合;依賴非來源控制的中繼資料組態,例如受管理封裝或依賴 [資料](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#中繼資料與資料)的自訂等。在某些情況下,來源型模型的挑戰與組織型模型的典型挑戰類似。 若要開發有效的環境策略: - **採用來源驅動的開發與發行模型**。停止使用 [以組織為基礎的開發](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)模型。請參閱 [發行管理](/docs/architect/zh-tw/well-architected/guide/resilient#版本管理)。)您必須將您的環境從您部署的內容中取消關聯,才能建立健康環境策略和更健康的版本。 - **瞭解每個環境支援的工作類型**。Salesforce 支援的環境類型有不同的功能與限制。當您設計環境策略時,請考量環境可以和無法執行的項目。請確保小組在具備所需功能的環境中進行工作。如需指引,請參閱此 Salesforce 開發環境及其功能的概觀。
臨時組織 Developer Sandbox Developer Pro Sandbox 複製 Sandbox 部分 完整 Sandbox
支援 組織形式 是 否 否 否 否
支援 來源追蹤 是 是 是 否 否
壽命 1–30 天 手動控制 手動控制 手動控制 手動控制
重新整理間隔 不提供 1 天 1 天 5 天 29 天
版本預覽支援 由開發人員控制 根據 Sandbox 例項 根據 Sandbox 例項 根據 Sandbox 例項 根據 Sandbox 例項
佈建時間 > 5 分鐘 小時或天數 小時或天數 小時或天數 小時或天數
中繼資料決定者 來源控制 生產 生產 生產 生產
資料決定者 手動資料載入 手動資料載入 手動資料載入 Sandbox 範本 生產
資料限制 200 MB 200 MB 1 GB 5 GB 與在生產環境中相同
請參閱此表格以瞭解哪些功能與環境可用於數個常見的開發工作。
工作 組織形狀 來源追蹤 經常重新整理 版本預覽支援 來自生產的所有中繼資料 來自生產的部分中繼資料 生產環境中的大型資料集 來自生產的部分資料集 相容環境
原型 X X X X X X X 臨時組織、開發人員與開發人員 Pro Sandbox
新功能調查或概念證明開發 X X X X X X X 臨時組織、開發人員與開發人員 Pro Sandbox
使用者接受度測試 X X X X X X Developer、Developer Pro 和 Partial Copy Sandbox
效能與規模測試 X X X 完整 Sandbox
使用者訓練 X X X X X* X Developer Pro、部分複製與*Full Sandbox
*如果完成特定類型工作的必要項目,請使用資源密集性較低的環境
此外,請注意,針對使用 Einstein 資料庫、Knowledge 文章和非結構化資料等功能的 Agentforce 工作人員,除非您擁有 Data 360 Sandbox,否則全面測試會受到限制。您也需要 Data 360 Sandbox 來確保準確的測試條件。 - **將環境與版本成品分離。**請勿使用 [以組織為基礎的開發](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)。將環境視為工作在固定時間內發生的位置。將環境中的中繼資料狀態視為與您的版本成品分開。如果程式碼或組態在環境中「解析」,則應認可來源控制,使其成為版本成品。 - 環境為臨時。建立流程,以便您可以盡快建立和終結流程。 - 成品持續不變。屬於來源控制。 - **將環境與發行路徑分離**。查看需要將變更部署至特定環境的必要版本路徑很常見。通常,此方法會實作以建立 Proxy 以驗證應用程式成熟度或版本穩定性。小組也可以使用它來嘗試將其必須設定複雜測試基礎結構的環境數量降到最低。在來源型範例中,您可以更有彈性地驗證和測試變更的方式和位置。 - 版本階段適用於版本成品,而不適用於環境。請勿建立環境只為了在特定版本階段中「收集」所有變更。這是來源控制 (尤其是分支) 的目的。使用來源控制中的分支策略來組織要部署至哪些環境的變更。視您需要執行的工作而定,您可能需要將版本中的所有中繼資料部署至環境。分支可讓您這麼做。除了某些例外,所有開發環境都必須在相關工作完成後立即重新整理或終結。確定您將在特定環境中進行的中繼資料變更 (且您想要保留) 同步至來源控制。 - 環境僅與其忠於生產力一樣有用。最佳化您的環境設定工作流程或自動化,以便您可以盡快拆除或重新整理環境。請將阻止您執行更快、更頻繁環境重新整理的任何組態視為對 ALM 流程整體彈性的重大風險。如果您有相關的補救工作,請將其新增至您的計畫並排定優先順序。探索如何在您的系統中採用較寬鬆連接的[模組化單位](/docs/architect/zh-tw/well-architected/guide/composable)。它們可讓小組在臨時組織中執行更多類型的開發,並可為其他工作釋出 Sandbox 配置。不要忘記臨時組織為您在生產環境中沒有的測試功能提供的功能,因為您尚未購買或啟用臨時組織的授權。 - 在業務使用者或一般使用者可存取的環境中,讓這些使用者專注於對其而言重要的項目。沒有一般、不區分的環境,讓許多不同的一般使用者或業務專案關係人嘗試執行 ALM 相關工作的群組。邀請特定利害關係人進入特定環境以執行特定工作。仔細評估將一般使用者或業務專案關係人放置在環境中的任何流程,其中包含的資料超過 Partial Copy Sandbox 可支援的資料。確定完成工作時需要資料量。規劃您的使用者接受度測試和早期開發週期,讓這些週期盡可能密切相同。最佳化所有測試階段,以針對您的開發小組和一般使用者啟用更快、更早的回饋意見和反覆循環。請參閱 [測試策略](/docs/architect/zh-tw/well-architected/guide/resilient#測試策略)。 - **針對不同類型的變更建立不同的版本路徑**。並非所有變更都需要以相同的順序完成相同類型的 ALM 工作。讓一般使用者針對系統後端元件的小型變更執行接受測試可能不是使用時間的好方法。然而,在行動應用程式的早期開發階段期間,使用者接受度與規模測試會非常有價值。識別不同種類變更的版本路徑,例如高度風險、中度風險和低度風險。 - **高度風險:**變更會影響客戶、合作夥伴或所有內部使用者。變更會影響安全性或整合。變更會新增複雜的新功能。 - **中度風險:**變更會影響的內部使用者超過已定義的值。變更會影響資料模型、執行資料作業的自動化或整合。 - **低度風險:**直接影響的值低於內部使用者的已定義值。不包含安全性的變更、資料模型或涉及資料作業或整合的自動化。 - **請勿允許擁擠的環境存在**。在排定優先順序、設定範圍和排序工作方面缺乏規律,導致開發環境過度繁重,工作量過多、過多、過多。擁擠的環境會在開發小組之間造成高層級的壓力、不明確性和衝突。他們也會在開發管道內產生雜訊,並阻礙品質控制工作。除了這些負面影響之外,過度擁塞的開發環境對環境維護和安全性也構成嚴重威脅。請將過度擁塞視為 ALM 流程中潛在問題的症狀。調查任何根本原因問題並加以解決。如果您仍然面臨擁塞,您可以[購買額外的 Sandbox](https://help.salesforce.com/s/articleView?id=sf.data_sandbox_environments.htm&type=5)。 ALM 的[模式與反模式](/docs/architect/zh-tw/well-architected/guide/resilient#alm-模式與反模式)清單顯示 Salesforce 組織中的適當與不良環境管理外觀。使用這些選項在您建立之前驗證您的設計,或識別需要重新設計的系統區域。 若要深入瞭解環境管理的 Salesforce 工具,請參閱彈性的 [Salesforce 工具](/docs/architect/zh-tw/well-architected/guide/resilient#彈性-salesforce-工具)。 ### 訊號策略 訊號策略會定義偵測、診斷和修復失敗所需的關鍵訊號和應用程式儀器,然後再串聯至全系統降級。有效的儀器處理可將應用程式從被動失敗的受害者轉換為活躍的參與者,以其自己的彈性來偵測問題、調整其行為,並在必要時協調慷慨降級。 當應用程式實作全方位儀器時,他們能夠在壓力下自行調節、向操作員傳達健康狀態,並參與協調的復原工作。這些功能可讓系統在個別元件遇到麻煩時,維持服務品質。另一方面,若沒有適當的儀器處理,應用程式會變成黑色方塊,直到出現災難性症狀為止會無聲地失敗。小組只有在使用者回應問題後才會做出回應,且疑難排解會成為考古中的演練,而非觀察。 - **偵測應用程式內的失敗**。應用程式必須自行儀器化,以偵測並回應在負載中出現的常見失敗模式。請考慮排列飽和度。當訊息的填入比處理的速度更快時,未經工具處理的應用程式會繼續接受工作,直到發生記憶體耗損或逾時的階層為止。正確儀器化的應用程式會監視排列深度、拒絕率和處理延遲,在超過值時觸發防禦回應。 - **有效處理應用程式外部的訊號**:作業系統中訊號的處理代表另一個重要儀表點。應用程式必須為終止訊號 (SIGTERM、SIGINT) 註冊處理常式,才能啟用寬鬆關機。在關閉期間,正確儀器化應用程式會停止接受新工作、允許完成即時要求、清除緩衝時間、清除連線,以及取消註冊服務探索。此協調式關機可防止資料遺失,並允許載入平衡器在不中斷的情況下重新導向流量。 - **複雜失敗案例的工具:**除了這些基本模式之外,應用程式必須針對更微妙的失敗模式進行儀器操作。識別灰色失敗,其中元件在某些觀察者看起來健康,而在其他觀察者看起來失敗,需要同時建立內部與外部訊號的關聯。應用程式可能會使用其資料庫連線集區來報告成功的健康檢查,同時追蹤顯示流失降級的交易完成率。有效的儀器策略會分層多個觀察點。 - **業務度量**可追蹤應用程式特定成功指標,例如訂單完成率或搜尋結果品質。 - **系統度量**會監視資源利用率、延遲分佈和錯誤率。 - **合成探測器**會持續執行重要路徑,以在使用者遇到降級之前偵測降級。 - **散佈式追蹤**可提供跨服務界限的要求層級可視性。 這些訊號透過標準化介面公開,允許自動化系統與人類操作員評估應用程式健康狀況。此儀器本身會成為應用程式彈性策略的一部分,讓斷路器能夠根據錯誤率出差、自動刻度器能夠回應排列深度,以及[操作員能夠在事件期間做出明智的決策](/docs/architect/zh-tw/well-architected/guide/resilient#事件回應)。 ALM 的 [模式和反模式](/docs/architect/zh-tw/well-architected/guide/resilient#alm-模式與反模式)顯示 Salesforce 組織中正確和不良的訊號策略呈現的外觀。使用這些選項在您建立之前驗證您的設計,或識別需要重新設計的系統區域。 若要深入瞭解訊號策略的 Salesforce 工具,請參閱彈性的 [Salesforce 工具](/docs/architect/zh-tw/well-architected/guide/resilient#彈性-salesforce-工具)。 ### 測試策略 測試策略是一組指引原則和標準,用於規劃和執行測試,以測量 ALM 流程期間應用程式的成功與失敗。測試策略可讓參與測試的每個利害關係人持續掌握並符合指定測試的優先順序、目的和範圍。這也會協助專案小組建立有效且謹慎的測試計畫。 通常,開發人員或品質保證和測試專家會參與建立和執行特定測試。測試策略有助於確保這些人員知道指定專案需要執行的測試類型,以及要執行的順序。測試策略也有助於確保小組擁有建立整齊測試、測試計畫和成品所需的功能 (例如測試資料集、裝置和流量或網路模擬器)。 有效的測試策略可讓您清楚瞭解如何、何時、何處以及為何在各種組合和條件中執行不同的測試類型,包括單元測試、UI 測試和迴歸測試,以發現系統和任何飛行中變更將如何運作。有效的測試策略會產生測試,以向您展示系統是否符合非功能需求 (例如可擴展性、可靠性和可用性),這可能難以透過單一類型的測試來測量。 建立 Salesforce 的有效測試策略: - **盡可能以反覆、頻繁且透過自動方式進行測試**。設計並實作測試自動化,讓小組能夠針對各種工作量執行各種測試類型。協調各種測試回合,以在變更進入來源控制時自動執行。此方法可讓小組主動識別並及早處理迴歸。如果可以的話,請針對此工作使用連續整合/連續傳送 (CI/CD)。如果您沒有,請建立明確的測試計畫,讓小組以自助方式及早且經常執行測試序列。針對 Agentforce 工作人員測試,請依賴測試中心來對具有各種輸入的 AI 工作人員進行嚴格的批次測試,以確保其在不同案例之間正確運作。 - **請注意,並非每個變更都需要每種類型的測試**。就像有效的發行管道能容納高、中和低風險應用程式的路徑一樣,有效的測試策略也是如此。為小組清楚概述如何為具有各種風險、使用個案或複雜性的應用程式選取並遵循適當的測試模式。請參閱「[環境策略](/docs/architect/zh-tw/well-architected/guide/resilient#環境策略)」。 - **定義可在不同環境類型中執行的測試**。對生產的忠誠度是準確測試的關鍵元件,但這對於不同類型的測試而言意味著不同的項目。例如,迴歸測試在中繼資料和部分資料方面需要忠於生產環境。請務必定義指定測試集所需的生產忠誠度類型,並清楚分類哪些類型的環境可以支援適合不同測試的條件。如需符合每個環境類型之工作類型的概觀,請參閱「[環境策略](/docs/architect/zh-tw/well-architected/guide/resilient#環境策略)」。 - **使用耐用度、壓力、效能和規模測試來持續測量應用程式成熟度**。這些測試顯示應用程式相對於生產層級需求的發行準備方式。針對主要新功能,請在應用程式開發週期中以數個間隔執行這些測試。將這些測試視為僅為單一開發階段或階段的一部分,而非為進行中工作的一部分,是反模式。小組最有用的是提早且經常取得有關應用程式效能的回饋意見,這有助於小組更進一步瞭解應用程式在生產層級整備前的距離或距離。能夠在變更進入生產環境前更進一步識別並解決問題,值得經常執行更複雜的測試來增加複雜性。 - **瞭解哪些測試很重要**。您可能會有固定的時間執行規模或效能測試,因此測試系統的每個面向並不實用。並非所有功能都會平均使用,且並非所有規模瓶頸都會平均影響業務。請確保您的刻度測試專注於系統中最常使用且高價值的部分。定義並瞭解驗證和改善組織規模與效能最重要的機會。 - **瞭解「good enough」的外觀。**定義規模與效能測試的成功條件十分重要。請確保您與開發小組使用成功條件作為測試基準。此外,請確保他們會告知開發小組建立的功能需求。這些條件通常包括支援少於協議值之回應時間的特定同時使用者數目,以及您的 [服務層級目標 (SLO)](/docs/architect/zh-tw/well-architected/guide/resilient#復原時間)。定義關鍵目標條件,然後設計規模和效能測試以確保符合條件。 - **確定您擁有適當的環境。**規模和效能測試需要對生產的特定忠誠度。您在非生產環境中的資料集、要求人口、要求率和工作量特性都應盡可能與您在生產環境中看到的內容相符。針對規模測試,您必須使用完整 Sandbox。如果您的組織沒有完整 Sandbox 供規模測試使用,則您無法執行適當的規模測試。 - **確保測試工作量可協助您測量非功能需求**。請記得考量: - **測試資料** \- 針對與生產組織隔離的資料,應執行各種測試。在 Apex 單元測試中,實作 [資料工廠模式](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_utility_classes.htm)以確保程式碼產生自己的測試資料,並與環境資料隔離。您也可以建立和維護各種格式的測試資料集,以測試資料載入行為、使用以 UI 為基礎之測試的資料填入開發環境,並協助進行整合測試。所有測試資料,無論是作為外部化資料集維護或依需求透過資料工廠程式碼建立,都應清除敏感且可識別的資料。其應包含損毀、不完整和格式錯誤的資料,以支援負值和邊界單元測試行為。 - **模擬與實作服務** \- 針對整合測試,您可以使用模擬與實作服務來模擬 API 回應。Apex 支援建立模擬架構以用於 Apex 測試的 [Stub API](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_stub_api.htm)。模擬以建立可用於 Apex 測試的模擬架構。模糊與實體可協助驗證系統的資料處理行為,並減少對複雜資料工廠或外部測試資料集的依賴。模糊與虛線有時更適合用於與生產類似的流量或資料量無關的測試。 - **裝置與輔助技術**—建立具有[吸引力的](/docs/architect/zh-tw/well-architected/guide/engaging)和可[存取](/docs/architect/zh-tw/well-architected/guide/compliant#無障礙)應用程式的關鍵部分,就是確保這些應用程式符合各種裝置與不同類型的輔助技術的使用者期望。有效執行有意義的可用性測試可能需要更多投資和不同類型的專業知識,但瞭解使用者面向應用程式發行時結構的程度至關重要。 - **模擬器** \- 當您需要複製類似生產的使用者要求、API 流量或網路速度變化時,可能需要模擬這些條件的工具。並非每個測試都需要此層級的投資。這些工具在延展性和效能測試中通常最有用。 - **AI 與工作人員測試**-測試的主要目標是減少 AI 幻覺,其為令人信服且不正確的回應。確保已測試 AI 使用個案,以醒目提示由於對客戶不完整瞭解、遺漏資料、具有不完整中繼資料的欄位,以及過時資料所導致的常見問題。使用測試中心協助建立此類測試的必要測試資料。 ### ALM 模式與反模式 下表顯示要在您的組織中尋找或建立的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/adaptable-application-lifecycle-management)探索更多 ALM 的模式。
模式 防模式
發行管理 在生產環境中:
- 中繼資料顯示使用穩定版本機制,例如:
-- 將中繼資料組織為解除鎖定的封裝
-- DevOps Center 已啟用並安裝
-- 透過使用來源格式的中繼資料 API 進行部署
- 部署記錄在可用歷程記錄內不會顯示失敗的部署。
- 部署歷程記錄會顯示清楚的版本步調,以及版本視窗內相當統一的部署叢集。
在生產環境中:
- 中繼資料表示使用以組織為基礎的發行機制,例如:
-- 主動使用變更集
-- 透過中繼資料 API 進行的部署使用 package.xml 格式
- 部署記錄會在可用歷程記錄中顯示失敗部署的重複例項。
- 部署沒有可辨識的步調或顯示不平均的部署叢集,這表示有熱修復和臨時回復)。
- DevOps Center 未啟用且未安裝。
在您的藍圖和文件中:
- 版本名稱清楚。
- 功能會明確繫結至特定已命名版本。
- 版本名稱可搜尋且可探索。
- 小組可以找到並遵循明確的原則來標記具有正確版本名稱的成品、開發項目和其他工作。
- 您可以透過版本名稱來提取版本資料清單的清晰檢視。
- 系統會針對不同的開發階段,定義生成式 AI 應用程式的品質水準。
在您的藍圖和文件中:
- 不包含版本名稱。
- 功能未明確繫結至特定版本。
- 版本名稱為特殊使用或不存在。
- 小組以不同的方式參照物件、開發項目和其他工作。
- 無法使用版本名稱來提取版本資料清單的清晰檢視。
- 系統不會定義生成式 AI 應用程式的品質界限,或者如果已定義,則不會定義不同開發階段的品質界限。
環境策略 在您的組織中:
- 採用來源驅動的開發和版本模型。
- 已針對 Developer 與 Developer Pro Sandbox 啟用來源追蹤。
- 指定環境中的中繼資料獨立於版本成品。
- 環境不會直接對應至釋出路徑。
- 變更的發行路徑取決於變更的類型 (高度風險、中度風險或低度風險)。
- 不存在擁擠的環境。
- 永遠不會直接在生產環境中進行有風險的組態變更。
- 在營業時間高峰期間不會發生發行。
- Data 360 Sandbox 用於適當測試需要 Einstein 資料庫、Knowledge 文章和非結構化資料的代理使用個案
在您的組織中:
- 採用以組織為基礎的開發和版本模型。
- 未針對 Developer 與 Developer Pro Sandbox 啟用來源追蹤。
- 指定環境中的中繼資料是版本成品。
- 環境會直接對應至釋出路徑。
- 無論變更類型為何,每個變更的版本路徑皆相同。
- 存在的環境過度擁塞。 - 直接在生產環境中進行有風險的組態變更。
- 發行會在營業時間高峰期間發生。
- 不會使用 Data 360 Sandbox 測試需要 Einstein 資料庫、Knowledge 文章和非結構化資料的 Agentforce 工作人員
訊號策略 在您的組織中:
- 小組可協同合作定義和標準化健康檢查 API 和 SLO。
- 定期審查和精簡訊號策略是死後與營運整備審查的一部分。
在生產環境中:
- 會針對所有應用程式實作健康檢查。
- 應用程式會提供有關其健康狀況 (例如載入與功能) 的明確訊號。
- 應用程式的設計目的為在相依性不良時順利降級。
- 載入分割用於防止串聯失敗。
在您的設計中:
- 反壓力與負載機制可防止服務遭到流量溢出。
- 系統會假設相依性最終會失敗。訊號處理常式是為了減輕失敗而建立。
在您的組織中:
- 小組在孤立作業中,建立不一致且不相容的健康訊號機制。
- 訊號策略是事後考量,只有在事件發生時才會處理。
在生產環境中:
- 元件會無訊息表示其健康狀態的情況下無聲失敗。
- 應用程式會無限期重試對不健康服務的要求。
- 所有要求都會以相同的優先順序處理,無論其重要性為何。
- 為了找出問題,運算子僅依賴反應性措施,例如使用者抱怨或重大系統故障。
在您的設計中:
- 假設所有相依性一律可供使用,且不會考慮網路分割、延遲高峰或其他常見問題。
- 應用程式接受所有傳入要求,即使應用程式載入過多,進而導致延遲增加且失敗的可能性更高
測試策略 在您的業務中:
- 可用性測試採用各種裝置和輔助技術。
- 模擬器用於複製類似生產的條件,以進行延展性和效能測試。
- 測試會在變更進入來源控制時自動執行。
- 應用程式開發週期中的多個間隔執行耐力、壓力、效能和規模測試,並將其視為進行中的工作。
- 當您擁有 B2C 規模應用程式、大量使用者或大量資料時,您可將刻度測試納入 QA 流程的一部分。
- 您的刻度測試專注於系統的高優先順序層面。
- 您的刻度測試具有已定義的條件。
- 您在完整 Sandbox 中執行規模測試。
- 提示工程包含人類的品質檢閱。
- Agentforce 測試中心用於強大的工作人員測試。
在您的業務中:
- 不會執行可用性測試,或者如果是,則會在有限的裝置上執行。
- 不會測試類似生產的使用者要求、API 流量和網路速度變化。
- 測試自動化未準備就緒。
- 耐力、壓力、效能、刻度測試視為開發階段。
- 您不會在 QA 流程中執行刻度測試,且擁有 B2C 刻度應用程式、大量使用者或大量資料。
- 您的刻度測試未排定優先順序。
- 您的刻度測試沒有正確定義的條件。
- 您在 Partial Copy 或 Developer Sandbox 中執行刻度測試。
- 提示工程不包括人類的品質檢閱。
- Agentforce 工作人員未經測試,或僅使用工作人員產生器進行臨時測試。
在您的組織中:
- 所有測試資料都會清除敏感且可識別的資料。
在您的組織中:
- 測試資料與生產資料相同。
在 Apex 中:
- 資料工廠模式用於單元測試
- 用於模擬 API 回應的模擬程式與實體。
在 Apex 中:
- 單元測試依賴組織資料。
- 未使用粗體及粗體。
在您的設計標準和文件中:
- 環境會依其支援的測試類型進行分類。
- 根據風險、使用個案或複雜度指定適當的測試模式。
在您的設計標準和文件中:
- 每個環境支援哪些測試類型並不清楚。
- 測試模式不會依風險、使用個案或複雜度分類。
## 事件回應 在安全性和網站可靠性工程 (SRE) 中,事件回應著重於小組如何識別和解決影響系統整體可用性或安全性的事件,以及小組如何處理根本原因並防止未來的問題。事件回應涉及即時和發生問題後解決問題所需的流程、工具和組織行為。 身為結構設計師,您可能不是監視解決方案上線後每日作業的人。彈性結構設計的一部分是設計復原功能,讓支援小組能夠執行第一層診斷、穩定化系統,並有效地將調查和根本原因緩解移交給開發或維護小組。每天直接支援使用者的小組可能對系統結構沒有深入的瞭解或專業知識。這些小組必須具備監視每日作業、在診斷潛在事件時從系統存取資訊,並作為影響可用性的任何問題的有效第一個回應者所需的工具和流程。 您可以專注於您的[復原時間](/docs/architect/zh-tw/well-architected/guide/resilient#復原時間)、[分級能力](/docs/architect/zh-tw/well-architected/guide/resilient#能夠分級),以及[監視和警示](/docs/architect/zh-tw/well-architected/guide/resilient#監視與警示),以改善小組在 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 天內測量」。 - **定義並標準化復原策略。**變更回復和因應措施實作可協助讓系統再次正常運作,並將事件的影響降到最低。記錄可由支援或作業小組的適當成員執行的復原策略和通訊協定。復原策略會根據事件類型而有所不同。下表顯示將事件類型對應至復原策略的一般架構。如需識別失敗點和定義緩解策略的詳細資訊,請參閱「[可用性](/docs/architect/zh-tw/well-architected/guide/reliable#可用性)」。
事件類型 外觀觸發 復原策略
系統缺勤 損毀的登入或帳戶存取權的問題 帳戶復原原則
服務無法使用 啟用冗餘的備份服務;手動因應措施
生產程式錯誤 最近變更 先前版本的部署回復或取消部署
新的無法解釋錯誤 手動因應措施、停用非必要功能、升級至 SME
- **定義清楚結束條件**。使用您的 SLO 判斷您的系統何時處於事件或影響狀態外。 - **定義事件後審查和根本原因修復的流程。**請在服務還原後花時間檢閱事件。在檢閱期間,採取一種*無罪的死後*方法。與利害關係人合作,專注於建立關於發生*事項*和發生*方式*的清楚事實,而不是嘗試將錯誤或責任指派給個人。使用不同的檢閱格式來檢查如何在長期內解決問題。 - *動作後審查*專注於事件的回應。評估是否有適當的回應流程和策略很有用。 - *根本原因分析*專注於事件的根本原因。這可協助識別導致事件的系統設計和實作中任何錯誤或問題。 - **定期實作協議的復原通訊協定**。實作復原通訊協定,以確保每個人都瞭解如何妥善處理事件。使用 Sandbox 和測試環境,為小組提供練習事件模擬和復原的空間。也請練習事件後審查。執行所有這些作法可讓復原成為您工程和支援文化的一部分。 事件回應的 [模式和反模式](/docs/architect/zh-tw/well-architected/guide/resilient#事件回應模式與反模式)會顯示在 Salesforce 解決方案中優先處理復原的結構。使用這些選項在您建立之前驗證您的設計,或識別需要重新設計的系統區域。 若要深入瞭解可協助修復時間的 Salesforce 工具,請參閱 [Salesforce 彈性工具](/docs/architect/zh-tw/well-architected/guide/resilient#彈性-salesforce-工具)。 ### 能夠分級 在技術環境中,分級涉及為問題和支援要求指派種類和嚴重性層級。無論您的解決方案計畫程度如何,使用者支援問題和要求都會發生。這些問題可能來自缺乏足夠的訓練或變更管理、UI/UX 缺口、非預期的一般使用者行為,以及未被 [監視或警示](/docs/architect/zh-tw/well-architected/guide/resilient#監視與警示)抓到的緊急系統問題。 支援和作業小組必須能夠有效率地調查使用者支援查詢並快速診斷。將問題分級以篩選出較不嚴重的疑慮,並快速找出重要的系統事件是這些小組的關鍵能力。排序不良會使所有層級的使用者支援速度變慢、延長重大事件,並增加客戶和業務進一步中斷的風險。 雖然您可能不參與日常作業和支援,但身為結構設計師,您有責任協助確保您的支援和作業小組能夠有效地在 Salesforce 平台上建立的任何解決方案中分級問題。 若要讓小組有效地分級 Salesforce 解決方案中的問題: - **確保支援小組可存取實用資訊**。 - **記錄您的系統和設計模式**。確保解決方案的可[讀性](/docs/architect/zh-tw/well-architected/guide/intentional#可讀性)和一致性是讓支援人員瞭解負責支援的系統的重要部分。在您的文件中,請考量小組如何尋找有關如何排定系統不同部分問題或事件優先順序的資訊。此外,請確保小組可以根據影響區域快速取得有關復原策略的技術資訊。針對常見 Agentforce 問題 (例如主題分類和動作選取) 提供相關的疑難排解指南,可協助小組快速分級與權限或組態相關的問題。 - **設計時請謹記除錯**。支援小組和組織管理員必須啟用除錯和診斷,才能在各種環境中正確地分級使用者問題。*除錯易用*模式的範例包括將記錄和自訂錯誤訊息納入整個系統的執行路徑。透過如事件記錄和工作人員產生器的推理檢視等工具,啟用常見 Agentforce 除錯方法的支援小組。 - **識別事件的 SME 和利害關係人**。建立應可支援事件復原的相關 SME 或利害關係人清單,以及應在事件後分析期間參與的利害關係人清單。 - **謹慎處理手續**。確保在上線過程中,每個解決方案轉送給支援或作業小組的品質。為支援人員提供訓練,以逐步完成相關的系統結構和模擬事件回應逐步解說。請思考事件後處理,包括小組應如何記錄記錄或個案備註未獲取的資訊,以及事件回應者如何貢獻至根本原因調查或針對任何補救措施執行使用者接受度測試。 - **若您被諮詢,請讓所有人專注於復原作為首要考量**。 - **快速回應**快速回應任何使用者支援要求、監視通知和您收到的警示。 - **協助區分症狀與問題。**工作以判斷是否有需要處理的實際系統事件。嘗試識別具有實際問題的元件。協助確保遵循協議的 [復原策略](/docs/architect/zh-tw/well-architected/guide/resilient#復原時間),以快速將系統從事件狀態中移出。 - 針對支援重要使用個案的 Agentforce 工作人員,請確保已具備可行且相關的因應措施,並可在短時間內開啟作為冗餘措施。範例包括切換至手動處理或重新導向至相關文件以手動檢閱。 事件回應的[模式和反模式](/docs/architect/zh-tw/well-architected/guide/resilient#事件回應模式與反模式)顯示如何在 Salesforce 解決方案中進行有效分級的結構。使用這些選項在您建立之前驗證您的設計,或識別需要重新設計的系統區域。 若要深入瞭解 Salesforce 工具以協助分級,請參閱 [Salesforce 工具以提高彈性](/docs/architect/zh-tw/well-architected/guide/resilient#彈性-salesforce-工具)。 ### 監視與警示 *監視*和 *警示*是網站可靠性工程中廣泛使用的詞彙。在系統彈性的情況下,監視會持續評估系統的目前狀態,而警示會自動通知利害關係人關於關於系統狀態的潛在疑慮。有效的監視與警示是將系統規模與成長與支援人員規模與成長分離的重要部分。 Salesforce 提供各種內建功能,可監視系統中的行為。Salesforce 也提供附加元件或作為 [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) 一部分的 [即時事件監視](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/real_time_event_monitoring_overview.htm)。在任何 Salesforce 解決方案中,針對監視與警示所建立的設計提供: - 自動事件回應的功能 - 在正確的時間將相關資訊提供給正確的使用者 - 清除歷程記錄檢視和趨勢分析的資訊 若要設計 Salesforce 解決方案內的有效監視與警示: - **優先處理自動化**。雖然通知使用者有關重要狀態變更是保持系統穩定和作業的關鍵部分,但在理想的結構中,系統會盡可能自行修正問題,並僅針對緊急且無法復原的問題傳送警示。即使沒有自我修正功能,自動化也可以讓您的警示和報告更有用。 - **從 Salesforce 已提供的內容開始**。Salesforce Platform 提供相關的記錄和 API,可讓您監視解決方案在管理員限制中執行的作業。此外,平台會針對管理員限制違規和類似問題傳送警示。使用這些記錄和警示作為探索如何更完全自動化系統自助復原、事件報告和警示的基礎。例如,您可能會實作監視記錄的自動化,然後在記錄特定類型的事件時採取復原動作。 - 以可預測的方式對系統狀態的變更進行**分類**。針對您要監視和報告的主要狀態建立具體且有意義的種類。將這些種類與您定義的種類保持一致,以管理您[應用程式元件中的](/docs/architect/zh-tw/well-architected/guide/composable#州省管理)狀態。針對您處理狀態變更資訊的方式,採用以 [API 為導向](/docs/architect/zh-tw/well-architected/guide/composable#api-管理)的心態。一致的訊息格式和狀態種類可簡化自動化、報告和警示。 - **讓自動化邏輯與系統的其他部分保持一致**。如果您已建立適當的自動化 [錯誤處理方式](/docs/architect/zh-tw/well-architected/guide/automated#錯誤處理),您可以將這些模式延伸至分類狀態變更和使用自動化回應的方式。針對視為可復原的狀態變更,您可以自動化重試行為。針對視為嚴重或致命的狀態變更,將警示自動傳送給使用者。 - **避免產生雜訊**。當使用者收到太多警示時,尤其是不需要採取任何動作的警示時,他們會開始停用或忽略所有警示。此情況會破壞建立 [實用](/docs/architect/zh-tw/well-architected/guide/engaging#實用)警示的任何努力。若要進一步確定接收警示的人員範圍、觸發它們的原因以及觸發它們的時間,請考慮進行下列動作。 - **建立利害關係人地圖**。若要確保您的系統在正確的時間將正確的警示傳送給正確的利害關係人,請先識別並分類您的利害關係人群組。 - **根據使用者權限路由訊息**。僅將警示傳送給具有回應能力和權限的收件者。業務使用者可能會受益於可透過修正其擁有存取權之記錄中的問題來修正之問題的相關警示。如果問題需要更積極的技術回應,則警示應導向至支援人員。 - **讓預期回應清楚**明確。僅在需要人力介入的情況下傳送警示。結構化訊息以清楚指出要從收件者採取的動作。如果您傳送警示給利害關係人以取得可視性,且他們不需要採取任何動作,請在他們收到的訊息版本中明確說明。 - **讓警示及時且相關**。作為回應已發生且仍需要補救的失敗而傳送的警示) 不如有關潛在失敗的警示有幫助。理想情況下,支援人員會在系統中出現問題狀況時立即收到警示,以便在問題對業務營運造成負面影響之前[分級](/docs/architect/zh-tw/well-architected/guide/resilient#能夠分級)問題。 [模式和反模式](/docs/architect/zh-tw/well-architected/guide/resilient#事件回應模式與反模式)清單顯示如何在 Salesforce 解決方案中進行有效監視和警示的結構。使用這些選項在您建立之前驗證您的設計,或識別需要重新設計的系統區域。 若要深入瞭解用於監視和警示的 Salesforce 工具,請參閱彈性的 [Salesforce 工具](/docs/architect/zh-tw/well-architected/guide/resilient#彈性-salesforce-工具)。 ### 事件回應模式與反模式 此表格顯示要在您的組織中尋找或建立的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/adaptable-incident-response)探索更多事件回應的模式。
模式 防模式
復原時間 在您的業務中:
- 系統會定期實作復原通訊協定。
- 小組瞭解他們在生產環境中擁有且負責的服務。
- 小組瞭解相關工具以支援問題的診斷。
在您的業務中:
- 復原通訊協定不存在或未定期執行。
- 不清楚哪些小組在生產環境中擁有並負責不同的服務。
- 小組沒有工具的指引或標準來支援問題的診斷。
在您的文件中:
- 系統會依事件類型與觸發定義及分類復原策略。
- 事件回應的結束條件包含在 SLO 中且清楚明確。
- 事件期間增加權限的啟用條件和指派邏輯已清楚明確。
- 事件回應權限集與授權會清楚列出。
- 存在疑難排解指南,協助識別和診斷常見問題。
在您的文件中:
- 事件回應會臨時執行。
- 不存在事件回應的結束條件。
- 未指派增強權限,或如果是,則會臨時指派權限。
- 事件回應權限集與授權未列出。
在您的組織中:
- 存在以工作階段為基礎的事件回應權限集,且可在復原期間指派給支援人員。
- 「設定稽核追蹤」顯示指定的復原測試人員在協議的時間登入測試環境,並遵循復原測試指令檔。
在您的組織中:
- 以工作階段為基礎的權限集不存在於事件回應中,否則支援人員不獲授權使用。
- 「設定稽核追蹤」顯示指定的復原測試人員未登入測試環境或未遵循復原測試指令檔
在測試計畫中:
- 復原測試的測試指令檔存在且可重複。
- 系統會清楚列出事件模擬的環境。
在測試計畫中:
- 不存在用於復原測試的測試指令檔。
- 未建立事件模擬的環境。
能力分級 在您的業務中:
- 在事件發生前,會識別應警示支援複雜問題的中小型企業或利害關係人。
- 交付與支援小組之間的交談是上線的一部分。
- 如有諮詢,Salesforce 結構設計師可快速回應並協助小組專注於復原。
在您的業務中:
- 在事件發生之前,不會識別應警示的 SME 或利害關係人。
- 傳送小組與支援小組之間的交談不是版本流程的一部分。
- Salesforce 結構設計師會將事件回應視為其工作範圍外。
在您的文件中:
- 支援人員可以探索並閱讀指定解決方案中使用的系統和設計模式。
在您的文件中:
- 指定解決方案中使用的系統和設計模式無法供支援人員使用。
在您的組織中:
- 記錄和自訂錯誤訊息會納入整個系統的執行路徑。
在您的組織中: - 不使用記錄和自訂錯誤訊息。
監視與警示 在您的組織中:
- 警示僅用於通知使用者需要人力介入的情況;其他失敗會記錄並進行報告。
- 警示會傳送給能夠回應警示的使用者。
- 如果可能,會在可能失敗之前傳送警示。
在您的組織中:
- 當發生任何類型的失敗時會傳送警示,無論是否需要後續動作。
- 將需要技術解決方案之問題的警示傳送給業務使用者。
- 警示只會針對已經發生的失敗傳送。
在您的文件中:
- 系統會根據直接和間接生成式 AI 回饋意見度量定義提示調整警示的項目條件。
在您的文件中:
- 沒有針對生成式 AI 應用程式觸發提示調整警示的條件定義。
## 持續性規劃 業務彈性的一個關鍵是持續性規劃,其著重於如何讓人員和系統透過因非預定事件造成的問題運作。業務連續性計畫 (BCP) 會以人員為導向的方式檢視如何讓流程在危機中繼續進行。持續性計畫的技術層面包含在 BCP 的災害復原部分中。請參閱 [技術持續性](/docs/architect/zh-tw/well-architected/guide/resilient#技術持續性)。 若沒有適當的連續性計畫,您的組織現在可能會知道如何在危機或系統中斷期間採取動作,因此完全無法採取動作。無效的持續性計畫會對客戶、利害關係人和業務造成災難。在發生不良事件後,每個沒有維護或復原重要流程的時刻都會造成財務損害、聲譽損害、員工安全,甚至是法規合規性的風險。 您可以將精力專注在三個區域中,以在系統中建立更佳的連續性計畫:[定義 Salesforce 的業務連續性](/docs/architect/zh-tw/well-architected/guide/resilient#業務連續性)、[規劃技術連續性](/docs/architect/zh-tw/well-architected/guide/resilient#技術持續性),以及[建立備份與還原功能](/docs/architect/zh-tw/well-architected/guide/resilient#建立備份與還原功能)。 ### 業務連續性 您的公司可能已具備 BCP。如果是,請確定其中包含 Salesforce。如果貴公司沒有 BCP,請與您的專案關係人合作建立一個涵蓋您 Salesforce 組織的專案。 Salesforce 經常被視為在許多業務部門中客戶資料和重要業務流程的事實來源。因此,Salesforce 在 BCP 中扮演的角色可能與其他系統扮演的角色不同。Salesforce 可能會參與許多高優先順序的復原區域。 若要為 Salesforce 系統建立相關的業務連續性計畫: - **澄清復原的優先順序**。如同一般的 [事件回應](/docs/architect/zh-tw/well-architected/guide/resilient#事件回應)方法,復原在危機時必須是系統的首要任務。許多關鍵業務的服務都會在 Salesforce 中和 Salesforce 中執行。您必須協助利害關係人識別復原各種業務功能和功能的正確優先順序。一般架構可以是: - 穩定化重要的業務基礎結構。 - 穩定化客戶服務。 - 穩定化員工和合作夥伴服務。 - 在您的 BCP 中**考量您的生態系統**。Salesforce 並非您環境中的唯一系統。請確保您在與 Salesforce 整合的系統、從 AppExchange 廠商安裝的解決方案,以及任何其他連線至 Salesforce 中資料或程序的系統中,識別 BCP 中的間隙。如果您的交付能力取決於廠商,請詢問這些廠商有關其連續性計畫。評估其功能並規劃如何讓系統保持可用。 - **將 BCP 疑慮整合到測試策略中**。為您的 BCP 建立測試計畫並執行。測試與流程或人員相關的 BCP 區域 (通常會被忽略) 特別重要。將 BCP 的相關項目納入您的整體 ALM [測試策略](/docs/architect/zh-tw/well-architected/guide/resilient#測試策略)。建立並遵循維護排程來檢閱測試,並確保計畫處於最新狀態。 連續性規劃的 [模式和反模式](/docs/architect/zh-tw/well-architected/guide/resilient#連續性規劃模式與反模式)顯示 Salesforce 解決方案中正確與不良的連續性規劃外觀。使用這些選項在您建立之前驗證您的設計,或識別系統中需要重新設計的位置。 若要深入瞭解用於定義業務連續性的 Salesforce 工具,請參閱彈性的 [Salesforce 工具](/docs/architect/zh-tw/well-architected/guide/resilient#彈性-salesforce-工具)。 ### 技術持續性 技術連續性的目標是確保系統中元件的問題不會阻止企業維護重要的作業。Salesforce 會優先將服務維持在最高層級的可用性,並提供有關任何問題的透明資訊。您可以在 [trust.salesforce.com](https://trust.salesforce.com/) 查看 Salesforce 系統效能與問題的即時資訊。身為 Salesforce 上的結構設計師,您的解決方案可從 Salesforce 在整個平台上提供的網站可靠性、安全性和效能功能中獲益。 不過,Salesforce 解決方案的整體連續性會超出 Salesforce 所提供的內建服務。從結構角度來看,Salesforce 技術持續性規劃必須先詢問與回答 Salesforce 如何適應您大企業的問題。哪些類型的系統可以與 Salesforce 整合?外部系統如何依賴 Salesforce 中的程序或資訊?在您的 Salesforce 組織中,哪些程序或功能依賴 AppExchange 解決方案?您的使用者是否透過第三方身分識別服務或 SSO 存取 Salesforce? 若要在您的 Salesforce 系統中建立更佳的技術連續性: - **評估您的基礎結構。**技術中斷或問題的最常見補救策略是建立可在事件發生期間回復的冗餘服務或系統。在 Salesforce 中,我們有刻意冗餘的結構,這表示我們在不同的實體位置中維護客戶系統和服務的複本。我們使用數種災害復原技術,包括網站切換,這可讓我們視需要將使用者流量從一個資料中心導向至另一個資料中心。若要找出您可能需要建立刻意冗餘的位置,請詢問自己下列問題。 - \[X] 服務服務中斷期間會發生什麼狀況?我們可以從該服務切換至另一個服務嗎? - 還原 \[X] 需要多長時間?對客戶的影響為何?對我們的合作夥伴有何影響?對內部小組的影響為何? - [備份](/docs/architect/zh-tw/well-architected/guide/resilient#建立備份與還原功能)及其頻率為何?備份是否可以提供支援業務所需的資料? - 我們是否依賴廠商?其 BCP 計畫為何? - **提供作業支援。**作業支援旨在讓小組盡快備份並執行。請思考您的系統如何處理產能需求大幅增加,以及因非預期變更 (包括產業範圍、區域範圍或全球變更) 的需求。確定您的 BCP 會考慮「網站可靠性工程」(SRE) 或支援小組可能需要的額外資源或斷眼流程,以有效回應事件。有關作業支援的問題包括: - 在中斷狀況下,我們的技術小組是否擁有繼續工作所需的工具?我們是否已模擬中斷以驗證計畫或識別間隙? - 如果災害位於特定區域,我們是否有該區域的涵蓋範圍計畫? - 我們的客戶是否為全球客戶?他們是否全天候營業? - 我們是否有適當的[監控和警示](/docs/architect/zh-tw/well-architected/guide/resilient#監視與警示),以在失敗時通知適當的個人? - **自動化並測試復原策略。**修復問題後,識別問題發生的位置以及修正方式。如果您可以,請根據補救措施自動化復原策略並調整任何流程問題。許多公司會為服務子集排程事件模擬,以測試系統彈性。例如,模擬系統管理員帳戶遭到鎖定或入侵,或模擬 AppExchange 提供者的中斷或問題。請參閱 [事件回應](/docs/architect/zh-tw/well-architected/guide/resilient#事件回應)。) 有關測試和自動化如何協助您更快還原服務的問題包括: - 我們排程並執行事件模擬的頻率為何? - 我們知道將服務還原為穩定狀態所需的時間為何? - 我們是否有穩定的遞送流程? - 我們知道我們可以在何處自動化錯誤轉換和復原嗎? 處理事件後審查中的任何項目,就像其他開發項目一樣。將其新增至您的規劃系統,讓您可以排定其優先順序並處理。 連續性計畫的 [模式和反模式](/docs/architect/zh-tw/well-architected/guide/resilient#連續性規劃模式與反模式)顯示 Salesforce 解決方案中正確與不良技術連續性計畫的外觀。使用這些選項在您建立之前驗證您的設計,或識別系統中需要重新設計的位置。 若要深入瞭解適用於技術連續性規劃的 Salesforce 工具,請參閱彈性的 [Salesforce 工具](/docs/architect/zh-tw/well-architected/guide/resilient#彈性-salesforce-工具)。 ### 建立備份與還原功能 還原資料或中繼資料的備份副本有助於將您的組織恢復為其最後已知穩定狀態。它也可以在災難性系統失敗或服務中斷期間提供故障切換系統。定期備份您的資料和中繼資料,並將加密的備份複本儲存在安全的位置,可為您的結構增加額外的彈性。 若沒有備份與還原策略,當生產資料和中繼資料遭到惡意損毀、瑕疵不小心進入生產環境時,或當大量資料載入時發生故障損毀生產資料時,您便無法還原生產資料和中繼資料的清除版本。以下任一情況可能會造成業務關鍵生產資料損毀或甚至永久遺失。除了持續性規劃外,設定備份與還原技術還提供許多優點,包括協助制定策略來減少大量資料,並遵循與合規性相關的保留原則。 若要協助確保 Salesforce 解決方案中備份與還原策略的連續性: - **開始.**擁有正確備份與還原策略的第一步,就是先擁有策略。即使是對您組織所有資料和中繼資料進行夜間備份等簡單的動作,也可讓貴公司在災害期間免於遺失重要資訊或功能。 - **限制備份的存取權。**系統管理員是唯一能夠存取資料備份複本的使用者。該存取權限制會讓業務使用者無法在未獲授權在貴組織中檢視的備份複本中檢視記錄。 - **定期測試還原流程。**無論您實作的備份與還原策略為何,請定期在「完整複製」或「部分複製」Sandbox 中[測試](/docs/architect/zh-tw/well-architected/guide/resilient#測試策略)還原流程,以確保在您需要時正確運作。 - **讓備份與還原策略與資料歸檔策略保持一致。**決定當記錄歸檔或從系統清除時,備份或歸檔應發生的狀況。請參閱 [資料量](/docs/architect/zh-tw/well-architected/guide/reliable#資料量))。 如果您的資料量這麼大,完整備份在下一個備份開始執行之前沒有時間完成,您可能需要更精確的備份策略。如果您組織的資料變更頻繁,因此更新對您的組織至關重要,您可能也需要更精確的備份策略。 若要讓備份策略更精確: - **將備份範圍縮小至特定物件**。此策略涉及在不同時間間隔備份不同物件的記錄。請記住,子系物件必須與其父系物件相同的時間間隔備份,才能維持資料的一致性。 - **時間箱** **部分備份**。此策略涉及區分完整備份 (所有資料和中繼資料) 和部分備份 (僅限自上次備份後新增或變更的中繼資料和記錄)。 **\* 請勿停止執行完整備份**。請務必注意,即使資料量導致執行時間過長,您絕不應該完全去除完整備份。針對大量資料,請規劃定期但不常進行的完整備份 (例如每週備份)。也請規劃更頻繁的部分或物件特定備份 (例如,每晚備份或每 X 個小時備份)。此方法可讓您彈性重建最完整且準確的資料集,以用於還原流程中。\* 連續性規劃的 [模式和反模式](/docs/architect/zh-tw/well-architected/guide/resilient#連續性規劃模式與反模式)會顯示 Salesforce 解決方案中正確與不良的備份與還原功能外觀。使用這些選項在您建立之前驗證您的設計,或識別系統中需要重新設計的位置。 ### Salesforce Backup 與復原 Salesforce Backup and Recovery 是一種整合的 Salesforce 解決方案,其中包含「自助式復原」,可保護重要資料免受遺失或損毀。我們高度安全、易於設定且隨時可用的解決方案可確保業務連續性與資料彈性,並簡化合規性。 使用 Salesforce Backup 與 Recovery 可防止資料遺失、快速從資料事件復原,並簡化您的整體資料管理策略。您可以針對高價值和受監管的資料建立備份原則,並按幾下滑鼠來還原該資料。 #### 部署自動備份 自動每日備份可保護您所有的關鍵組織資料,包括中繼資料、Sandbox、受管理封裝資料、檔案附件等。視需要頻繁執行備份,以符合復原點目標 (RPO) 目標並保護您的部署。備份一律可供存取,並以安全且合規的方式儲存。「持續資料保護」也適用於更敏感或交易性的資料,可加速復原快速變化的重要資訊。 #### 主動監視資料 透過直接傳送至電子郵件的主動警示來偵測異常的資料活動、資料遺失和損毀。接收即時警示以識別統計極端值,或建立通知您異常資料活動的規則,協助您比以往更快地偵測事件。 #### 精確快速還原 Salesforce Backup 與 Recovery 透過提供更改的細微可視性,可快速識別及還原受影響的資料來加速復原。如視覺圖形等工具會醒目提示不想要的變更,而易於使用的復原功能可精確還原受影響的物件、欄位和記錄。 #### 延伸備份的使用 我們的工具可讓您使用備份進行分析、稽核和合規性,提供可搜尋的歷程記錄資料、開啟搜尋功能以瞭解過去資料的可視性,以及匯出外部分析或倉庫的功能。這會重新使用備份,而不需要額外的 Salesforce API。 #### 統一備份資料管理 「備份與復原」提供單一主控台,以合併所有備份、管理、作業與合規性。此主控台可讓您存取、管理、自訂和監視所有生產組織和 Sandbox 的備份。透過此功能,您也可以執行資料主題要求以確保備份資料合規性,並擁有自訂備份排程、頻率和保留原則的完整控制權。 #### Salesforce Backup 與復原的重要使用個案 - **減少資料事件的影響**。Salesforce Backup and Recovery 可讓使用者將受影響的記錄回復為其事件前狀態,藉此協助緩解資料事件 (例如網路攻擊或惡意內部或外部活動)。「備份與復原」的匯出功能可保證持續存取與使用者重要資料的可用性。 - **防止永久資料遺失**。人力錯誤仍是資料遺失的主要原因。「備份與復原」提供這些錯誤的精確快速解決方案。 - **更輕鬆地符合資料合規性和法律需求**。Salesforce Backup and Recovery 支援共用責任模型,啟用備份資料中大量忘記或資料修正的自助式服務功能。 若要深入瞭解用於備份與還原的 Salesforce 工具,請參閱彈性的 [Salesforce 工具](/docs/architect/zh-tw/well-architected/guide/resilient#彈性-salesforce-工具)。 ### 連續性規劃模式與反模式 此表格顯示要在您的組織中尋找或建立的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/adaptable-continuity-planning)探索更多連續性規劃的模式。
模式 防模式
業務連續性 在您的業務中:
- 採用「復原優先」心態,專注於盡快使優先順序最高的業務功能和功能不受影響。
- 有維護排程可供檢閱 BCP 測試計畫。
在您的業務中:
- 「修正問題」心態是事件管理的唯一方法。
- 不會定期重新整理 BCP 測試計畫。
在您的文件中:
- 存在 BCP,其中包含在 Salesforce 無法使用時繼續處理或分級資料的步驟、觸發使用 BCP 的事件清單,以及 BCP 測試的步驟和間隔。
- BCP 包含上游和下游系統和相依性。
在您的文件中:
- BCP 不存在、不完整或僅包含 Salesforce。
在測試計畫中:
- 系統會考慮與程序和人員相關的 BCP 區域。
在測試計畫中:
- 不會考慮與程序和人員相關的 BCP 區域。
技術持續性 在您的業務中:
- 您已評估是否需要建立有意的冗餘或錯誤系統
- 事件復原策略會盡可能自動化。
在您的業務中:
- 您尚未評估有關有意冗餘或停機系統的需求
- 事件復原策略完全為手動。
在您的文件中:
- BCP 會考慮小組可能需要的額外資源或中斷程序,以有效回應事件。
在您的文件中:
- BCP 不包含作業支援需求。
備份與還原 在您的文件中:
- 資料與中繼資料皆有備份與還原策略。
在您的文件中:
- 備份與還原策略不存在,或者如果存在,則不完整,僅套用至資料或僅套用至中繼資料,而非兩者。
在貴公司:
- 備份會儲存在僅授權使用者可存取的安全位置。
- 測試計畫和測試記錄顯示資料還原每年至少在完整或部分複製 Sandbox 中進行兩次測試。
在貴公司:
- 備份並非人類可讀。
- 備份會儲存在未經授權的業務使用者可存取的位置。
- 沒有資料還原流程,或者資料還原流程未經測試。
## 彈性 Salesforce 工具
工具描述應用程式週期管理事件回應持續性規劃
Apex 锤子測試 瞭解目前和新版本中的 Salesforce Apex 測試。 X
Apex Stub API 建立模擬架構以簡化測試。 X
備份與復原 自動產生備份以防止資料遺失。 X
大型物件 在平台上儲存及管理大量資料。 X
欄位歷程記錄追蹤 追蹤並顯示欄位歷程記錄。 X
取得您組織的採用與安全性洞察新視窗中的開啟連結 監視您組織中 Lightning Experience 的採用與使用狀況。 X
管理大量資料載入工作 使用「大量 API」建立更新或刪除大量記錄。 X
管理即時事件監視事件 管理事件監視串流和儲存空間設定。 X
資料與儲存資源 檢視您 Salesforce 組織的儲存空間限制與使用量。 X
監視器除錯記錄 監視記錄並設定標記以觸發記錄。 X
使用登入鑑識監視登入活動 識別可能表示身分詐騙的行為。 X
使用設定稽核追蹤監視設定變更 追蹤管理員最近進行的設定變更。 X
監視訓練歷程記錄 檢視使用者已參加的 Salesforce 訓練課程。 X
監視背景工作 監視您組織中的背景工作。 X
監視排程的工作 檢視報告快照、排程的 Apex 工作和顯示面板重新整理。 X
規模測試 測試系統效能並解譯結果。 X
主動監視 使用 Salesforce 監視服務將中斷降到最低。 X
Salesforce Data Mask 自動遮罩 Sandbox 中的資料。 X
系統概觀頁面 檢視您組織的使用狀況資料與限制。 X
使用 force:lightning:lint 透過 Salesforce CLI 分析和驗證程式碼。 X
## 與彈性相關的資源
資源描述應用程式週期管理事件回應持續性規劃
效能與規模測試中的 7 個防模式 避免在效能和規模測試中出現常見的反模式。 X
分析複雜 Salesforce 應用程式中的效能與規模熱點 瞭解解決您組織中效能與延展性問題的方法。 X
建立災害復原計畫 (Trailhead) 建立災害復原計畫。 X
業務連續性不僅僅是備份與還原 全方位檢視 BCP。 X
設計標準範本 為您的組織建立設計標準。 X
Salesforce 中的 診斷與監視工具 瞭解如何改善實作的品質與效能。 X
業務持續性規劃的指導原則 檢閱有效 BCP 的基礎基本原則。 X
如何在 Salesforce 上規模測試 瞭解規模測試生命週期的五個階段。 X
效能測試簡介 瞭解如何開發效能測試方法。 X
監視您的組織 瞭解自助式服務監視選項。 X
測試策略範本 建立和自訂規模和效能測試計畫。 X
測試策略範本 確定測試策略已完成。 X
瞭解來源驅動的開發 (Trailhead) 瞭解封裝開發和臨時組織。 X
## 告訴我們您的想法 協助我們讓 Salesforce Well-Architected 與您相關;進行我們的[調查](https://sfdc.co/bxNtvh)以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。 > [在此](/docs/architect/zh-tw/well-architected/guide/contributors)閱讀我們的更新排程。 ## 簡介 意圖解決方案會立即與隨著時間提供業務價值。意圖結構會以策略的方式進行規劃和傳送、有效地進行維護,且對人類很容易閱讀和理解。 系統會以對業務和技術專案關係人一樣透明的方式排定功能和修正,並提供優先順序。工程選項可建立簡易供傳送和維護小組使用的實作,而不會新增功能或複雜。意圖結構更容易與業務一起擁有、維護和發展,因為其遵循明確且一致的實作模式。產生器可以解譯和實作新功能的設計,而維護小組可以瞭解已實作項目的文件。 您可以透過專注於三個關鍵區域:策略、維護性和可讀性,來建立更有意圖的系統。 ## 策略 結構中的策略表示系統經過謹慎的規劃和交付。這表示運送和維護小組能夠清楚瞭解今天和未來要完成的工作,且每個人都瞭解要完成工作的「原因」。這表示緊急要求可以有效率地分級,利害關係人可以清楚地瞭解要求的影響和權衡。 您可以透過專注於優先順序、藍圖和管治,在結構中建立更明確的策略。 ### 優先順序 優先順序表示規劃您要提供工作的順序和範圍。排定優先順序涉及瞭解可交付對業務的真實影響,並根據其他工作要求評估這些影響,以及產品或計畫的整體藍圖。 評估指定工作項目的影響的一個方法是查看業務的實際成本或效益。識別自動化的 [KPI](/docs/architect/zh-tw/well-architected/guide/automated#kpi) 後,您可以使用 [業務影響計算工作表](/docs/architect/zh-tw/resources/guide/kpi-spreadsheet-template)來評估實作的整體成本或益處。這些計算可協助您取得專案關係人的對齊方式,並讓專案關係人瞭解要建立的自動化以及其順序。它們也可以協助您找出要延後或避免的自動化。如需自動化,請參閱 [流程設計](/docs/architect/zh-tw/well-architected/guide/automated#流程設計) 以瞭解識別有效工作的詳細資訊。 建立傳送的優先順序架構也可協助您和您的維護小組管理使用者期望,並與您的藍圖保持一致。 您可用於排定優先順序的一些考量事項包括: - 可交付項目的業務影響 (成本/益處) - 可交付項目的必要新工作量 - 維護可傳遞所需的工作量 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/intentional#策略模式與反模式)清單顯示適當 (與不良) 優先順序在 Salesforce 工作的外觀。您可以使用這些項目來驗證您的實作計畫,或在建立前找出需要更進一步識別優先順序的位置。 若要深入瞭解 Salesforce 提供的工具,以協助排定優先順序,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。 ### 路線圖 藍圖是要執行之動作的已排定優先順序、經過驗證且已正確定義的檢視。有效的藍圖可讓您清楚瞭解未來工作的業務影響和技術影響。與您的企業和技術專案關係人互動是藍圖的關鍵部分。「藍圖」可讓您在任何工作開始前取得方法和成果的回饋意見和取得意見。最後,藍圖可讓每個利害關係人瞭解為什麼要提前工作。 如果您的小組使用待處理項目,請務必瞭解您的藍圖不是待處理項目摘要或清單。關係相反:只有在項目能夠清楚且可靠地繫結至您藍圖上可提供的項目時,才會進入待處理項目。在利害關係人的參與下建立的高品質藍圖,可讓傳送和維護小組清楚瞭解他們應專注在哪些項目以及應如何排定要求的優先順序,進而更輕鬆地排解衝突的要求並管理利害關係人的期望。 藍圖不良或不存在會導致: - 新功能與功能何時可供使用的清晰度不足 - 利害關係人之間的優先順序衝突 - 提供的解決方案與整體組織願景之間的中斷連線 - 無法瞭解正在進行的工作 - 跨小組的不平均工作量 - 工作項目之間關係與相依性的可視性不足 - 由於管理不良相依性而導致實作延遲 利害關係人通常需要符合其角色的資訊,才能做出決策。建立有效的藍圖需要清楚瞭解您的受眾以及其所需的資訊類型。藍圖分為兩種樣式,以支援業務和技術受眾。每個樣式都包含兩個層級的細微度,以支援不同類型的資訊。 業務藍圖可協助利害關係人計畫組織變更、利用成長機會,並掌握公司目標。業務藍圖也可讓您確保 IT 支出符合整體業務願景。 - 建立業務功能藍圖,以向主管專案關係人顯示要啟用的功能。此類型的藍圖包含功能本身的概況詳細資料,以及其與業務目標保持一致的方式,例如提升營運效率或啟動新產品線。 - 建立業務功能藍圖以逐層細分至特定功能,並在您需要協助業務專案關係人進行資源規劃、預算和變更管理時,顯示其支援功能。 技術藍圖可協助技術專案關係人進行預算和資源配置規劃。他們也可協助實作小組瞭解其專案的適用程度,作為整體全貌的一部分,並識別任何跨小組相依性。 - 建立技術系統藍圖以顯示要實作的特定系統,以及任何系統層級相依性。此類型的藍圖會顯示概況系統資訊,以及系統與業務功能之間的對齊方式。 - 建立技術元件藍圖,以逐層細分所要部署系統的特定元件,以協助處理資源規劃和啟用需求。此類型的藍圖會顯示元件層級資訊和實作需求 (例如宣告式開發、Pro-code 等等)。 請確保您的藍圖包含實際的時間表。常見的錯誤是僅包含實作系統所需的時間,而不考量完成相關活動所需的時間。這可能會導致實作小組成員的配置過多,且延遲時間超出預期。建立藍圖時,請考量完成下列項目所花費的時間: - 所有新增與更新的功能文件 - 支援新功能所需的現有功能維護 - 支援整合所需的相關系統更新 - 專案小組在上線後立即提升支援 - 測試、訓練和變更管理 完全一致的業務和技術藍圖可傳達功能何時上線的整體檢視,以及其背後有哪些技術。下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/intentional#策略模式與反模式)清單顯示 Salesforce 組織的正確 (和不良) 藍圖外觀。您可以使用這些項目來驗證或改善您的藍圖策略。 若要深入瞭解可協助您建立藍圖的 Salesforce 工具,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。 ### 監管 監管是您與利害關係人一起處理優先順序、決策和變更管理的結構。監管可讓您清楚說明如何做出決策和溝通。其提供一致的方式讓回饋意見和要求進入決策流程,並讓所有利害關係人瞭解維護和開發工作的狀態。監管有助於使版本管理流程清楚且一致,並協助所有小組成員瞭解其角色和責任。 若未適當管理,小組將會遇到各種問題,包括: - 對重疊功能與功能的要求會臨時收到 - 實作小組會排定更具影響力的利害關係人的「更簡單」工作或要求優先順序,而不會適當考量業務價值、權衡或整體組織目標 - 缺少一致的批准與審查流程 - 不一致的版本步調與品質 - 在開發工作中有高瑕疵率、覆寫、衝突和冗餘工作 可能系統沒有有效的管治最明顯的跡象是發行速度緩慢且繁琐。請務必瞭解,管治系統的大小並非其效率的度量。事實上,精心設計的管治系統 (如同在許多大型企業中找到的系統) 可能會降低發佈的速度和頻率。 良好的管治是讓不良自訂難以超越開發的早期階段,並以可預測且一致的方式將正確的自訂新增至生產環境。 管治工作過度反應性。當問題 (例如過量的技術債務) 開始成為業務問題時,便會起始或重複。在許多情況下,不幸的回應是企業「鎖定」開發工作和版本,而非建立有效的 [設計標準](/docs/architect/zh-tw/resources/guide/design-standards-template)和建立自動化,以在開發人員工具鏈和來源控制系統中強制執行這些標準。 建立 Salesforce 管理系統架構時,請包含下列元素,並考量要回答的這些關鍵問題: - **工作要求。**使用者如何要求功能或功能?如何報告程式錯誤? - **優先順序和工作規劃。**誰會決定工作要求有何意義?工作範圍、優先順序以及接受或登出方式為何? - **環境與發行規劃。**什麼是開發、測試和發行環境的銷售管道?誰會執行哪些動作來佈建、重新整理和提供存取權?誰會處理部署和驗證?變更如何及何時發行?您在 Salesforce 版本週期期間如何處理部署或環境?(如需此項目的詳細資訊,請參閱 [應用程式週期管理](/docs/architect/zh-tw/well-architected/guide/resilient#應用程式週期管理)。) - **服務擁有權與生產支援。**誰支援哪些項目?誰會處理「Hot-fix」生產問題?這些項目如何測試和釋出?誰負責組織的整體安全性標準? 下方的[模式與反模式](/docs/architect/zh-tw/well-architected/guide/intentional#策略模式與反模式)清單顯示 Salesforce 組織的正確 (和不良) 監管狀況。您可以使用這些項目來驗證或改善您的管治策略。 若要深入瞭解可用於管治的 Salesforce 工具,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。 ### 策略模式與反模式 下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/easy-strategy)探索更多策略模式。
模式 防模式
優先順序 在您的文件中:
- 所有新工作項目都有明確的業務價值度量 (例如,收入增加、流程最佳化節省成本等)
- 藍圖顯示根據業務值排定工作的優先順序
在您的文件中:
- 與工作相關的業務值不明確或不存在
- 藍圖不存在
在貴公司內:
- 已識別所有工作項目的實作與維護成本
- 系統會根據業務影響、需要提供的新工作量,以及需要維護的工作量,來排定功能要求的優先順序
在貴公司內:
- 與實作與維護功能相關聯的成本不明確
- 要求會以臨時或先進/先出為基礎來傳送
路線對應 路線圖:
- 為您的受眾量身打造的資訊 (業務或技術)
- 以正確的詳細資料層級傳達資訊
- 顯示開始與結束日期
- 顯示先決條件與相依性
路線圖 (若存在):
- 作為專案起始材料而非傳送的成品使用
- 不要協助使利害關係人和遞送小組保持一致
- 混合詳細資料層級 (例如,透過在相同的藍圖中包含系統和元件)
- 包含未針對受眾量身打造的資訊 (例如,相同藍圖內的業務功能與系統)
在您的業務中:
- 利害關係人瞭解工作項目的「原因」
- 遞送小組瞭解如何根據較長期優先順序評估待處理項目
- 小組瞭解誰要執行哪些動作以及如何管理相依性
- 工作是有意的,即使優先順序必須快速變更
在您的業務中:
- 工作從待處理項目中的一切提取,且沒有明確的「原因」
- 小組無法協調相互相依工作,且經常在不瞭解的情況下重複工作
- 工作通常為反應性
- 利害關係人經常對正在完成的動作感到挫折和困惑,並在提供新功能時感到自信
管治 在您的業務中:
- 使用者可以輕鬆報告程式錯誤和要求功能
- 工作項目的優先順序流程已記錄並向所有利害關係人透明
- 已清楚記錄環境策略,且開發環境符合文件
- 發行規劃對所有遞送小組成員可預測且透明
- 小組成員瞭解在整個應用程式生命週期負責的項目
- 使用者和傳送/維護小組可以清楚瞭解版本
- 生產支援流程清楚明確,且 hot-fixes 具有生產的明確路徑
- 小組和專案僅使用已批准業務使用的 AI 模型
在您的業務中:
- 錯誤報告與功能要求為臨時
- 工作項目沒有明確的優先順序
- 環境為臨時佈建,且可能無法以預測的方式重新整理;開發人員通常沒有所需的環境和存取權
- 傳送小組和使用者無法預期發行版本
- 小組不知道誰負責哪些事項
- 臨時處理熱修復
- 您的待處理項目已成為過時且停滯的「計畫銀行」
- 管治機構會作為協助台來疑難排解支援要求
- 無法輕鬆存取文件
- 小組臨時選取 AI 模型
## 永續性 永續性表示系統可以保持在正常狀態,新功能會進入,技術債務會定期地以可預測的方式移出系統。可維護的系統可讓您的小組以可預測的速度和品質為業務提供價值。系統的維護性取決於數個因素,包括其可讀性、寬鬆的配對程度,以及其測試策略的完整性。 最重要的是,系統的維護性取決於其設計的直接性。本節涵蓋如何建立更直接的解決方案設計,並提升維護性。 您可以建立更容易維護的解決方案,方法是專注於兩個關鍵:使用標準而非自訂功能,以及處理技術債務。 ### 標準與自訂功能 Salesforce 提供一系列預先建置的解決方案—Sales Cloud、Service Cloud 和許多 Salesforce 產業解決方案,以及建立您自己的自訂解決方案的彈性。支援 Salesforce 自有雲端解決方案的基礎服務也可供任何在 Salesforce Customer 360 Platform 上建立的自訂解決方案使用。使用 Salesforce 的預先建立服務和解決方案,作為盡可能多個解決方案的信任基礎。 使用預先建置平台服務有兩個不同的優點。首先,您的應用程式自然會在每個版本中受益於最新的 Salesforce 創新。其次,您的開發小組可以專注於擴充和深化 Salesforce 解決方案所提供的業務能力,而不是處理基本的結構繁重工作。 從結構的角度來看,正確選擇何時使用標準功能以及何時建立自訂功能並不具有挑戰性。索引鍵為: - **自訂平台表示修改和擴充,而非複製**。當您設計或評估結構時,應詢問:此功能是否已存在於 Salesforce Platform 中的某一處?如果回答為「_是,但...\[在此插入業務利害關係人想要的變更...]」_,請使用平台中的預先建立功能。要完成的結構工作是找出最有用的方式來設定預先建立的 Salesforce 功能,以符合業務期望。 - **沒有任何自訂內容無缺**。隨著時間的推移,每個變更都會有後果。如果您需要實作自訂解決方案,您可以選擇盡可能使用低程式碼技術,並在實作中建立可[組合單位,以](/docs/architect/zh-tw/well-architected/guide/composable)減輕系統將產生的不可避免的[技術債務](/docs/architect/zh-tw/well-architected/guide/intentional#技術債務)。 - **考量 build-buy 頻譜**。[Salesforce AppExchange](https://appexchange.salesforce.com/) 是可擴充 Salesforce 的應用程式和解決方案市集。AppExchange 應用程式可以提供功能,而不需要建立和維護自訂解決方案的負擔。評估 AppExchange 解決方案時,請考量下列事項: - 識別解決方案的功能與間隙。在理想情況下,您會找到符合您所有業務需求的應用程式。實際上,您可能找不到完美的適配。當您評估解決方案時,請將潛在解決方案中的功能對應至業務需求的優先順序清單。這將協助您找到最符合您最嚴重需求的解決方案。 - 使用 Sandbox 和免費試用版。使用免費試用期間來評估 Sandbox 環境中的應用程式,並找出最合適的應用程式。判斷應用程式是否需要您進行與現有組態衝突的組態變更。 - 考量短期與長期成本。根據訂閱式應用程式的循環成本評估長期應用程式維護節省的成本。避免您必須為業務專案關係人永遠不會使用的許多功能支付循環成本的情境。 - **使用 Salesforce 的預先建立資料模型。**Salesforce 提供銷售、服務和各種產業垂直的預先建立資料模型。使用 Salesforce 提供的資料模型可確保系統中的功能僅定義一次 (消除冗餘與孤立狀況)、在整個系統中建立單一事實來源、透過分析更容易瞭解應用程式資料、更容易使用 Salesforce 預先建置的人工智慧服務、降低維護成本 (透過減少您需要支援的自訂項目),並減少技術債務。 如此簡單。如您在下方的 [模式和反模式](/docs/architect/zh-tw/well-architected/guide/intentional#維護模式與反模式)中所見,反模式主要是複製自訂解決方案中的標準功能,或使用更複雜的技術來提供自訂。 在實際上,您可能會遇到一個情況,即業務專案關係人將自訂功能反模式視為最佳或唯一可行的進展方式。在這些情況下,您必須向利害關係人說明選擇此路徑所涉及的權衡,然後完整記錄決策、其原因和實作。這也是提供早期核心價值並隨著時間調整的區域,可協助您的利害關係人進一步瞭解前進的最佳方式。 若要深入瞭解可協助您提升維護能力的 Salesforce 工具,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。 ### 技術債務 技術債務是任何系統的自然部分。當技術或業務需求改變時,昨天的音效設計可能會變成反模式。或許為了填補 Salesforce 平台功能缺口而建立的項目,會在新的 Salesforce 版本或產品啟動時突然變成冗餘。更高效能或彈性的技術可能會取代您已實作的技術。技術債務可透過許多方式建立。 使用 Salesforce Customer 360 Platform 建立應用程式的關鍵優點是平台內建的[回溯相容性](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#平台-api)。這表示新平台創新可能會改變您應用於解決方案進展的模式,但您在先前 Salesforce 技術上建立的解決方案其日常功能仍會繼續運作。隨著時間的推移,任何以舊技術為基礎的解決方案都會開始造成新功能新增至應用程式的風險或瓶頸,並降低整體解決方案運作狀況。 規劃並執行定期工作以解決技術債務,對於在 Salesforce 解決方案中維持健康且直接的設計至關重要。無法規劃、稽核和補救技術債務是建立結構不良系統的確實方式。 將技術債務降到最低的方法之一是盡可能避免導入技術債務,方法是避免使用捷徑,並且偏好使用[標準功能而非自訂功能](/docs/architect/zh-tw/well-architected/guide/intentional#標準與自訂功能)。快速鍵 (如硬式編碼值) 可能有助於節省時間,但在長期內會產生必須償還的債務。 從結構角度解決技術債務的關鍵包括: - 識別動作與不動作對業務的實際[成本或益處](/docs/architect/zh-tw/resources/guide/kpi-spreadsheet-template) - 適當的 [路線圖](/docs/architect/zh-tw/well-architected/guide/intentional#路線圖) - 建立[可組合解決方案](/docs/architect/zh-tw/well-architected/guide/composable) 難以讓利害關係人與採取行動保持一致。某些利害關係人可能會將持續維護視為解決「昨天的錯誤」,或移除他們想要預算支援的功能。 顯示動作與未動作的實際業務影響,以及清楚定義的可運送項目與時程表,可協助您的利害關係人瞭解處理技術債務的價值與相對優先順序。一律執行工作,將技術債務與業務影響連結在一起,不僅有助於您的利害關係人進一步瞭解待完成的工作。這也會協助您確保以實際有利於使用者的方式來識別和解決技術債務。 下方的[模式與反模式](/docs/architect/zh-tw/well-architected/guide/intentional#維護模式與反模式)清單顯示 Salesforce 組織的正確 (和不良) 技術債務管理外觀。 若要深入瞭解可協助您處理技術債務的 Salesforce 工具,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。 ### 維護模式與反模式 下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/easy-maintainability)探索更多可維護的模式。
模式 防模式
標準與自訂 在您的設計標準中:
- 有明確的指導原則可防止解決方案不需要自訂
- 解決方案的指引原則使用下列優先順序:1.使用內建平台服務、2.在建立自訂解決方案前,請先考量 AppExchange 應用程式。在撰寫程式碼前使用低程式碼自訂項目
在您的設計標準中:
- 設計標準不存在或沒有避免不需要自訂和程式碼的明確理由
在您的文件中:
- 當選擇建立或購買解決方案時,決策記錄會顯示近期和長期成本的計算
在您的文件中:
- 當選擇建立或購買解決方案時,決策記錄不會同時考量近期與長期成本
在資料模型中:
- 沒有任何物件具有重複標準物件的名稱或功能
- 標準物件不會用於遠超出預期範圍的用途
在資料模型中:
- 物件會複製標準物件的名稱和/或功能
- 標準物件用於遠超出預期範圍的用途
在 LWC、Aura 或 Visualforce 中:
- 沒有可覆寫標準頁面檢視機制的程式碼
在 LWC、Aura 或 Visualforce 中:
- 存在程式碼來覆寫標準頁面檢視機制,通常是單一頁面應用程式的形式
在 LWC、Aura 或 Apex 中:
- 沒有程式碼嘗試覆寫或略過執行平台順序
在 LWC、Aura 或 Apex 中:
- 程式碼嘗試覆寫或略過平台執行順序
技術債務 在您的藍圖中:
- 已計畫處理技術債務的工作
- 交付與開始/結束日期清楚
在您的藍圖中:
- 未計畫處理技術債務的工作
- 交付項目不明確;開始/結束日期不明確
在您的決策記錄中:
- 清楚記錄前/後技術補償債務的 KPI
- 對動作與未動作的權衡討論,專注於業務成本或益處
在您的決策記錄中:
- 技術償還債務沒有可測量的 KPI
- 技術債務會以技術或 IT 重點的術語考量,與業務無關
在您的組織中:
- 未啟用任何不支援或舊版技術,包括:
-- 所有使用者都在 Lightning Experience 中工作
-- 在 Apex 中沒有或非常少使用 @future (使用 Queueable)
-- 所有第三方 Apex 都屬於 AppExchange 封裝
-- 沒有啟用的工作流程規則 (使用流程)
-- 沒有啟用的流程產生器程序 (使用流程)
-- PushTopic 事件 (使用「變更資料擷取」)
-- 一般事件 (使用平台事件)
-- 30.0 版之前的 API 版本
-- Salesforce 組織連線使用 Salesforce Connect 的跨組織轉接器
在您的組織中:
- 不支援或舊技術已啟用,包括:
-- 在 Salesforce Classic 中工作的使用者
-- Apex 中的 @future usage
-- 來自非 AppExchange 來源的第三方 Apex
-- 工作流程規則
-- 流程產生器流程
-- PushTopic 事件
-- 一般事件
-- 30.0 版之前的 API 版本
-- Salesforce 到 Salesforce 連線
## 可讀性 *可讀性*的概念的核心是建立一致性,讓人們能夠輕鬆瞭解事物的運作方式。建立可讀取系統可讓傳送與維護小組保持一致,並協助對系統不熟悉的人員快速瞭解組件的整合方式。這表示您的小組可能較不依賴具有機構或歷史 Knowledge 的人員,以有效地引導廠商或新小組成員。這表示小組中的技能人員可以專注於所做的選擇的品質和權衡,因為系統的組態和程式碼對人類很容易讀取和理解。可讀性可加速管理和品質保證流程,並協助小組在何時建立冗餘自訂項目。其也會增加具有可重複使用和可測試方式運作之系統的機會。 您可以透過有效的設計標準和文件來提升可讀性。 ### 設計標準 [設計標準](/docs/architect/zh-tw/resources/guide/design-standards-template)提供指引,讓所有自訂都保持一致,即使是在開發的最早階段。設計標準的運作方式與護欄相似,讓所有運送小組和維護小組在系統上工作,都能掌握如何進行自訂和實作。定義設計標準有助於提升傳送和維護小組的生產力、讓程式碼和結構審查更容易執行,並為更好的[文件](/docs/architect/zh-tw/well-architected/guide/intentional#文件)提供基礎。 若沒有設計標準,小組較有可能在單間工作。若沒有設計標準所提供的一致性,企業將會遇到下列問題: - 廠商和開發小組在解決方案之間使用臨時模式和方法,進而可能導入反模式並減少可重複使用性 (請參閱 [關注分隔](/docs/architect/zh-tw/well-architected/guide/composable#分離疑慮))。 - 增加解決生產問題的時間,以及引導新小組成員的必要支援小組,並協助他們瞭解不同的模式和方法集。 - 跨小組協同合作不佳、跨小組工作的冗餘、解決衝突所花費的時間,以及整合測試期間發現的錯誤。 - 挫折感和營業率增加。 設計標準的主要優點來自利害關係人必須進行的對話和決策以建立標準。具體而言,此流程為您的業務和技術負責人提供機會,讓他們能夠配合業務的最佳設計。 在您的 [設計標準中](/docs/architect/zh-tw/resources/guide/design-standards-template)包含下列內容 - Salesforce 中繼資料的 **命名慣例**。定義一組慣例,用於定義系統中每個自訂的命名方式。良好的命名慣例不僅會強制執行物件、欄位、程式碼、流程和系統其他元素的名稱的一致性。良好的命名慣例也可協助開發小組使用名稱來傳達其正在建立之目的與功能的相關資訊。因此,其他利害關係人只需查看其名稱即可更進一步瞭解特定自訂。 - **已批准的設計模式及其使用個案**。建立「[模式與防模式探索器](/docs/architect/zh-tw/well-architected-tools/guide/patterns)」庫,以及使用每個模式時機 (及不使用時機) 的重要資訊。文件庫可能包含必要的 Apex 觸發模式,或根據您在系統中所需的可[組合性](/docs/architect/zh-tw/well-architected/guide/composable)包含流程協調流程模式。 - **開發環境與工具指引**。維護開發小組用於其工作之工具的清單。這可能包含任何撰寫程式碼的人員所批准的工具鏈和語言,或已 (或尚未) 批准用於低程式碼開發的陳述性功能。您的標準可能包含自訂和文件的來源控制系統清單,以及必要的簽到/簽退步驟。也可以包含用於不同類型開發工作的環境清單。 除了定義這些標準外,您還需要決定維護與儲存標準的方式與位置。如果貴公司的小組找不到您的設計標準 (或甚至不知道其存在),則這些標準將無法生效。理想情況下,您的設計標準會與文件位於相同的系統內 (如需詳細資訊,請參閱下一節)。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/intentional#可讀性模式與反模式)清單顯示 Salesforce 組織的正確 (和不良) 設計標準外觀。您可以使用這些項目來驗證或改善您的設計標準。 若要深入瞭解可協助您定義設計標準的 Salesforce 工具,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。 ### 文件 文件說明系統的功能、方式和原因。若沒有有意義且一致的文件,小組會浪費大量時間嘗試瞭解系統的原狀 (以及可能誤解的功能和自訂項目)。 良好的文件需要時間才能建立。雖然大多數小組都同意文件對於大型專案很重要,但在進行快速變更 (例如組態更新或對自動化進行小幅微調) 時,可能會是一個誘人的步驟。不記錄您對系統進行的變更一律為反模式。略過文件可能會提前節省少量時間,但針對未正確記錄的組織進行疑難排解所需的時間會超過取消這些節省時間的時間。無論您計畫進行之更新的所需精力層級為何,請一律將足夠的時間包含在所有估計值中建立文件。 缺少清楚的文件可能會導致各種問題,包括: - 花在重新處理現有實作的開發週期 - 重複對先前決策進行重複或困惑的討論 - 新增小組成員或廠商的上線時間更長 - 對具有機構或歷史 Knowledge 個人的過度相依性 - 可在整個業務中支援相同或類似功能的冗餘結構 - 無法將解決方案的目的和價值傳達給關鍵利害關係人 針對 Salesforce 解決方案,請維護文件: - **解決方案概觀**。[圖表](/docs/architect/zh-tw/reference-diagrams/guide/introduction)可讓您與專案關係人以各種詳細資料層級將解決方案視覺化。Salesforce 圖表架構可協助您建立圖表,以顯示解決方案的業務功能,以及技術實作詳細資料。 - **決策記錄**。將考量選項、權衡、最終決策和推理的記錄保存在集中的位置,所有小組成員都可以存取以供日後參考。 - **代碼**。程式碼的格式本身是文件的關鍵,這可以 (且應該) 符合您的 [設計標準](/docs/architect/zh-tw/well-architected/guide/intentional#設計標準)。您也會想要有關鍵資訊的記錄,並在每次修改程式碼時進行更新。針對所有類別、觸發和元件,記錄以下內容: - 撰寫程式碼的人 - 撰寫程式碼的時間 - 程式碼應執行的動作 - 主要相依性 - 所有變更 - **宣告自訂**。針對您組織中可對中繼資料進行的每種自訂,Salesforce 會為小組提供 [內建屬性](/docs/architect/zh-tw/fundamentals/guide/platform-multitenant-architecture#瀏覽器型無程式碼和低程式碼應用程式開發),以提供有關中繼資料目的與意圖的實用資訊。作為設計標準的一部分,請包含小組如何使用這些內建功能,以及小組如何命名陳述式自訂。同時維護與您用於程式碼相同的金鑰資訊記錄。 開發一組文件標準,以確保所有目前和未來的小組成員都能夠以相同的方式解讀文件。 ([設計標準](/docs/architect/zh-tw/resources/guide/design-standards-template) 可為此提供協助。)請務必考量使用者如何搜尋文件以尋找相關的區段或字詞。隨著系統的年齡和複雜性增加,您的文件也會成長。您文件中資訊的實用性將直接與使用者搜尋及尋找相關項目的頻率、速度及輕鬆度有關。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/intentional#可讀性模式與反模式)清單顯示 Salesforce 組織的適當 (與不良) 文件外觀。您可以使用這些項目來驗證或改善您的文件策略。 若要深入瞭解 Salesforce 工具的文件,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。 ### 可讀性模式與反模式 下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/easy-readability)探索更多可讀的模式。
模式 防模式
設計標準 在您的組織中:
- 程式碼和陳述式自訂項目具有一致且人類可讀的名稱
- 資料模型具有一致且統一的物件和欄位名稱
- 稽核顯示在報告中一致填寫和參照的欄位等。
在您的組織中:
- 程式碼和陳述性自訂項目沒有一致的名稱
- 資料模型名稱不一致,且許多物件和欄位似乎為冗餘
- 稽核會顯示許多未使用的欄位或不同層級的用量,且報告等沒有一致的連結。
在您的業務中:
- 小組瞭解要使用 (而非使用) 哪些工具來完成工作
- 通過使用個案輕鬆找到並識別批准的設計模式
- 已核准的 AI 模型會清楚識別並包含預期的用途
在您的業務中:
- 小組使用許多不同的工具完成類似的工作
- 沒有已批准的設計模式
- 廠商或新進員工需要很多時間才能上線
- 批准的 AI 模型未清楚識別,且其預期用途不明確
文件 在您的組織中:
- 程式碼和陳述性自訂項目具有明確的描述
在您的組織中:
- 程式碼和陳述式自訂項目沒有描述、具有難以理解的描述,或具有描述,似乎不符合自訂項目實際執行的動作
在您的業務中:
- 所有解決方案的業務功能圖表和技術實作詳細資料存在
- 金鑰誰/何時/存在的程式碼和陳述式自訂記錄資訊
- 人員可以搜尋並尋找相關文件
在您的業務中:
- 難以找到解決方案的什麼/如何/原因,且大多數的小組可能無法使用
- 人員難以瞭解解決方案以及其使用的系統
- 廠商或新進員工需要很多時間才能上線
## 與意圖相關的工具
工具描述策略永續性可讀性
ApexDoc使用靜態 HTML 頁面文件 ApexXX
大量刪除未啟用的選項清單值從選項清單中刪除未啟用的未使用值X
Lightning 設計系統驗證程式驗證標記並瞭解如何改善程式碼XX
移轉至流程將工作流程規則和流程產生器程序轉換為流程X
Salesforce Labs 的專案管理工具在您的 Salesforce 組織內管理專案XX
Visual Studio Code 的 Salesforce 擴充功能 (展開型)使用 Visual Studio 程式碼擴充功能有效率地分析 Salesforce 程式碼XX
組織檢查快速分析您的組織及其技術債務X
Salesforce 程式碼分析器透過 IDE、CLI 或 CI/CD 掃描程式碼,以確保程式碼符合最佳作法XX
Salesforce 藍圖探索器探索 Salesforce 產品創新X
設定稽核追蹤追蹤設定變更和稽核歷程記錄XX
## 與意圖相關的資源
資源描述策略永續性可讀性
改善 Salesforce 組織的 5 個文件策略改善 Salesforce 實作文件X
選擇命名慣例 (Trailhead)瞭解如何套用命名慣例X
定義、識別和測量技術債務定義、識別和測量技術債務XX
設計標準範本為您的組織建立設計標準XXX
開始使用 Salesforce 圖表瞭解如何為您的使用個案建立正確的圖表X
開始使用程式碼慣例 (Trailhead)定義並遵循程式碼慣例X
如何處理技術債務 (Trailhead)在您的 Salesforce 組織中管理技術債務XX
改善您的 Apex 程式碼 (Trailhead)套用以測試為導向開發的基本原則X
組織對齊方式 (Trailhead)瞭解對齊方式的 V2MOM 流程X
排定優先順序並規劃技術債務退出之路制定減少和移除技術債務的計畫XX
Salesforce 命名慣例範本開始使用命名慣例XX
技術債務:它是什麼,以及您應該注意的原因? 瞭解組織中技術債務的影響X
在企業結構中使用業務模型畫布在業務模型中建立、傳送和查看值X
## 告訴我們您的想法 協助我們讓 Salesforce Well-Architected 與您相關;進行我們的[調查](https://sfdc.co/bxNtvh)以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。 ## 簡介 Diagram showing Salesforce Well-Architected core capabilities are Trusted, Easy, Adaptable Salesforce Well-Architected Framework 會顯示健康狀況的外觀,以及您使用 Salesforce Customer 360 Platform 建立藍圖和設計解決方案的時間。它會根據 Salesforce 和我們生態系統中產品小組和實作專家的 Knowledge,分享規範指引和模式和反模式的範例。Salesforce Well-Architected 已組織以協助您建立信任、簡單且可調整的解決方案。 **信任的**解決方案可保護利害關係人。
**簡單**的解決方案可快速提供價值。
**可調整**的解決方案會隨業務進化。
Salesforce Well-Architected 的設計目的為協助您逐步完成在 Customer 360 Platform 上建立健康解決方案所需的結構思維。 結構設計師使用 Salesforce 建立解決方案的獨特挑戰是平台的基本彈性。一個解決方案可以擴充 Salesforce 所提供的預先建立解決方案 (例如 Sales Cloud、Service Cloud、不同的 Industries Cloud 垂直解決方案)。其他解決方案可能是完全自訂應用程式。您可以使用 Salesforce 執行的動作廣泛且深入,最適合您實作的特定技術選擇將取決於業務需求。對於每個可能的 Salesforce 解決方案而言,知道什麼會建立長期健康的最佳機會,會很難。 Salesforce Well-Architected 會根據您的需求提供高經驗結構設計師的洞察與指引。您可以使用意見的檢視和建議來驗證 (或挑戰) 您的思維,並深入瞭解您可能的新考量或技術領域。 考慮到實作之間的多樣性,如果所有健康解決方案都有共同的結構基準,也難以瞭解。在 Salesforce,我們作為公司和人員所做的一切都會以核心價值觀為導向。我們認為這也適用於結構。這就是為什麼 Salesforce Well-Architected 以「信任」、「簡單」與「可調整」為核心為基礎所建立。當您評估複雜的結構詳細資料和權衡時,您可以返回這些核心功能,並使用這些功能作為指南針來引導您的決策。 以下是個別主題的詳細資料,可在我們的「信任、簡單且可調整」架構中探索。 ## 主題的排列方式 我們使用兩個層級來組織整個 Salesforce Well-Architected 的資訊。最上層是適合良好的解決方案:可靠、簡單且可調整。第二個層級會深入瞭解考量事項、要建立的模式 (或要避免的反模式),以及與「信任」、「簡單」和「可調整」解決方案特定層面相關的指示性指引。將您的設計與整個架構提供的指引保持一致,應促進 Salesforce Customer 360 應用程式中更高的品質與更長的運作狀況。 💡 想要快速開始使用模式和反模式嗎?造訪 [模式與反模式探索器](/docs/architect/zh-tw/well-architected-tools/guide/patterns)。 以下是主題排列方式的概觀:
信任
受信任的解決方案可保護您的業務和利害關係人。
安全 符合 可靠
組織安全性
工作階段安全性
資料安全性
法律符合度
道德標準
無障礙
可用性
績效
延展性
簡單
簡單的解決方案可快速提供業務價值。
意圖 自動 參與
策略
永續性
可讀性
效率
資料完整性
已簡化
實用
可調整
可調整的解決方案會隨著您的業務而發展。
彈性 可組合
應用程式週期管理
事件回應
持續性規劃
分離疑慮
互通性
可封裝性
> [在此](/docs/architect/zh-tw/well-architected/guide/contributors)閱讀我們的更新排程。 # 簡介 **簡單** 的 Salesforce 解決方案可快速提供價值。針對「**簡單**」設計良好的解決方案,其有意義、自動化且吸引人。 **意圖**的解決方案會隨著時間提供業務價值。
**自動化**解決方案可讓企業更快速且大規模完成工作。
**互動式**解決方案能讓使用者開心並促進採用。
建立 **簡單**的結構可能會對結構設計師造成複雜的挑戰。由於 Salesforce Platform 的彈性以及各種可用的 [自動化工具](/docs/architect/zh-tw/well-architected/guide/automated#與自動化相關的工具),因此各個 Salesforce 組織的實作詳細資料可能會有所不同。**簡單**的結構可能需要更聰明 (且難以置信) 的權衡分析和與利害關係人的對話。對於程式設計師而言,解決方案設計可以是彈性的且可靠的,但對於組織管理員而言,擁有或維護的設計並不簡單。這類解決方案並不適當設計,且不易於使用\*\*\*\*。 若要找到一種 **簡單**的解決方案,您必須深入且準確地瞭解業務優先順序。您必須瞭解您的使用者,包括其偏好設定、需求,以及其工作的日常實情。您也必須瞭解運送和維護小組中的技能 (以及技能差距)。您將需要反覆使用不同的工具選項和設計模式,以達到旨在為業務提供價值的解決方案,同時可管理給遞送和維護小組、更快、更大規模地自動化工作,並真正吸引使用者參與。 下列幾節提供更深入的指引,以瞭解 **簡易**解決方案結構的核心考量事項。 ## 簡易概觀
意圖
意圖解決方案會立即與隨著時間提供業務價值。意圖結構會以策略的方式進行規劃和交付、有效地進行維護,且對人類很容易閱讀和理解。
策略 永續性 可讀性
優先順序
路線圖
監管
標準與自訂
技術債務
設計標準
文件
自動
自動化解決方案可讓企業更快速且大規模完成工作。健康的自動化可減少重複、手動工作或複雜資料項目的時間。
效率 資料完整性
流程設計
作業邏輯
KPI
資料處理
錯誤處理
參與
參與解決方案讓使用者開心,並促進採用。參與的結構表示建立直覺式、實用的使用者體驗。
簡化 實用
應用程式複雜性
表單
尺寸規格
通知與傳訊
應用程式內導覽
認可與獎勵
> [在此](/docs/architect/zh-tw/well-architected/guide/contributors)閱讀我們的更新排程。 ## 簡介 系統會透過讓業務更快速且大規模地達成主要目標來示範自動行為。健康的自動化可讓使用者專注於高價值的工作,並減少對重複、手動工作或複雜資料輸入所花費的時間。 自動化通常是指將業務流程從一個表單轉換為另一個表單:從紙本表單轉換為數位表單,從舊系統轉換為新的系統。每個業務流程翻譯都會帶來轉換的機會。 轉換並非使用新技術為使用者導入中斷和混淆的變更。轉換是關於建立更簡單的方式來完成工作、讓業務不受摩擦地成長,以及讓業務使用者更深入地專注於對利害關係人的真正重要性。從結構角度來看,這涉及識別可以一併去除或自動處理的工作。它需要在技術使用方式與其對業務的可測量影響之間建立明確的連結。 Salesforce 自動化的重要注意事項:可透過各種工具完成,並使用程式設計和陳述性技能集。設計結構正確的自動化,並非選擇只使用一個自動化工具來建立。這是關於使用一致且可預測的方法,並讓小組開發、測試、部署和維護您設計的自動化。您的自動化應盡可能採用最可[維持且可讀的](/docs/architect/zh-tw/well-architected/guide/intentional)形式。 本節涵蓋如何設計和重新產生自動化,讓企業能夠更快速且大規模地達成關鍵目標。您可以專注於效率與資料完整性,以改善 Salesforce 中的自動化結構。 ## 效率 透過 Salesforce 技術,建立自動化效率並非如往常般重建業務。這是關於深入瞭解小組將負責會議或追蹤的關鍵度量和業務成果,以及返回查看您正在自動化工作的內部和整個工作中的[功能單位](/docs/architect/zh-tw/well-architected/guide/composable#功能單位)。您可以透過自動化來識別如何建立模式,讓業務更有效率、更快速地進行大規模作業。 有效率的自動化邏輯可讓您的系統: - 更容易調整且對業務有價值 - 對使用者更有幫助 - 更容易[適應](/docs/architect/zh-tw/well-architected/guide/adaptable-overview)並能夠滿足不斷變化的業務需求 您可以透過流程設計和作業邏輯改善自動化效率。 ### 流程設計 流程設計涉及定義工作完成的方式。建立真正有效率且有效率的流程表示您的設計不只是複製目前的工作方式。識別和移除無效或不明確的步驟至關重要。最佳化的流程應在沒有不必要步驟的情況下建立可測量的業務價值 (請參閱 [KPI](/docs/architect/zh-tw/well-architected/guide/automated#kpi))。不明確或不必要的步驟可能會造成技術債務,並導致無法維持的自動化。 通常,探索和記錄業務流程的責任會屬於業務分析師或甚至是系統管理員的責任。結構設計師負責與這些小組成員合作,以確保您的流程設計在技術上是健全且結構良好。盡早套用您對 Salesforce 平台的 Knowledge 可協助您的小組找出要透過自動化來簡化的流程,或需要變更的流程,以避免付費自訂。 若要建立 Salesforce 的最佳化流程,請考量: - **全面定義程序**。具有不明確目的或定義不明確的程序在設計時更有可能遭到誤解。這會導致以假設為基礎的錯誤設計,這會導致自動化不正確或效率不佳。確保您要自動化的業務流程符合下列標準: - 範圍為單一特定函數 (請參閱 [功能單位](/docs/architect/zh-tw/well-architected/guide/composable#功能單位)) - 已清楚定義可測量的輸出 (請參閱 [業務值](/docs/architect/zh-tw/well-architected/guide/automated#業務價值)) - 已清楚定義輸入與輸出 - **讓流程步驟更清楚**。\* 雖然新增「未來可能有幫助」的其他步驟有時會很誘人,但這絕對不是一個好方法。自動化中的每個步驟都與整體流程的結果相關。確定每個流程步驟具有下列特性: - 執行特定細微工作 (請參閱可[編譯](/docs/architect/zh-tw/well-architected/guide/composable)) - 需要程序產生其定義的輸出 (移除所有非必要步驟) - 可以使用最少數量的資源完成 - 盡可能使用現有系統資料,而非要求使用者輸入 (請參閱 [參與](/docs/architect/zh-tw/well-architected/guide/engaging)) - 提供輸入選項,使用者無須瞭解基本系統的運作方式即可瞭解 (請參閱「[實用](/docs/architect/zh-tw/well-architected/guide/engaging#實用)」) 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/automated#效率模式與反模式)清單顯示 Salesforce 組織中的正確 (和不良) 最佳化外觀。您可以在建立之前使用這些項目來驗證您的自動化設計,或識別需要進一步最佳化的自動化。 若要深入瞭解 Salesforce 提供的流程自動化工具,請參閱與自動化相關的 [工具](/docs/architect/zh-tw/well-architected/guide/automated#與自動化相關的工具)。 ### 作業邏輯 作業邏輯會處理從流程的設計轉換為實際實作的效率。無論交易量高峰或執行中的同時例項數量為何,具有強大作業邏輯的自動化都會持續表現良好。邏輯上,有效的自動化可協助企業更輕鬆地調整規模,以滿足更高的需求。在您的自動化中建立強大的作業邏輯,與系統的整體[可靠性](/docs/architect/zh-tw/well-architected/guide/reliable)有直接關係。 未有效運作的自動化提供較差的使用者和客戶體驗,進而導致潛在的收入損失和客戶的 Trust 損失。其維護成本也較高,且可能會變成瓶頸,使相關程序延遲,進而造成整體系統效能問題。 若要在自動化中建立有效的作業邏輯,請考量: - **確保所有建立自動化的使用者都知道如何執行此操作**。使用任何類型的自動化工具可能會產生不良設計選擇。程式碼可能會發生錯誤或實作選項不佳,而非點按型工具。例如,使用硬式編碼參照識別碼是「流程」與程式碼中出現的反模式。按一下式工具不應視為授權,以允許任何人和每個人將自動化釋出至生產環境。建立自動化的每個小組成員都需要知道如何以正確的方式建立自動化。請參閱可[讀性](/docs/architect/zh-tw/well-architected/guide/intentional#可讀性)與 [設計標準](/docs/architect/zh-tw/well-architected/guide/intentional#設計標準),以深入瞭解如何在整個系統中定義及套用有效標準。 - **清楚記錄所有執行路徑**。自動化的使用量增加不僅會增加潛在的資料量,也會增加非預定叫用內容。您需要瞭解如何叫用不同的自動化,並確保在具有多個進入點的所有自動化中都會顯示適當的交易控制 (請參閱資料處理)。例如,畫面流程不會在大量資料載入時執行,但 Apex 觸發和觸發 (及自動啟動) 流程可能會執行。清楚記錄自動化的計畫式和潛在執行路徑是瞭解實作期間需要配合的邏輯條件的重要層面。 - **「批次」所有資料作業 (包括 SOQL)**。每個資料作業 (插入、更新等) 都應針對集合執行。一律。沒有例外情況。這就是「大量處理」作業的意思。雖然平台可以支援 singleton 資料作業,但您絕不應允許實作 singleton 模式。 - **使用 SOSL 進行搜尋作業**。我們錯誤地認為無法針對透過 SOSL 傳回的記錄執行資料作業。事實上,無法直接針對 SOSL 結果叫用 DML,但程式碼可以剖析 SOSL 結果,並建立可在 DML 或資料庫類別方法中參照的集合。SOSL 與 SOQL 之間的關鍵差異是各自的傳回類型,以及其回應廣義或萬用字元搜尋的方式。SOSL 可以針對數種 sObject 類型運作 (這就是傳回類型不同的原因),並能處理與 SOQL 相較的萬用字元和廣義字串搜尋,效能更佳。 - **將 SOQL 視為資料作業**。請勿使用 SOQL 尋找記錄,請使用它來限定資料作業。SOQL 和資料作業對 [基本關聯式資料庫](/docs/architect/zh-tw/fundamentals/guide/platform-multitenant-architecture#平台資料層)的效能有非常類似的影響。SOQL 甚至可以傳遞 [明確的 DML 指標](https://developer.salesforce.com/docs/atlas.en-us.238.0.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_for_update.htm?q=for%20update),該指標會在預期資料作業時鎖定資料庫列。若要建立可調整的自動化,請確保您以類似的盡職調查方式處理 SOQL:不要在沒有非常具體且格式正確的選取條件的情況下使用 SOQL,不要允許外部欄位參照,並要求在 `WHERE` 陳述式邏輯中仔細比對欄位和篩選輸入的資料類型。您的程式碼也應有適當的控制項,以確保查詢永不在非大量處理的環境中執行,或針對空值或空白篩選條件執行。 - **將同步作業專注於即時協助使用者的工作**。在您的 [流程最佳化](/docs/architect/zh-tw/well-architected/guide/automated#流程設計)期間,識別與使用者即時或近乎即時需要完成的相關邏輯,以及可延後至非同步 (非同步) 交易的項目。請參閱「[資料處理」,](/docs/architect/zh-tw/well-architected/guide/automated#資料處理)以取得設計同步化/非同步化作業的詳細考量事項。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/automated#效率模式與反模式)清單顯示 Salesforce 自動化中的正確 (與不良) 作業邏輯外觀。您可以在建立之前使用這些項目來驗證您的自動化設計,或識別需要進一步最佳化的自動化。 若要深入瞭解可協助您計畫規模的 Salesforce 可用工具,請參閱與自動化相關的 [工具](/docs/architect/zh-tw/well-architected/guide/automated#與自動化相關的工具)。 ### KPI 自動化 KPI 測量自動化隨著時間的影響。若沒有自動化功能,您將無法確定自動化是否真正增加業務價值,或為使用者建立非預期的複雜性。您建立的每個自動化都應繫結至一組清楚且可測量的 KPI。 良好 KPI 由可測量的值與相關聯的時間範圍定義。範例包括: - \[X 數] 每個月儲存的工作時數 - 每週手動資料輸入的處理失敗減少 \[Y%] 一旦您擁有清楚且可測量的 KPI,您也必須瞭解 Salesforce 中的自動化是否以及如何產生與根據這些 KPI 報告相關的資料。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/automated#效率模式與反模式)清單顯示 Salesforce 自動化時的正確 (與不良) KPI 外觀。您可以使用這些項目來驗證現有的 KPI,或在建立之前找出需要更進一步識別 KPI 的位置。 若要深入瞭解 Salesforce 提供可協助 KPI 的工具,請參閱與自動化相關的 [工具](/docs/architect/zh-tw/well-architected/guide/automated#與自動化相關的工具)。 ### 效率模式與反模式 下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/easy-efficiency)探索更多效率模式。
模式 防模式
流程設計 在您的組織中:
- 每個流程都提供單一特定用途
- 每個步驟都會執行特定的細微工作
- 流程以包含主要流程和支援子流程的階層結構進行組織
- 流程內所有使用者輸入都具有明確的目的
- 僅在無法使用現有系統資料時要求使用者提供資料
在您的組織中:
- 流程可用於多種用途,且需要額外的輸入才能提供內容
- 流程需要未使用資料的輸入
- 相關步驟群組包含與其他流程中步驟群組重疊的功能
- 當可以改用儲存的資料時,流程會要求使用者輸入
在 Apex 中:
- 每個類別都提供單一特定用途
- 每個方法都會執行特定的細微工作
- 所有輸入變數在類別中都有明確的目的
- 程式碼執行需要最少數量的資源
在 Apex 中:
- 類別適用於多種用途
- 方法執行多個工作,或方法執行不符合其所屬類別所述用途的工作
- 輸入變數實際不會用於方法
- 方法不必要地從資料庫或外部系統提取資料
作業邏輯 在流程中:
- 沒有變數參照硬式編碼值 (針對記錄類型、使用者等)
- 所有自動啟動流程和程序都會使用決策和/或暫停元素來評估輸入條件,並防止對大型資料量執行無限迴圈或執行
- 在大型資料量內容中將流程 (包含程序) 授與 Apex 的邏輯
- 子流程用於需要在整個業務中重複使用的流程區段
在流程中:
- 變數具有硬式編碼值
- 必須先手動停用流程 (包含程序),才能大量載入資料
- 流程 (包含程序) 會觸發「未處理例外」通知
- 即使是簡單的流程也會定期造成與管理員限制相關的錯誤
- 流程的部分會在流程之間重複,而非使用子流程
在 Apex 中:
- 沒有變數參照硬式編碼值 (針對記錄類型、使用者等)
- 所有萬用字元條件都會顯示在 SOSL 中
- SOQL 封裝在 試用中
- 迴圈內沒有 SOQL 顯示
- SOQL 陳述式是選擇性的,包括:
-- 不使用 LIKE 比較或部分文字比較
-- 比較運算子使用正數邏輯 (亦即 包含, IN) 作為主要或唯一邏輯
-- = NULL、!= NULL 的使用極少見,且/或一律遵循正比較運算子
-- 沒有顯示 LIMIT 1 陳述式
-- 沒有使用 ALL ROWS 關鍵字
在 Apex 中:
- 變數具有硬式編碼值
- SOSL 極少或不一致用於萬用字元選取條件
- SOQL 不包含在 試用中
- SOQL 會顯示在迴圈內
- SOQL 陳述式為非選擇性,包括:
-- 顯示 LIKE 與萬用字元篩選條件
-- 使用 NOT、NOT IN 條件的比較會作為主要或唯一比較運算子使用
-- = NULL、!= NULL 條件會作為主要或唯一比較運算子使用
-- 顯示 LIMIT 1 陳述式
-- 使用 ALL ROWS 關鍵字
在您的設計標準和文件中:
- 系統會清楚概述自動化的計畫式與潛在執行路徑
- 自動化中的同步和非同步作業使用個案會清楚概述為設計標準的一部分
在您的設計標準和文件中:
- 自動化叫用未記錄
- 未處理同步和非同步作業的使用個案
KPI 在您的文件中:
- 每個自動化的輸出皆為可測量且繫結時間
- 系統會針對每個 KPI 列出負責的利害關係人
在您的文件中:
- KPI 不存在於自動化,或有不明確的測量時間範圍
- KPI 存在於沒有負責的利害關係人的情況下
在報告與顯示面板中:
- 與 KPI 相關的所有度量都包含在至少一個報告或顯示面板中
在報告與顯示面板中:
- KPI 報告不存在,或報告缺少與某些 KPI 相關的度量
## 資料完整性 資料完整性是指系統維護準確且完整資料的程度。Salesforce Platform 維護強大的 [內建處理邏輯](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#資料庫操作),專為保護儲存在個別組織關聯性資料庫中的資料完整性而設計。建立健康自動化的基本概念之一是瞭解 Salesforce 的內建資料完整性行為,並確保所有自動化設計都符合 (並確認) 這些行為。 自動化設計中最大的反模式是因為無法辨識 Salesforce 已經提供的強大[資料完整性服務](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#資料庫操作),以及無法使用利用這些服務的[標準功能](/docs/architect/zh-tw/well-architected/guide/intentional#標準與自訂功能)。若要設計可保護及維護資料完整性的自動化,您必須熟悉 Salesforce 作業行為的基本順序。 將資料完整性適當延伸至自訂自動化,表示您的系統可以: - 無須手動介入即可對抗大量與大型資料量, - 視需要強制執行使用者安全性原則,並視需要切換至系統內容, - 在執行階段遇到錯誤,並遵循可預測的復原或失敗路徑。 您可以透過正確的資料處理和錯誤處理,將更佳的資料完整性建立在 Salesforce 自動化中。 ### 資料處理 設計 Salesforce 中正確資料處理的第一步是瞭解多重租戶平台如何處理[交易](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#交易)。這包括瞭解 Salesforce Platform 用來在記錄層級資料作業期間確保資料完整性的內建執行行為[順序](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)。如需有關此行為影響的詳細資訊,請參閱 Salesforce 結構基本概念中的 [資料庫操作](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#資料庫操作)。 自動化中的資料處理不佳,可能是最難識別和完全修復的反模式之一。平台執行順序的遞迴性與重疊性質可能會導致難以瞭解問題的起源。將致命錯誤或超過管理員限制的程式碼或流程特定區段可能不是基本資料處理問題的根本原因。 *交易認知*是建立可靠且大規模執行 Salesforce 之自動化的關鍵。這意味著確保自動化中的每個步驟都經過設計,並瞭解其與平台控制的執行[順序](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)相關的 Knowledge,可以正確執行其功能,並將資訊正確傳遞至下一個步驟。 無論您使用的自動化工具為何,適當的交易感知會遵循類似的模式,且需要一般考量事項: - 假設系統會要求您針對大量資料執行所有自動化,且不會在任何時間通知。自動化應具有允許批次或大量執行的路徑 (請參閱「[延展性](/docs/architect/zh-tw/well-architected/guide/reliable#延展性)」)。 - 請勿在相同的交易中混合系統和使用者內容資料作業。 - 將同步化資料作業保留在 [_前後_ 環境](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm) 中,並針對所有內容 _後_ 動作使用非同步化作業。 - 使用 [傳訊與通知](/docs/architect/zh-tw/well-architected/guide/engaging#通知與訊息)可避免建立應用程式內體驗,這會要求使用者根據非同步作業的結果等待資料。 除了交易認知之外,資料處理還有第二個維度:瞭解何時在不同[執行內容中執行](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#執行內容)邏輯。將自動化拆分為不同執行內容的常見原因包括: - **大量和/或複雜的資料作業** - [大量處理作業](/docs/architect/zh-tw/well-architected/guide/automated#資料處理)並不保證自動化將正確處理大量資料。如果自動化中的資料作業量超過每個交易限制,您將需要使用大型資料量特有的功能 (例如透過批次 Apex 或 [大量 2.0 API](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm)) 來執行資料作業。這些項目有不同的交易限制,適用於大量資料。 - 當大量執行時,需要在記錄之間周遊複雜關係階層或執行複雜重新計算 (不包括公式欄位) 的資料作業可以輕鬆超過每個交易限制。考量某個記錄更新的「雜訊」程度,以完成系統中後續動作所需的相關資料作業或 SOQL 為準。 - 自動化整個鏈中涉及的 sObject 類型可能需要您將資料作業分割成個別的交易,以避免發生「[混合 DML](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm)」錯誤。 - **需要在使用者或系統環境中執行的邏輯** - Salesforce Platform 會在使用者環境中強制執行[共用與可視性](/docs/architect/zh-tw/well-architected/guide/secure#共用與可視性)。如果您需要執行超出自動化使用者權限層級的作業,您必須確保這些作業在系統環境中執行。 - 不同的工具會或不會在不同的環境中執行: - Apex 依預設會在系統環境中執行。您可以使用 Apex 類別定義中的 [共用關鍵字](https://developer.salesforce.com/docs/atlas.en-us.238.0.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm?q=run%20as%20user)來控制 Apex 行為是否以及如何強制執行使用者層級共用規則。 - 流程沒有單一預設行為。流程會在使用者或系統環境中執行,[視流程啟動方式而定](https://help.salesforce.com/s/articleView?id=sf.flow_distribute_context.htm&type=5)。您可以選擇在系統環境中強制執行共用。 - 流程 (亦即使用流程產生器建立的自動化) 會在系統環境中執行,而無須共用考量事項。(注意:我們建議使用「流程」建立低程式碼自動化。 - **需要以非同步方式執行的邏輯** - 外部系統作業 - 存取外部資料的同步呼叫或動作不會包含在任何平台回復行為中。若要利用這些行為,您必須將涉及外部系統的動作放入個別的交易中 (使用非同步 [Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_async_overview.htm) 方法、[非同步路徑](https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_builder_asynchronous_path.htm&type=5&release=234)或可叫用的 [動作](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_forcecom_flow_invocable_action_callout.htm))。 - 事件與傳訊 - 若要控制與資料作業相關之事件或訊息的流程 (並利用平台回復行為),請使用非同步 Apex 方法,將與傳訊或事件相關的所有動作放入 [內容\_\_](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm)後。 下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/automated#資料完整性模式與反模式)清單顯示 Salesforce 自動化中的正確 (與不良) 資料處理。您可以使用這些功能在建立之前驗證您的自動化設計,或識別需要重新設定以改善資料處理的自動化。 若要深入瞭解 Salesforce 可用於自動化中資料處理的工具,請參閱與自動化相關的 [工具](/docs/architect/zh-tw/well-architected/guide/automated#與自動化相關的工具)。 ### 錯誤處理 錯誤處理對於資料完整性而言至關重要。強大的錯誤處理也可協助您的系統調整規模並使其更具[彈性](/docs/architect/zh-tw/well-architected/guide/resilient)。 自動化中的錯誤處理可能會導致: - 記錄不一致和其他資料完整性問題 - 傳送不準確的通知給使用者和其他系統 - 浪費時間與資源以手動或重複處理 - 整體缺乏系統的 [Trust](/docs/architect/zh-tw/well-architected/guide/trusted-overview) 自動化中的錯誤處理需要授與任何執行中的程序剖析資訊錯誤的功能、根據錯誤資訊存取後續步驟應如何的邏輯,然後遵循正確的路徑。這些功能不需要在每個自動化中重複建立 (這是[最佳化反模式](/docs/architect/zh-tw/well-architected/guide/automated#流程設計))。相反地,系統中的每個自動化都應能夠連線至相關的錯誤處理 [元件](/docs/architect/zh-tw/well-architected/guide/composable#寬鬆配對)。 若要在您的自動化中建立適當的錯誤處理控制項,請詢問以下問題: - 什麼是「致命」錯誤? - 什麼是「可復原」錯誤? - 針對由使用者動作觸發的自動化,自動化如何在嘗試認可變更前找出錯誤並通知使用者? 決定如何處理這些錯誤後,您可以開始在自動化中建立有效的錯誤處理。下方的 [模式與防模式](/docs/architect/zh-tw/well-architected/guide/automated#資料完整性模式與反模式)清單顯示 Salesforce 自動化中的正確 (與不良) 錯誤處理。您可以在建立之前使用這些項目來驗證您的自動化設計,或識別需要重新設定以改善錯誤處理的自動化。 若要深入瞭解 Salesforce 可用於錯誤處理的工具,請參閱與自動化相關的 [工具](/docs/architect/zh-tw/well-architected/guide/automated#與自動化相關的工具)。 ### 資料完整性模式與反模式 下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。 ✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/easy-data-integrity)探索更多資料完整性的模式。
模式 防模式
資料處理 在您的資料字典中:
- 存在所有資料來源和資料湖物件的欄位級資料和優先順序邏輯
- 資料湖物件到資料模型物件的欄位對應已存在
在您的資料字典中:
- 不包含資料來源和資料湖物件的欄位級資料和優先順序邏輯
- 不包含資料湖物件到資料模型物件的欄位對應
在您的 Apex 中:
- 在觸發執行內容 之前,會執行所有同步 DML 陳述式或資料庫類別方法
- 非同步 Apex 叫用使用在交易之間的「鏈結」複雜 DML
- 批次 Apex 僅用於大量資料
- @future Apex 不會用於呼叫或系統物件 DML
在您的 Apex 中:
- DML 陳述式會定期顯示在觸發內容 後 要叫用的程式碼中
- 極少使用非同步 Apex
- 非同步 Apex 功能會被任意使用,包括:
-- Future Methods 與可排列 Apex 不一致或交替使用
-- 資料庫作業沒有明確且一致的邏輯,可在需要時將執行傳送至批次 Apex
在流程中:
- 在使用者環境中啟動的所有流程會將所有系統環境交易摘要到子流程 (會一致地放在「暫停」元素之後) 以建立新交易
- 使用協調器建立相關資料作業的複雜序列 (而非在單一流程內叫用多個子流程)
- 所有記錄觸發流程均已填入觸發順序值
- 涉及外部系統呼叫或長時間執行程序的流程會使用非同步路徑
在流程中:
- 大型單一流程會嘗試協調相關資料作業的複雜序列 (含或不含子流程)
- 記錄觸發流程完全不使用觸發順序屬性,或不一致使用觸發順序值
- 非同步路徑不會一直或完全使用
在您的組織中:
- 「身分解析協調規則」遵循資料字典中的優先順序邏輯
在您的組織中:
- 身分解析協調規則不遵循資料字典中的優先順序邏輯
錯誤處理 在 Apex 中:
- 程式碼會將所有 DML、SOQL、呼叫和其他重要程序步驟包含在 試用抓取區塊中
- 自訂例外用於建立進階錯誤傳訊和邏輯
- 在非同步和大量環境中,會使用 資料庫類別方法,而非使用 DML
- 資料庫類別方法只能用於所有資料作業 (而非 DML)
在 Apex 中:
- DML、SOQL、呼叫或其他重要程序步驟並未一致封裝在 試用區塊中
- System.debug 陳述式會顯示在生產程式碼中 (且不會加上註解)
- 未使用資料庫類別方法
- 資料作業僅使用 DML 進行
在 Lightning Web 元件 (LWC):
- JavaScript 會將所有資料作業和重要程序步驟包含在 if()/else if() 區塊中
- 所有 @wire 函數都使用 API 提供的 資料和 錯誤內容
- All if (error)/else if (error) 陳述式包含處理錯誤並提供資訊豐富訊息的邏輯
在 LWC 中:
- JavaScript 不會持續使用資料作業或重要程序步驟的封鎖 若 ()/其他 if ()
- @wire 函數不使用 API 提供的 資料和 錯誤內容 (或不一致使用這些內容)
- 如果已使用,則陳述式實際上不包含處理錯誤的邏輯,且不提供實用的錯誤訊息,如果 (錯誤)/其他 (錯誤)陳述式
在 Aura 中:
- JavaScript 會將所有資料作業和重要程序步驟以 試取區塊括住
- 在 試用區塊內,會在 throw 陳述式中使用原生 JavaScript Error (不使用 $A.error())
- 所有可復原錯誤邏輯都會顯示在 抓取陳述式中,並提供清楚的使用者訊息
在 Aura 中:
- JavaScript 不會將資料作業和重要程序步驟一致括在 試用區塊中
- 元件使用 $A.error()
- 可復原錯誤邏輯不會一直顯示在 抓取陳述式中,且使用者的錯誤訊息不明確
在流程中:
- 畫面流程會持續使用錯誤連結向使用者顯示錯誤
- 已針對畫面上顯示的錯誤設定自訂錯誤訊息
- 具有資料作業、呼叫和其他重要處理邏輯的流程具有所有關鍵動作的錯誤路徑
在流程中:
- 流程不會一直或完全使用錯誤路徑
- 未使用自訂錯誤訊息,因此使用者會看到預設的「在此流程中發生未處理的錯誤」訊息
## 業務價值 在自動化方面,業務價值的概念是關於流程如何對業務專案關係人產生可測量的正面影響。理想情況下,流程自動化可讓使用者更少花費時間處理重複的低價值工作。它也會透過去除可能產生錯誤的手動處理活動來協助提升資料完整性。與 [流程設計](/docs/architect/zh-tw/well-architected/guide/automated#流程設計)類似,識別並提供將推動實際業務價值的自動化需要超出基本探索和業務分析的工作。 有時,將價值提供給業務的最佳方法似乎就是簡單地將業務使用者要求的每個流程自動化,無論其出現在待處理項目 (或票證排行榜) 中的順序,或根據您組織中的政治因素。這可能會導致兩個相關問題:以子最佳順序建立自動化,以及建立錯誤的自動化。第一個問題,即優先順序不佳,會讓高價值流程無法在應用時進行實作,進而降低成長速度。第二個問題,建立錯誤的自動化,不僅會延遲高價值的自動化傳遞,也會導致錯誤的時間、不必要的成本,以及傳送小組的挫折度增加。 您可以透過專注於 KPI 和排定優先順序來提供更大的業務價值。 ## 與自動化相關的工具
工具描述效率資料完整性業務價值
Apex 批次批次記錄並處理為可管理區塊XX
Apex Future 方法在背景中非同步執行 Apex 方法XX
Apex 等級將 Apex 工作新增至某列,並監視這些工作XX
Apex Scheduler在指定的時間非同步執行 Apex 類別XX
批准指定批准記錄的必要步驟XX
非同步 Apex非同步執行 Apex 程式碼XX
自動化動作在背景中執行欄位更新、電子郵件傳送和其他動作XX
Einstein Next Best Action在正確的時間向正確的人員顯示正確的建議XX
電子郵件警示建立與傳送自動化電子郵件XX
升級動作指定要對個案升級採取的自動化動作XX
欄位更新根據自動化更新欄位值XX
Flow Builder使用點選介面建立自動化XX
流程擴充存取儲存的變數作為流程中的元件輸入X
流程範本庫使用範本設計產業特定的流程XX
流程觸發自動化複雜的業務流程X
可叫用動作將 Apex 功能新增至流程XX
協調流程建立與管理多步驟自動化XX
輸出訊息透過收據和重試,從自動程序傳送資訊 X
使用流程發佈平台事件透過使用者互動與自動化發佈事件X
查詢最佳化工具使用選擇性與索引改善查詢、報告和清單檢視效能XX
Salesforce 流程使用 Flow Builder 建立陳述性流程自動化XX
使用流程傳送通知透過 SMS、WhatsApp 或 Facebook Messenger 傳送訊息XX
使用程序傳送通知透過 SMS、WhatsApp 或 Facebook Messenger 傳送訊息XX
SOQL FOR UPDATE 修飾詞鎖定記錄以防止比賽條件和執行緒安全問題X
Strategy Builder 識別要在記錄頁面上顯示的建議XX
子流程透過重複使用降低流程複雜性X
使用流程訂閱平台事件接收透過自動化發佈的訊息X
工作動作決定由自動化提供給使用者的指派詳細資料X
## 與自動化相關的資源
資源描述效率資料完整性業務價值
Apex 執行管理員與限制瞭解 Apex 執行階段引擎如何強制執行限制XX
批次管理資源建立、管理、排程和監視批次工作XX
SOQL 和 SOSL 的最佳作法 改善具有大量資料之應用程式的查詢效能X
設計標準範本為您的組織建立設計標準XXX
交易中的流程大量處理設計流程以針對集合作業XX
流程資料考量事項瞭解批次資料的排程觸發流程XX
流程除錯測試和疑難排解流程X
要求的處理方式瞭解 Salesforce 如何快速處理工作並將失敗降到最低XX
KPI 試算表範本決定特定度量的業務價值XX
從可叫用動作對外部系統進行呼叫使用 Apex 從流程呼叫外部系統X
混合 DML 作業 瞭解哪些 sObject 可在相同交易中一起用於 DMLXX
執行指示瞭解插入、更新和更新插入的事件順序XX
查詢計畫常見問題最佳化涉及大量資料的查詢XX
排程觸發流程考量事項瞭解排程所觸發流程的特殊行為X
交易控制產生指定目前資料庫狀態的 savepointXX
流程失敗時會發生什麼事?瞭解流程中的錯誤處理XX
工作流程自動化最佳作法指南開始使用 Salesforce 自動化XXX
使用非常大的 SOQL 查詢撰寫更有效率的 SOQL 查詢X
## 告訴我們您的想法 協助我們讓 Salesforce Well-Architected 與您相關;進行我們的[調查](https://sfdc.co/bxNtvh)以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。