资源和成本优化

资源和成本优化

资源优化和成本优化共同为贵公司实现最大成本价值。Salesforce 管理多租户基础设施，强制执行调控器限制，以保持平台对每个租户公平，并通过许可证和消费信用为访问权限定价。您优化的是您获得的价值：每支出一美元和每单位平台容量返回多少业务成果。资源优化是一种机制：它有效地利用您已经支付的东西。成本优化是结果：它有意将支出导向推动竞争优势的因素。此支柱将它们视为一个决策，因为它们是同一目标的两个视图。

此成本价值视图塑造了您的每个架构决策。当您了解总拥有成本时，您会在能力和投资之间做出更好的权衡。您可以调整解决方案的大小，以满足业务需求，而不是过度配置未使用的功能或对加速价值交付的功能投资不足。许可证、消耗信用、API 调用和 Sandbox 环境都是相同等式的输入。重要的是每个返回的值，而不是登录哪个分类帐。问题从来不是“这是成本还是资源”，而是“这种投入是否有适当的回报？”

忽视这一支柱会产生可预测的后果。公司累积未使用的许可证会消耗预算，而其他功能仍没有资金。低效架构将 API 容量、存储和开发精力浪费在更好的设计可以防止的问题上。随着时间的推移，资源的低效率以可预测的方式特别复杂：

  • 随着数据量的增长，性能会下降。
  • 当非选择性查询扫描整个表时，几十万个记录会出现查询超时。
  • 当解决方案检索不必要的字段时，会出现堆限制异常。
  • 当复杂计算同步运行时，会出现 CPU 超时。
  • 当团队围绕每个新限制修补时，解决方法成倍增加。

这些故障中的每一个都是可靠性问题和成本问题，因为浪费的计算会消耗您为此付出的容量。最重要的是，团队错过了投资创新的机会，因为预算和工程能力被浪费而不是被战略举措消耗。

经济高效的解决方案通过以下方式实现价值最大化：

  • 使用已购买的平台功能
  • 使适当规模的许可和消费与实际使用保持一致
  • 在承诺采用方法之前，对完整成本进行建模
  • 根据业务结果持续监控支出

这些实践更加复杂。将成本意识和资源效率融入设计的团队比在支出已经增长后将优化视为清理工作的团队提供更高的每美元能力。

资源和成本优化直接连接到其他架构支柱。卓越运营通过减少手动操作的自动化降低了持续成本。可靠性和信任通过业务连续性保证和监管合规价值证明了优质投资的合理性。这些支柱共同帮助公司自信地投资，因为它们的架构提供了最大的回报。

使用这些原则来指导您在平台上进行资源和成本优化的架构决策。

  • **针对总拥有成本进行优化。**总拥有成本 (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 容量中返回更多业务价值，这是保持成本优化可持续性的机制，而不是一次性削减预算。相比之下，浪费的计算消耗了基础设施资源，而没有提供业务价值及其成本复合。随着数据量的增长，性能会可预测的下降，而随着团队在他们本可以设计的限制周围修补，解决方法会成倍增加。

您的优化责任跨越四个相互关联的领域：性能、代码组织、打包和数据。在成为技术性决策之前，每项决策都是按成本计算的价值决策。本节解释了如何做出这一决定，以及它为何如此重要。本节中引用的精确实施模式、代码级模板、设置导航和特定调整阈值位于资源和成本优化模式库中。

性能优化从您看待调控器限制的方式的转变开始。它们不是工作的障碍。它们是架构约束，当从初始设计开始，它们会产生具有可预测的性能特征的解决方案。每个事务都在固定边界内执行，这些边界的存在是为了在平台上的每个租户之间强制实施公平的资源共享。Apex 事务消耗其 100 个允许的 SOQL 查询中的 95 个查询，这不会为未来的功能、其他团队添加的触发器或意外的数据模式留下任何余地。将事务保持在远低于限制一半的架构师构建的解决方案，可以在限制用尽时在不紧急重构的情况下增长。纪律是，在峰值负载和最大数据量下，在限制范围内很好地设计，这样添加功能或其他软件包的自动化就不会将事务推到边缘。常见且代价高昂的失败：该解决方案完美适用于 Developer Sandbox 中的 10 个记录，但在生产中达到了调控器限制。Developer Sandbox 仅复制配置，不包含数据。针对完全复制 Sandbox 中的实际卷进行测试会在客户之前暴露出可扩展性问题。

查询选择性是决定解决方案是扩展到数百万条记录还是超时数十万条的最大杠杆。选择性查询使用索引有效地定位记录，而非选择性查询扫描整个表，消耗过多的数据库资源，并最终超时。该平台在定义的字段集上维护标准索引，并应用选择性阈值，该阈值在对象超过其前 100 万条记录时变紧。选择性架构意味着在索引字段上作为主要条件进行筛选，并在针对大对象进行部署之前使用查询计划工具进行验证，因为显示高用量对象上的表扫描的查询是等待发生的生产事件。选择性是您不必购买的容量：高效的查询以毫秒为单位返回，并将数据库资源留给您自己的组织中的每个其他租户和所有其他事务。

批量化是区分大规模工作的 Apex 和达到限制的 Apex 的基本可扩展性模式。反模式（放在循环中的查询或 DML 语句）适用于小记录集，但在批量操作运行时违反调控器限制。补救措施是在循环外部的单个语句中查询所有需要的数据，将结果组织到 ID 键控的映射中，以便在迭代期间快速查找，并使用批处理 DML 处理整个集合。设计每个自动化，以处理标准的 200 个记录触发器批次，而不会接近限制，并且无论生产中的负载如何，相同的代码都会按比例变化。

对于不能或不应在用户事务的同步限制内完成的工作，存在异步处理。将该工作移动到异步上下文中大约会将其可用的调控器限制增加一倍，并防止长时间运行的操作阻止用户。这个空间是真实的，但它不是免费的，每当一个限制感觉接近时就达到异步是错误的。异步是一种有意的架构权衡：它引入了最终的一致性，因此工作的结果在请求它的事务中不可见，这迫使用户体验做出不依赖于即时确认的决策。它需要明确的错误处理和监控，因为故障出现在作业日志中，而不是出现在触发它的用户面前。当一个业务操作跨越几个交易时，它会使系统的心理模型复杂化。按成本计算的价值决策是权衡工作真正需要的容量和增加的复杂性，并在工作适合时保持同步。

当异步是正确的调用时，机制之间的选择遵循工作的形状，而不是限制的大小。批次 Apex 适用于数量。它通过将数百万条记录分成块来处理它们，每条都有其自己的独立调控器限制 — 这就是为什么数据迁移、数据归档和批量丰富属于这里的原因。可排队适用于顺序：它处理超出同步限制但不需要批量规模的多步骤工作流，并且它支持将一个作业与另一个作业链接起来，以处理必须按顺序运行的步骤。平台事件用于解耦：生产者在不了解或等待消费者的情况下发布事件。将此模式用于跨系统通知和分离不属于同一事务的工作，并考虑至少一次交付需要幂等订阅者。未来的方法涵盖了简单异步工作与原始输入的狭隘情况，最常见的是从同步触发器调出。它们无法链接或接受复杂对象，这正是它们不是通用异步工作的工具的原因。将异步机制与工作的形状相匹配。否则，您可以用调控器限制问题来换取一致性和监控成本，而成本大于收益。

缓存会将重复的工作转换为您保留的工作量。平台缓存存储跨事务边界的可序列化数据，因此缓存命中可以避免重新执行产生值的查询或重新计算，直接降低 SOQL 和 CPU 消耗。决定缓存的创建或中断取决于您选择放入缓存的内容和持续时间。缓存读取频率远远超过更改频率的数据，例如自定义元数据、配置和选项列表值，并将生存时间设置为与数据的波动性相匹配，而不是单一的默认值。每月更改的参考数据可以安全地缓存数小时，而一天轮班的配置需要很短的窗口，因此缓存不会提供足够长的过时值。过于激进的缓存以性能为代价来换取正确性风险，而命中率低的缓存消耗存储空间而不返回容量，这就是为什么命中率是需要监控的指标，而不是假设的设置。分区选择是一项安全决策：将组织分区用于跨用户共享的数据，将会话分区用于必须保持隔离的用户范围数据，并且永远不要将个人身份信息放在每个用户都可以读取的组织分区中。Lightning 数据服务将相同的理念扩展到客户端:它在页面上的每个组件之间共享缓存的记录，并消除了冗余的服务器往返。每个缓存命中都是计算和 API 容量，您无需花费，只要它返回的值仍然正确。

数据偏差是记录分配不平衡造成的性能热点。当单个父级记录累积超过 10,000 个子级时，查询性能会下降，并在并发操作期间出现行锁定冲突。阈值是设计信号，不是硬限制。它告诉您在多个父级之间分配负载，使用在任何父级接近边界时提醒的计划作业监控高用量对象，并按父级 ID 对批量负载进行排序，这样并发批次就不会为相同的行而争抢。所有权倾斜，集成用户拥有成千上万条记录，这会产生相同的锁定冲突，应该得到相同的负载分配。

Salesforce 提供工具，以在解决方案发展的过程中保持性能特征的健康。规模中心为长时间运行的操作、行锁定竞争和接近限制的事务提供事务级可见性，然后命名所涉及的特定触发器和对象。ApexGuru 将 AI 分析应用于生产运行时间遥测，以在达到规模之前显示反模式，Salesforce Code Analytics 在 CI/CD 漏斗中执行静态分析，因此当查询出现在循环中或检测到其他性能缺陷时，构建会失败。Event Monitoring 揭示了一段时间内的消费趋势，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 预算通过分配限制和审批流程控制环境的扩散。

预算控制在不阻止必要投资的情况下培养成本意识。警报阈值提供预警，可实现周到的优化，而不是反应性扰乱。

成本分配在业务部门之间创建了问责制和明智的决策，公司通过两种不同的模式之一来实施它，这两种模式在问责程度上有所不同。在不应用实际财务费用的情况下，按业务部门显示报表成本。它创建了透明度，并促进了成本意识的讨论和优化优先级，而没有内部计费的争议，这适合更喜欢协作成本管理而不是财务问责制的公司。按存储容量使用计费将实际成本分配给业务部门，并为消费决策建立直接的财务问责制。它推动了更强的优化行为，因为成本直接影响部门预算，但它需要一种准确的分配方法，以防止关于谁为什么付费的争议。无论哪种方式，分配规则都遵循相同的逻辑：按用户部门划分的许可证成本，按拥有开发团队划分的环境成本，按消耗集成的业务流程划分的集成成本，以及按为工作提供资金的倡议划分的开发成本。当这些规则不存在时，每个成本都会落在中央 IT 预算中，业务利益相关者会将平台视为免费，这正是在没有成本意识的情况下产生请求的条件。

使云 FinOps 实践适应 Salesforce Platform Economics，以创建持续优化功能，而不是定期清理。五种实践具有影响力。

  • 财务、架构和业务利益相关者之间的跨职能协作可确保成本决策权衡业务价值和支出。它将财务专业知识引入架构讨论，并将技术理解引入预算规划。
  • 持续的优化节奏防止了定期审查周期的成本偏差：每月一次的异常审查，发现支出高峰；每季度一次的利用率审计，验证许可证分配和容量使用情况；以及每年一次的全面 TCO 评估，使支出与战略优先级保持一致。
  • 数据驱动的投资决策使用利用率数据和 TCO 模型，而不是假设或历史习惯。这些决策用对当前支出是否提供最佳价值的分析取代了“我们一直这样做”。
  • 成本监控的自动化减少了跟踪利用率、确定优化业务机会和生成报表的手动工作，因此实践会随着组织复杂性的增长而扩展，而不会实现人员线性增长。
  • 成本意识教育帮助团队了解架构决策如何影响总拥有成本，因为了解成本的架构师和了解平台经济学的开发人员可以更好地权衡利弊。

将成本意识集成到架构审查过程中，以便投资影响与功能和技术注意事项一起可见，而不是在部署后发现。在架构决策记录中包含成本影响评估，记录主要设计选择。对于超过定义投资阈值的解决方案，需要 TCO 预测。在设计期间评估许可证的含义，确定一种方法在承诺之前是否需要高级许可证或加载项。在采用影响 API 消耗或中间件许可的模式之前，请评估集成成本。架构审查委员会将成本视角与功能和非功能需求联系起来，做出更一致的投资决策。将成本视为架构决策的一个输入，而不是其唯一的驱动因素，这样公司就可以在重要的事情上进行适当的投资，同时避免在无关紧要的事情上浪费。

云计算可持续性的重点是通过有效利用资源来最大限度地减少数字基础设施对环境的影响，并且与每成本的价值自然保持一致：降低资源消耗的效率也降低了成本。Salesforce 和架构师共同负责可持续发展结果。Salesforce 管理数据中心基础设施，包括电力使用效率优化、冷却效率和硬件生命周期管理，以及多租户资源池和平台级效率改进。您会在该多租户环境中影响解决方案的资源消耗模式。

单个解决方案与数据中心排放之间的关系是间接的，准确无误非常重要。单个租户的优化不会直接减少数据中心的排放。他们所做的是促成聚合效应：所有租户的效率提高让 Salesforce 以更高的利用率运行其基础设施，并推迟容量扩展。因此，资源效率度量，包括 SOQL 查询、CPU 时间、堆消耗和存储，是可持续性的代理指标。消除计算浪费可以提高性能和成本，并有助于实现平台范围的效率目标。该支柱中的设计原则，包括批量化、选择性查询、缓存、异步处理和严格的数据生命周期，创建了消耗更少资源的解决方案。可持续性不是一项单独的计划，而是固定于架构之上。当根据环境影响而不是财务成本来衡量资源效率时，这就是资源效率。

一些架构实践承载了大部分可持续性价值，并且每个实践还提高了性能或成本，这就是为什么它们属于同一个支柱。

非活动自动化会消耗基础设施资源，而不会提供任何业务价值。处理不相关记录的触发器、执行不必要操作的工作流和在不存在工作时运行的预定作业会浪费计算、存储和能源。补救措施是每季度进行一次自动化审计，对哪些内容被视为未使用有明确的标准：过去 90 天内没有执行，批处理作业始终处理零条记录，自动化被更新的实施取代，但从未停用。记录每次停用，以便在业务需求重新出现时回滚。一家公司有几十个以前实施留下来的进程构建器，大多数在过去一年中没有执行过，它付费评估每个相关的记录保存。

在非高峰时段计划资源密集型操作会在时间窗口之间分配负载。在多租户环境中，这一纪律提高了平台在工作时间的响应能力，并且总的来说，让 Salesforce 以更高的平均利用率运行基础设施。为低用量窗口计划批量归档、丰富和清理，错开作业，而不是在午夜启动 20 个并造成处理高峰，并且更喜欢事件驱动的模式，而不是计划的轮询，这样就不会花费周期来检查不存在的工作。

重复计算相同值会浪费 CPU 周期和基础设施容量。计算一次，缓存结果，并在事务和用户之间重复使用。平台缓存为重复查询的参考数据提供服务，缓存的累计值避免了近乎实时准确性的实时聚合查询，公式字段在记录访问时动态重新计算，而不是存储值并需要自动化来维护它，Lightning 数据服务消除了客户端上的冗余服务器请求。每个避免的计算都是返回到平台的容量。

数据存储会消耗基础设施资源，并随着增长降低查询性能。归档或删除活动操作不再需要的数据的保留策略保持活动表较小，查询速度更快。将陈旧记录归档到计划作业中的大对象或外部存储，在合规时硬删除，而不是依赖继续消耗存储空间的软删除，并配置每个字段的字段审计跟踪保留，而不是应用存储远远超过合规要求的历史的最大值。与计划处理一样,单个归档决策不会直接减少数据中心的能源使用,但聚合所有租户的数据生命周期纪律可以提高平台效率并推迟存储基础架构的扩展。

外部集成会消耗 Salesforce 及其连接的系统中的资源。变更数据捕获和其他事件驱动的模式消除了重复检查变更而一无所获的轮询调用，从而减少了 API 消耗、好处调控器限制并消除了浪费的计算。复合 API 模式将多个操作聚合到单个调用中，批量 API v2 处理大量操作的效率远远高于数千个单独的 REST 调用，并且带有指数回退的重试逻辑避免了使外部系统举步维艰。每五分钟轮询一次并且大部分时间里什么也没做的一个集成纯粹是浪费，而由变更事件驱动的同一个集成只处理真正的变更。

客服人员架构通过大型语言模型推理来消耗计算资源，并且相同的效率思维也适用。最小化提示长度，总结对话历史，而不是携带无限增长的完整逐字记录，使用适合任务的最小模型，而不是默认设置为最有能力的模型，并缓存参考数据和确定性响应。在仅评估 5 个矢量搜索结果时检索 50 个矢量搜索结果会消耗推理和检索资源，并且没有增加值，因此配置检索限制以匹配实际使用。

可持续性与该支柱的其余部分一样，需要持续监控，而不是一次性的，因为资源消耗模式会随着解决方案的发展、数据量的增长和用户数量的增加而变化。只有在触发操作时，监控才重要。为每个度量定义可操作的阈值（每个事务超过目标的 SOQL 查询计数、超过每月百分比的存储增长或低于目标的缓存命中率），并记录首先进行哪些优化。将精力集中在高用量事务和频繁执行的自动化上，在这些方面，效率的提高会产生最大的聚合影响。进程构建器于 2025 年 12 月 31 日结束支持，将剩余进程构建器迁移到流；不要只是停用它们。

使用此核对清单来评估解决方案是否返回每个成本的最大值。它将该支柱的资源效率和成本纪律做法合并为一项审查，因为这两项是单一决定。

价值和成本建模

  • 将每项重要的 Salesforce 投资与可衡量的业务成果联系起来。
  • 在承诺采用方法之前，请对直接、间接、一次性和持续类别的总拥有成本进行建模。
  • 比较基准和优化架构备选方案在 3-5 年内的总拥有成本。
  • 应用一致的构建与购买评估，权衡战略差异化、价值实现时间和退出成本，而不是依赖临时判断。

资源效率

  • 将事务设计为在峰值负载和最大数据量下的调控器限制内舒适运行。
  • 在针对大型对象部署前，使查询对索引字段具有选择性，并使用查询计划工具进行验证。
  • 批量化所有数据操作，并在同步限制需要时有意选择异步处理。
  • 通过平台缓存和 Lightning 数据服务缓存参考数据，以避免重复查询和重新计算。
  • 通过分配负载和监控高用量对象来防止数据偏差。
  • 集中触发器、服务和选择器逻辑，以便业务逻辑保持可测试和更改成本低廉。
  • 定义从创建到归档的完整数据生命周期，并在对象级别监控存储消耗。

许可和消费

  • 将每个用户与工作所需的许可证类型匹配，并定期审核角色、登录活动和功能使用情况。
  • 建立对消耗信用烧毁率的可见性，并设计自动化和客服人员来高效调用计量服务。
  • 通过明确的所有权、刷新节奏和停用策略，管理 Sandbox 配置。
  • 在添加组织之前，了解完整的多组织成本乘数，并青睐批量或事件驱动的集成，而不是聊天模式。

监控和治理

  • 提供可供技术团队和业务利益相关者访问的成本和容量仪表板。
  • 为许可证、存储、API 消耗和 Sandbox 设置预算提醒，以便优化是主动的，而不是被动的。
  • 建立展示或按存储容量使用计费，以便成本分配在业务部门之间形成问责制。
  • 采用 FinOps 节奏：每月异常审查、每季度利用率审计和每年全面 TCO 评估。
  • 将成本影响评估集成到架构审查和架构决策记录中。

持续优化和可持续性

  • 将优化视为持续实践，并验证之前的优化投资是否实现了预期回报。
  • 通过定期审计，消除未使用的自动化和冗余计算。
  • 跟踪一段时间内的资源消耗，并定义可操作的阈值，当度量超过阈值时触发优化。

分享您对良好架构框架的反馈。