在这里阅读我们的更新计划。

弹性解决方案即使在出现故障时也能保持高质量的服务。如果性能下降或服务中断，解决方案会快速有效地恢复。

解决方案的弹性基于两个关键品质：

• 韧性:当出现问题时，解决方案会经受住这些问题。
• 弹性:解决问题后，解决方案会恢复到理想状态或形状。

要为弹性构建解决方案，您必须同时设计韧性和弹性，确保在面对计划内和计划外的变化时保持耐用性和快速恢复。

在技术上下文中，将系统或解决方案视为相互依赖的组件集合，这些组件相互协调，以实现共同目标。每个组件都有失败的可能性。这些组件中的问题，从代码和配置缺陷到网络和硬件问题，都会导致意外的、不需要的行为。当一个或多个组件出现故障时，系统会显示弹性行为，但整个系统会继续运行或快速恢复到稳定状态。

为了提高 Salesforce 解决方案的弹性，我们建议关注三个关键习惯。

• 应用程序生命周期管理 (ALM) - 团队如何在软件的整个生命周期中对其进行管理(从构想到停用)
• 事件响应 — 团队如何识别、解决和防止影响系统可用性或安全性的问题
• 连续性规划 — 团队如何规划人员和系统，以在计划外事件导致问题时继续运行

应用程序生命周期管理 (ALM) 是一种在软件的整个生命周期（从创建到停用）中对其进行整体管理的实践。ALM 是系统弹性的基石，并包含与应用程序生命周期相关的人员、流程、工具和学科。这些学科包括 DevOps 和交付方法、可观察性、测试策略、治理和 CI/CD。

当业务实践有效的 ALM 时，其团队会快速响应变化，其应用程序也会跟上不断变化的业务需求，而不会损害稳定性或质量。

另一方面，如果没有健康的 ALM，团队在应用程序生命周期的每个阶段都会举步维艰。

不良 ALM 的症状包括：

• 开发周期缓慢且容易出错
• 密集和困难的部署
• 在生产和后 QA 环境中发现的高严重性问题或错误
• AI 客服人员出现幻觉或行为不一致
• 稳定版本所需的频繁回滚或热修复部署

因为 ALM 涉及解决方案的几乎所有方面，所以为您的解决方案建立清晰有效的 ALM 实践是您的架构工作的关键部分。

通过关注三个关键领域，构建更好的 ALM 实践。

• 版本管理 — 变更的规划、排序、控制和迁移到不同环境
• 环境策略 — 在开发和测试期间如何在目标环境中使用和管理应用程序的策略
• 信令策略 — 定义关键信号和应用仪器，用于在降级前检测和补救系统中的故障
• 测试策略 — 指导您如何计划和运行测试的原则和标准，以衡量 ALM 流程期间应用程序的成功

发布管理涉及计划、排序、控制和将更改迁移到一个或多个环境。单个版本是团队同时移动到目标环境的一组计划更改。

发布对系统的更改会引入风险。如果系统在更改前处于稳定状态，则会转换到新状态，其中也更容易受到未来更改的风险。如果未来的任何更改触发了系统中不受控制的不稳定状态，它们可能会导致严重事件。在解决方案架构中，设计弹性版本不仅仅是有效测试单个更改。它还涉及计划如何安全地向您的系统及其用户引入更改。

团队的工作取决于可预测和准确的发布信息。在变更管理和启用过程中，请清楚哪些变更可以进入您的系统。在发布管理和启用流程中，指定更改发布到系统的方式和频率。

您的业务利益相关者也关心发布信息，特别是如果这些信息与他们要求的功能或缺陷修复相关。为了建立对解决方案的 Trust 并向利益相关者展示价值，请制定一致和明确的发布时间表，并运送稳定的发布工件。

要为 Salesforce 建立有效的发布管理：

• 与架构和开发治理紧密结合确保提前计划发布，以便与所有相关治理论坛和控制保持一致。在开始开发之前，请让 AI 理事会审核和批准所有优先 Agentforce 用例。让高风险 Agentforce 用例由法律和道德使用团队审查。使用部署核对清单和文档，根据治理活动跟踪部署工件，例如 Agentforce 客服人员 API 名称。
• 请勿使用组织开发或发布流程。这一范式反映了较旧的、较有限的开发和发布技术。借助 Salesforce CLI，团队现在可以采用源驱动的开发和发布功能。
• **选择最稳定的释放机制。**这种方法实现了两件事情。首先，它最大限度地减少了发布窗口和服务中断的持续时间。其次，它允许高度控制和可预测的发布行为。您的发布机制越稳定，发布引入需要热修复或回滚的更改的可能性就越低。如果出现意外问题，稳定的发布机制也会为支持人员或系统管理员执行回滚创建更简单的方法。

团队的最佳发布机制是团队拥有所需技能的最稳定选项。这些是推荐的发布机制，按稳定性顺序排列。所有这些组件都相互兼容，因此如果这对贵公司最有利，请将它们中的多个组件串联使用。

• 解锁软件包 - 解锁软件包是最稳定的发布工件。通过安装软件包部署更改是引入更改的最快和最可预测的方式。软件包使用版本控制，这允许强大的变更管理和细粒度的、系统管理员友好的回滚。软件包需要强大的元数据管理，这可以帮助您尽早发现管理不善的依赖关系。他们还创建可审计的开发漏斗和工件。请参阅可打包性。
• DevOps Center — DevOps Center 允许具有低代码或专业代码技能的交付团队使用源控制、协作处理更改并定义通用发布路径。DevOps Center 与源控制集成，并允许对更改和部署进行点击式控制。
• 使用 Salesforce CLI 进行源驱动开发和元数据部署 — 如果您无法使用软件包，请将 Salesforce CLI 用于源驱动开发和元数据部署。不要使用旧的 package.xml 格式部署元数据，它遵循与推荐的源格式不同的结构。源格式已发展为支持软件包开发、临时组织工作流和 Sandbox 中的更精细变更跟踪。该格式更具可读性，允许更多解耦复杂的元数据类型和依赖性，并为您提供对部署清单的更多控制。
• 命名发布版本。为您的版本提供明确的标识符，以帮助您的团队和利益相关者保持一致。在 Salesforce 中，每个主发布版本的名称都以“春季”、“夏季”或“冬季”开头，然后是发布年份（例如，“Summer ’25”）。如果您的公司还没有定义和组织版本的命名约定，请建立一个并使用它。使用清晰的发布名称，可让您更容易在团队系统的规划、开发和交付的每个阶段保持井然有序。在路线图中使用您的版本名称，向利益相关者清楚地传达哪些变化即将到来以及何时到来。在文档、更改日志、工作描述、代码注释和源代码控制分支中使用您的版本名称，以便您可以轻松地跟踪和审计您的开发工件。
• **在版本清单中，管理依赖性。**Salesforce 元数据具有内置依赖性。Salesforce 部署失败的一个常见原因是依赖性管理不当。如前所述，选择稳定的发布机制有助于在开发周期的早期暴露管理不当的依赖关系。解锁软件包是最稳定的发布工具的主要原因之一是其强大的元数据管理，这是软件包开发和创建所必需的。如果您或您的发布管理团队不理解 Salesforce 元数据类型之间的内在依赖性，您将无法在部署和发布清单中主动发现有问题的组合。请参阅依赖性管理。

ALM 的模式和反模式显示了 Salesforce 组织正确和糟糕的发布管理。使用模式在构建之前验证您的设计，或者确定系统中需要重构的位置。

要了解有关适用于发布管理的 Salesforce 工具的更多信息，请参阅适用于弹性的 Salesforce 工具。

Salesforce 提供了多种环境供您在应用程序开发和测试周期中使用。Salesforce 的有效环境策略需要了解如何使用环境，以及良好的管理是什么样子。在 ALM 中，开发或测试环境的用途取决于它对生产的忠诚度和与生产的隔离。

良好的环境策略提供了几个好处。

• 对生产的更高忠诚度
• 更快的环境设置和拆除
• 开发和测试更加敏捷
• 提高整个漏斗的安全性
• 在整个交付阶段减少噪音和冲突
• 更快乐的开发团队

团队通常很难实现这些好处。充分利用开发环境和战略的挑战可能来自几个方面。一个可能的来源是团队遵循的开发模式类型。

在旧的、基于组织的开发方法中，每个环境都需要为几个功能提供服务。除了是团队进行各种工作的地方之外，它还需要是发布工件的来源（即您想要在版本中部署的元数据）。因为环境不容易设置或拆除，所以它们通常过度拥挤，并且充满了团队之间的元数据冲突，它们没有为 ALM 整体贡献有意义的速度或灵活性。

使用基于源的开发模型从根本上改变了环境与您的发布和发布工件的关系。在此模型中，源控制是您想要发布的元数据的来源。环境只是团队开展工作的地方。

然而，遵循基于源代码的发展模式并不能保证良好的环境策略。即使使用源控制，团队仍然很难设置条件来测试与外部系统的集成；依赖于源控制之外的元数据的配置，例如依赖于数据的受管软件包或自定义等。在某些情况下，基于源模型的挑战类似于基于组织模型的典型挑战。

要制定有效的环境策略：

• 采用源驱动的开发和发布模型停止使用基于组织的开发模型。请参阅版本管理。）您必须将环境与部署的环境分开，以创建健康的环境策略和更健康的版本。
• **了解每个环境支持的工作类型。**Salesforce 支持的环境类型具有不同的功能和限制。在设计环境策略时，请考虑环境可以做什么和不可以做什么。确保您的团队在具有所需功能的环境中工作。有关指导，请参考 Salesforce 开发环境及其功能的概述。

请参阅此表，了解将哪些功能和环境用于一些常见开发任务。

此外，请注意，对于使用 Einstein 数据库、Knowledge 文章和非结构化数据等功能的 Agentforce 客服人员，全面测试将受到限制，除非您拥有 Data 360 Sandbox。您还需要 Data 360 Sandbox，以确保测试条件准确。

• **将环境与发布工件分离。**请勿使用基于组织的开发。将环境视为工作在固定时间内发生的地方。将环境中的元数据状态视为与您的发布工件分开。如果一段代码或配置在环境中被“弄清楚”，它应该被提交到源代码控制中，使其成为一个发布工件。

  • 环境是短暂的。构建进程，以便您可以尽快创建和销毁它们。
  • 人工制品经久不衰。它们属于源控制。

• **将环境与发布路径分离。**常见的是，需要将更改部署到特定环境的强制发布路径。通常，实施这种方法是为了建立代理来验证应用程序的成熟度或发布稳定性。团队也可以用它来尝试最大限度地减少他们必须配置复杂测试基础设施的环境数量。在基于源的范式中，您可以在如何和在哪里验证和测试更改方面拥有更大的灵活性。

  • 发布阶段适用于发布工件，不适用于环境。不要仅为“收集”特定发布阶段的所有更改而创建环境。这就是源控制的目的，特别是分支。在源控制中使用分支策略，以组织将哪些更改部署到哪些环境。根据您需要完成的工作，您可能需要将版本中的所有元数据部署到环境中。分支使您能够做到这一点。除了一些例外情况，每个开发环境必须在相关工作完成后立即刷新或销毁。请确保将对在特定环境中发生的元数据的任何更改（以及要保留的元数据）同步到源控制。
  • 环境只有在忠于生产的情况下才有用。优化环境设置工作流或自动化，以便您可以尽快拆除或刷新环境。请将任何阻止您执行更快、更频繁环境刷新的配置视为对 ALM 流程整体弹性的重大风险。如果您有相关的补救工作，请将其添加到计划中，并确定优先级。探索如何在系统中采用更多松耦合的模块化单元。它们使团队能够在临时组织中执行更多类型的开发，并为其他工作释放 Sandbox 分配。请勿忘记临时组织提供的功能，用于测试您在生产中没有的功能，因为您没有为其购买许可证或启用它们。
  • 在业务用户或最终用户可以访问的环境中，让这些用户关注对他们重要的事情。不要有通用的、没有区别的环境，在这种环境中，许多不同的最终用户或业务利益相关者试图从事与 ALM 相关的工作。邀请并激活特定利益相关者进入特定环境，以完成特定工作。仔细评估将最终用户或业务利益相关者置于数据超过部分复制 Sandbox 支持的环境中的任何流程。确保数据量对于要完成的工作是必要的。规划用户验收测试和早期开发周期，以便尽可能紧密地结合在一起。优化所有测试阶段，为您的开发团队和最终用户提供更快、更早的反馈和迭代周期。请参阅测试策略。

• 为不同类型的更改构建不同的发布路径并非所有更改都需要以相同的顺序完成相同类型的 ALM 工作。让最终用户对系统的后端组件进行细微的更改进行验收测试可能不会很好地利用他们的时间。但在移动应用程序的早期开发阶段，用户接受和规模测试可能非常有价值。确定不同变更类别的发布路径，例如高风险、中度和低风险。

  • **高风险：**更改会影响客户、合作伙伴或所有内部用户。更改会影响安全性或集成。更改增加了复杂的新功能。
  • **中度风险：**更改的影响超过定义的内部用户阈值。更改会影响数据模型、执行数据操作的自动化或集成。
  • **低风险：**直接影响少于定义的内部用户阈值。不包括对安全性、数据模型或涉及数据操作的自动化或集成的更改。

• **不要允许存在过度拥挤的环境。**在确定工作的优先级、范围和排序方面缺乏纪律不可避免地导致开发环境过载，工作量太多、太多、太不同。过度拥挤的环境在开发团队之间造成了高度的压力、模糊性和冲突。它们还会在开发漏斗中制造噪音，并阻碍质量控制工作。除了这些负面影响之外，过度拥挤的开发环境也是对环境维护和安全的严重威胁。将过度拥挤视为 ALM 流程中潜在问题的症状。调查任何根本原因问题并加以解决。如果您仍然面临过度拥挤,您可以购买额外 Sandbox。

ALM 的模式和反模式列表显示了 Salesforce 组织中正确和糟糕的环境管理。在构建之前，使用它们来验证您的设计，或者确定系统中需要重构的区域。

要了解有关适用于环境管理的 Salesforce 工具的更多信息，请参阅适用于弹性的 Salesforce 工具。

信令策略定义了在故障级联到全系统降级之前检测、诊断和补救故障所需的关键信号和应用仪器。有效的仪器将应用程序从失败的被动受害者转变为自身复原力的积极参与者，能够发现问题，调整行为，并在必要时协调优雅的降级。

当应用程序实施全面的仪器时，他们获得在压力下自我调节的能力，向操作员传达他们的健康状况，并参与协调的恢复工作。这些功能允许系统即使在单个组件遇到问题时也能保持服务质量。另一方面，如果没有适当的仪器，应用程序就会变成黑匣子，在出现灾难性症状之前，它会无声地失败。团队仅在用户报告后对问题做出反应，故障排除成为考古工作，而不是观察。

• 检测应用程序中的失败。应用程序必须自行检测并响应在重负载下出现的常见故障模式。考虑队列饱和度。当消息队列的填充速度超过处理速度时，未经检测的应用程序会继续接受工作，直到出现内存耗尽或超时级联。正确检测的应用程序会监控队列深度、拒绝率和处理延迟，并在超过阈值时触发防御性响应。

• 有效处理来自应用程序外部的信号:操作系统信号的处理代表了另一个关键的检测点。应用程序必须注册终止信号 (SIGTERM、SIGINT) 的处理器，才能正常关闭。在关闭期间，正确检测的应用程序会停止接受新工作，允许实时请求完成、清除缓冲、干净关闭连接，并从服务发现中注销。这种精心策划的关闭可以防止数据丢失，并允许负载平衡器在不中断的情况下重定向流量。

• **复杂故障场景的说明：**除了这些基本模式之外，应用程序还必须针对更微妙的故障模式进行设备检测。识别灰色故障，即一些观察者认为组件正常，而其他观察者认为组件故障，这需要将内部和外部信号进行关联。应用程序可能会检测其数据库连接池，以报告成功的运行状况检查，同时跟踪显示蠕变降级的事务完成率。有效的仪器策略将多个观察点分层。

  • 业务度量跟踪特定于应用程序的成功指标，例如订单完成率或搜索结果质量。
  • 系统度量监控资源利用率、延迟分布和错误率。
  • 合成探针会持续使用关键路径，以在用户遇到之前检测降级。
  • 分布式跟踪提供了跨服务边界的请求级可见性。

这些信号通过标准化界面公开，允许自动化系统和人工操作员评估应用程序运行状况。仪器本身成为应用程序弹性策略的一部分,使断路器能够根据错误率跳闸,自动缩放器能够响应队列深度,操作员在事故期间做出明智的决定。

ALM 的模式和反模式显示了在 Salesforce 组织中正确和糟糕的信号策略是什么样子。在构建之前，使用它们来验证您的设计，或者确定系统中需要重构的区域。

要了解有关适用于信令策略的 Salesforce 工具的更多信息，请参见适用于弹性的 Salesforce 工具。

测试策略是一套指导原则和标准，用于如何计划和运行测试，以衡量 ALM 流程期间应用程序的成功和失败。测试策略让参与测试的每个利益相关者了解并符合给定测试的优先级、目的和范围。它还帮助项目团队创建有效和周到的测试计划。

通常，开发人员或质量保证和测试专家会参与创建和执行特定测试。测试策略有助于确保这些个人知道给定项目需要执行哪种测试，以及执行的顺序。测试策略还有助于确保团队拥有构建格式良好的测试、测试计划和工件所需的内容（例如，测试数据集、设备和流量或网络模拟器）。

有效的测试策略清楚地描述了如何、何时、何地和为何以各种组合和条件运行不同的测试类型（包括单元测试、UI 测试和回归测试），以揭示您的系统和任何正在进行的更改的行为方式。有效的测试策略会生成测试，向您展示系统对非功能要求的合规性（例如可扩展性、可靠性和可用性），而这些要求很难通过单一类型的测试来衡量。

要为 Salesforce 创建有效的测试策略：

• **迭代、频繁和尽可能通过自动化手段进行测试。**设计和实施测试自动化，使团队能够针对各种工作负载运行各种测试类型。编排各种测试运行，以便在更改进入源控制时自动进行。这种方法使团队能够提前主动识别和解决回归问题。如果可能，为此使用持续集成/持续交付 (CI/CD)。如果没有，请制定明确的测试计划，使团队能够尽早并经常以自助方式运行测试序列。对于 Agentforce 客服人员测试，依靠测试中心对具有各种输入的 AI 客服人员进行严格的批量测试，以确保他们在不同场景中正常运行。
• **认识到不是每个更改都需要每种测试。**正如有效的发布漏斗适合高、中和低风险应用程序的路径一样，有效的测试策略也是如此。清楚地为团队概述如何为具有各种风险、用例或复杂性的应用程序选择和遵循适当的测试制度。请参阅环境策略。
• **定义可以在不同的环境类型中执行哪些测试。**对生产的忠诚度是准确测试的关键组成部分，但对于不同类型的测试来说，这意味着不同的东西。例如，回归测试需要在元数据方面忠实于生产，并在一定程度上忠实于数据。确保定义一组给定的测试需要什么样的生产忠诚度，并清楚地分类什么类型的环境可以支持适合不同测试的条件。有关与每种环境类型一致的工作类型的概述，请参阅环境策略。
• **使用耐久性、压力、性能和规模测试来持续衡量应用程序的成熟度。**这些测试显示了与生产级需求相比，应用程序的发布准备程度。对于主要新功能，请在应用程序开发周期中间隔几次运行这些测试。将这些测试仅仅视为一个开发阶段或阶段的一部分，而不是正在进行的任务的一部分是一种反模式。对于团队来说，尽早并经常获得关于应用程序性能的反馈非常有用，这有助于他们更好地了解如果应用程序离生产级就绪的程度。在更改投入生产之前更好地识别和解决问题的能力非常值得频繁运行更复杂的测试来增加复杂性。
  • 了解哪些测试重要。您可能会有固定的时间进行规模或性能测试，因此测试系统的各个方面不切实际。并非所有功能都得到同等使用，并非所有规模瓶颈都会对业务产生同等影响。确保您的规模测试集中在系统中使用率最高和价值最高的部分。定义并了解最重要的业务机会，以验证和改善贵组织的规模和性能。
  • **了解“足够好”是什么样子。**定义规模和性能测试的成功标准至关重要。确保您和您的开发团队将成功标准用作测试基准。此外，确保它们为开发团队构建的功能要求提供信息。通常，这些标准包括支持响应时间小于商定值的特定数量的并发用户，以及您的服务级别目标 (SLO)。定义关键目标条件，然后设计规模和性能测试，以确保满足条件。
  • **确保您有足够的环境。**规模和性能测试需要特别忠实于生产。非生产环境中的数据集、请求人口统计、请求率和工作量特征应尽可能匹配您在生产环境中看到的内容。对于规模测试，您必须使用完全 Sandbox。如果贵组织没有用于规模测试的完全 Sandbox，您无法运行足够的规模测试。
• **确保测试工作负载帮助您衡量非功能需求。**请记住考虑：
  • 测试数据 - 每种测试都应针对与生产隔离的数据执行。在 Apex 单元测试中，实施数据工厂模式，以确保代码生成自己的测试数据，与环境数据隔离。您还可以以各种格式创建和维护测试数据集，以测试数据加载行为，使用基于 UI 的测试数据填充开发环境，并协助集成测试。所有测试数据，无论是作为外部数据集维护，还是通过数据工厂代码按需创建，都应该清除敏感和识别数据。它应包括损坏、不完整和格式错误的数据，以支持消极和边界单元测试行为。
  • 模拟和存根服务 - 对于集成测试，您可以使用模拟和存根服务来模拟 API 响应。Apex 支持一个存根 API 来创建在 Apex 测试中使用的模拟框架。嘲笑创建可用于 Apex 测试的嘲笑框架。模型和存根可以帮助验证系统的数据处理行为，更少地依赖复杂的数据工厂或外部测试数据集。有时，模拟和存根更适合用于生产类流量或数据量不相关的测试。
  • 设备和辅助技术 - 构建引人入胜和可访问的应用程序的关键部分是确保它们在各种设备和不同类型的辅助技术中满足用户的期望。有意义的可用性测试可能需要更多投资和不同类型的专业知识来有效执行，但它是了解面向用户的应用程序在发布时架构如何的重要部分。
  • 模拟器 - 当您需要复制类似生产数量的用户请求、API 流量或网络速度的变化时，您可能需要模拟这些情况的工具。不是每个测试都需要这种投资水平。这些工具通常在可扩展性和性能测试中非常有用。
  • AI 和客服人员测试 - 测试的主要目标是减少 AI 幻觉，这是令人信服的回答是捏造的和不正确的。确保测试 AI 用例，以突出显示由对客户理解不完整、缺少数据、元数据不完整的字段和过时数据导致的常见问题。使用测试中心帮助创建此类测试所需的测试数据。

下表显示了在您的组织中要查找或构建的模式的选择，以及要避免或针对补救的反模式。

在模式和反模式探索器中，发现 ALM 的更多模式。

在安全和站点可靠性工程 (SRE) 中，事件响应侧重于团队如何识别和处理影响系统整体可用性或安全性的事件，以及团队如何努力解决根本原因并防止未来出现问题。事件响应涉及实时解决问题和问题发生后所需的流程、工具和组织行为。

作为架构师，您可能不是每天监控解决方案上线后运营的人员。弹性架构的一部分是设计恢复功能，使支持团队能够执行第一级诊断，稳定系统，并将调查和根本原因缓解有效地移交给开发或维护团队。日常直接支持用户的团队可能对系统的架构没有深刻的理解或专业知识。这些团队必须具备所需的工具和流程来监控日常运营，在诊断潜在事件时从系统中获取信息，并在任何影响可用性的问题上充当有效的第一响应者。

通过关注恢复时间、分类能力以及监控和提醒，您可以提高团队对 Salesforce 解决方案中事件的响应程度。

当事件发生时，第一优先级必须是将系统恢复到稳定的运行状态。通常，企业认为从事件中恢复的唯一途径是“解决问题”。这一假设是公平的，因为准确的根本原因分析和补救是您最终解决系统中关键问题的方式。但是，在危机响应的早期阶段“解决问题”并不是最实际的方法。根据事件的严重程度，每一秒及其影响都可能导致业务的收入或声誉损失。

通常，尝试诊断并解决根本原因会延迟将系统恢复到运行状态的工作。从逻辑上讲，采用要求事件响应者解决根本原因的方法会给贵公司的主题专家 ( SME) 和支持人员带来巨大压力。在事件期间努力寻找并修复根本原因需要中小企业随时待命，这可能会阻止面向客户的一线支持人员采取行动。这也会导致团队发布变更，进而产生更多事件。归根结底,这种方法会增加成本,消耗团队之间的带宽,并导致在危机时出现可能削弱客户 Trust 和品牌声誉的行为。

正确的事件管理模式是确定优先级，并将恢复作为第一步。在系统恢复稳定后，您可以进行无可指责的事后分析、事件调查、根本原因修复和类似活动。这种操作顺序更好地使事件响应人员能够分类、诊断和执行恢复策略，并提醒相关中小企业仅在必要时提供帮助。它还使中小企业能够识别并修复事件的根本原因，而不会感到压力过大。

对事件响应采取恢复优先的思想：

• 建立并实现服务级别目标 SLO。SLO 是您与利益相关者一起为系统的特定非功能要求 (NFR) 制定的标准，例如性能或正常运行时间。这些目标由一段时间内的服务水平指标 (SLI) 来衡量。如果没有 SLO，围绕事件响应和复杂问题故障排除的大部分工作可能会感觉混乱和反应性，例如，促使人们迅速采取行动，“为报告它的一小部分用户停止这一特定的错误”。通常，这种循环会使团队将根本原因分析推向事件响应的更近一步，因为它似乎有助于阻止反应性行为。建立 SLO 和 SLI 是更有效的开始方式。要建立 SLO，请考虑这些问题。
  • **未来 1-3 年系统的 NFR 是多少？**例如，您的 NFR 可能包括您的系统必须能够支持的响应时间、峰值请求率和并发用户。
  • **您希望客户及其用户体验什么？**将 SLO 基于此问题的答案，即“用户可以在 Salesforce 中快速运行报表”。
  • **您可以测量什么,应该在多长时间内测量？**将幻灯片基于此问题的答案。匹配上述示例的 SLI 可能是“在 30 天内测量的平均 n 秒内加载的报表的 x%”。
• **定义并标准化恢复策略。**更改回滚和解决方法实施可以帮助系统再次正常运行，并将事件的影响最小化。文档恢复策略和协议，可由支持或运营团队的适当成员执行。恢复策略因事件类型而异。下一个表显示了将事件类型映射到恢复策略的一般框架。有关识别故障点和定义缓解策略的更多信息，请参阅可用性。

• 定义明确退出标准。使用您的 SLO 来确定您的系统何时没有事件或影响状态。
• **定义事件后审查和根本原因补救的流程。**在服务恢复后，花时间查看事件。在审查期间，采取无怨无悔的方法。与利益相关者合作,专注于确定关于发生什么以及发生方式的明确事实,而不是试图将错误或指责归咎于个人。使用不同的审查格式来检查长期解决问题的方法。
  • 事后审查侧重于对事件的响应。它有助于评估适当的响应流程和策略是否到位。
  • 根本原因分析侧重于事件的根本原因。它可以帮助识别导致事件的系统设计和实施中的任何错误或问题。
• 定期实践商定的恢复协议实践恢复协议，以确保每个人都知道如何很好地处理事件。使用 Sandbox 和测试环境，为团队提供实践事件模拟和恢复的地方。还要练习事件后审查。执行所有这些实践会使恢复成为您的工程和支持文化的一部分。

事件响应模式和反模式显示了在 Salesforce 解决方案中确定恢复优先级的架构。在构建之前，使用它们来验证您的设计，或者确定系统中需要重构的区域。

要了解有关 Salesforce 工具的更多信息，以帮助恢复时间，请参见Salesforce 恢复工具。

在技术环境中，分类包括将类别和严重级别分配给问题和支持请求。无论您的解决方案计划得有多周全，都会出现用户支持问题和请求。这些问题可能源于缺乏足够的培训或变更管理、UI/UX 中的差距、意外的最终用户行为以及没有被监控或提醒发现的紧急系统问题。

支持和运营团队需要能够高效地调查用户支持查询并快速诊断它们。分类问题以筛选出不太严重的问题并快速发现关键系统事件是这些团队的关键能力。糟糕的分类会降低所有级别的用户支持，延长关键事件，并增加进一步中断客户和业务的风险。

虽然您可能没有参与日常运营和支持，但作为架构师，您有责任帮助确保您的支持和运营团队能够有效地分类您在 Salesforce 平台上创建的任何解决方案中的问题。

要使团队能够有效地分类 Salesforce 解决方案中的问题：

• 确保支持团队可以访问有用信息。
  • 记录您的系统和设计模式。确保解决方案的可读性和一致性是使支持人员了解他们负责支持的系统的关键部分。在文档中，请考虑团队如何找到有关如何确定系统不同部分问题或事件的优先级的信息。此外，确保团队可以根据影响区域快速获取有关恢复策略的技术信息。为常见 Agentforce 问题提供相关故障排除指南，例如主题分类和操作选择，这将帮助团队快速分类与权限或配置相关的问题。
  • 设计时请谨记调试。支持团队和组织管理员需要启用调试和诊断，以正确分类各种环境中的用户问题。调试友好模式的示例包括将日志记录和自定义错误消息纳入整个系统的执行路径的模式。通过事件日志和客服人员生成器的推理视图等工具，在常见 Agentforce 调试方法上启用支持团队。
  • 确定事件中小企业和利益相关者。创建相关中小企业或利益相关者的列表，他们应支持从事件中恢复，并应参与事件后分析。
  • 好好对待交接。作为上线的一部分，确保每个解决方案移交给支持或运营团队的质量。为支持人员提供培训，以完成相关系统架构和模拟事件响应演练。考虑事件后的切换，包括团队应如何记录日志或个案备注未捕获的信息，以及事件响应者如何为根本原因调查做出贡献或执行用户验收测试以采取任何补救措施。
• 如果征求您的意见，请将每个人的注意力放在恢复上作为最关注的问题。
  • **快速响应。**快速响应您收到的任何用户支持请求、监控通知和提醒。
  • **帮助区分症状和问题。**确定是否存在需要解决的实际系统事件。尝试识别存在实际问题的组件。帮助确保遵循商定的恢复策略，以使系统快速脱离事件状态。
• 对于支持关键用例的 Agentforce 客服人员，请确保可行的相关解决方法到位，并且作为冗余措施，可以在接到通知后立即启用。示例包括切换到手动处理或重定向到相关文档进行手动审查。

事件响应模式和反模式显示了有效分类的架构在 Salesforce 解决方案中的外观。在构建之前，使用它们来验证您的设计，或者确定系统中需要重构的区域。

要了解有关 Salesforce 工具的更多信息以帮助分类，请参见适用于弹性的 Salesforce 工具。

监控和警报是站点可靠性工程中广泛使用的术语。在系统弹性的上下文中，监控是持续评估系统的当前状态，而警报是自动通知利益相关者有关系统状态的潜在问题。有效的监控和警报是使系统的规模和增长与支持人员的规模和增长脱钩的关键部分。

Salesforce 提供各种内置功能来监视您的系统中的行为。Salesforce 还提供作为加载项或 Salesforce Shield 一部分的实时事件监测。在任何 Salesforce 解决方案中，专为监控和警报设计的设计都提供：

• 自动化事件响应的功能
• 在正确的时间将相关信息发送给正确的用户
• 清除历史视图和趋势分析的信息

要在 Salesforce 解决方案中构建有效监控和警报的架构：

• 优先考虑自动化。虽然通知用户关键状态更改是保持系统稳定运行的关键部分，但在理想架构中，系统会在可能时自行更正问题，并仅针对不可恢复的紧急问题发送警报。即使没有自我纠正功能，自动化也可以使您的提醒和报告更加有用。
  • **从 Salesforce 已经提供的内容开始。**Salesforce 平台会为您提供相关日志和 API，以监控解决方案在调控器限制方面的操作。此外，平台会发送违反调控器限制和类似问题的警报。使用这些日志和警报作为基础，探索更完全自动化系统自我恢复、事件报告和警报的方法。例如，您可以实施监控日志的自动化，然后在记录特定类型的事件时采取恢复操作。
  • **以可预测的方式对系统状态的更改进行分类。**为您想要监控和报告的关键州/省创建特定、有意义的类别。将这些类别与您为管理应用程序组件中的状态而定义的类别对齐。对于如何处理状态更改信息，采用面向 API 的思维方式。一致的消息格式和状态类别简化了自动化、报告和提醒。
  • **将自动化逻辑与系统的其他部分保持一致。**如果您已构建适当的自动化错误处理，您可以将这些模式扩展到如何分类状态更改并使用自动化进行响应。对于视为可恢复的状态更改，您可以自动重试行为。对于被视为关键或致命的状态更改，自动向用户发出警报。
• 避免制造噪音。当用户收到太多警报时，特别是不需要采取任何操作的警报，他们倾向于开始禁用或忽略所有警报。这种情况破坏了创建有用提醒的任何努力。为了更好地确定谁收到警报、什么触发警报以及何时触发警报，请考虑执行以下操作。
  • 构建相关方地图。要确保您的系统在正确的时间向正确的利益相关者提供正确的提醒，请先确定和分类您的利益相关者群体。
  • 基于用户权限路由消息。仅向有能力和权限响应的收件人发送警报。业务用户可能会从有关问题的提醒中受益，这些问题可以通过更正他们有权访问的记录中的问题来修复。如果问题需要更复杂的技术响应，应向支持人员发出警报。
  • 明确预期响应。仅在需要人为干预的情况下发送警报。构建消息，以清楚地指示期望收件人采取的操作。如果您确实向利益相关者发送了警报以获得可见性，并且不需要他们采取任何行动，请在他们收到的消息版本中清楚地说明这一点。
  • 及时发出相关提醒。针对已发生且仍需要补救的故障而提供的警报）不如关于潜在故障的警报有用。理想情况下，一旦系统中出现问题,支持人员就会收到警报,从而有机会在问题对业务运营产生负面影响之前对其进行分类。

模式和反模式列表显示了 Salesforce 解决方案中有效监控和提醒的架构。在构建之前，使用它们来验证您的设计，或者确定系统中需要重构的区域。

要了解有关用于监控和提醒的 Salesforce 工具的更多信息，请参见适用于弹性的 Salesforce 工具。

此表显示了要在贵组织中查找或构建的模式选择，以及要避免或针对补救的反模式。

✨ 在模式和反模式探索器中，发现事件响应的更多模式。

业务弹性的一个关键是连续性规划，它侧重于如何使人员和系统能够应对计划外事件引起的问题。业务连续性计划 (BCP) 从以人为本的角度看待如何让流程在危机中继续前进。连续性计划的技术方面包含在 BCP 的灾难恢复部分中。请参阅技术连续性。

如果没有适当的连续性计划，您的组织现在可能知道如何在危机或系统停机期间采取行动，因此根本不采取行动。无效的连续性规划会对客户、利益相关者和业务产生灾难性的影响。在发生不利事件后，没有维护或恢复关键流程的每一刻都有可能遭受财务损害、声誉损害、员工安全，甚至监管合规。

您可以通过将精力集中在三个方面来为系统构建更好的连续性规划：定义 Salesforce 的业务连续性、规划技术连续性以及构建备份和还原功能。

您的公司可能已经有 BCP。如果是，请确保 Salesforce 包含在其中。如果您的公司没有 BCP，请与利益相关者合作，创建一个涵盖您的 Salesforce 组织的 BCP。

Salesforce 通常被依赖为许多业务部门的客户数据和基本业务流程的真实来源。因此，Salesforce 在 BCP 中扮演的角色可能与其他系统扮演的角色不同。Salesforce 很可能会参与许多高优先级的恢复领域。

要为 Salesforce 系统创建相关业务连续性规划：

• 澄清恢复的优先级。与事件响应的一般方法一样,恢复需要成为系统在危机时刻的第一优先事项。许多关键业务服务在 Salesforce 中运行并与 Salesforce 一起运行。您必须帮助利益相关者确定恢复各种业务功能和功能的正确优先级。一般框架可以是：
  • 稳定基本业务基础设施。
  • 稳定客户服务。
  • 稳定员工和合作伙伴服务。
• **在您的 BCP 中考虑您的生态系统。**Salesforce 不是您环境中的唯一系统。请确保您在 BCP 中找出与 Salesforce 集成的系统、从 AppExchange 供应商安装的解决方案以及与 Salesforce 中的数据或流程连接的任何其他系统之间的差距。如果您的交付能力取决于供应商，请询问这些供应商他们的连续性计划。评估他们的功能，并计划如何保持系统可用。
• **将 BCP 问题集成到测试策略中。**为您的 BCP 创建测试计划并执行它们。测试 BCP 中与流程或人员相关的区域尤其重要，因为这些区域通常会被忽略。将 BCP 中的相关项目纳入整体 ALM 测试策略。创建并遵循维护计划，以审查测试，并确保计划保持最新。

模式和反模式显示了 Salesforce 解决方案中正确和糟糕的连续性规划。在构建之前，使用它们来验证您的设计，或者确定系统中需要重构的地方。

要了解有关用于定义业务连续性的 Salesforce 工具的更多信息，请参阅适用于弹性的 Salesforce 工具。

技术连续性的目标是确保系统中的组件问题不会阻止业务维护基本操作。Salesforce 优先考虑将我们的服务保持在最高的可用性水平，并提供有关任何问题的透明信息。您可以在Trust.salesforce.com上看到有关 Salesforce 系统性能和问题的实时信息。作为构建在 Salesforce 上的架构师，您的解决方案受益于 Salesforce 在整个平台中提供的可靠性、安全性和性能功能。

但 Salesforce 解决方案的整体连续性不仅限于 Salesforce 提供的内置服务。从架构的角度来看，Salesforce 技术连续性规划必须首先提出和回答有关 Salesforce 如何融入更大的企业环境的问题。哪些类型的系统集成了 Salesforce？外部系统如何依赖于 Salesforce 中的进程或信息？在 Salesforce 组织中，哪些流程或功能依赖于 AppExchange 解决方案？您的用户是通过第三方身份服务或 SSO 访问 Salesforce 吗？

要在 Salesforce 系统中建立更好的技术连续性：

• **评估基础设施。**对于技术中断或问题，最常见的补救策略是构建冗余服务或系统，您可以在事件期间重新使用。在 Salesforce 中，我们有一个有意冗余的架构，这意味着我们在不同的物理位置维护客户的系统和服务副本。我们使用几种灾难恢复技术，包括站点交换，这使我们能够在需要时将用户流量从一个数据中心引导到另一个数据中心。要确定您可能需要在何处构建有意冗余，请自问这些问题。
  • [X] 服务的服务中断期间会发生什么？我们可以从该服务切换到另一个服务吗？
  • 恢复 [X] 需要多长时间？对我们的客户有什么影响？对我们的合作伙伴有什么影响？对内部团队有什么影响？
  • 备份及其频率如何？备份能否提供支持业务所需的数据？
  • 我们是否依赖于供应商？他们的 BCP 计划是什么？
• **提供运营支持。**运营支持是让团队尽快恢复并运行。请仔细考虑您的系统如何处理意外变化带来的容量要求和需求的显著增加，包括行业范围、区域范围或全球范围的变化。请确保您的 BCP 考虑了站点可靠性工程 (SRE) 或支持团队有效响应事件可能需要的额外资源或打破常规的程序。有关运营支持的问题包括：
  • 在停机时，我们的技术团队是否拥有继续工作所需的工具？我们是否模拟停机来验证计划或找出差距？
  • 如果灾害发生在特定地区，我们是否有该地区的承保计划？
  • 我们的客户是否全球化？它们是否全天候运行？
  • 我们是否有适当的监控和提醒，以便在出现故障时通知适当的个人？
• **自动化并测试恢复策略。**解决问题后，确定问题发生的位置和修复方式。如果您可以，根据补救措施，自动化您的恢复策略并调整任何流程问题。许多公司为测试系统弹性的服务子集安排事件模拟。例如，模拟系统管理员帐户被锁定或泄露，或者模拟 AppExchange 提供商的中断或问题。请参阅事件响应。)有关测试和自动化如何帮助您更快地恢复服务的问题包括：
  • 我们多久计划和运行一次事件模拟？
  • 我们是否知道将服务恢复到稳定状态需要多长时间？
  • 我们是否有稳定的交付流程？
  • 我们是否知道在哪里可以自动化故障切换和恢复？

像对待其他开发项目一样对待来自事件后审查的任何项目。将它们添加到您的计划系统中，以便您可以确定它们的优先级并加以处理。

模式和反模式显示了 Salesforce 解决方案中正确和糟糕的技术连续性规划。在构建之前，使用它们来验证您的设计，或者确定系统中需要重构的地方。

要了解有关适用于技术连续性计划的 Salesforce 工具的更多信息，请参阅适用于弹性的 Salesforce 工具。

恢复数据或元数据的备份副本有助于将贵组织恢复到上次已知的稳定状态。它还可以在灾难性系统故障或服务中断期间提供故障切换系统。定期备份您的数据和元数据，并将加密的备份副本存储在安全的位置，这将为您的架构增加一层弹性。

如果没有备份和还原策略，当生产数据和元数据被恶意损坏时，当缺陷无意中进入生产环境时，或者当大量数据加载期间的故障损坏生产数据时，您无法还原干净版本的生产数据和元数据。其中任何一种情况都可能导致业务关键型生产数据损坏，甚至永久丢失。除了连续性规划之外，设置备份和还原技术还具有一些优势，包括帮助制定减少大量数据的策略，并遵守与合规性相关的保留策略。

为了帮助确保 Salesforce 解决方案中备份和还原策略的连续性：

• **开始吧。**制定好的备份和还原策略的第一步是首先制定策略。即使是像对贵组织的所有数据和元数据进行夜间备份这样简单的事情，也可以避免您的业务在灾难期间丢失重要信息或功能。
• **限制对备份的访问权限。**系统管理员是唯一有权访问数据备份副本的用户。该访问权限限制使业务用户无法查看他们在贵组织中无权查看的备份副本中的记录。
• **定期测试还原过程。**无论您实施哪种备份和还原策略，请定期在完全或部分复制 Sandbox 中测试还原过程，以确保在需要时它正常工作。
• **使备份和还原策略与数据归档策略保持一致。**确定在将记录归档或从系统中清除时，备份或归档中应执行的操作。请参阅数据量）。

如果您的数据量非常大，以至于完全备份在下一次备份开始运行之前没有时间完成，您可能需要更精细的备份策略。如果贵组织的数据频繁更改，更新对贵组织至关重要，您可能还需要更精细的备份策略。

要使备份策略更加精细：

• **将备份范围限定到特定对象。**此策略涉及以不同的时间间隔备份来自不同对象的记录。请记住，子对象必须与父对象以相同的时间间隔备份，以保持数据的一致性。
• **时间盒****部分备份**。此策略包括区分完全备份（所有数据和元数据）和部分备份（仅元数据和自上次备份以来添加或更改的记录）。

*请勿停止执行完全备份。重要的是要注意，您永远不要完全消除完全备份，即使数据量会导致长时间运行。对于大数据量，计划定期但不常见的完整备份（例如，每周备份）。还要计划更频繁的部分或特定于对象的备份（例如，夜间备份或每 X 小时备份一次）。此方法可让您灵活地重建最完整和准确的数据集，以在还原过程中使用。*

连续性计划模式和反模式显示了 Salesforce 解决方案中正确和差劲的备份和还原功能。在构建之前，使用它们来验证您的设计，或者确定系统中需要重构的地方。

Salesforce 备份和恢复是一个集成的 Salesforce 解决方案，它包括从 Own 收购中进行的 Own 恢复，可以保护重要数据不丢失或损坏。我们高度安全、易于设置、始终可用的解决方案确保了业务连续性和数据弹性，并简化了合规性。

使用 Salesforce 备份和恢复来防止数据丢失，从数据事件中快速恢复，并简化您的整体数据管理策略。您可以为高价值和受监管的数据创建备份策略，并只需几次单击即可恢复该数据。

每日自动备份会保护所有重要组织数据，包括元数据、Sandbox、受管软件包数据、文件附件等。根据需要随时运行备份，以实现恢复点目标 (RPO) 并保护您的部署。备份始终可以安全和合规地访问和存储。连续数据保护还可用于甚至更敏感或更事务性的数据，允许更快地恢复快速变化的重要信息。

通过直接发送到电子邮件的主动警报，检测异常数据活动、数据丢失和损坏。接收实时警报，以识别统计异常值或创建通知您异常数据活动的规则，从而帮助您比以往更快地检测事件。

Salesforce 备份和恢复通过提供对更改的精细可见性来加快恢复，从而可以快速识别和恢复受影响的数据。可视化图表等工具会突出显示不需要的更改，而易于使用的恢复功能会精确恢复受影响的对象、字段和记录。

我们的工具使您能够使用备份进行分析、审计和合规，并提供可搜索的历史数据、用于查看过去数据的开放搜索功能以及用于外部分析或仓储的导出功能。这将重新调整备份的目的，而无需额外的 Salesforce API。

备份和恢复提供了单个控制台来整合所有备份、管理、操作和合规性。此控制台允许您访问、管理、自定义和监控所有生产组织和 Sandbox 的备份。通过它，您还可以执行数据主体请求来确保备份数据的合规性，并完全控制自定义备份计划、频率和保留策略。

• 减轻数据事件的影响。Salesforce 备份和恢复通过使用户能够将受影响的记录恢复到事件发生前的状态，帮助缓解数据事件，例如网络攻击或恶意的内部或外部活动。备份和恢复的导出功能保证了对用户关键数据的连续访问和可用性。
• 防止永久数据丢失。人为错误仍然是数据丢失的主要原因。备份和恢复为这些错误提供了精确快速的解决方案。
• 更轻松地满足数据合规性和法律要求Salesforce 备份和恢复支持共享责任模型，为备份数据中的批量忘记或数据更正启用自助功能。

要了解有关备份和还原的 Salesforce 工具的更多信息，请参阅适用于弹性的 Salesforce 工具。

此表显示了要在贵组织中查找或构建的模式选择，以及要避免或针对补救的反模式。

✨ 在模式和反模式探索器中，发现连续性计划的更多模式。

帮助我们保持 Salesforce 良好的架构与您相关；参加我们的调查，以提供有关此内容的反馈，并告诉我们您接下来想要看到的内容。