可靠性

Salesforce 在多个地区运营弹性基础设施，具有自动故障切换和基础设施级弹性。该平台处理数据中心冗余、网络可用性和基础设施修补，实时平台可用性状态在 trust.salesforce.com 上可见。

您可以设计在此基础设施上运行的一切的可靠性：在调控器限制范围内扩展的数据模型、预测故障并从故障中恢复的事务、检测解决方案何时偏离可用性目标的监控，以及在发生故障时恢复业务操作的灾难恢复程序。

Salesforce SLA 涵盖了该平台，但您拥有基础设施层以上所有内容的可靠性。您负责定义和实现自己的服务级别目标 (SLO)，即业务所需的可靠性目标。无论平台 SLA 级别如何，应用程序层的可靠性仍然是您的责任。保证可用性的相同平台也限制了可用性：调控器限制会限制每个租户的资源消耗，因此任何单个租户都不能降低其他租户的平台。因此，您的解决方案必须在这些限制内进行适度扩展，而不仅仅是请求更大的容量。

不可靠的解决方案会产生级联业务影响。当商业平台不可用时，收入流会变慢。当内部工具在工作流中失败时，生产力会下降。当数据损坏或记录丢失时，Trust 会削弱。随着解决方法的累积和技术债务的增加，这些问题会随着时间的推移而复杂化。

可靠性不是防止所有故障。在分布式系统中出现故障。可靠性是指设计预测故障、帮助控制爆破半径和自动恢复服务的系统。可靠性要求因业务影响而异。例如，需要 99.9% 可用性的面向客户的 Experience Cloud 入口网站所涉及的架构选择与容忍偶尔延迟的内部批处理报告流程有着根本的不同。

可靠性和卓越运营是紧密关联的。两者都解决了监控、事件响应和系统可用性的问题。这种重叠是有意的，不是偶然的。区别在于设计时间与运行时间。

可靠性是在系统运行之前构建到系统的内容，包括：

• 前面提到的在调控器限制范围内扩展的数据模型
• 预测故障并从中恢复的事务
• 包含爆炸半径的冗余和断路器
• 恢复目标 - 恢复时间目标 (RTO) 和恢复点目标 (RPO) 决定了系统在出错时的行为方式。

可靠性至关重要；这是解决方案的结构属性。

卓越运营是指系统运行后如何操作、改进和维护，包括：

• 降低变更风险的部署实践
• 事件期间指导团队的 Runbook 和升级路径
• 表面信号的可观察性漏斗
• 随着时间的推移改善系统的反馈回路。

实践卓越运营；这是围绕解决方案的人力和流程纪律。

两个支柱之间的共同点是监测和观察层。监控设计为可靠性问题。您应该构建可观察的系统。它是作为卓越运营来实践的。您的团队会根据这些系统告诉您的信息采取行动。可靠性涵盖了您构建的架构模式，例如警报阈值和健康仪表板。卓越运营涵盖了团队如何响应信号，例如 Runbook 和随叫随到的响应。

请考虑以下区别：可靠性解决的是“此系统能否生存？”，而运营卓越解决的是“您的团队能否操作？”由没有运行手册、部署不一致或没有反馈环路的团队运营的完全可靠的系统在实践中仍然会失败。一个运营出色的团队管理一个脆性、设计糟糕的系统时，他们将被无法防止的事件淹没。这两个支柱都是必要的,不能取代另一个。

可靠性并非孤立操作。如前面章节所述，卓越运营是其最密切的合作伙伴。这两个支柱共享可观察性层，可靠性定义了您构建到系统中的内容，运营卓越性定义了团队的工作方式。Trust 还需要能够抵御攻击并保持数据完整性的基础设施:如果系统可能遭到破坏,它就不可靠。资源优化防止调控器限制耗尽，确保平台保持大规模的可靠性。成本优化平衡了可靠性投资及其提供的业务价值。可用性目标证明了实现这些目标所需的架构复杂性。没有一个支柱能够单独产生架构良好的解决方案 — 可靠性提供了其他支柱依赖和强化的结构基础。

使用这些原则来指导您在平台上的可靠性的架构决策。

• **通过批量化分配工作量。**在单个事务中处理多个记录，而不是依赖按顺序进行的每条记录操作。批量化在单个事务中处理的批次之间共享调控器限制，遵守这些限制，同时最大限度地提高吞吐量。基于集合的 Apex 处理、具有可配置范围的批处理作业以及批量消耗的平台事件都体现了这一原则。在顺序处理中，批量化良好的解决方案处理 200 个 SOQL 和 DML 语句数量相同的记录。分布式工作负载模式提供了弹性，因为没有单个记录故障影响整个批次的处理。
• **假设一切失败。**调控器限制、平台维护窗口和集成依赖性创建与 Salesforce 多租户架构相关的失败模式。从一开始就设计这些特定于平台的故障。SOQL 查询超出数据偏差下的行限制。Apex CPU 时间可能在复杂计算期间到期。随着外部服务变慢，可能会出现标注超时。当并发事务冲突时，DML 行锁定失败。当文件上传意外达到峰值时，存储限制可能会失败。为这些失败制定计划的架构师无需手动干预即可构建可靠的解决方案。这些可靠的系统检测接近调控器限制，通过错误处理控制爆炸半径，并通过重试框架和平台事件自动恢复。
• **构建自我恢复系统。**设计无需人工干预即可检测故障并自动恢复的解决方案。平台事件启用自定义重试模式。可以使用 EventBus.RetryableException 重试向订阅者交付，但重放原始事务需要自定义架构。流错误处理会将异常定向到恢复流。Apex 批处理作业隔离块失败 - 失败的块不会阻止其他块处理 - 启用部分作业完成和目标重试。使用 AsyncApexJob 上的错误跟踪实施显式重试逻辑，以实现暂时性故障恢复。在处理暂时性失败时，对这些重试模式应用指数回退。自助恢复系统即使在非工作时间事件（人工响应人员可能不可用）中也能保持可用性目标，从而减轻了操作负担，同时缩短了平均恢复时间。
• **首先设计业务需求。**在选择技术解决方案之前，根据实际业务影响定义服务级别目标。不是每个组件都需要五个 9 的可用性。将可靠性投资与业务关键度相匹配，并为支持功能设计合理的降级。现实的目标支持适当的架构选择，并避免过度设计或交付不足。
• **通过钻机验证恢复。**安排灾难恢复演练，以测试备份还原、故障转移程序和事件响应行动手册。从生产备份恢复完全复制 Sandbox，以验证恢复过程。在 Sandbox 环境中引入故意故障，以确认您的监控检测到问题，以及自动恢复正确执行。演练会在真实事件暴露出来之前揭示程序、工具和运行手册中的差距。记录钻取结果，并跟踪发现的缺口的补救措施。定期测试可确保恢复功能随着解决方案的发展和团队成员的变化保持最新状态。

了解 Salesforce 的操作有助于您将可靠性设计工作集中在您控制的内容上。该平台处理传统 IT 环境中需要专职团队的基础架构问题，例如：

• **多区域基础设施和故障切换：**Salesforce Hyperforce 为区域数据中心提供内部服务的自动故障切换。它还提供了区域内的多个可用性区域，以及在基础设施层的数据复制。该平台透明地处理区域内的冗余和可用性区域分配。
• **平台 SLA 承诺：**带有合同补救措施的保证可用性级别是根据每个客户商定的。 Trust.salesforce.com公布实时平台状态和正常运行时间历史,但任何具体的可用性保证及其补救措施都存在于你商定的协议中。查看您的合同和当前的 Salesforce Trust 与合规文档，了解适用于贵组织的承诺。
• **基础设施冗余：**该平台维护冗余服务器、网络路径、数据库基础设施和存储系统。基础设施级故障切换会在硬件故障期间自动发生，无需客户采取行动。平台备份可以防止基础设施级别的数据丢失。
• **平台维护和更新：**主要平台版本提供 Salesforce 管理的向后兼容性的功能和安全补丁。平台维护时段将在 trust.salesforce.com 上安排和传达。基础设施修补以透明方式发生，无需客户参与。
• **核心平台运行状况监控：**Salesforce 监控基础设施性能，包括数据库响应时间、网络延迟、API 网关运行状况和存储系统性能。平台健康状态显示在 trust.salesforce.com 上，并包括实时事件更新。特定于实例的状态可通过状态 API 获得。

这些平台操作为您构建奠定了基础。您无需管理数据中心、配置服务器或设计基础设施灾难恢复。相反，您负责在此基础之上设计和配置的内容。

共享责任模型指定您拥有使用 Salesforce 创建的一切内容的可靠性。平台可靠性支持您的工作，但不会取代它。您的可靠性责任跨越六个相互关联的领域：

服务级别目标 (SLO) 以可衡量的方式量化可靠性要求。SLO 将业务需求和技术架构联系起来。在选择技术或设计数据模型之前，请建立定义每个关键用户流成功的 SLO。

SLO 通常衡量：

• 可用性 - 系统运行和可访问的时间百分比
• Latency — 完成操作所需的时间，以百分位数 (p50、p95、p99) 衡量
• 吞吐量 - 单位时间内成功完成的操作量
• 错误率 - 失败或返回错误的请求的百分比
• 恢复时间 - 事件发生后恢复服务所需的持续时间

定义每个业务能力的 SLO，而不是每个技术组件。面向用户的功能需要比管理或批处理更严格的 SLO。每个 SLO 应使用现有仪器进行客观测量。

服务级别协议 (SLA) 是带有失败后果的合同承诺。任何保证的可用性级别及其合同补救措施都是按客户协商商定的。查看您的协议和当前的 Salesforce Trust 与合规文档，了解适用于贵组织的承诺。

解决方案 SLO 应该比平台 SLA 更严格，以保持错误预算。如果您的平台 SLA 和解决方案 SLO 的目标都是 99.9%，任何显著的平台停机都会直接消耗您的错误预算，从而在相同的测量周期内没有为应用程序层故障、集成问题或计划的维护留下缓冲空间。只有当累积停机时间耗尽测量期间的全部误差预算时，才会正式违反 SLO。如果您的 SLA 和 SLO 设置为相同的目标，一个平台事件会完全耗尽该预算。例如，当平台提供 99.9% 时，将解决方案 SLO 的目标设置为 99.5%，以便为您必须解决的问题（应用程序错误、集成失败和部署窗口）保持有意义的缓冲。

服务级别指标 (SLI) 是用于评估 SLO 实现情况的评测。SLI 必须可以客观衡量、持续收集，并与用户体验直接相关。

对于 Salesforce 解决方案，SLI 包括：

• 通过 trust.salesforce.com 的平台正常运行时间
• 通过 Experience Cloud Analytics 加载页面的时间
• 通过 Event Monitoring（需要 Event Monitoring 加载项或 Salesforce Shield）的 API 响应时间
• 通过自定义应用程序日志记录的事务成功率
• 通过 AsyncApex 作业监控完成批处理作业

更高的可用性目标导致复杂性和成本呈指数增长。在提交目标之前，了解架构含义：

避免任意的目标，例如“所有事情都用五个九”。相反，评估每个功能停机对业务的影响，并相应地设定目标。允许每月停机 7 小时的内部批处理报告需要的架构与需要子小时恢复的收入关键订单处理根本不同。

从用户角度定义可靠性，而不仅仅是从技术指标。报告 99.9% 正常运行时间但频繁超时的系统会降低基于用户体验的可靠性。用户更关心成功完成工作流，而不是个人 API 正常运行时间。

设计反映用户过程而不是个人 API 调用的 SLO。多步骤 Checkout 流要求每个步骤在可接受的时间内成功完成。衡量端到端用户流完成率，作为主要的可靠性指标。组件可用性是必要的，但不足以保证用户体验的可靠性。

Salesforce Hyperforce 提供支持地理分布的区域数据中心。该平台处理区域内的基础设施冗余，包括多个可用性区域、内部服务的自动故障切换以及基础设施层的数据复制。平台 SLA 反映了这种基础设施冗余。

对于大多数解决方案，具有平台受管冗余的单区域部署提供了足够的可用性。Trust Salesforce 基础设施的基础可用性，并将解决方案架构集中在应用程序层可靠性上，包括容错集成模式、正常降级和自动恢复。

跨可用性区域的区域内故障切换是自动的，并包含在标准平台 SLA 承诺中 — Salesforce 在基础设施层对此进行透明的管理。跨区域（区域外）灾难恢复是单独的付费产品，默认情况下不包括在任何标准版本中。如果您的业务连续性要求进行跨区域故障切换，请在灾难恢复计划中明确记录这种依赖性，以便利益相关者了解包含的平台弹性和购买的跨区域灾难恢复功能之间的区别。

多组织架构提供了最强的隔离和地理冗余，但增加了操作复杂性，包括数据同步、用户配置、部署协调和许可证成本。为业务需求明确证明复杂性的场景保留多组织模式。例如，考虑这些场景的多组织模式：

• 该业务需要超出平台功能的保证 RPO/RTO
• 监管要求要求地理数据隔离，业务连续性规划要求完全独立于单个区域
• 由于业务部门自治要求，组织整合不可行。

主动-被动模式：- 主要组织在正常条件下为所有流量提供服务。不同区域的次要组织保持同步但空闲。故障切换发生在主要区域停机期间。此解决方案提供了最简单的多组织模式，但未使用辅助容量。DNS 路由或用户身份验证层将用户定向到活动组织。

主动-主动模式：- 两个组织都持续为生产流量提供服务。用户按地理位置、业务部门或工作量类型进行分配。主动-主动最大限度地提高了容量利用率，但需要复杂的数据同步和用户路由。在两个组织中修改相同记录时，解决冲突至关重要。

设计适合 RPO 要求的数据同步。平台事件为关键数据更改提供近乎实时的事件流。变更数据捕获最少的开发为选定对象提供自动变更跟踪。通过固定间隔的批量 API 2.0 进行计划的 API 复制适合时间要求较低的参考数据。

在数据、应用程序和集成层应用冗余，以防止单点故障。分层冗余可确保任何单个层的故障不会影响整体系统可用性。

• **数据冗余：**该平台通过基础设施备份提供数据冗余。当业务需要比平台还原程序更快的恢复时，使用应用程序级复制来补充这种冗余。使用变更数据捕获或平台事件将关键数据连续复制到辅助存储或外部系统。这将支持从逻辑损坏或基础设施备份无法解决的配置错误中恢复。
• **应用程序冗余：**设计无状态应用程序逻辑，以便任何应用程序服务器都可以处理任何请求。避免阻止水平缩放的服务器端状态。使用自定义元数据类型和自定义设置进行配置，这些配置必须在所有应用程序服务器中立即可用。无状态设计使应用程序服务器能够处理请求，而不依赖于特定的服务器状态。
• **集成冗余：**设计容忍临时外部系统不可用的集成。实施断路器模式来检测失败的集成。当外部系统停机时，通过平台事件将请求排队，而不是阻止用户操作。这将外部系统故障与面向用户的功能隔离开来。

使用 trust.salesforce.com 和特定于实例的状态 API 监测 Salesforce 平台的健康。订阅实例的状态通知，以接收有关事件、维护时段和性能影响的提醒。平台运行状况信号支持主动响应，而不是被动故障排除。

设计响应平台健康状况的解决方案。当平台性能下降时，减少非关键批处理负载。使用计划的作业监控，在维护时段内延迟后台作业。禁用非必要集成，以在事件期间保护面向用户的关键操作。这种动态负载降低功能可以保持关键功能在压力下的可靠性。

使用规模中心来识别消耗不成比例的平台资源的长期事务和操作。规模中心提供事务级可见性，使架构师能够在成为面向用户的事件之前检测可靠性风险。每周规模中心审查揭示了需要架构补救的模式。

在多个级别实施故障检测，以在问题级联为完全停机之前发现问题。分层检测提供了对未检测到的故障的深度防御。

设计警报阈值，平衡早期发现和假阳性。在错误率超过阈值或出现持续降级时发出警报，而不是在孤立的故障时。单个错误在分布式系统中是正常的。错误模式表示需要注意的可靠性问题。

Salesforce 调控器限制会限制多租户平台中每个租户的资源消耗，因此单个租户不会降低其他租户的性能。这些不是任意的限制；它们是影响解决方案设计的架构边界。在设计可靠的架构之前，请了解调控器的限制。在正常负载下经常接近调节器限制的解决方案很可能会在压力下失败。

影响架构决策的关键调控器限制：

设计在限制内完成的交易，即使在峰值负载下。通过将调控器限制的 70% 作为正常条件下的操作上限来建立利润，并为意外的峰值保留 30%。此缓冲区适应临时负载增加，通常不会达到硬限制。

批量化是 Salesforce 的基本可扩展性模式。在单个事务中处理多个记录，而不是在单个记录操作中。批量化减少了调控器限制消耗，同时提高了吞吐量。每个 Salesforce 架构师必须掌握批量化模式，因为它们是所有可扩展解决方案的基础。

设计所有 Apex 触发器、批处理类和集成，以高效处理记录集合。首先收集记录标识符，然后使用单查询和 DML 语句处理所有记录。使用地图和集合进行高效的查找，而不是使用带有单个查询的嵌套循环。与逐条记录的方法相比，基于集合的处理提供了数量级的效率改进。

记录触发的自动化必须处理每个触发器调用 200 个记录，因为平台处理最多 200 个记录的批量触发器执行。Lightning 数据服务操作会自动批处理，但自定义组件必须在执行 DML 操作时明确实施批量模式。

异步处理会跨时间分配工作，而不是在单个事务的调控器限制内尝试立即完成。当操作处理超过同步调控器限制的大数据量、依赖于响应时间可变的外部系统、可以容忍延迟完成或需要超出同步 CPU 限制的延长执行时间时，请使用异步模式。

Salesforce 异步功能及其架构适应性：

• **批量 Apex：**以每个执行方法最多 2,000 条记录的块形式处理大记录量。批次提供每个块的专用调控器和故障隔离 — 失败的块不会阻止其他块完成。这将启用部分成功和目标重试。通过跟踪 AsyncApexJob 对象上的失败块范围，并重新将目标批处理作业排队，为暂时失败实施自定义重试逻辑。将批处理用于数据迁移、计划的批量更新和大规模数据处理。每个组织最多可以同时运行或等待执行的五个批处理作业。Apex 弯曲队列中的其他作业排队(最多 100 个处于保持状态的作业),并在空档打开时自动执行。
• **Queueable Apex：**使用链接功能执行异步作业，以启用多步骤工作流和复杂对象参数。Queueable Apex 与所有其他异步 Apex（批处理、未来和计划 Apex）共享组织范围内的 DailyAsyncApexExecutions 限制，即每 24 小时 250,000 次执行，而不是保留专用的Quueable 特定分配。将 Queuable Apex 用于需要顺序处理的多步骤编排和集成工作流，其监控效果优于 @future 方法。
• **平台事件：**平台事件用于将发布者与订阅者分离的发布-订阅事件架构。事件从 72 小时（3 天）的保留时段重放。超过 72 小时的延长保留作为付费加载项提供 — 在承诺履行依赖于延长重放的 SLA 义务之前，请验证最新的 Salesforce 平台事件文档中的当前最大限制和正式发布状态。将平台事件用于事件驱动的自动化、跨系统集成和实时数据流。平台事件提供了事务阶段之间的自然异步边界。
• **计划 Apex：**使用通过 System.schedule() 的 CRON 表达式，按固定计划执行作业。作业最多可以计划每小时运行一次 — CRON 秒和分钟字段必须使用固定值，而不是范围。通过将类似的操作合并到单个可计划类中，保持在每个组织最多 100 个计划的 Apex 作业的范围内。

当数据量超过实际处理限制时，即使使用批量化和异步模式，也要跨逻辑边界对数据进行分区，以启用并行处理。数据分区将大型顺序操作转换为较小的并行操作，这些操作完成速度更快，并且保持在调控器限制内。

• **基于日期的分区：**在时间窗口中处理数据，包括本月的交易或上一季度的个案。将历史数据归档到大对象或外部存储，以保持工作集可管理。大多数事务性查询关注最近的数据，这使得基于时间的分区自然高效。
• **记录类型分区：**独立处理不同的记录类型，包括合作伙伴个案与客户个案或企业客户与 SMB 客户。每种类型的单独批处理作业启用并行化。记录类型通常与证明独立处理的合理性的不同业务流程相关联。
• **基于所有者的分区：**按记录所有人分配处理，例如独立处理每个销售区域的业务机会。基于所有者的分区在与共享模式结合时尤其有效，因为安全性是通过现有机制强制执行的。基于所有者的分区支持处理负载的地理分布。

根据业务增长预测未来容量需求，而不是对限制耗尽做出反应。主动式容量规划可防止因平台资源不足而导致的可靠性事故。

• 用户许可证 - 人数增长推动每个用户的 API 调用分配和存储权利
• 数据存储 - 推动存储消耗的事务量和保留策略(名义上计划至少实现 10-20% 的年增长)
• API 调用 - 集成计数和频率驱动 24 小时 API 分配（每个新的集成模式都会增加重复消耗）
• 处理能力 - 批处理作业数量和复杂性导致异步处理队列和并发执行限制

使用 Proactive Monitoring 持续评估组织容量使用情况。Proactive Monitoring 显示了容量风险，包括 API 使用接近请求限制峰值、存储接近限制以及批处理作业队列深度超出可持续水平。每周容量审查可在业务影响发生前为其他许可证或限制预留采购准备时间。

在生产部署前，通过负载测试验证可扩展性假设。负载测试揭示了低用量开发测试中不可见的调控器限制问题、集成瓶颈和容量约束。使用生产规模的数据量和并发进行测试，以验证在现实条件下的可靠性。

• **数据量测试：**在完全复制 Sandbox 中填充生产规模数据量，以通过实际数据偏差、关系深度和记录计数验证查询性能。在生产达到该规模时，使用 1000 多万条记录进行测试。随着数据量的增加，查询优化器的行为会急剧变化，这可能会导致误导性的小扩展测试结果。
• **并发用户测试：**模拟峰值并发用户负载，以验证事务吞吐量和竞争。在部署前，使用适用于合格组织的规模测试来模拟 Sandbox 环境中的生产工作负载。并发执行揭示了单用户测试中不可见的锁定问题。
• **API 负载测试：**生成峰值 API 容量，以验证集成可扩展性、速率限制处理和持续负载下的断路器行为。API 负载测试揭示了重试逻辑和错误处理是否在压力条件下正常工作。
• **扩展测试:**扩展测试是 Salesforce 产品，用于在完全复制 Sandbox 环境中模拟生产工作负载，并根据生产能力进行扩展。扩展测试针对 Hyperforce 上的完全复制 Sandbox 运行。您的生产实例无需在 Hyperforce 上即可使用。您可以在生产组织中创建测试计划，同时根据 Sandbox 执行测试。在主要部署前，使用扩展测试来验证调控器限制净空、异步处理吞吐量和峰值负载条件下的集成响应行为。

当非关键组件出现故障时，温和降级会保持核心功能。设计系统在故障期间优先考虑关键用户流而不是支持功能。并非所有功能都具有同等的业务重要性，架构应反映这些优先级。

定义功能关键度层次结构：

这种层次结构使架构师能够设计即使在部分系统故障期间也能保持业务连续性的降级策略。用户更喜欢减少功能，而不是完全不可用。

断路器模式防止集成不可用时的级联故障。检测失败模式并停止调用失败的系统，而不是累积消耗事务时间和调控器限制的超时。断路器提供快速故障，而不是缓慢故障。

断路器状态：

• 已关闭 - 正常运行，请求按设计流向外部系统
• 打开 - 超过失败阈值，请求立即失败，无需尝试外部调用，节省资源
• 半开放 - 恢复测试期间，有限请求会探测外部系统，以在完全闭合电路之前检测恢复情况

使用平台缓存实施断路器，以存储所有事务可访问的电路状态。使用平台事件在组织中广播状态更改。断路器逻辑会在尝试外部调用前检查状态，避免浪费已知失败系统的标注限制。

在分布式系统中，瞬态故障是正常的。网络中断、临时服务不可用和速率限制响应通常在几秒内解决。实施重试逻辑，在渐进式延迟后重复失败的操作，而不是立即失败。

指数回退可以防止使恢复系统淹没的重试风暴。第一次重试可以在 1 秒后发生，第二次重试可以在 2 秒后发生，第三次重试可以在 4 秒后发生，第四次重试可以在 8 秒后发生。无论指数增长如何，将最大延迟上限为 30-60 秒。这种回退模式为失败的系统提供了恢复时间，同时限制了重试的总持续时间。

将重试策略与失败类型匹配。

• **网络超时：**请稍作后退重试（操作可能未到达服务器）
• **流量限制错误 (429)：**在重试后标题值后或速率限制重置时间后重试
• **服务器错误 (5xx)：**使用指数回退重试，因为服务器可能暂时过载
• **客户端错误（4xx 除外 429）：**请勿重试；修复请求，因为错误表示输入无效
• **管理者限制错误：**请勿在同一事务中重试；作为具有专用限制的异步操作重新排队，例如，发布异步订阅者在新的事务限制下重新处理的失败事件

回退策略定义了主要方法失败时的替代方法，允许在降级条件下继续操作。

• **替代数据源：**当实时 API 不可用时，从平台缓存会话或组织分区检索数据。在成功操作期间预填充缓存。缓存提供过时但可用的数据，这对许多用例来说比完全失败要好。
• **默认行为：**当个性化或丰富服务不可用时，应用标准业务规则。使用默认值处理，并在服务恢复时标记丰富。默认行为以精度降低为代价来保持吞吐量。
• **手动进程：**在自动化失败时启用手动操作完成。提供管理员界面，以完成停滞事务。当自动化受到损害时，手动回退可以防止数据丢失并保持业务连续性。
• **重试队列：**将操作存储在平台事件或自定义队列对象中，以便在外部系统恢复时进行处理。具有 72 小时标准保留的平台事件重放支持订阅者在临时故障后恢复，而不会丢失数据。

为所有集成标注配置适当的超时。Salesforce 强制执行每个事务最多 120 秒的总标注时间。在单个事务中的所有标注中预算该时间，以避免耗尽挂起连接的事务时间。

超时设计注意事项：

• **面向用户的同步标注：**使用最多 5-10 秒来维护响应式 UI，因为用户往往不会等待更长时间
• **后台异步标注：**使用 30-60 秒适应可变的外部性能，无需用户等待
• 批处理标注：在没有用户等待响应时使用允许的整个 120 秒
• **每个事务的多个标注：**所有标注的预算总时间，例如 3 次标注，每次 10 秒，消耗 120 秒预算中的 30 秒。

更短的超时会更快地失败，使后备策略能够更快地参与进来。较长的超时提高了速度缓慢但功能正常的外部系统的成功率。平衡注意事项取决于用户是否正在等待响应，以及后备策略的可用性。

设计全面的错误处理，将故障从崩溃转化为受管降级：

• **快速失败：**在入口点验证输入和先决条件。在昂贵操作前，检查调控器限制消耗。立即检测故障，而不是通过多个处理层传播无效状态。早期检测减少了爆破半径，并简化了调试。
• **优雅地失败：**即使操作部分失败，也要维护用户功能。如果批次中的 200 个记录中有 3 个验证失败，则处理 197 个成功记录并报告 3 个失败，而不是整个批次失败。对于批处理操作，部分成功优于全部失败。
• **信息性失败：**使用事务 ID、用户上下文、输入参数和堆栈跟踪记录错误。错误上下文不足是快速解决事件的主要障碍。每个错误日志应使响应者能够了解失败的原因、原因以及如何复制。
• **安全失败：**确保失败不会损害数据完整性或安全性。回滚部分事务，而不是将数据留在不一致的状态。请勿向最终用户公开内部错误详细信息，因为堆栈跟踪显示了对攻击者有用的实施详细信息。

恢复时间目标定义了灾难后可接受的最长停机时间。RTO 推动了关于故障切换自动化、备份频率和恢复测试投资的架构决策。不同的业务能力证明不同的 RTO 投资是正确的。因为 RTO 是用户直接经历的停机时间，所以错过目标会转化为长期停机和客户 Trust 的削弱。

RTO 因业务能力而异：

在设计灾难恢复架构之前，定义每个功能的 RTO。RTO 决定了技术选择、自动化投资和测试节奏。更激进的 RTO 目标需要在自动化和冗余方面加大投资。

恢复点目标定义了用时间测量的最大可接受数据丢失窗口。RPO 确定备份频率、复制策略和同步模式。更严格的 RPO 需要更频繁的数据复制，增加了复杂性和成本。因为 RPO 是您的业务吸收的数据丢失，所以错过目标可能意味着丢失交易和记录中无法恢复的缺口。

平衡 RPO 要求与成本和复杂性。近乎零的 RPO 需要连续的数据复制，并需要大量的基础设施投资。每日备份提供 24 小时 RPO，复杂性最低。对于非财务数据，大多数组织可以容忍一些数据丢失。

平台基础设施冗余可以防止基础设施故障，但它复制了用户错误、部署缺陷和集成缺陷的结果，这些缺陷会导致大多数数据丢失。存在备份是为了从这些应用程序层故障中恢复，而不是为了补偿平台的可靠性。实施涵盖数据、元数据和文件的备份策略，因为每个策略都需要不同的备份方法：

• **数据备份：**实施针对数据和元数据的全面备份策略。使用本地数据导出服务导出关键对象数据 — Enterprise、Performance 和 Unlimited Edition 每 7 天导出一次；Professional 和更低版本每 29 天导出一次。导出文件在发送通知电子邮件后的 48 小时内可用，不包括自动删除前的周末设置自动下载流程，以便文件不会永久丢失。使用元数据 API 和 Salesforce CLI（sf 项目检索）对 Git 等源控制系统中的组织配置、自定义代码和声明自动化进行版本控制。将元数据备份视为标准 CI/CD 漏斗的一部分。使用专用备份和恢复服务补充数据备份，例如 Own 用于时间点恢复、粒度记录级恢复和超出本地导出节奏的保留。本地数据导出不支持时间点还原，如果您的 RTO/RPO 需要精细的恢复窗口，则需要第三方工具。定期测试还原程序；从未还原的备份是未经测试的假设。
• **元数据备份：**使用 Git 存储库中的 Salesforce DX 源格式，版本控制所有元数据。元数据版本控制允许在损坏或意外更改后快速恢复配置。每个部署都应可从源控制中复制。Git 中的元数据为配置提供了时间点恢复。
• **文件备份：**将 ContentVersion 记录、附件和文档导出到外部存储。Salesforce 最适合活动数据，而不是长期文件归档 - 将文件导出到外部存储进行监管保留。对于超出平台功能的法规保留要求，实施自动文件导出。
• **验证：**定期将备份恢复到临时组织或开发人员 Sandbox，以验证程序和备份完整性。由于备份范围不完整或归档损坏，未经测试的备份通常会在需要时失败。计划每季度一次的还原验证，以便在灾难发生之前发现问题。除了恢复验证之外，还要监控备份的新鲜度。当最近的成功备份早于其预期的节奏时发出警报 - 例如，当每周导出超过 8 天未完成时。通过此验证，静默失败的备份作业会立即显示，而不是在下一次演练时。

设计适合 RPO 和多组织要求的复制：

• **变更数据捕获(CDC):**订阅被跟踪对象的变更事件。CDC 提供具有更改字段值的创建、更新、删除和取消删除事件。以最少的开发工作量为支持的对象（包括标准和自定义）提供近乎实时的复制。取决于基于版本的每日交付分配。
• **平台事件：**用于复制业务事件和状态更改的自定义事件架构。比 CDC 更灵活，支持自定义负载和复杂的事件结构，但需要在触发器或进程中显式发布逻辑。72 小时重放窗口标准支持从临时订阅者失败中恢复。
• **计划 API 复制：**计划 API 复制是通过批量 API 2.0 按固定计划批量提取。这是最简单的实施，RPO 等于提取频率。计划 API 复制适用于不需要近乎实时执行的非关键数据，例如参考数据或历史分析。
• **MuleSoft 编排的复制：**对于复杂的多系统复制拓扑，MuleSoft Anypoint 平台提供编排、转换和监控。它的使用适合跨 Salesforce 和多个外部系统进行复制，这需要复杂的路由和转换逻辑。

使用共同验证人员、流程和技术的计划演练测试灾难恢复：

• **桌面练习：**该团队逐步了解灾难场景，讨论角色和决策点，而无需实际故障转移。这项活动成本低，而且揭示了程序上的差距和沟通上的失败。定期进行桌面练习，以在人员变化时保持团队准备就绪。
• 部分故障切换：- 测试特定的恢复程序，例如从源控制还原元数据、从备份服务还原数据或 Sandbox 刷新。这将验证对业务影响有限的技术程序。定期执行，轮流测试哪些程序，以涵盖每年的所有恢复功能。
• **完整故障转移演练：**完全故障切换是具有生产流量切换的灾难恢复环境的完全故障切换。它提供了最高的信心，但需要业务协调和用户沟通。每年对关键系统进行此演练。完整的故障切换钻取会验证整个恢复功能，包括切换程序和用户通信。

记录每次演练后吸取的经验教训。根据调查结果更新 Runbook。随着团队的变化和解决方案的发展，恢复功能可能会下降。将灾难恢复文档视为需要定期维护的活工件，而不是一次性交付品。

业务连续性超出了技术恢复的范围，还包括人员、流程和供应商依赖性：

• **团队可用性：**文档升级程序和关键角色的后备人员。确保操作 Knowledge 中不存在单点故障。主要响应者可能在灾难期间不可用，这使得后备人员至关重要。
• **通信程序：**定义事件如何传达给用户、客户和管理人员。建立主要工具（例如，外部状态页面或短信通知系统）不可用时可用的通信渠道，包括 Salesforce 本身。
• **供应商依赖性：**映射对解决方案运营至关重要的外部供应商依赖性。记录每个重要供应商（包括 Salesforce、集成合作伙伴和 ISV 软件包提供商）的升级路径和合同 SLA。例如，了解哪些供应商提供全天候支持，哪些供应商的仅工作时间支持会影响恢复时间。
• **监管义务：**确定由长期停机触发的通知要求。金融服务、医疗保健和政府合同通常要求在特定时间范围内通知事件。不合规会产生监管和法律风险，这两种风险都会加剧灾害影响。

定义健康模型，将多个信号聚合到整体系统健康状态。运行状况模型一目了然地显示运行状态，无需分析详细的度量。例如：

设计立即显示运行状态的健康仪表板。健康状态指导操作响应，包括绿色状态下的正常操作、黄色状态下的强化监控和红色状态下的活动事件响应。

平台状态信号（之前在平台运行状况监控中介绍）显示 Salesforce 基础设施何时降级，但不会显示您自己的解决方案的性能。

通过特定于解决方案的观察性增强这些信号：

• **事件监控：**Event Monitoring 包括捕获 API 调用、页面视图、报表导出、登录活动和 Apex 执行的详细日志。EventLogFile 对象以 24 小时(每天)或 1 小时的频率传递日志 – 每小时传递需要 Event Monitoring 加载项或 Salesforce Shield。通过“设置”最多可以配置保留 365 天，但延长保留需要 Salesforce Shield 或 Event Monitoring 加载项。如果没有加载项，日志文件将保留 1 天。将事件路由到外部安全信息和事件管理 (SIEM) 系统或日志聚合平台，以进行相关性、警报和超出本机限制的保留。使用 Event Monitoring 检测异常 API 消耗模式，识别失控的 Apex 进程，并审计受管环境中的数据访问。
• **比例中心：**规模中心提供了对长时间运行的操作、行锁定竞争和资源密集型事务的事务级可见性。规模中心使架构师能够在导致面向用户的事件之前从特定的事务模式中识别可靠性风险。每周审查可以揭示优化业务机会。
• 主动监控：Proactive Monitoring 支持持续评估组织运行状况，并显示性能和可扩展性风险。Proactive Monitoring 提供有关 API 请求限制峰值、并发 Apex 执行失败、SOQL 行限制问题和存储消耗趋势的警报。它适用于拥有签名成功(以前称为签名支持)权利的客户 — 它不是标准版本中包含的自助功能。

从用户角度而不是基础设施角度监控应用程序性能：

• **实时用户监控 (RUM)：**通过 Experience Cloud 分析或自定义仪器测量实际用户体验。rum 捕获真实延迟，反映实际网络条件、设备性能和地理分布。合成监控无法复制这种变化。
• **合成监控：**从多个位置定期执行自动事务，以验证可用性和性能。综合监控会在用户报告前检测到问题。使用计划的 Apex 实施合成监控，执行关键操作，并通过平台事件报告结果。
• **交易跟踪：**对复杂的多步骤操作进行仪器化，以获取每个步骤的时间。接下来，确定五步工作流中的哪个步骤引入了延迟。不要将整个流视为黑匣子。步骤级时间揭示了聚合度量中不可见的优化机会。

使用错误率、延迟百分比和吞吐量监控所有外部集成。集成失败是可靠性事故的主要原因：

• 错误率 - 返回错误的呼叫百分比（目标：<1% 表示正常集成）
• Latency - 在 p50、p95、p99 测量的响应时间（根据超时预算设置每个集成的 SLO）
• 超时率 - 超出配置的超时(目标:<0.1%)的百分比
• 断路器状态 - 打开状态表示需要立即注意的持续故障
• 队列深度 - 对于异步集成，不断增长的队列表示处理落后于生产速度

使用请求 ID、端点、响应代码和持续时间记录所有集成调用。当集成失败影响可靠性时，此数据可以快速进行根本原因分析。集成日志应启用聚合和趋势分析。

在影响用户之前设计问题警报，实现主动响应：

• **可操作的警报：**每个警报都有定义的响应操作和分配的响应者。没有明确响应的警报会产生疲劳感，并模糊关键信号。警报设计应涵盖谁响应、他们检查什么以及如何补救。
• **适当的紧迫性：**呼叫呼叫人员，了解影响用户的故障。为性能下降发送电子邮件。在每日摘要中包含问题，以捕获有关趋势的信息。紧急程度不匹配会因过度升级而产生警报疲劳，或因升级不足而产生错过事件。
• **富上下文通知：**包括跨越的阈值、当前值、最近趋势，以及指向相关仪表板或 Runbook 的链接。使响应者能够立即开始诊断，而无需收集上下文。每个警报应包含足够的信息，无需额外查询即可分类。
• **风暴抑制：**在多个系统同时出现故障时，禁用冗余警报。一个指示集成平台失败的警报比 50 个掩盖根本原因的单个集成失败警报更具可操作性。

异常检测识别异常模式，并可以指示静态阈值警报不可见的新问题：

• 数量异常:大大高于或低于预期的每日模式的事务量可能表明进程失控或用户访问问题。
• 错误率异常:与上周同期基准相比，错误率升高会导致在阈值突破前逐步下降。
• 延迟异常:响应时间在多天内向上偏移表示容量饱和或性能下降。
• 行为异常:不寻常的登录模式、意外的 API 使用峰值和在计划窗口之外运行的批处理作业可能表明存在可疑的使用。

对于拥有签名成功权利的客户，Proactive Monitoring 无需额外配置即可提供平台级异常检测。使用特定于应用程序的异常检测来补充它，以检测导出到外部 Analytics 平台的自定义 SLI。使用异常信号来指导调查，而不是触发立即升级，因为异常检测的误报率高于阈值警报。

在架构审查期间、生产部署之前，使用此核对清单，并定期进行持续的可靠性评估。

可靠性目标和 SLO

• 在设计开始前，定义所有关键用户流的 SLO
• 建立与用户体验相关的可衡量SL，而不仅仅是基础设施度量
• 根据业务影响分析制定现实的可用性目标，而不是任意的目标
• 确保解决方案 SLO 没有平台 SLA 那么严格，以提供错误预算
• 在架构决策记录中记录可用性目标和理由

高可用性架构

• 在数据、应用程序和集成层设计冗余
• 通过 trust.salesforce.com 和实例状态 API 监控平台运行状况
• 实施独立于平台状态的应用程序健康检查
• 仅在业务需求明确证明复杂性时考虑多组织架构
• 使用经过测试的多组织模式 Runbook 设计自动故障切换

可扩展性和容量规划

• 在正常负载下，设计事务在调控器限制的 70% 内完成
• 在所有 Apex 触发器、批处理类和集成中实施批量化模式
• 对超过同步限制的操作使用异步处理
• 批处理所有 API 集成，而不是进行单个记录调用
• 在部署前对生产规模数据量进行负载测试
• 通过 OrgLimits API 或自定义 Apex 监控容量利用率，并在消耗接近 70% 的操作上限时发出警报
• 基于 12 个月增长预期的项目容量要求
• 按日期、记录类型或所有者对高用量数据进行分区，以在用量超过顺序限制时启用并行处理

容错和恢复

• 使用定义的功能关键度层设计优雅降级
• 为所有外部系统集成实施断路器
• 对暂时性失败应用具有指数回退的重试逻辑
• 配置适合操作类型的超时（5-10 秒面向用户，30-60 秒异步）
• 使用平台缓存和基于队列的模式设计后备策略
• 通过足够的诊断上下文实施结构化错误处理

灾难恢复和业务连续性

• 在设计前定义每个业务能力的 RTO 和 RPO
• 实施数据、元数据（源控制）和文件的自动备份
• 在非生产环境中每季度验证备份还原程序
• 监控备份新鲜度，并在计划备份过期时发出警报
• 设计符合 RPO 要求的数据复制策略
• 每年进行灾难恢复测试（桌面季度）
• 记录业务连续性程序，包括供应商升级路径

监控和可观察性

• 定义聚合服务、集成、数据和容量信号的运行状况模型
• 订阅 Salesforce 实例的平台状态通知
• 为关键 Experience Cloud 流实施真正的用户监控
• 通过错误率、延迟和断路器状态监控集成运行状况
• 设计具有定义响应程序和所有权的可操作警报
• 将 Event Monitoring 数据路由到外部平台进行长期保留和分析
• 使用 Proactive Monitoring 和规模中心进行连续的可靠性风险评估
• 对数量、错误率和延迟模式应用异常检测，以发现静态阈值错过的降级

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