| 临时组织 | Developer Sandbox | Developer Pro Sandbox | 部分复制 Sandbox | 完全 Sandbox | |
|---|---|---|---|---|---|
| 支持组织形状 | 是 | 没有 | 没有 | 没有 | 没有 |
| 支持源跟踪 | 是 | 是 | 是 | 没有 | 没有 |
| 寿命 | 1–30 天 | 手动控制 | 手动控制 | 手动控制 | 手动控制 |
| 刷新间隔 | 不可用 | 1 天 | 1 天 | 5 天 | 29 天 |
| 发布预览支持 | 开发人员控制 | 基于 Sandbox 实例 | 基于 Sandbox 实例 | 基于 Sandbox 实例 | 基于 Sandbox 实例 |
| 配置时间 | > 5 分钟 | 小时或天 | 小时或天 | 小时或天 | 小时或天 |
| 元数据确定人 | 源控制 | 生产 | 生产 | 生产 | 生产 |
| 数据确定人 | 手动数据加载 | 手动数据加载 | 手动数据加载 | Sandbox 模板 | 生产 |
| 数据限制 | 200 MB | 200 MB | 1 GB | 5 GB | 与生产相同 |
| 任务 | 组织形状 | 源跟踪 | 频繁刷新 | 发布预览支持 | 来自生产的所有元数据 | 来自生产的部分元数据 | 来自生产的大型数据集 | 来自生产的部分数据集 | 兼容的环境 |
|---|---|---|---|---|---|---|---|---|---|
| 原型 | X | X | X | X | X | X | X | 临时组织、Developer 和 Developer Pro Sandbox | |
| 新功能调查或概念验证开发 | X | X | X | X | X | X | X | 临时组织、Developer 和 Developer Pro Sandbox | |
| 用户验收测试 | X | X | X | X | X | X | Developer、Developer Pro 和 Partial Copy Sandbox | ||
| 性能和规模测试 | X | X | X | 完全 Sandbox | |||||
| 用户培训 | X | X | X | X | X* | X | Developer Pro、部分复制和*完全 Sandbox | ||
| *如果需要完成特定类型的工作，否则使用资源密集度较低的环境 | |||||||||
| 模式 | 反模式 | |
|---|---|---|
| 版本管理 | 在生产中：
- 元数据显示了稳定发布机制的使用情况，例如： -- 元数据被组织成解锁的软件包 -- DevOps Center 已启用并安装 -- 使用源格式通过元数据 API 进行部署 - 部署日志显示可用历史记录中没有失败的部署。 - 部署历史记录显示了明确的发布节奏和发布窗口中相当统一的部署集群。 |
在生产中：
- 元数据表示使用基于组织的发布机制，例如： -- 有效使用更改集 -- 使用 package.xml 格式通过元数据 API 进行部署 - 部署日志显示可用历史记录中失败部署的重复实例。 - 部署没有明显的节奏或显示不均衡的部署集群，这是热修复和临时回滚的迹象）。 - 未启用并安装 DevOps Center。 |
| 在路线图和文档中：
- 发布名称很清楚 - 功能明确与特定的命名版本相关联。 - 发布名称可搜索和发现。 - 团队可以找到并遵循标记工件、开发项目和具有正确发布名称的其他工作的明确指南。 - 可以通过版本名称清晰地查看版本清单。 - 生成式 AI 应用程序的质量阈值是为不同的开发阶段定义的。 |
在路线图和文档中：
- 不包括发布名称。 - 功能未明确绑定到特定版本。 - 发布名称是临时使用或不存在。 - 团队以不同的方式引用工件、开发项目和其他工作。 - 使用版本名称无法清晰查看版本清单。 - 未定义生成式 AI 应用程序的质量阈值，或者如果定义，也未针对不同的开发阶段定义。 | |
| 环境战略 | 在您的组织中：
- 采用源驱动的开发和发布模式。 - 为 Developer 和 Developer Pro Sandbox 启用源跟踪。 - 给定环境中的元数据独立于发布工件。 - 环境不直接对应于发布路径。 - 变更的发布路径取决于变更的类型（高风险、中度风险或低风险）。 - 拥挤的环境不存在。 - 风险配置更改不会直接在生产中实施。 - 在工作高峰时段不会出现发布。 - Data 360 Sandbox 用于正确测试需要 Einstein 数据库、Knowledge 文章和非结构化数据的客服人员用例 |
在您的组织中：
- 采用基于组织的开发和发布模式。 - 源跟踪未为 Developer 和 Developer Pro Sandbox 启用。 - 给定环境中的元数据是发布工件。 - 环境直接对应于发布路径。 - 每个更改的发布路径相同，无论更改类型如何。 - 存在过度拥挤的环境。- 直接在生产中实施危险的配置更改。 - 发布发生在高峰工作时间。 - 需要使用 Einstein 数据库、Knowledge 文章和非结构化数据的 Agentforce 客服人员未使用 Data 360 Sandbox 进行测试 |
| 信号策略 | 在您的组织中：
- 团队协作定义和标准化健康检查 API 和 SLO。 - 定期审查和改进信号战略是事后和行动准备情况审查的一部分。 在生产中： - 对所有应用程序实施健康检查。 - 应用程序提供有关其运行状况的明确信号，例如负载和功能。 - 当依赖性不健康时，应用程序会正常降级。 - 负载脱落用于防止级联故障。 在您的设计中： - 背压和负载减少机制防止流量淹没服务。 - 假设依赖性最终失败。信号处理器旨在减少故障。 |
在您的组织中：
- 团队在孤岛中工作，创建不一致和不兼容的健康信号机制。 - 信令策略是一种事后的想法，仅在事件发生时解决。 在生产中： - 组件以静默方式失败，而不指示其健康状况。 - 应用程序会无限期重试对不健康服务的请求。 - 所有请求都以相同的优先级处理，无论其重要性如何。 - 要识别问题，运营商仅依赖反应性措施，例如用户投诉或关键系统故障。 在您的设计中： - 假设所有依赖性始终可用，并且不考虑网络分区、延迟峰值或其他常见问题。 - 应用程序接受所有传入请求，即使它们过载，也会导致延迟增加和失败的可能性增加 |
| 测试策略 | 在您的业务中：
- 可用性测试使用各种设备和辅助技术。 - 模拟器用于复制类似生产的条件，以实现可扩展性和性能测试。 - 当更改进入源控制时，测试会自动运行。 - 在应用程序开发周期中，耐久度、压力、性能和规模测试以若干间隔运行，并视为持续任务。 - 当您拥有 B2C 规模的应用程序、大量用户或大量数据时，您可以将规模测试作为 QA 流程的一部分。 - 规模测试侧重于系统的高优先级方面。 - 规模测试有定义明确的标准。 - 在完全 Sandbox 中执行规模测试。 - 即时工程包括由人工进行的质量审查。 - Agentforce 测试中心用于强大的客服人员测试。 |
在您的业务中：
- 不会进行可用性测试，或者如果进行了可用性测试，也会在有限的设备上执行。 - 不会测试类似生产的用户请求量、API 流量和网络速度的变化。 - 测试自动化不到位。 - 耐力、压力、性能、规模测试被视为一个发展阶段。 - 您没有在 QA 流程中执行规模测试，您拥有 B2C 规模的应用程序、大量用户或大量数据。 - 规模测试未确定优先级。 - 规模测试没有定义明确的标准。 - 您可以在部分复制或 Developer Sandbox 中执行规模测试。 - 提示工程不包括人工的质量审查。 - Agentforce 客服人员未测试，或者如果测试，仅使用客服人员生成器进行临时测试。 |
| 在您的组织中：
- 所有测试数据会清除敏感和识别数据。 |
在您的组织中：
- 测试数据与生产数据相同。 | |
| 在 Apex 中：
- 数据工厂模式用于单元测试 - 模拟和存根用于模拟 API 响应。 |
在 Apex 中：
- 单元测试依赖于组织数据。 - 不用嘲笑小作品 | |
| 在设计标准和文档中：
- 环境按支持的测试类型分类。 - 根据风险、用例或复杂性指定适当的测试制度。 |
在设计标准和文档中：
- 不清楚每个环境支持哪些类型的测试。 - 测试方案未按风险、用例或复杂性分类。 |
| 事件类型 | 外观触发器 | 恢复策略 |
|---|---|---|
| 系统中断 | 登录错误或帐户访问权限问题 | 客户恢复策略 |
| 服务不可用 | 激活冗余备份服务；手动解决方法 | |
| 生产错误 | 最近更改 | 部署回滚或取消部署以前的版本 |
| 一个无法解释的紧急错误 | 手动解决方法，禁用非必要功能，升级到 SME |
| 模式 | 反模式 | |
|---|---|---|
| 恢复时间 | 在您的业务中：
- 定期练习恢复协议。 - 团队知道他们拥有和负责生产中的哪些服务。 - 团队了解支持问题诊断的相关工具。 |
在您的业务中：
- 恢复协议不存在或未定期实践。 - 不清楚哪些团队拥有并负责生产中的不同服务。 - 团队没有支持问题诊断的工具指南或标准。 |
| 在您的文档中：
- 恢复策略按事件类型和触发器定义和分类。 - 事件响应的退出标准包含在 SLO 中，并且是明确的。 - 事件期间提升权限的激活条件和分配逻辑很清楚。 - 事件响应权限集和授权已明确列出。 - 存在帮助识别和诊断常见问题的故障排除指南。 |
在您的文档中：
- 事件响应是临时执行的。 - 事件响应的退出条件不存在。 - 未分配提升的权限，或者，如果是，将临时分配。 - 事件响应权限集和授权未列出。 |
|
| 在您的组织中：
- 存在基于会话的事件响应权限集，可以在恢复期间分配给支持人员。 - 设置审计跟踪显示指定的恢复测试人员在商定的时间登录测试环境，并遵循恢复测试脚本。 |
在您的组织中：
- 事件响应不存在基于会话的权限集，或者如果存在，支持人员无权使用。 - 设置审计跟踪显示指定的恢复测试人员未登录测试环境或未遵循恢复测试脚本 | |
| 在您的测试计划中：
- 存在用于恢复测试的测试脚本，并且可以重复。 - 事件模拟的环境已明确列出。 |
在您的测试计划中：
- 恢复测试的测试脚本不存在。 - 未建立事件模拟的环境。 |
|
| 分类能力 | 在您的业务中：
- 应在事件发生前确定应提醒中小企业或利益相关者支持复杂问题。 - 交付和支持团队之间的切换是上线的一部分。 - 如果咨询，Salesforce 架构师会快速响应，并帮助团队专注于恢复。 |
在您的业务中：
- 在事件发生之前，不会确定应引起警报的中小企业或利益相关者。 - 交付团队和支持团队之间的切换不是发布过程的一部分。 - Salesforce 架构师认为事件响应超出了他们的工作范围。 |
| 在您的文档中：
- 支持人员可以发现和读取给定解决方案中使用的系统和设计模式。 |
在您的文档中：
- 给定解决方案中使用的系统和设计模式对支持人员不可用。 |
|
| 在您的组织中：
- 记录和自定义错误消息被合并到整个系统的执行路径中。 |
在您的组织中： - 不使用日志记录和自定义错误消息。 | |
| 监控和警报 | 在您的组织中：
- 警报仅用于通知用户需要人为干预的场景；其他故障将被记录并报告。 - 向能够响应警报的用户发送警报。 - 在可能时，在潜在故障前发送警报。 |
在您的组织中：
- 当任何类型的故障发生时，都会发送警报，无论是否需要后续行动。 - 向业务用户提供需要技术解决方案的问题提醒。 - 仅针对已发生的故障发送警报。 |
| 在您的文档中：
- 提示调整警报的准入条件基于直接和间接生成式 AI 反馈度量定义。 |
在您的文档中：
- 没有定义触发生成式 AI 应用程序的提示调整警报的条件。 |
| 模式 | 反模式 | 业务连续性 | 在您的业务中：
- 采用“恢复优先”的思想，重点是尽快使优先级最高的业务功能和功能失去影响。 - 有一个用于审查 BCP 测试计划的维护计划。 |
在您的业务中：
- “解决问题”的心态是事件管理的唯一方法。 - BCP 测试计划不会定期刷新。 |
|---|---|---|
| 在您的文档中：
- 存在 BCP，其中包含在 Salesforce 不可用时继续处理或分类数据的步骤，触发使用 BCP 的事件列表，以及 BCP 测试的步骤和间隔。 - BCP 包括上游和下游系统和依赖性。 |
在您的文档中：
- BCP 不存在、不完整或仅包含 Salesforce。 |
|
| 在您的测试计划中：
- 考虑 BCP 中与流程和人员相关的区域。 |
在您的测试计划中：
- 未考虑 BCP 中与流程和人员相关的区域。 | |
| 技术连续性 | 在您的业务中：
- 您已评估是否需要构建有意冗余或故障转移系统 - 事件恢复策略尽可能自动化。 |
在您的业务中：
- 您没有评估有意冗余或故障转移系统的必要性 - 事件恢复策略全部是手动操作。 |
| 在您的文档中：
- BCP 考虑了团队可能需要的额外资源或打破常规的程序，以有效应对事件。 |
在您的文档中：
- BCP 不包括运营支持需求。 |
|
| 备份和还原 | 在您的文档中：
- 数据和元数据都存在备份和还原策略。 |
在您的文档中：
- 备份和还原策略不存在，或者如果存在，则不完整，仅应用于数据或元数据，而非两者。 |
| 在贵公司：
- 备份存储在只有授权用户才能访问的安全位置。 - 测试计划和测试日志显示，每年至少两次在完全或部分复制 Sandbox 中测试数据还原。 |
在贵公司：
- 备份不是人类可读的。 - 备份存储在未经授权的业务用户可以访问的位置。 - 没有数据还原过程，或数据还原过程未经测试。 |
| 工具 | 描述 | 应用程序生命周期管理 | 事件响应 | 连续性计划 |
|---|---|---|---|---|
| Apex锤子测试 | 了解当前和新版本中的 Salesforce Apex 测试。 | X | ||
| Apex 小作品 API | 构建模拟框架，简化测试。 | X | ||
| 备份和恢复 | 自动生成备份以防止数据丢失。 | X | ||
| 大对象 | 在平台上存储和管理大量数据。 | X | ||
| 字段历史跟踪 | 跟踪和显示字段历史。 | X | ||
| 获取贵组织的采用和安全见解在新窗口中打开链接 | 监控 Lightning Experience 在贵组织中的采用和使用。 | X | ||
| 管理批量数据加载作业 | 使用批量 API 创建更新或删除大量记录。 | X | ||
| 管理实时 Event Monitoring 事件 | 管理事件监控流和存储设置。 | X | ||
| 数据和存储资源 | 查看 Salesforce 组织的存储限制和使用情况。 | X | ||
| 监控调试日志 | 监视日志并设置标记以触发日志记录。 | X | ||
| 使用登录取证监控登录活动 | 识别可能表明身份欺诈的行为。 | X | ||
| 使用设置审计跟踪监控设置更改 | 跟踪管理员最近的设置更改。 | X | ||
| 监控培训历史 | 查看用户已参加的 Salesforce 培训课程。 | X | ||
| 监控后台作业 | 监视贵组织的后台作业。 | X | ||
| 监控计划作业 | 查看报表快照、计划 Apex 作业和仪表板刷新。 | X | ||
| 扩展测试 | 测试系统性能并解释结果。 | X | ||
| 主动监控 | 通过使用 Salesforce 监控服务，最大限度地减少中断。 | X | ||
| Salesforce Data Mask | 自动屏蔽 Sandbox 中的数据。 | X | ||
| 系统概览页面 | 查看贵组织的使用数据和限制。 | X | ||
| 使用 force:lightning:lint | 通过 Salesforce CLI 分析和验证代码。 | X |
| 资源 | 描述 | 应用程序生命周期管理 | 事件响应 | 连续性计划 |
|---|---|---|---|---|
| 性能和规模测试中的 7 种反模式 | 在性能和规模测试中避免常见的反模式。 | X | ||
| 分析复杂 Salesforce 应用程序中的性能和规模热点 | 了解解决贵组织中性能和可扩展性问题的方法。 | X | ||
| 制定灾难恢复计划 (Trailhead) | 构建灾难恢复计划。 | X | ||
| 业务连续性不仅仅是备份和还原 | 全面了解 BCP。 | X | ||
| 设计标准模板 | 为您的组织创建设计标准。 | X | ||
| Salesforce 中的诊断和监控工具 | 了解如何提高实施的质量和性能。 | X | ||
| 业务连续性计划的指导原则 | 查看有效 BCP 的基本原则。 | X | ||
| 如何在 Salesforce 上扩展测试 | 了解规模测试生命周期的五个阶段。 | X | ||
| 性能测试简介 | 了解如何开发性能测试方法。 | X | ||
| 监控您的组织 | 了解自助监控选项。 | X | ||
| 测试策略模板 | 创建并自定义规模和性能测试计划。 | X | ||
| 测试策略模板 | 请确保测试策略完整。 | X | ||
| 了解源驱动的开发 (Trailhead) | 了解软件包开发和临时组织。 | X |