可靠性 - 灾难恢复模式


了解有关架构良好的可靠性的更多信息 → 灾难恢复和业务连续性

模式

何处查看好样的
数据备份策略✅ 使用数据导出服务或专用备份和恢复服务（例如 Own）每周或每月自动导出。导出频率匹配 RPO 要求。必要时，将关键对象数据导出到外部对象存储。
元数据备份策略✅ 使用 Salesforce DX 源格式在 Git 中版本化的所有元数据。元数据更改仅从源控制部署。CI/CD 漏斗可以从存储库重新创建任何环境。通过 Git 历史记录提供的时间点恢复。
文件备份策略✅ ContentVersion 记录、附件和文档按计划导出到外部存储。满足监管保留要求的自动文件导出。外部归档系统，适用于早于业务运营需求的文件。
备份验证✅ 每季度将演练恢复到完全 Sandbox 或开发人员环境。Runbook 中记录的还原过程，以及逐步说明。测试还原会在灾难发生前验证备份的完整性和完整性。
恢复测试时间表✅ 每季度进行部分还原测试（元数据、特定对象、文件子集）。具有完整环境恢复的年度完全恢复演练。每次测试后，都会记录经验教训并更新运行手册。
第三方备份服务✅ 具有时间点还原功能的自动备份。定义 RPO/RTO 的服务级别协议。备份完成的每日自动验证。备份存储在多个区域的地理冗余。
自定义对象和字段✅ 计划的数据导出服务运行中包含的自定义对象，公式和累计汇总字段值被重新计算，而不是导出（没有存储的值可以提取），文件或附件二进制文件通过单独的导出路径进行处理。在还原顺序中记录和测试的复杂字段类型和查找关系。
文件和附件✅ ContentDocument 和 ContentVersion 对象使用文件二进制文件导出。备份的文档库包括文件夹结构和权限。导出的文件维护关键文档类型的版本历史。
Sandbox 刷新策略✅ 生产组织每季度刷新为完全 Sandbox，以进行负载测试和灾难恢复验证。Sandbox 刷新用作还原程序测试。刷新后应用的数据掩码保护测试环境中的敏感数据。
备份监控和提醒✅ 在计划备份失败或延迟时自动提醒。显示备份作业成功率、完成时间和数据量趋势的仪表板。超过可接受延迟窗口的备份故障的随叫随到升级。

反模式

何处查看什么不好的样子
备份策略未配置自动备份，仅依赖平台基础设施备份。第三方备份服务已配置但未测试 - 备份可能已损坏或不完整。备份依赖于手动 Data Loader 导出（执行不一致、覆盖范围不完整、没有自动化）。
元数据版本通过更改集部署的元数据更改，无需源控制。元数据历史没有 Git 存储库。时间点恢复不可能 - 在破坏性更改后，无法恢复上一个已知良好的配置。
备份验证已配置但从未恢复到测试环境的备份。第一次还原尝试发生在实际灾难期间，显示了不完整的范围或损坏的归档。备份过程已记录，但未由备份人员测试。
备份范围假设当公式和累计汇总字段值从不导出（动态重新计算，不存储）并且文件或附件二进制文件需要单独处理时，数据导出服务会捕获所有内容，从而仅在还原时发现差距。
恢复程序恢复 Runbook 包含 2 年前架构中的过时步骤。由一位专家测试的恢复程序，该专家后来离开了公司。手动程序复杂到在压力下执行容易出错。
备份频率在业务需求为 24 小时 RPO 时，每周备份关键交易数据。备份频率与业务关键度不一致 - 所有数据的备份计划相同，无论重要性如何。由于缺乏监控和警报，错过了备份计划。
法规遵从性备份保留时间比管理法规要求更短。例如，HIPAA 合规文档（保单、风险分析、BAA、违约记录）在其 6 年 §164.316 保留前清除，或 SOX 监管的财务审计记录在其 7 年保留前删除。审计期间发现的合规性差距。
文件存储存储在 Salesforce 中的大文件，没有归档策略。文件存储增长，直到组织接近限制。ContentVersion 记录没有备份 - 如果组织损坏，文件会丢失。依赖用户维护关键文件的个人副本。
Sandbox 测试完全 Sandbox 从未从生产环境中刷新 - 测试环境与生产环境完全不同。Sandbox 中的数据量是生产的 1%，阻止了现实的还原验证。Sandbox 刷新被视为不方便，而不是灾难恢复验证机会。
监视⚏ 备份作业以静默方式失败，并且没有警报。几周后在灾难期间发现备份失败，此时需要备份。没有显示备份作业成功趋势的仪表板。仅在发票到达时监控备份服务运行状况。
加密密钥将 Shield 加密的数据视为安全，而不保护密钥材料：仅轮换密钥会使先前的数据保持不变，但销毁租户密码（加密粉碎）或丢失自带密钥或仅缓存密钥材料会使加密数据永久无法恢复。恢复程序中省略了密钥管理。
跨组织依赖性当解决方案依赖于连接的应用程序、外部集成或 SSO 时，单独备份主要组织：连接的应用程序密码、命名凭据和 OAuth 授权以及外部身份验证令牌不会被数据和元数据还原保留，必须在恢复的组织可以验证外部系统之前重新配置和重新授权。当外部 SSO 是唯一的登录路径时，不可用的身份提供商会阻止登录，甚至阻止登录完全恢复的组织。

模式

何处查看好样的
恢复时间目标 (RTO) 定义✅ RTO 按业务能力定义，而不是在整个组织中统一。收入关键型操作：几分钟到 1 小时。面向客户的服务：1-4 小时。内部工具：4-24 小时。历史报表：天数。经业务相关方批准的 RTO。
恢复点目标 (RPO) 定义✅ RPO 基于每个功能的可接受数据丢失定义。财务交易：近零 RPO（秒，事件驱动的异步复制）。客户记录：接近零（通过 CDC 的分钟数）。Analytics 数据：小时（计划同步）。临时工作流状态：天数（无需复制）。
团队可用性和角色✅ 所有重要角色的主要和后备人员都有记录。operational Knowledge 中没有单点故障。定义主要响应者、第一个备份、第二个备份的升级树。当 Salesforce 不可用时，可以访问系统中维护的联系信息。
来文程序✅ 事件通信计划定义谁通知用户、客户、管理人员。托管在 Salesforce 外部的外部状态页面，用于在平台停机期间进行用户通信。当主要通信工具不可用时，适用于随叫随到团队的短信通知系统。记录的升级时间范围（何时从团队升级到经理到主管）。
供应商依赖性映射✅ 所有重要的外部供应商都有文档记录，包括 Salesforce、集成合作伙伴、ISV 软件包提供商。记录了供应商 SLA 和支持窗口（全天候与仅限工作时间）。记录了供应商升级联系人和程序。为关键依赖性确定的替代供应商选项。
监管通知义务✅ 每个行业（金融服务、医疗保健、政府）记录的强制性事件通知要求。为匹配每个治理条例的所需窗口而定义的通知时间范围。定义谁向哪些监管机构提交通知的责任矩阵。为快速监管通知准备的模板。
业务影响分析✅ 每个业务能力按收入影响、用户影响和监管风险排名。基于业务影响排名的恢复优先级。分配给灾难恢复的资源与业务关键度成正比。随着业务优先级的变化，每年审查影响分析。

反模式

何处查看什么不好的样子
RTO/RPO 定义在没有可衡量的 RTO/RPO 目标的情况下，“系统应该可靠”。由 IT 团队定义的 RTO/RPO，无需业务相关方输入。所有功能的统一目标会忽略关键程度差异 (“所有功能都需要99.999%的正常运行时间”)。
团队就绪单个 Salesforce 管理员了解灾难恢复过程，无需文档或备份人员。随叫随到的轮换包括从未执行恢复程序的人员。主要响应人员在灾难期间不可用（休假、生病、离开公司）。
通信计划没有通信计划 - 发现需要在事件已经发生时通知用户。Salesforce 本身托管的状态页面在 Salesforce 停机期间不可用。尝试恢复时通知主管的等待时间。
供应商依赖性⚏ 在发生灾难之前，不了解供应商 SLA 条款，并期望供应商提供全天候支持，并且仅提供工作时间服务。没有记录的供应商升级联系人。恢复需要 ISV 软件包提供商，但公司不再经营。
监管要求⚠ 不知道强制性违反通知法律。在 48 小时后发现 24 小时通知要求。未准备模板 - 在事件响应期间起草监管通知，同时合规时间紧迫。
恢复优先级尝试在灾难期间同时恢复所有功能，而不是优先考虑收入关键型操作。在解决面向客户的订单系统之前，花费 8 小时恢复内部报告功能。
测试和演练⚏ 业务连续性计划从未通过演练测试。假设文档化的过程将在没有验证的情况下在压力下工作。尽管在实际灾难期间花费了几天时间从未发现的问题中恢复，但由于“时间不足”而避免了桌面练习。
Knowledge 转移灾难恢复 Knowledge 集中在一个没有文档的高级架构师身上。新团队成员未接受灾难恢复培训。假设每个人都知道灾难期间该做什么，而没有明确的训练或演练。
假设验证恢复过程假设备份可在 15 分钟内访问，但从冷库检索备份需要 8 小时。假设团队在 30 分钟内可用，但未定义随叫随到的轮换或升级程序。基于从未通过测试验证的乐观假设的恢复时间估计。

模式

何处查看好样的
RTO 架构调整✅ 架构决策与 RTO 承诺相匹配。分钟 RTO 需要自动故障切换和热备用。小时 RTO 需要脚本恢复和温暖待机。RTO 接受从冷备份手动恢复的天数。在业务无法证明复杂性的情况下，避免过度工程。
RPO 复制策略✅ 复制方法匹配 RPO 目标。近零 RPO：每次记录保存时通过平台事件异步事件流（传播延迟秒数，至少交付一次）。分钟 RPO：更改数据捕获异步复制。小时 RPO：计划批量 API 提取。天数 RPO：按固定计划手动备份。
RTO 测试✅ 在定时条件下测试的恢复程序。灾难恢复演练期间测量的实际 RTO。目标 RTO 与已实现 RTO 之间的差距已查明并得到解决。RTO 可由备份人员实现，而不仅仅是主要专家。
RPO 验证✅ 恢复测试期间测量的数据丢失。实际 RPO 与演练期间的目标比较。在生产中持续监控复制滞后。复制落后于 RPO 承诺时配置的警报。
特定于功能的 RTO/RPO✅ 不同的业务能力有不同的 RTO/RPO 目标，反映了业务的重要性。电子商务订单流：15 分钟的 RTO，接近零的 RPO（证明了多组织主动-被动的合理性）。内部Knowledge库：8 小时 RTO、24 小时 RPO（证明需要手动从备份还原）。
成本效益分析✅ RTO/RPO 目标与实施成本平衡。更严格的目标要求投资呈指数增长。记录的业务个案表明停机成本证明灾难恢复投资是正确的。年度审查确认投资与业务价值之间的一致性。
SLA 对齐✅ 解决方案 RTO/RPO 目标考虑平台 SLA 基准。解决方案只能提供比多组织架构的平台基准更好的 RTO。将平台功能作为基础的现实目标集。
监控恢复功能✅ 持续监控备份币种（备份帐龄与 RPO 目标）。当备份落后于计划时发出警报。自动验证恢复基础设施（辅助组织、外部存储）是否正常运行。
自动恢复与手动恢复✅ 激进的 RTO 目标（分钟）需要自动化故障切换，人为干预最少。管理 RTO 目标（小时）允许通过人为启动进行脚本恢复。放宽的 RTO 目标（天数）接受按照记录的程序进行手动恢复。

反模式

何处查看什么不好的样子
不切实际的目标⚠ 承诺 15 分钟的 RTO，手动恢复程序需要 4 小时执行。在没有同步复制基础架构的情况下有望实现零 RPO。由 IT 部门制定的 RTO 目标，无需架构支持。
架构未对齐30 分钟的 RTO 承诺，但没有完全手动的自动故障切换和恢复程序。零 RPO 承诺，但仅配置每日备份。攻击性目标，没有相应的自动化和冗余投资。
未测试的目标⚏ RTO 从未通过定时灾难恢复演练验证。假设 2 小时 RTO 可实现，但在时间限制下从未实际恢复。在实际灾难期间发现记录 4 小时 RTO 实际需要 18 小时。
统一目标⚏ 所有功能都分配了相同的 RTO/RPO，无论业务关键程度如何。内部批处理报告系统专为“五个 9”的可用性而设计，而收入关键的电子商务具有相同的目标。对非关键功能的大量过度投资以及对关键系统的投资不足。
忽略依赖性RTO 仅假设 Salesforce 组织还原，但解决方案依赖于外部身份提供商也不可用。RPO 假设数据备份充足，但集成凭据和配置未备份。恢复时间估计会忽略恢复依赖系统的时间。
复制差距⚠ 承诺 15 分钟的 RPO，但变更数据捕获仅为 12 个关键对象中的 3 个配置。配置了平台事件复制，但没有监控事件传递延迟。复制基础架构损坏，在灾难发生前几周内无人发现。
成本无知⚠ 承诺“五个 9”的可用性，而不了解实施成本。在没有成本效益分析的情况下制定的 RTO/RPO 目标。企业不愿意为已经向客户承诺的目标所需的基础设施提供资金。
静态目标尽管业务增长和优先级不断变化，但 5 年前定义的 RTO/RPO 从未重新评估。随着解决方案的发展和重要性的变化，目标保持不变。缺少年度审查过程。
文档缺口架构文档中记录的 RTO/RPO 目标，但未传达给业务利益相关者。业务不了解承诺的恢复功能。当业务预计 1 小时恢复，但架构仅支持 24 小时 RTO 时，发现了差距。
假精度在监控基础设施无法测量到该精度时，承诺“99.97% 的可用性”。当基础分析是粗略估计时，以虚假精度定义的目标表明其严格性。
监控缺勤⚏ 没有持续监控恢复功能。备份落后于计划 2 天，违反了 RPO 承诺，但没有警报。主动-被动架构中的次要组织未接收复制更新，但未配置健康检查。
不执行的计划⚠ 美丽的灾难恢复计划，具有积极的 RTO/RPO 目标，但没有自动化、测试或验证的程序。为满足合规性复选框而创建的计划，但承诺背后没有操作现实。

模式

何处查看好样的
数据冗余✅ 平台自动提供基础设施备份。当业务需要更快的恢复时，应用程序级复制是对平台备份的补充。变更数据捕获或平台事件将关键数据连续复制到辅助存储。复制支持从基础架构备份无法解决的逻辑损坏或配置错误中恢复。
应用程序冗余✅ 在单个事务失败后生存的无国籍应用程序逻辑。没有阻止水平缩放的服务器端状态。自定义元数据类型和配置的自定义设置在所有应用程序服务器中立即可用。任何应用程序服务器都可以处理任何请求，而无需依赖于特定的服务器状态。
集成冗余✅ 断路器模式检测失败的集成。当外部系统不可用时，平台事件会将请求排队，而不是阻止用户操作。与面向用户的功能隔离的外部系统故障。为重要集成确定的多个外部供应商选项，可在供应商停机期间快速切换提供商。
关键工作负载的多组织模式✅ 主动-被动模式：主要组织为所有流量提供服务，次要组织同步但空闲，主要区域停机期间故障转移。主动-主动模式：两个组织持续为生产流量提供服务，用户按地理位置或业务部门分配。多组织仅在业务需要超出平台功能的 RPO/RTO 时成立。
多组织数据同步✅ 变更数据捕获为关键数据提供近乎实时的复制(15 分钟 RPO)。平台事件为关键事务提供事件流（近零 RPO）。参考数据的批量 API 2.0 计划复制（可接受 24 小时 RPO）。在两个组织中修改相同记录时，为主动-主动定义的冲突解决策略。
多组织主动-被动架构✅ 美国东部地区的主要组织为所有生产流量提供服务。欧洲地区的次要组织通过 CDC 同步，但闲置。DNS 路由或身份验证层将用户定向到活动组织。当主要组织连续 10 分钟不可用时，自动健康检查会触发故障转移。
多组织主动-主动架构✅ 根据用户简档区域字段，EMEA 用户在欧洲组织，AMER 用户在美国组织。共享参考数据（客户、产品）的双向复制。区域数据保留在各自的组织中（订单、个案）。冲突解决使用与客户主数据区域权威机构的“最后写入-赢得”权限。
地理分布Hyperforce 区域数据中心支持地理分布。单区域部署，平台受管冗余，可用性高达 99.9%。跨区域的多组织仅考虑 99.95% 以上的要求或监管数据驻留要求。
外部系统冗余✅ 关键外部 API 具有主要和故障转移端点。当主要电路遇到持续故障时，断路器切换到故障切换端点。对于关键集成，地理位置冗余的外部服务优先于单区域提供商。
基础设施监控✅ Trust.salesforce.com 通过状态 API 监控。订阅特定于实例的状态通知。解决方案通过减少降级期间的非关键负载来动态响应平台运行状况。规模中心会在影响冗余容量之前识别资源密集型操作。
故障切换自动化✅ 对于激进的 RTO 目标，自动故障切换优先于手动故障切换。健康检查每 1-5 分钟运行一次，以检测故障。故障转移决策逻辑避免误报（需要持续故障，而不是暂时错误）。如果故障转移目标也不健康，则自动回滚。
单点故障✅ 架构审查识别所有单点故障。评估每个已识别的 SPOF 的业务影响和缓解成本。通过冗余缓解了高影响力的 SPOF。低影响 SPOF 已接受，并有文件记录的风险接受和恢复程序。
测试冗余功能✅ 计划的故障切换演练验证自动故障切换逻辑。在负载下测试的备份系统（不仅仅是空闲的暖备）。在主动-被动测试期间，验证次要组织容量以处理生产负载。从每个测试中吸取的经验教训提高了自动化程度和程序。

反模式

何处查看什么不好的样子
单点故障⚏ 整个解决方案取决于单个外部 API，没有回退。自定义域提供商是 SPOF - 如果提供商失败，用户无法访问 Experience Cloud。单个集成用户帐户 - 如果禁用，所有集成都会失败。
未经测试的冗余多组织主动-被动架构已配置，但从未测试。次要组织不同步，但未配置健康检查。第一次故障切换尝试发生在实际灾难期间，表明次要组织损坏或无法正常工作。
数据同步差距主动-被动多组织，为 30 个关键对象中的 5 个配置了 CDC 复制。发生故障转移，但次要组织缺少 80% 的所需数据。复制滞后监控缺失 - 次要组织落后于主要组织 3 天，但没有警报。
假冗余假设两个组织实际托管在同一 Hyperforce 区域时采用多区域架构。实际使用相同上游提供商的“冗余”外部 API。多个集成路径，所有路径都通过相同的单点故障。
有状态架构应用程序逻辑取决于阻止水平缩放的内存状态。单个应用程序服务器保持所有用户会话状态 - 服务器重新启动会注销所有用户。缓存在应用程序内存中的静态资源，而不是平台缓存，会在服务器之间造成不一致。
无断路器外部集成失败，每个事务会等待完整的 120 秒超时。当单个外部系统不可用时，所有用户都会受到影响。无故障隔离 - 一个失败的集成会降低整个平台性能。
仅手动故障切换⚏ 多组织架构，仅包含手动故障切换程序。在业务停机时，需要 2 小时的程序来启动故障切换。未实施自动健康检查。故障切换决策需要主管批准，以延迟恢复。
容量规划失败主-被动架构中的次要组织，大小为生产负载的 20%。故障转移会发生，但次要组织无法处理完整的生产流量。两个组织都处于 85% 容量的主动-主动架构，在一个组织出现故障时不会留下冗余。
配置偏差主要和次要组织会随着时间的推移而有所不同，因为部署不同步。部署到主要而非次要的元数据。故障转移显示运行 6 个月代码版本的次要组织。
过度工程⚏ 具有主动-主动复制的多组织架构，适用于 5 人使用的内部管理工具。多组织的运营复杂性，无法用业务关键度来证明。批处理报告的可用性目标为99.999%，可接受率为99%。
地理上的误解假设 Hyperforce “multi-region” 自动提供多组织功能。不理解单个组织总是在单个区域中，而多区域需要多个组织。基于地理位置的冗余对于单组织架构是不可能的。
集成耦合所有集成同步，没有异步回退。外部系统不可用会阻止用户操作。无队列机制 - 如果外部系统暂时停机，事务会失败。在支持集成不可用时，用户无法继续。