# architect 精心设计 (well-architected) - Full Documentation ## 导言 Salesforce 精心构建代表 Salesforce 和整个生态系统的专家的指导和最佳实践。感谢为良好架构贡献资源和 Knowledge 的每个人。 我们每年更新两次精心设计的文档。我们将在下一个维护时段宣布如何为“良好架构”做出贡献。 您可以随时在[此](https://sfdc.co/bxNtvh)提供对 Well-Architected 的反馈。 ## 告诉我们您的想法 帮助我们保持 Salesforce 架构合理与您相关;参加我们的[调查](https://sfdc.co/bxNtvh),以提供有关此内容的反馈,并告诉我们您接下来想要看到的内容。 > 在[这里](/docs/architect/zh-cn/well-architected/guide/contributors)阅读我们的更新计划。 ## 导言 系统通过使人们能够轻松访问和使用应用程序、让用户感觉他们正在完成更高质量的工作以及让人们希望在系统中使用应用程序来展示引人入胜的行为。 提供吸引人的行为对业务很重要,因为它直接关系到用户的采用以及整体工作人员和客户满意度。参与行为也有助于减少支持请求,并有助于提高用户功能请求的质量。 创建吸引人的行为的挑战之一是很难仅通过客观度量来衡量。相反,它是根据用户的主观体验来衡量的;用户觉得吸引人的应用程序提供了真正的价值。参与应用程序是[可访问](/docs/architect/zh-cn/well-architected/guide/compliant#可访问性)的、非侵入性的、易于理解的。他们需要最少的入职培训和培训。他们使用明确的方法来主动防止用户错误。 另一个挑战是,参与目标通常会随着系统中不同类型的用户交互而变化。例如,对于管理个案的内部用户,您可能有一组目标,对于通过网站上的表格提交信息的外部用户,您可能有一组目标。要设计参与系统,您需要仔细考虑您尝试创建的参与类型,以及用户为什么希望在您开始组装功能和页面之前参与。 与用户体验 (UX) 设计师合作将有助于您在交付引人入胜的应用程序时做出更有效的决策。从架构的角度来看,用户采用和保留是健康系统的重要组成部分。采用架构可以减少用户匆忙完成流程或跳过步骤以避免在不喜欢使用的系统中花费时间而导致数据质量问题的可能性。对于面向外部的系统,引人入胜的架构可以提高收入和留住客户,因为发现您的系统更易于使用的客户会选择与贵组织开展更多业务。 您可以通过专注于提供简化和有帮助的体验来创建更吸引人的应用程序。 ## 简化 简化的应用程序易于导航,清晰显示信息和数据输入任务,并适应各种外形规格。简化的应用程序还具有用户在其他常用应用程序中已经习惯的体验模式。例如,当用户右键单击链接时,大多数 Web 浏览器会将“在新选项卡中打开”显示为顶部选项。包含选项卡的简化应用程序将遵循相同的模式。 低效应用程序体验的影响可能远远超出单个应用程序。糟糕的应用程序体验会削弱用户的 Trust。随着更多类型的业务关键型和面向客户的应用程序转向数字渠道,这会损失公司的关键利益相关者的忠诚度。 您可以通过有意处理应用程序复杂性、外形设计和外形规格来更好地简化您的应用程序。 ### 应用程序复杂性 最小化应用程序复杂性意味着用户只能看到相关的菜单项、选项卡和导航控制。您需要创建用户组、用户权限和正确应用程序体验之间的映射。使用这些映射来了解要向给定用户提供的应用程序体验,然后确保您的应用程序具有提供这种体验所需的逻辑控制。 为用户呈现过于复杂的应用程序会导致各种不良体验: - 用户经常看到不必要或不相关的选项卡,导航到空白屏幕,并遇到禁用或阻止的链接。 - 不必要或无帮助的说明,例如“如果您的角色是 X...,请忽略此选项卡”显示在培训和支持材料中。 - 混乱的导航菜单迫使用户花费额外的时间来查找完成工作所需的项目。 这些糟糕的体验导致采用率和满意度低。 在确定应用程序复杂性的正确级别时,请考虑以下事项: - 根据用户所需工作的优先级,组织菜单、选项卡和其他导航控件。 - 避免引入用户必须单独学习的新行为,以便他们可以使用您的应用程序。 - 请勿删除对允许用户自定义用户界面各方面的功能的访问权限。 - 使用权限集提供扩展或减少导航选项。 - 简化 Lightning 页面[激活分配](https://help.salesforce.com/s/articleView?id=sf.lightning_page_getting_into_salesforce1.htm)。最小化每个应用程序的活动 Lightning 页面数量。使用动态表单、权限集和条件渲染将项目添加到应用程序中的 Lightning 页面。执行此操作,而不是维护由简档激活和分配的多个 Lightning 页面。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/engaging#简化的应用程序模式和反模式)列表显示了 Salesforce 组织中正确(和差)的应用程序复杂性管理。您可以使用这些来验证或改进您的应用程序设计。 要了解有关可帮助您管理应用程序复杂性的 Salesforce 工具的更多信息,请参阅[相关工具](/docs/architect/zh-cn/well-architected/guide/engaging#与参与相关的工具)。 ### 表格 简化的表单将信息组织成逻辑序列,支持快速数据输入,并最大限度地减少所需的步骤。它们还允许[有用](/docs/architect/zh-cn/well-architected/guide/engaging#有用)的客户端数据验证消息,并消除重复的表单提交周期。 在设计表单时考虑以下事项: - 将**相关字段分组**。对与流程或数据输入任务中的相同步骤相关的字段进行分组。删除与当前任务没有直接关联的字段。 - **尽早输入和验证数据**。需要用户输入数据的字段应尽早显示在表单中。最佳实践是在字段级别尽快显示数据格式化或缺失数据的问题(即在用户尝试导航到下一步或提交表单之前)。此外,避免在用户有机会将数据输入字段之前显示字段级错误。 - **最小化数据输入任务**。预填写或自动填写尽可能多的字段,以最大限度地减少数据输入错误并提高效率。仅要求用户输入重要或关键数据。消除任何与当前业务流程无关的数据输入。尽可能使用选项列表而不是自由格式文本字段来强制选择有效选项,并减少相同答案的变体。 - **最小化对服务器的提交**。请勿让多步骤表单多次向服务器提交数据。确保所有自定义 [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.apex_result_caching) 或 [Aura](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_storable_actions.htm) 组件使用客户端缓存来处理导航或分页操作。(Salesforce Lightning Experience 和 Salesforce 移动应用程序默认使用客户端缓存。)设计表单,以便用户仅向服务器提交一次数据。在提交表单之前,验证客户端的用户输入。这将最大限度地减少意外的用户提交,防止重复或脏事务在后端消耗带宽,并帮助您设计更好的[数据处理](/docs/architect/zh-cn/well-architected/guide/automated#数据处理)。 - **管理表单状态**。客户端缓存不仅有助于导航和分页等行为,还有助于最大限度地减少间歇性连接问题导致的数据丢失。有效地管理状态还意味着应用程序可以适当地编排向服务器提交的数据,防止重复事务,以及根据服务器端操作的状态向用户提供相关和及时的消息。简化的表单仅提交一次数据操作,不需要用户等待服务器上长时间运行的操作完成。 - **遵循无障碍标准**。为了最大化应用程序的受众并帮助确保它们包括所有客户,请在表单设计中强制执行[可访问性](/docs/architect/zh-cn/well-architected/guide/compliant#可访问性)标准。 简化的表单有助于提高应用程序中[的数据完整性](/docs/architect/zh-cn/well-architected/guide/automated#数据完整性),以及应用程序对用户的[帮助](/docs/architect/zh-cn/well-architected/guide/engaging#有用)。它们还可以减少支持票证和请求,因为用户能够更好地处理错误并清楚地了解他们的表单提交状态。此外,简化的表单支持快速高效的数据输入,并确保用户无需等待运行时间更长的流程才能完成进一步的工作。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/engaging#简化的应用程序模式和反模式)列表显示了 Salesforce 组织中正确(和糟糕)的表单设计。您可以使用这些来验证或改进您的表单设计。 要了解有关 Salesforce 工具的更多信息,这些工具可以帮助您构建更简化的表单,请参见[相关参与工具](/docs/architect/zh-cn/well-architected/guide/engaging#与参与相关的工具)。有关为您的用例选择正确表单工具的更具体的指导,请查看[架构师使用 Salesforce](/docs/architect/zh-cn/decision-guides/guide/build-forms#重要外卖) 构建表单的决策指南。 ### 外形规格 参与应用程序可以优雅地适应不同的设备和交互类型,或外形规格。根据设备类型,不同类型的用户交互将更容易(或更难),表单和字段的可读性将发生变化。请记住,除了屏幕尺寸之外,外形规格也是指您的用户如何与屏幕交互。越来越多的设备现在拥有触摸屏,一些用户也可能使用特殊设备实现[无障碍](/docs/architect/zh-cn/well-architected/guide/compliant#可访问性)。在设计表单时,请确保考虑这些因素。 不考虑外形规格的变化会导致各种问题,包括: - 数据质量差 - 不可用的应用程序界面 - 支持客服人员的更多故障排除或“代表”会话 - 用户采用率低、活跃用户数量少,以及应用程序“放弃”率高 要在 Salesforce 应用程序中设计跨外形规格的互操作性,请考虑以下事项: - **确定每个应用程序支持的外形规格** - **确定用户的输入方法和可访问性需求。**有关更多信息,请查看[可访问性](/docs/architect/zh-cn/well-architected/guide/compliant#可访问性)。 - **使用[标准功能](/docs/architect/zh-cn/well-architected/guide/intentional#标准与自定义功能),尽可能跨设备提供自适应体验。** - Salesforce 提供的 [Lightning 页面模板](https://help.salesforce.com/s/articleView?id=sf.lightning_page_templates.htm&type=5)默认支持不同的外形规格。如果您选择使用 Aura 开发自定义 Lightning 页面模板,开发人员将需要将外形规格信息合并到组件设计文件中。 - Salesforce 提供的[标准页面组件](https://help.salesforce.com/s/articleView?id=sf.lightning_page_components.htm&type=5)可为您处理跨支持的外形规格的渲染。如果您使用 LWC 或 Aura 创建自定义组件,开发人员将需要处理宽度感知([Aura](https://developer.salesforce.com/docs/atlas.en-us.238.0.lightning.meta/lightning/components_config_for_app_builder_width_aware.htm?q=width) 和 [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_width_aware) 之间存在实施差异),并在组件的设计文件中声明外形规格支持。 - **请遵循[所有设备上](/docs/architect/zh-cn/well-architected/guide/engaging#表格)**的简化表单指南。 - **为关键外形规格创建测试计划(和良好测试)。**理想情况下,您会为所有应用程序测试所有设备和外形规格。但是,为外形规格测试设置正确的设备(或设备模拟器)是一项重大投资。如果您知道某个应用程序或一组应用程序将在移动设备或平板电脑上拥有大量用户,请优先考虑在移动设备和平板电脑外形规格上对这些应用程序进行准确测试。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/engaging#简化的应用程序模式和反模式)列表显示了 Salesforce 组织中正确(和差)外形规格意识的外观。您可以在构建之前使用这些来验证您的设计,或者确定需要重构的页面。 要了解有关适用于有效外形设计的 Salesforce 工具的更多信息,请参阅[相关工具](/docs/architect/zh-cn/well-architected/guide/engaging#与参与相关的工具)。 ### 简化的应用程序模式和反模式 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/easy-streamlined)器中,发现简化应用程序的更多模式。
模式 反模式
应用程序复杂性 在您的组织中:
- 在管理员提供的默认配置中,应用程序的选项卡少于 10 个
- 没有应用程序将“禁用此应用程序中导航项目的最终用户个性化”设置为 true
在您的组织中:
- 在管理员提供的默认配置中,应用程序通常拥有超过 10 个选项卡
- 许多应用程序将“禁用此应用程序中最终用户对导航项目的个性化”设置为真,或在组织范围内禁用自定义导航项目的权限
表格 在您的应用程序中:
- 字段遵循逻辑分组
- 数据输入字段以五个或更少的组显示在一起
- 在用户导航离开或提交数据之前,数据输入错误已清除并显示在字段级别
- 分页控件支持在步骤之间移动
- 数据提交仅发生一次
- 操作和导航的标签清晰
- 提供及时和可视的反馈,以确认用户操作,例如按钮单击
- 导航按钮(例如,“转到”、“下一步”和“返回”)在整个 UI 中一致放置
在您的应用程序中:
- 数据输入字段没有逻辑分组,需要填写表单的用户进行大量的上下文切换
- 数据输入错误包含只能由了解系统内部工作原理的人员解释的加密信息
- 数据输入错误仅在单击表单的提交按钮时显示
- 步骤和分组未明确定义,导致导航困难
- 在整个数据输入过程中多次提交数据
- 操作和导航的标签会使不熟悉基础系统功能的用户感到困惑
- 未提供用户操作的视觉确认
- 导航按钮出现在整个 UI 的任意位置
在表单逻辑中:
- 字段尽可能预填或自动填写
- 用户无需等待长时间运行的服务器端操作完成
- 自定义组件对不涉及数据操作的基于服务器的操作使用 cacheable=true
- 数据操作仅执行一次
- 在 LWC @wire 适配器中,处理所有不涉及数据操作的操作
在表单逻辑中:
- 可以预填写或自动填写的字段需要手动输入
- 用户必须在提交过程中停止工作,以等待服务器端操作完成
- 自定义组件集 cacheable=false
外形规格 在您的组织中:
- Salesforce 提供的 Lightning 页面模板用于所有或大部分页面
- 自定义 Lightning 页面模板在 Aura 组件设计文件中使用 design:supportedFormFactors 和 design:supportedFormFactor
- 应用程序生成器中可用的自定义 LWC 或 Aura 组件在各自的设计文件中声明支持的外形规格,并实施宽度感知样式模式
在您的组织中:
- Classic 仍处于活动状态
- 自定义 Lightning 页面模板在 Aura 组件设计文件中没有统一使用 design:supportedFormFactors 和 design:supportedFormFactor
- 应用程序生成器中可用的自定义 LWC 或 Aura 组件未在各自的设计文件中一致声明支持的外形规格
- 在自定义 LWC 或 Aura 组件中,Salesforce 提供的界面不会实施宽度感知样式
- 在自定义 LWC 或 Aura 组件中,不同外形规格的样式完全由 CSS 中的硬编码 px 或 % 值驱动
在桌面上:
- 数据输入字段和导航控件适合屏幕,并可按照预期进行交互
- 根据页面激活分配规则,记录和应用程序页面正确显示
在桌面上:
- 数据输入字段和导航控件不会显示在屏幕上的预期位置
- 与数据输入字段和导航控件的交互不匹配所需行为
- 缺少页面激活分配规则意味着所有用户都可以看到相同的记录和应用程序页面
在手机和平板电脑上:
- 数据输入和导航控件正确显示
- 用户可以轻松输入数据
- 显示专为更小外形优化的移动导航菜单
- 紧凑布局显示在记录级别
在手机和平板电脑上:
- 数据输入和导航控制呈现不一致或不正确
- 用户无法轻松输入数据
- 移动导航菜单无法与桌面导航区分
- 紧凑布局未在记录级别配置
## 有用 有用的应用程序使用户感觉更有力和更有效,干扰或中断更少。 有用的应用程序通过减少手动错误并在用户需要的时间和地点向他们提供反馈来帮助保持[数据完整性](/docs/architect/zh-cn/well-architected/guide/automated#数据完整性)。它们帮助用户了解他们现在和下一步需要关注什么操作,并提供相关信息来帮助用户更快地解决他们自己的问题。它们提供了用户的行动和有意义的影响或成就之间的明确联系。 您可以通过三个主要习惯构建更有用的应用程序:通知和消息、应用程序内指导以及认可和奖励。 ### 通知和消息 通知和消息帮助用户保持了解。 设计良好的通知和消息传递系统可以通过为用户提供及时做出关键决策所需的信息来提高参与度和生产力。设计不当的通知和消息传递系统——一种既不相关也不及时的消息传递系统——将产生相反的效果。内部用户将快速禁用或忽略通知,导致他们错过可能影响基本业务流程的合法消息。厌倦了毫无意义的通知的客户或其他外部用户可能会决定完全停止使用您的系统。 在决定应用程序如何处理向用户发送通知和消息时,请考虑以下事项: - **对于错误,作为最后手段使用通知和消息。**通过后端处理设计系统中的[错误处理](/docs/architect/zh-cn/well-architected/guide/automated#错误处理),无需人工干预即可更正特定类型的错误。仅向用户发送有关阻止他们完成任务的关键错误的消息。同样,当业务用户可以(并且需要)采取一些纠正措施时,只向他们发送错误消息。额外的错误消息或详细信息可以通过报表提供和/或使用异步方法发送给技术支持人员,以便进一步跟进。 - **根据相关性、紧迫性和及时性选择消息类型。**不同类型的消息具有不同的阻止或中断行为级别。通知是一种“阻止”类型的消息,因为它们要求用户在能够继续工作之前进行确认。与错误消息一样,应谨慎使用通知。吐司通知是[非阻止](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_toast)的,可以有不同的持久性行为,并支持不同类型的消息用例。干扰性最小的消息是[应用程序内通知](https://help.salesforce.com/s/articleView?id=sf.notif_builder.htm&type=5)或电子邮件。这些信息最适合用于提供信息,用户可以在选择的时间和方式处理这些信息。 - **考虑接下来需要做什么**。虽然一些通知是信息性的(例如成功消息),但其他通知可能需要用户采取某种类型的操作。在设计通知时,请确保不仅考虑通知本身,还要考虑用户可能需要采取行动的任何其他信息。包括明确的说明或链接,以便用户在所有可操作的通知中找到更多信息或完成后续步骤。 - **关注可读性**。确保您清楚地传达了每个通知的目的,以及用户需要采取的后续步骤。不熟悉基础系统内部工作原理的业务用户应了解消息。在创建消息时,遵循[可访问性标准](/docs/architect/zh-cn/well-architected/guide/compliant#可访问性),并确保本地化,以支持可能显示消息的区域的用户。 在[设计标准](/docs/architect/zh-cn/well-architected/guide/intentional#设计标准)中包含何时使用通知或不同类型错误的模式,以帮助确保应用程序生成器遵循一致的实践。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/engaging#有用的应用程序模式和反模式)列表显示了 Salesforce 组织中正确(和差)的通知和消息传递。您可以在构建之前使用这些来验证您的设计,或者确定需要重构的使用情况。 要了解有关适用于通知和消息传递的 Salesforce 工具的更多信息,请参阅[相关工具](/docs/architect/zh-cn/well-architected/guide/engaging#与参与相关的工具)。 ### 应用程序内指导 应用程序内指导是揭示复杂工作流神秘面纱(尽管您应该先确保已[优化](/docs/architect/zh-cn/well-architected/guide/automated#流程设计))或帮助新员工入职的强大方式。它可以以自动化和可扩展的方式引入流程更改、突出显示新功能或分发培训。但如果实施不当,应用程序内指导可能会被过度使用。频繁的弹出窗口或警报会为用户带来大量噪音和中断,导致工作效率下降。应用程序内指导也可能使用不足,导致发布和变更管理流程更加繁琐(尤其是对于简单功能)。归根结底,应用程序内指导的过度使用和不足都会导致一系列对业务构成风险的问题,包括: - 降低数据完整性 - 用户错误增加 - 更高的用户挫败感级别和更低的用户满意度 - 降低用户效率 请记住,您可能想要在不同场景中以不同方式使用应用程序内指导,因为用户的心态将决定指导的“过多”与“不足”的程度。对于首次使用新系统的用户,他们需要的消息传递频率可能高于仅在已熟悉系统中了解新功能的用户。 以下是创建有效应用程序内指导的一些关键: - **制定设计标准**。重要的是要记住,过度暴露应用程序内指导会导致用户开始定期忽略或忽略消息。此时,应用程序内指导会成为一种烦恼,而不是一种资源。定义[设计标准](/docs/architect/zh-cn/well-architected/guide/intentional#设计标准),以明确何时使用提示、逐步解说、字段级帮助文本、验证消息、路径、屏幕流等。 - **为指导实施创建优先级系统**不是每个应用程序内指导的用例都应实施。相反,请考虑以下问题以确定优先级。在哪些方面,您可以简单地使用更好的字段名称、按钮上更明确的标签、更好的[表单设计](/docs/architect/zh-cn/well-architected/guide/engaging#表格)和[流程优化](/docs/architect/zh-cn/well-architected/guide/automated#流程设计)来创建更直观的工作流?在哪里可以向路径添加更多帮助文本或链接?应用程序内指导将对[业务成本影响](/docs/architect/zh-cn/resources/guide/kpi-spreadsheet-template)?您想要多久向用户传递一次消息?此外,请确保您的[路线图](/docs/architect/zh-cn/well-architected/guide/intentional#路线图)中包含任何实施,以便所有相关方都能看到。 - **将用户映射到有效(和建议的)应用程序内指导。**将用户映射到应用程序内指导将帮助您识别并防止由于为用户显示太多的应用程序内指导而导致的“帮助性过载”。通常,这是孤立开发的结果,因为团队对他们特定的用例考虑得太狭隘。对于大型组织,保持对用户将接触的内容的整体视图尤其重要。在路线图中包含指导实施也会有所帮助。 - **收集并使用反馈进行改进**。查看应用程序内指导使用情况的数据,并将其用于判断应用程序内指导部署的有效性。确保为用户提供开放式反馈的方式,以帮助指导生成器。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/engaging#有用的应用程序模式和反模式)列表显示了 Salesforce 组织中正确(和差)的应用程序内指导。您可以在构建之前使用这些来验证设计,并确定需要重构的实施。 要了解有关适用于应用程序内指导的 Salesforce 工具的更多信息,请参阅[相关工具](/docs/architect/zh-cn/well-architected/guide/engaging#与参与相关的工具)。 ### 认可和奖励 将认可和奖励构建到应用程序中有助于使用该应用程序的个人感觉与工作的影响更加相关,并更好地了解他们的贡献、生产力和绩效的价值。这也是释放忠诚度和参与度的有效方式。 不为认可或奖励应用程序体验而设计会导致各种问题,包括: - 难以了解进度或速度的用户 - 对目标进度或未完成工作的困惑 - 更多没有生产力的用户,他们没有看到他们的任务和“更大的情况”之间的联系 - 在手动、低级别的目标报告上浪费的管理时间 奖励应用程序体验可能难以设计和交付,因为它们取决于公司文化、政策和标准以及个人用户的上下文和首选项。帮助桌面用户感受愉悦或欣赏时刻的功能可能会对移动设备用户或试图在嘈杂繁忙的家庭办公室工作的用户造成刺激。使用应用程序处理私人或高度敏感信息的人员可能不喜欢以五彩纸屑庆祝或徽章的形式交流重大事件。相反,分布式销售团队可能会将这种游戏化视为一种回报适当的应用程序体验。最终,您选择的实施模式可能最好通过与团队中的用户体验 (UX) 设计者合作来确定。 在架构方面,确定应用程序如何以及在哪里实施帮助用户获得认可和奖励的功能非常重要。了解这些功能如何及在何处使应用程序降低可[重用性](/docs/architect/zh-cn/well-architected/guide/composable)或降低[实际业务价值](/docs/architect/zh-cn/well-architected/guide/automated#业务价值)也是至关重要的。 以下是在 Salesforce 应用程序中评估荣誉和奖励时需要考虑的一些问题: - **用户如何以及在哪里可以看到自己的进度以及团队的整体数据统计?**报表很重要,但它们通常包含的汇总数据可能遗漏了日常工作的上下文。您可以使用 Lightning 应用程序生成器等工具在应用程序上下文的记录屏幕上嵌入图表或仪表板,帮助用户在处理日常任务时了解它们的影响或进度。 - **如何识别用户?**这可能因团队或个人首选项而异。在某些情况下,主管可能想要查看有关用户进度的消息,以便与更大的小组共享。认可也是帮助提高员工士气的一项额外优势。在其他情况下,用户可能只是更喜欢成为唯一知道他们在特定任务或项目上进度的人。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/engaging#有用的应用程序模式和反模式)列表显示了 Salesforce 组织中正确(和差)的认可和奖励是什么样子的。您可以在构建之前使用这些来验证设计,并确定需要重构的实施。 要了解有关表彰和奖励的 Salesforce 工具的更多信息,请参阅[相关参与工具](/docs/architect/zh-cn/well-architected/guide/engaging#与参与相关的工具)。 ### 有用的应用程序模式和反模式 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/easy-helpful)器中,发现更多帮助应用程序的模式。
模式 反模式
通知和消息 您的设计标准包括:
- 批准通知、吐司和通知的用例
- 吐司变体和通知的设计模式
- 错误消息的设计模式
如果定义了设计标准,它们不会解决错误和通知
在您的组织中:
- 通知是主要的消息传递格式
- 吐司消息使用变体
- 模式设置为粘滞的吐司消息不存在
- 通知很少使用(如果有的话)
- 生成式响应始终标识使用的数据源
- 机器人在与用户的第一次交互之前清楚地标识自己
- 与生成式 AI 相关的风险免责声明会在首次交互前向用户显示
- AI 免责声明以清晰易懂的语言供用户使用
在您的组织中:
- 电子邮件是主要的消息传递格式
- 消息类型没有一致的方法
- 吐司消息没有一致使用变体
- 存在模式设置为粘滞的吐司消息
- 通知是临时使用的
- 生成式回复不会识别使用的数据源
- 机器人在第一次与用户交互之前没有清楚地标识自己
- 不会向用户显示生成性 AI 风险的免责声明
- AI 免责声明没有以清晰易懂的语言呈现给用户
在您的应用程序中:
- 没有人员参与点,不会直接将生成式响应发送到最终用户
在您的应用程序中:
- 生成式响应直接发送到最终用户,无需人工参与
另请参阅:错误处理
应用程序内指导 您的设计标准和文档包括:
- 应用程序内指导的批准用例
- 提示和逐步解说的设计模式
- 用户、应用程序和活动应用程序内指导的明确矩阵
如果存在设计标准和文档,将:
- 不处理应用程序内指导
- 请勿包含显示用户、应用程序、有效应用程序内指导的明确矩阵
在您的组织中:
- “应用程序内指导之间的延迟”设置使用默认值或长于 Salesforce 提供的默认(24 小时)周期的自定义值
- 没有应用程序包含多个有效逐步解说
- 没有逐步解说的“显示时间”设置高于 10
- 未激活“任何页面、任何应用程序”或“此页面、任何应用程序”的提示
在您的组织中:
- “应用程序内指导之间的延迟”设置设置为短于 Salesforce 提供的默认(24 小时)期间
- 应用程序有多个活动逐步解说
- 许多逐步解说都有高于 10 的“显示时间”设置(有些的最大值为 30)
- 提示是临时激活的,许多具有“任何页面、任何应用程序”或“此页面、任何应用程序”设置
荣誉和奖励 在您的组织中:
- 应用程序使用嵌入式分析向用户显示相关目标进度和生产力统计数据
- 路径庆祝仅在用户同意下启用
- 通知和消息传递包括用户识别,并在通知对象和触发通知的内容的设计中反映用户首选项
在您的组织中:
- 与目标进度和生产力统计数据相关的 Analytics 仅在报表或经理仪表板中可用
- 在未检查用户同意的情况下启用路径庆祝
- 通知和消息传递不包括任何类型的用户识别,或者不反映用户的首选项,并且感觉噪音或噱头
## 与参与相关的工具
工具描述简化有用
激活 Lightning 应用程序页面管理页面可用性、命名、可见性和定位X
采用仪表板查看登录历史、功能采用率和生产力XX
提醒在会话上保留提醒,并在用户不启动的情况下显示提醒X
客户端缓存 Apex 方法结果使用缓存的客户端数据评估性能X
动态表单仅向用户显示必填字段和页面部分X
参与见解监控最近的用户活动,并根据需要采取操作XX
应用程序内指导 利用提示和逐步解说进行培训和入门X
学习路径个性化用户学习体验X
Lightning应用程序生成器创建没有代码的自定义移动和 Lightning 页面X
Lightning数据服务跨组件缓存和共享数据X
VS Code Lightning 设计系统验证器根据 SLDS 指南验证标记XX
Lightning 页面模板为不同外形构建 Lightning 页面X
查找筛选器查找、主-详细信息和层次结构的筛选值X
管理多币种在交易中使用多币种X
消息 传递发送短信、Facebook Messenger 或 WhatsApp 消息X
Mobile Publisher创建 Lightning 应用程序和 Experience Cloud 站点的移动版本X
移动就绪组件构建在移动体验中表现出色的组件X
多语言站点创建站点的不同语言版本XX
通知生成器创建自定义通知以显示信息X
路径指导用户完成业务流程并庆祝成功XX
平台缓存缓存数据时提高性能和可靠性X
在 Lightning 应用程序生成器中预览移动应用程序页面在移动设备上预览记录和应用程序页面X
提示提醒用户系统相关问题和更新X
荣誉徽章确认并庆祝用户的成就X
使用 WDC 进行识别为技能背书并致谢X
记录类型个性化业务流程、选项列表值和页面布局XX
声誉概览认可参与和Knowledge共享X
限制规则阻止用户访问可能包含不必要数据的记录X
标准页面组件了解标准 Salesforce Lightning 组件X
翻译管理全局用户的翻译XX
验证规则在保存前验证数据是否符合指定标准X
## 与参与相关的资源
资源描述简化有用
建筑表单架构师指南评估表单设计注意事项,并选择最佳工具X
为不同的外形规格配置组件配置组件以在桌面和手机中呈现X
自定义帮助内容根据您的独特实施定制帮助内容 X
默认字段值定义默认、动态或静态字段值X
设计指南创建符合最佳实践的用户界面XX
设计标准模板为您的组织创建设计标准XX
设计测试技能 (Trailhead)计划验证和测试设计的方法XX
应用程序内反馈指南查看指南,以收集系统内的反馈XX
Lightning设计系统Android静态库使用 Lightning 页面的外观构建本地 Android 应用程序X
Lightning 设计系统 iOS 静态库使用 Lightning 页面的外观构建本地 iOS 应用程序X
消息传递指南交流相关信息,创造欢乐时刻X
消息传递类型根据用户交互了解不同的消息传递类型X
导航指南帮助用户在页面之间移动并在应用程序中定位X
测试网络可访问性 (Trailhead)使用自动和手动测试来确保可访问性XX
用户参与指南查看入门、采用、帮助和学习指南XX
## 告诉我们您的想法 帮助我们保持 Salesforce 架构合理与您相关;参加我们的[调查](https://sfdc.co/bxNtvh),以提供有关此内容的反馈,并告诉我们您接下来想要看到的内容。 > 在[这里](/docs/architect/zh-cn/well-architected/guide/contributors)阅读我们的更新计划。 ## 导言 受**信任**的 Salesforce 解决方案保护业务和利益相关者。设计良好的受**信任**解决方案安全、合规且可靠。 **安全解决**方案控制访问并保护数据。
**合规**解决方案遵循法律和道德准则。
**可靠**的解决方案高效、可靠地运行。
创建**受信**解决方案需要谨慎规划。您需要了解解决方案所服务的业务和/或行业的上下文。业务的整体风险容忍度如何?什么样的数据会移入和移出系统?Salesforce 将作为具有专门安全、合规或道德考虑的数据的记录或存储点系统吗?相关法规和合规标准是什么?是否有其他特定于公司的标准?Salesforce 是业务关键型系统吗?流量或系统使用情况是否有季节性或环境性的峰值需要您考虑? 要达成**可信**的解决方案,您需要与整个业务的利益相关者合作。您必须清楚了解需要访问解决方案的用户和系统类型,以及完成工作所需的数据和权限。您需要了解法律和行业要求,以及内部政策和标准。您需要与开发和维护团队合作,以确保功能可以访问,并公平地为用户服务。您需要计划解决方案的可用性和性能,即使在中断或快速增长时。对于架构良好的解决方案,没有什么比受**信任**更重要的了。 以下部分为**受信**解决方案架构的核心注意事项提供了更深入的指导。 ## 受信概览
安全
安全的系统保护业务、利益相关者和数据。安全架构确保只有批准的用户才能获得访问权限,将用户访问权限限制为完成工作所必需的内容,并保护系统中的数据不被泄露。
组织安全性 会话安全性 数据安全性
身份验证
授权
会话管理
设备访问权限
威胁检测和响应
共享和可见性
加密的使用
合规
合规解决方案遵循法律和道德准则。合规架构遵守法律法规和行业标准,维护道德政策,并公平地为所有用户提供服务。
法律遵守 道德标准 可访问性
数据隐私
本地化
公司策略
人工智能
数据输入
导航
可靠
可靠的解决方案可在一系列条件下高效可靠地运行。可靠的架构在用户期望、一致执行和随业务扩展的时间和地点可用。
可用性 性能 可扩展性
风险管理
故障缓解
吞吐量
延迟
数据建模
数据量
> 在[这里](/docs/architect/zh-cn/well-architected/guide/contributors)阅读我们的更新计划。 ## 导言 可组合解决方案调整快速,稳定性更高。设计为可组合的系统构建在有意义的单元或构建块中,它们可以彼此优雅地操作,并且可以轻松地进出服务。通过将可组合性构建到系统中,您可以通过重构或重组系统的单个单元来引入新功能或消除技术债务。可组合性支持更快、更可预测的交付周期和发布,因为团队可以通过更少的更改专注于构建和交付有意义的功能。 可组合系统使企业能够更快、更稳定地适应 — 无论刺激因素是企业内部因素还是外部因素造成的。可组合性帮助系统更具[弹性](/docs/architect/zh-cn/well-architected/guide/resilient),并帮助解决方案和架构模式更具[针对性](/docs/architect/zh-cn/well-architected/guide/intentional)。 您可以通过建立三个关键习惯来使您的 Salesforce 解决方案更具可组合性:关注点分离、互操作性和可封装性。下面,您可以通过两种方式看到这些习惯的关系:对于可组合系统中的单个单元,以及可组合系统中的多个单元。 单个可组合单元: 此图显示了可撰写主题如何通过 3 个嵌套卡片相互关联。最里面的卡片是功能单元,下一层是互操作性,外层是可打包性。 可组合系统: 此图显示了可撰写主题如何通过 3 个嵌套卡片相互关联。最里面的卡片是功能单元,下一层是互操作性,外层是可打包性。 ## 分离问题 *关注点分离*是软件工程和系统架构中的一个基本概念,它要求在一个更大的系统中识别各种关注点,这些关注点可以分为模块单元。要在系统中实现问题的强烈分离,需要为整个系统的应用程序逻辑和功能创建有意义的单元。更小的单元使应用程序交付和维护团队更容易理解如何以及在哪里进行更改,而对更大的系统的中断最少。更小的单元还使得解决[技术债务](/docs/architect/zh-cn/well-architected/guide/intentional#技术债务)时如何以及在哪里集中工作变得更加清晰,并有助于提高系统的整体[可读性](/docs/architect/zh-cn/well-architected/guide/intentional#可读性)。 通过面向业务能力和管理状态,您可以将问题更好地分离到您的 Salesforce 组织中。 ### 功能单元 对于 Salesforce 系统,分离问题的最佳方式是应用面向业务的视角来识别和组织系统中的模块化单元(或功能)。这与专注于工程的视图不同,后者根据单位的技术功能来识别单位。分离问题的面向业务的视角需要根据代码和自定义为业务和业务用户提供的服务来组织系统中的代码和自定义。采取这种方法并不意味着忽略系统中冗余或重复技术功能的可能性。相反,这意味着技术服务被清楚地映射到最终对业务透明的组织原则。 面向业务功能有助于确保业务分析和发现团队与交付团队之间的交接尽可能简单。如果应用程序构建者不知道他们的工作单位映射到您的可组合架构中的位置,您会看到一团糟,而不是可组合的应用程序环境。业务所需的最终状态与组织中模块化单元之间的映射不明确,也会增加开发团队或供应商在系统中构建冗余功能的可能性。 请考虑以下事项,以将职能单位定向到业务能力: - **从要完成的工作开始**。关注用户和业务本身要完成的工作 (JTBD)。JTBD 方法由 Tony Ulwick 倡导,它侧重于理解人们试图通过使用产品或服务实现的“工作”或真正目的。它比用户的角色相关任务或业务流程中的单个步骤更抽象。例如,重复检查和地址验证等任务可能属于“建立客户的单一视图”的更高级别功能。在您清楚了解这些更高级别的业务功能后,您可以开始将系统的一部分映射到它们。 - **面向功能,而不是报告结构**业务部门的内部层次结构不是有意义的功能或要完成的工作的代理。业务的内部层次结构的确对流程和团队结构有重大影响(更不用说预算了)。这些都是重要的后勤考虑。但业务的功能需求在比物流更高的抽象级别上运作。如果您正在创建模块来为报表结构提供服务,而不是为更高级别的功能提供服务,请注意,您可能必须采取额外的步骤来确定该模块与业务功能的关系。 - **迭代**。从与企业合作开始,确定哪些功能可用于最低可行产品 (MVP)。在您确定功能时,开始构建该 MVP。在构建时,确定对您正在创建的功能单元至关重要的流程、元数据和[事件或消息](/docs/architect/zh-cn/well-architected/guide/composable#消息传递和事件)。识别任何具有外部依赖性的进程、元数据和事件或消息。随着更多功能单元的设计,实施 [API 管理](/docs/architect/zh-cn/well-architected/guide/composable#api-管理)和[依赖性管理](/docs/architect/zh-cn/well-architected/guide/composable#依赖性管理)来构建彼此良好协作的单元(而不是构建孤立的单元 ) 。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/composable#关注模式和反模式分离)列表显示了 Salesforce 解决方案中业务功能的正确(和不佳)方向。您可以在构建之前使用这些来验证您的设计,或者确定您的系统需要重构的区域。 要了解有关 Salesforce 可用工具的更多信息,以帮助您更好地定位业务功能,请参阅[相关工具](/docs/architect/zh-cn/well-architected/guide/composable#与可撰写相关的工具)。 ### 状态管理 状态管理以整个系统中不同时间点的信息移动为中心。有效的状态管理使应用程序能够以最少的计划外或不确定的结果处理复杂的数据流或交互。在模块化 Salesforce 组织中管理状态意味着为单位内部和单位之间的逻辑流构建清晰的路径,以及为计划外的执行行为构建优雅的路径。通过状态管理,可以从模块化 Salesforce 应用程序单元形成一致的逻辑流。在大多数情况下,这需要[互操作性](/docs/architect/zh-cn/well-architected/guide/composable#交互性)来构建单位之间的信息流。 松耦合单元之间管理状态的困难通常会导致 Salesforce 中的单片应用程序开发。您可以在大型“单层流”中看到这一点,这些“单层流”是为了在单个流中编排复杂的流程而构建的。另一个例子是大型 Apex 类 , 它们通过*意大利面代码* , 或一长串一次性方法来编排复杂的过程。这些类型的应用程序架构使重构和调试变得困难,并增加了新团队成员或供应商的入职时间。它们还降低了交付给企业的应用程序的价值,因为功能不可重复使用。 考虑以下事项,以在模块化 Salesforce 组织中管理状态: - **决定何时使用有状态与无状态模式。**有状态模式会保留整个执行路径中的信息,而无状态模式不会。在松耦合的系统中,无状态模式使得组件的重构更快,副作用更少。然而,无国籍模式并非适用于所有用例。如果您正在为数据操作构建组件,状态模式有助于整个系统的数据完整性和一致性。如果您的组件满足以下任何条件,请使用有状态模式: - 了解放置在更大的执行路径中对于组件的行为至关重要 - 组件的行为需要根据下游操作的结果进行更改(例如,需要根据下游组件的回滚/错误/成功消息更改执行) - 组件需要等待来自外部或下游系统的响应才能完成工作 - **为状态信息创建有意义的类别。**_State_ 是一个模糊的术语,可以应用于 Salesforce 组织内部(及外部)如此广泛而深入的信息,以至于该术语本身几乎没有意义。因此,构建有状态模式的必要第一步是为系统中最重要的有状态执行路径(或各种有状态行为)创建有*意义*的类别。需要考虑的一些类别: - 导航和表单 - 数据库操作 - 批处理和批量操作 - 错误 - **从数 [据库事务](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#数据库操作)的角度定义数据相关的状态**。平台的内置行为将限制 Salesforce 中数据的大多数状态注意事项。请勿尝试针对或规避此行为。为它设计并使用它。设计最小化或消除分布式事务逻辑的解决方案。(有关更多详细信息,请参阅[数据处理](/docs/architect/zh-cn/well-architected/guide/automated#数据处理))。 - **识别功能单元内部(和之间)发生的状态。**当您将功能单元组装成更大的系统时,请注意您何时混合了无状态和有状态的组件行为,并防止可能在处理中产生无限循环或间隙的组合。 - **定义切换**。请考虑组件将使用什么[消息传递或事件](/docs/architect/zh-cn/well-architected/guide/composable#消息传递和事件)模式将状态相关数据传输到系统的另一个部分。确保您正在将事务意识和[处理](/docs/architect/zh-cn/well-architected/guide/automated#数据处理)构建到组件中。请勿在切换中包含任何分布式事务逻辑。 - **创建进程图和状态之间的映射。**进程图详细说明了在不同时间点通过系统移动信息的步骤。状态图显示了信息(状态)的实际变化。使用 [Salesforce 图表](/docs/architect/zh-cn/reference-diagrams/guide/kit-of-parts)形状的元数据页脚部分来捕获流程中每个步骤中不断变化的信息状态。如果您分开进程图和状态图,请确保将它们链接起来。不应将这一概念与在设计和实施期间捕获流程或系统总体状况的当前和未来状态混淆,因为这与在系统中移动的信息无关。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/composable#关注模式和反模式分离)列表显示了 Salesforce 解决方案中正确(和糟糕)的状态管理。您可以在构建之前使用这些来验证您的设计,或者确定系统中需要重构的地方。 要了解有关用于管理状态的 Salesforce 工具的更多信息,请参见[工具相关可撰写](/docs/architect/zh-cn/well-architected/guide/composable#与可撰写相关的工具)。 ### 关注模式和反模式分离 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/adaptable-separation-of-concerns)器中,发现更多关注分离的模式。
模式 反模式
功能单元 在设计标准中:
- 命名约定解决了如何表示功能单元的问题
- 存在所有当前定义的功能单元(和相关命名约定)的列表
- 存在提议增加或更改职能单位的标准
在设计标准中:
- 设计标准不存在或未涉及功能单元和用例
在您的文档中:
- 系统横向图清楚显示组织中的功能单元
- 所有文档和实施图表都清楚地显示了组件的功能单元
- 单个组件的文档包含组件的功能单元映射
- 功能单元中的所有组件均可搜索并易于查找
在您的文档中:
- 组件文档不存在
- 组件文档描述了组件所属的功能单元,但这是该功能单元定义出现的唯一位置
- 您无法搜索特定功能单元和/或搜索无助于识别功能单元中的所有组件
在您的组织中:
- 可以快速识别指定元数据的功能单元对齐方式(例如,流、Apex 类或 Lightning 页面)
- 职能单位使用业务友好术语进行标记
在您的组织中:
- 无法识别任何元数据的功能单元对齐
- 职能单位信息不一致或不准确
- 功能单元信息使用对业务用户毫无意义的工程术语进行标记
状态管理 在设计标准中:
- 有状态设计与无状态设计的用例很清楚
- 存在批准的无国籍通信模式
- 存在状态通信的批准模式
- 州/省的清除类别已存在
在设计标准中:
- 设计标准不存在或未处理状态/无国籍模式和用例
在您的文档中:
- 每个处理有状态和/或无状态通信的组件都指示已实施什么模式
- 可以搜索和查找实施特定有状态/无状态模式的所有组件
- 进程和交互图表提供有关状态类别和切换的详细信息
在您的文档中:
- 组件文档不存在
- 组件文档描述了实施的有状态/无状态模式,但这是定义出现的唯一位置
- 无法搜索特定模式和/或搜索无助于识别使用该模式的所有组件
在 Apex 中:
- 保存点和回滚行为用于所有数据操作
在 Apex 中:
- 不使用保存点和回滚行为
在流中:
- 错误路径和使用回滚记录元素
在流中:
- 未使用回滚记录元素
## 交互性 在为互操作性设计的系统中,组件可以交换信息并有效地一起工作。交互性是使模块化系统可组合而不是孤立的关键。在[松散耦合](/docs/architect/zh-cn/well-architected/guide/composable#松耦合)的系统中,交互性可能很难实现。您需要为一致的集成方法建立标准,这些集成方法不会破坏单位之间的独立性和整个系统整体[的关注分离](/docs/architect/zh-cn/well-architected/guide/composable#分离问题)。 交互性也会影响用户体验的质量。您的用户希望在一个区域中创建的数据(例如订单信息)在另一个区域中可用(例如市场营销市场活动),您的构建者希望,如果他们学习如何做某事(例如构建流或验证 API),他们会在继续下一个问题时发现熟悉的技术有效。如果不能设计互操作性,将导致冗余的架构、重复的数据、流程效率低下,并增加开发和支持成本。 您可以通过消息传递和事件以及 API 管理在模块化系统中创建互操作性。 ### 消息传递和事件 消息和事件是启用整个系统组件发送和接收信息的两种方式。在它们可以携带的内容方面,事件和消息是相似的。一个关键区别是发件人的行为。发送*消息*的组件通常会将数据发送到特定目的地,并等待收件人的某种响应。相比之下,组件会在事情发生时发出*事件*。没有具体的目的地,也没有响应的预期。这些行为差异支持不同的通信模式。消息支持有状态的通信模式,事件支持无状态的通信模式。(有关此区别的更多信息,请参见[状态管理](/docs/architect/zh-cn/well-architected/guide/composable#状态管理)。) 在消息传递和事件的协议和用例上协调团队非常重要。不明确的标准会导致整个系统的模式混合,从而导致: - 错误模式应用于特定用例时的性能和可扩展性问题 - 处理不一致,使系统对最终用户不稳定 - 更长的故障排除时间和更复杂的维护流程 在设计消息和事件以在 Salesforce 组织中创建更松散耦合的结构时,请考虑以下事项: - **识别同步和异步用例**。事件允许在系统中进行松耦合、无状态和异步通信。消息传递允许更紧密的控制、有状态和同步的通信模式。在决定何时使用消息或事件时,您需要决定通信是否需要同步(并可能阻止)还是异步和非阻止。 - **仔细定义数据结构**。组件在它们之间传递的信息结构是保持松散耦合的系统易于管理和一致的重要部分。(有关更多信息,请查看 [API 管理](/docs/architect/zh-cn/well-architected/guide/composable#api-管理)。)设计消息或事件时的一个关键注意事项是信息的结构可能需要更改的频率。一旦消息或事件结构在您的系统中定义和实施,就很难处理更新,特别是如果事件或消息已经被用来向外部系统发送信息。 - **正确大小的消息**。通常,最佳实践是保持消息大小较小。但是,在消息*大小*和消息*量*之间也有平衡作用。系统可以更快地处理更少的数据。处理行为会产生大量额外开销,因为收件人必须解压缩、解释并确定如何处理他们收到的信息。这些步骤可能需要很少的时间来完成,但它们会大规模地累积起来并给系统造成负担。避免设计需要系统中的组件连续处理许多小消息来完成一件工作。要正确调整消息的大小,请考虑为下游组件设计最少的数据,以便成功处理它们发送的信息并采取行动,同时不要假设每个下游组件都能够请求或处理大量的后续消息。 - **设计可扩展性**。松散耦合的组件可以更容易地扩展您的架构。消除跨组件依赖性使团队能够致力于提高任何单个组件的性能或可扩展性,而对其他组件的影响最小。然而,松散耦合的组件也会大规模引入架构的复杂性(特别是在[管理状态](/docs/architect/zh-cn/well-architected/guide/composable#状态管理)方面 ) 。确定出于有效用户体验或数据完整性原因需要更紧密耦合逻辑或依赖性的进程,不要尝试在这些进程中引入基于异步/事件的模式。使用基于同步/消息的模式和适当的错误处理。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/composable#交互模式和反模式)列表显示了 Salesforce 解决方案中正确(和差)的消息传递和事件的外观。您可以在构建之前使用这些来验证您的设计,或者确定系统中需要重构的地方。 要了解有关 Salesforce 消息传递和事件工具的更多信息,请参阅[工具相关可撰写](/docs/architect/zh-cn/well-architected/guide/composable#与可撰写相关的工具)。有关为给定用例选择事件模式或工具的更多信息,请参见[架构师指南](/docs/architect/zh-cn/decision-guides/guide/event-driven#key-takeaways)。 ### API 管理 在 Salesforce 解决方案中构建适当的应用程序编程接口 (API) 管理可使系统的单个组件遵循可预测的通信模式。Salesforce 提供用于与 Salesforce 外部系统通信的内置安全 API。(有关 Salesforce 平台 API 的更多信息,请查看[架构基本知识](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#平台-api)。) Salesforce 解决方案中有效的 API 管理是构建真正可组合架构的关键。它使 Salesforce 组织中的组件能够有效地发送和接收信息。它还使解决方案生成器能够遵循明确的协议,了解他们构建的组件如何与系统中的其他组件通信,并帮助他们尽早发现糟糕的实施。此外,它使解决方案构建者能够更专注于他们正在构建或重构的特定组件,从而提高生产率和质量。 企业级的 API 管理是一个单独的主题,最好使用全面的 API 管理工具来实现。(有关此主题的 MuleSoft 视角的更多信息,请查看[什么是 API 管理](https://www.mulesoft.com/resources/api/what-is-api-management#:~:text=API%20management%20is%20the%20process,create%20are%20consumable%20and%20secure.)。) 在 Salesforce 解决方案中构建 API 管理功能时,请考虑以下事项: - **将 API 视为通信的可*预测*模式或合同。**输入或输出变量的数据类型、变量名称、应该(或不应该)以给定模式显示的信息 — 这些是有效 API 管理的关键。这些定义应该出现在您的设计标准中,团队应该能够通过您的文档找出这些定义是如何在系统的特定部分实施的。查看将更改从新开发合并到集成环境的困难的一种方式是将它们视为您实施 API 通信不力的证据(或者可能根本没有 API 定义)。 - **请勿将 API 思维限制为仅编码。**在此上下文中定义 API 的是该消息中消息结构和变量的一致性。只要保持一致性,API 就可以在代码以及声明性自定义中实施,例如模块化自动启动(或平台事件触发)流,甚至是流模板。您在代码中与流中定义什么的决策不是基于 API 实施,而是基于可[封装性](/docs/architect/zh-cn/well-architected/guide/composable#可打包性)和可[测试性](/docs/architect/zh-cn/well-architected/guide/resilient#应用程序生命周期管理)。 - **保持生命周期和版本简单**。与应用程序开发的所有部分一样,API 有一个生命周期:定义、构建、测试、部署和维护(包括停用)。Salesforce 平台 API 在一个日历年内发布多个版本,因为平台的发布周期很快。(您可以在 Salesforce [架构基础](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#平台-api)中阅读有关此行为的更多信息。)这意味着平台 API 的生命周期相当复杂,因为需要维护特定 API 的多个版本,可供 Salesforce 客户使用。此复杂性级别适用于 PaaS 用例,但它很可能是平台内解决方案架构不必要的复杂性(请参阅:可[读性反模式](/docs/architect/zh-cn/well-architected/guide/intentional#可读性模式和反模式))。专注于定义 API 的明确目的(例如,错误处理)和明确的基准定义。目标是每个 API 只有一个版本。 - **使您的 API 可发现、可访问和管理。**[记录 API,](/docs/architect/zh-cn/well-architected/guide/intentional#设计标准)以便潜在消费者可以轻松找到可用的 API。API 需要作为[功能](/docs/architect/zh-cn/well-architected/guide/composable#功能单元)环境的一部分平稳运行。 - **迭代**。专注于一次仅定义和实施一个内部 API。这样,您可以专注于快速迭代 API 定义,为*一个*支持的版本找到正确的形式,并从实施经验中建立最佳实践。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/composable#交互模式和反模式)列表显示了 Salesforce 解决方案中正确(和差)的 API 管理。您可以在构建之前使用这些来验证您的设计,或者确定您的系统需要重构的区域。 要了解有关 Salesforce 可用工具的更多信息,以帮助您建立更好的互操作性,请参阅[相关工具](/docs/architect/zh-cn/well-architected/guide/composable#与可撰写相关的工具)。 ### 交互模式和反模式 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/adaptable-interoperability)器中,发现更多互操作性模式。
模式 反模式
消息传递和事件 在设计标准中:
- 对于何时使用同步模式(消息传递)和异步模式(事件),存在明确的标准
- 事件和消息结构存在明确的标准
在设计标准中:
- 设计标准不存在,或者缺乏同步与异步模式的明确标准,以及消息或事件结构的明确标准
在您的组织中:
- 用于内部系统消息传递的平台事件被清楚地标记
- Salesforce 流工具引用全系统消息传递或事件服务
- 一致的消息传递和事件模式出现在流和代码中
在您的组织中:
- 用于内部系统消息传递的平台事件未明确标记或不存在
- 流和代码中出现不同的消息传递和事件模式策略
在 Apex 或 LWC 中:
- 自定义事件定义的范围有限(代码中未定义系统范围的事件或消息)
- Apex 中的系统范围消息传递或事件服务以使它们在 Salesforce 流工具中可用的方式注释
在 Apex 或 LWC 中:
- 系统范围的消息和/或事件结构在 Apex 或 JavaScript 中定义
- Apex 中定义的系统范围事件或消息结构在流等工具中不可用
API 管理 在设计标准中:
- 存在跨组件通信的清除协议(即 API)
- 协议/API 在生成器可以搜索和查找的逻辑组中概述
- 协议/API 定义了变量数据类型、变量名称、必填或可选内容,并清楚地描述了何时使用
在设计标准中:
- 设计标准不存在或未定义 API 和用例
在您的文档中:
- 每个组件的文档都清楚地列出了哪些 API/通信协议已经实施
- 可以搜索特定 API 或协议,并确定实施该协议的组件
在您的文档中:
- 组件文档不存在
- 组件文档描述了在组件中实施的 API,但这是 API 定义出现的唯一位置
- 无法搜索特定 API 或协议和/或搜索无助于识别已实施 API 或协议的组件
在您的组织中:
- 内部通信的 API 消息格式和变量使用自定义元数据类型定义
- 内部通信的 API 消息格式和变量由平台事件定义
- 代码和声明性自定义引用适当的自定义元数据类型(或平台事件),以便发送或接收信息
在您的组织中:
- 系统组件之间的通信(代码和声明性自定义)是临时的
- API 专为 Salesforce 与外部系统之间的通信定义
## 可打包性 在 Salesforce 组织中创建可打包性意味着组织中的功能来自可作为软件包独立可靠地开发和部署的单元。理想情况下,这些单元被定义为[第二代](https://developer.salesforce.com/docs/atlas.en-us.218.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_plan_pkg_types.htm)软件包的类型(解锁软件包或 ISV 受管软件包 ) 。注意:因为架构良好的解决方案专门使用这些软件包类型,所以这里不包括第一代受管软件包。 在 Salesforce 组织中定义[关注分离](/docs/architect/zh-cn/well-architected/guide/composable#分离问题)并创建功能单元是一回事。清晰地解开和管理依赖性是另一回事,可以成功地将这些单元作为软件包工件进行版本化。实现该级别的稳定性和元数据隔离需要相当程度的 DevOps(和架构)成熟度。它还加快了开发时间,改善了应用程序生成器体验,并为发布和发布管理带来了可预测性和控制力。并非每个组织都能够支持定义、维护和开发有效软件包所需的基础架构。但实现可打包性应该是几乎所有 Salesforce 组织的最终目标。 通过关注松耦合和依赖性管理,您可以在 Salesforce 解决方案中构建可打包性。 ### 松耦合 在松耦合的系统中,单个部件不会彼此紧密相连。可组合系统的许多优点都来自松耦合。在可封装系统中,实现软件包之间的松耦合(和安装组织)将使您能够拥有定义明确的软件包,并为使用软件包的团队提供更高效的开发周期。 在 Salesforce 平台上,您可以构建[紧密耦合到特定组织](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_org_dependent.htm)的软件包。随着您封装成熟度的进展,此功能有助于定义功能单元并在贵组织中尝试正确[分离关注](/docs/architect/zh-cn/well-architected/guide/composable#分离问题)。但是,如果您选择这种方法,您将不会意识到真正可封装元数据的好处,包括源驱动的开发、使用版本的能力和工件稳定性。相反,您很可能会继续遇到紧耦合系统的缺点,包括: - 导致停机和性能问题的单点故障 - 部署缓慢、不可预测 - 困难、复杂的调试和故障排除周期 - [规模](/docs/architect/zh-cn/well-architected/guide/reliable#可扩展性)和[绩效](/docs/architect/zh-cn/well-architected/guide/reliable#性能)问题 任何可封装 Salesforce 系统的最终目标是松耦合软件包。 在您将 Salesforce 元数据分为有效软件包时,请考虑以下事项: - **哪些自定义是数据与元数据**在可打包性方面,Salesforce 平台对数据和元数据的处理方式非常不同。了解贵组织中哪些功能是[元数据或数据](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#元数据与数据)非常重要。您不能将数据包含在任何封装单元中。当您决定从哪里开始将功能抽象到封装单元中时,您的团队将需要决定存储为数据的自定义是应该完全从软件包中排除,还是应该重构到基于元数据的实施中。 - **打包如何影响团队**。Salesforce 打包的一个逻辑现实是,生产和发布软件包版本的大部分工作需要具备 Salesforce CLI 和/或 CI/CD 技术的技能。这意味着低代码和编程自定义都需要时间和关注能够使用软件包相关 DevOps 技术的人员。根据您的团队管理功能交付的方式,软件包采用可能会给组织内的不同团队带来显著的减缓或阻碍。您必须确定团队是否能够通过打包管理功能交付,并制定计划来解决任何技能或人员不足的问题。解决方案可能包括采用成对编程或为开发环境实施 CI/CD 作业。 - **打包将如何改变环境策略**在软件包驱动的开发生命周期中,早期工作应在[临时组织中](https://developer.salesforce.com/docs/atlas.en-us.238.0.sfdx_setup.meta/sfdx_setup/sfdx_setup_next_steps.htm?q=scratch%20org)完成。这些临时源代码驱动的开发环境允许更快、更迭代的周期。它们还支持开发团队进行更精细的环境访问控制,并与生产更好地隔离。软件包对未封装元数据或仅存在于 Sandbox 或生产环境中的数据的依赖性越大,团队就越不可能实际使用临时组织。您可以[在 Sandbox 中启用源跟踪](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_source_tracking_sandboxes.htm),以允许在非临时组织环境中使用源驱动的开发模式,但您的开发团队不会从临时组织的速度和迭代速度中受益。 - **软件包版本与发布版本的关系**。计划开发软件包版本的频率和阶段。软件包版本请求在 24 小时滚动的基础上受到限制(每个组织)。作为一般最佳实践,只有当您确信软件包内容不需要更改时,才对软件包进行版本化。理想情况下,您将在质量保证流程完成后配置软件包版本。请勿允许开发团队将软件包创建请求的成功或失败用作对软件包边界定义的“测试”。有几种方法可以做到这一点,而无需尝试对软件包工件进行版本化。 - **理想的最终状态应该支持什么**。理想的打包策略允许快速开发和交付受控、稳定的 Salesforce 版本。在整个组织中定义太多的软件包可能会给开发团队带来新的复杂性和瓶颈。过度模块化的组织也会导致发布缓慢和困难。从构建和发布一个有意义软件包的几个版本开始。增量派生跟进软件包。当您的发布节奏很好地服务于您的业务时,停止引入软件包。如果业务需求发生变化或发布质量下降,随着时间的推移,重构软件包。理想的软件包结束状态是主观的。 无论您决定如何定义软件包,您都只能通过有效的[依赖管理](/docs/architect/zh-cn/well-architected/guide/composable#依赖性管理)来成功版本松耦合的软件包。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/composable#可封装性模式和反模式)列表显示了 Salesforce 打包的正确(和差)松耦合的外观。您可以在构建之前使用这些来验证您的设计,或者确定您的系统需要重构的区域。 要了解有关 Salesforce 工具的更多信息,以帮助您构建更多可打包性,请参阅[工具相关可撰写](/docs/architect/zh-cn/well-architected/guide/composable#与可撰写相关的工具)。 ### 依赖性管理 在 Salesforce 解决方案的上下文中,依赖性管理意味着识别和构建软件包中的元数据与这些软件包将被安装到的组织中元数据之间的关系。依赖性管理是开发稳定软件包工件的关键部分。 依赖性与创建完全分离、[松散耦合](/docs/architect/zh-cn/well-architected/guide/composable#松耦合)的功能单元的努力背道而驰。在理想的工程状态下,松散耦合的系统在单元之间没有依赖性。但在现实世界中,消除所有依赖性并不实际。 通常,要使系统[可读](/docs/architect/zh-cn/well-architected/guide/intentional#可读性)和使用业务友好[功能单元](/docs/architect/zh-cn/well-architected/guide/composable#功能单元)之间保持平衡,需要在系统中各单元之间的完美隔离方面进行权衡。更务实地讲,Salesforce Platform 的[标准功能](/docs/architect/zh-cn/well-architected/guide/intentional#标准与自定义功能)提供的核心服务为任何 Salesforce 解决方案创建了关键的净正依赖性。许多内置的可扩展性、性能和安全性优势来自它们与平台集成的深度。在设计可封装的 Salesforce 解决方案时,重要的是要记住软件包依赖性本质上不是坏的。依赖关系管理差*是*不好的。 使用 Salesforce 打包进行有效的依赖性管理意味着开发和维护团队可以: - 更快地加入新项目,环境访问权限有限 - 快速开发和测试更改 - 了解如何在更小的具体承诺中提供复杂的功能 - 控制发布节奏,减少系统维护/发布中断时段 - 在任何环境中可预测地回滚不利变化 使用 Salesforce 进行依赖性管理的技术非常简单: - 使用[消息传递和事件](/docs/architect/zh-cn/well-architected/guide/composable#消息传递和事件)处理组件之间有状态或无状态信息的优雅切换。 - 使用自定义元数据类型提供动态运行时信息,并支持依赖注入模式。 - 让 Apex 开发人员使用[抽象或虚拟类](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_extending.htm)。 最后,您需要决定贵组织中允许的声明性和编程性开发的设计模式。最重要的注意事项(在架构上)是定义您想要在哪些方面增加工程复杂性,以便减少依赖性,以及您需要在哪些方面容忍更多依赖性,以简化应用程序生成器工作流。 当您将依赖性管理策略构建到软件包中时,请考虑软件包单元的两个主要组织原则:水平和垂直。 - **水平边界**。在水平模式中,多个软件包可能需要的功能被抽象到水平层中。然后,水平层成为常见功能的来源,并通过声明的依赖关系访问。最小化软件包之间的冗余功能优于最小化依赖性。 - **垂直边界**。垂直模式最大化了系统各部分之间的隔离和松散耦合。共享功能有限,类似的工作可能会跨单位显示。依赖性受到严格限制,以便最大限度地隔离软件包单元。 请注意,这不是一个要么/要么的决定。您可以根据需要混合垂直和水平模式。通常,从软件包开始的最快方法是创建水平服务层。随着软件包采用的规模和复杂性的增长,抽象更多垂直单元将有助于简化复杂的环境设置流程或开发人员入门。 例如,具有两个功能单元(A 和 B)的系统可以使用以垂直、水平和垂直-水平混合模式排列的软件包依赖性来构建。 该图显示了两个软件包 A 和 B,它们被构建为没有共享依赖性(垂直切片),被构建为有许多常见的服务(水平)和每个服务的混合(混合)。 不论您选择的软件包组织模式如何,请记住一些绝对值: - **请勿在软件包之间重复元数据。**多个软件包需要的元数据应抽象为一个或多个声明为依赖项的软件包。 - **利用 Salesforce Platform 元数据的内置依赖性。**对于应用程序生成器,Salesforce Platform 提供的内置服务提供了大量可以快速配置的功能。其中许多服务具有内置的依赖性,使它们难以抽象为低级别的功能单元。对于给定的元数据类型,您需要了解它在[内置依赖关系](https://developer.salesforce.com/blogs/2018/06/lets-talk-deployment-and-reasons-why-they-succeed-or-fail)中所处的位置,并使用这种了解来[定义软件包依赖](https://developer.salesforce.com/blogs/2018/06/working-with-modular-development-and-unlocked-packages-part-2)链。不要通过尝试将松散耦合强制纳入具有大量内置依赖性的标准平台功能来开始软件包采用。当您达到更高的功能时,它将增加复杂性(而不是价值)。这也是另一种归入[标准和自定义](/docs/architect/zh-cn/well-architected/guide/intentional#标准与自定义功能)[反模式](/docs/architect/zh-cn/well-architected/guide/intentional#可维护性模式和反模式)的方法。从底部(最低的依赖性)向上封装元数据,并随着时间的推移进行迭代。 - **留意依赖链**。避免创建软件包依赖链,这将要求开发人员在任何时候将他们所做的更改拆分成许多不同的软件包。 - **想想什么对源控制有意义**在源控制中管理软件包有两种基本方法。第一个是单个*monorepo*,软件包隔离在文件夹中。第二个是多个存储库,软件包隔离在自己的存储库中。长期管理每种源策略都很复杂。就开发人员入门而言,垂直边界在多个存储库模式中效率更高。水平边界在单层建筑中更容易理解。同样,随着架构的成熟,您可以混合和匹配策略。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/composable#可封装性模式和反模式)列表显示了 Salesforce 软件包中正确(和差)的依赖管理是什么样子的。您可以在构建之前使用这些来验证您的设计,或者确定您的系统需要重构的区域。 要了解有关适用于依赖管理的 Salesforce 工具的更多信息,请参阅[工具相关可撰写](/docs/architect/zh-cn/well-architected/guide/composable#与可撰写相关的工具)。 ### 可封装性模式和反模式 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/adaptable-packageability)器中,发现更多可封装性模式。
模式 反模式
松耦合 在设计标准中:
- 命名约定解决了如何表示软件包单位的问题
- 可以搜索并查找所有当前定义的软件包单元(和相关命名约定)的列表
- 存在建议软件包单元添加或更改的标准
-(可选)自定义设置的所有批准的用例都清楚地列出(如果有)
在设计标准中:
- 设计标准不存在或未处理软件包单元和用例
在您的组织中:
- 自定义元数据类型为代码和声明性自定义提供动态运行时信息
- 不存在自定义设置或自定义设置很少,并且没有与封装功能相关的设置
- 不存在自定义对象,以便为代码或声明性自定义提供动态运行时信息
在您的组织中:
- 使用自定义设置
- 自定义对象的存在是为了提供代码或声明性自定义的动态运行时信息
- 自定义元数据类型未用于(或未一致使用)为代码和声明性自定义提供动态运行时信息
在 Apex 中:
- 使用抽象或虚拟 Apex 类定义常见服务和模板代码
- 依赖于动态运行时信息的方法引用适当的自定义元数据类型
在 Apex 中:
- 常见服务和模板代码不易与其他类区分
- 跨类和方法的内部引用难以遵循,并且在整个代码库中不一致
- 方法没有使用一致的方法来访问动态、运行时信息,或者方法没有查询运行时行为信息的自定义对象,或者代码引用自定义设置
在源控制和开发环境中:
- package.xml 文件仅出现在早期阶段或概念验证项目清单中
在源控制和开发环境中:
- package.xml 文件用于控制元数据部署
在软件包中:
- 依赖于组织的解锁软件包仅用于早期阶段或概念验证实验
- 在生产或 Sandbox 中未定义非受管软件包
在软件包中:
- 所有软件包都是依赖于组织的解锁软件包
- 非受管软件包在生产或 Sandbox 中定义
依赖性管理 在设计标准中:
- 存在声明依赖性的标准
- 存在引入或修改依赖性的标准
在设计标准中:
- 设计标准不存在或未涉及如何声明依赖性
在源控制中:
- 解锁软件包的软件包版本使用别名 (LATEST) 在 sfdx-project.json 清单中声明依赖性
- 开发人员可以从源代码控制中创建临时组织并成功部署软件包元数据
在源控制中:
- 解锁软件包的软件包版本在 sfdx-project.json 清单中明确声明(无 lateST 别名)
- 开发人员无法使用源代码控制成功使用临时组织
在软件包中:
- 软件包之间没有重复的元数据
- 对于软件包开发,所有早期开发工作都在临时组织中进行
在软件包中:
- 通过在不同软件包中复制元数据来规避依赖性
- 早期软件包开发发生在 Developer Sandbox 中,或者早期软件包开发不能发生在临时组织中
另请参阅:松耦合
## 与可撰写相关的工具
工具描述分离问题交互性可打包性
Apex REST Web Services通过 REST 向外部应用程序公开 Apex 类和方法X
Apex SOAP Web Services通过 SOAP 向外部应用程序公开 Apex 类和方法X
变更数据捕获将更改发布到 Salesforce 记录X
自定义元数据类型定义可重用、可自定义、可封装的功能X
装饰师将函数或属性公开为 apiXX
Dev Hub管理临时组织、第二代软件包和 Einstein 功能。XXX
通用事件(传统)*发送与 Salesforce 数据更改无关的自定义事件X
Lightning数据服务跨组件缓存和共享数据XX
Metadata API在 Salesforce 环境之间部署自定义X
元数据覆盖范围报表确定几个渠道之间支持的元数据覆盖范围 X
MuleSoft Composer使用单击而不是代码为数据构建流程自动化X
出站消息在更新字段值时向外部端点发送消息X
平台事件 发送包含近乎实时事件数据的安全和可扩展的消息X
发布/订阅 API订阅平台事件、变更数据捕获或实时 Event MonitoringX
PushTopic 事件(原有)*发送和接收与用户定义的 SOQL 查询匹配的数据变更通知X
Salesforce CLI与 Salesforce 组织协作时开发和构建自动化X
Salesforce Diagrams创建图表以显示业务功能和技术详细信息X
适用于 Visual Studio 代码的 Salesforce 扩展(展开)适用于 Salesforce 开发的官方 VS Code 扩展X
临时组织将 Salesforce 代码和元数据部署到一次性组织X
第二代受管软件包为 AppExchange 开发和分发应用程序X
工具 API为 Lightning 平台应用程序构建自定义开发工具或应用程序X
解锁的软件包组织元数据、封装应用程序或扩展 AppExchange 应用程序X
*Salesforce 将继续在当前功能范围内支持 PushTopic 和通用事件,但不打算对此技术进行进一步投资。
## 与可撰写相关的资源
资源描述分离问题交互性可打包性
对数字集成的初步了解为连接概念开发通用语言X
将域驱动的设计应用于 Salesforce围绕业务功能定位解决方案X
第二代软件包的最佳实践了解 2GP 打包模式和实践X
受管软件包中可用的组件了解受管软件包元数据组件X
设计标准模板为您的组织创建设计标准XXX
事件驱动架构决策指南比较事件驱动的架构模式和工具X
事件反模式确定使用事件时要避免的反模式X
如何设计消息驱动和事件驱动的 API阅读 MuleSoft 开发指南中的差异XX
了解要完成的作业框架在 Trailhead 上探索 JTBDX
在 B2C Commerce 中管理全球状态在组件之间轻松传递数据以保持状态X
消息传递指南交流相关信息,创造欢乐时刻X
消息传递类型根据用户交互的性质了解不同的消息传递类型X
元数据类型了解 Salesforce 组织中不同类型的元数据XX
移动应用程序通知类型了解 Salesforce 移动应用程序的通知类型X
优化视图状态在 Visualforce 页面中维护状态X
Salesforce 开发人员体验 (DX)在 Lightning 平台上管理和开发应用程序XXX
不支持的元数据类型识别在元数据 API 中不可用的组件X
## 告诉我们您的想法 帮助我们保持 Salesforce 架构合理与您相关;参加我们的[调查](https://sfdc.co/bxNtvh),以提供有关此内容的反馈,并告诉我们您接下来想要看到的内容。 > 在[这里](/docs/architect/zh-cn/well-architected/guide/contributors)阅读我们的更新计划。 ## 导言 可**适应**的 Salesforce 解决方案会随业务发展。设计良好的可**适应**解决方案具有弹性和可组合性。 **弹性**解决方案可以很好地处理变化。
可**组合**解决方案可以快速调整,并具有更高的稳定性。 业务变革的需求可能来自许多方面:客户请求、市场或行业中断或数字转型机会。有时,更改很小。有时,变化是深刻的。在最深刻的层面上,变化可能需要企业重新考虑和转变他们运营的核心原因,并重新评估他们的客户提供的内容、方式和位置。可**适应**的架构不仅有助于企业从中断中生存和恢复,还为企业在深刻变革中创新和繁荣创造了潜力。 创建可**适应**的系统需要深度创新和精确的建筑思维。您必须从准确了解业务的短期和长期轨迹开始。在您评估单个实施细节时,您必须考虑多个维度和详细信息级别的影响。您必须从人员、流程和技术方面进行思考。对于当前状态和任何未来状态,您必须同时预测宏观和微观层面的影响。 以下部分为可**适应**解决方案架构的每个核心行为提供了更深入的指导。 ## 适应性概述
弹性
弹性解决方案可以很好地处理变化。弹性架构能够以可预测的方式快速恢复到预期行为和运营。
应用程序生命周期管理 事件响应 连续性计划
发布管理
环境策略
测试策略
恢复时间
分类能力
监控和警报
业务连续性
技术连续性
可合成
可组合解决方案调整快速,稳定性更高。可组合架构构建在彼此正常操作的单元中,并且可以在服务中交换和停用。
关注分离 交互性 可打包性
功能单元
状态管理
消息传递和事件
API 管理
松耦合
依赖性管理
> 在[这里](/docs/architect/zh-cn/well-architected/guide/contributors)阅读我们的更新计划。 ## 导言 可靠的解决方案有效和可靠地运行。它们可用、表现一致,并且能够扩展以支持不断增长的业务。 可靠的系统不会出错,行为如预期,并及时提供结果。相反,不可靠的系统速度缓慢,行为不如预期,或者在关键时刻出现故障。不可靠的系统提供的信息不准确,因此利益相关者不能 Trust 它们来做出业务决策。 系统可靠性不是恒定的。如果不为增长而设计,如今可靠的系统可能会变得不可靠。不可靠的系统可能需要昂贵的维护、重构或重新实施,从而将资金从战略项目中转移。 通过关注三个原则:[可用性](/docs/architect/zh-cn/well-architected/guide/reliable#可用性)、[性能](/docs/architect/zh-cn/well-architected/guide/reliable#性能)和[可扩展性](/docs/architect/zh-cn/well-architected/guide/reliable#可扩展性),提高 Salesforce 解决方案的可靠性。[Salesforce 的可扩展](https://www.salesforce.com/platform/application-scaling-performance-testing/)性产品套件提供本机功能,帮助架构师实施可靠的实施。 ## 可用性 可用性是衡量系统运行时间的百分比。Salesforce 平台处理大多数[基础设施级](https://trust.salesforce.com/)可用性问题。但是,您在平台上构建的解决方案的可用性以及您的客户所体验的解决方案的可用性是一项共同的责任。重要的是要了解,即使 Salesforce 具有[高可用性](https://trust.salesforce.com/en/#systemStatus),服务中断的风险也永远不会为零。 架构师必须为 Salesforce 服务中断做好准备,例如计划的维护或不可预见的情况。除了服务中断之外,还要考虑如何保持高性能并与业务一起发展。狭隘的架构选择会导致长期可用性问题。 在构建解决方案*之前*,请考虑设计阶段的可用性。延迟可用性架构的时间越长,可用性问题的实际成本从长远来看就越高。为了降低潜在风险,请在测试环境中使用 Salesforce 扩展测试。在该环境中,您可以在生产中部署代码之前在生产规模上进行测试。 架构师使用业务语言,为业务利益相关者构建技术问题,以获得支持并确定可用性工作的优先级。为了降低潜在风险,请在测试环境中使用 Salesforce 扩展测试。在该环境中,在生产中部署代码之前,您可以在生产规模上进行测试。 通过[风险管理](/docs/architect/zh-cn/well-architected/guide/reliable#风险管理)和[故障缓解](/docs/architect/zh-cn/well-architected/guide/reliable#故障缓解),您可以构建 Salesforce 解决方案的高可用性。 ### 风险管理 在 Salesforce 架构的上下文中管理风险涉及识别对系统运行、用户(包括员工、合作伙伴和客户)以及业务流程的潜在危害。通常,进行风险分析的正式过程属于项目经理的职责范围。作为架构师,确保风险分析充分代表技术和业务利益相关者的关注。您还负责确定需要根据生产高峰热点进行规模测试的关键业务用例。 风险管理中一些最大的陷阱来自没有投入足够的时间和思考。团队通常会跳过风险评估,或者将解决[备份和还原](/docs/architect/zh-cn/well-architected/guide/resilient#构建备份和还原功能)问题与全面的风险评估和缓解措施混为一谈,而备份和还原是降低数据完整性风险的重要部分。 要评估 Salesforce 解决方案的风险,使用这些方法: - **使用风险评估框架**。一些大型企业可能已经建立了相关的风险矩阵。如果您有,请使用它们来确定如何分类危险、要收集哪类信息、您需要为补救准备什么等等。如果您还没有风险评估框架,请从信誉良好的来源找到并使用它。 - **从客户的角度评估影响严重性和风险类别**Proactive Monitoring 和规模中心提供可配置的警报和仪表板。它们不断评估性能和可扩展性风险,并减少您对手动核对清单的依赖。Customer Trust 和感知是每个业务的关键。就业务影响而言,对于联系到客户的问题,风险通常大于联系不到客户的问题。客户可能不会像内部团队那样思考或感知风险。如果客户无法登录帐户,他们可能不关心问题的根本原因。他们最关心自己的即时体验。 - **确定风险优先级**。理想情况下,每个风险都与可靠的缓解和应对计划相关联。实际上,您将需要随着时间的推移解决一些差距。采用“尽早交付价值并迭代”的方法非常重要。您和您的交付和维护团队在指定时间只能承担这么多工作。在 Salesforce 中,常见的说法是“如果一切都重要,没有什么是重要的。”我们使用 V2MOM 来确定整个公司、团队以及每个人工作的优先级和一致性。(您可以在 Trailhead 上[了解更多关于](https://trailhead.salesforce.com/content/learn/modules/manage_the_sfdc_organizational_alignment_v2mom/msfw_oav2m_writing_a_v2mom) V2MOM 的信息。 )使用您的风险评估,这让您有机会与利益相关者合作,确定最重要的风险管理工作的优先级并致力于这项工作。使用扩展测试 - 创建测试计划来识别风险,以便使用扩展测试确定优先级并缓解这些风险。 使用 Proactive Monitoring 检测早期可用性风险。它显示异常,例如 API 请求限制峰值、行锁定错误或并发 Apex 失败,在问题升级为服务中断之前提供可操作的见解。 可用性[模式和反模式](/docs/architect/zh-cn/well-architected/guide/reliable#可用性模式和反模式)显示了 Salesforce 解决方案中正确和糟糕的风险管理。在构建或确定系统中的重构区域之前,请使用模式来验证您的设计。 要了解有关风险管理的 Salesforce 工具的更多信息,请参阅[Salesforce Tools for Reliability](/docs/architect/zh-cn/well-architected/guide/reliable#salesforce-可靠性工具)。 ### 故障缓解 故障点是使系统不可靠的漏洞。良好的故障缓解不是精确定位每个潜在的故障点。相反,它涉及快速分类并确定故障点的优先级,以便维护和支持团队可以做出有效响应。请参阅[事件响应](/docs/architect/zh-cn/well-architected/guide/resilient#事件响应)。 要制定更好的故障缓解策略: - **从人员、流程和技术的角度对失败点的触发器进行分类。**正如您从人员、流程和技术的角度对风险进行分类一样,将相同的思维应用于如何触发高优先级故障点。这种方法可以帮助您识别潜在的失败触发器,并制定和组织对它们的响应。有时,您可以根据触发器的分类方式,使用类似的缓解方法缓解看似不同的故障触发器。
触发器分类/类型 缓解
人员 策略
进程 行动手册、连续性计划
技术 冗余
- **确定基本、中级和成熟的缓解措施是什么样子**制定缓解战略需要时间。定义缓解级别,以帮助您和团队了解您可以立即将控制放在何处,以及如何随着时间的推移集中精力。请始终寻找在缓解方法中使用自动化的机会,尽可能早。为了说明这种方法在实践中是什么样子,本示例显示了以人为本的触发器,以及基于策略的缓解在基本、中级和成熟级别上是什么样子。
触发器 缓解 基本 中间 成熟
新员工或离职员工的用户访问权限更改 服务级别协议 (SLA) 和配置或取消配置用户的要求 根据手动更改的 SLA,手动配置和取消配置用户。 根据计划更改的 SLA,通过计划作业处理用户更改。 通过 SSO/IDM 解决方案自动配置和取消配置用户。
除了使用架构行动手册和连续性计划之外,还要使用 Proactive Monitoring。通过 Proactive Monitoring,您可以设置对失败触发器的实时提醒,例如登录失败、CPU 超时异常或并发 API 请求错误。这种警报方法通过确保技术和业务利益相关者及时了解情况以减少故障的影响来增强故障缓解。 可用性的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/reliable#可用性模式和反模式)显示了 Salesforce 解决方案中正确和较差的故障缓解措施。在构建之前,使用它们来验证您的设计,或者确定要重构的系统的位置。 要了解有关适用于故障缓解的 Salesforce 工具的更多信息,请参见[工具相关可靠](/docs/architect/zh-cn/well-architected/guide/reliable#salesforce-可靠性工具)。 ### 可用性模式和反模式 此表显示了要在贵组织中查找或构建的模式选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/trusted-availability)器中,发现更多可用性模式。
模式 反模式
风险管理 在您的业务中:
- 正在使用既定风险评估框架。
- 风险分为人员、流程和技术领域。
在您的业务中:
- Salesforce 的风险评估框架是临时的。
- 风险未明确识别。
在您的文档中:
- 根据客户影响对风险严重性进行分类和评估。
- 风险缓解和应对计划优先。
在您的文档中:
- 评估风险严重性或类别时,不考虑客户视角。
- 风险缓解和响应计划尝试捕获可以想象的每个风险。
故障缓解 在您的组织中:
- 故障点触发器及其相应的缓解计划按人员、流程和技术分类。
- 缓解控制立即到位,随着时间的推移而成熟,并尽早纳入自动化。
- 为了确保最佳可扩展性,在将更改发布到生产之前,需要完成全面的测试和优化。
- 在业务关键事件之前,根据 SLA 进行规模测试和优化。
在您的组织中:
- 故障点触发器未分类。缓解方法不存在或仅临时使用。
- 缓解控制措施未重新审核或改进。
- 自动化不用于缓解。
监控和可观察性 在您的组织中:
- 对于检查和异常检测,启用 Proactive Monitoring。
- 为保持可见性,Proactive Monitoring 警报与规模中心集成。
在您的组织中:
- 仅执行手动健康检查,没有持续监控。
## 性能 系统架构性能是衡量系统处理量(吞吐量)和响应速度(延迟)的度量。您通常通过生产测试和监控了解系统的性能。 绩效系统会在每个预期的需求级别及时完成流程。 性能不佳与更高的延迟和更低的吞吐量并存,这将导致更低的生产力和更高的用户挫折感。修复性能问题迫在眉睫,因为它们会导致失去客户 Trust 和经济损失。 您可以通过优化吞吐量和延迟来提高解决方案的性能。 > 注意:吞吐量和延迟优化是改善系统处理和响应的基本方面。然而,重要的是要记住,整体系统性能还取决于您构建[规模](/docs/architect/zh-cn/well-architected/guide/reliable#可扩展性)的能力。您必须在设计时考虑这两个维度。 ### 吞吐量 在 Salesforce 架构的上下文中,吞吐量是系统在给定时间间隔内可以完成的并发请求的数量。专为吞吐量设计和优化的客户 Salesforce 解决方案在 Salesforce Platform 的内置[调控器限制](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)内运行得更好。 在 Salesforce 中优化吞吐量首先要准确计算系统中的工作负载,并规划其增长。如果没有对系统需求的准确预测,您就无法准确定位系统吞吐量的潜在问题。 在考虑工作量时,请考虑这三个维度。 - 系统必须在指定时间内处理**的交易数量** - 必须同时访问系统**的用户数量** - 系统中**事务逻辑的总体**复杂性 在考虑性能时,团队有时会过于狭隘地关注计算和对最大 CPU 时间的限制,这些是平台的调控器限制之一。专注于 CPU 时间的团队忽略了优化吞吐量的其他方法。扩展重点并应用这些方法可以提高 Salesforce 架构的整体吞吐量和效率。这些改进反过来将有助于减少延迟并提高整体系统性能。ApexGuru 会主动检测吞吐量限制的反模式,例如循环中的 SOQL、循环中的 DML、低效 GGD 调用和昂贵的方法。这些见解有助于团队消除限制吞吐量的调控器限制风险。 要优化系统中的吞吐量: - **支持异步处理**。Salesforce 平台使用事务上下文来控制数据完整性和限制失控代码。请参阅架构基础中的[事务](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#交易)。因此,尽可能使用异步(异步)处理有助于最大限度地减少同步执行上下文中的潜在瓶颈。请参阅[数据处理](/docs/architect/zh-cn/well-architected/guide/automated#数据处理)。使用异步计算并非解决每种性能问题的良药,您需要在合并异步进程时考虑延迟。某些平台功能,例如可排队 Apex,可能会在流量高峰期间增加延迟,因为它们会导致消息在队列中等待更长时间。根据您的用例,您可以决定容忍响应性的潜在下降,以保持或提高吞吐量。在其他情况下,您可能决定增加的延迟是不可接受的。通过扩展测试,您可以通过在完全 Sandbox 中模拟流量峰值来验证这些权衡。您可在此处测量作业如何影响吞吐量和延迟。 - **始终使用批量化**。在高级别,批量化意味着对集合执行操作。通常,讨论 Salesforce 解决方案批量化的团队会重点关注针对集合简化数据操作。请参阅[操作逻辑](/docs/architect/zh-cn/well-architected/guide/automated#操作逻辑)。但是,系统级别的批量化不仅仅涉及数据操作。还要考虑某些任务,例如标注或复杂计算,作为批量化的候选项。适当的批量化减少了开销。它执行多个操作,每个操作有一个请求,而不是一个请求。ApexGuru 在[循环内显示 DML 或 SOQL](https://help.salesforce.com/s/articleView?language=en_US&id=xcloud.apexguru_antipatterns.htm&type=5) 等反批量化模式,您可以在扩展到生产前修复它们。请参阅[批量操作](/docs/architect/zh-cn/fundamentals/guide/platform-multitenant-architecture#批量操作)。 - **使用 SOSL 进行搜索,并将 SOQL 视为数据操作。**显然,使用过于复杂的 SOQL 语句会增加系统检索记录的时间。SOQL 增加了[基础关系数据库](/docs/architect/zh-cn/fundamentals/guide/platform-multitenant-architecture#平台数据层)的开销,降低了处理速度。在使用文本或通配符条件时,SOSL 的性能更好。SOSL 使用平台的搜索引擎,该引擎针对全文索引和通用搜索进行了优化。要优化记录检索模式,请确保您的设计标准指定何时使用 SOSL 在系统中查找数据。还要确保他们指定如何使用 SOQL 进行高效的数据操作。请参阅[操作逻辑](/docs/architect/zh-cn/well-architected/guide/automated#操作逻辑))。 - **使用平台缓存和 ApexGuru**。[Lightning 平台缓存](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_namespace_overview.htm)层在缓存 Salesforce 会话和组织数据时提供了更快的性能和更好的可靠性。平台缓存通过分配缓存空间来提高性能,这样一些应用程序或操作就不会从其他应用程序或操作中窃取容量。ApexGuru 检测错过的缓存重复查询的机会(例如,[平台缓存 SOQL 结果](https://help.salesforce.com/s/articleView?id=xcloud.apexguru_antipattern_soql_without_platform_cache.htm&type=5)),从而提高了大规模环境中的吞吐量。 性能的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/reliable#性能模式和反模式)显示了 Salesforce 组织中正确和较差的吞吐量。在构建之前,使用它们来验证您的设计,或者确定进一步优化的机会。 要了解有关适用于吞吐量优化的 Salesforce 工具的更多信息,请参阅适用于可靠性的 [Salesforce 工具](/docs/architect/zh-cn/well-architected/guide/reliable#salesforce-可靠性工具)。 ### 延迟 延迟是衡量系统完成执行路径的速度。优化系统的吞吐量将有助于改善延迟。延迟的另一个维度是感知的性能,或者系统对用户的反应。 人们不想等待页面加载或进程完成。如果用户在尝试导航列表视图、记录页面、报表等时经常遇到漫长的加载时间,系统用户会感到沮丧。当出现这种情况时,客户或合作伙伴可能会决定将他们的业务转移到其他地方,而不是处理性能不佳的系统。在内部,员工可能会创建解决方法来避免使用设计的系统,这可能会导致下游的安全性和数据完整性问题。 感知的性能很难诊断。当用户报告性能缓慢时,支持团队可能无法重现该问题。延迟的增加通常是相互依靠的较小问题的组合的结果,这可能会使诊断感知的性能问题的确切原因变得困难。 要减少 Salesforce 系统中的延迟并提高响应能力: - **优化报表**。确保每个报表服务于一个特定的目的。清楚地确定系统中每个报表的受众和目的。在报表中,仅包含受众成员决策所需的最少数据量。删除与报表目的不一致的列将通过减少需要检索和显示的数据量来提高报表性能。 - **优化筛选器**。有效的筛选器通过准确确定从数据库中检索的行数来加快报表和列表视图的性能。一般来说,您制定的筛选器逻辑越具体,数据的基础查询就越有效。优化筛选器的方法包括: - 使用“等于”和“不等于”,而不是“包含”和“不包含” - 避免按公式字段筛选 - **简化共享模式**。过于复杂的共享模型会使各种进程变慢,因为系统必须检查共享和可见性模型,以确定用户是否可以访问要显示或处理的数据。复杂的共享计算会增加在用户上下文中运行的报表、列表视图和自动化的延迟。请参阅[共享和可见](/docs/architect/zh-cn/well-architected/guide/secure#共享和可见性)性。 - **优化自定义 UI 组件**。自定义构建的用户界面 (UI) 组件会增加延迟。要优化自定义 UI 组件的性能,请考虑执行以下操作。 - **使用 Lightning Web 组件 (LWC)**。LWC 框架与现代 Web 标准紧密一致。使用 LWC 编写的自定义组件在 Web 浏览器中呈现效率更高,并使开发人员能够使用性能更高的 JavaScript 方法。始终致力于使用 LWC,而不是旧的 UI 技术,例如 Aura 或 Visualforce。 - **使用 Lightning 数据服务**。Lightning 数据服务处理跨组件的安全、高性能和共享缓存的创建和维护。使用它可以避免不必要的数据往返服务器,并提高整体应用程序响应。 - **对列表数据使用客户端排序和筛选。**对于 LWC(首选)和 Aura 组件(否则),开发人员可以使用标准 JavaScript 数组功能在客户端排序、筛选和选择值,从而减少所需的服务器行程次数。 [模式和反模式](/docs/architect/zh-cn/well-architected/guide/reliable#性能模式和反模式)显示了 Salesforce 组织中正确和较差的延迟。在构建之前,使用它们来验证您的设计,或者确定进一步优化的机会。 要了解有关适用于延迟优化的 Salesforce 工具的更多信息,请参阅适用于可靠性的 [Salesforce 工具](/docs/architect/zh-cn/well-architected/guide/reliable#salesforce-可靠性工具)。 ### 性能模式和反模式 此表显示了要在贵组织中查找或构建的模式选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/trusted-performance)器中探索更多性能模式。
模式 反模式
吞吐量 在设计标准中:
- 有关如何使用平台缓存的指导符合平台缓存最佳实践
在设计标准中:
- 如果平台缓存使用有指导,则不清楚或与最佳实践不一致。
在您的组织中:
- 批量化用于数据和系统操作。
- DML 或数据库方法始终针对 Apex 中的集合进行操作。
- DML 期间用于缩短数据库中已过去时间的字段有限。
- 所有通配符条件在 SOSL 中使用。
- SOQL 语句具有选择性:
-- 它们不使用 LIKE 比较或部分文本比较。
-- 比较运算符使用正逻辑(换句话说,INCLUS 或 IN)作为其主要逻辑或唯一逻辑。
--= NULL 和 != NULL 仅用于很少总是跟在正比较运算符后面的。
– 为了最大限度地减少数据负载和最大限度地提高性能,仅检索 SOQL 查询中所需的字段。
-- 不使用 LIMIT 1 语句。
-- 不使用 ALL ROWS 关键字。
- 尽可能支持异步处理。
- 配置平台缓存分区。
在您的组织中:
- DML 语句未批量化。
- DML 或数据库方法针对 Apex 中的单个记录进行操作。
- SOSL 很少或没有一致地用于通配符选择条件。
- SOQL 语句是非选择性的:
-- 它们包括 LIKE 和通配符筛选条件。
-- 使用 !=、NOT 或 NOT IN 条件的比较用作主要或唯一比较运算符。
-- 使用 = NULL 和 != NULL 条件作为主要或唯一比较运算符。
-- 使用 LIMIT 1 语句。
-- 使用 ALL ROWS 关键字。
- SOQL 显示在循环中。
- 支持同步进程。
延迟 在您的组织中:
- 报表服务于单一特定目的,并包含决策所需的最小行数和列数。
- 筛选器使用“等于”和“不等于”。
- 筛选器不包含公式字段。
- 共享模式尽可能简化。
- 自定义 UI 组件使用 Lightning Web 组件 (LWC)。
- LWC 使用 Lightning 数据服务进行数据操作。
- 排序和筛选列表数据在客户端使用 JavaScript 处理。
- Salesforce Edge 已启用。
在您的组织中:
- 报表用于多种目的,或包含决策不需要的额外行和列。
- 筛选器使用“contains”(包含)和“not contain”(不包含)。
- 筛选器包含公式字段。
- 共享模型很复杂。
- 自定义 UI 组件使用的框架可能会导致呈现效率低于 LWC(例如 Aura 或 Visualforce)。
- LWC 使用 Apex 进行数据操作。
- 使用 Apex 在服务器端处理列表数据的排序和筛选。
- Salesforce Edge 未启用。
## 可扩展性 可扩展性是系统在不断发展壮大时保持一致性能的能力。可扩展的系统可以处理大量增加的事务量或并发访问,而无需进行根本性的更改。Salesforce 的平台服务旨在支持应用程序的可扩展性。请参阅[内部平台处理](/docs/architect/zh-cn/fundamentals/guide/platform-multitenant-architecture#内部平台处理)。话虽如此,随着贵组织的增长,对产品和服务的需求增加,您有责任创建一个可以如预期有效执行的系统。从一开始就为可扩展性构建架构可以更快地交付新功能,并随着用户流量的增加减少服务中断。在设计阶段早期,在将新功能部署到生产之前,使用**扩展测试**来模拟预计的工作量,并验证架构是否可以扩展以支持它们。 并非为可扩展性设计的系统需要不断进行昂贵的故障排除、重新设计和重构。可扩展性问题随着时间的推移而复杂化,降低了整个系统的性能。在某些情况下,企业发现自己将大部分开发和维护资源用于解决可扩展性问题,而不是用于创造价值的新功能。 有时,企业会达到临界临界点。其系统的原始设计无法支持业务的增长,意外事件使系统不稳定。使用**规模中心的**见解,尽早确定可扩展性临界点。规模中心显示了随着时间的推移而恶化的异常热点、长时间运行的事务和队列瓶颈。 通过关注数据模型优化和数据量管理,您可以更好地构建规模。 _注意:虽然此处未讨论,但可扩展性测试是验证应用程序架构的关键部分。有关指导,请查看[测试策略](/docs/architect/zh-cn/well-architected/guide/resilient#测试策略)。_ ### 数据建模 数据建模涉及构建贵组织中的对象,并将其相互关联,以使您的用户和自动化流程能够尽快检索到他们需要的数据。采取措施[提高吞吐量](/docs/architect/zh-cn/well-architected/guide/reliable#吞吐量)可以解决许多性能问题,但是如果没有优化的数据模型,您的努力就不会那么有效。 设计不当的数据模型的负面影响不会立即明显;随着系统在数据量、流程、用户和集成方面的增长,它的弱点也会暴露出来。随着需求的添加和扩展,设计良好的数据模型可以更容易地持续重构您的应用程序。**ApexGuru** 显示了直接影响数据模型可扩展性的数据访问反模式,例如非选择性 SOQL、未使用的字段和模式的低效率。 要优化数据模型: - **使用 Salesforce 中的预构建数据模型。**Salesforce 为销售、服务和各种行业垂直行业提供预构建的数据模型。使用 Salesforce 提供的数据模型可确保系统中的功能仅定义一次,消除冗余和孤岛,并在整个系统中建立单一的真实来源。因为您使用了该单一来源的 Salesforce 预构建数据模型,所以更容易使用 Analytics 理解应用程序数据,也更容易使用 Salesforce 的预构建人工智能服务。此外,减少您必须支持的自定义会降低维护成本并减少技术债务。 - **选择正确的数据类型**。了解 Salesforce 支持的不同类型字段及其局限性。请考虑报告和加密要求,这样您就不必将来在类型之间转换数据。 - **选择正确的关系**。Salesforce 支持对象之间的两种关系:主-详细信息和查找。主-详细信息关系提供两个主要好处。一个是内置的累计汇总功能,它统计和汇总子记录的详细信息。另一个是内置的级联删除功能,通过该功能,删除父记录也会删除其子记录。但在决定使用前,请确保您了解主-详细信息关系的[共享和数据偏差](/docs/architect/zh-cn/well-architected/guide/reliable#数据量)。 - **为了规模而去标准化。**标准化是构建数据模型的过程,以减少数据冗余并提高数据完整性。遗憾的是,标准化有时会导致缩放问题。非标准化表在规模上表现更好,但请谨记考虑数据完整性和冗余性。 [模式和反模式](/docs/architect/zh-cn/well-architected/guide/reliable#可扩展性模式和反模式)显示了 Salesforce 组织中正确和糟糕的数据模型优化。在构建之前,使用它们来验证您的设计,或者确定进一步优化的机会。 要了解有关适用于数据模型优化的 Salesforce 工具的更多信息,请参阅适用于[可靠性的 Salesforce 工具](/docs/architect/zh-cn/well-architected/guide/reliable#salesforce-可靠性工具)。 ### 数据量 数据量是根据记录计数和大小衡量存储在系统中的数据量。如果贵组织有数万名用户、数千万条记录或数百 GB 的记录总存储,则数据量很大。数据量和贵组织中的对象之间的关系会影响可扩展性,并且对可扩展性的影响可能大于仅记录数量的影响。 要提高具有大量数据的组织的可扩展性: - **分发子记录**。通过确保没有父级拥有大量子级记录,避免父子级数据偏差。一般建议是,任何父级记录的子记录都不应超过 10,000 个。例如,在具有多个联系人但未使用客户的部署中,请考虑设置多个客户记录并在其中分发相关联系人记录。 - **分配记录的所有权**。通过确保没有单个用户或队列拥有,也没有单个角色或公用小组的所有成员拥有来自相同对象的超过 10,000 条记录,避免所有权偏差。使用“虚拟用户”“停放”数据是一种通常导致所有权倾斜的做法。如果您遇到此问题,请谨记其对[共享计算](/docs/architect/zh-cn/well-architected/guide/reliable#延迟)的影响。如果您无法重新分配记录来缓解所有权偏差,请避免将数据拥有用户分配到角色。如果贵组织的共享模式需要角色分配,请将数据拥有用户放在共享层次结构顶部的不同角色中。请勿允许频繁或计划外更改该用户的角色。由于共享重新计算,任何更改都会对性能产生重大影响。将该用户排除在任何共享规则中可以引用的公用小组之外。 - **减少 Salesforce 中的记录数据量**Salesforce 旨在向企业提供客户的单一视图。在 Salesforce 中限制数据是一种最佳实践,这似乎违反直觉。但是,单一视图的功能在于它使业务用户能够很好地理解客户数据并对其采取行动。随着数据量的增长,与日常流程或分析无关的最新数据会导致一些问题。这些问题包括应用程序性能下降、数据安全风险增加以及对搜索、报告和分析的负面影响。为避免此类问题,请为数据模型中的每个对象定义数据生命周期,并随着数据的老化和丧失即时业务价值,为其提供时间表和分类。根据数据生命周期,实施这些程序,随着时间的推移管理数据。 - **数据归档和清除** \- 要保持尽可能低的数据量,请删除业务不需要的记录,以帮助保持尽可能低的数据量。使用批量 API 2.0 的硬删除功能删除大量数据。 - **数据聚合 -** 创建聚合自定义对象,以兼容报表的格式汇总关键历史趋势或汇总数据。使用[批量 Apex](/docs/architect/zh-cn/well-architected/guide/reliable#吞吐量) 填充自定义对象。然后,用户可以根据聚合的对象记录执行报表。 - **数据分层**。如果 Salesforce 报表或日常工作不需要大型数据集,请在不同的应用程序中维护它们。根据需要,通过混搭、标注或外部对象,使数据在 Salesforce 中可用。 实际上,您可能并不总是能够在出现问题时立即解决可扩展性问题的根本原因。因此,Salesforce 提供了帮助缓解当前痛点的选项。重要的是要知道,在贵组织中启用这些功能对于处理大量数据来说并不是一个可行的长期架构策略。这些短期的权宜之计有助于减少数据架构不佳的系统延迟,但它们也会给贵组织增加技术负担。 规模问题的短期解决方法包括: - **自定义索引**索引存储在平台查询优化器用来加速数据访问操作的特殊内部表中。请参阅[多租户索引](/docs/architect/zh-cn/fundamentals/guide/platform-multitenant-architecture#索引))。默认情况下,平台会自动索引特定类型的字段。要加速性能不佳的查询,您可以通过联系 Salesforce 客户支持来请求其他自定义索引。使用“查询计划”工具确定自定义索引是否会提高查询的性能。 - **瘦桌子**如果您需要进一步优化对具有超过 100 万条记录的对象上的常见字段集的查询,瘦表可以提供帮助。瘦表格消除了在报表或自动化中使用同一对象中的自定义和标准字段时出现的[后台连接](https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_skinny_tables.htm)。要使用瘦表格,Salesforce 客户支持必须为贵组织启用它们。 可扩展性的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/reliable#可扩展性模式和反模式)显示了 Salesforce 组织中正确和糟糕的数据量管理。在构建之前,使用它们来验证您的设计,或者确定进一步优化的机会。 要了解有关管理数据量的 Salesforce 工具的更多信息,请参阅[Salesforce 可靠性工具](/docs/architect/zh-cn/well-architected/guide/reliable#salesforce-可靠性工具)。 ### 可扩展性模式和反模式 这显示了在您的组织中寻找或构建的模式选择,以及避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/trusted-scalability)器中,发现更多可扩展性模式。
模式 反模式
数据建模 在设计标准中:
- 存在业务理由支持自定义对象的标准和指南。
在设计标准中:
- 不存在创建自定义对象的标准。
在您的数据模型中:
- 尽可能使用标准对象。
- ApexGuru 对反模式的检查确认 SOQL 查询是选择性的,并避免低效的模式使用。
- 表格因规模而去标准化。
在您的数据模型中:
- 您已复制标准对象。
- 表格标准化,以避免冗余。
在您的业务中:
- 低代码生成器了解 Salesforce 支持的不同字段类型,并在选择字段数据类型之前评估报表和加密要求。
- 在决定建立对象之间的主-详细信息关系之前,您需要评估该关系的共享和数据偏差影响。
在您的业务中:
- 低代码生成器选择数据类型,而不评估下游报告和加密要求。
- 在决定建立对象之间的主-详细信息关系之前,您不会评估该关系的共享和数据偏差影响。
数据量 在您的数据中:
- 没有父级记录包含超过 10,000 个子级记录。
- 没有用户被分配到超过 10,000 个相同对象类型的记录。
- 实例不包含超过 10,000 个具有指向相同记录的查找字段的记录。
- 根据 ParentId 字段值,批量数据加载会分批排序。
- 为了确保批处理策略不会在并发下中断,扩展测试用于验证生产规模的批量加载模式。
- 将数据批量加载到生产中不会在高峰工作时间发生。
- 批量数据加载仅包含业务决策所需的最少数据。
在您的数据中:
- 存在超过 10,000 个子记录的记录。
- 用户被分配到超过 10,000 个相同类型的记录。
- 存在超过 10,000 个记录具有指向相同记录的查找字段的实例。
- 批量数据加载不会根据 ParentId 字段值进行批量排序。
- 将数据批量加载到生产中发生在工作高峰时段。
- 批量数据加载不限于业务决策所需的最少数据。
在 Flow 和 Apex 中:
- 在数据偏差令人担忧的情况下,存在在多个父级记录之间分配子级记录数量的逻辑。
- 当通过集成导入或复制记录时,逻辑会将它们分配给适当的人工用户。
- 对于 Apex 集合,例如列表和集,存在处理多个记录的逻辑,以最大限度地减少查询并优化数据处理。
- 编写和部署遵循可扩展代码标准和最佳实践的高效 Apex 代码。
在 Flow 和 Apex 中:
- 子记录被任意分配给父记录,而不管已经分配的子记录的数量。
- 通过数据加载或集成创建的记录被分配给通用“集成用户”。
- 来自同一对象的多个递归 SOQL 查询处于同步事务中,导致高堆使用率。
当开发人员编写 Apex 代码时,他们会引入低效率和性能反模式。
在您的业务中:
- 您已记录并实施数据归档和清除策略
在您的业务中:
- 您没有数据归档和清除策略,或者您的策略已记录但未实施
## Salesforce 可靠性工具
工具描述可用性性能可扩展性
大对象 在平台上存储和管理大量数据。 X
代码扫描仪 扫描 Apex 代码是否存在性能问题。 X
自定义索引 使用自定义索引提高查询性能。 X
删除数据 删除不必要的数据以提高性能。 X X
分部 分区数据以限制查询和报表中的记录计数。 X
扩展测试 测试系统性能并解释结果。在部署到生产之前,为了验证可扩展性和性能,请使用 Playwright 或 JMeter 脚本模拟大规模 UI 和 API 工作负载。 X X
比例中心 获取关于系统性能的自助和实时见解。查找长时间运行的事务、异常热点和吞吐量瓶颈。在开发周期的早期诊断规模问题。 X X
ApexGuru 在 Scale Center 中使用此基于 GenAI 的功能,以在运行时检测 Apex、SOQL 并测试类反模式。通过 ApexGuru 与 Salesforce Code Analyzer 的集成,在开发工作流中获得 AI 支持的推荐和内联修复。使用这些建议和修复来解决热点问题,并提高查询选择性、批量化、缓存使用和测试质量。 X X
Salesforce 代码分析器 使用 IDE、CLI 或 CI/CD 扫描代码,以确保符合最佳实践。通过 Salesforce Code Analytics 与 ApexGuru 的集成,直接在开发人员工作流中获取有关性能反模式的见解。 X
Salesforce Edge 网络 通过 Salesforce Edge 网络路由 My Domain,改善下载时间和用户体验。 X
瘦桌子 避免在具有频繁使用字段的表上连接。 X
主动监控 持续监控记录增长、所有权倾斜和性能回归中的异常。在规模问题变得重要之前发出警报。 X X
## Salesforce 可靠性资源
资源描述可用性性能可扩展性
规模挑战成本数百万 — 以下是如何面向未来发展业务 了解实施可扩展性如何实现可持续增长和长期成功。 X X
使用规模中心构建和部署可扩展应用程序 了解如何主动评估和解决 Salesforce 实施中的性能问题。
分析复杂 Salesforce 应用程序中的性能和规模热点 解决贵组织中的性能和可扩展性问题。 X X
在交通高峰时段,应用程序不应惊慌 - 以下是如何准备 了解成功规模测试的四个关键步骤。
ApexGuru AI 引擎解释 了解 ApexGuru 如何使用自定义训练模型、真实组织遥测和智能筛选来提供精确、上下文和可操作的见解。 X X
使用 ApexGuru 优化 Apex for Apps 和 Agentforce 了解 ApexGuru 如何帮助开发人员检测和修复性能反模式,包括 SOQL、DML、调试和测试低效率。 使用 ApexGuru 作为 AI 支持的教练,以进行应用程序的可扩展开发和 Agentforce 的实施。 X X
ApexGuru 反模式 了解 ApexGuru 检测到的反模式的官方库,该库会在每个主要 Salesforce 版本中更新。 X X
大数据量部署的最佳实践 了解大数据量对流程的影响。 X
Salesforce Edge 网络的注意事项 了解如何准备贵组织使用 Salesforce Edge 网络。 X
设计标准模板 为您的组织创建设计标准。 X X X
数据模型设计注意事项 为规模和维护优化数据模型。 X X
设计企业级的记录访问权限 通过配置优化访问控制性能。 X
大数据量系统的基础架构 了解支持大数据量部署的系统性能的功能。 X
适用于批处理的学习资源 了解批次管理。 X X
Lightning Experience 性能优化 改善贵组织中的 Lightning Experience,以帮助用户更快地工作。 X
在 Salesforce 中管理查找偏差以避免记录锁定异常 了解如何最小化查找偏差的影响。 X X
SOQL 和 SOSL 最佳实践 对于大数据量部署,遵循 SOQL 和 SOSL 最佳实践。 X X
大规模重新校准的工具 有效计划和执行重新校准。 X
使用 Mashups 在不同的应用程序中维护大型数据集。 X X
## 告诉我们您的想法 帮助我们保持 Salesforce 架构合理与您相关;参加我们的[调查](https://sfdc.co/bxNtvh),以提供有关此内容的反馈,并告诉我们您接下来想要看到的内容。 > 在[这里](/docs/architect/zh-cn/well-architected/guide/contributors)阅读我们的更新计划。 法律免责声明:本文件仅作参考之用,不构成法律咨询意见,亦不应用作法律咨询意见。 ## 导言 合规系统旨在遵守适用的法律和道德准则,其遵守情况既是可衡量的,又是可审计的。具体表现是限制授权个人出于预期目的访问数据,遵守相关法律法规,并确保所有授权用户公平访问数据。 主动措施对于防止和检测违反法规的行为至关重要。对法规和标准的反应性方法会削弱客户 Trust,特别是如果仅应客户请求或投诉而发生变化。此类投诉会损害贵组织的品牌和声誉,并导致收入损失。 您可以通过关注三个关键习惯来建立 Salesforce 解决方案的合规性:法律合规、道德标准和可访问性。 ## 法律遵守 遵守法律授权涉及遵守区域法律和行业法规。作为架构师,一旦贵组织的法律团队或第三方审计员确定了特定的合规要求,您的责任就是了解这些要求,并在设计过程的早期主动识别和标记潜在的合规问题,以减少罚款和诉讼的风险。 通过数据隐私和本地化,您可以提高 Salesforce 解决方案的法律合规性。 ### 数据隐私 数据隐私涉及您的解决方案如何收集、存储和处理个人身份信息 (PII),以及相关法规和个人控制对其个人数据访问的能力。遵守这些法规可能需要更新您的[共享和可见性模型](/docs/architect/zh-cn/well-architected/guide/secure#共享和可见性)、修改元数据配置以限制访问、实施字段级加密、监控日志和事件、创建自动化以根据请求导出或删除客户数据,以及制定管理自动化和 AI 中数据使用的策略。 不遵守数据隐私条例可能会导致巨额罚款和诉讼。此外,由于控制不足或安全漏洞而暴露利益相关者的数据会导致收入损失和客户 Trust 受损。 在努力确保遵守数据隐私要求时,请考虑以下事项: - **咨询监管专家**。与您的法律团队或第三方审计员合作,评估适用于您业务的行业特定的合规条例。例如,医疗保健公司必须遵守健康保险携带和责任法案 (HIPAA)。 - **分类数据**。数据分类帮助项目团队了解贵组织中的各种数据元素何时可用或不可用。它还使您的业务能够[报告](https://help.salesforce.com/s/articleView?id=sf.data_classification_report.htm&type=5)数据管理策略合规性。通过指定[字段级别的](https://help.salesforce.com/s/articleView?id=sf.data_classification_intro.htm&type=5)适用法规来分类贵组织中的数据,以获取所有者是谁、敏感度级别以及字段当前是否正在使用。 在分类过程中,重要的是考虑如何使用数据模型中的所有字段,而不仅仅是那些乍一看似乎很敏感的字段。在某些情况下,如果在错误的上下文中使用,看起来无关紧要的字段会变得敏感。例如,美国的邮政编码可以是种族的代理,因此如果在预测模式中使用,可能会无意中增加偏见或造成伤害。名称可用于预测性别、原籍国、种族、宗教甚至年龄,因为流行名称往往一代又一代地变化。包括所有字段的分类,并清楚地描述任何关联的 AI 功能将如何在文档中使用它们。 使用[数据检测](https://help.salesforce.com/s/articleView?id=sf.einstein_data_detect.htm&type=5)等工具识别贵组织中的敏感数据。如果字段被归类为敏感字段或如果您知道哪些字段敏感,Einstein 内容选择等工具也将识别[高度相关](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.mc_pb_manage_einstein_content_selection_attributes_and_bias.htm)的字段,因此可以是这些敏感字段的代理。 - **建立数据治理的最佳实践**确保所有相关文档完整、最新并集中存储,以便所有相关方可以轻松使用。这将为您的组织增加一层保护,使其免受法律责任的侵害,同时保持与客户和合作伙伴之间的 Trust。例如,数据字典记录了将存储在系统中的所有数据元素的对象和字段级定义和分类,设计文档包含有关您为遵守法规而创建的任何自动化的详细信息,安全矩阵概述了用户可以访问的数据。重要的是,这个全面的文档成为检索扩充生成 (RAG) 的权威来源,直接将 Agentforce 等代理系统置于经过验证的合规操作上下文中,从而防止输出不一致或出现幻觉。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/compliant#法律合规模式和反模式)列表显示了 Salesforce 解决方案中正确(和差)的数据隐私管理。在构建之前,使用这些组件来验证您的设计,或者确定系统中需要重构的区域。 要了解有关数据隐私的 Salesforce 工具的更多信息,请参阅[合规相关工具](/docs/architect/zh-cn/well-architected/guide/compliant#与合规相关的工具)。 ### 本地化 本地化是指调整产品,使其与特定的语言、文化和所需的本地美学保持一致。这也包括适应特定于地区的法规,例如数据驻留法,它们可能因国家/地区甚至城市而异。因此,您的系统可能需要满足多个监管框架,这取决于客户的位置以及您的业务如何向市场介绍其产品和服务。 除了数据隐私法的变化之外,许多国家/地区也在颁布数据居住法。至少,数据驻留法要求与一国公民相关的所有数据都实际存储在该国境内。一些法律进一步要求本地存储公民可能访问的所有数据(包括有关产品和服务的数据)。在某些情况下,法规要求公民数据仅由该国家或地区的其他公民维护。 不遵守可能会导致巨额罚款和诉讼。例如,欧盟的数据保护机构可以处以高达 2000 万欧元或全球收入的 4% 的罚款,以较高者为准。在美国,加州总检察长办公室可以要求对有意和无意的违法行为进行重大处罚。 考虑以下事项,以更好地管理本地化和数据驻留要求: - **咨询监管专家**。与您的法律团队或第三方审计员合作,评估您的业务运营地区的法律,以确定哪些法律适用。示例包括欧盟的通用数据保护条例 (GDPR) 和欧盟 AI 法案,以及加州消费者隐私法案 (CCPA)。 - **本地存储数据**。确保特定于区域的数据保留在自己的单独组织中。使用 [Hyperforce](https://help.salesforce.com/s/articleView?id=000356459&type=1) 这一 Salesforce 的公共云平台在特定区域托管您的组织。 - **避免数据复制**。本地数据存储意味着数据*静态*存储在国家/地区;当然,当数据通过标准接口传输出国家/地区时,可能会出现合规性问题。例如,在本地创建和维护记录,但将其复制到其他国家的数据仓库进行报告将违反数据驻留法。如果您为具有跨区域报告要求的全球企业工作,请先在存储数据的国家/地区汇总数据,删除所有可能识别与其相关的公民的信息,然后仅复制汇总信息。这种方法可能需要您向利益相关者传达报告的限制,以便他们知道,虽然在国家/地区或区域级别上将提供更详细的数据,但在全球范围只有汇总数据。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/compliant#法律合规模式和反模式)列表显示了 Salesforce 解决方案中正确(和差)的本地化和数据驻留流程。在构建之前,使用这些来验证您的设计,或者确定需要重构的区域。 要了解有关适用于本地化的 Salesforce 工具的更多信息,请参阅[合规相关工具](/docs/architect/zh-cn/well-architected/guide/compliant#与合规相关的工具)。 ### 法律合规模式和反模式 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式浏览](/docs/architect/zh-cn/well-architected-tools/guide/trusted-legal-adherence)器中,发现更多合法合规的模式。
模式 反模式
数据隐私 在您的文档中:
- 您拥有包含字段级名称、描述和分类的最新数据字典
- 您拥有最新的安全矩阵,可确定哪些用户可以访问哪些数据
- 您拥有最新的设计文档,包括为满足监管要求而创建的任何自动化的标准和图表
在您的文档中:
- 数据字典不存在或未保持最新
- 共享和可见性文档不存在或未保持最新
- 满足监管要求的自动化设计标准、图表和文档不存在或未保持最新
在您的组织中:
- 所有包含敏感信息或受数据隐私条例约束的对象和字段都配置了合规分类、数据所有者、数据敏感级别和字段使用情况
在您的组织中:
- 包含敏感信息或受数据隐私条例约束的对象和字段缺少合规分类、数据所有者、数据敏感级别或字段使用情况的配置
本地化 在您的文档中:
- 您的组织策略概述了数据的存储和维护位置,以符合所有适用的数据驻留要求
- 您有一个集成策略,它概述了跨境复制数据的可接受场景和流程
- 您有一个概述区域、国家和全球级别的粒度报表和仪表板的分析策略
在您的文档中:
- 您没有组织策略,或者您的组织策略没有解决数据本地化和驻留要求
- 您没有集成策略,或者您的集成策略没有解决数据本地化和驻留要求
- 您没有 Analytics 策略,或者您的 Analytics 策略没有解决数据本地化和驻留要求
## 道德标准 在商业环境中,道德标准是公司和个人如何从价值或道德角度进行自我行为的准则。在 Salesforce 中,[我们的核心价值](https://trailhead.salesforce.com/content/learn/modules/salesforce-culture-and-values/explore-salesforce-culture-and-values)观指导着我们作为公司和员工所做的一切。我们还有一个[符合道德使用策略](https://www.salesforce.com/company/intentional-innovation/ethical-use-policy/)的团队,帮助确保客户以合乎道德的方式使用我们的软件。我们的可[接受使用政策 (AUP)](https://sfdc.co/AUP) 和 [AI 可接受使用政策 (AI AUP)](http://sfdc.co/AI-Policy) 是我们核心价值的延伸,如果出现使用方面的问题,将有助于指导我们的决策。 贵组织可能拥有额外的策略集,而不仅仅是遵守当地法规。这些政策可以采取各种形式,从遵守其他地区的法规、拒绝与某些组织或市场做生意,到监控员工与客户的互动以防止歧视或偏见行为。要维护这些政策,您可能需要更新设计标准或系统配置,如同您希望[合法合规](/docs/architect/zh-cn/well-architected/guide/compliant#法律遵守)。 为了在 Salesforce 解决方案中促进更好地遵守道德标准,请与公司政策保持一致,并评估您对人工智能的使用。 ### 公司策略 公司策略是定义业务各个方面(包括人员、流程和技术)应如何操作的指导原则。客户更喜欢与他们 Trust 的组织做生意。大多数公司策略旨在反映这一原则。如果您的系统创建的用户体验与您的声明策略不一致,Customer Trust 将迅速削弱。 有效的政策自然来自[道德文化](https://www.salesforce.com/blog/new-research-ethical-leadership-business/)。从工程设计到数据科学、市场营销和销售,每个员工都必须接受道德使用责任的教育。在这种文化中,员工会看到奖励道德行为的明确激励结构,以及不道德行为的明确一致的后果。 请考虑以下事项,以确保贵组织的策略反映在您的设计中: - **请注意意外后果**。作为架构师,您有责任预测解决方案的潜在影响以及如何使用它们。不要落入只考虑或测试幸福道路的陷阱。相反,在测试边缘个案和评估权衡方面应用您的专业知识,以充分考虑解决方案的道德影响。想想受产品影响的每个人,特别是那些代表不足、边缘化或脆弱的人。评估某人或某物与您的解决方案交互并产生意外后果的多种方式。使用[意图构建工具](http://sfdc.co/BuildwithIntention)包进行设计时考虑包容性。 - **将道德嵌入贵公司的可接受使用策略。**与法律团队或第三方合作,将道德纳入可接受的使用策略,以确保解决方案的使用符合贵公司的价值观。文档应包含有关解决方案支持贵组织哪些价值和政策的信息,无论是使用低代码工具还是专业代码工具开发。发布可接受的使用策略,以表明您致力于与员工和客户建立 Trust。 - **使用包含语言**。了解人们体验解决方案的不同方式,并在用户界面、代码和文档中[完善语言](https://www.salesforce.com/news/stories/salesforce-updates-technical-language-in-ongoing-effort-to-address-implicit-bias/),以更准确地反映包容性。首先确定并删除排斥性语言,然后致力于了解可能导致排斥的习惯或做法的类型。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/compliant#道德标准模式和反模式)列表显示了 Salesforce 解决方案中正确遵守公司策略(和欠遵守)的情况。在构建之前,使用这些组件来验证您的设计,或者确定系统中需要重构的区域。 要了解有关使设计与公司策略一致的 Salesforce 工具的更多信息,请参阅[合规相关工具](/docs/architect/zh-cn/well-architected/guide/compliant#与合规相关的工具)。 ### 人工智能 人工智能使用计算系统来执行通常需要人类智能的任务,例如推理、感知和决策。Salesforce Platform AI 功能涵盖预测、生成和代理技术,提供了一套全面的工具,以改善客户体验和业务运营: - **预测 AI** 分析历史数据并预测未来结果,例如销售趋势或客户流失。Einstein AI 通过分析数据中的模式来提供这些见解,以提供建议和预测业务结果。 - **生成式 AI** 专注于利用大型语言模型创建新内容。Einstein GPT 是一个核心组件,与您的 CRM 数据一起工作来生成个性化内容,例如电子邮件、聊天回复和客户通信。 - 通过使客服人员能够自主推理并采取行动来实现特定的目标,**客服人员 AI** 将 AI 向前推进了一步。Agentforce 是构建这些智能客服人员的平台,可以自动化复杂的业务流程,例如解决客户个案或优化市场营销活动。这些客服人员可以通过 Data 360 实时与数据交互,并利用现有工作流和 API。所有这些 AI 功能都由 Einstein Trust 层保护。这确保了道德使用。 大多数 Einstein AI 的核心算法不可配置,但对于一些功能,客户可以使用自己的数据对模型进行微调,如文档中所述。此外,您可以通过检索增强基础训练 (RAG) 在自己的 CRM、Knowledge 库文章和其他文档中对 AI 模型进行基础训练,以使输出对您的组织、客户和用例来说更加准确。但是,如果您的基础数据有偏差或歪曲,您的输出也可能会有偏差和不准确。偏见的一个例子是,即使您的客户群多种多样,并且包括该群体的成员,您的联系人列表中也不会包括特定种族、性别或族裔的成员。有关更多信息,请参考 Salesforce [负责创建 AI Trailhead 模块](https://trailhead.salesforce.com/en/content/learn/modules/responsible-creation-of-artificial-intelligence)、[了解可信 AI Trailhead](https://trailhead.salesforce.com/content/learn/modules/trusted-agentic-ai)、[AI 道德成熟模型](https://www.salesforceairesearch.com/static/ethics/EthicalAIMaturityModel.pdf)、Salesforce 的[可信 AI 原则](https://www.salesforceairesearch.com/trusted-ai)、[负责生成 AI 准则](https://www.salesforce.com/news/stories/generative-ai-guidelines/)和[负责代理 AI 准则](https://www.salesforce.com/news/stories/responsible-agentic-ai-guidelines/)。 不考虑适用的法律条例和贵公司自己的道德标准会导致 AI 中的偏见,导致诉讼、收入损失、Customer Trust 问题,并损害贵公司的公共形象。 以下是负责任和合乎道德地使用 AI 的注意事项: - **检查数据集和文档**。确保您的数据集代表 AI 功能将影响的每个人。这可能需要用户研究来了解他们是谁,并确认您的数据准确地代表了他们所有人,以减轻任何潜在的偏见。查看 CRM 数据、Knowledge 文章和您作为模型基础的任何其他文档也非常重要,以确保它们是最新的、准确的和完整的。将模型建立在数据负载上没有帮助,如果数据陈旧、矛盾或不完整,可能会导致幻觉。 - **[让人类掌舵](https://www.salesforce.com/news/stories/human-at-the-helm/)**您不希望人类干预每个单独的 AI 交互,而是让您的员工专注于最需要他们关注的高判断力项目。测试 AI 系统,直到您确信他们可以承担更多责任,并监控结果,以确保他们继续准确有效地工作。确保您的 AI 系统或客服人员接到指示,在 AI 置信度较低时,针对高风险用例升级为人工。 - **优先考虑模型输出和结果的安全性。**进行偏见、可解释性和稳健性[评估](https://www.salesforce.com/news/stories/developing-ethical-ai/),以及[符合道德的红色](https://www.salesforce.com/blog/red-teaming-ai/)团队。通过客服人员对用于培训的数据中存在的任何个人身份信息 (PII) 的响应和操作,优先考虑隐私保护,并创建防护栏以防止额外的伤害。如果您在测试时发现有害结果,请在系统提示中添加说明并重新测试。您可能需要提高用于检索扩充生成 (RAG) 的数据的质量或代表性。 - **为法规做好准备**。除了对 AI 的道德关切外,许多国家政府已经通过或正在通过立法来规范在其管辖范围内运作的组织使用 AI。该立法可以包括要求发布模型卡,描述 AI 解决方案是如何创建的和如何工作的。在实施基于人工智能的解决方案之前,请了解在将使用系统的地区接受或不接受哪种类型的 AI 相关功能,并对策略进行必要的调整。您可能需要在某些地区禁用某些功能,以遵守当地法规;如果是,请确保您的系统可以在没有这些功能的情况下继续运行。当客户或最终用户与 AI 系统进行交互时,许多司法管辖区还要求透明度。 - **监控贵组织的 AI 模型**。受影响的用户应该知道 AI 何时被使用,并有机会轻松报告伤害和请求补救。请注意,仅靠报告可能不足以确定 AI 功能是否对用户造成伤害。持续监控模型的数据漂移、公平/偏见分数的变化、准确性和稳健性。请确保您制定了[处理质量警报](https://help.salesforce.com/s/articleView?id=sf.bi_edd_quality_alert.htm&type=5)的计划,并在发现负面影响时快速响应。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/compliant#道德标准模式和反模式)列表显示了 Salesforce 解决方案中正确(和差)的 AI 设计。在构建之前,使用这些组件来验证您的设计,或者确定系统中需要重构的区域。 要了解有关 Salesforce 工具的更多信息,以实施更道德的 AI 策略,请参阅[合规相关工具](/docs/architect/zh-cn/well-architected/guide/compliant#与合规相关的工具)。 ### 道德标准模式和反模式 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/trusted-ethical-standards)器中探索道德标准的更多模式。
模式 反模式
公司策略 在设计标准中:
- 标准包含受公司政策影响领域的明确指导
在设计标准中:
- 设计标准不存在,或未对受公司政策约束的领域提供明确指导
在您的文档中:
- 配置和自定义文档包括对受支持公司值的引用
在您的文档中:
- 配置和自定义文档不引用公司价值或策略
在您的组织中:
- 受公司策略相关合规性约束的所有对象和字段都配置了合规性分类、数据所有者、数据灵敏性级别和字段使用情况
在您的组织中:
- 受公司策略相关合规性约束的对象缺少合规性分类、数据所有者、数据灵敏性级别或字段使用情况的配置
人工智能 在设计标准中:
- AI 应用程序的策略和批准的用例清晰易懂
- 确保用于 RAG 的数据和文档具有代表性、完整性、准确性和最新性。查找数据集或文档中可能存在的偏见、毒性和其他有害内容
- 生成式响应始终识别 AI 模型使用的数据源
- 已记录可用于/不可用于提示工程的数据集
- 向用户明确识别机器人和生成式 AI 响应
- 明确定义了何时及如何使用生成式 AI 免责声明的标准
- 对如何记录 AI 解决方案设计中的人员参与点有明确要求
- 存在用于记录 AI 解决方案设计中直接和间接反馈路径的标准
- 必须为用户识别 AI 的点被明确界定
- 让人员掌舵,特别是在受监管或高风险用例中
在设计标准中:
- 设计标准不存在或不包含明确的策略和批准的 AI 应用程序用例
- 生成式响应不会识别 AI 模型使用的数据源
- 未记录用于提示工程的数据集
- 机器人和生成式 AI 响应未向用户识别
- 缺少有关生成式回复的免责声明
- 没有记录 AI 解决方案设计中人员参与点的要求
- 没有记录 AI 解决方案设计的直接和间接反馈路径的标准
- 设计标准未指明必须向用户识别 AI 的点
在您的文档中:
- 涉及 AI 功能的配置和自定义文档包含所有流程逻辑的详细描述,并存储在法律团队或审核员可以访问的中心位置
- 您构建或带到 Salesforce 的模型有明确的文档记录,包括任何适用的数据段
- 对话逻辑和客服人员对话已完整记录
- 流程到位,以监控贵组织的 AI 模型的数据漂移、公平和偏见分数的变化、准确性和稳健性
- 为所有 AI 流程使用的培训、评估和测试数据保留描述
- 保留任何 AI 相关数据清理的描述,以及偏见测试、相关结果和性能/准确性分数(例如,F1 分数)
在您的文档中:
- 涉及 AI 功能的配置和自定义文档缺失、不完整或存储在无法访问的位置
- AI 模型或系统在贵组织中实施,但没有模型文档
- 客服人员在贵组织中实施,无需消息和对话流文档
- AI 监控流程不存在或未记录
- 有关所有 AI 流程使用的培训、评估和测试数据的信息不清楚或不可用
- 有关 AI 相关数据清理、偏见测试和结果的信息不清楚或不可用
## 可访问性 技术的*可访问性*是指系统或解决方案对不同能力的人的可用性。设计适合所有用户的系统(无论能力如何),是某些位置和行业的法律要求。除了法律要求之外,构建可访问的系统有助于贵组织培养并增强与利益相关者之间的 Trust。对于面向客户的应用程序,这甚至可以增加收入,因为客户可能会选择使用您的系统,而不是访问较少的替代方案。 Salesforce 会发布[可访问性合规报告 (ACR)](https://www.salesforce.com/company/legal/508_accessibility/),这是行业标准文档,详细描述我们的软件如何符合可访问性标准。我们的大多数基于 UI 的控制,包括 Lightning Web 组件和 Experience Cloud 模板,旨在遵守这些标准。虽然我们的基准可访问性功能对许多企业来说已经足够,但在开始任何项目之前查看我们的 ACR 和发行说明非常重要。这将帮助您识别和记录超出我们标准的任何其他可访问性要求,这取决于您的产品或服务的上市方法。 您可以通过关注两个关键领域来改善系统的可访问性:数据输入和导航。 ### 数据输入 每当用户需要将信息输入到字段、表格或用户界面的其他部分时,都会发生数据输入活动。虽然键盘和鼠标是最常见的输入方法,但一些用户可能会依赖语音转文本或类似设备。此外,您的用户可以使用不同的语言交流。 在设计解决方案时不考虑无障碍环境,会使某些残疾人无法与他们互动。 在设计可访问性时,请考虑以下事项: - **用户喜欢的语言**。根据您的业务运营位置,您可以决定为您的系统设置单一的标准语言,或者您可能想要提供多语言功能。如果以多种语言显示文本,您的设计标准应包含字段标签和其他需要翻译的 UI 元素(例如通知和错误消息)的列表。请母语人士检查翻译的准确性和含义。使用 Salesforce [翻译功能](https://help.salesforce.com/s/articleView?id=sf.workbench_overview.htm&type=5)进行实时元数据和数据翻译,并彻底测试所有多语言功能。 - **将使用的输入设备类型。**列出可用于设计标准中标准键盘和鼠标之外的数据输入的任何工具。在测试计划中包括可访问性测试,并确保所有输入都使用多种类型的输入设备进行测试。 - **表格的可用性**。确保您的表单包含可见标签,提供有用的错误消息,指导用户完成,通知用户他们的进度,并让他们检查、确认和编辑他们的输入。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/compliant#可访问性模式和反模式)列表显示了在 Salesforce 解决方案中为可访问性设计正确(和糟糕)时数据输入的外观。在构建之前,使用这些组件来验证您的设计,或者确定系统中需要重构的区域。 要了解有关 Salesforce 工具的更多信息,以构建更易于访问的数据输入,请参阅与合规[相关的工具](/docs/architect/zh-cn/well-architected/guide/compliant#与合规相关的工具)。 ### 导航 导航涉及用户在屏幕之间和屏幕内的字段之间移动焦点。用户可能需要以多种方式导航系统中的各种 UI 元素,包括通过单击和按键,同时依靠他们的视觉、听觉和触觉。请确保您的设计标准包含您计划支持的导航设备列表。实施团队应在测试时参考此列表,以确保考虑所有导航可能性。 在设计可访问导航时,请考虑以下问题及其答案: - **用户将如何导航解决方案?**列出可用于导航超出设计标准中的标准键盘和鼠标的任何设备。 - **您的导航是否一致?**建立导航控制的设计标准,以确保整个系统的一致性。在整个系统中,导航路径应相似。不一致的导航,例如一个屏幕右下角的蓝色“下一步”按钮和下一个屏幕中间的绿色“下一步”按钮,对一些用户来说可能有点烦恼,但会使应用程序对残疾人不可用。 - **您的测试是否考虑了可访问性?**在测试计划中包括可访问性测试,并确保所有导航流都使用多种类型的输入设备进行测试。 - **键盘焦点是否始终可见?**始终直观显示键盘焦点的当前状态,以帮助依赖键盘的用户导航。 - **导航是否依赖于颜色?**避免仅使用颜色来显示信息或请求操作。遵守 [Web 内容可访问性准则 (WCAG) 2.0](https://www.w3.org/TR/WCAG20/#visual-audio-contrast) 正确使用颜色来传达含义,并应用适当的对比度。 - **您的设计是否已审核?**进行定期审查,以确保用户界面一致且易于理解。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/compliant#可访问性模式和反模式)列表显示了在 Salesforce 解决方案中为可访问性设计正确(和糟糕)时导航的外观。在构建之前,使用这些组件来验证您的设计,或者确定系统中需要重构的区域。 要了解有关 Salesforce 工具的更多信息,以构建更加可访问的导航,请参阅[与合规相关](/docs/architect/zh-cn/well-architected/guide/compliant#与合规相关的工具)的工具。 ### 可访问性模式和反模式 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式浏览](/docs/architect/zh-cn/well-architected-tools/guide/trusted-accessibility)器中,发现更多可访问性模式。
模式 反模式
数据输入 在设计标准中:
- 列出可用于标准键盘和鼠标之外的数据输入的所有设备
- 列出文本值及其翻译成所有支持的语言
在设计标准中:
- 仅列出部分或未列出可用于标准键盘和鼠标之外的数据输入的设备
- 支持的语言与要翻译的 UI 元素一起列出
在您的测试计划中:
- 测试步骤包括使用多种类型的输入设备输入数据
- 测试步骤包含多种语言的数据输入
在您的测试计划中:
- 不包括可访问性测试,或对可访问数据输入的测试是临时进行的
在您的组织中:
- 支持语言的翻译存储在翻译工作台中
在您的组织中:
- 翻译存储在自定义标签中
导航 在设计标准中:
- 明确列出可用于导航的所有设备(而不仅仅是标准键盘和鼠标)
- UI/UX 标准指定所有导航控件的类型和样式
- 明确列出批准传达含义或状态的视觉提示类型,颜色不是主要提示
在设计标准中:
- 设计标准不存在或未考虑导航控制的可访问性要求
- 导航的 UI/UX 标准不一致
- 意义或状态的视觉提示依赖于颜色,或者没有生成器视觉提示的明确列表
在您的测试计划中:
- 测试步骤包括使用多种类型的输入设备进行导航
- 测试计划包括使用 UI/UX 测试来确保一致的导航路径
在您的测试计划中:
- 不包括可访问性测试,或对可访问导航的测试是临时进行的
## 与合规相关的工具
工具描述法律遵守道德标准可访问性
Agentforce Analytics深入了解客服人员的表现X
Agentforce 测试中心运行最多 10 个测试作业,每个测试最多 1000 个测试用例,因此您可以快速创建和评估多个场景。X
引用引用有助于您识别生成的回复中潜在的不准确或幻觉,提高您使用 AI 工具的信心。X
同意 API跟踪客户同意的首选项X
同意事件流发送同意或联系信息更改通知X
同意管理对象管理客户隐私和同意首选项X
数据访问和可移植性应要求导出客户相关数据X
数据分类对象字段的记录密钥合规性和审计信息X
Data 360 报表监控客服人员指令遵守情况X
数据删除删除数据以遵守法律条例X
数据隐私首选项存储客户数据隐私首选项XX
数据翻译翻译向用户显示的数据XX
数据检测将类别和敏感度级别与实际数据保持一致X
Data 360 资源管理器管理数据科学家的项目和对象权限XX
Einstein Data PrismSalesforce 中生成式 AI 应用程序的基准解决方案,提高了使用其基准功能的 AI 解决方案的准确性X
Einstein Trust 层旨在保护数据隐私、提高 AI 准确性并促进在整个 Salesforce 生态系统中负责任地使用 AI 的功能、流程和政策集合X
增强事件日志事件日志捕获客服人员会话中的事件和用户消息,以查看说明遵守情况、测试客服人员并排除故障。X
文件连接从 Salesforce 浏览、搜索和共享外部文件X
Hyperforce符合本地数据存储要求X
元数据翻译翻译语言以本地化应用程序XX
可移植性 API编译可移植性策略中识别的客户数据XX
首选项中心收集客户通信首选项XX
隐私中心满足客户请求和数据隐私法XX
数据处理限制限制个人数据处理方法XX
被遗忘的权利应要求删除单个客户数据X
Salesforce 文件专用共享和存储文件X
安全中心查看多个组织的安全性和隐私设置X
Shield Platform Encryption加密静态和传输中的数据X
翻译工作台维护元数据和数据标签的翻译值XX
## 与合规相关的资源
资源描述法律遵守道德标准可访问性
负责任 AI 设计的 5 个原则以合乎道德的方式设计人工智能 (AI) 功能X
无障碍基本知识 (Trailhead)了解可访问性为何重要X
可访问性一致性报告 (ACR)了解 Salesforce 如何满足可访问性标准X
可访问性概览了解 Salesforce Lightning 中的可访问性X
AI 道德成熟度模型制定实施道德原则的路线图X
AI 红色团队:测试 Trust了解 Salesforce 的“道德黑客”如何通过红色团队合作开发负责任的 AI。X
自动化对手:为红色团队 AI 设计可扩展框架了解 Salesforce 如何自动化对抗性提示生成和响应验证,fuzani 有助于保护 AI 交互,同时减少人类接触有害内容的风险。X
对话设计的最佳实践在设计聊天机器人时遵循最佳实践XX
可持续设计的最佳做法(Trailhead)将可持续性融入您的设计X
同意管理跟踪并遵守同意和选择退出请求X
Einstein的数据策略控制 Einstein 功能中的数据使用XX
设计标准模板为您的组织创建设计标准XXX
符合道德的黑客实践在构建可信 AI 产品方面证明是成功的通过测试恶意使用、故意完整性攻击、良性滥用以及识别负责任的 AI 问题,了解 Salesforce 如何使用红色团队合作来提高 AI 产品的安全性。X
符合道德的领导和业务对技术、平等和道德的见解X
符合道德的使用策略了解 Salesforce 关于产品和服务道德使用的政策X
设计的伦理学(Trailhead)将道德设计融入技术发展X
探索 Salesforce 的文化和价值观 (Trailhead)探索 Salesforce 的核心价值XX
遵循无障碍移动设计指南遵循最佳实践,使您的设计可访问XX
开始使用网络可访问性 (Trailhead)了解如何访问网站和应用程序的基础知识X
Salesforce 如何构建可重复的红色团队基础设施在设计、实施和执行对抗性测试时,我们推荐四个组件X
如何运行结果扫描研讨会在创新时考虑所有可能的结果X
实施数据保护和隐私评估数据保护和隐私要求X
包容性设计 (Trailhead)通过包容性设计原则促进创新XX
KPI 电子表格模板为您的组织设置关键绩效指标 (KPI)X
法律信息探索 Salesforce 的法律信息中心X
LWC Cookie 同意模块控制 Experience Cloud 站点中的用户 Cookie 访问权限XX
隐私概览按地区和行业了解数据隐私X
促进负责和讲道德的客服人员了解如何实施道德的红色团队和测试策略,并为贵组织制定指导原则和标准。X
负责任的客服人员 AI 指南X
负责地创建 AI Trailhead 模块了解如何从数据和算法中消除偏见,以在贵公司创建符合道德的 AI 系统。X
负责任的生成式 AI 指南我们在可信 AI 原则的基础上提出了一套新的准则,侧重于负责任地开发和实施生成式 AI。X
Salesforce 合规认证查看 Salesforce 的合规认证和证明X
可持续设计 (Trailhead)加强企业与社会的关系X
测试网络可访问性 (Trailhead)利用自动和手动测试来确保可访问性X
受信客服人员 AI了解 Agentforce 如何使用保障措施和负责任的 AI 原则来创建符合道德的 AI。x
## 告诉我们您的想法 帮助我们保持 Salesforce 架构合理与您相关;参加我们的[调查](https://sfdc.co/bxNtvh),以提供有关此内容的反馈,并告诉我们您接下来想要看到的内容。 > 在[这里](/docs/architect/zh-cn/well-architected/guide/contributors)阅读我们的更新计划。 ## 导言 安全的系统保护组织的利益相关者和数据。安全架构验证用户身份,将数据访问限制为仅必要的信息,并防止数据泄露。 Salesforce 优先考虑 Customer Trust 和数据安全。Salesforce 平台确保隐私和安全。[Salesforce Trust](https://trust.salesforce.com/)提供实时系统性能和安全信息。 保护您的组织和客户数据是构建安全的 Salesforce 解决方案的基础。作为 Salesforce 架构师,您有责任通过利用 Salesforce 的内置安全功能来保护您的组织和客户数据。在做出这些决策时,请考虑地理分布、行业、公司操作程序和客户数据类型。 您可以通过关注三个方面来使您的解决方案更安全:组织安全性、会话安全性和数据安全。 ## 组织安全性 通过确保只有经过验证的授权用户可以访问系统,并且只有必要的功能和数据,组织安全保护系统免受未经授权的访问。 组织安全性存在问题的迹象包括: - 启用或禁用用户的临时进程 - 更新用户或系统角色更改授权的步骤不明确 - 正确用户安全分配对个人机构 Knowledge 的依赖 - 不符合既定安全框架或行业最佳实践 - 缺乏结构化的数据治理框架和支持政策 通过关注身份验证和授权,您可以为 Salesforce 组织构建更好的组织安全控制。 ### 身份验证 身份验证对于安全性和访问权限管理至关重要,可以验证尝试访问系统的用户的身份。这适用于人工用户(员工、客户)和自动化用户(外部系统、集成),每种用户类型都需要特定的身份验证方案。要确保贵组织中的所有 Salesforce 入口点的安全访问,您需要设置各种身份验证方法。 要在 Salesforce 中创建安全身份验证流: - **根据个人而不是角色创建 Salesforce 用户**当每个用户帐户对应于访问平台的单个个人时,Salesforce 的内置审计功能最有效。使用共享用户帐户会损害这些审计的有效性,引入额外的安全漏洞,加剧帐户泄露的潜在影响,并使您创建有效授权方案的能力复杂化。这包括集成用户的用户帐户。 - 基于 UI 的**安全访问场景**。对于 Salesforce 组织,大多数人类用户需要某种基于 UI 的访问权限(通常称为登录访问权限)。Salesforce 为这些登录场景提供了几层保护,包括: - **密码策略。**网络罪犯通常以用户名和密码为目标,以获取对应用程序的未授权访问。虽然配置[密码策略](https://help.salesforce.com/s/articleView?id=sf.admin_password.htm&type=5)是保护登录访问权限的基本步骤,但重要的是要注意,仅此还不够,因为 Salesforce 允许每个用户覆盖这些策略。 - **多重身份验证 (MFA)**。Salesforce 对所有基于 UI 的用户登录[要求 MFA](https://help.salesforce.com/s/articleView?id=000352937&type=1)。MFA 通过要求用户在成功输入用户名和密码后提供额外的身份识别形式或因素,提供了抵御凭据泄露和暴力攻击的基本防御手段。这种附加因素通常采取物理形式,例如移动设备、安全密钥或生物识别标记。 - **单点登录 (SSO)**。在 SSO 场景中,用户仅在组织的应用程序之间使用一组凭据。从中心位置配置和管理对系统的访问,从而提高了安全性。Salesforce 可以在 [SSO 场景](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5)中充当服务提供商或身份提供商。请确保允许一些或所有管理员直接登录 Salesforce,以便他们可以解决您的 SSO 实施的中断或问题。 - **登录后的步骤。**对于一些用例,您可能需要用户在访问您的系统之前完成额外的步骤。可以实施自定义登录流来指导用户完成这些额外的过程步骤。示例包括: - 接受条款和条件 - 完成[登录发现和无密码登录](https://help.salesforce.com/s/articleView?id=sf.external_identity_passwordless_login_use_cases.htm&type=5)场景 - 限制每个用户同时进行 Salesforce 会话的数量,以减少基于会话的攻击的可能性(请参阅[会话安全](/docs/architect/zh-cn/well-architected/guide/secure#会话安全性)性)。 - 连接到地理围栏服务 - 基于**安全 API 的访问场景**。任何用户都可以为 Salesforce 组织请求基于 API 的访问权限。Salesforce 为基于 API 的场景提供了几层保护,包括: - **API 访问控制**。如果没有 [API 访问控制](https://help.salesforce.com/s/articleView?id=sf.security_api_access_control_about.htm&type=5),任何拥有有效凭据集的人都可以利用任何应用程序与您的组织连接,即使连接的应用程序没有部署在组织中。数据访问控制仍将强制执行,但用户可能会以不受控制的方式访问信息。例如,应用程序可用于下载大量数据,甚至上载损坏的信息,而无需系统管理员批准。 - **仅限 API 权限**。您可以在 Salesforce 中配置仅 API 用户权限。将其作为权限集的一部分分配给任何自动化或[集成用户](https://help.salesforce.com/s/articleView?language=en_US&id=sf.integration_user.htm)角色,以完全阻止基于 UI 的访问。 - **证书和密钥**。[证书和密钥](https://help.salesforce.com/s/articleView?id=sf.security_keys_about.htm&type=5)使 Salesforce 能够验证请求是否来自授权企业或公司。如果您想要将 [SSO 与 Salesforce](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5) 一起使用,您将需要配置证书和密钥。 - **连接的应用程序**。在 Salesforce 中配置[连接的应用程序](https://help.salesforce.com/s/articleView?id=sf.connected_app_overview.htm&type=5)使您能够控制外部系统对 Salesforce 的访问,包括在单个定义中所需的身份验证协议、授权范围和会话行为。 - **命名凭据**。[命名凭据](https://help.salesforce.com/s/articleView?id=sf.named_credentials_define.htm&type=5)使您能够在 Salesforce 的单个定义中控制外部接入点和身份验证协议。使用它们安全地定义和管理来自 Apex、外部服务和 Salesforce Connect 数据源的标注的身份验证。 - **Agentforce Agent 用户身份验证**。基于 Salesforce 构建的 Agentforce 客服人员使用具有可管理权限的客服人员-用户对象,如同真实用户。在设置客服人员时,请谨慎调整访问权限与客服人员扮演的角色,将数据访问权限限制为仅为最终用户提供服务所需的权限。同样重要的是,客服人员可以配置公用和专用操作。对于专用操作,验证和验证最终用户,并将其映射到客服人员上下文。这允许客服人员在最终用户的访问控制中模拟和操作,维护安全性和 Trust。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/secure#组织安全模式和反模式)列表显示了 Salesforce 组织中正确(和差)身份验证架构的外观。在构建之前,使用这些来验证您的设计,或者确定进一步改进的机会。 要了解有关 Salesforce 提供的身份验证工具的更多信息,请参阅[工具相关安全](/docs/architect/zh-cn/well-architected/guide/secure#与安全相关的工具)。 ### 授权 授权定义了用户可以访问哪些特性、功能和数据,以及他们可以在经过[身份验证](/docs/architect/zh-cn/well-architected/guide/secure#身份验证)后对这些资源执行的操作。授权控制不仅仅针对人类用户,它们还需要针对 Agentforce 客服人员用户进行定制,特别是向未经身份验证的最终用户提供服务的客服人员。 虽然限制谁可以验证您的组织是至关重要的第一步,但同样重要的是将强身份验证与强大的授权配对。如果没有适当的授权控制,用户可能会以对您的业务和相关方有害的方式创建、编辑和删除记录或访问系统功能。授权控制不足也会使系统更难使用。通过控制用户可在系统中执行的操作,您可以培养更高的 Trust 级别,从而保护您的系统和用户。 要为 Salesforce 构建安全授权方案: - **遵循最小特权原则**。通过只为用户分配他们的任务所需的权限来接受最小权限 (PoLP) 的原则。要遵循这一原则,请设计粒度和模块化权限集。这允许通过权限集小组进行复杂的访问控制,实现权限的精确管理,包括[静音](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_muting.htm&type=5)、[设置到期日期](https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_permissions_assn_expiration.htm&type=5&release=238)等。将您的系统[功能单元](/docs/architect/zh-cn/well-architected/guide/composable#功能单元)与业务功能结合起来,定义精细的权限和有效的权限集组。请记住,权限适用于 Salesforce 中的*元数据*访问。有关为 Salesforce *数据*访问配置 PoLP 的详细信息,请参阅[共享和可见](/docs/architect/zh-cn/well-architected/guide/secure#共享和可见性)性。 - **从角色而不是个人的角度考虑用户访问。**从单个用户的角度考虑授权(或总体安全性)不会将您的系统设置为可以扩展和发展。相反,设计和管理代表用户小组的角色。安全 Salesforce 解决方案使用个人进行身份验证,并使用角色进行授权。通过为不同的角色定义安全配置,您可以获得对安全模型中访问权限和权限的精细控制,从而最大限度地减少了长期的重构需求。包括您在[设计标准和文档](/docs/architect/zh-cn/well-architected/guide/intentional#可读性)中定义的安全人员。 - **使用权限集和权限集组控制用户对元数据的访问。**权限集和权限集组控制用户可以访问哪些元数据,以及他们可以对该元数据执行哪些操作。要了解有关 Salesforce 元数据的更多信息,请参见[元数据与数据](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#元数据与数据)。通过权限集和权限集组配置应用程序分配、功能许可证激活、受管软件包访问权限、系统权限、[CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm) 访问权限和字段级访问权限。将此访问权限包含在[设计标准和文档](/docs/architect/zh-cn/well-architected/guide/intentional#可读性)中。 - **使用组织范围的默认值 (OWD) 和共享来控制用户的数据访问权限。**[数据和元数据](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#元数据与数据)是 Salesforce 中不同的实体,需要分别进行访问控制。使用 OWD 和内置共享工具来配置对 Salesforce 数据(单个记录、文件和文档)的访问权限。有关更多详细信息,请查看[数据安全](/docs/architect/zh-cn/well-architected/guide/secure#数据安全)性。 - **使用 OAuth 范围来控制对连接的应用程序的访问权限。**配置连接的应用程序时,您可以定义应用程序用户对 Salesforce 资源拥有的[范围](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US)或访问权限。有关管理 OAuth 令牌的更多信息,请查看[会话管理](/docs/architect/zh-cn/well-architected/guide/secure#会话管理)。 - **为每个集成创建一个 Salesforce 用户。**要遵守最低权限原则,请为每个集成创建唯一的 Salesforce [集成用户](https://help.salesforce.com/s/articleView?id=sf.integration_user.htm)。这允许您分配特定的数据访问权限,改善对操作的控制,确保事务的可追溯性,并最大限度地减少潜在安全漏洞的影响。 - **通过 PoLP 为所有客服人员用户实施唯一客户。**每个 Agentforce 客服人员用户应该是唯一的,并且不能在多个客服人员之间重复使用。这些客户的权限必须严格遵守最低权限原则。请谨记,客服人员用户执行的操作可能在 Salesforce 内部或针对不尊重 Salesforce 访问控制的外部系统的提升安全上下文中操作。这可能会导致操作访问敏感信息或向用户泄露敏感信息。 - **最大限度地减少简档的使用,并将任何访问控制从简档中迁移出去**简档提供了限制访问[登录 IP 范围](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm&type=5)、[登录时间](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5)和特定于传统 Salesforce Classic 用户界面的功能(特别是默认记录类型和页面布局分配)的能力。简档中当前的任何其他功能应迁移到[权限集和权限集组](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_create_with_perm_sets.htm)中的等效功能。您的简档中与 Salesforce Classic UI 功能相关的功能应作为补救的目标。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/secure#组织安全模式和反模式)列表显示了 Salesforce 组织中正确(和差)的授权实践。在构建之前,使用这些来验证您的设计,或者确定进一步改进的机会。 要了解有关 Salesforce 提供的授权工具的更多信息,请参阅[工具相关安全](/docs/architect/zh-cn/well-architected/guide/secure#与安全相关的工具)。 ### 组织安全模式和反模式 此表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式浏览](/docs/architect/zh-cn/well-architected-tools/guide/trusted-organizational-security)器中,发现组织安全的更多模式。
模式 反模式
身份验证 在设计标准和文档中:
- 明确定义并列出批准的安全角色
- 安全矩阵中存在安全角色和允许的身份验证方案(UI、API)之间的映射
如果存在设计标准和文档,它们:
- 不包括安全角色
- 请勿包含具有安全角色和允许身份验证方案明确映射的安全矩阵
在您的组织中:
- 登录配置符合 Salesforce MFA 检查
- 登录 Salesforce 的用户和实体之间的关系是 1:1(没有共享用户)
- API 访问控制阻止用户通过未经授权的连接的应用程序进行身份验证
- 如果启用了 SSO,批准的管理员用户具有直接登录访问权限
在您的组织中:
- 登录配置与 Salesforce MFA 检查不一致
- 登录 Salesforce 的用户和实体之间的关系不是 1:1(存在共享用户帐户)
- 如果用户从防火墙后访问 Salesforce,防火墙会使用硬编码的 IP 地址来保护进出 Salesforce 的通信
- 未启用 API 访问控制
- 如果启用了 SSO,则没有批准的管理员用户拥有直接登录访问权限
在LWC, Apex, Aura中:
- 执行身份验证的方法使用命名凭据来处理用户名/密码流
- 用户名或密码不会以可读的格式显示在代码中(没有硬编码的值或字符串)
- 如果存在自定义登录流,所有相关自定义代码会使用适当的 SessionManagement 方法
在LWC, Apex, Aura中:
- 身份验证是临时处理的
- 用户名和密码显示在代码中
授权 在设计标准和文档中:
- 有权访问 Salesforce 的每个用户和系统都映射到安全矩阵中的一个或多个角色
- 安全矩阵明确列出元数据权限和分配的用户角色
- 明确列出了授予提升权限的用例,包括:
-- 修改所有数据权限
-- 查看所有数据权限
如果存在设计标准和文档,它们:
- 不包括安全矩阵
- 未明确列出权限
- 未明确列出授予提升权限的用例
在您的组织中:
- 权限集和权限集组用于控制对元数据的访问
- 权限集和权限集组与业务功能保持一致
- 分配给用户的权限遵循安全矩阵定义
- 简档仅用于控制登录 IP 范围和登录时间
- 为每个集成配置唯一的仅 API 集成用户
在您的组织中:
- 权限集小组未配置为允许基于业务功能的访问权限
- 权限集是临时配置的
- 权限集是冗余的或大量重复;难以理解清晰的功能逻辑和集之间的差异
- 分配给用户的权限不遵循安全矩阵定义
- 简档包含元数据的访问控制
- 仅 API 用户未配置或在多个集成中共享
在 Apex 中:
- 数据库操作适当地执行字段和对象级访问权限检查,包括:
-- DML 和数据库 DML 语句声明数据操作的用户或系统模式和/或
-- DML 和数据库 DML 语句在数据操作之前使用 stripInaccessible 方法
-- SOQL 和 SOSL 语句与 USER_MODE 和 System_MODE 关键字 AND/OR 一起使用
-- stripInaccessible 方法用于筛选查询和子查询结果
-- sObject 描述结果方法(即 isAccessible、isCreateable、isUpdateable 和/或 isDeletable)被谨慎使用
在 Apex 中:
- DML、数据库类方法、SOQL 和 SOSL 在默认系统模式下运行
- 数据库操作未正确执行访问权限检查,包括:
-- DML 或数据库类方法仅使用 isAccessible、isCreateable、isUpdateable 和/或 isDeletable 检查进行 sObject 和字段级访问
-- SOQL 查询仅使用 with SECURITY_ENFORCED 关键字进行访问限制
在流中(流设计安全注意事项):
- 流使用最严格的执行上下文,理想情况下是用户模式
- 子流执行安全敏感或特权数据访问,以最小化执行上下文
- 在记录触发的流中执行的限制逻辑
- 验证流输入,以确保仅将允许的负载作为输入传递
在流中:
- 流以系统模式或不带共享的系统模式运行,无论流执行什么操作
- 所有流逻辑都在单个大型流中执行
- 流输入未经验证,未经验证就传递给消费者
## 会话安全性 会话是一段时间内与用户相关联的一系列请求和响应。当用户成功验证 Salesforce 时,将启动会话。[会话安全](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.security_overview_sessions.htm)是通过阻止会话干扰或劫持来配置您的系统以防止未经授权的访问和数据泄露的实践。 系统中的所有用户活动都在会话上下文中发生,因此重要的是考虑会话的启动方式、会话期间可能发生的情况、用户将(和应该)使用哪些设备,以及如何检测和响应可疑或异常会话行为。 您可以通过关注三个关键来构建 Salesforce 中的会话安全性:会话管理、设备访问以及威胁检测和响应。 ### 会话管理 会话将在用户成功验证并访问 Salesforce 时启动。这些会话使平台能够将特定请求和响应与该特定用户相关联。 HTTPS 协议促进了前端客户端和 Salesforce 平台之间的通信。客户端可以包括浏览器、移动应用程序、本地应用程序等。HTTPS 是一种无状态协议,这意味着每个通信都是离散的,与任何以前或未来的通信都是无关的。 这种无状态的方法加速了网络通信,并消除了由于数据包之间的链路断开而造成的错误。但是,Web 应用程序仍然需要一种在多个请求和响应交互中跟踪每个用户的身份和其他相关信息的方式。与大多数 Web 应用程序一样,Salesforce 使用会话和[令牌](https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_tokens_scopes.htm&type=5)来实现这一点。 - **会话**使 Salesforce 能够将请求和响应与用户相关联。用户经过身份验证后,平台会将会话 ID 发送回客户端应用程序,其中包含该 ID 以及任何用户请求(例如导航、搜索和提交数据)。 - **令牌**使用户和连接的应用程序能够验证他们的身份一次,并从那时起使用唯一的访问令牌。令牌具有有限的生命周期,并且只提供对特定资源的访问权限(有关配置访问权限级别的更多信息,请参见[授权](/docs/architect/zh-cn/well-architected/guide/secure#授权))。令牌允许访问授权资源,而无需用户登录。 如果会话和令牌未正确保护,不良行为者可能会干扰它们,并冒充用户或在系统中执行恶意代码。 要为 Salesforce 构建安全会话管理: - **了解 Salesforce 如何分类会话类型**识别批准的[会话类型](https://help.salesforce.com/s/articleView?id=sf.security_session_types.htm&type=5)并将其映射到安全用户角色,并在文档中记录这些角色。 - **控制会话的发起方式以及会话流量的去向。**在您确定了允许各种用户角色启动的会话类型后,配置控制,以阻止来自未批准的源或上下文的会话。Salesforce 提供了几种控制会话来源和流量的方法,包括: - **内置会话保护**。Salesforce 会自动为基于会话的恶意活动启用组织范围保护,包括跨站点脚本、跨站点请求伪造、[内容嗅探](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing)、[点击劫持](https://owasp.org/www-community/attacks/Clickjacking)等。这些保护不应被禁用;一些保护不能被禁用。 - **域和 IP 范围**。默认情况下,所有 Salesforce 组织都启用 [My Domain](https://help.salesforce.com/s/articleView?id=sf.domain_name_overview.htm&type=5),这将为 Salesforce 访问权限创建特定于公司的子域。您可以通过 My Domain 自定义或更改与组织关联的名称。此外,Salesforce 支持 Experience Cloud 站点和其他应用程序页面的其他[域配置](https://help.salesforce.com/s/articleView?id=sf.domain_mgmt_overview.htm&type=5)。注意:如果用户需要在公司防火墙后访问 Salesforce,请将[所需域](https://help.salesforce.com/s/articleView?id=sf.setup_domains.htm&type=5)添加到防火墙允许列表中。您可以设置[登录 IP 范围](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/users_profiles_epui_login_ip_ranges_edit.htm)和[受信 IP 范围](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm),以控制对 Salesforce 的入站登录和会话请求。 - **登录时间**。如果某些用户角色设置了工作时间,您可以限制他们在定义的[登录时间](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5)之外访问 Salesforce 的能力。 - **控制需要添加会话级安全性的活动。**默认情况下,会话可以有两种[安全级别](https://help.salesforce.com/s/articleView?id=sf.security_overview_sessions.htm&type=5):标准和高保证。使用这些安全级别来控制用户如何执行和不能执行活动,例如访问报表和仪表板,或管理 Salesforce 组织中的安全配置。会话级安全策略可以要求用户建立[高保证会话](https://help.salesforce.com/s/articleView?id=sf.security_auth_require_ha_session.htm&type=5)来执行操作,或者完全阻止用户执行任何敏感操作。 - **控制需要添加基于会话的权限的活动。**Salesforce 支持[基于会话](https://help.salesforce.com/s/articleView?id=sf.perm_sets_session_use.htm&type=5)的权限激活,以临时允许用户在特定会话期间提升授权或访问权限。您可以通过流或 Salesforce API 激活和取消激活基于会话的权限。 - **通过超时管理非活动用户会话**结束非活动会话是管理会话安全性的关键部分。例如,当用户在浏览器选项卡中保持 Salesforce 会话打开,但在另一个应用程序中处于活动状态时,或者当用户的移动设备登录 Salesforce,但无人参与时,这将有助于保护您的系统。Salesforce 默认会话不活动超时为 2 小时。您可以增加或减少会话不活动超时级别,但增加超时必须有一个令人信服和有充分记录的理由。 - **通过令牌配置管理连接的应用程序会话。**在配置连接的应用程序时,您还可以定义将授予通过连接的应用程序访问 Salesforce 的用户的授权范围或级别。此范围通过 [OAuth 令牌](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US)在会话级别强制执行,这些令牌是在连接的应用程序的用户成功验证后颁发的。您可以通过[令牌刷新策略](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US)控制令牌的持续时间。如果需要,组织管理员可以按用户和组织手动撤销令牌。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/secure#会话安全模式和反模式)列表显示了 Salesforce 组织中正确(和差)的会话管理。在构建之前,使用这些来验证您的设计,或者确定进一步改进的机会。 要了解有关 Salesforce 提供的会话管理工具的更多信息,请参阅[工具相关安全](/docs/architect/zh-cn/well-architected/guide/secure#与安全相关的工具)。 ### 设备访问权限 在当前上下文中,*设备*是个人用于访问 Salesforce 的任何电子设备,例如台式工作站、笔记本电脑、平板电脑或手机。 便携式设备为用户提供了从任何位置访问 Salesforce 的灵活性。但是,这种便利性可能会为恶意行为者引入额外的攻击向量。这些威胁媒介多种多样,从简单的策略(例如在公共场所肩膀冲浪以窃取凭据),到更复杂的方法(例如在设备上安装恶意软件或创建虚假的公共 Wi-Fi 网络以拦截数据传输)。因此,保护设备(特别是便携式设备)对整体系统安全性至关重要。 保护 Salesforce 的设备访问权限: - **使用 Salesforce 提供的移动应用程序解决方案。**让移动设备上需要访问 Salesforce 的用户使用适用于 iOS 和 Android 的官方 [Salesforce 应用程序](https://help.salesforce.com/s/articleView?id=sf.mobile_security.htm&type=5)。如果业务需求需要自定义移动解决方案,应使用 [Salesforce Mobile SDK](https://developer.salesforce.com/docs/atlas.en-us.mobile_sdk.meta/mobile_sdk/intro.htm),它提供安全身份验证和授权的方法。 - **将移动设备使用情况设计到您的会话管理中。**会话安全级别、会话超时和其他会话上下文控制应考虑用户在移动设备上的任何预期访问权限。考虑哪些设备应该和不应该被允许访问 Salesforce,以及哪些类型的用户应该有权访问移动会话。在安全角色文档中包括移动访问标准。有关此主题的更多信息,请查看[会话管理](/docs/architect/zh-cn/well-architected/guide/secure#会话管理)。 - **使用移动设备管理 (MDM) 技术补充设备级安全性。**适用于 iOS 和 Android 的 Salesforce 应用程序[兼容许多流行](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mdm.htm&type=5)的 MDM 套件。您可以通过首选 MDM 解决方案为用户设备上的 Salesforce 应用程序配置其他访问控制。 - **通过移动应用程序管理 (MAM) 技术,补充应用程序级安全性。**MAM 技术支持移动设备上的应用程序级控制。Salesforce 为 Salesforce 移动应用程序提供付费 [MAM 加载项](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mam_overview.htm&type=5)。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/secure#会话安全模式和反模式)列表显示了 Salesforce 组织中正确(和糟糕)的设备管理。在构建之前,使用这些来验证您的设计,或者确定进一步改进的机会。 要了解有关 Salesforce 提供的设备管理工具的更多信息,请参阅[工具相关安全](/docs/architect/zh-cn/well-architected/guide/secure#与安全相关的工具)。 ### 威胁检测和响应 威胁检测是识别系统中可能指示恶意活动的行为模式的过程。这可能包括下载的数据量大于平均水平,或者用户在比平均水平更短的时间内修改了若干记录上包含敏感数据的字段。对威胁的响应可以包括自动会话到期、警报和其他通知。 威胁检测的目标是尽快识别和响应潜在问题。基于实时威胁检测采取行动可以阻止跟踪中的恶意行为。Salesforce 作为加载项或 [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) 的一部分提供[实时事件监测](https://help.salesforce.com/s/articleView?id=sf.real_time_event_monitoring_overview.htm&type=5)。如果您有高度敏感的应用程序或需要强大的实时威胁检测和响应功能,请使用以下解决方案之一。 要为您的 Salesforce 解决方案建立有效的威胁检测和响应策略: - **使用内置审计功能**。Salesforce 提供各种[内置工具](https://help.salesforce.com/s/articleView?id=sf.monitoring_admin.htm&type=5),以帮助跟踪和审核对贵组织的更改。例如,[设置审计跟踪](https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5)允许您查看管理操作的审计历史记录。默认情况下,Salesforce 会在有限的时间内跟踪字段级更改,但您可以激活[字段历史跟踪](https://help.salesforce.com/s/articleView?id=sf.tracking_field_history.htm&type=5),以在 UI 中显示最多 18 个月的字段更改,并通过 API 显示最多 24 个月的字段更改。此外,您可以激活[字段审计跟踪](https://help.salesforce.com/s/articleView?id=sf.field_audit_trail.htm&type=5),以无限期保留字段级更改的审计历史记录(直到您手动删除数据)。 - **建立定期审核**。审计对于识别实时威胁检测可能错过的异常更改至关重要。考虑这样一个场景,一个具有合法访问权限的用户在很长时期内每天一致地删除少量记录。由于此用户拥有有效的登录凭据、删除记录的正确授权,并且不是一次删除大量记录,因此该活动不太可能被检测为实时威胁。但审核用户活动报表的审计团队将明确识别单个用户随着时间的推移过度删除记录的趋势,使其更易于应对。作为[治理策略](/docs/architect/zh-cn/well-architected/guide/intentional#治理)的一部分,建立定期间隔,以审计登录历史、用户会话活动和连接的应用程序使用情况。 - **制定威胁响应策略,并将其包含在安全策略中。**创建威胁响应策略,涵盖: - 威胁响应类型定义(例如警报和自动化)以及任何相关方[群体应参与](/docs/architect/zh-cn/well-architected/guide/resilient#事件响应)。有关设计消息或提醒的更多信息,请查看[错误和通知](/docs/architect/zh-cn/well-architected/guide/engaging#通知和消息)。 - 可视为威胁的实时更改或活动的特定类别,以及每个威胁的相关响应类型 - 所有自动威胁响应(例如撤销令牌、结束会话、停用用户帐户或阻止访问资源)和自动触发器的清晰列表 Event Monitoring 通过启用实时威胁检测和响应,提供了实施这一原则所需的数据。事务安全性应用贵公司的策略驱动操作,事件类型支持随时间监控用户和应用程序访问权限。 Salesforce 的本地威胁检测服务使用统计和机器学习模型来识别可疑行为。此服务生成特定事件,防止网络攻击和可疑数据访问。 事务安全性更进一步,因为它提供了一个框架来拦截在贵组织中发生的关键事件,并应用贵公司的策略驱动的操作。这将 Event Monitoring 从日志记录工具转变为自动安全防御的重要组成部分。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/secure#会话安全模式和反模式)列表显示了 Salesforce 组织中正确(和差)的威胁检测和响应。在构建之前,使用这些来验证您的设计,或者确定进一步改进的机会。 要了解有关 Salesforce 提供的威胁检测、警报和响应自动化工具的更多信息,请参阅[工具相关安全](/docs/architect/zh-cn/well-architected/guide/secure#与安全相关的工具)。 ### 会话安全模式和反模式 此表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式浏览](/docs/architect/zh-cn/well-architected-tools/guide/trusted-session-security)器中,发现会话安全的更多模式。
模式 反模式
会话管理 在设计标准和文档中:
- 安全角色清楚地列出每个角色批准的会话类型和超时/持续时间设置
- 已指定登录时间(或标识为不需要)
- 需要提升会话级安全性或权限的操作清晰可查
- 连接的应用程序范围和令牌管理策略清晰可查
在设计标准和文档中:
- 安全角色不存在或缺少有关会话类型和超时/持续时间设置的信息
- 安全策略不包含有关连接的应用程序范围或令牌管理的信息
在您的组织中:
- 会话审计显示用户仅通过预期的会话类型访问 Salesforce
- 对于“仅 API 用户”访问权限,有一个清晰有效的权限集(“仅 API”权限集设置为真),并且所有集成和自动化用户都被分配
- 如果用户从防火墙后访问 Salesforce,防火墙会使用必填域的允许列表,而不是 IP 地址来保护与 Salesforce 的通信
- 非活动会话超时间隔不超过默认值(2 小时)
- 启用以下所有设置:
-- 设置页面的点击劫持保护
-- 非设置 Salesforce 页面的点击劫持保护
-- 跨站点请求伪造 (CSRF) 保护
-- 跨站点脚本 (XSS) 保护
-- 启用内容嗅探保护
-- 推荐人 URL 保护
-- 在用户重定向到 Salesforce 外部之前警告他们
在您的组织中:
- 没有定期会话审计
- 没有定义用户应该拥有哪些会话类型
- 集成和自动化用户中的“仅限 API”权限不明确或缺失
- 如果用户从防火墙后访问 Salesforce,防火墙会使用硬编码的 IP 地址来保护进出 Salesforce 的通信
- 非活动会话超时间隔超过默认值(2 小时)
- 禁用以下任何设置:
-- 设置页面的点击劫持保护
-- 非设置 Salesforce 页面的点击劫持保护
-- 跨站点请求伪造 (CSRF) 保护
-- 跨站点脚本 (XSS) 保护
-- 启用内容嗅探保护
-- 推荐人 URL 保护
-- 在用户重定向到 Salesforce 外部之前警告他们
在LWC, Apex, Aura中:
- 如果存在自定义登录流,所有相关自定义代码会使用适当的 SessionManagement 方法来分配会话级安全性
在LWC, Apex, Aura中:
- 如果存在自定义登录流,没有分配会话级安全性的逻辑
设备访问权限 在设计标准和文档中:
- 设备策略清晰可发现
- 安全角色明确映射到适当的设备使用情况和策略
在设计标准和文档中:
- 安全策略不存在或不包含有关设备访问权限的信息
在您的组织中:
- Salesforce 移动连接的应用程序配置需要在不活动后解锁 PIN/密码
- 如果业务需求需要严格控制可以访问 Salesforce Mobile 的用户,将启用 API 访问控制,并将权限集分配给 Salesforce 移动应用程序的所有用户
在您的组织中:
- Salesforce 移动连接的应用程序未配置为需要 PIN/密码解锁才能不活动
– 业务需求需要严格控制可以访问 Salesforce Mobile 的用户,但未启用 API 访问控制,或权限集未用于控制对 Salesforce 移动应用程序的访问
威胁检测和响应 在设计标准和文档中:
- 安全策略包含应触发响应的事件列表以及适当的响应类型
- 已为数据模型中的所有对象指定审计级别
- 记录查看 Salesforce 中可用日志的步骤
- 所有自动回复都有清晰的记录
在设计标准和文档中:
- 安全策略不存在或不包含有关威胁检测和警报的信息
- 自动回复的文档不存在或不清楚
在贵公司内:
- 审计数据在业务利益相关者可以理解和访问的报表中可用
- 定期审查审计历史和报告
在贵公司内:
- 审计数据只能通过需要主题专业知识才能访问和解释的日志文件获得
- 没有审核审计信息的流程
在您的组织中:
- 如果检测到异常使用,自动化可通过停用用户帐户或阻止访问资源来响应威胁
- 通知和警报被配置为通知适当的用户异常活动
- 对包含专用或敏感数据的所有字段启用字段历史跟踪
在您的组织中:
- 没有自动化来应对威胁
- 通知和警报未配置为通知适当用户异常活动,或存在一些与异常活动相关的通知和警报,但它们是临时的
- 未始终为包含专用或敏感数据的字段启用字段历史跟踪
## 数据安全 数据安全是保护您的数据免受未经授权的访问、损坏或意外删除的实践。数据安全包括保护传输中和静态的数据。 强大的数据安全性最大限度地减少了未经授权访问您的系统的风险和潜在损害。数据安全性不足会使系统容易受到数据泄露的攻击,这会严重影响客户和贵公司。因此,保护您的数据是构建安全架构的基础。 提高数据安全性首先要清楚地了解在 Salesforce 中什么被认为是数据,以及它的分类。存储在 Salesforce 组织中的单个记录、文件和文档是它的数据。有关元数据和数据之间区别的更多信息,请参阅[Salesforce 架构基础](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#元数据与数据)。 通过关注共享和可见性以及加密的使用,您可以在 Salesforce 解决方案中建立更强的数据安全性。 > 注意:在设计数据安全时,请确保考虑[到数据隐私](/docs/architect/zh-cn/well-architected/guide/compliant#数据隐私)以及[归档和清除](/docs/architect/zh-cn/well-architected/guide/resilient#连续性计划),因为这两个概念都会影响解决方案的整体数据安全。 ### 数据分类 根据敏感程度(例如,公共、内部、机密、受限),识别并分类存储在 Salesforce 平台中的所有数据。定义清晰的**数据分类策略**,概述如何处理和保护每种数据类型。实施适当的安全控制,例如字段级安全性、加密和数据屏蔽,以强制执行策略并保护敏感数据免受未经授权的访问或泄露。定期审查和审核这些分类和控制,以确保它们与业务和合规要求保持一致。 ### 共享和可见性 共享和可见性涉及配置您的系统,以控制用户如何访问 Salesforce 中的数据。重要的是要注意到,共享和可见性控制用户可以访问哪些单个记录,但这些设置本身并不能最终控制用户可以对特定记录执行的操作,或该记录中的哪些特定字段可见。执行数据操作的权限(例如 [CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm))通过元数据访问控制分配给用户,元数据访问控制可以在单个对象和字段级别为用户配置。有关更多信息,请参阅[授权](/docs/architect/zh-cn/well-architected/guide/secure#授权)。 Agentforce 操作会将数据暴露给通常缺乏直接访问的经过身份验证的用户和匿名用户。在构建 Agentforce 客服人员时,请仔细考虑并记录分配给客服人员的所有操作。对于每个操作,您必须了解: - 操作可以访问哪些数据。 - 操作在什么安全上下文中运行。 - 操作是否具有 Knowledge 检索或其他功能,可以将敏感或受限数据合并到客服人员会话中。 要在 Salesforce 中配置有效共享和可见性: - **围绕有意义的工作职能设计访问权限**创建安全矩阵,将[用户角色](/docs/architect/zh-cn/well-architected/guide/secure#身份验证)映射到要执行的业务功能。使用此[模板](/docs/architect/zh-cn/resources/guide/security-policy-template)作为基础来设计您的共享和可见性。有关识别有意义的业务功能的更多信息,请参见[功能单位](/docs/architect/zh-cn/well-architected/guide/composable#功能单元)。 - **选择应用最小特权原则的最简单路径**。当您在设计共享和可见性方案时应用[最小权限原则](/docs/architect/zh-cn/well-architected/guide/secure#授权)时,请以最直接的方式执行此操作。避免过度设计的数据限制和共享方案,这可能会导致系统可维护性、可扩展性和适应性的下游问题。相反,利用 [Salesforce 中灵活](https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/sharing_architecture.pdf)的分层数据共享,在数据级别为用户访问权限配置细粒度规则。 - **将*内部*组织范围的默认值 (OWD) 设置为公用只读,除非您的业务涉及敏感数据,否则使用专用。**OWD 控制用户在数据级别将拥有的“最低”权限级别。您不能将访问权限限制在 OWD 级别以下。虽然专用 OWD 似乎在每个用例中都是理想的选择,但整个企业中的用户最终常常会通过复杂的共享方案无意中复制一个更宽松的 OWD。此外,专用 OWD 会使用户创建重复数据。共享计算(和重新计算)可能需要大量时间才能完成,这取决于数据量和父-子或所有权倾斜 — 专用 OWD 加剧了这种情况。请注意,OWD 无法控制 CRUD 权限和字段级可见性。只有在业务需求证明合理时,才选择专用 OWD — 通常,此类证明与[合规性](/docs/architect/zh-cn/well-architected/guide/compliant)相关。 - **将*外部*组织范围的默认值 (OWD) 设置为专用,除非您有令人信服的业务理由允许更大的访问权限。**[外部 OWD](https://help.salesforce.com/s/articleView?id=sf.security_owd_external.htm&type=5) 适用于从 Experience Cloud 站点、入口网站等访问 Salesforce 数据的用户。这允许您为内部和外部用户配置单独的 OWD 基准,以允许不同类型的“最小”权限。始终将外部用户的 OWD 设置为专用 — 对于更开放的级别,例外情况必须由业务需求明确证明。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/secure#数据安全模式和反模式)列表显示了 Salesforce 组织中正确(和差)共享和可见性的外观。在构建之前,使用这些来验证您的设计,或者确定进一步改进的机会。 要了解有关 Salesforce 共享和可见性工具的更多信息,请参阅[工具相关安全](/docs/architect/zh-cn/well-architected/guide/secure#与安全相关的工具)。 ### 加密的使用 加密将可读数据转换为无法解码的编码格式。加密数据可以通过密钥解密或翻译回其原始形式。因此,加密是保护静态和传输数据的最有效方法之一,可确保即使未经授权的方访问数据,也无法读取。 要在 Salesforce 解决方案中设计正确使用加密: - **始终充分加密传输中的数据**。Salesforce 为在 [Salesforce 支持浏览](https://help.salesforce.com/s/articleView?id=sf.getstart_browser_overview.htm&type=5)器中发生的所有会话[使用传输层安全 (TLS)](https://help.salesforce.com/s/articleView?id=sf.security_overview_infrastructure.htm&type=5),并要求使用 HTTPS 的出站呼叫满足特定的安全标准。平台 API 也默认使用 HTTPS。此外,在 Salesforce Experience Cloud 站点或入口网站及其相关 Salesforce 组织之间发送的数据[默认](https://help.salesforce.com/s/articleView?id=xcloud.security_pe_platform_encryption_faq.htm&type=5)在传输过程中加密。如果您使用 Salesforce 的电子[邮件服务](https://help.salesforce.com/s/articleView?id=sf.emailadmin_send_email_from_salesforce_overview.htm&type=5),Salesforce 用于[发送和尝试发送](https://help.salesforce.com/s/articleView?id=sf.emailadmin_deliverability.htm&type=5)电子邮件的传输层安全性 (TLS) 有默认级别。您至少应确保组织设置不低于默认设置,除非您有明确的业务理由。根据数据的分类和敏感性,考虑通过 AWS Direct Connect 或 Salesforce Private Connect 利用与 Salesforce 的专用网络连接。这可以确保您的数据不会通过公共互联网,而是通过专用网络连接安全地流动,以便用户访问和集成。 - **如果业务需要,加密静态数据。**Salesforce 提供了不同的方法来加密静态数据。 - **Hyperforce**数据在使用 [Hyperforce](/docs/architect/zh-cn/fundamentals/guide/platform-multitenant-architecture#hyperforce) 的组织中静态加密。加密由 Salesforce 为您的组织管理。您无法创建(或销毁)自己的加密密钥。 - **Salesforce Shield**[Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) 使您能够加密 Salesforce 组织中其他各层的静态数据,包括应用程序层和数据库层。通过 Shield,您拥有租户加密密钥的完整管理功能,包括强大的“自带密钥”(BYOK)选项。您也可以加密非结构化数据(包括文件、附件、搜索索引和事件)。基于 Hyperforce 的实例提供了使用外部密钥管理器的选项,允许您自带 AWS KMS。借助此功能,您可以完全控制 KMS 中用于加密和解密存储在 Salesforce 中的数据的加密密钥,从而加强安全性并符合贵组织的合规要求。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/secure#数据安全模式和反模式)列表显示了加密在 Salesforce 组织中的正确(和糟糕)使用。在构建之前,使用这些来验证您的设计,或者确定进一步改进的机会。 要了解有关 Salesforce 提供的加密工具的更多信息,请参阅[工具相关安全](/docs/architect/zh-cn/well-architected/guide/secure#与安全相关的工具)。 ### 数据安全模式和反模式 此表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式浏览](/docs/architect/zh-cn/well-architected-tools/guide/trusted-data-security)器中,发现更多数据安全模式。
模式 反模式
共享和可见性 在设计标准和文档中:
- 安全矩阵概述每个用户角色有权访问的数据
- 对外部用户和内部用户使用不同的数据访问标准(如果适用)
在设计标准和文档中:
- 设计标准和文档不存在或不包含安全矩阵
- 如果存在安全矩阵,则不会概述用户角色的数据访问权限
在您的组织中:
- 由于合规性要求,内部用户的组织范围默认设置 (OWD) 是公用读取,或内部用户的 OWD 是专用
- 外部用户的 OWD 是专用的
- 生成式 AI 仅在用户模式下操作,或选择用于系统访问的用途具有明确的业务理由
在您的组织中:
- 内部用户的 OWD 设置为专用,没有业务理由,或者内部用户的 OWD 设置为公用读/写
- 外部用户的 OWD 设置为专用以外的任何内容,而没有业务理由
- 生成式 AI 在无业务理由的系统模式下运行
在 Apex 中:
- 访问数据 (SOQL/SOSL) 或执行数据操作 (DML/Database Class 方法) 的所有代码与共享关键字一起使用
在 Apex 中:
- 共享关键字的使用不一致
使用加密 在设计标准和文档中:
- 传输中和(如果需要)静态数据加密的用例清晰易懂
- 明确列出批准的加密协议
- 代码文档明确指出加密的使用位置和使用的协议
在设计标准和文档中:
- 批准的加密协议不明确或未列出
- 代码没有文档记录,或者文档记录不清楚在代码中使用加密的位置和方式
在您的组织中:
- 如果发现安全风险需要更大的静态数据保护,Hyperforce 或 Salesforce Shield 会提供静态加密
在您的组织中:
- 业务需求需要更大的静态数据保护,但未使用 Hyperforce 或 Salesforce Shield
在 Apex 中:
- 如果业务需求需要在传输过程中加强数据保护,集成涉及的所有代码都会使用加密类方法执行逻辑,以在传输前加密数据或在接收时解密数据
在 Apex 中:
- 业务需求要求在传输过程中加强数据保护,但集成涉及的代码在传输前或接收时执行逻辑而不加密数据,或者临时使用加密类方法
## 与安全相关的工具
工具描述组织安全性会话安全性数据安全
Apex 加密类在 Apex 中加密和解密数据X
API 访问控制管理对 Salesforce API 和连接的应用程序的访问权限X XX
API 异常事件跟踪用户如何进行 API 调用的异常X
浏览器安全设置保护敏感数据并监控 SSL 证书X
基于证书的身份验证使用唯一数字证书验证个人XX
证书和密钥验证来自 Salesforce 的外部网站请求XX
代码扫描仪扫描 Apex 代码以了解安全漏洞XX
连接的应用程序通过 API 和标准协议集成XX
凭据填充事件跟踪使用被盗用户凭据的尝试登录X
CSP 受信站点防止代码注入攻击(即跨站点脚本)X
自定义登录流控制用户的登录业务流程X
客户身份控制网站和应用程序登录和验证X
Data Mask自动屏蔽 Sandbox 中的敏感数据X
调试日志跟踪贵组织发生的事件X
委派管理将有限的管理员权限分配给非管理员用户XX
设备激活验证从不可信浏览器、设备或 IP 范围登录X
增强事务安全性拦截事件,监视和控制用户活动X
字段访问权限控制字段级的数据访问权限X
字段审计跟踪定义策略以保留归档的字段历史数据X
字段历史跟踪跟踪和显示字段历史X
Frontdoor.jsp允许使用现有会话 ID 和服务器 URL 进行访问X
Heroku ConnectHeroku 和 Salesforce 之间的双向同步X
Heroku Shield构建 HIPAA 或 PCI 兼容应用程序X
高保证会话安全性敏感操作需要额外安全性X
Identity Connect将用户记录映射到 Active Directory 帐户X
身份验证历史审计用户身份验证尝试X
集成用户许可证仅通过 API 授予对数据和功能的访问权限。XX
Lightning Login防止弱或忘记密码和锁定帐户X
登录访问权限允许支持用户以其他用户身份登录X
登录取证识别可能表明身份欺诈的行为X
登录历史监视组织和 Experience Cloud 站点登录尝试X
移动设备跟踪跟踪和监控移动设备对贵组织的访问权限X
移动 SDK在独立移动应用程序中连接到 Salesforce 平台XXX
监控用户权限 (Shield)权限集和权限集组更改XX
多重身份验证登录需要两种或更多验证方法XX
相互身份验证强制执行 SSL 或 TLS 相互身份验证
My Domain配置登录页面和策略、SSO 和社交登录X
命名凭据指定端点 URL 和身份验证参数X
OAuth 授权通过令牌交换授权客户端应用程序访问权限 X
密码策略设置密码历史、长度和复杂性X
权限集分配到期设置权限集和权限集组分配的到期时间XX
权限集事件监视对权限集和权限集小组所做的更改XX
权限集小组支持复杂访问权限要求的捆绑权限集X
权限集控制用户访问元数据、功能和应用程序的方式X
专用连接Salesforce 和 Amazon Web Services 之间的安全集成X
简档控制登录 IP 范围和登录时间X
实时 Event Monitoring在 Salesforce 中监视和检测标准事件 X
远程站点设置为 Apex 或 JavaScript 调用注册外部站点X
报告异常事件跟踪用户运行或导出报表方式的异常X
限制规则防止用户访问不必要的记录X
Salesforce 代码分析器通过 IDE、CLI 或 CI/CD 扫描代码,以确保符合最佳实践XX
范围规则控制用户可以看到的默认记录X
安全中心查看所有组织的安全设置,并配置状态变化的警报XX
安全健康检查识别安全设置中的漏洞X
会话劫持事件通过被盗会话标识符识别未经授权的访问X
会话管理类自定义活动会话的安全设置X
会话安全设置配置会话以防范恶意攻击X
设置审计跟踪跟踪管理员最近的设置更改X
共享设置在记录级别控制数据访问权限X
Shield Platform Encryption加密静态和传输中的敏感数据X
单点登录通过单点登录提供对多个应用程序的访问权限XX
跨域身份管理系统 (SCIM)通过 REST API 跨系统管理身份X
威胁检测使用统计信息和机器学习来检测威胁X
受信 IP 范围定义不需要额外验证的 IP 地址X
用户访问报表获取用户对象、记录和权限访问权限的统一视图XX
## 与安全相关的资源
资源描述组织安全性会话安全性数据安全
共享架构指南了解有关访问工具、共享模型和用例的更多信息X
设计标准模板为您的组织创建设计标准XXX
如何构建用户安全模型更好地了解用户安全模型XX
如何在 Salesforce 中实施最小权限原则了解在 Salesforce 中应用 PoLP 数据访问控制XX
监控用户会话查看有效会话并结束可疑会话X
多重身份验证从 Salesforce 访问官方 MFA 资源X
权限集小组 (Trailhead)开始使用权限集小组XX
REST API 架构了解 REST API 术语和概念XXX
安全性和 SOAP API了解 SOAP API 术语和概念XXX
API 和内部系统用户的安全最佳实践API 用户和安全内部系统用户对 Salesforce 的安全访问X
安全实施指南全面了解 Salesforce 安全性XXX
安全策略模板为您的组织设置安全策略XXX
会话类型确定用于访问贵组织的会话类型X
威胁建模基础知识 (Trailhead)了解安全威胁以及如何预防它们。X
## 告诉我们您的想法 帮助我们保持 Salesforce 良好的架构与您相关;参加我们的[调查](https://sfdc.co/bxNtvh),以提供有关此内容的反馈,并告诉我们您接下来想要看到的内容。 > 在[这里](/docs/architect/zh-cn/well-architected/guide/contributors)阅读我们的更新计划。 ## 导言 弹性解决方案即使在出现故障时也能保持高质量的服务。如果性能下降或服务中断,解决方案会快速有效地恢复。 解决方案的弹性基于两个关键品质: - **韧性**:当出现问题时,解决方案会经受住这些问题。 - **弹性**:解决问题后,解决方案会恢复到理想状态或形状。 要为弹性构建解决方案,您必须同时设计韧性和弹性,确保在面对计划内和计划外的变化时保持耐用性和快速恢复。 在技术上下文中,将系统或解决方案视为相互依赖的组件集合,这些组件相互协调,以实现共同目标。每个组件都有失败的可能性。这些组件中的问题,从代码和配置缺陷到网络和硬件问题,都会导致意外的、不需要的行为。当一个或多个组件出现故障时,系统会显示弹性行为,但整个系统会继续运行或快速恢复到稳定状态。 为了提高 Salesforce 解决方案的弹性,我们建议关注三个关键习惯。 - [**应用程序生命周期**](/docs/architect/zh-cn/well-architected/guide/resilient#应用程序生命周期管理)管理 (ALM) - 团队如何在软件的整个生命周期中对其进行管理(从构想到停用) - [**事件响应**](/docs/architect/zh-cn/well-architected/guide/resilient#事件响应) — 团队如何识别、解决和防止影响系统可用性或安全性的问题 - [**连续性规划**](/docs/architect/zh-cn/well-architected/guide/resilient#连续性计划) — 团队如何规划人员和系统,以在计划外事件导致问题时继续运行 ## 应用程序生命周期管理 应用程序生命周期管理 (ALM) 是一种在软件的整个生命周期(从创建到停用)中对其进行整体管理的实践。ALM 是系统弹性的基石,并包含与应用程序生命周期相关的人员、流程、工具和学科。这些学科包括 DevOps 和交付方法、可观察性、测试策略、治理和 CI/CD。 当业务实践有效的 ALM 时,其团队会快速响应变化,其应用程序也会跟上不断变化的业务需求,而不会损害稳定性或质量。 另一方面,如果没有健康的 ALM,团队在应用程序生命周期的每个阶段都会举步维艰。 不良 ALM 的症状包括: - 开发周期缓慢且容易出错 - 密集和困难的部署 - 在生产和后 QA 环境中发现的高严重性问题或错误 - AI 客服人员出现幻觉或行为不一致 - 稳定版本所需的频繁回滚或热修复部署 因为 ALM 涉及解决方案的几乎所有方面,所以为您的解决方案建立清晰有效的 ALM 实践是您的架构工作的关键部分。 通过关注三个关键领域,构建更好的 ALM 实践。 - [**版本管理**](/docs/architect/zh-cn/well-architected/guide/resilient#发布管理) — 变更的规划、排序、控制和迁移到不同环境 - [**环境策略**](/docs/architect/zh-cn/well-architected/guide/resilient#环境策略) — 在开发和测试期间如何在目标环境中使用和管理应用程序的策略 - [**信令策略**](/docs/architect/zh-cn/well-architected/guide/resilient#信令策略) — 定义关键信号和应用仪器,用于在降级前检测和补救系统中的故障 - [**测试策略**](/docs/architect/zh-cn/well-architected/guide/resilient#测试策略) — 指导您如何计划和运行测试的原则和标准,以衡量 ALM 流程期间应用程序的成功 ### 发布管理 发布管理涉及计划、排序、控制和将更改迁移到一个或多个环境。单个版本是团队同时移动到目标环境的一组计划更改。 发布对系统的更改会引入风险。如果系统在更改前处于稳定状态,则会转换到新状态,其中也更容易受到未来更改的风险。如果未来的任何更改触发了系统中不受控制的不稳定状态,它们可能会导致严重事件。在解决方案架构中,设计弹性版本不仅仅是[有效测试单个更改](/docs/architect/zh-cn/well-architected/guide/resilient#测试策略)。它还涉及计划如何安全地向您的系统及其用户引入更改。 团队的工作取决于可预测和准确的发布信息。在变更管理和启用过程中,请清楚哪些变更可以进入您的系统。在发布管理和启用流程中,指定更改发布到系统的方式和频率。 您的业务利益相关者也关心发布信息,特别是如果这些信息与他们要求的功能或缺陷修复相关。为了建立对解决方案的 Trust 并向利益相关者展示价值,请制定一致和明确的发布时间表,并运送稳定的发布工件。 要为 Salesforce 建立有效的发布管理: - **与架构和开发治理紧密结合**确保提前计划发布,以便与所有相关治理论坛和控制保持一致。在开始开发之前,请让 AI 理事会审核和批准所有优先 Agentforce 用例。让高风险 Agentforce 用例由法律和道德使用团队审查。使用部署核对清单和文档,根据治理活动跟踪部署工件,例如 Agentforce 客服人员 API 名称。 - **请勿使用[组织开发或发布流程](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)**。这一范式反映了较旧的、较有限的开发和发布技术。借助 Salesforce CLI,团队现在可以采用源驱动的开发和发布功能。 - **选择最稳定的释放机制。**这种方法实现了两件事情。首先,它最大限度地减少了发布窗口和服务中断的持续时间。其次,它允许高度控制和可预测的发布行为。您的发布机制越稳定,发布引入需要热修复或回滚的更改的可能性就越低。如果出现意外问题,稳定的发布机制也会为支持人员或系统管理员执行回滚创建更简单的方法。 团队的最佳发布机制是团队拥有所需技能的最稳定选项。这些是推荐的发布机制,按稳定性顺序排列。所有这些组件都相互兼容,因此如果这对贵公司最有利,请将它们中的多个组件串联使用。 - [**解锁软件包**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm) \- 解锁软件包是最稳定的发布工件。通过安装软件包部署更改是引入更改的最快和最可预测的方式。软件包使用版本控制,这允许强大的变更管理和细粒度的、系统管理员友好的回滚。软件包需要强大的元数据管理,这可以帮助您尽早发现管理不善的依赖关系。他们还创建可审计的开发漏斗和工件。请参阅可[打包性](/docs/architect/zh-cn/well-architected/guide/composable#可打包性)。 - [**DevOps Center**](https://help.salesforce.com/s/articleView?id=sf.devops_center_overview.htm&type=5) — DevOps Center 允许具有低代码或专业代码技能的交付团队使用源控制、协作处理更改并定义通用发布路径。DevOps Center 与源控制集成,并允许对更改和部署进行点击式控制。 - **使用 [Salesforce CLI](https://developer.salesforce.com/tools/sfdxcli) 进行源驱动开发和元数据部署** — 如果您无法使用软件包,请将 Salesforce CLI 用于源驱动开发和元数据部署。不要使用旧的 package.xml 格式部署元数据,它遵循与推荐的[源格式](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm)不同的结构。源格式已发展为支持软件包开发、临时组织工作流和 Sandbox 中的更精细变更跟踪。该格式更具可读性,允许更多解耦复杂的元数据类型和依赖性,并为您提供对部署清单的更多控制。 - **命名发布版本**。为您的版本提供明确的标识符,以帮助您的团队和利益相关者保持一致。在 Salesforce 中,每个主发布版本的名称都以“春季”、“夏季”或“冬季”开头,然后是发布年份(例如,“Summer ’25”)。如果您的公司还没有定义和组织版本的命名约定,请建立一个并使用它。使用清晰的发布名称,可让您更容易在团队系统的规划、开发和交付的每个阶段保持井然有序。在[路线图中](/docs/architect/zh-cn/well-architected/guide/intentional#路线图)使用您的版本名称,向利益相关者清楚地传达哪些变化即将到来以及何时到来。在文档、更改日志、工作描述、代码注释和源代码控制分支中使用您的版本名称,以便您可以轻松地跟踪和审计您的开发工件。 - **在版本清单中,管理依赖性。**Salesforce 元数据具有内置依赖性。Salesforce 部署失败的一个常见原因是依赖性管理不当。如前所述,选择稳定的发布机制有助于在开发周期的早期暴露管理不当的依赖关系。解锁软件包是最稳定的发布工具的主要原因之一是其强大的元数据管理,这是软件包开发和创建所必需的。如果您或您的发布管理团队不理解 Salesforce 元数据类型之间的内在依赖性,您将无法在部署和发布清单中主动发现有问题的组合。请参阅[依赖性管理](/docs/architect/zh-cn/well-architected/guide/composable#依赖性管理)。 ALM 的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/resilient#alm-模式和反模式)显示了 Salesforce 组织正确和糟糕的发布管理。使用模式在构建之前验证您的设计,或者确定系统中需要重构的位置。 要了解有关适用于发布管理的 Salesforce 工具的更多信息,请参阅[适用于弹性](/docs/architect/zh-cn/well-architected/guide/resilient#适用于弹性的-salesforce-工具)的 Salesforce 工具。 ### 环境策略 Salesforce 提供了多种[环境](https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm&type=5)供您在应用程序开发和测试周期中使用。Salesforce 的有效环境策略需要了解如何使用环境,以及良好的管理是什么样子。在 ALM 中,开发或测试环境的用途取决于它对生产的忠诚度和与生产的隔离。 良好的环境策略提供了几个好处。 - 对生产的更高忠诚度 - 更快的环境设置和拆除 - 开发和测试更加敏捷 - 提高整个漏斗的安全性 - 在整个交付阶段减少噪音和冲突 - 更快乐的开发团队 团队通常很难实现这些好处。充分利用开发环境和战略的挑战可能来自几个方面。一个可能的来源是团队遵循的开发模式类型。 在旧的、基于组织的开发方法中,每个环境都需要为几个功能提供服务。除了是团队进行各种工作的地方之外,它还需要是发布工件的来源(即您想要在版本中部署的元数据)。因为环境不容易设置或拆除,所以它们通常过度拥挤,并且充满了团队之间的元数据冲突,它们没有为 ALM 整体贡献有意义的速度或灵活性。 使用基于源的开发模型从根本上改变了环境与您的发布和发布工件的关系。在此模型中,源控制是您想要发布的元数据的来源。环境只是团队开展工作的地方。 然而,遵循基于源代码的发展模式并不能保证良好的环境策略。即使使用源控制,团队仍然很难设置条件来测试与外部系统的集成;依赖于源控制之外的元数据的配置,例如依赖于[数据的受管](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#元数据与数据)软件包或自定义等。在某些情况下,基于源模型的挑战类似于基于组织模型的典型挑战。 要制定有效的环境策略: - **采用源驱动的开发和发布模型**停止使用基于[组织的开发](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)模型。请参阅[版本管理](/docs/architect/zh-cn/well-architected/guide/resilient#发布管理)。)您必须将环境与部署的环境分开,以创建健康的环境策略和更健康的版本。 - **了解每个环境支持的工作类型。**Salesforce 支持的环境类型具有不同的功能和限制。在设计环境策略时,请考虑环境可以做什么和不可以做什么。确保您的团队在具有所需功能的环境中工作。有关指导,请参考 Salesforce 开发环境及其功能的概述。
临时组织 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
*如果需要完成特定类型的工作,否则使用资源密集度较低的环境
此外,请注意,对于使用 Einstein 数据库、Knowledge 文章和非结构化数据等功能的 Agentforce 客服人员,全面测试将受到限制,除非您拥有 Data 360 Sandbox。您还需要 Data 360 Sandbox,以确保测试条件准确。 - **将环境与发布工件分离。**请勿使用[基于组织](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)的开发。将环境视为工作在固定时间内发生的地方。将环境中的元数据状态视为与您的发布工件分开。如果一段代码或配置在环境中被“弄清楚”,它应该被提交到源代码控制中,使其成为一个发布工件。 - 环境是短暂的。构建进程,以便您可以尽快创建和销毁它们。 - 人工制品经久不衰。它们属于源控制。 - **将环境与发布路径分离。**常见的是,需要将更改部署到特定环境的强制发布路径。通常,实施这种方法是为了建立代理来验证应用程序的成熟度或发布稳定性。团队也可以用它来尝试最大限度地减少他们必须配置复杂测试基础设施的环境数量。在基于源的范式中,您可以在如何和在哪里验证和测试更改方面拥有更大的灵活性。 - 发布阶段适用于发布工件,不适用于环境。不要仅为“收集”特定发布阶段的所有更改而创建环境。这就是源控制的目的,特别是分支。在源控制中使用分支策略,以组织将哪些更改部署到哪些环境。根据您需要完成的工作,您可能需要将版本中的所有元数据部署到环境中。分支使您能够做到这一点。除了一些例外情况,每个开发环境必须在相关工作完成后立即刷新或销毁。请确保将对在特定环境中发生的元数据的任何更改(以及要保留的元数据)同步到源控制。 - 环境只有在忠于生产的情况下才有用。优化环境设置工作流或自动化,以便您可以尽快拆除或刷新环境。请将任何阻止您执行更快、更频繁环境刷新的配置视为对 ALM 流程整体弹性的重大风险。如果您有相关的补救工作,请将其添加到计划中,并确定优先级。探索如何在系统中采用更多松耦合的[模块化单元](/docs/architect/zh-cn/well-architected/guide/composable)。它们使团队能够在临时组织中执行更多类型的开发,并为其他工作释放 Sandbox 分配。请勿忘记临时组织提供的功能,用于测试您在生产中没有的功能,因为您没有为其购买许可证或启用它们。 - 在业务用户或最终用户可以访问的环境中,让这些用户关注对他们重要的事情。不要有通用的、没有区别的环境,在这种环境中,许多不同的最终用户或业务利益相关者试图从事与 ALM 相关的工作。邀请并激活特定利益相关者进入特定环境,以完成特定工作。仔细评估将最终用户或业务利益相关者置于数据超过部分复制 Sandbox 支持的环境中的任何流程。确保数据量对于要完成的工作是必要的。规划用户验收测试和早期开发周期,以便尽可能紧密地结合在一起。优化所有测试阶段,为您的开发团队和最终用户提供更快、更早的反馈和迭代周期。请参阅[测试策略](/docs/architect/zh-cn/well-architected/guide/resilient#测试策略)。 - **为不同类型的更改构建不同的发布路径**并非所有更改都需要以相同的顺序完成相同类型的 ALM 工作。让最终用户对系统的后端组件进行细微的更改进行验收测试可能不会很好地利用他们的时间。但在移动应用程序的早期开发阶段,用户接受和规模测试可能非常有价值。确定不同变更类别的发布路径,例如高风险、中度和低风险。 - **高风险:**更改会影响客户、合作伙伴或所有内部用户。更改会影响安全性或集成。更改增加了复杂的新功能。 - **中度风险:**更改的影响超过定义的内部用户阈值。更改会影响数据模型、执行数据操作的自动化或集成。 - **低风险:**直接影响少于定义的内部用户阈值。不包括对安全性、数据模型或涉及数据操作的自动化或集成的更改。 - **不要允许存在过度拥挤的环境。**在确定工作的优先级、范围和排序方面缺乏纪律不可避免地导致开发环境过载,工作量太多、太多、太不同。过度拥挤的环境在开发团队之间造成了高度的压力、模糊性和冲突。它们还会在开发漏斗中制造噪音,并阻碍质量控制工作。除了这些负面影响之外,过度拥挤的开发环境也是对环境维护和安全的严重威胁。将过度拥挤视为 ALM 流程中潜在问题的症状。调查任何根本原因问题并加以解决。如果您仍然面临过度拥挤,您可以[购买额外 Sandbox](https://help.salesforce.com/s/articleView?id=sf.data_sandbox_environments.htm&type=5)。 ALM 的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/resilient#alm-模式和反模式)列表显示了 Salesforce 组织中正确和糟糕的环境管理。在构建之前,使用它们来验证您的设计,或者确定系统中需要重构的区域。 要了解有关适用于环境管理的 Salesforce 工具的更多信息,请参阅[适用于弹性](/docs/architect/zh-cn/well-architected/guide/resilient#适用于弹性的-salesforce-工具)的 Salesforce 工具。 ### 信令策略 信令策略定义了在故障级联到全系统降级之前检测、诊断和补救故障所需的关键信号和应用仪器。有效的仪器将应用程序从失败的被动受害者转变为自身复原力的积极参与者,能够发现问题,调整行为,并在必要时协调优雅的降级。 当应用程序实施全面的仪器时,他们获得在压力下自我调节的能力,向操作员传达他们的健康状况,并参与协调的恢复工作。这些功能允许系统即使在单个组件遇到问题时也能保持服务质量。另一方面,如果没有适当的仪器,应用程序就会变成黑匣子,在出现灾难性症状之前,它会无声地失败。团队仅在用户报告后对问题做出反应,故障排除成为考古工作,而不是观察。 - **检测应用程序中的失败**。应用程序必须自行检测并响应在重负载下出现的常见故障模式。考虑队列饱和度。当消息队列的填充速度超过处理速度时,未经检测的应用程序会继续接受工作,直到出现内存耗尽或超时级联。正确检测的应用程序会监控队列深度、拒绝率和处理延迟,并在超过阈值时触发防御性响应。 - **有效处理来自应用程序外部的信号**:操作系统信号的处理代表了另一个关键的检测点。应用程序必须注册终止信号 (SIGTERM、SIGINT) 的处理器,才能正常关闭。在关闭期间,正确检测的应用程序会停止接受新工作,允许实时请求完成、清除缓冲、干净关闭连接,并从服务发现中注销。这种精心策划的关闭可以防止数据丢失,并允许负载平衡器在不中断的情况下重定向流量。 - **复杂故障场景的说明:**除了这些基本模式之外,应用程序还必须针对更微妙的故障模式进行设备检测。识别灰色故障,即一些观察者认为组件正常,而其他观察者认为组件故障,这需要将内部和外部信号进行关联。应用程序可能会检测其数据库连接池,以报告成功的运行状况检查,同时跟踪显示蠕变降级的事务完成率。有效的仪器策略将多个观察点分层。 - **业务度量**跟踪特定于应用程序的成功指标,例如订单完成率或搜索结果质量。 - **系统度量**监控资源利用率、延迟分布和错误率。 - **合成探针**会持续使用关键路径,以在用户遇到之前检测降级。 - **分布式跟踪**提供了跨服务边界的请求级可见性。 这些信号通过标准化界面公开,允许自动化系统和人工操作员评估应用程序运行状况。仪器本身成为应用程序弹性策略的一部分,使断路器能够根据错误率跳闸,自动缩放器能够响应队列深度,[操作员在事故](/docs/architect/zh-cn/well-architected/guide/resilient#事件响应)期间做出明智的决定。 ALM 的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/resilient#alm-模式和反模式)显示了在 Salesforce 组织中正确和糟糕的信号策略是什么样子。在构建之前,使用它们来验证您的设计,或者确定系统中需要重构的区域。 要了解有关适用于信令策略的 Salesforce 工具的更多信息,请参见[适用于弹性](/docs/architect/zh-cn/well-architected/guide/resilient#适用于弹性的-salesforce-工具)的 Salesforce 工具。 ### 测试策略 测试策略是一套指导原则和标准,用于如何计划和运行测试,以衡量 ALM 流程期间应用程序的成功和失败。测试策略让参与测试的每个利益相关者了解并符合给定测试的优先级、目的和范围。它还帮助项目团队创建有效和周到的测试计划。 通常,开发人员或质量保证和测试专家会参与创建和执行特定测试。测试策略有助于确保这些个人知道给定项目需要执行哪种测试,以及执行的顺序。测试策略还有助于确保团队拥有构建格式良好的测试、测试计划和工件所需的内容(例如,测试数据集、设备和流量或网络模拟器)。 有效的测试策略清楚地描述了如何、何时、何地和为何以各种组合和条件运行不同的测试类型(包括单元测试、UI 测试和回归测试),以揭示您的系统和任何正在进行的更改的行为方式。有效的测试策略会生成测试,向您展示系统对非功能要求的合规性(例如可扩展性、可靠性和可用性),而这些要求很难通过单一类型的测试来衡量。 要为 Salesforce 创建有效的测试策略: - **迭代、频繁和尽可能通过自动化手段进行测试。**设计和实施测试自动化,使团队能够针对各种工作负载运行各种测试类型。编排各种测试运行,以便在更改进入源控制时自动进行。这种方法使团队能够提前主动识别和解决回归问题。如果可能,为此使用持续集成/持续交付 (CI/CD)。如果没有,请制定明确的测试计划,使团队能够尽早并经常以自助方式运行测试序列。对于 Agentforce 客服人员测试,依靠测试中心对具有各种输入的 AI 客服人员进行严格的批量测试,以确保他们在不同场景中正常运行。 - **认识到不是每个更改都需要每种测试。**正如有效的发布漏斗适合高、中和低风险应用程序的路径一样,有效的测试策略也是如此。清楚地为团队概述如何为具有各种风险、用例或复杂性的应用程序选择和遵循适当的测试制度。请参阅[环境策略](/docs/architect/zh-cn/well-architected/guide/resilient#环境策略)。 - **定义可以在不同的环境类型中执行哪些测试。**对生产的忠诚度是准确测试的关键组成部分,但对于不同类型的测试来说,这意味着不同的东西。例如,回归测试需要在元数据方面忠实于生产,并在一定程度上忠实于数据。确保定义一组给定的测试需要什么样的生产忠诚度,并清楚地分类什么类型的环境可以支持适合不同测试的条件。有关与每种环境类型一致的工作类型的概述,请参阅[环境策略](/docs/architect/zh-cn/well-architected/guide/resilient#环境策略)。 - **使用耐久性、压力、性能和规模测试来持续衡量应用程序的成熟度。**这些测试显示了与生产级需求相比,应用程序的发布准备程度。对于主要新功能,请在应用程序开发周期中间隔几次运行这些测试。将这些测试仅仅视为一个开发阶段或阶段的一部分,而不是正在进行的任务的一部分是一种反模式。对于团队来说,尽早并经常获得关于应用程序性能的反馈非常有用,这有助于他们更好地了解如果应用程序离生产级就绪的程度。在更改投入生产之前更好地识别和解决问题的能力非常值得频繁运行更复杂的测试来增加复杂性。 - **了解哪些测试重要**。您可能会有固定的时间进行规模或性能测试,因此测试系统的各个方面不切实际。并非所有功能都得到同等使用,并非所有规模瓶颈都会对业务产生同等影响。确保您的规模测试集中在系统中使用率最高和价值最高的部分。定义并了解最重要的业务机会,以验证和改善贵组织的规模和性能。 - **了解“足够好”是什么样子。**定义规模和性能测试的成功标准至关重要。确保您和您的开发团队将成功标准用作测试基准。此外,确保它们为开发团队构建的功能要求提供信息。通常,这些标准包括支持响应时间小于商定值的特定数量的并发用户,以及您的[服务级别目标 (SLO)](/docs/architect/zh-cn/well-architected/guide/resilient#恢复时间)。定义关键目标条件,然后设计规模和性能测试,以确保满足条件。 - **确保您有足够的环境。**规模和性能测试需要特别忠实于生产。非生产环境中的数据集、请求人口统计、请求率和工作量特征应尽可能匹配您在生产环境中看到的内容。对于规模测试,您必须使用完全 Sandbox。如果贵组织没有用于规模测试的完全 Sandbox,您无法运行足够的规模测试。 - **确保测试工作负载帮助您衡量非功能需求。**请记住考虑: - **测试数据** \- 每种测试都应针对与生产隔离的数据执行。在 Apex 单元测试中,实施[数据工厂模式](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_utility_classes.htm),以确保代码生成自己的测试数据,与环境数据隔离。您还可以以各种格式创建和维护测试数据集,以测试数据加载行为,使用基于 UI 的测试数据填充开发环境,并协助集成测试。所有测试数据,无论是作为外部数据集维护,还是通过数据工厂代码按需创建,都应该清除敏感和识别数据。它应包括损坏、不完整和格式错误的数据,以支持消极和边界单元测试行为。 - **模拟和存根服务** \- 对于集成测试,您可以使用模拟和存根服务来模拟 API 响应。Apex 支持一个[存根 API](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_stub_api.htm) 来创建在 Apex 测试中使用的模拟框架。嘲笑创建可用于 Apex 测试的嘲笑框架。模型和存根可以帮助验证系统的数据处理行为,更少地依赖复杂的数据工厂或外部测试数据集。有时,模拟和存根更适合用于生产类流量或数据量不相关的测试。 - **设备和辅助**技术 - 构建[引人入胜](/docs/architect/zh-cn/well-architected/guide/engaging)和[可访问](/docs/architect/zh-cn/well-architected/guide/compliant#可访问性)的应用程序的关键部分是确保它们在各种设备和不同类型的辅助技术中满足用户的期望。有意义的可用性测试可能需要更多投资和不同类型的专业知识来有效执行,但它是了解面向用户的应用程序在发布时架构如何的重要部分。 - **模拟器** \- 当您需要复制类似生产数量的用户请求、API 流量或网络速度的变化时,您可能需要模拟这些情况的工具。不是每个测试都需要这种投资水平。这些工具通常在可扩展性和性能测试中非常有用。 - **AI 和客服人员测试** \- 测试的主要目标是减少 AI 幻觉,这是令人信服的回答是捏造的和不正确的。确保测试 AI 用例,以突出显示由对客户理解不完整、缺少数据、元数据不完整的字段和过时数据导致的常见问题。使用测试中心帮助创建此类测试所需的测试数据。 ### ALM 模式和反模式 下表显示了在您的组织中要查找或构建的模式的选择,以及要避免或针对补救的反模式。 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/adaptable-application-lifecycle-management)器中,发现 ALM 的更多模式。
模式 反模式
版本管理 在生产中:
- 元数据显示了稳定发布机制的使用情况,例如:
-- 元数据被组织成解锁的软件包
-- 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 中:
- 单元测试依赖于组织数据。
- 不用嘲笑小作品
在设计标准和文档中:
- 环境按支持的测试类型分类。
- 根据风险、用例或复杂性指定适当的测试制度。
在设计标准和文档中:
- 不清楚每个环境支持哪些类型的测试。
- 测试方案未按风险、用例或复杂性分类。
## 事件响应 在安全和站点可靠性工程 (SRE) 中,事件响应侧重于团队如何识别和处理影响系统整体可用性或安全性的事件,以及团队如何努力解决根本原因并防止未来出现问题。事件响应涉及实时解决问题和问题发生后所需的流程、工具和组织行为。 作为架构师,您可能不是每天监控解决方案上线后运营的人员。弹性架构的一部分是设计恢复功能,使支持团队能够执行第一级诊断,稳定系统,并将调查和根本原因缓解有效地移交给开发或维护团队。日常直接支持用户的团队可能对系统的架构没有深刻的理解或专业知识。这些团队必须具备所需的工具和流程来监控日常运营,在诊断潜在事件时从系统中获取信息,并在任何影响可用性的问题上充当有效的第一响应者。 通过关注[恢复时间](/docs/architect/zh-cn/well-architected/guide/resilient#恢复时间)、[分类能力](/docs/architect/zh-cn/well-architected/guide/resilient#分类能力)以及[监控和提醒](/docs/architect/zh-cn/well-architected/guide/resilient#监控和警报),您可以提高团队对 Salesforce 解决方案中事件的响应程度。 ### 恢复时间 当事件发生时,第一优先级必须是将系统恢复到稳定的运行状态。通常,企业认为从事件中恢复的唯一途径是“解决问题”。这一假设是公平的,因为准确的根本原因分析和补救是您最终解决系统中关键问题的方式。但是,在危机响应的早期阶段“解决问题”并不是最实际的方法。根据事件的严重程度,每一秒及其影响都可能导致业务的收入或声誉损失。 通常,尝试诊断并解决根本原因会延迟将系统恢复到运行状态的工作。从逻辑上讲,采用要求事件响应者解决根本原因的方法会给贵公司的主题专家 ( SME) 和支持人员带来巨大压力。在事件*期间*努力寻找并修复根本原因需要中小企业随时待命,这可能会阻止面向客户的一线支持人员采取行动。这也会导致团队发布变更,进而产生更多事件。归根结底,这种方法会增加成本,消耗团队之间的带宽,并导致在危机时出现可能削弱客户 Trust 和品牌声誉的行为。 正确的事件管理模式是确定优先级,并将恢复作为第一步。在系统恢复稳定后,您可以进行无可指责的事后分析、事件调查、根本原因修复和类似活动。这种操作顺序更好地使事件响应人员能够分类、诊断和执行恢复策略,并提醒相关中小企业仅在必要时提供帮助。它还使中小企业能够识别并修复事件的根本原因,而不会感到压力过大。 对事件响应采取恢复优先的思想: - **建立并实现服务级别目标 SLO**。SLO 是您与利益相关者一起为系统的特定非功能要求 (NFR) 制定的标准,例如性能或正常运行时间。这些目标由一段时间内的服务水平指标 (SLI) 来衡量。如果没有 SLO,围绕事件响应和复杂问题故障排除的大部分工作可能会感觉混乱和反应性,例如,促使人们迅速采取行动,“为报告它的一小部分用户停止这一特定的错误”。通常,这种循环会使团队将根本原因分析推向事件响应的更近一步,因为它似乎有助于阻止反应性行为。建立 SLO 和 SLI 是更有效的开始方式。要建立 SLO,请考虑这些问题。 - **未来 1-3 年系统的 NFR 是多少?**例如,您的 NFR 可能包括您的系统必须能够支持的响应时间、峰值请求率和并发用户。 - **您希望客户及其用户体验什么?**将 SLO 基于此问题的答案,即“用户可以在 Salesforce 中快速运行报表”。 - **您可以测量什么,应该在多长时间内测量?**将幻灯片基于此问题的答案。匹配上述示例的 SLI 可能是“在 30 天内测量的平均 _n_ 秒内加载的报表的 _x_%”。 - **定义并标准化恢复策略。**更改回滚和解决方法实施可以帮助系统再次正常运行,并将事件的影响最小化。文档恢复策略和协议,可由支持或运营团队的适当成员执行。恢复策略因事件类型而异。下一个表显示了将事件类型映射到恢复策略的一般框架。有关识别故障点和定义缓解策略的更多信息,请参阅[可用性](/docs/architect/zh-cn/well-architected/guide/reliable#可用性)。
事件类型 外观触发器 恢复策略
系统中断 登录错误或帐户访问权限问题 客户恢复策略
服务不可用 激活冗余备份服务;手动解决方法
生产错误 最近更改 部署回滚或取消部署以前的版本
一个无法解释的紧急错误 手动解决方法,禁用非必要功能,升级到 SME
- **定义明确退出标准**。使用您的 SLO 来确定您的系统何时没有事件或影响状态。 - **定义事件后审查和根本原因补救的流程。**在服务恢复后,花时间查看事件。在审查期间,采取*无怨无悔*的方法。与利益相关者合作,专注于确定关于发生*什么*以及发生*方式*的明确事实,而不是试图将错误或指责归咎于个人。使用不同的审查格式来检查长期解决问题的方法。 - *事后审查*侧重于对事件的响应。它有助于评估适当的响应流程和策略是否到位。 - *根本原因分析*侧重于事件的根本原因。它可以帮助识别导致事件的系统设计和实施中的任何错误或问题。 - **定期实践商定的恢复协议**实践恢复协议,以确保每个人都知道如何很好地处理事件。使用 Sandbox 和测试环境,为团队提供实践事件模拟和恢复的地方。还要练习事件后审查。执行所有这些实践会使恢复成为您的工程和支持文化的一部分。 [事件响应模式](/docs/architect/zh-cn/well-architected/guide/resilient#事件响应模式和反模式)和反模式显示了在 Salesforce 解决方案中确定恢复优先级的架构。在构建之前,使用它们来验证您的设计,或者确定系统中需要重构的区域。 要了解有关 Salesforce 工具的更多信息,以帮助恢复时间,请参见[Salesforce 恢复工具](/docs/architect/zh-cn/well-architected/guide/resilient#适用于弹性的-salesforce-工具)。 ### 分类能力 在技术环境中,分类包括将类别和严重级别分配给问题和支持请求。无论您的解决方案计划得有多周全,都会出现用户支持问题和请求。这些问题可能源于缺乏足够的培训或变更管理、UI/UX 中的差距、意外的最终用户行为以及没有被[监控或提醒](/docs/architect/zh-cn/well-architected/guide/resilient#监控和警报)发现的紧急系统问题。 支持和运营团队需要能够高效地调查用户支持查询并快速诊断它们。分类问题以筛选出不太严重的问题并快速发现关键系统事件是这些团队的关键能力。糟糕的分类会降低所有级别的用户支持,延长关键事件,并增加进一步中断客户和业务的风险。 虽然您可能没有参与日常运营和支持,但作为架构师,您有责任帮助确保您的支持和运营团队能够有效地分类您在 Salesforce 平台上创建的任何解决方案中的问题。 要使团队能够有效地分类 Salesforce 解决方案中的问题: - **确保支持团队可以访问有用信息。** - **记录您的系统和设计模式**。确保解决方案的可[读性](/docs/architect/zh-cn/well-architected/guide/intentional#可读性)和一致性是使支持人员了解他们负责支持的系统的关键部分。在文档中,请考虑团队如何找到有关如何确定系统不同部分问题或事件的优先级的信息。此外,确保团队可以根据影响区域快速获取有关恢复策略的技术信息。为常见 Agentforce 问题提供相关故障排除指南,例如主题分类和操作选择,这将帮助团队快速分类与权限或配置相关的问题。 - **设计时请谨记调试**。支持团队和组织管理员需要启用调试和诊断,以正确分类各种环境中的用户问题。*调试友好*模式的示例包括将日志记录和自定义错误消息纳入整个系统的执行路径的模式。通过事件日志和客服人员生成器的推理视图等工具,在常见 Agentforce 调试方法上启用支持团队。 - **确定事件中小企业和利益相关者**。创建相关中小企业或利益相关者的列表,他们应支持从事件中恢复,并应参与事件后分析。 - **好好对待交接**。作为上线的一部分,确保每个解决方案移交给支持或运营团队的质量。为支持人员提供培训,以完成相关系统架构和模拟事件响应演练。考虑事件后的切换,包括团队应如何记录日志或个案备注未捕获的信息,以及事件响应者如何为根本原因调查做出贡献或执行用户验收测试以采取任何补救措施。 - **如果征求您的意见,请将每个人的注意力放在恢复上作为最关注的问题。** - **快速响应。**快速响应您收到的任何用户支持请求、监控通知和提醒。 - **帮助区分症状和问题。**确定是否存在需要解决的实际系统事件。尝试识别存在实际问题的组件。帮助确保遵循商定的[恢复策略](/docs/architect/zh-cn/well-architected/guide/resilient#恢复时间),以使系统快速脱离事件状态。 - 对于支持关键用例的 Agentforce 客服人员,请确保可行的相关解决方法到位,并且作为冗余措施,可以在接到通知后立即启用。示例包括切换到手动处理或重定向到相关文档进行手动审查。 [事件响应模式](/docs/architect/zh-cn/well-architected/guide/resilient#事件响应模式和反模式)和反模式显示了有效分类的架构在 Salesforce 解决方案中的外观。在构建之前,使用它们来验证您的设计,或者确定系统中需要重构的区域。 要了解有关 Salesforce 工具的更多信息以帮助分类,请参见[适用于弹性](/docs/architect/zh-cn/well-architected/guide/resilient#适用于弹性的-salesforce-工具)的 Salesforce 工具。 ### 监控和警报 *监控*和*警报*是站点可靠性工程中广泛使用的术语。在系统弹性的上下文中,监控是持续评估系统的当前状态,而警报是自动通知利益相关者有关系统状态的潜在问题。有效的监控和警报是使系统的规模和增长与支持人员的规模和增长脱钩的关键部分。 Salesforce 提供各种内置功能来监视您的系统中的行为。Salesforce 还提供作为加载项或 [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) 一部分的[实时事件监测](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/real_time_event_monitoring_overview.htm)。在任何 Salesforce 解决方案中,专为监控和警报设计的设计都提供: - 自动化事件响应的功能 - 在正确的时间将相关信息发送给正确的用户 - 清除历史视图和趋势分析的信息 要在 Salesforce 解决方案中构建有效监控和警报的架构: - **优先考虑自动化**。虽然通知用户关键状态更改是保持系统稳定运行的关键部分,但在理想架构中,系统会在可能时自行更正问题,并仅针对不可恢复的紧急问题发送警报。即使没有自我纠正功能,自动化也可以使您的提醒和报告更加有用。 - **从 Salesforce 已经提供的内容开始。**Salesforce 平台会为您提供相关日志和 API,以监控解决方案在调控器限制方面的操作。此外,平台会发送违反调控器限制和类似问题的警报。使用这些日志和警报作为基础,探索更完全自动化系统自我恢复、事件报告和警报的方法。例如,您可以实施监控日志的自动化,然后在记录特定类型的事件时采取恢复操作。 - **以可预测的方式对系统状态的更改进行分类。**为您想要监控和报告的关键州/省创建特定、有意义的类别。将这些类别与您为管理[应用程序组件](/docs/architect/zh-cn/well-architected/guide/composable#状态管理)中的状态而定义的类别对齐。对于如何处理状态更改信息,采用[面向 API](/docs/architect/zh-cn/well-architected/guide/composable#api-管理) 的思维方式。一致的消息格式和状态类别简化了自动化、报告和提醒。 - **将自动化逻辑与系统的其他部分保持一致。**如果您已构建适当的自动化[错误处理](/docs/architect/zh-cn/well-architected/guide/automated#错误处理),您可以将这些模式扩展到如何分类状态更改并使用自动化进行响应。对于视为可恢复的状态更改,您可以自动重试行为。对于被视为关键或致命的状态更改,自动向用户发出警报。 - **避免制造噪音**。当用户收到太多警报时,特别是不需要采取任何操作的警报,他们倾向于开始禁用或忽略所有警报。这种情况破坏了创建[有用](/docs/architect/zh-cn/well-architected/guide/engaging#有用)提醒的任何努力。为了更好地确定谁收到警报、什么触发警报以及何时触发警报,请考虑执行以下操作。 - **构建相关方地图**。要确保您的系统在正确的时间向正确的利益相关者提供正确的提醒,请先确定和分类您的利益相关者群体。 - **基于用户权限路由消息**。仅向有能力和权限响应的收件人发送警报。业务用户可能会从有关问题的提醒中受益,这些问题可以通过更正他们有权访问的记录中的问题来修复。如果问题需要更复杂的技术响应,应向支持人员发出警报。 - **明确预期响应**。仅在需要人为干预的情况下发送警报。构建消息,以清楚地指示期望收件人采取的操作。如果您确实向利益相关者发送了警报以获得可见性,并且不需要他们采取任何行动,请在他们收到的消息版本中清楚地说明这一点。 - **及时发出相关提醒**。针对已发生且仍需要补救的故障而提供的警报)不如关于潜在故障的警报有用。理想情况下,一旦系统中出现问题,支持人员就会收到警报,从而有机会在问题对业务运营产生负面影响之前对其进行[分类](/docs/architect/zh-cn/well-architected/guide/resilient#分类能力)。 [模式和反模式](/docs/architect/zh-cn/well-architected/guide/resilient#事件响应模式和反模式)列表显示了 Salesforce 解决方案中有效监控和提醒的架构。在构建之前,使用它们来验证您的设计,或者确定系统中需要重构的区域。 要了解有关用于监控和提醒的 Salesforce 工具的更多信息,请参见[适用于弹性](/docs/architect/zh-cn/well-architected/guide/resilient#适用于弹性的-salesforce-工具)的 Salesforce 工具。 ### 事件响应模式和反模式 此表显示了要在贵组织中查找或构建的模式选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/adaptable-incident-response)器中,发现事件响应的更多模式。
模式 反模式
恢复时间 在您的业务中:
- 定期练习恢复协议。
- 团队知道他们拥有和负责生产中的哪些服务。
- 团队了解支持问题诊断的相关工具。
在您的业务中:
- 恢复协议不存在或未定期实践。
- 不清楚哪些团队拥有并负责生产中的不同服务。
- 团队没有支持问题诊断的工具指南或标准。
在您的文档中:
- 恢复策略按事件类型和触发器定义和分类。
- 事件响应的退出标准包含在 SLO 中,并且是明确的。
- 事件期间提升权限的激活条件和分配逻辑很清楚。
- 事件响应权限集和授权已明确列出。
- 存在帮助识别和诊断常见问题的故障排除指南。
在您的文档中:
- 事件响应是临时执行的。
- 事件响应的退出条件不存在。
- 未分配提升的权限,或者,如果是,将临时分配。
- 事件响应权限集和授权未列出。
在您的组织中:
- 存在基于会话的事件响应权限集,可以在恢复期间分配给支持人员。
- 设置审计跟踪显示指定的恢复测试人员在商定的时间登录测试环境,并遵循恢复测试脚本。
在您的组织中:
- 事件响应不存在基于会话的权限集,或者如果存在,支持人员无权使用。
- 设置审计跟踪显示指定的恢复测试人员未登录测试环境或未遵循恢复测试脚本
在您的测试计划中:
- 存在用于恢复测试的测试脚本,并且可以重复。
- 事件模拟的环境已明确列出。
在您的测试计划中:
- 恢复测试的测试脚本不存在。
- 未建立事件模拟的环境。
分类能力 在您的业务中:
- 应在事件发生前确定应提醒中小企业或利益相关者支持复杂问题。
- 交付和支持团队之间的切换是上线的一部分。
- 如果咨询,Salesforce 架构师会快速响应,并帮助团队专注于恢复。
在您的业务中:
- 在事件发生之前,不会确定应引起警报的中小企业或利益相关者。
- 交付团队和支持团队之间的切换不是发布过程的一部分。
- Salesforce 架构师认为事件响应超出了他们的工作范围。
在您的文档中:
- 支持人员可以发现和读取给定解决方案中使用的系统和设计模式。
在您的文档中:
- 给定解决方案中使用的系统和设计模式对支持人员不可用。
在您的组织中:
- 记录和自定义错误消息被合并到整个系统的执行路径中。
在您的组织中: - 不使用日志记录和自定义错误消息。
监控和警报 在您的组织中:
- 警报仅用于通知用户需要人为干预的场景;其他故障将被记录并报告。
- 向能够响应警报的用户发送警报。
- 在可能时,在潜在故障前发送警报。
在您的组织中:
- 当任何类型的故障发生时,都会发送警报,无论是否需要后续行动。
- 向业务用户提供需要技术解决方案的问题提醒。
- 仅针对已发生的故障发送警报。
在您的文档中:
- 提示调整警报的准入条件基于直接和间接生成式 AI 反馈度量定义。
在您的文档中:
- 没有定义触发生成式 AI 应用程序的提示调整警报的条件。
## 连续性计划 业务弹性的一个关键是连续性规划,它侧重于如何使人员和系统能够应对计划外事件引起的问题。业务连续性计划 (BCP) 从以人为本的角度看待如何让流程在危机中继续前进。连续性计划的技术方面包含在 BCP 的灾难恢复部分中。请参阅[技术连续性](/docs/architect/zh-cn/well-architected/guide/resilient#技术连续性)。 如果没有适当的连续性计划,您的组织现在可能知道如何在危机或系统停机期间采取行动,因此根本不采取行动。无效的连续性规划会对客户、利益相关者和业务产生灾难性的影响。在发生不利事件后,没有维护或恢复关键流程的每一刻都有可能遭受财务损害、声誉损害、员工安全,甚至监管合规。 您可以通过将精力集中在三个方面来为系统构建更好的连续性规划:[定义 Salesforce 的](/docs/architect/zh-cn/well-architected/guide/resilient#业务连续性)业务连续性、[规划技术连续](/docs/architect/zh-cn/well-architected/guide/resilient#技术连续性)性以及[构建备份和还原功能](/docs/architect/zh-cn/well-architected/guide/resilient#构建备份和还原功能)。 ### 业务连续性 您的公司可能已经有 BCP。如果是,请确保 Salesforce 包含在其中。如果您的公司没有 BCP,请与利益相关者合作,创建一个涵盖您的 Salesforce 组织的 BCP。 Salesforce 通常被依赖为许多业务部门的客户数据和基本业务流程的真实来源。因此,Salesforce 在 BCP 中扮演的角色可能与其他系统扮演的角色不同。Salesforce 很可能会参与许多高优先级的恢复领域。 要为 Salesforce 系统创建相关业务连续性规划: - **澄清恢复的优先级**。与[事件响应](/docs/architect/zh-cn/well-architected/guide/resilient#事件响应)的一般方法一样,恢复需要成为系统在危机时刻的第一优先事项。许多关键业务服务在 Salesforce 中运行并与 Salesforce 一起运行。您必须帮助利益相关者确定恢复各种业务功能和功能的正确优先级。一般框架可以是: - 稳定基本业务基础设施。 - 稳定客户服务。 - 稳定员工和合作伙伴服务。 - **在您的 BCP 中考虑您的生态系统。**Salesforce 不是您环境中的唯一系统。请确保您在 BCP 中找出与 Salesforce 集成的系统、从 AppExchange 供应商安装的解决方案以及与 Salesforce 中的数据或流程连接的任何其他系统之间的差距。如果您的交付能力取决于供应商,请询问这些供应商他们的连续性计划。评估他们的功能,并计划如何保持系统可用。 - **将 BCP 问题集成到测试策略中。**为您的 BCP 创建测试计划并执行它们。测试 BCP 中与流程或人员相关的区域尤其重要,因为这些区域通常会被忽略。将 BCP 中的相关项目纳入整体 ALM [测试策略](/docs/architect/zh-cn/well-architected/guide/resilient#测试策略)。创建并遵循维护计划,以审查测试,并确保计划保持最新。 [模式和反模式](/docs/architect/zh-cn/well-architected/guide/resilient#连续性计划模式和反模式)显示了 Salesforce 解决方案中正确和糟糕的连续性规划。在构建之前,使用它们来验证您的设计,或者确定系统中需要重构的地方。 要了解有关用于定义业务连续性的 Salesforce 工具的更多信息,请参阅[适用于弹性](/docs/architect/zh-cn/well-architected/guide/resilient#适用于弹性的-salesforce-工具)的 Salesforce 工具。 ### 技术连续性 技术连续性的目标是确保系统中的组件问题不会阻止业务维护基本操作。Salesforce 优先考虑将我们的服务保持在最高的可用性水平,并提供有关任何问题的透明信息。您可以在[Trust.salesforce.com](https://trust.salesforce.com/)上看到有关 Salesforce 系统性能和问题的实时信息。作为构建在 Salesforce 上的架构师,您的解决方案受益于 Salesforce 在整个平台中提供的可靠性、安全性和性能功能。 但 Salesforce 解决方案的整体连续性不仅限于 Salesforce 提供的内置服务。从架构的角度来看,Salesforce 技术连续性规划必须首先提出和回答有关 Salesforce 如何融入更大的企业环境的问题。哪些类型的系统集成了 Salesforce?外部系统如何依赖于 Salesforce 中的进程或信息?在 Salesforce 组织中,哪些流程或功能依赖于 AppExchange 解决方案?您的用户是通过第三方身份服务或 SSO 访问 Salesforce 吗? 要在 Salesforce 系统中建立更好的技术连续性: - **评估基础设施。**对于技术中断或问题,最常见的补救策略是构建冗余服务或系统,您可以在事件期间重新使用。在 Salesforce 中,我们有一个有意冗余的架构,这意味着我们在不同的物理位置维护客户的系统和服务副本。我们使用几种灾难恢复技术,包括站点交换,这使我们能够在需要时将用户流量从一个数据中心引导到另一个数据中心。要确定您可能需要在何处构建有意冗余,请自问这些问题。 - \[X] 服务的服务中断期间会发生什么?我们可以从该服务切换到另一个服务吗? - 恢复 \[X] 需要多长时间?对我们的客户有什么影响?对我们的合作伙伴有什么影响?对内部团队有什么影响? - [备份](/docs/architect/zh-cn/well-architected/guide/resilient#构建备份和还原功能)及其频率如何?备份能否提供支持业务所需的数据? - 我们是否依赖于供应商?他们的 BCP 计划是什么? - **提供运营支持。**运营支持是让团队尽快恢复并运行。请仔细考虑您的系统如何处理意外变化带来的容量要求和需求的显著增加,包括行业范围、区域范围或全球范围的变化。请确保您的 BCP 考虑了站点可靠性工程 (SRE) 或支持团队有效响应事件可能需要的额外资源或打破常规的程序。有关运营支持的问题包括: - 在停机时,我们的技术团队是否拥有继续工作所需的工具?我们是否模拟停机来验证计划或找出差距? - 如果灾害发生在特定地区,我们是否有该地区的承保计划? - 我们的客户是否全球化?它们是否全天候运行? - 我们是否有适当的[监控和提醒](/docs/architect/zh-cn/well-architected/guide/resilient#监控和警报),以便在出现故障时通知适当的个人? - **自动化并测试恢复策略。**解决问题后,确定问题发生的位置和修复方式。如果您可以,根据补救措施,自动化您的恢复策略并调整任何流程问题。许多公司为测试系统弹性的服务子集安排事件模拟。例如,模拟系统管理员帐户被锁定或泄露,或者模拟 AppExchange 提供商的中断或问题。请参阅[事件响应](/docs/architect/zh-cn/well-architected/guide/resilient#事件响应)。)有关测试和自动化如何帮助您更快地恢复服务的问题包括: - 我们多久计划和运行一次事件模拟? - 我们是否知道将服务恢复到稳定状态需要多长时间? - 我们是否有稳定的交付流程? - 我们是否知道在哪里可以自动化故障切换和恢复? 像对待其他开发项目一样对待来自事件后审查的任何项目。将它们添加到您的计划系统中,以便您可以确定它们的优先级并加以处理。 [模式和反模式](/docs/architect/zh-cn/well-architected/guide/resilient#连续性计划模式和反模式)显示了 Salesforce 解决方案中正确和糟糕的技术连续性规划。在构建之前,使用它们来验证您的设计,或者确定系统中需要重构的地方。 要了解有关适用于技术连续性计划的 Salesforce 工具的更多信息,请参阅[适用于弹性](/docs/architect/zh-cn/well-architected/guide/resilient#适用于弹性的-salesforce-工具)的 Salesforce 工具。 ### 构建备份和还原功能 恢复数据或元数据的备份副本有助于将贵组织恢复到上次已知的稳定状态。它还可以在灾难性系统故障或服务中断期间提供故障切换系统。定期备份您的数据和元数据,并将加密的备份副本存储在安全的位置,这将为您的架构增加一层弹性。 如果没有备份和还原策略,当生产数据和元数据被恶意损坏时,当缺陷无意中进入生产环境时,或者当大量数据加载期间的故障损坏生产数据时,您无法还原干净版本的生产数据和元数据。其中任何一种情况都可能导致业务关键型生产数据损坏,甚至永久丢失。除了连续性规划之外,设置备份和还原技术还具有一些优势,包括帮助制定减少大量数据的策略,并遵守与合规性相关的保留策略。 为了帮助确保 Salesforce 解决方案中备份和还原策略的连续性: - **开始吧。**制定好的备份和还原策略的第一步是首先制定策略。即使是像对贵组织的所有数据和元数据进行夜间备份这样简单的事情,也可以避免您的业务在灾难期间丢失重要信息或功能。 - **限制对备份的访问权限。**系统管理员是唯一有权访问数据备份副本的用户。该访问权限限制使业务用户无法查看他们在贵组织中无权查看的备份副本中的记录。 - **定期测试还原过程。**无论您实施哪种备份和还原策略,请定期在完全或部分复制 Sandbox 中[测试](/docs/architect/zh-cn/well-architected/guide/resilient#测试策略)还原过程,以确保在需要时它正常工作。 - **使备份和还原策略与数据归档策略保持一致。**确定在将记录归档或从系统中清除时,备份或归档中应执行的操作。请参阅[数据量](/docs/architect/zh-cn/well-architected/guide/reliable#数据量))。 如果您的数据量非常大,以至于完全备份在下一次备份开始运行之前没有时间完成,您可能需要更精细的备份策略。如果贵组织的数据频繁更改,更新对贵组织至关重要,您可能还需要更精细的备份策略。 要使备份策略更加精细: - **将备份范围限定到特定对象。**此策略涉及以不同的时间间隔备份来自不同对象的记录。请记住,子对象必须与父对象以相同的时间间隔备份,以保持数据的一致性。 - **时间盒\*\***部分备份\*\*。此策略包括区分完全备份(所有数据和元数据)和部分备份(仅元数据和自上次备份以来添加或更改的记录)。 **\*请勿停止执行完全备份**。重要的是要注意,您永远不要完全消除完全备份,即使数据量会导致长时间运行。对于大数据量,计划定期但不常见的完整备份(例如,每周备份)。还要计划更频繁的部分或特定于对象的备份(例如,夜间备份或每 X 小时备份一次)。此方法可让您灵活地重建最完整和准确的数据集,以在还原过程中使用。\* [连续性计划模式](/docs/architect/zh-cn/well-architected/guide/resilient#连续性计划模式和反模式)和反模式显示了 Salesforce 解决方案中正确和差劲的备份和还原功能。在构建之前,使用它们来验证您的设计,或者确定系统中需要重构的地方。 ### Salesforce 备份和恢复 Salesforce 备份和恢复是一个集成的 Salesforce 解决方案,它包括从 Own 收购中进行的 Own 恢复,可以保护重要数据不丢失或损坏。我们高度安全、易于设置、始终可用的解决方案确保了业务连续性和数据弹性,并简化了合规性。 使用 Salesforce 备份和恢复来防止数据丢失,从数据事件中快速恢复,并简化您的整体数据管理策略。您可以为高价值和受监管的数据创建备份策略,并只需几次单击即可恢复该数据。 #### 部署自动备份 每日自动备份会保护所有重要组织数据,包括元数据、Sandbox、受管软件包数据、文件附件等。根据需要随时运行备份,以实现恢复点目标 (RPO) 并保护您的部署。备份始终可以安全和合规地访问和存储。连续数据保护还可用于甚至更敏感或更事务性的数据,允许更快地恢复快速变化的重要信息。 #### 主动监控数据 通过直接发送到电子邮件的主动警报,检测异常数据活动、数据丢失和损坏。接收实时警报,以识别统计异常值或创建通知您异常数据活动的规则,从而帮助您比以往更快地检测事件。 #### 精确快速地恢复 Salesforce 备份和恢复通过提供对更改的精细可见性来加快恢复,从而可以快速识别和恢复受影响的数据。可视化图表等工具会突出显示不需要的更改,而易于使用的恢复功能会精确恢复受影响的对象、字段和记录。 #### 扩展备份的使用 我们的工具使您能够使用备份进行分析、审计和合规,并提供可搜索的历史数据、用于查看过去数据的开放搜索功能以及用于外部分析或仓储的导出功能。这将重新调整备份的目的,而无需额外的 Salesforce API。 #### 统一备份数据管理 备份和恢复提供了单个控制台来整合所有备份、管理、操作和合规性。此控制台允许您访问、管理、自定义和监控所有生产组织和 Sandbox 的备份。通过它,您还可以执行数据主体请求来确保备份数据的合规性,并完全控制自定义备份计划、频率和保留策略。 #### Salesforce 备份和恢复的关键用例 - **减轻数据事件的影响**。Salesforce 备份和恢复通过使用户能够将受影响的记录恢复到事件发生前的状态,帮助缓解数据事件,例如网络攻击或恶意的内部或外部活动。备份和恢复的导出功能保证了对用户关键数据的连续访问和可用性。 - **防止永久数据丢失**。人为错误仍然是数据丢失的主要原因。备份和恢复为这些错误提供了精确快速的解决方案。 - **更轻松地满足数据合规性和法律要求**Salesforce 备份和恢复支持共享责任模型,为备份数据中的批量忘记或数据更正启用自助功能。 要了解有关备份和还原的 Salesforce 工具的更多信息,请参阅[适用于弹性](/docs/architect/zh-cn/well-architected/guide/resilient#适用于弹性的-salesforce-工具)的 Salesforce 工具。 ### 连续性计划模式和反模式 此表显示了要在贵组织中查找或构建的模式选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/adaptable-continuity-planning)器中,发现连续性计划的更多模式。
模式 反模式
业务连续性 在您的业务中:
- 采用“恢复优先”的思想,重点是尽快使优先级最高的业务功能和功能失去影响。
- 有一个用于审查 BCP 测试计划的维护计划。
在您的业务中:
- “解决问题”的心态是事件管理的唯一方法。
- BCP 测试计划不会定期刷新。
在您的文档中:
- 存在 BCP,其中包含在 Salesforce 不可用时继续处理或分类数据的步骤,触发使用 BCP 的事件列表,以及 BCP 测试的步骤和间隔。
- BCP 包括上游和下游系统和依赖性。
在您的文档中:
- BCP 不存在、不完整或仅包含 Salesforce。
在您的测试计划中:
- 考虑 BCP 中与流程和人员相关的区域。
在您的测试计划中:
- 未考虑 BCP 中与流程和人员相关的区域。
技术连续性 在您的业务中:
- 您已评估是否需要构建有意冗余或故障转移系统
- 事件恢复策略尽可能自动化。
在您的业务中:
- 您没有评估有意冗余或故障转移系统的必要性
- 事件恢复策略全部是手动操作。
在您的文档中:
- BCP 考虑了团队可能需要的额外资源或打破常规的程序,以有效应对事件。
在您的文档中:
- BCP 不包括运营支持需求。
备份和还原 在您的文档中:
- 数据和元数据都存在备份和还原策略。
在您的文档中:
- 备份和还原策略不存在,或者如果存在,则不完整,仅应用于数据或元数据,而非两者。
在贵公司:
- 备份存储在只有授权用户才能访问的安全位置。
- 测试计划和测试日志显示,每年至少两次在完全或部分复制 Sandbox 中测试数据还原。
在贵公司:
- 备份不是人类可读的。
- 备份存储在未经授权的业务用户可以访问的位置。
- 没有数据还原过程,或数据还原过程未经测试。
## 适用于弹性的 Salesforce 工具
工具描述应用程序生命周期管理事件响应连续性计划
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
## 告诉我们您的想法 帮助我们保持 Salesforce 良好的架构与您相关;参加我们的[调查](https://sfdc.co/bxNtvh),以提供有关此内容的反馈,并告诉我们您接下来想要看到的内容。 > 在[这里](/docs/architect/zh-cn/well-architected/guide/contributors)阅读我们的更新计划。 ## 导言 意图性解决方案会随着时间的推移立即提供业务价值。意图架构以战略性的方式规划和交付,可以有效维护,并且易于人类阅读和理解。 功能和修复的优先级以对业务和技术利益相关者透明的方式提供。工程选择创建易于交付和维护团队使用的实施,无需添加功能或复杂化。意图性架构更容易拥有、维护和随业务发展,因为它们遵循明确一致的实施模式。生成器可以解释和实施新功能的设计,维护团队可以理解实施内容的文档。 您可以通过关注三个关键领域来创建更具针对性的系统:策略、可维护性和可读性。 ## 策略 架构中的策略意味着系统经过深思熟虑的规划和交付。这意味着交付和维护团队清楚地了解今天和将来要完成的工作,每个人都围绕要完成的工作的“原因”保持一致。这意味着紧急请求可以有效分类,利益相关者可以清楚地了解请求的影响和权衡。 通过关注预先测试、路线图和治理,您可以将更清晰的策略构建到您的架构中。 ### 优先级 优先级意味着计划您将交付的工作的顺序和范围。优先级包括了解交付品对业务的真正影响,根据其他工作请求和产品或计划的整体路线图评估这些影响。 评估给定工作项目影响的一种方式是查看业务的实际成本或收益。在您确定了自动化的 [KPI](/docs/architect/zh-cn/well-architected/guide/automated#kpi) 后,您可以使用[业务影响计算工作表](/docs/architect/zh-cn/resources/guide/kpi-spreadsheet-template)来评估实施的总体成本或收益。这些计算可以帮助您从利益相关者那里获得关于构建什么自动化以及以什么顺序构建的一致和支持。它们还可以帮助您确定要推迟或避免的自动化。有关识别有效工作的更多信息,请查看[流程设计](/docs/architect/zh-cn/well-architected/guide/automated#流程设计)。 为交付建立优先级框架也有助于您和您的维护团队管理用户期望,并与路线图保持一致。 可用于确定优先级的一些注意事项包括: - 交付品的业务影响(成本/效益) - 交付品所需的新工作量 - 维护交付件所需的工作量 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#策略模式和反模式)列表显示了 Salesforce 工作时正确(和糟糕)的优先级。您可以使用这些来验证您的实施计划,或者在构建之前确定您需要更好地确定优先级的地方。 要了解有关 Salesforce 工具的更多信息,以帮助确定优先级,请参见[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。 ### 路线图 路线图是确定优先级、经过验证、定义明确的待办事项视图。有效的路线图清楚地描述了未来工作的业务影响和技术影响。让业务和技术利益相关者参与进来是路线图的关键部分。路线图使您能够在任何工作开始前获得关于方法和结果的反馈和支持。归根结底,路线图让每个利益相关者了解未来工作的“原因”。 如果您的团队使用待办事项,重要的是要了解您的路线图不是待办事项中的汇总或项目列表。关系相反:只有当项目能够明确和可靠地与路线图上的交付品联系起来时,它们才会进入待办事项。通过利益相关者的参与创建的高质量路线图,使交付和维护团队能够清楚地看到他们应该关注什么以及如何确定请求的优先级,从而更容易理清冲突的请求和管理利益相关者的期望。 不良或不存在路线图会导致: - 不清楚新特性和功能何时可用 - 利益相关者之间的优先事项冲突 - 交付的解决方案与整体组织愿景脱节 - 难以理解正在进行的工作 - 团队之间的工作负荷不均衡 - 对工作项目之间的关系和依赖性缺乏可见性 - 由于依赖关系管理不善,实施暂停 利益相关者通常需要与其角色相符的信息来做出决策。创建有效的路线图需要清楚地了解您的受众以及他们需要的信息类型。路线图分为两种风格,以支持业务和技术受众。每个样式包含两个级别的粒度,以支持不同类型的信息。 业务路线图帮助利益相关者规划组织变革,利用增长机会,并与公司目标保持一致。业务路线图还提供了一种方式来确保 IT 支出与整体业务愿景保持一致。 - 创建业务能力路线图,向主管利益相关者展示将启用的功能。这种类型的路线图包含有关功能本身以及如何与业务目标保持一致的高级详细信息,例如提高运营效率或推出新产品线。 - 创建业务功能路线图,以深入了解特定功能,并在您需要帮助业务利益相关者进行资源规划、预算编制和变更管理时显示支持特性和功能。 技术路线图帮助技术利益相关者进行预算和资源分配规划。它们还帮助实施团队了解他们的项目适合作为更大整体的一部分的位置,并确定任何跨团队的依赖关系。 - 创建技术系统路线图,以显示将实施的特定系统,以及任何系统级依赖性。这种类型的路线图显示了高级系统信息,以及系统和业务功能之间的协调。 - 创建技术组件路线图,深入了解将部署以帮助满足资源规划和支持要求的系统的特定组件。这种类型的路线图显示了组件级信息和实施要求(例如,声明性开发、专业代码等)。 请确保路线图包含现实的时间表。一个常见的错误是只包括实施系统所需的时间,而不考虑完成相关活动所需的时间。这会导致过度分配实施团队成员,并比预期的延迟更长。在创建路线图时,请考虑完成以下内容所需的时间: - 所有新功能和更新功能的文档 - 维护支持新功能所需的现有功能 - 支持集成所需的相关系统的更新 - 上线后项目团队的支持率提高 - 测试、培训和变更管理 高度一致的业务和技术路线图传达了功能何时上线以及落后技术的整体视图。下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#策略模式和反模式)列表显示了 Salesforce 组织的正确(和糟糕)路线图。您可以使用这些来验证或改进您的路线图策略。 要了解有关可以帮助您绘制路线图的 Salesforce 工具的更多信息,请参见[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。 ### 治理 治理是您用来与利益相关者一起处理优先级、决策和变更管理的结构。治理明确了如何做出和传达决策。它为反馈和请求进入决策过程以及所有利益相关者了解维护和开发工作的状态提供了一致的方式。治理有助于发布清晰一致的管理流程,并帮助所有团队成员了解他们的角色和职责。 如果没有适当的治理,团队会遇到各种问题,包括: - 对重叠特性和功能的请求是临时的 - 实施团队优先考虑“更容易”的努力或来自更具影响力的利益相关者的请求,而没有适当考虑业务价值、权衡或整体组织目标 - 缺乏一致的审批和审查流程 - 发布节奏和质量不一致 - 开发工作中的高缺陷率、覆盖、冲突和冗余工作 也许系统没有有效治理的最明显的迹象是发布缓慢和繁琐。认识到治理体系的规模不是衡量其有效性的标准非常重要。事实上,精心设计的治理系统(就像许多大型企业的系统一样)可以限制发布的速度和频率。 良好的治理是让糟糕的自定义很难通过早期开发阶段,让好的自定义可以预测和一致地投入生产。 治理工作往往具有反作用。当问题(例如过多的技术债务)开始成为业务问题时,就会启动或加倍它们。在许多情况下,不幸的回应是企业“锁定”开发工作和版本,而不是创建有效的[设计标准](/docs/architect/zh-cn/resources/guide/design-standards-template)和构建自动化来在开发人员工具链和源控制系统中强制执行这些标准。 在构建 Salesforce 治理系统的框架时,请包含以下元素,并考虑这些需要回答的关键问题: - **工作请求。**用户如何询问功能或特性?如何报告错误? - **优先级和工作规划。**谁决定什么工作请求重要?如何确定工作范围、确定优先级、接受或签署? - **环境和发布计划。**开发、测试和发布的环境漏斗是什么?谁负责配置、刷新和提供访问权限?谁负责部署和验证?如何及何时发布更改?如何在 Salesforce 发布周期内处理部署或环境?(有关更多信息,请查看[应用程序生命周期管理](/docs/architect/zh-cn/well-architected/guide/resilient#应用程序生命周期管理)。) - **服务所有权和生产支持。**谁支持什么?谁处理“热修复”生产问题?如何测试和发布这些项目?谁负责组织的整体安全标准? 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#策略模式和反模式)列表显示了 Salesforce 组织的正确(和糟糕)治理。您可以使用这些来验证或改进您的治理策略。 要了解有关适用于治理的 Salesforce 工具的更多信息,请参见[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。 ### 策略模式和反模式 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/easy-strategy)器中,发现更多策略模式。
模式 反模式
优先级 在您的文档中:
- 所有新工作项目都有明确的业务价值度量(例如,收入增加、流程优化的成本节约等)
- 路线图显示基于业务价值的工作优先级
在您的文档中:
- 与工作关联的业务价值不明确或不存在
- 路线图不存在
在贵公司内:
- 已确定所有工作项目的实施和维护费用
- 根据业务影响、交付所需的新工作量和维护所需的工作量确定功能请求的优先级
在贵公司内:
- 实施和维护功能的相关成本不明确
- 请求以临时或先进先出的方式传递
路线图 路线图:
- 传达专为受众定制的信息(业务或技术)
- 以正确的详细程度传达信息
- 显示开始和结束日期
- 显示先决条件和依赖性
路线图(如果存在):
- 用作项目启动材料,而非交付的工件
- 请勿帮助利益相关者和交付团队保持一致
- 混合详细信息级别(例如,通过在同一路线图中包含系统和组件)
- 包含并非针对受众定制的信息(例如,同一路线图中的业务功能和系统)
在您的业务中:
- 利益相关者了解工作项目的“原因”
- 交付团队知道如何根据长期优先级评估待办事项
- 团队知道谁在做什么以及如何管理依赖性
- 工作是有意的,即使优先级需要快速更改
在您的业务中:
- 工作从待办事项中提取,没有明确的“原因”
- 团队难以协调相互依赖的工作,并且经常在不知不觉中重复工作
- 工作往往是反应性的
- 利益相关者通常对正在做的事情感到沮丧和困惑,并且对何时交付新功能感到忌惮
治理 在您的业务中:
- 用户可以轻松报告错误并请求功能
- 记录工作项目的优先级过程,并对所有利益攸关方透明
- 环境战略有明确的文档记录,开发环境与文档记录相匹配
- 发布计划可以预测,对所有交付团队成员透明
- 团队成员知道谁在整个应用程序生命周期中负责什么
- 用户和交付/维护团队清楚了解版本
- 生产支持流程清晰,热修复程序有清晰的生产路径
- 团队和项目仅使用为业务用途批准的 AI 模型
在您的业务中:
- 错误报表和功能请求是临时的
- 工作项目没有明确的优先级
- 环境是临时配置的,可能不会以可预测的方式刷新;开发人员通常没有他们需要的环境和访问权限
- 交付团队和用户无法预测发布
- 团队不知道谁负责什么
- 热修复是临时解决的
- 您的待办事项已成为过时和停滞的“意见库”
- 治理机构充当帮助台,对支持请求进行故障排除
- 文档不容易访问
- 团队会临时选择 AI 模型
## 可维护性 可维护性意味着系统可以保持健康状态,新功能进入系统,技术债务定期、可预测地移出系统。可维护的系统使您的团队能够以可预测的速度和质量为业务提供价值。系统的可维护性取决于几个因素,包括可读性、松耦合性以及测试策略的彻底性。 最重要的是,系统的可维护性取决于其设计的简单性。本节介绍如何创建更直接的解决方案设计,并提高可维护性。 您可以通过关注两个关键来构建更容易维护的解决方案:使用标准功能而不是自定义功能,以及处理技术债务。 ### 标准与自定义功能 Salesforce 提供一系列预构建的解决方案 — Sales Cloud、Service Cloud 和许多 Salesforce 行业解决方案,以及创建您自己的自定义解决方案的灵活性。支持 Salesforce 自有云解决方案的基础服务也适用于构建于 Salesforce Customer 360 平台的任何自定义解决方案。将 Salesforce 的预构建服务和解决方案用作尽可能多的解决方案的可信基础。 使用预构建平台服务有两个明显的优势。首先,您的应用程序自然会受益于每个版本的最新 Salesforce 创新。其次,您的开发团队可以专注于扩展和深化您的 Salesforce 解决方案提供的业务功能,而不是处理基本的架构繁重的工作。 从架构的角度来看,正确选择何时使用标准功能以及何时构建自定义功能并不具有挑战性。密钥是: - **自定义平台意味着修改和扩展,而不是复制。**当您设计或评估您的架构时,您应该问:这是否已经存在于 Salesforce 平台的某个地方?如果答案是“_是,但是...\[插入业务利益相关者想要的更改...]”_,那么在平台中使用预构建功能。要完成的架构工作是确定配置预构建 Salesforce 功能的最有用的方式,以满足业务预期。 - **没有自定义是小事**。随着时间的推移,每个变化都会产生影响。如果您需要实施自定义解决方案,您可以通过尽可能选择使用低代码技术并在实施中创建可[组成单元](/docs/architect/zh-cn/well-architected/guide/composable)来减轻系统不可避免的[技术债务](/docs/architect/zh-cn/well-architected/guide/intentional#技术债务)。 - **考虑构建-购买频谱**。[Salesforce AppExchange](https://appexchange.salesforce.com/)是扩展 Salesforce 的应用程序和解决方案市场。AppExchange 应用程序可以提供功能,而无需在构建和维护自定义解决方案时涉及的开销。评估 AppExchange 解决方案时,请考虑以下事项: - 确定解决方案功能和差距。理想情况下,您会找到满足所有业务需求的应用程序。实际上,您可能找不到完美匹配。在您评估解决方案时,将潜在解决方案中的功能映射到业务需求的优先级列表。这将帮助您找到最能满足您最关键要求的解决方案。 - 使用 Sandbox 和免费试用。使用免费试用期来评估 Sandbox 环境中的应用程序,并确定最合适的应用程序。确定应用程序是否需要您进行与现有配置冲突的配置更改。 - 考虑短期和长期成本。根据基于订阅的应用程序的经常性成本,评估长期应用程序维护的节省。避免出现以下情况:您必须为业务利益相关者永远不会使用的很多功能支付经常性费用。 - **使用 Salesforce 中的预构建数据模型。**Salesforce 为销售、服务和各种行业垂直行业提供预构建的数据模型。使用 Salesforce 提供的数据模型可确保系统中的功能仅被定义一次(消除冗余和孤岛),在整个系统中建立单一的真实来源,更容易使用分析来理解应用程序数据,更容易使用 Salesforce 的预构建人工智能服务,降低维护成本(通过减少您需要支持的自定义),并减少技术债务。 就这么简单。从下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#可维护性模式和反模式)中可以看出,反模式可以归结为在自定义解决方案中复制标准功能,或者使用更复杂的技术来提供自定义。 在实践中,您可能会遇到这样的情况,即业务利益相关者将自定义功能反模式视为最佳或唯一可行的前进道路。在这些情况下,您必须向利益相关者解释选择这条道路所涉及的权衡,然后彻底记录决定、其理由和实施。在这一领域,尽早交付核心价值并随着时间的推移进行调整,可帮助利益相关者更好地了解最佳前进方向。 要了解有关 Salesforce 工具的更多信息,以帮助您提高可维护性,请参阅[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。 ### 技术债务 技术债务是任何系统的自然组成部分。当技术或业务需求发生变化时,昨天的合理设计可能会成为反模式。也许,为了填补 Salesforce 平台功能中的空白而构建的东西会随着新的 Salesforce 版本或产品发布而突然变得多余。也许性能更好或更灵活的技术取代了您已经实施的技术。技术债务可以通过多种方式产生。 使用 Salesforce Customer 360 平台构建应用程序的一个关键好处是[平台内置向后兼容](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#平台-api)性。这意味着新的平台创新可能会改变您未来应使用的解决方案的模式,但您基于以前的 Salesforce 技术构建的解决方案的日常功能将继续有效。随着时间的推移,任何基于旧技术的解决方案都会开始为您的应用程序添加新功能带来风险或瓶颈,并降低整体解决方案的运行状况。 规划和执行定期工作以解决技术债务问题对于在 Salesforce 解决方案中保持健康、简单的设计至关重要。不规划、审计和补救技术债务是创建架构不佳的系统的一种肯定方法。 最小化技术债务的一个方法是尽可能避免引入它,避免快捷方式,并优先使用[标准功能而不是自定义](/docs/architect/zh-cn/well-architected/guide/intentional#标准与自定义功能)功能。快捷方式,例如硬编码值,可能会节省时间,但从长远来看,它们会产生必须偿还的债务。 从架构角度解决技术债务问题的关键包括: - 确定作为或不作为的实际[成本或收益](/docs/architect/zh-cn/resources/guide/kpi-spreadsheet-template) - 正确[的路线图](/docs/architect/zh-cn/well-architected/guide/intentional#路线图) - 构建可[组合解决方案](/docs/architect/zh-cn/well-architected/guide/composable) 困难可能是让利益相关者与采取行动保持一致。一些利益相关者可能会将日常维护视为解决“昨天的错误”或剥夺他们希望预算支持的功能。 显示作为和不作为的实际业务影响,以及明确界定的交付品和时间表,可以帮助您的利益相关者了解解决技术债务的价值和相对优先级。坚持不懈地开展工作,将技术债务与业务影响联系起来,不仅有助于您的利益相关者更好地理解要完成的工作。它还将帮助您确保以真正有利于用户的方式识别和解决技术债务。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#可维护性模式和反模式)列表显示了 Salesforce 组织正确(和糟糕)的技术债务管理。 要了解有关可帮您解决技术债务问题的 Salesforce 工具的更多信息,请参阅[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。 ### 可维护性模式和反模式 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/easy-maintainability)器中,发现更多可维护性模式。
模式 反模式
标准与自定义 在设计标准中:
- 有一个明确的指导原则来避免不必要的自定义解决方案
- 解决方案的指导原则使用以下优先级:1.使用内置平台服务,2.在构建自定义解决方案之前,请考虑 AppExchange 应用程序。在编写代码之前使用低代码自定义
在设计标准中:
- 设计标准要么不存在,要么没有明确的理由来避免不必要的自定义和代码
在您的文档中:
- 决策记录显示选择构建或购买解决方案时的短期和长期成本计算
在您的文档中:
- 决策记录在选择构建或购买解决方案时不考虑短期和长期成本
在数据模型中:
- 没有对象的名称或功能与标准对象重复
- 标准对象未用于超出预期范围的目的
在数据模型中:
- 对象与标准对象的名称和/或功能重复
- 标准对象用于远远超出预期范围的目的
在LWC、Aura或Visualforce中:
- 不存在覆盖标准页面视图机制的代码
在LWC、Aura或Visualforce中:
- 代码用于覆盖标准页面视图机制,通常以单页面应用程序的形式存在
在LWC、Aura或Apex中:
- 没有代码尝试覆盖或规避平台执行顺序
在LWC、Aura或Apex中:
- 代码尝试覆盖或规避平台执行顺序
技术债务 在路线图中:
- 计划解决技术债务问题
- 交付件和开始/结束日期明确
在路线图中:
- 没有计划解决技术债务问题的工作
- 交付品不明确;开始/结束日期不明确
在您的决策记录中:
- 技术前/技术后债务补救的 KPI 有明确记录
- 关于作为和不作为的权衡讨论侧重于业务成本或收益
在您的决策记录中:
- 技术债务补救没有可衡量的 KPI
- 从技术或 IT 角度考虑技术债务,与业务无关
在您的组织中:
- 没有不支持的或传统技术处于活动状态,包括:
-- 所有用户在 Lightning Experience 中工作
-- Apex 中没有或很少使用 @future (使用Queueable)
-- 所有第三方 Apex 属于 AppExchange 软件包
-- 没有有效的工作流规则(使用流)
-- 没有有效的进程构建器进程(使用流)
-- PushTopic 事件(使用变更数据捕获)
-- 通用事件(使用平台事件)
-- 30.0 之前的 API 版本
-- Salesforce 组织连接使用适用于 Salesforce Connect 的跨组织适配器
在您的组织中:
- 不支持或原有技术已启用,包括:
-- 使用 Salesforce Classic 的用户
-- @future use in Apex
-- 来自非 AppExchange 源的第三方 Apex
-- 工作流规则
-- 进程构建器进程
-- PushTopic 事件
-- 通用事件
-- 30.0 之前的 API 版本
-- Salesforce 到 Salesforce 的连接
## 可读性 *可读性*的核心概念是创造一致性,使人们容易理解事物的工作方式。构建可读的系统会使交付和维护团队保持一致,并帮助不熟悉系统的人员快速了解零件如何组合在一起。这意味着您的团队可以更少地依赖具有机构或历史 Knowledge 的个人来有效地引导供应商或新的团队成员。这意味着团队中的熟练人员可以专注于正在做出的选择的质量和权衡,因为系统的配置和代码易于人类阅读和理解。可读性可以加快治理和质量保证流程,并帮助团队更好地识别何时创建冗余自定义。它还可以提高系统以可重用和可测试的方式运行的可能性。 您可以通过有效的设计标准和文档来提高可读性。 ### 设计标准 [设计标准](/docs/architect/zh-cn/resources/guide/design-standards-template)提供了保持所有自定义一致的指导,即使在开发的早期阶段。设计标准就像护栏一样,使所有从事系统工作的交付团队和维护团队在如何处理和实施自定义方面保持一致。定义设计标准有助于提高交付和维护团队的效率,使代码和架构审查更容易进行,并为更好的[文档](/docs/architect/zh-cn/well-architected/guide/intentional#文档)提供基础。 如果没有设计标准,团队更有可能在竖井中工作。如果没有设计标准提供的一致性,企业将发现自己很难做到: - 供应商和开发团队跨解决方案使用临时模式和方法,可能会引入反模式并降低可重用性(请参阅[关注分离](/docs/architect/zh-cn/well-architected/guide/composable#分离问题))。 - 增加了解决生产问题的时间,以及培训新团队成员所需的支持团队,并帮助他们了解一组不同的模式和方法。 - 跨团队协作不佳、团队之间工作冗余、解决冲突的时间浪费,以及集成测试中发现的错误。 - 增加挫折感和更高的更替率。 设计标准的一个关键优势来自利益相关者为创建标准而必须进行的对话和决策。特别是,该流程为您的业务和技术潜在客户提供了机会,让他们能够围绕业务所需的优化设计进行调整。 在[设计标准中](/docs/architect/zh-cn/resources/guide/design-standards-template)包含以下内容 - **Salesforce 元数据的命名约定**为如何命名系统中的每个自定义定义一组约定。良好的命名约定不仅仅是在对象、字段、代码、流和系统的其他元素的名称之间强制执行一致性。良好的命名约定也有助于开发团队使用名称来传达有关他们正在构建的内容的目的和功能的信息。因此,其他利益相关者可以通过查看其名称来更好地理解特定的自定义。 - **批准的设计模式及其用例**建立[模式和反模式浏览](/docs/architect/zh-cn/well-architected-tools/guide/patterns)器库,以及关于何时(和不使用)使用每个模式的关键信息。该库可能包括所需的 Apex 触发器模式,或基于您在系统中的可[组成性](/docs/architect/zh-cn/well-architected/guide/composable)的流编排模式。 - **开发环境和工具指导**。维护开发团队用于工作的明确工具列表。这可能包括为编写代码的任何人批准的工具链和语言,或者为低代码开发批准(或未批准)的声明性功能。您的标准可能包括用于自定义和文档的源控制系统列表,以及所需的签入/签出步骤。它们可能还包括用于不同类型开发工作的环境列表。 除了定义这些标准之外,您还需要决定如何以及在哪里维护和存储它们。如果贵公司的团队找不到您的设计标准(或者甚至不知道存在),它们将不会有效。理想情况下,您的设计标准与您的文档在同一个系统中(有关更多信息,请查看下一节)。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#可读性模式和反模式)列表显示了 Salesforce 组织的正确(和糟糕)设计标准。您可以使用这些来验证或改进您的设计标准。 要了解有关可帮您定义设计标准的 Salesforce 工具的更多信息,请参阅[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。 ### 文档 文档解释了系统的内容、方式和原因。如果没有有意义和一致的文档,团队会浪费大量时间来尝试了解系统的现状(并潜在地误解功能和自定义)。 创建好的文档需要时间。虽然大多数团队都认为文档对大型项目很重要,但在进行快速更改(例如配置更新或对自动化进行小的调整)时,跳过这一步可能很有诱惑力。不记录您对系统进行的更改始终是一种反模式。跳过文档可能会节省少量前期时间,但排除未正确记录的组织故障所需的时间将不仅仅是抵消这些节省时间。请始终在所有预估中包含足够的时间来创建文档,而不论您计划进行的更新需要付出多大的努力。 缺乏清晰的文档会导致各种问题,包括: - 用于返工现有实施的开发周期 - 重复讨论重新讨论或对先前的决定感到困惑 - 新团队成员或供应商入职时间更长 - 过度依赖拥有机构或历史 Knowledge 的个人 - 冗余架构支持整个业务中相同或类似的功能 - 难以向关键利益相关者传达解决方案的目的和价值 对于 Salesforce 解决方案,维护文档: - **解决方案概述**。通过[图表](/docs/architect/zh-cn/reference-diagrams/guide/introduction),您和利益相关者能够以各种详细信息级别可视化解决方案。Salesforce 图表框架帮助您创建图表,显示解决方案的业务功能以及技术实施详细信息。 - **决策记录**。将考虑的选项、权衡、最终决策和推理记录在一个所有团队成员都可以访问的中心位置,以备将来参考。 - **代码**。代码格式本身是文档的关键部分,它可以(并且应该)与您的[设计标准](/docs/architect/zh-cn/well-architected/guide/intentional#设计标准)保持一致。您还需要记录关键信息,并在每次修改代码时进行更新。对于所有类、触发器和组件,请记录以下内容: - 代码的作者 - 编写代码的时间 - 代码应该做什么 - 关键依赖性 - 所有更改 - **声明性自定义**。对于贵组织中元数据的每种自定义,Salesforce 会为团队提供[内置属性](/docs/architect/zh-cn/fundamentals/guide/platform-multitenant-architecture#基于浏览器的无代码和低代码应用程序开发),以提供有关元数据目的和意图的帮助信息。作为设计标准的一部分,包括团队如何使用这些内置功能,以及如何命名声明性自定义。还要维护与您用于代码的信息相同的关键信息日志。 制定一套文档标准,以确保所有当前和未来团队成员能够以同样的方式解释文档。 ([设计标准](/docs/architect/zh-cn/resources/guide/design-standards-template)可以帮助做到这一点。)考虑用户如何搜索文档以查找相关部分或术语也很重要。随着系统的老化和复杂性的增加,您的文档也会增加。文档中信息的用途将与用户搜索和查找相关项目的频率、速度和容易程度直接相关。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#可读性模式和反模式)列表显示了 Salesforce 组织的正确(和糟糕)文档。您可以使用这些来验证或改进您的文档策略。 要了解有关适用于文档的 Salesforce 工具的更多信息,请参见[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。 ### 可读性模式和反模式 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式浏览](/docs/architect/zh-cn/well-architected-tools/guide/easy-readability)器中,发现更多可读模式。
模式 反模式
设计标准 在您的组织中:
- 代码和声明性自定义具有一致的、人类可读的名称
- 数据模型的对象和字段名称一致、统一
- 审计显示字段在报表等中一致填写和引用。
在您的组织中:
- 代码和声明性自定义名称不一致
- 数据模型的名称不一致,许多对象和字段似乎多余
- 审计显示许多未使用的字段或各种使用级别,并且没有与报告等一致的链接。
在您的业务中:
- 团队知道使用(和不使用)什么工具完成工作
- 批准的设计模式易于按用例查找和识别
- 批准的 AI 模型被明确识别,并包含预期目的
在您的业务中:
- 团队使用许多不同的工具完成类似的工作
- 没有批准的设计模式
- 供应商或新员工入职需要大量时间
- 批准的 AI 模型未明确识别,预期目的不明确
文档 在您的组织中:
- 代码和声明性自定义有明确的描述
在您的组织中:
- 代码和声明性自定义没有描述,有难以理解的描述,或描述似乎与自定义的实际功能不匹配
在您的业务中:
- 所有解决方案都有业务功能和技术实施详细信息的图表
- 为代码和声明性自定义设置关键信息日志
- 人员可以搜索并查找相关文档
在您的业务中:
- 解决方案的内容/方式/原因很难找到,并且可能对大多数团队不可用
- 人们很难理解解决方案和他们正在使用的系统
- 供应商或新员工入职需要大量时间
## 与意图相关的工具
工具描述策略可维护性可读性
ApexDoc包含静态 HTML 页面的文档 ApexXX
批量删除无效选项列表值从选项列表中删除无效未使用的值X
Lightning设计系统验证器验证标记并了解如何改进代码XX
迁移到流将工作流规则和进程构建器进程转换为流X
Salesforce Labs 的项目管理工具在 Salesforce 组织中管理项目XX
适用于 Visual Studio 代码的 Salesforce 扩展(展开)使用 Visual Studio 代码扩展高效分析 Salesforce 代码XX
组织检查快速分析您的组织及其技术债务X
Salesforce 代码分析器通过 IDE、CLI 或 CI/CD 扫描代码,以确保符合最佳实践XX
Salesforce 路线图资源管理器探索 Salesforce 产品创新X
设置审计跟踪跟踪设置更改和审计历史XX
## 与意图相关的资源
资源描述策略可维护性可读性
改进 Salesforce 组织的 5 个文档策略改进 Salesforce 实施文档X
选择命名约定 (Trailhead)了解如何应用命名约定X
定义、识别和衡量技术债务定义、识别和衡量技术债务XX
设计标准模板为您的组织创建设计标准XXX
Salesforce 图表入门了解如何为您的用例创建正确的图表X
编码惯例入门 (Trailhead)定义并遵循编码约定X
如何处理技术债务 (Trailhead)在 Salesforce 组织中管理技术债务XX
改进 Apex 代码 (Trailhead)应用测试驱动开发的基本原则X
组织调整 (Trailhead)了解 V2MOM 校准流程X
优先考虑并计划摆脱技术债务的方法制定减少和删除技术债务的计划XX
Salesforce 命名约定模板开始使用命名约定XX
技术债务:它是什么以及您为什么要关心它?了解技术债务对贵组织的影响X
在企业架构中使用业务模型画布在业务模型中创建、交付和查看价值X
## 告诉我们您的想法 帮助我们保持 Salesforce 架构合理与您相关;参加我们的[调查](https://sfdc.co/bxNtvh),以提供有关此内容的反馈,并告诉我们您接下来想要看到的内容。 ## 导言 Diagram showing Salesforce Well-Architected core capabilities are Trusted, Easy, Adaptable Salesforce 精心构建的框架向您展示了健康的面貌,以及使用 Salesforce Customer 360 平台制定路线图和设计解决方案的时间。它基于整个 Salesforce 和生态系统的产品团队和实施专家的 Knowledge 分享了规范性指导以及在您的环境中要寻找的模式和反模式示例。Salesforce 精心构建旨在帮助您构建可信、轻松和适应性强的解决方案。 受**信任**的解决方案保护利益相关者。
**简单**的解决方案可快速交付价值。
可**适应**的解决方案会随着业务的发展而发展。
Salesforce Well-Architected 旨在帮助您逐步了解在 Customer 360 平台上构建健康解决方案所需的架构思维。 对于使用 Salesforce 创建解决方案的架构师来说,一个独特的挑战是平台的基本灵活性。一个解决方案可能会扩展 Salesforce 提供的预构建解决方案(即 Sales Cloud、Service Cloud、不同的 Industries Cloud 垂直行业)。另一个解决方案可能是完全自定义的应用程序。您可以使用 Salesforce 的功能广泛深入,最适合您的实施的特定技术选择将取决于业务需求。很难知道什么能够为每种可能的 Salesforce 解决方案创造长期健康的最佳机会。 Salesforce 精心构建可为您提供经验丰富的架构师的见解和指导。您可以使用见解和建议来验证(或挑战)您的思维,并深入了解您可能不熟悉的注意事项或技术领域。 可能也很难理解是否存在所有健康解决方案通用的架构基准,因为实施多种多样。在 Salesforce 中,我们作为公司和员工所做的每件事都以我们的核心价值观为指导。我们认为这也适用于建筑。这就是为什么 Salesforce 良好架构是围绕可信、轻松和可适应的核心构建的。当您评估复杂的架构细节和权衡时,您可以返回到这些核心功能,并将其用作指南针来指导您的决策。 下面,您将找到有关在我们可信、轻松和适应性强的框架内探索的单个主题的详细信息。 ## 主题如何排列 我们使用两个级别来组织整个 Salesforce 架构良好的信息。顶层是架构良好的解决方案应该是什么:受信、容易和适应性。第二个级别更详细地介绍了注意事项、要构建的模式(或要避免的反模式)以及与可信、轻松和适应性解决方案的特定方面相关的规范性指导。将您的设计与在此框架中提供的指导保持一致,应能提高 Salesforce Customer 360 应用程序的质量,使其运行状况更持久。 是否想要快速开始使用模式和反模式?访问[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/patterns)器。 下面,您可以看到主题排列方式的概览:
受信
受信任的解决方案保护您的业务和利益相关者。
安全 合规 可靠
组织安全性
会话安全性
数据安全
法律遵守
道德标准
可访问性
可用性
性能
可扩展性
轻松
简单的解决方案可以快速提供业务价值。
意图 自动 参与
策略
可维护性
可读性
效率
数据完整性
简化
有用
可适应
适应性强的解决方案会随业务发展。
弹性 可合成
应用程序生命周期管理
事件响应
连续性计划
分离问题
交互性
可打包性
> 在[这里](/docs/architect/zh-cn/well-architected/guide/contributors)阅读我们的更新计划。 ## 导言 系统通过使业务更快、更大规模地满足关键目的和目标来展示自动化行为。健康的自动化使用户能够专注于高价值的工作,并减少了在重复的手动任务或复杂的数据输入上花费的时间。 通常,自动化意味着将业务流程从一种形式转换为另一种形式:从纸质形式转换为数字形式,从旧系统转换为新系统。每个业务流程翻译都会带来一个转换的机会。 转型不是使用新技术为用户引入破坏性和混乱的变革。转型涉及创建更简单的工作方式,使业务能够毫无摩擦地发展,并使业务用户能够更深入地关注对其利益相关者真正重要的事情。从架构的角度来看,这涉及识别可以完全消除或自动处理的任务。它要求在如何使用技术及其对业务的可衡量的影响之间建立明确的联系。 关于使用 Salesforce 实现自动化,请注意一些重要事项:可以使用各种工具,使用编程和声明性技能集完成。设计架构良好的自动化不仅仅是选择使用一个自动化工具构建。它涉及使用一致和可预测的方法,并使团队能够开发、测试、部署和维护您设计的自动化。您的自动化应该采用最可[维护和可读](/docs/architect/zh-cn/well-architected/guide/intentional)的形式。 本节涵盖了如何设计和重构自动化,以使企业更快、更大规模地实现关键目标。您可以通过关注效率和数据完整性来改进 Salesforce 中自动化的架构。 ## 效率 在自动化中提高效率不是像往常一样勤奋地利用 Salesforce 技术重新创建业务。它涉及深入理解团队将负责满足或跟踪的关键指标和业务结果,并了解您自动化工作内部和之间的[职能单位](/docs/architect/zh-cn/well-architected/guide/composable#功能单元)。它涉及确定您如何通过自动化创建模式,使业务更有效、更快地大规模运营。 高效的自动化逻辑将使您的系统: - 更具可扩展性和业务价值 - 对用户更有帮助 - 更具[适应性](/docs/architect/zh-cn/well-architected/guide/adaptable-overview),能够满足不断发展的业务需求 您可以通过流程设计和操作逻辑提高自动化的效率。 ### 流程设计 流程设计包括定义工作方式。构建真正高效和有效的流程意味着您的设计不仅仅是复制当前的工作方式。识别和删除无效或不明确的步骤至关重要。优化的流程应无需不必要的步骤即可创造可衡量的业务价值(请参阅[KPI](/docs/architect/zh-cn/well-architected/guide/automated#kpi))。不明确或不必要的步骤很可能会造成技术债务,并导致自动化无法维护。 通常,发现和记录业务流程的责任属于业务分析师甚至系统管理员。架构师负责与团队的这些成员合作,以确保您的流程设计在技术上可靠且结构合理。尽早应用 Salesforce Platform 的 Knowledge 将有助于团队识别通过自动化简化的流程,或需要更改以避免昂贵自定义的流程。 要为 Salesforce 构建优化的流程,请考虑: - **彻底定义流程**。目的不明确或定义不明确的进程更有可能在设计时被误解。这将导致基于假设的错误设计,从而导致自动化不正确或效率低下。确保您想要自动化的业务流程符合以下标准: - 范围为单个特定功能(请参阅[功能单元](/docs/architect/zh-cn/well-architected/guide/composable#功能单元)) - 具有清晰定义、可衡量的产出(请参阅[业务价值](/docs/architect/zh-cn/well-architected/guide/automated#业务价值)) - 具有明确界定的输入和输出 - **明确流程步骤**。\* 虽然有时添加“可能有助于未来”的其他步骤很有诱惑力,但这从来都不是一个好方法。自动化的每一步都与整个流程的结果相关。确保每个流程步骤具有以下特征: - 执行特定的精细任务(请参阅[可撰写](/docs/architect/zh-cn/well-architected/guide/composable)) - 进程生成其定义输出所需的(删除所有非必要步骤) - 可以使用最少的资源完成 - 利用现有系统数据,而不是尽可能要求用户输入(请参阅[参与](/docs/architect/zh-cn/well-architected/guide/engaging)) - 提供用户可以理解的输入选项,而无需了解基础系统的工作原理(请参阅[帮助](/docs/architect/zh-cn/well-architected/guide/engaging#有用)) 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/automated#效率模式和反模式)列表显示了 Salesforce 组织中正确(和差)优化的外观。在构建之前,您可以使用这些来验证您的自动化设计,或者确定需要进一步优化的自动化。 要了解有关 Salesforce 提供的流程自动化工具的更多信息,请参阅[工具相关自动化](/docs/architect/zh-cn/well-architected/guide/automated#与自动化相关的工具)。 ### 操作逻辑 操作逻辑处理流程如何有效地从设计转化为实际实施。无论事务量的峰值或正在运行的并发实例的数量如何,具有强大操作逻辑的自动化都会继续表现良好。逻辑上合理的自动化有助于企业更容易地扩展,以便在更高的需求级别上进行操作。在自动化中构建强大的操作逻辑直接关系到系统的整体[可靠性](/docs/architect/zh-cn/well-architected/guide/reliable)。 无法有效运行的自动化会提供糟糕的用户体验和客户体验,导致潜在的收入损失和客户 Trust 损失。它们还具有更高的维护成本,并可能成为延迟相关流程的瓶颈,从而导致整体系统性能问题。 要在自动化中创建有效的操作逻辑,请考虑: - **确保创建自动化的每个人都知道正确的方法。**使用任何类型的自动化工具都可以做出糟糕的设计选择。代码与基于点击的工具相比,同样容易出错或实施选择不当。例如,使用硬编码参考 ID 是流和代码中出现的反模式。基于点击的工具不应被视为允许任何人和每个人都将自动化发布到生产的许可证。创建自动化的每个团队成员都需要知道如何以正确的方式构建它。有关如何在系统中定义和应用有效标准的更多信息,请查看[可读性](/docs/architect/zh-cn/well-architected/guide/intentional#可读性)和[设计标准](/docs/architect/zh-cn/well-architected/guide/intentional#设计标准)。 - **清楚记录所有执行路径**。自动化的使用增加不仅会增加潜在数据量,还会增加计划外调用上下文。您需要了解如何调用不同的自动化,并确保正确的事务控制(请参阅数据处理)出现在具有多个入口点的所有自动化中。例如,屏幕流不会在批量数据加载时运行,但 Apex 触发器和触发(以及自动启动)的流可能会运行。清楚地记录自动化的计划和潜在执行路径是理解在实施过程中您需要适应哪些逻辑条件的关键方面。 - **“批量化”所有数据操作(包括 SOQL)。**每个数据操作(插入、更新等)都应针对集合执行。总是。毫无例外。这就是“批量化”操作的含义。虽然平台可以支持 singleton 数据操作,但您不应允许实施 singleton 模式。 - **使用 SOSL 进行搜索操作**有一种误解,即不能对通过 SOSL 返回的记录执行数据操作。的确,不能直接针对 SOSL 结果调用 DML,但代码可以解析 SOSL 结果并创建可以在 DML 或数据库类方法中引用的集合。SOSL 和 SOQL 之间的关键区别在于各自的返回类型,以及它们如何响应广义搜索或通配符搜索。SOSL 可以处理几种 sObject 类型(这就是为什么返回类型不同),它可以处理通配符和广义字符串搜索,性能比 SOQL 好。 - **将 SOQL 视为数据操作。**请勿使用 SOQL 查找记录 — 将其用于优化数据操作。SOQL 和数据操作对[基础关系数据库](/docs/architect/zh-cn/fundamentals/guide/platform-multitenant-architecture#平台数据层)的性能影响非常相似。SOQL 甚至可以传递[明确的 DML 指示符](https://developer.salesforce.com/docs/atlas.en-us.238.0.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_for_update.htm?q=for%20update),这将在预期的数据操作中锁定数据库行。要创建可扩展的自动化,请确保您以类似的尽职调查对待 SOQL:在没有非常具体、格式良好的选择条件的情况下不要使用它,不允许无关的字段引用,并且需要在字段和 `WHERE` 语句逻辑中的筛选器输入之间进行仔细的数据类型匹配。您的代码还应具有适当的控制,以确保查询永远不会在非批量化上下文中或根据空或空白筛选条件运行。 - **保持同步操作严格专注于实时帮助用户的工作。**在[流程优化](/docs/architect/zh-cn/well-architected/guide/automated#流程设计)期间,确定与用户需要实时或近实时执行的操作相关的逻辑,以及哪些操作可以延迟到异步(异步)事务。有关设计同步/异步操作的更多注意事项,请参见[数据处理](/docs/architect/zh-cn/well-architected/guide/automated#数据处理)。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/automated#效率模式和反模式)列表显示了 Salesforce 自动化中正确(和糟糕)的操作逻辑。在构建之前,您可以使用这些来验证您的自动化设计,或者确定需要进一步优化的自动化。 要了解有关 Salesforce 提供的可帮助您规划规模的工具的更多信息,请参阅[相关工具 自动化](/docs/architect/zh-cn/well-architected/guide/automated#与自动化相关的工具)。 ### KPI 自动化 KPI 衡量自动化随时间的影响。如果没有它们,您将无法判断自动化是真正增加了业务价值还是为用户造成了意想不到的复杂性。您构建的每个自动化都应与一组清晰、可衡量的 KPI 相关联。 好的 KPI 由可评测值和相关的时间范围定义。示例包括: - 每月保存\[X 个数字]工作时间 - 处理手动数据输入失败的次数每周减少 \[Y%] 一旦有了清晰、可衡量的 KPI,您还必须了解 Salesforce 中的自动化是否以及如何生成与根据这些 KPI 进行报告相关的数据。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/automated#效率模式和反模式)列表显示了 Salesforce 自动化时正确(和差)的 KPI 是什么样子。您可以使用这些来验证您现有的 KPI,或者在构建之前确定您需要更好地识别 KPI 的地方。 要了解有关 Salesforce 工具的更多信息,以获得 KPI 帮助,请参阅[工具相关自动化](/docs/architect/zh-cn/well-architected/guide/automated#与自动化相关的工具)。 ### 效率模式和反模式 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/easy-efficiency)器中,发现更多提高效率的模式。
模式 反模式
流程设计 在您的组织中:
- 每个流服务于一个特定目的
- 每个步骤执行特定的精细任务
- 流以层次结构组织,包括主流和支持子流
- 所有用户输入在流中都有明确的目的
- 仅在无法使用现有系统数据时要求用户提供数据
在您的组织中:
- 流服务于多种目的,需要额外的输入来提供上下文
- 流需要不使用数据的输入
- 相关步骤组包含与其他流中的步骤组重叠的功能
- 流会在存储的数据可用于替代时请求用户输入
在 Apex 中:
- 每个类都服务于一个特定的目的
- 每种方法执行特定的精细任务
- 所有输入变量在类中都有明确的目的
- 代码执行需要最少的资源
在 Apex 中:
- 类具有多种用途
- 方法执行多个任务或方法执行的任务与其所属类的声明目的不一致
- 输入变量未在方法中实际使用
- 从数据库或外部系统检索不必要数据的方法
操作逻辑 在流中:
- 没有变量引用硬编码值(适用于记录类型、用户等)
- 所有自动启动的流和进程都使用决策和/或暂停元素来评估准入条件,并防止对大量数据执行无限循环或执行
- 在大数据量上下文中,流(包括进程)将逻辑移交给 Apex
- 子流用于需要在整个业务中重用的流程部分
在流中:
- 变量包含硬编码值
- 流(包括进程)必须在批量数据加载之前手动停用
- 流(包括进程)触发“未处理异常”通知
- 即使简单的流也会定期导致与调控器限制相关的错误
- 流的一部分在流之间重复,而不是使用子流
在 Apex 中:
- 没有变量引用硬编码值(适用于记录类型、用户等)
- 所有通配符条件都显示在 SOSL 中
- SOQL 使用 try-catch 封装
- 循环中未显示 SOQL
- SOQL 语句具有选择性,包括:
-- 不使用 LIKE 比较或部分文本比较
-- 比较运算符使用正逻辑(即 INCLUDES、IN)作为主要或唯一逻辑
-- 很少使用 = NULL、!= NULL 和/或始终跟在正比较运算符之后
-- 未显示 LIMIT 1 语句
-- 不使用 ALL ROWS 关键字
在 Apex 中:
- 变量包含硬编码值
- SOSL 很少或没有一致地用于通配符选择条件
- SOQL 未封装在 try-catch 中
- SOQL 显示在循环中
- SOQL 语句是非选择性的,包括:
-- 显示点赞和通配符筛选条件
-- 使用 NOT、NOT IN 条件的比较用作主要或唯一比较运算符
-- = NULL、!= NULL 条件用作主要或唯一比较运算符
-- 显示 LIMIT 1 个报表
-- 使用所有行关键字
在设计标准和文档中:
- 清晰概述自动化的计划和潜在执行路径
- 自动化中同步和异步操作的用例被清楚地概述为设计标准的一部分
在设计标准和文档中:
- 自动化调用未记录
- 同步和异步操作的用例未处理
KPI 在您的文档中:
- 每个自动化的输出都是可测量和有时限的
- 为每个 KPI 列出负责任的利益相关者
在您的文档中:
- 自动化没有 KPI,或者测量的时间范围不明确
- KPI 没有负责任的利益相关者
在报表和仪表板中:
- 与 KPI 相关的所有度量都包含在至少一个报表或仪表板中
在报表和仪表板中:
- KPI 报表不存在或报表缺少与一些 KPI 相关的度量
## 数据完整性 数据完整性是指系统如何维护准确和完整的数据。Salesforce 平台维护强大的[内置处理逻辑](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#数据库操作),旨在保护存储在单个组织的关系数据库中的数据的完整性。构建健康的自动化的一个基本要素是了解 Salesforce 的内置数据完整性行为,并确保您的所有自动化设计都符合(并确认)这些行为。 自动化设计中最大的反模式来自未能识别 [Salesforce 已经提供](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#数据库操作)的强大数据完整性服务,以及未能使用利用这些服务的[标准功能](/docs/architect/zh-cn/well-architected/guide/intentional#标准与自定义功能)。要设计保护和维护数据完整性的自动化,您必须熟悉 Salesforce 操作行为的基本顺序。 将数据完整性正确扩展到自定义自动化意味着您的系统可以: - 无需手动干预即可对批量和大量数据进行操作, - 在需要时强制执行用户安全策略,在需要时切换到系统上下文, - 在运行时遇到错误,并遵循可预测的恢复或故障路径。 通过适当的数据处理和错误处理,您可以在 Salesforce 自动化中构建更好的数据完整性。 ### 数据处理 在 Salesforce 中设计正确数据处理的第一步是了解多租户平台如何处理[事务](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#交易)。这包括了解 Salesforce Platform 用来确保记录级数据操作期间数据完整性的内置[执行](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)行为顺序。有关此行为影响的更多信息,请查看 Salesforce 架构基础中的[数据库操作](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#数据库操作)。 自动化中数据处理不佳可能是一些最难以识别和完全补救的反模式。平台执行顺序的递归性和重叠性会使人难以发现问题的根源。抛出致命错误或超出调控器限制的代码或流的特定部分可能不是基础数据处理问题的根本原因。 *事务感知*是构建自动化的关键,这些自动化可以通过 Salesforce 可靠和大规模地执行。这意味着确保自动化中的每个步骤在设计时都了解与平台控制[的执行顺序](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)相关的知识,能够正确执行其功能,并将信息正确传递给下一个步骤。 无论您使用的是哪种自动化工具,正确的事务意识都遵循类似的模式,并需要共同的注意事项: - 假设在任何给定时间,每个自动化都会被要求针对大量数据运行,恕不另行通知。自动化应具有允许批量或批量执行的路径(请参阅[可扩展性](/docs/architect/zh-cn/well-architected/guide/reliable#可扩展性))。 - 请勿在同一事务中混合使用系统和用户上下文数据操作。 - 为[*之前*的上下文](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm)保留同步数据操作,并为所有*之后*的上下文操作使用异步操作。 - 使用[消息和通知](/docs/architect/zh-cn/well-architected/guide/engaging#通知和消息),避免创建需要用户根据异步操作的结果等待数据的应用程序内体验。 除了事务意识之外,数据处理还有第二个维度:知道何时在不同[的执行上下文](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#执行上下文)中执行逻辑。将自动化分解为不同执行上下文的常见原因包括: - **大数据量和/或复杂数据操作** - [批量化操作](/docs/architect/zh-cn/well-architected/guide/automated#数据处理)不能保证自动化能够正确处理大量数据。如果自动化中的数据操作量将超过每个事务限制,您将需要使用特定于大数据量的功能进行数据操作(例如通过批量 Apex 或[批量 2.0 API](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm))。它们具有不同的事务限制,适合大数据量。 - 当批量执行时,需要在记录之间遍历复杂关系层次结构或执行复杂重新计算(不包括公式字段)的数据操作很容易超出每个事务的限制。请考虑,就完成系统中的后续操作所需的相关数据操作或 SOQL 而言,更新一个记录有多“吵”。 - 自动化整个链中涉及的 sObject 类型可能需要将数据操作拆分为单独的事务,以避免“[混合 DML](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm)”错误。 - **需要在用户或系统上下文中执行的逻辑** - Salesforce 平台在用户上下文中强制实施[共享和可见](/docs/architect/zh-cn/well-architected/guide/secure#共享和可见性)性。如果您需要执行超出自动化用户权限级别的操作,您必须确保这些操作在系统上下文中执行。 - 不同的工具将运行或不会运行在不同的上下文中: - 默认情况下,Apex 将在系统上下文中运行。通过在 Apex 类定义中使用[共享关键字](https://developer.salesforce.com/docs/atlas.en-us.238.0.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm?q=run%20as%20user),您可以控制 Apex 行为是否以及如何强制执行用户级共享规则。 - 流没有单一的默认行为。[根据流的启动](https://help.salesforce.com/s/articleView?id=sf.flow_distribute_context.htm&type=5)方式,流将在用户或系统上下文中运行。您可以选择在系统上下文中强制共享。 - 进程(即使用进程构建器构建的自动化)在系统上下文中运行,没有共享注意事项。(注意:我们建议使用流构建低代码自动化。 - **需要异步执行的逻辑** - 外部系统操作 - 访问外部数据的同步标注或操作不包括在任何平台回滚行为中。为了利用这些行为,您必须将涉及外部系统的操作放入单独的事务中(使用异步 [Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_async_overview.htm) 方法、[异步路径](https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_builder_asynchronous_path.htm&type=5&release=234)或[可调用操作](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_forcecom_flow_invocable_action_callout.htm))。 - 事件和消息传递 -- -- 要控制与数据操作相关的事件或消息的流(并利用平台回滚行为),请使用异步 Apex 方法将与消息传递或事件相关的所有操作放在[_上下文之后_](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm)。 下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/automated#数据完整性模式和反模式)列表显示了 Salesforce 自动化中正确(和糟糕)的数据处理。您可以在构建之前使用这些来验证您的自动化设计,或者确定需要重构的自动化来改进数据处理。 要了解有关 Salesforce 提供的自动化数据处理工具的更多信息,请参阅[自动化相关工具](/docs/architect/zh-cn/well-architected/guide/automated#与自动化相关的工具)。 ### 错误处理 错误处理对于数据完整性至关重要。强大的错误处理还有助于您的系统以更高的[弹性](/docs/architect/zh-cn/well-architected/guide/resilient)进行扩展和老化。 自动化中的错误处理不当会导致: - 记录不一致和其他数据完整性问题 - 向用户和其他系统发送不正确的通知 - 在手动或重复处理上浪费时间和资源 - 对系统总体缺乏 [Trust](/docs/architect/zh-cn/well-architected/guide/trusted-overview) 自动化中的错误处理需要使任何正在运行的进程能够解析错误以获取信息,访问关于后续步骤应该基于错误信息的逻辑,然后遵循正确的路径。这些功能不需要在每个自动化中重复构建(这是[优化反模式](/docs/architect/zh-cn/well-architected/guide/automated#流程设计) ) 。相反,系统中的每个自动化应能够连接到相关的错误处理[组件](/docs/architect/zh-cn/well-architected/guide/composable#松耦合)。 要在自动化中构建适当的错误处理控制,请提出以下问题: - 什么是“致命”错误? - 什么是“可恢复”错误? - 对于由用户操作触发的自动化,自动化如何在尝试提交更改之前捕获并通知用户错误? 在您决定如何处理这些错误后,您可以开始在自动化中建立有效的错误处理。以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/automated#数据完整性模式和反模式)列表显示了 Salesforce 自动化中正确(和差)错误处理的外观。您可以使用这些在构建之前验证您的自动化设计,或者确定需要重构的自动化,以改善错误处理。 要了解有关 Salesforce 错误处理可用工具的更多信息,请参阅[工具相关自动化](/docs/architect/zh-cn/well-architected/guide/automated#与自动化相关的工具)。 ### 数据完整性模式和反模式 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/easy-data-integrity)器中,发现更多数据完整性模式。
模式 反模式
数据处理 在您的数据字典中:
- 存在所有数据源和数据湖对象的字段级数据和优先级逻辑
- 存在从数据湖对象到数据模型对象的字段映射
在您的数据字典中:
- 不包括数据源和数据湖对象的字段级数据和优先级逻辑
- 不包括从数据湖对象到数据模型对象的字段映射
在 Apex 中:
- 所有同步 DML 语句或数据库类方法都在触发器执行上下文之前执行
- 异步 Apex 调用使用可排队项在事务之间“链接”复杂的 DML
- 批量 Apex 专用于大数据量
- @future Apex 未用于标注或系统对象 DML 或未谨慎使用
在 Apex 中:
- DML 语句定期出现在将在触发器上下文后调用的代码中
- 异步 Apex 很少使用
- 异步 Apex 功能被任意使用,包括:
-- 未来方法和可排队 Apex 使用不一致或互换
-- 数据库操作没有明确一致的逻辑来在需要时将执行传递给批处理 Apex
在流中:
- 在用户上下文中启动的所有流将所有系统上下文事务抽象到子流,这些子流一致放在暂停元素之后,以创建新事务
- 使用 Orchestrator 创建相关数据操作的复杂序列(而不是调用单个流中的多个子流)
- 所有记录触发的流都填充了触发顺序值
- 涉及外部系统标注或长时间运行的流程的流使用异步路径
在流中:
- 大型单片流尝试协调相关数据操作的复杂序列(带或不带子流)
- 记录触发的流根本不使用触发顺序属性,或者没有一致使用触发顺序值
- 异步路径的使用不一致或根本不一致
在您的组织中:
- 身份解析协调规则遵循数据字典中的优先级逻辑
在您的组织中:
- 身份解析协调规则不遵循数据字典中的优先级逻辑
错误处理 在 Apex 中:
- 代码包含 try- catch 块中的所有 DML、SOQL、标注和其他关键流程步骤
- 自定义异常用于创建高级错误消息和逻辑
- 在异步和批量上下文中,使用数据库类方法,而不是 DML
- 数据库类方法可以专用于所有数据操作(而不是 DML)
在 Apex 中:
- DML、SOQL、标注或其他关键流程步骤没有一致地封装在试用块中
- System.debug 语句出现在生产代码中(不会被注释掉)
- 不使用数据库类方法
- 数据操作仅通过 DML 完成
在 Lightning Web 组件中:
- JavaScript 将所有数据操作和关键流程步骤封装在 if ()/else if () 块中
- 所有 @wire 函数都使用 API 提供的数据和错误属性
- All if (error)/else if (error) 语句包含处理错误和提供信息性消息的逻辑
在 LWC 中:
- 如果 ()/如果 () 包含数据操作或关键流程步骤的块,JavaScript 不会一致使用
- @wire 函数不使用 API 提供的数据和错误属性(或没有一致使用)
- 如果使用,if (error)/else if (error) 语句实际上不包含处理错误和提供有用错误消息的逻辑
在 Aura 中:
- JavaScript 将所有数据操作和关键流程步骤封装在试用捕获块中
- 在 try-catch 块中,本地 JavaScript 错误在 throw 语句中使用(不使用 $A.error())
- 所有可恢复的错误逻辑都出现在 catch 语句中,并提供明确的用户消息
在 Aura 中:
- JavaScript 没有一致地将数据操作和关键流程步骤封装在尝试捕获块中
- 组件使用 $A.error()
- 可恢复的错误逻辑并不总是出现在 catch 语句中,并且对用户的错误消息不清楚
在流中:
- 屏幕流始终使用错误连接器向用户显示错误
- 为屏幕上显示的错误配置自定义错误消息
- 具有数据操作、标注和其他关键处理逻辑的流具有所有关键操作的错误路径
在流中:
- 流没有一致或根本不使用错误路径
- 未使用自定义错误消息,因此用户会看到默认“此流中发生未处理的错误”消息
## 业务价值 在自动化环境中,业务价值的概念是关于流程如何为业务利益相关者创造可衡量的积极影响。理想情况下,流程自动化使用户能够减少花费在重复、低价值任务上的时间。它还有助于通过消除可能导致错误的手动处理活动来提高数据完整性。与[流程设计](/docs/architect/zh-cn/well-architected/guide/automated#流程设计)非常相似,识别和交付将推动实际业务价值的自动化需要基本发现和业务分析之外的工作。 有时,向业务交付价值的最佳方式似乎是简单地自动化业务用户请求的每个流程,或者按照它们在待办事项(或售票队列)中出现的顺序,或者根据组织中的政治因素。这会导致两个相关的问题:以次优的顺序构建自动化和构建完全错误的自动化。第一个问题,即优先级不佳,阻碍了高价值流程在应该实施时的实施,从而有可能降低增长。第二个问题,构建错误的自动化,不仅延迟了高价值自动化的交付,还导致了时间浪费、不必要的成本,并增加了交付团队的挫折感。 通过关注 KPI 和优先级,您可以提供更大的业务价值。 ## 与自动化相关的工具
工具描述效率数据完整性业务价值
Apex 批处理将记录批处理在一起,并处理可管理的块XX
Apex 未来方法在后台异步执行 Apex 方法XX
Apex 队列 将 Apex 作业添加到队列并监视它们XX
Apex Scheduler在指定时间异步执行 Apex 类XX
批准指定批准记录所需的步骤XX
Asynchronous Apex异步运行 Apex 代码XX
自动操作在后台执行字段更新、电子邮件发送和其他操作XX
Einstein Next Best Action在正确的时间向正确的人显示正确的推荐XX
电子邮件提醒创建并发送自动电子邮件XX
升级操作指定对个案升级采取的自动操作XX
字段更新基于自动化更新字段值XX
流生成器使用指点单击式界面构建自动化XX
流扩展访问存储的变量作为流中的组件输入X
流模板库使用模板设计特定于行业的流XX
流触发器自动化复杂的业务流程X
可调用操作将 Apex 功能添加到流XX
编配员创建和管理多步骤自动化XX
出站消息从带有回执和重试的自动化流程发送信息 X
使用流发布平台事件通过用户交互和自动化发布事件X
查询优化器使用选择性和索引改善查询、报表和列表视图性能XX
Salesforce 流使用 Flow Builder 创建声明性流程自动化XX
使用流发送通知通过 SMS、WhatsApp 或 Facebook Messenger 发送消息XX
通过进程发送通知通过 SMS、WhatsApp 或 Facebook Messenger 发送消息XX
SOQL FOR UPDATE 修改器锁定记录,以防止竞赛条件和线程安全问题X
Strategy Builder确定要在记录页面上显示的推荐XX
子流通过重复使用降低流复杂性X
使用流订阅平台事件接收通过自动化发布的消息X
任务操作确定自动化为用户提供的分配详细信息X
## 与自动化相关的资源
资源描述效率数据完整性业务价值
Apex 执行调控器和限制了解 Apex 运行时引擎如何强制执行限制XX
批处理管理资源创建、管理、计划和监控批处理作业XX
SOQL 和 SOSL 的最佳实践 提高大数据量应用程序的查询性能X
设计标准模板为您的组织创建设计标准XXX
事务中的流批量化设计针对集合操作的流XX
流数据注意事项了解批处理数据的计划触发流XX
流调试测试流并进行故障排除X
如何处理请求了解 Salesforce 如何快速处理作业并最大限度地减少失败XX
KPI 电子表格模板确定特定度量的业务价值XX
从可调用操作对外部系统进行标注使用 Apex 从流调用外部系统X
混合 DML 操作了解哪些 sObject 可以在同一事务中一起用于 DMLXX
执行顺序了解插入、更新和更新插入的事件顺序XX
查询计划常见问题解答优化涉及大量数据的查询XX
计划触发的流注意事项了解计划触发的流的特殊行为X
交易控制生成指定当前数据库状态的保存点XX
当流失败时会发生什么?了解流中的错误处理XX
工作流自动化最佳实践指南Salesforce 自动化入门XXX
使用非常大的 SOQL 查询编写更高效的 SOQL 查询X
## 告诉我们您的想法 帮助我们保持 Salesforce 架构合理与您相关;参加我们的[调查](https://sfdc.co/bxNtvh),以提供有关此内容的反馈,并告诉我们您接下来想要看到的内容。 > 在[这里](/docs/architect/zh-cn/well-architected/guide/contributors)阅读我们的更新计划。 # 导言 **轻松**的 Salesforce 解决方案可快速交付价值。精心设计**简单**的解决方案是有意为之、自动化且引人入胜的。 **意图**性解决方案可以随着时间的推移立即提供业务价值。
**自动解决**方案使企业能够更快地大规模完成工作。
**吸引**解决方案会让用户高兴,并推动采用。
创建**简单**的架构会给架构师带来复杂的挑战。鉴于 Salesforce Platform 的灵活性和可用的[自动化工具](/docs/architect/zh-cn/well-architected/guide/automated#与自动化相关的工具)多种多样,实施细节在各个 Salesforce 组织之间可能会有很大差异。**简单**的架构可能需要更加智能(和困难)的权衡分析以及与利益相关者的对话。解决方案设计对程序员来说具有弹性和可靠性,但对组织管理员来说并不简单。这样的解决方案不会设计得那么**简单**。 要达成**轻松**的解决方案,您必须深入准确地了解业务优先级。您必须了解您的用户,包括他们的首选项、需求和他们工作的日常现实。您还必须了解交付和维护团队的技能(和技能差距)。您将需要通过不同的工具选项和设计模式进行迭代,以得出一个解决方案,该解决方案旨在给业务带来价值,同时便于交付和维护团队管理,更快地大规模地自动化工作,并真正吸引用户。 以下部分为**轻松**解决方案架构的核心注意事项提供了更深入的指导。 ## 轻松概览
意图
意图性解决方案会随着时间的推移立即提供业务价值。意图架构以战略性的方式规划和交付,可以有效维护,并且易于人类阅读和理解。
策略 可维护性 可读性
优先级
路线图
治理
标准与自定义
技术债务
设计标准
文档
自动
自动化解决方案使企业能够更快地大规模完成工作。健康的自动化减少了在重复的手动任务或复杂的数据输入上花费的时间。
效率 数据完整性
流程设计
操作逻辑
KPI
数据处理
错误处理
参与
吸引解决方案会使用户高兴,并推动采用。参与架构意味着创建直观、有帮助的用户体验。
简化 有用
应用程序复杂性
表格
外形规格
通知和消息传递
应用程序内指导
荣誉和奖励