--- schema_version: "1" id: 293bd7b541dedc6b986fc550ca3b7689337137599f5b2beb0515f136fad87a37 title: 卓越运营 - 自动化模式 collection: architect version: current locale: zh-cn portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/operational-excellence-automation-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/operational-excellence-automation-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 733fd97fff6d16d958baaddf7002092b45a3176d4ea74492308796b87e2be41f products: - 架构良好的框架 - Architect Site Content Repo --- # 卓越运营 - 自动化模式
了解有关架构良好的[卓越运营](/docs/architect/zh-cn/well-architected/guide/operational-excellence.html)的更多信息 → [自动化和效率](/docs/architect/zh-cn/well-architected/guide/operational-excellence.html#automation-and-efficiency) ## KPI 和度量 **模式** | 何处查看 | 好样的 | | --- | --- | | 平台 \| 仪表板 | ✅ 与 KPI 相关的所有度量都包含在至少一个仪表板中 | | 平台 \| 文档 | ✅ 每个自动化的输出都是可测量和有时限的 | | 平台 \| 文档 | ✅ 为每个 KPI 列出负责任的利益相关者 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 平台 \| 仪表板 | ⚏ KPI 报告不存在或仪表板缺少与一些 KPI 相关的度量 | | 平台 \| 文档 | 没有负责任的利益相关者, KPI 就会存在 | | 平台 \| 文档 | 自动化不存在 KPI，或者测量的时间范围不明确 | ## 声明自动化 **模式** | 何处查看 | 好样的 | | --- | --- | | 平台 \| 流 | ✅ Flow Builder 用于记录触发的自动化（替换进程构建器和工作流规则） | | 平台 \| 流 | ✅ 具有保存前执行的记录触发流用于创建记录前的字段群 | | 平台 \| 流 | ✅ 流处理决策逻辑、循环、API 标注、DML 操作和复杂的多步骤编排 | | 平台 \| 流 | ✅ 流事务控制用于在需要时提交中间更改 | | 平台 \| 流 | ✅ 实施错误处理，以在流中正常恢复错误 | | 平台 \| 流 | ✅ 反应性屏幕流提供动态用户体验 | | 平台 \| 流 | ✅ 当业务用户或管理员需要修改逻辑而无需开发人员参与时，选择声明性自动化 | | 平台 \| 流 | ✅ 变量不是指硬编码值（适用于记录类型、用户等） | | 平台 \| 流 | ✅ 在大数据量上下文中，流将逻辑切换到 Apex | | 平台 \| 流 | ✅ 子流用于需要在整个业务中重用的部分流程 | | 平台 \| 流 | ✅ 所有自动启动的流都使用决策和/或暂停元素来评估准入条件，并防止针对大数据量的无限循环或执行 | | 平台 \| 流 | ✅ 仅在现有系统数据无法使用时要求用户提供数据 | | 平台 \| 流 | ✅ 流以层次结构组织，包括主流和支持子流 | | 平台 \| 流 | ✅ 所有用户输入在流中都有明确的目的 | | 平台 \| 流 | ✅ 每个流服务于一个特定目的 | | 平台 \| 流 | ✅ 每个步骤执行特定的精细任务 | | 平台 \| 流 | ✅ 在用户上下文中启动的所有流将系统上下文事务抽象到子流，一致放在暂停元素之后，以创建新事务 | | 平台 \| 流 | ✅ 所有记录触发的流都填充了触发顺序值 | | 平台 \| 流 | ✅ 涉及外部系统标注或长时间运行的流程的流使用异步路径 | | 平台 \| 流 | ✅ 使用 Orchestrator 创建相关数据操作的复杂序列（而不是在单片流中调用多个子流） | | 平台 \| 验证 | ✅ 使用验证规则、重复规则和必填字段在平台级别强制执行数据完整性 | | 平台 \| 验证 | ✅ 验证规则防止保存前无效数据输入（比触发器验证更高效） | | 平台 \| 审批流程 | ✅ 多步骤批准路由处理委派批准人的并行和顺序批准路径 | | 平台 \| 审批流程 | ✅ 批准架构考虑异常情况（所有批准人休假，紧急业务需求绕过正常批准） | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 平台 \| 流 | 用于新自动化的流程生成器和工作流规则（流生成器是战略方向） | | 平台 \| 流 | 在业务用户或管理员需要修改逻辑而无需开发人员参与时使用的程序自动化 | | 平台 \| 流 | 流缺少错误处理，导致错误恢复不佳 | | 平台 \| 流 | 变量包含硬编码值 | | 平台 \| 流 | ⚏ 流必须在批量数据加载之前手动停用 | | 平台 \| 流 | 流的一部分在流之间重复，而不是使用子流 | | 平台 \| 流 | 流会触发“未处理异常”通知 | | 平台 \| 流 | ⚠ 即使简单的流也会定期导致与调控器限制相关的错误 | | 平台 \| 流 | ⚏ 流需要额外的输入来提供上下文 | | 平台 \| 流 | ⚠ 流服务于多种目的 | | 平台 \| 流 | 相关步骤组包含与其他流中的步骤组重叠的功能 | | 平台 \| 流 | 流会在存储的数据可用于替代时请求用户输入 | | 平台 \| 流 | 流需要不使用数据的输入 | | 平台 \| 流 | 使用从屏幕组件输出的集合执行 DML（在从屏幕组件输出集合时，在创建、更新或删除元素时，利用“使用记录或记录集合中的 ID 和所有字段值”设置） | | 平台 \| 流 | 记录触发的流根本不使用触发顺序属性，或者没有一致使用触发顺序值 | | 平台 \| 流 | 异步路径的使用不一致或根本不存在 | | 平台 \| 流 | 大型单片流尝试协调相关数据操作的复杂序列（带或不带子流） | | 平台 \| 审批流程 | 批准架构不考虑异常情况（所有批准人休假、紧急业务需求） | | 平台 \| 验证 | ⚏ 数据完整性仅在触发器中强制执行，而非验证规则（触发器验证效率更低，更复杂） | ## 编程自动化 **模式** | 何处查看 | 好样的 | | --- | --- | | 平台 \| Apex | ✅ 触发器处理器框架强制实施每个对象的单一触发器、批量化、关注分离和递归执行预防 | | 平台 \| Apex | ✅ 触发器处理器委派给业务逻辑的服务类，保持明确的关注分离 | | 平台 \| Apex | ✅ 触发器使用静态标记或专用递归控制类进行递归保护 | | 平台 \| Apex | ✅ Future Apex 谨慎使用，适用于标注或系统对象 DML | | 平台 \| Apex | ✅ 异步 Apex 调用使用可排队以在事务之间“链接”复杂的 DML | | 平台 \| Apex | ✅ 批量 Apex 用于大数据量（使用每个块的专用调控器限制处理大量数据） | | 平台 \| Apex | ✅ 批处理作业的错误处理记录失败的记录，而不会停止整个批处理执行 | | 平台 \| Apex | ✅ 批量 API 仅在必须处理大量数据时使用（本地 SOAP 和 REST API 可用于少量数据） | | 平台 \| Apex | ✅ Queueable Apex 用于复杂的工作流编排、具有重试逻辑的外部标注以及受益于异步限制的处理 | | 平台 \| Apex | ✅ Scheduled Apex 按固定计划执行夜间维护、每日报告、定期集成同步和基于时间的业务规则处理 | | 平台 \| 设计标准 | ✅ 自动化内部同步和异步操作的用例被清楚地概述为设计标准的一部分 | | 平台 \| 文档 | ✅ 清晰概述自动化的计划和潜在执行路径 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 平台 \| Apex | 一个对象上的多个触发器，执行顺序不可预测，逻辑重叠 | | 平台 \| Apex | 直接嵌入触发器文件的业务逻辑使测试变得困难 | | 平台 \| Apex | ⚠ 没有触发器处理程序框架或对象之间的触发器模式不一致 | | 平台 \| Apex | 批处理 Apex 作业的范围大小非常小（例如，范围大小 = 1） | | 平台 \| Apex | 用于外部标注的批处理 Apex（使用批处理 Apex 将大量 Salesforce 数据推送到外部系统） | | 平台 \| Apex | 任意使用的异步 Apex 功能（未来方法和可排队 Apex 使用不一致或互换） | | 平台 \| Apex | 异步 Apex 很少使用 | | 平台 \| Apex | 数据库操作没有明确一致的逻辑来在需要时将执行传递给 Batch Apex | | 平台 \| 设计标准 | 未解决同步和异步操作的用例 | | 平台 \| 文档 | 自动化调用未记录 | ## 平台事件 **模式** | 何处查看 | 好样的 | | --- | --- | | 平台 \| 平台事件 | ✅ 平台事件用于事件驱动的自动化，将发布者与订阅者分离 | | 平台 \| 平台事件 | ✅ 发布者不知道订阅者并发布火与忘了 | | 平台 \| 平台事件 | ✅ 多个订阅者通过平台事件触发的流、Apex 触发器或外部集成对事件做出独立反应 | | 平台 \| 平台事件 | ✅ 重放 ID 用于从 72 小时保留时段中的任何时间点重放错过的事件 | | 平台 \| 平台事件 | ✅ 平台事件支持跨组织通信、外部系统通知和内部工作流编排 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 平台 \| 平台事件 | 发布者和订阅者之间的直接耦合阻止了可组合自动化 | | 平台 \| 平台事件 | ⚏ 客户层升级直接在一个事务中调用业务机会更新、客户团队通知和数据仓库同步（每次需要新的下游处理时，紧耦合都需要更改客户逻辑） | | 平台 \| Apex | ⚠ 立即发布使用的临时平台事件（无论发布订单要求或记录锁定风险如何，都使用实时事件，而不是提交后发布） | ## Apex 开发标准 **模式** | 何处查看 | 好样的 | | --- | --- | | 平台 \| Apex | ✅ SOQL 语句使用正逻辑比较运算符（`INCLUDES`、`IN`）作为主要或唯一逻辑 | | 平台 \| Apex | ✅ SOQL 避免在正比较运算符后`= NULL`、`!= NULL`或谨慎使用它们 | | 平台 \| Apex | ✅ SOQL 不使用 `LIMIT 1` 语句 | | 平台 \| Apex | ✅ SOQL 不使用 `ALL ROWS` 关键字 | | 平台 \| Apex | ✅ SOQL 不会出现在循环中 | | 平台 \| Apex | ✅ 通配符条件显示在 SOSL（非 SOQL）中 | | 平台 \| Apex | ✅ SOQL 语句避免`LIKE`比较或部分文本比较 | | 平台 \| Apex | ✅ SOQL 封装在`try-catch`块中 | | 平台 \| Apex | ✅ 变量不是指硬编码值（适用于记录类型、用户等） | | 平台 \| Apex | ✅ 每个类都服务于一个特定的目的 | | 平台 \| Apex | ✅ 每种方法执行特定的精细任务 | | 平台 \| Apex | ✅ 所有输入变量在类中都有明确的目的 | | 平台 \| Apex | ✅ 代码执行需要最少的资源 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 平台 \| Apex | SOQL 语句使用 `NOT`、`NOT IN` 条件作为主要或唯一比较运算符（非选择性） | | 平台 \| Apex | ⚏ SOQL 语句使用 `ALL ROWS` 关键字（非选择性） | | 平台 \| Apex | SOQL 语句使用 `= NULL`、`!= NULL` 条件作为主要或唯一比较运算符（非选择性） | | 平台 \| Apex | 变量包含硬编码值 | | 平台 \| Apex | ⚏ SOQL 显示在循环中 | | 平台 \| Apex | ⚏ SOQL 语句经常使用`LIKE`和通配符筛选条件（非选择性） | | 平台 \| Apex | ⚏ SOQL 未封装在`try-catch`块中 | | 平台 \| Apex | ⚏ SOQL 语句使用 `LIMIT 1`（非选择性） | | 平台 \| Apex | ⚏ SOSL 很少或没有一致地用于通配符选择条件 | | 平台 \| Apex | 类具有多种用途 | | 平台 \| Apex | 方法执行多个任务，或方法执行的任务与其所属类的声明目的不一致 | | 平台 \| Apex | 输入变量未在方法中实际使用 | | 平台 \| Apex | 方法从数据库或外部系统检索不必要的数据 | ## 错误处理 **模式** | 何处查看 | 好样的 | | --- | --- | | 平台 \| Apex | ✅ 自定义异常用于创建高级错误消息和逻辑 | | 平台 \| Apex | ✅ 代码将所有 DML、SOQL、标注和其他关键流程步骤封装在`try-catch`块中 | | 平台 \| Apex | ✅ 数据库类方法可以专用于所有数据操作（而不是 DML） | | 平台 \| Apex | ✅ 在异步和批量上下文中，使用数据库类方法，而不是 DML | | 平台 \| Aura | ✅ JavaScript 将所有数据操作和关键流程步骤封装在`try-catch`块中 | | 平台 \| Aura | ✅ 在`try-catch`块中，本地 JavaScript `Error` 用于 throw 语句（不使用 `$A.error()`） | | 平台 \| Aura | ✅ 所有可恢复的错误逻辑都出现在 `catch` 语句中，并提供明确的用户消息 | | 平台 \| 流 | ✅ 具有数据操作、标注和其他关键处理逻辑的流具有所有关键操作的错误路径 | | 平台 \| 流 | ✅ 屏幕流始终使用错误连接器向用户显示错误 | | 平台 \| 流 | ✅ 为屏幕上显示的错误配置自定义错误消息 | | 平台 \| Lightning Web 组件 (LWC) | ✅ JavaScript 将所有数据操作和关键流程步骤封装在 `if ()`/`else if ()` 块中 | | 平台 \| Lightning Web 组件 (LWC) | ✅ 所有`@wire`函数使用 API 提供的`data`和`error`属性 | | 平台 \| Lightning Web 组件 (LWC) | ✅ 所有 `if (error)`/`else if (error)` 语句都包含处理错误和提供信息性消息的逻辑 | **反模式** | 何处查看 | 什么不好的样子 | | --- | --- | | 平台 \| Apex | DML、SOQL、标注或其他重要流程步骤未一致封装在 Try-Catch 块中 | | 平台 \| Apex | 不使用数据库类方法 | | 平台 \| Apex | ⚏ 数据操作仅通过 DML 完成 | | 平台 \| Apex | `System.debug` 语句出现在生产代码中（不会被注释掉） | | 平台 \| Aura | JavaScript 没有一致地将数据操作和关键流程步骤封装在`try-catch`块中 | | 平台 \| Aura | 组件使用 `$A.error()` | | 平台 \| Aura | 可恢复的错误逻辑并不总是出现在 `catch` 语句中，并且对用户的错误消息不清楚 | | 平台 \| 流 | ⚏ 流不会一致或根本不使用错误路径 | | 平台 \| 流 | 未使用自定义错误消息，因此用户会看到默认“此流中发生未处理的错误”消息 | | 平台 \| Lightning Web 组件 (LWC) | `@wire` 函数不使用 API 提供的`data`和`error`属性（或没有一致使用） | | 平台 \| Lightning Web 组件 (LWC) | `if (error)`/`else if (error)` 语句如果使用，实际上不包含处理错误和提供有用错误消息的逻辑 | | 平台 \| Lightning Web 组件 (LWC) | JavaScript 没有一致使用带有数据操作或关键流程步骤的 `if ()`/`else if ()` 块 |