資源和成本最佳化

資源和成本最佳化

資源最佳化與成本最佳化可共同協助貴公司達成每個成本的最大價值。Salesforce 管理多租戶基礎結構、強制執行管理員限制,讓平台對每個租戶保持公平,以及透過授權和耗用信用存取價格。您最佳化的項目是回傳的值:每美元的支出業務成果與每個平台產能單位的退貨量。資源最佳化是下列機制:它會有效利用您已付費的項目。成本最佳化是以下結果:它會刻意將支出導向推動競爭優勢的項目。此支柱會將其視為一個決策,因為它們是同一個目標的兩個觀點。

此按成本的價值檢視會塑造您所做的每個結構決策。當您瞭解擁有總成本時,您可以更妥善地在能力與投資之間權衡。您可以調整解決方案大小,以符合業務需求,而不是過度佈建未使用或投資於加速價值傳遞能力的功能功能。授權、耗用信用、API 呼叫和 Sandbox 環境皆為相同方程式的輸入。重要的是每個傳回的值,而不是其所在的總帳。問題從未是「這是成本還是資源」,而是「此輸入是否有適當的回扣?」

忽略此支柱會產生可預測的後果。公司會累積耗用預算的未使用授權,而其他功能仍未獲得資金。結構效率不佳會浪費 API 容量、儲存空間和開發工作,以解決更好的設計所防止的問題。特定化合物在一段時間內以可預測的方式產生資源效率:

  • 效能會隨著資料量增加而降低。
  • 當非選擇性查詢掃描整個表格時,查詢逾時會出現在數百萬筆記錄中。
  • 堆疊限制例外會在解決方案取得不必要的欄位時顯示。
  • 複雜計算同步執行時,CPU 逾時會顯示。
  • 因應措施會在小組輪替每個新限制時相乘。

每個失敗都是可靠性問題與成本問題,因為浪費的計算會消耗您付費的容量。最關鍵的是,小組會遺漏投資於創新的機會,因為預算和工程產能是由廢棄物而非策略性倡議所消耗。

符合成本效益的解決方案可透過:

  • 使用已購買的平台功能
  • 使大小正確的授權與耗用與實際使用保持一致
  • 認可方法前先建模完整成本
  • 根據業務成果持續監視費用

這些作法是複合的。將成本認知與資源效率建立在其設計中的小組,可為每美元提供更多能力,而非在支出已增加後將最佳化視為清理演練的小組。

「資源和成本最佳化」會直接連線至其他結構支柱。「卓越作業」可透過降低手動工作量的自動化來減少持續成本。可靠性和 Trust 可透過業務連續性保證和法規合規性價值來證明高級投資。這些支柱共同協助公司有信心進行投資,因為其結構可提供最大回報。

使用這些原則來引導您在平台上針對資源和成本最佳化的結構決策。

  • **針對總擁有成本最佳化。**總擁有成本 (TCO) 超出訂閱費用,延伸至耗用信用、實作成本、營運成本、整合費用和變更管理工作。使用 TCO 分析評估決策,以顯示解決方案生命週期內的完整投資狀況。有時候,前期投資越高,會大幅減少進行中的營運成本,而 TCO 分析會呈現權衡。針對長期價值最佳化,而非短期成本最小化。

  • **以業務價值對齊支出。**將每個 Salesforce 投資連線至可測量的業務成果。授權支出可讓使用者透過採用與工作完成來測量生產力。Data 360 投資可強化透過轉換和客戶終身價值測量的決策。Sandbox 的成本是透過部署頻率和品質測量的基金開發速度。當花費與價值保持一致時,您可以自信地投資推動成功的因素,並識別不再獲得報酬的費用。

  • **在平台限制內設計。**管理員限制會定義解決方案可針對每個交易處理的內容。請從一開始將其視為設計限制,而非要解決的障礙。設計在高峰負載和資料量上限的限制內舒適運作的交易,並為未來的功能、其他已安裝的封裝和非預期的資料模式建立利潤。設計在概念上限制之內的解決方案具有可預測的效能,且稍後會避免緊急重構。

  • **最佳化您已付費的資源。**在購買更多容量前,請將已佈建平台資產的輸送量、效率和價值最大化。有效率的查詢、大量處理記錄 (大量處理)、快取和嚴謹的資料生命週期會減少解決方案所需的運算、儲存和 API 耗用。此資源效率是推動永續成本最佳化的機制:從提供的資源中去除的廢棄物可改善績效與長期 TCO。

  • **大小正確的授權與耗用以實際使用。**將每個使用者與其工作所需的授權類型進行比對,並設計自動化和工作人員,以有效率地叫用計量服務。過度授權與未監視的耗用信用是最常見且成本最昂貴的廢棄物來源。針對角色、登入活動和功能用量進行定期稽核,並確保對信用額度的清晰可見性,讓以耗用量為基礎的成本保持可預測。

  • **建立財務管理和成本感知的文化。**透過主動監督和共用責任來管理 Salesforce 支出作為策略性投資。財務管理會將成本效益分析帶入設計決策,而非在部署後探索成本。成本認知是業務專案關係人、結構設計師和開發人員的共同責任,他們會將成本影響與功能需求同時加權,因此在每個層級都會進行智慧型投資決策,而不會集中瓶頸。

  • **實作持續最佳化。**最佳化是持續的實作,不是一次性的演練。透過可供技術和業務專案關係人存取的顯示面板監視費用和資源消耗。設定當耗用支出達到達值時,在忽略耗用前觸發的警示。定期審查會發現逐漸累積的廢棄物、驗證先前的最佳化投資是否提供預期的報酬率,並在業務優先順序和資料量不斷發展時呈現新的機會。

瞭解 Salesforce 作業的內容可協助您將最佳化工作專注在您控制的項目上。此平台可處理在傳統 IT 環境中需要專屬的小組的基礎結構層級資源管理:

  • **多租戶資源配置:**Salesforce 可確保在共用基礎結構上所有客戶的 CPU、記憶體和資料庫連線共用公平、監視租戶耗用,並強制執行限制,以防止任何單一租戶降低其他客戶的效能。
  • **管理員限制結構:**平台強制執行的邊界 (每個同步交易 100 個 SOQL 查詢、10 秒 CPU 時間、6 MB 堆疊大小) 可保護所有租戶免受資源耗盡。Salesforce 會對多租戶基礎結構容量校正這些限制。這些限制是結構界限,而非任意限制。
  • **查詢最佳化工具與執行引擎:**Salesforce 查詢最佳化程式會產生執行計畫、維護資料散佈的統計資料,並選取最佳查詢路徑。標準欄位上的平台管理索引會加速常見的查詢模式,最佳化程式會自動調整資料量變更。
  • **基礎結構調整:**Salesforce 會佈建硬體容量、管理資料庫叢集、分配載入,並隨著使用量增加來調整基礎結構。您永不佈建伺服器、管理資料庫複製或設定負載平衡器。
  • **平台效能最佳化:**Salesforce 會持續最佳化核心平台程式碼、查詢執行、API 回應時間和 UI 架構效能,並透過其定期發行提供基礎結構改善,而不需要客戶採取動作。

Salesforce 也會管理平台的商業層面,因此授權與耗用都屬於運算與儲存的相同支柱。平台會定義購買容量的版本、授權類型、附加元件和耗用信用模型,並測量減少這些信用的使用量。您在佈建伺服器時,不會再設定這些價格,而是決定每個價格的耗用量:每個使用者擁有的授權、自動化叫用計量服務的效率、有多少 Sandbox 保持啟用。

這些平台作業是您建立的基礎。由於 Salesforce 同時管理基礎結構與定價模型,因此您的最佳化工作完全取決於您在基礎結構上進行的決策:您如何有效率地使用提供給您的資源,以及如何刻意導向提供資源的支出。

「共用責任模型」表示您擁有 Salesforce 中所建立所有項目的資源效率。平台資源管理支援您的工作,但不會取代您最佳化的需求。有效率的解決方案會從您已付費的運算、儲存和 API 產能中傳回更多業務價值,這是一種讓成本最佳化保持可持續性的機制,而不是一次性的減少預算。相反地,浪費運算會耗用基礎結構資源,而不會提供業務價值及其成本組合。隨著資料量增加,效能會以預測的方式降低,而因應措施會隨著小組在其設計的限制之間進行修補而增加。

您的最佳化責任涵蓋四個相互連線的區域:效能、程式碼組織、封裝和資料。每個項目都是成本價值決策,而不是技術性決策。本節說明如何做出該決策,以及其重要原因。此區段中參照的確切實作配方、程式碼層級範本、設定瀏覽和特定調校值位於「資源和成本最佳化」模式庫中。

效能最佳化從您考量管理員限制的方式開始。它們並不是您可以解決的障礙。這些是架構限制,當從初始設計中採用時,會產生具有可預測效能特性的解決方案。每個交易都會在固定的邊界內執行,而這些邊界存在於平台上,以強制執行平台上每個租戶的公平資源共用。耗用其 100 個允許 SOQL 查詢中的 95 個 Apex 交易不會為未來功能、其他小組新增的觸發或非預期的資料模式留下任何餘額。讓交易遠低於限制的一半的結構設計師可建立解決方案,這些解決方案在耗盡限制時無須緊急重構。規範是在高峰負載和資料量上限的限制之內設計,讓新增功能或其他封裝的自動化永遠不會讓交易超出邊緣。常見且高成本的失敗:此解決方案在 Developer Sandbox 中適用於 10 個記錄,但在生產環境中達到管理員限制。Developer Sandbox 僅複製組態,且不包含任何資料。在 Full Copy Sandbox 中對照實際的體積進行測試,會在客戶之前呈現延展性問題。

查詢選取性是解決方案是否可調整為數百萬筆記錄或逾時數百萬筆的單一最大杠杆。選擇性查詢會使用索引有效找到記錄,而非選擇性查詢會掃描整個表格、耗用過多的資料庫資源,並最終逾時。平台會在已定義的欄位集中維護標準索引,並套用隨著物件成長超過其前一百萬筆記錄而縮小的選用性上限。針對選擇性進行結構描述意味著篩選索引欄位作為您的主要條件,並在針對大型物件部署之前使用查詢計畫工具進行驗證,因為顯示大量物件表格掃描的查詢是等待發生的生產事件。選擇性是您不必購買的容量:有效率的查詢會以毫秒傳回,並讓資料庫資源可供您組織中每個其他租戶和每個其他交易使用。

大量處理是基本的延展性模式,可區別大規模作業的 Apex 和達到限制的 Apex。反模式 (位於迴圈內的查詢或 DML 陳述式) 適用於小型記錄集,但違反管理員對大量作業執行時間限制。解決方法是在迴圈外的單一陳述式中查詢所有必要的資料、將結果組織為由識別碼金鑰的地圖,以在迭代期間快速對應,並使用批次 DML 處理整個集合。設計每個自動化,以在不接近限制的情況下處理標準 200 筆記錄觸發批次,且無論生產環境中的負載為何,都會有相同的程式碼級數。

無法或不應在使用者交易的同步限制內完成的工作存在非同步處理。將該工作移至非同步環境大致會使其可用的管理員限制倍增,並防止長時間執行作業封鎖使用者。該標題空間是真實的,但並非免費,而且當限制感到已結束時,只要尋求非同步,便是錯誤。非同步是刻意的結構權衡:它會導入最終的一致性,因此要求工作的交易中不會顯示工作的結果,這會強制使用者體驗做出不取決於立即確認的決定。這需要明確的錯誤處理與監視,因為失敗會出現在工作記錄中,而非觸發它的使用者。單一業務作業跨越多個交易時,系統的精神模型可能會變得複雜。成本價值的決定是將增加的複雜度對照工作真正需要的容量加權,並在工作舒適時保持同步。

當非同步為正確的呼叫時,機制之間的選擇會遵循工作的形式,而非限制的大小。批次 Apex 適用於 大量使用。它會將數百萬筆記錄分成區塊來處理,每個記錄都有自己的獨立管理員限制,這就是資料移轉、資料歸檔和大量增強所屬的原因。Sequence: 的可排列項目它會處理超過同步限制但不需要「批次」刻度的多步驟工作流程,並支援針對必須依序執行的步驟,將一個工作從另一個工作鏈結。「平台事件」適用於 取消連接:生產商在未瞭解或等待其消費者的情況下發送事件。將此模式用於跨系統通知,並用於分隔不屬於相同交易的工作,考量到至少一次傳送需要 IDempotent 訂閱者。未來方法涵蓋使用原始輸入簡單非同步工作的窄個案,通常是同步觸發中的呼叫。他們無法鏈結或接受複雜物件,這正是他們不是所有用途非同步工作的工具的原因。將非同步機制與工作的形狀進行比對。否則,您會將管理員限制問題取代為一致性,並監視高於收益的成本。

快取會將重複的工作轉換為您保留的產能。「平台快取」會跨交易界限儲存可序列化資料,因此快取會避免重新執行產生值的查詢或重新計算,直接減少 SOQL 和 CPU 耗用。建立或中斷快取的決策是您選擇在快取中放入的項目以及時間長度。快取讀取比變更更更頻繁的資料,例如自訂中繼資料、組態和選項清單值,並設定即時時間以符合資料的波動性,而非單一預設值。每月變更的參照資料可以安全地快取數小時,而一天變更的組態需要一個短的視窗,如此快取永遠不會提供過時值,時間足以重要。過於積極的快取會將績效成交交易為正確性風險,而具有較差成交率的快取會花費儲存空間而不傳回容量,這就是為什麼成交率是要監視的度量,而不是要假設的設定。分割選項是安全性決策:針對跨使用者共用的資料使用組織分割、針對必須保持隔離的使用者範圍資料使用工作階段分割,且永不將個人身分識別資訊放置在組織分割區中,讓每個使用者都能讀取。Lightning Data Service 會將相同的計畫延伸至用戶端:它會在頁面上的每個元件之間共用快取的記錄,並排除冗餘的伺服器來回行程。只要傳回的值仍然正確,每個快取事件都會是您不必花費的運算和 API 容量。

資料誤差是由不平衡的記錄散佈所建立的效能熱點。當單一父系記錄累積超過 10,000 個子系時,查詢效能會降低,且在同時作業期間會出現列鎖爭用。這是設計訊號,不是硬性限制。它會告訴您在多個父系之間分配載入、使用已排程工作來監視大量物件,以在任何父系接近邊界時警示,並依父系識別碼排序大量載入,讓同時批次不會在相同的列上衝突。擁有權誤差 (其中整合使用者擁有數百萬筆記錄) 會產生相同的鎖定爭用,並且值得相同的負載分佈。

Salesforce 提供工具來隨著解決方案的進化保持效能特性健康。「刻度中心」提供長時間執行作業、列鎖爭用和即將達到限制的交易交易層級可視性,然後命名涉及的特定觸發和物件。ApexGuru 會將 AI 分析套用至生產執行階段距離測量,以在反模式達到規模之前呈現,而 Salesforce Code Analyzer 會在 CI/CD 管道中執行靜態分析,因此當查詢出現在迴圈內或偵測到其他效能瑕疵時,組建會失敗。「事件監視」會顯示隨時間的耗用趨勢,而「Proactive Monitoring」(「簽章成功計畫」功能) 會持續評估組織的效能與延展性風險。

程式碼組織是以維護性表示的成本決策。維護通常會耗用成熟解決方案的大部分開發容量,因此您選擇的結構會決定未來的容量變更為何,而非重新處理。三個模式承載該值的大多數。觸發處理常式模式會將觸發邏輯集中在處理常式類別中,並將觸發檔案本身減少至最小委派點,這可讓邏輯保持可測試,不受觸發內容影響,並提供遞迴控制單一首頁。服務層模式會將業務邏輯壓縮在類別中,這些類別會顯示可從觸發、REST 端點、可叫用流程或批次工作呼叫的作業,因此業務規則會存在於一個實作中,而不是在每個進入點之間重複並逸出同步。選取器模式會為專屬類別中的每個物件集中 SOQL,這會使查詢調整為單點變更,並為每個查詢提供明確且具名意圖。

混合 DML 錯誤是個別的組織風險,值得明確地針對。當一個交易對設定物件 (例如「使用者」和「權限集」) 和非設定物件 (例如「帳戶」和自訂物件) 執行 DML 時,它們會發生,因為影響使用者存取權的設定變更必須在個別的交易中認可。在整合工作、測試設定和使用者提供自動化中大規模出現失敗。結構修復措施包括使用非同步處理或平台事件,在交易界限之間分隔設定與非設定 DML,設計資料模型以避免在單一業務步驟中結合這兩個作業,並在測試中隔離設定 DML。

封裝選項會定義長期開發成本,以及您可在整個公司中達到的重複使用。第二代受管理封裝提供具有命名空間保護的來源驅動模組化開發,且是透過 AgentExchange 散佈的「獨立軟體廠商」(ISV) 產品的正確選擇。解除鎖定的封裝可提供內部小組相同的模組化與相依性管理,無須命名空間超額,適用於需要獨立部署但無市集清單的企業應用程式。第一代受管理封裝仍會用於現有產品,但缺少可維持新模組開發的新來源驅動工作流程。

模組性會延伸至您建立的元件。使用清晰的內容介面設計 Lightning Web 元件,以單一責任為基礎,將組成優先於繼承,讓複雜的 UI 從小型聚焦元件進行組合,並使用自訂事件進行父系通訊,而非直接連絡父系。將可重複使用的 Apex 公開為可叫用動作,讓管理員可以從開發人員建立的功能撰寫 Flow Builder 中的自動化,進而減少重複項目,並橋接陳述性與程式設計的世界。設計良好的模組性可讓功能建立一次並重複使用,而非在需要的每個位置重新實作並分開維護。

未受管理的資料成長是漸進式效能降級的最常見來源,並同時提高儲存成本和 Sandbox 重新整理時間。有兩個決策可管理資料效率。第一個是資料模型設計。「主要 - 詳細資料」關係可提供串聯刪除、累計摘要和資料共用,但需要更緊密的配對。對應可提供自訂累計邏輯所需的彈性,而您篩選欄位的刻意索引策略可讓查詢隨著物件成長保持選擇性。第二個是資料生命週期。定義從建立到歸檔的完整生命週期,而不是讓物件無限期累積記錄,因為若物件在沒有歸檔策略的情況下成長為數百萬個,則最終會產生逾時的查詢逾時、非選擇性查詢和清單檢視。

只有在您協調合規性後才選擇歸檔機制。選擇機制之前,請確認資料落地、刪除權或保留需求是否會限制您的選項。大型物件無法在插入後修改,這會使僅限記錄刪除已歸檔的個人資料成為可能影響稽核追蹤的刪除與重新建立作業。大型物件會將大量的歷程記錄資料集儲存在與標準限制分開的儲存空間中,並符合不再用於日常工作的已完成交易和稽核記錄。外部儲存空間可透過 Salesforce Connect 讓資料保持可查詢,同時減少組織量,並適合彈性的查詢模式或與企業資料倉庫的整合。監視物件層級的儲存空間耗用,讓成長在變成問題前可見,使用 Salesforce Files 而非舊版附件,並針對合規性要求設定每個欄位的「欄位稽核追蹤」保留,而非套用浪費儲存空間的總計上限。

成本最佳化會將業務價值與解決方案成本平衡,這取決於一開始建立準確的成本。若要這麼做,請考量每個成本元件,因為查看單一元件 (例如授權成本) 會導致不正確地瞭解解決方案的實際成本。寬鬆的授權費用會隱藏實作、營運、整合和變更成本,進而使其變化。僅對可見數字進行的決策僅會使用圖片的一部分。「總擁有成本」是全方位的模型。它包含 Salesforce 解決方案在其存留時間內所有相關聯的成本,並將其分為直接成本 (明顯與解決方案相關聯) 和間接成本 (實際但容易忽略)。兩者建模會將成本估計轉為明智的結構決策,其會加權長期價值,而不只是初始費用。

系統的實作、作業和維護產生直接成本:

  • 授權與耗用成本是依版本、使用者類型與功能集而異的持續訂閱費用,以及以耗用為基礎的信用額。版本選擇是基本成本決策,因為每位使用者差異很明顯。很難及早建立耗用成本的模型,因此請在設計決策時重新造訪這些估計值。
  • 實作成本涵蓋解決方案設計、開發、測試、資料移轉和訓練。其主要是一次性,但會根據複雜度建立持續的維護義務。公司系統低估實作工作,因為他們專注於開發,並低估測試和訓練。
  • 營運成本涵蓋管理、使用者支援、監視、事件回應和作業工具。它們隨著解決方案的複雜性而成長,且通常在規劃中不可見,因為它們會顯示為內部工作而非外部發票。
  • 維護成本涵蓋增強、技術債務補救、版本調整和組態變更。維護通常會為成熟解決方案耗用 60–80% 的開發容量,這會使維護成為最大的持續成本種類。
  • 整合成本包括整合平台授權、API 耗用、同步化開發和持續維護。由於系統計數隨著增加而產生點對點整合維護複合,因此會隨著生態系統複雜度而成長。
  • 變更成本涵蓋業務流程重新設計、變更管理、採用和利害關係人協調。其會隨著跨業務單位和區域的接觸率而增加,且會經常省略,因為其會顯示為業務小組的努力。

間接成本在初始規劃中不會立即顯示,但會在解決方案的生命週期內大幅累積,對於成熟的實作而言,其通常會超過直接成本。一家僅最佳化其直接成本且忽略間接支出的公司會遺漏其總投資的大部分。多個種類值得特別關注。

組織成本是促進 Salesforce 成功但永不顯示在 Salesforce 發票上的投資。其中包括管理員、開發人員和結構設計師的內部小組薪資、如版本控制和 CI/CD 工具等開發基礎結構、訓練和認證維護和技能開發,以及分配給維護而非創新的開發容量機會成本。很難偵測到最後一個項目,因為它不會顯示為已支出。它會顯示為從未出貨的創新。

技術債務利息是結構快速鍵的組合成本。符合啟動期限所採取的快速鍵會產生維護負擔,這可能需要在稍後解決原始工作量的多次,而每一次耗用來修復債務的衝刺則是未提供新業務價值的衝刺。延後結構改善時間足夠長的小組最終發現大多數的容量會移至維護而非新功能。

管治額外負擔會耗用批准流程、協調會議和手動審查的時間。管治可透過降低風險和一致性提供實際價值,但過度的管治會透過延遲的決策和重複工作來產生隱藏成本,因此,目標是設計能促進安全自主性的系統,而不是為每個變更要求集中批准的瓶頸。

實作功能但從未完全採用功能時,會累積未使用的功能。部分部署的解決方案會耗用持續維護,但不會提供比例值,且授權利用率與功能採用監視會顯示要進一步投資或淘汰以重新導向產能的功能。

全方位成本可視性需要同時歸屬直接條列項目和這些間接項目,因為只有完整的全貌才能支援明確的投資決策。

請先為基準和最佳化的結構替代項目建立 TCO 模型,再認可方法。使用已記錄的假設預測 3-5 年成本的模型可讓您系統比較選項。對最重要的假設執行敏感性分析,以決定成本估計值的差異與邊界。計畫在條件變更時重新造訪決策。將假設寫下來是值的一部分,因為這會讓後續重新評估成為以證據為基礎的比較,而不是新的引數。

使用全方位 TCO 比較來評估對照自訂開發的商業可用解決方案,而不僅僅是初始成本。建立與購買決策會透過持續訂閱費用或持續維護義務,塑造長期投資,而這兩個路徑會帶來基本不同的投資設定檔。

AgentExchange (先前稱為 AppExchange) 是來自 Salesforce ISV 社群的現成解決方案領導來源。其投資設定檔偏好速度與共用維護。部署以週為單位,而非以相似自訂組建所需的月為單位進行測量。廠商可維護功能,包括平台版本相容性,而無需客戶努力。功能由現有客戶基礎所證明,進而降低實作風險。專門功能可受益於廠商領域專業知識和高於單一公司自己資金的研究投資。支援可用性會因 ISV 而有所不同,通常會針對問題定義升級路徑,且會對模型帶來持續訂閱成本。

自訂開發有助於調整和控制。其可精確符合獨特的組織需求,而不影響一般解決方案模式、提供功能和藍圖優先順序的完整控制權、無需超出基本平台授權的持續訂閱,並可透過使用相同現成解決方案的競爭者無法使用的功能來建立競爭優勢。權衡是公司負責維護和讓解決方案與每個 Salesforce 版本相容。

長期 TCO 比較可將這些設定檔轉為決策。現成的解決方案會帶來複雜的年度訂閱費用,但包含廠商提供的維護、增強功能和相容性更新。自訂解決方案需要一次性開發投資,但必須承擔持續維護成本,並負責版本相容性。預測兩者的 3–5 年總計,以便比較反映完整的投資而非初始費用,這通常優先於第一天看起來較便宜的選項。

除了原始成本之外,有四個因素會決定建立與購買的決定。

  • 策略性差異化可決定某個功能是值得建立的競爭優勢還是購買較佳的商品。
  • 當立即需要功能來抓住機會或回應競爭壓力時,由於大量自訂功能需要數月的時間,因此「時間轉換值」會優先購買。
  • 組織功能僅優先建立可持續維護和發展解決方案之能力的內部小組,且缺勤時購買。
  • 結束成本優先於保留彈性的選項,因為透過專屬格式或廣泛自訂建立深入鎖定的解決方案會在需求變更時造成風險。

系統化決策,使其以一致的評估為基礎,而非臨時判斷。

授權與耗用是每成本值方程式的輸入,就像運算與儲存一樣,也是最常見的廢棄物來源。最佳化它們並不需要直接減少。這是將每個使用者與其工作的正確授權進行比對,並有效地叫用每個計量服務。

授權最佳化會將每個使用者與正確的授權類型進行比對。其核心是將公司中的每位使用者與其工作所需的授權進行比對。過度授權 (例如將完整平台授權指派給僅需要有限功能的使用者 (唯讀存取權或簡單的工作流程批准) 是公司最常見且昂貴的錯誤之一,在有人查看之前就不會顯示。定期稽核使用者角色、登入活動和功能用量,可透過在整個使用者群組中將指派縮小為權限,進而大幅節省成本。請依步調執行,而不只是在續約時執行—不相符項目會隨著角色變更和人員變更公司職位而靜態增加。

由於公司採用 Agentforce、Data 360 和其他 AI 技術支援的功能,這些功能會依使用情況而非依位置定價,因此耗用信用最佳化變得越來越重要。當小組設計其流程的效率不高或未監視其使用模式時,信用額度集區可能會意外快速地耗用。不同於固定授權計數,耗用情況在未做出任何佈建決策的情況下會激增。建立對信用額度耗用率的清楚可視性、設定觸發檢閱的耗用值,以及設計自動化和工作人員,以有效率地叫用計量服務。保持交易在管理員限制內的效率工作會使計量服務在其信用預算內保持。這是相同的成本價值計畫,以耗用量表示。

環境與 Sandbox 策略是一種具有直接成本影響的資源決策,而成熟的 Salesforce 傳送模型需要結構良好的環境策略。開發、測試、暫存和生產環境每個都提供不同的用途,而正確的 Sandbox 類型混合可讓小組在到達生產環境前安全地建立和驗證變更。挑戰在於,如果沒有刻意管理,則啟用中的 Sandbox 數量會快速擴充,特別是在大型或長時間執行中的程式上,並以讓公司保持警惕的方式提高成本。補救措施是使用與任何其他資源相同的意圖來處理 Sandbox 佈建。重新整理或取消佈建不再主動使用的 Sandbox,而不是將其留在閒置狀態,讓 Sandbox 類型的選擇由實際的資料忠誠度需求所驅動,而非便利性,並設定擁有權、重新整理步調和停用的明確原則,讓財產保持與工作相容的大小。

多組織結構會乘以成本。單一組織結構可從合併授權、共用平台基礎結構和減少的管理負擔中獲益,因為管理、設定和維護的次數很少。當所有業務單位都在一個組織內運作時,整合是內部而非跨組織,資料共用是原生,而 Sandbox、支援和管治工具的總足跡會保持比例較小。多組織結構雖然有時對於地理位置、法規合規性或組織分隔而言是必要的,但會對某些成本種類產生乘數效果。每個額外的組織都會帶來自己的授權需求、自己的 Sandbox 財產、自己的整合負擔和自己的管理工作,而且需要更複雜的工具來管理跨組織部署、身分識別聯邦和資料同步。在做出難以反轉且昂貴的結構決策之前,請先瞭解每個額外組織的真實總擁有成本。

API 和整合成本是 Salesforce 生態系統中最低估的成本驅動因素之一。將 Salesforce 連線至外部系統看起來很簡單,但複雜的整合需求會快速累積中介軟體授權、開發工作、持續維護,以及來自每個資料交換的 API 耗用。具有許多整合系統、大量資料或近乎即時同步化需求的公司特別容易受到影響。此處的結構方法十分重要。比起設計良好的大量或以事件為導向的模式,讓頻繁進行小型 API 呼叫的細微整合更為昂貴且更脆弱,進而將來回行程降到最低,而連線應用程式的差異會複雜。管理整合設計標準、盡可能合併整合平台,並定期檢閱現有整合是否仍與原始設計相同地有效運作。

永續結構需要比初始設計最佳化更多。這需要持續監督和結構化責任。成本監視與管治是將最佳化從一次性演練轉為持續作業作法的架構。一致的追蹤和清楚的擁有權會減少意外成本超額的風險,讓每筆支出的美元都符合業務價值。

透過可供技術小組和業務專案關係人存取的顯示面板,建立支出模式的可視性,讓投資對話以資料為基礎,而非發票為基礎。成本可視性會開始關於投資優先順序和最佳化機會的資料驅動對話,且當有三個不同的檢視可用時,效果最佳。授權利用率顯示面板會顯示未啟用的使用者、過度授權的使用者,以及授權類型的不相符項目,這是隱藏在固定人數內的最佳化機會。容量顯示面板會顯示具有成長趨勢的儲存、API 和處理耗用,讓小組在限制造成中斷之前 (而不是之後) 最佳化。投資顯示面板會依業務單位顯示費用、擁有小組的環境成本、對其利用率的附加成本,以及以目前成長為基礎的預測支出,這會將預算對話轉為配置對話。

這些顯示面板可以來自各種工具,包括查詢中繼資料的 Digital Wallet 和自訂報告。此工具與呈現決策所在資料的規則相比,較不重要。與業務專案關係人和領導階層共用顯示面板,為明智的投資討論建立透明度,而非反應性預算討論。檢視利用率模式的財務小組可以最佳化支出。僅看見發票總計的小組只能將其減去。

在整個公司實作費用認知,包括在您超過限制前標記最佳化的主動警示:

  • 授權預算會在接近容量時,透過警示設定各部門的配置目標,因此不會僅在續約時發現未受控制的佈建。
  • 當趨勢預測超過下一個續約週期之前的限制時,儲存預算會使用警示來監視成長率。這些警示會提供預先警告,以便在發生超額之前實作封存。
  • API 預算會根據限制追蹤耗用情況,且在範例利用率值 (例如 70% 和 85%) 的警示中,因此最佳化是在限制造成失敗後主動進行,而非緊急回應。
  • Sandbox 預算透過配置限制和批准流程控制環境擴充。

預算控制會建立成本認知,而不會封鎖必要的投資。警示值會提供早期警告,以啟用謹慎的最佳化,而非反應性打亂。

成本分配會在整個業務單位之間建立問責和明智的決策,而公司會透過兩個模型之一來實作,這些模型在其強制執行問責程度上有所不同。依業務單位顯示報告成本,而不套用實際財務費用。它會建立透明度,並促進感知成本的討論和最佳化優先順序,而不會爭用內部帳單,這適合偏好協同合作成本管理而非財務責任的公司。Chargeback 會將實際成本分配給業務單位,並為耗用決策建立直接財務責任。這可促進更強大的最佳化行為,因為成本會直接影響部門預算,但需要準確的配置方法,以避免有關誰為何付款的爭議。無論如何,配置規則都遵循相同的邏輯:依使用者部門的授權成本、擁有開發小組的環境成本、耗用整合的業務流程的整合成本,以及資助工作的倡議的開發成本。缺少這些規則時,所有成本都會落在中央 IT 預算中,而業務專案關係人會將平台視為免費,這正是產生無成本感知要求的條件。

將雲端 FinOps 作法調整至 Salesforce Platform Economics,以建立連續最佳化功能,而非定期清理。五個作法承載重量。

  • 財務、結構和業務專案關係人的跨功能協同合作可確保成本決策與支出同時加權業務價值。其將財務專業知識帶入結構討論,並將技術知識帶入預算規劃。
  • 持續最佳化步調可防止成本在定期檢閱週期中漂移:每月異常檢閱可抓住支出高峰、每季利用率稽核可驗證授權指派與產能用量,以及年度全面 TCO 評估可使支出與策略優先順序保持一致。
  • 資料驅動的投資決策會使用利用率資料和 TCO 模型,而非假設或歷程記錄習慣。這些決策會以目前支出是否提供最佳價值的分析取代「我們一律這麼做」。
  • 成本監視的自動化可減少手動追蹤利用率、識別最佳化機會和產生報告的精力,因此此實作會以組織複雜度擴展,而不會導致線性人數成長。
  • 成本認知教育可協助小組瞭解結構決策如何影響擁有總成本,因為瞭解成本的結構設計師會設計更好的權衡,而瞭解平台經濟的開發人員會撰寫更有效率的自動化。

將成本感知整合到結構審查流程中,以便在部署後發現投資影響,而非在功能和技術考量事項旁邊看到。在文件主要設計選擇的結構決策記錄中包含成本影響評估。針對超過定義的投資值的解決方案,要求 TCO 預測。評估設計期間的授權影響,判斷方法在認可前是否需要頂級授權或附加元件。在採用影響 API 耗用或中介軟體授權的模式之前,請先評估整合成本。架構檢閱板搭配功能與非功能需求搭配成本觀點,可產生更一致的投資決策。將成本視為結構決策的一項投入,而非唯一的驅動因素,讓公司可以適當地投資重要的項目,同時避免浪費不重要的項目。

雲端運算永續性著重於透過有效率的資源使用來將數位基礎架構對環境的影響降到最低,並自然地與每個成本的價值保持一致:降低資源消耗的相同效率也會降低成本。Salesforce 和結構設計師負責永續性成果。Salesforce 管理資料中心基礎結構,包括電力使用效率最佳化、冷卻效率和硬體生命週期管理,以及多租戶資源集區和平台層級效率改善。您會影響該多重租戶環境中解決方案的資源消耗模式。

個別解決方案與資料中心排放之間的關係是間接的,且具精確性很重要。單一租戶的最佳化不會直接減少資料中心的排放量。這些動作會影響彙總效果:所有租戶的效率提升可讓 Salesforce 以更高的利用率運作其基礎結構,並延後產能擴充。因此,資源效率度量 (包括 SOQL 查詢、CPU 時間、堆疊耗用和儲存空間) 可作為永續性的 Proxy 指標。去除計算廢棄物可改善效能與成本,並為整個平台的效率目標做出貢獻。此支柱中的設計原則,包括大量處理、選擇性查詢、快取、非同步處理和嚴謹的資料生命週期,可建立耗用較少資源的解決方案。永續性並非專屬於結構的計畫。當您根據環境影響來衡量資源效率,而不是僅根據財務成本來衡量資源效率時,這就是資源效率的樣子。

多種建築作法帶來大部分的永續性價值,且每種都會改善效能或成本,這就是為什麼它們屬於同一個支柱。

未啟用的自動化會耗用基礎結構資源,而不會提供任何業務價值。處理不相關記錄的工作流程、不必要執行的工作流程,以及在沒有工作時執行的排程工作,都會產生廢棄的計算、儲存和能源。此修復措施是每季自動化稽核,其中包含明確的條件,用於說明未使用的項目:過去 90 天內沒有執行、持續處理零記錄的批次工作,以及由較新實作取代的自動化,但從未停用。記錄每次停用,以便在業務需求出現時回復。擁有來自先前實作剩餘的數十個流程產生器 (大多數在去年沒有執行) 的公司,會付費評估每個相關記錄儲存的每個流程產生器。

在離峰時段排程資源密集型作業,會在整個時段散佈負載。在多租戶環境中,此學科可改善營業時間的平台回應能力,並在整體租戶之間,讓 Salesforce 以更高的平均利用率營運基礎結構。為低使用量視窗排程批次歸檔、增強和清理、暫停工作,而非在午夜啟動 20 個工作並導致處理高峰,並且偏好以事件為導向的模式,而非排程輪詢,如此一來,不會花數週期檢查沒有的工作。

計算相同值會重複浪費 CPU 週期和基礎結構容量。計算一次,快取結果,然後在交易和使用者之間重複使用結果。「平台快取」會提供重複查詢的參考資料、快取累計值會避免近乎即時準確度足夠的即時彙總查詢、公式欄位會在記錄存取時動態重新計算,而非儲存值並需要自動化來維護值,Lightning Data Service 會去除用戶端上的冗餘伺服器要求。每個避免的計算皆為傳回至平台的容量。

資料儲存空間會耗用基礎結構資源,並隨著成長降低查詢效能。歸檔或刪除已啟用作業不再需要之資料的保留原則會使啟用中表格保持小,並快速查詢。將舊記錄歸檔至已排程工作的「大型物件」或外部儲存空間、在符合時實刪除,而非依賴持續耗用儲存空間的虛刪除,並設定每個欄位的「欄位稽核追蹤」保留,而非套用儲存超過合規性所需更多歷程記錄的上限。與排程處理一樣,個別歸檔決策不會直接減少資料中心的能源使用,但所有租戶之間彙總資料生命週期規範會改善平台效率,並延後儲存基礎結構的擴充。

外部整合會耗用 Salesforce 和其連線的系統中的資源。Change 資料擷取 和其他以事件為導向的模式會消除重複檢查變更並找不到變更的輪詢呼叫,進而減少 API 耗用、優先於管理員限制,並移除浪費的計算。複合 API 模式可將多個作業彙總到單一呼叫中,「大量 API v2」可比數千個個別 REST 呼叫更有效率地處理大量作業,並使用指數反向的重試邏輯避免對困難的外部系統產生麻煩。單一整合會每五分鐘輪詢一次,且在大多數時間中找不到任何可執行的項目,而由變更事件驅動的相同整合只會處理實際的變更。

工作人員結構會透過大型語言模型推斷來耗用運算資源,且會套用相同的效率心態。將提示長度最小化、摘要交談歷程記錄,而非帶有無限成長的完整文字記錄、使用最小的模型,而非預設為最有能力的模型,以及快取參考資料和決定性回應。當只有 5 個評估的費用評估結果產生 50 個向量搜尋結果時,系統會推斷費用,且沒有任何新增值,因此請設定取用限制以符合實際使用量。

如同此支柱的其餘部分,永續性需要持續監視,而非一次性通過,因為資源消耗模式會隨著解決方案的演變、資料量增加和使用者族群的擴大而改變。只有在監視觸發動作時,監視才會重要。針對每個度量定義可採取動作的值—超過每個交易目標的 SOQL 查詢計數、超過每月百分比的儲存空間成長,或低於目標的快取達成率,並記錄要先執行的最佳化。將精力專注於大量交易和經常執行的自動化,其中效率改善的彙總影響最大。流程產生器於 2025 年 12 月 31 日達到支援結束 將剩餘的流程產生器移轉至流程,而不只是停用流程產生器。

使用此檢查清單可評估解決方案是否傳回每個成本的最大值。它將此支柱的資源效率與成本規範作法結合到一個檢閱中,因為這兩者都是單一決策。

值和成本建模

  • 將每個重要的 Salesforce 投資連線至可測量的業務成果。
  • 在認可方法之前,模型化直接、間接、一次性和進行中種類的擁有總成本。
  • 比較 3–5 年範圍內基準與最佳化結構替代項目的 TCO。
  • 套用一致的建立對買評估,其會將策略差異、時間對價值和結束成本加權,而非依賴臨時判斷。

資源效率

  • 設計交易以在最高負載和資料量上限的管理員限制內舒適地作業。
  • 請先針對索引欄位選取查詢,並使用查詢計畫工具進行驗證,再針對大型物件部署。
  • 大量處理所有資料作業,並在同步限制需要時刻意選擇非同步處理。
  • 透過平台快取和 Lightning Data Service 快取參照資料,以避免重複查詢和重新計算。
  • 透過分配載入和監視大量物件來防止資料誤差。
  • 集中觸發、服務和選取器邏輯,讓業務邏輯保持可測試且變更便宜。
  • 定義完整的資料生命週期,從建立到歸檔,並在物件層級監視儲存空間耗用。

授權與耗用量

  • 將每個使用者與其工作所需的授權類型進行比對,並定期稽核角色、登入活動和功能用量。
  • 建立對耗用信用耗用率的可視性,並設計自動化,並讓工作人員有效率地叫用計量服務。
  • 使用明確的擁有權、重新整理步調和停用原則來管理 Sandbox 佈建。
  • 在新增組織前,請先瞭解完整的多組織成本乘數,並且偏好大量或以事件為導向的整合,而非聊天模式。

監視與管治

  • 提供可供技術小組和業務專案關係人存取的成本和容量顯示面板。
  • 設定授權、儲存空間、API 耗用量和 Sandbox 的預算警示,讓最佳化為主動,而非反應性。
  • 建立顯示或傳回,以便成本分配建立跨業務單位的責任。
  • 採用 FinOps 步調:每月異常審查、每季利用率稽核和年度 TCO 全方位評估。
  • 將成本影響評估整合至結構評論和結構決策記錄。

持續最佳化與永續性

  • 將最佳化視為持續作法,並驗證先前的最佳化投資是否提供預期的報酬率。
  • 透過定期稽核去除未使用的自動化和冗餘計算。
  • 追蹤隨時間的資源消耗,並定義可採取動作時,當度量超過這些值時,會觸發最佳化。

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