卓越运营

出色的 Salesforce 解决方案不是一次性构建的，而是不断优化的。通过监控解决方案的性能并改进其工作方式，将卓越运营嵌入您的系统，以便以可预测的方式提供业务价值，并在出现故障时快速恢复。

忽视卓越运营会对解决方案产生可预测的后果。手动部署流程成为瓶颈，减慢功能交付并增加错误风险。监控不足会延迟事件检测，直到用户报告问题，延长影响持续时间并削弱 Trust。缺少自动化需要运营团队随着解决方案的复杂性成比例地增长，从而产生不可持续的成本轨迹。监控不力的批处理作业如果失败，可能会在任何人发现之前损坏数据或下游流程。

专为卓越运营设计的解决方案使团队能够通过全面的监控来观察系统行为，使用自动化漏斗安全地部署更改，通过预定义的程序有效地响应事件，并通过无懈可击的审查从运营经验中学习。这些功能会随着时间的推移而复合。与将运营问题推迟到生产问题迫使进行反应性投资的团队相比，早期投资于运营基础的团队更快、更可靠地提供功能。

卓越运营直接连接到其他架构支柱。可靠性取决于检测故障的监控和实现快速恢复的自动化。Trust 需要安全的开发生命周期做法和业务变化的审计跟踪。资源优化受益于运营遥测提供的持续改进。成本优化需要部署效率和自动化，以防止运营成本增长。这些支柱共同创建了解决方案，通过可持续的运营投资提供持续的业务价值。

Salesforce 操作基础设施 — 服务器、数据库、运行时和网络。您操作的是构建在它之上的一切 — 定义解决方案的元数据、管理其行为的配置、流过它的数据、连接它的集成以及在其中操作的客服人员。

这种责任分工决定了您的每个运营决策。虽然 Salesforce 确保平台可用、高性能和安全，但您必须设计可观察、可部署、可自动化和可恢复的解决方案。该平台的多租户架构意味着您的解决方案中的操作问题可能会触发调控器限制，导致单个事务失败，并导致行锁定或资源竞争在您的组织中级联。您无法在事后专注于可观察性、部署安全性或事件准备，而无需额外努力或返工。

在本指南中，您将了解如何设计和实施操作实践（监控、部署自动化、事件响应和持续改进），将 Salesforce 解决方案转化为可靠、可持续的系统。

使用这些原则来指导您在平台上实现卓越运营的架构决策。

• **随着可观察性的发展。**从初始版本设计全面的可观察性，而不是在出现问题后被动地重新配置仪器。可观察系统揭示了它们在真实条件下的实际行为方式，实现了数据驱动的架构改进和快速问题诊断。可观察性是一个架构问题，它从一开始就决定了解决方案的设计 — 仪器、监控和遥测收集决策会影响数据模型、集成模式和组件边界。

• **标准化操作程序。**源代码控制中的版本配置和操作程序，以及应用程序代码。编码操作支持自动 Salesforce DX 部署、Sandbox 刷新自动化和元数据部署，可在环境中一致执行。有关组织配置的部落 Knowledge 会转换为任何团队成员都可以运行的可执行脚本。当过程在版本控制中运行时，它们通过与应用功能相同的审查和改进周期来演变，从而创建可重复的操作模式，从而显著减少配置偏差。实施卓越中心。

• **拥抱 DevOps 文化。**打破开发、运营和业务团队之间的组织孤岛。对解决方案结果的共同责任取代了将工作扔到墙外。DevOps 文化减少了摩擦，加快了反馈循环，并建立了运营影响的责任。架构师通过支持协作的技术选择和通过消除分担责任的结构性障碍的组织宣传来支持 DevOps。

• **自动化提高效率。**自动化重复的操作任务，以消除手动工作，减少人为错误，并使操作能够扩展，同时优化成本和资源使用。频繁重复的手动操作是自动化的理想选择。通过节省的小时数、减少的错误和创建的运营容量来衡量自动化价值。

• **从所有运营事件中学习。**从事件、性能异常、濒临缺失和成功操作中提取组织经验。无怨无悔的尸检侧重于系统改进，而不是个人错误，为诚实评估创造心理安全。操作遥测揭示了各种事件的模式，从而实现了主动预防。学习文化将运营经验转化为随着时间的推移而复合的组织能力。

了解 Salesforce 的操作有助于您将操作设计工作集中在您控制的内容上。该平台处理传统 IT 环境中需要专职团队的基础架构问题：

• **基础架构的可靠性和性能：**Salesforce 在所有实例中监控和维护服务器容量、数据库性能、网络可用性和存储系统。平台状态显示在 status.salesforce.com 中，并带有实时事件更新和计划维护时段。
• **平台更新和补丁：**每年 3 个主要版本（春季、夏季、冬季）会提供新的功能、安全补丁和性能改进。Salesforce 管理发布时间、API 版本支持和弃用，以及平台级更改的更改管理。在生产部署之前，您可以根据 Sandbox 环境中的版本测试解决方案。
• **多租户资源管理：**存在调控器限制是为了保持共享基础设施的公平性 — 由于您与其他客户在相同的资源上运行，Salesforce 会对 CPU 时间、堆大小、Salesforce 对象查询语言 (SOQL) 查询、数据操纵语言 (DML) 语句和 API 调用等事项实施限制，因此任何租户都不会过度消耗容量。虽然 Salesforce 会跟踪整体使用情况，并让客户通过许可层请求对某些限制（例如 API 调用）进行更高的分配，但每个事务的 Apex 调控器限制本身是固定的，并以相同的方式对每个人强制执行。
• **核心平台安全操作：**Salesforce 安全团队监控威胁，管理漏洞披露和补丁，维护安全认证，并响应平台级安全事件。这种基础安全性创建了基准，您可以在此基础上构建特定于解决方案的安全控制。
• **灾难恢复和业务连续性：**Salesforce 维护地理位置分散的数据中心，测试灾难恢复程序，并维护无需客户操作即可实现故障切换的冗余系统。在基础架构故障期间，平台级恢复可以透明地进行。

这些平台操作为您构建奠定了基础。您无需为基础设施配置服务器、修补数据库或设计灾难恢复。但您仍应对在此基础之上构建和配置的一切内容负责。

共享责任模型意味着您在 Salesforce 中创建的一切内容都拥有卓越的运营。平台操作支持您的工作，但不会替换它。您的运营责任跨越五个相互关联的领域：

可观察性是从外部输出理解内部系统状态的能力。可观察的 Salesforce 解决方案使操作员能够回答有关系统行为的问题、诊断故障和验证假设，而无需为每个调查部署新的仪器。监控（使用预定义的仪表板回答已知问题）和可观察性（使用全面的遥测回答任意问题）之间的区别非常重要，因为生产系统会产生超出您在设计期间预期的意外行为。

对于 Salesforce 解决方案，可观察性跨越适应平台多租户模型的三种互补信号类型：

• 日志 - 使用完整上下文信息捕获离散事件。Event Monitoring 提供捕获 API 调用、登录事件、Apex 执行、SOQL 查询、Visualforce 页面、Lightning 页面的事件日志文件，以及包含用户身份、时间戳、持续时间和结果的请求上下文的报表运行。日志会回答以下问题：“哪些用户遇到此错误？”和“成功执行和失败执行之间发生了什么变化？”
• 度量 - 随时间汇总的数字度量，揭示趋势和模式。度量包括 API 消耗率、Apex CPU 时间分布、批量作业成功率、集成延迟百分比和用户流完成率。度量回答了“性能是否会随时间下降？”和“我们是否接近调控器限制？”等问题。
• 跟踪 - 显示通过分布式系统的请求路径，揭示延迟源和故障点。对于 Salesforce 解决方案，跟踪可以将同步 API 调用连接到异步处理链，将平台事件连接到订阅者执行，并将集成请求连接到外部系统响应。跟踪回答了“此流中的延迟累积在哪里？”和“此多步骤流程中哪个组件失败？”等问题。

从初始架构设计可观察性。关于要启用哪些 Event Monitoring 事件类型的决策、如何构建平台事件负载以实现操作可见性、在哪里放置集成检查点以及要实施哪些自定义日志记录，所有这些都决定了解决方案的长期可操作性。将可观察性改造到现有解决方案需要更改涉及大多数组件的仪器，并存在在操作改进过程中引入错误的风险。

Salesforce 提供了专门构建的监控功能，架构师从一开始就应该围绕这些功能进行设计。

Event Monitoring 会捕获整个组织的详细运营数据。事件类型包括 API 使用情况、登录活动、注销事件、Apex 执行、SOQL 查询、Visualforce 页面加载、Lightning 页面视图、报表运行、文档附件、内容转移和您定义的自定义事件。Event Monitoring 为安全分析、性能优化、容量规划和合规报告提供了基础。

为生产环境启用 Event Monitoring，并建立事件日志文件到外部聚合平台的自动导出。对于大多数事件类型，本地保留是有限的，不足以满足趋势分析、容量规划和合规性要求。外部聚合支持历史分析、与其他系统的企业遥测关联、高级分析和符合监管要求的保留期。

Proactive Monitoring不断评估贵组织的性能和可扩展性风险,在预定义信号成为用户可见的事件之前发出警报。Proactive Monitoring 检测的模式包括接近每日分配的 API 请求限制峰值、指示共享资源竞争的并发 Apex 执行失败、接近调控器阈值的 SOQL 行限制以及建议设计改进的行锁定竞争。

Proactive Monitoring 使用一组预定义的警告和警报阈值，由 Salesforce 管理。对于需要更深入的性能可见性并想要调查基准和趋势的组织，Scale Center 提供了详细的运行时分析，包括 CPU 超时、并发和行锁定、调控器限制错误和数据库性能。

数据检测(需要 Salesforce Shield)扫描标准和自定义对象字段,以识别、分类和补救文本、富文本和加密字段中的敏感数据,例如个人身份信息。它使用带有模式匹配和自定义正则表达式的本地平台处理来最小化误报。运行针对新记录或修改记录的重复扫描（每周或每月），已分类或已弃用的字段除外。

使用调查结果推动下游治理，以更新合规分类、强制执行 Shield Platform Encryption、触发 Event Monitoring 安全策略或应用 Sandbox 数据屏蔽。

规模中心提供了对长期运行操作、吞吐量模式、异常热点和调控器限制消耗的事务级可见性。规模中心揭示了哪些操作消耗了最多的资源，哪些事务接近超时阈值，以及优化投资将在哪些方面产生最大的运营影响。

在解决方案稳定期间建立规模中心基准，并在每个主发布版本后重新访问基准。没有上下文的表现很难解释。基准比较揭示了更改是提高了性能还是降低了性能，从而指导了进一步的优化决策。

• **设置审计跟踪：**跟踪配置更改，包括权限修改、元数据部署、管理操作和安全设置更新，本地保留最多 180 天。设置审计跟踪通过揭示谁在何时更改了什么配置，来支持安全调查、合规性验证和事件事后分析。当合规性或合同要求需要更长的历史窗口时，导出设置审计跟踪条目，以便保留 180 天以上。
• 字段审计跟踪:(需要 Salesforce Shield)跟踪历史字段值的变化。对于包含敏感数据、需要变更历史的受管数据或关键业务数据的字段，有选择地启用字段审计跟踪，了解历史值有助于运营和合规报告。
• **运行状况检查:**提供自动安全配置评估，将当前设置与 Salesforce 安全基准建议进行比较。根据环境的风险优先级，安排季度健康检查审查和补救发现。如果您有补偿控制或与默认建议不同的风险容忍度，并非所有发现都需要补救，但每个发现都值得仔细审查。

平台监控揭示了组织级别的运行状况，但忽略了特定于应用程序的问题。通过检测关键业务流程，从用户角度监控应用程序运行状况：

根据业务影响定义关键用户流程，并监控端到端成功率、完成时间、放弃点和错误率。关键流通常包括创收活动（订单提交、合同执行、业务机会完结）、高用量活动（用户登录、搜索操作、记录创建）和合规要求的活动（同意捕获、数据主体权利履行、审计敏感的工作流）。

带有重大事件标记的仪器流程，指示每个重要步骤的开始、完成、放弃和失败。在流成功率低于可接受阈值或持续时间超过延迟目标时发出警报。进程级监控揭示了组件级监控中不可见的问题，因为涉及多个 Apex 类、几个流、三个平台事件和两个外部集成的用户旅程可能会在任何过渡点失败。

双向监控集成运行状况。跟踪对外部系统的出站调用，以了解成功率、延迟、重试模式和错误类型。跟踪来自外部系统的入站呼叫，以了解数量模式、身份验证失败、数据验证错误和处理持续时间。集成监控通常会在操作员发现外部系统问题之前发现它们，从而实现主动升级。

与外部合作伙伴建立集成 SLA，并根据承诺的目标监控实际绩效。当发生违反服务级别协议 (SLA) 的情况时，遥测会区分问题是来自 Salesforce、集成层、网络路径还是外部系统。在事件升级和合同谈判中，这种区分很重要。

服务级别指标 (SLI) 是精心选择的指标，代表用户感知的质量。服务级别目标 (SLO) 是平衡用户期望与运营投资的 SLI 的目标值。对于 Salesforce 解决方案，有效 SLI 包括：

• **可用性：**解决方案成功响应用户请求的时间百分比。从用户角度衡量可用性，而不是基础设施角度。平台可用，但由于单点登录 (SSO) 配置错误，用户无法登录的解决方案不可用，无论平台正常运行时间如何。
• **延迟：**从用户操作启动到可见响应的时间。以特定百分比（p50、p90、p99）定义延迟目标，而不是平均值，因为平均值会掩盖最慢的请求所遭受的可怕体验。p99 延迟为 8 秒意味着 100 个请求中就有 1 个需要 8 秒以上，这可能代表在高流量解决方案中每天有数千次不良体验。
• **成功率：**没有用户可见的错误而完成的操作的百分比。区分用户引起的错误（无效输入、权限不足）和系统引起的错误（调控器限制失败、集成超时、未处理的异常）。只有系统导致的错误才会计入成功率 SLO。
• **吞吐量：**每个时间单位完成的操作量。批处理、数据导入、计划作业和批量操作的吞吐量事项，其中是否满足业务期限取决于处理能力。

根据用户要求而不是技术能力设置 SLO。问题不是“我们能做到多快？”，而是“用户必须做到多快才能实现目标？”如果用户能够容忍两秒钟，200ms 的页面加载目标毫无意义。相反，如果用户在 500 毫秒后放弃，2 秒的目标毫无意义。用户研究、会话分析和业务需求为现实的 SLO 目标提供信息。

监控 SLI 燃烧率，以检测累积的 SLO 违反排放错误预算的时间。错误预算代表可接受的失败率，它平衡了用户体验和运营投资。当烧毁率超过可持续水平时，停止功能工作，并专注于可靠性改进，直到 SLO 恢复。这一纪律防止了团队在追求功能截止日期的同时忽视可靠性下降的常见模式，直到灾难性故障迫使做出应急响应。

当自动化系统检测到需要人为判断或操作的问题时，警报会通知人类。有效的警报平衡了覆盖范围（检测真正的问题）与精确度（避免误报）。不良警报会错过事件（警报太少，阈值太高），或造成警报疲劳（警报太多，阈值太低），操作员会学会忽略通知。

围绕可操作性设计提醒。每个警报应回答三个问题：

1. 有什么问题？
2. 为什么重要？
3. 我该怎么办？

缺少明确答案的警报会训练操作员忽略它们。例如，一条警告称“API 调用超过限制的 80%”，而没有关于哪个 API、哪个集成或要采取什么操作的上下文来提供响应的不足信息。

实施与操作升级程序匹配的警报严重级别：

• **重要警报：**指示面向用户的服务降级，需要立即响应，而不论何时。重要提醒页面呼叫工程师。示例包括登录失败超过设置阈值、创收流低于可用性 SLO 或数据丢失检测。
• **警告提醒：**指示在没有干预的情况下将变得至关重要但还不会影响用户的问题。警告会为工作时间调查生成票证。示例包括 API 消耗趋于每日限制、批量作业完成但缺少 SLA 目标，或集成错误增加但仍低于失败阈值。
• **信息提醒:**无需采取行动即可了解运营变化。信息提醒会显示在监控仪表板中，但不生成通知。示例包括成功部署、计划维护完成或配置更改。

建立警报审查节奏，以评估警报质量并根据实际事件模式调整阈值。跟踪警报度量，包括真阳性率（表示实际问题的警报）、假阳性率（不存在问题的警报）和解决时间（警报导致事件解决的速度）。假阳性率高表明阈值过于敏感，需要调整才能恢复操作员 Trust。

DevOps 文化将开发和运营责任整合到统一团队中，这些团队拥有从初始代码提交到生产运营的解决方案结果。与传统的孤立组织相比，DevOps 实现了更快的交付、更高的质量和更好的运营结果，在这些组织中，开发人员将工作移交给了缺乏有效运行上下文的运营团队。

源驱动的开发将所有解决方案工件（元数据、配置、代码、文档）视为版本控制的源文件，而不是仅存在于组织中的点击式设置。源控制支持可重复构建、协作开发、变更跟踪和自动部署漏斗。

Salesforce DX 为源驱动的开发提供了工具链。元数据 API 将组织配置公开为 XML 文件。临时组织提供从源代码控制创建的一次性开发环境。CLI 工具支持脚本部署和组织操纵。版本控制系统（包括 Git）会跟踪更改并启用协作工作流。

有意构建元数据，以实现团队协作。模块化软件包结构允许团队独立工作，而不会合并冲突。将共享组件（页面布局、权限集和自定义字段）与特定于功能的组件（Apex 类、流和 Lightning 组件）分开。明确的所有权边界可以防止每个人改变一切的混乱。

在更改进入生产环境之前，代码审查提供了质量控制、Knowledge 共享和学习机会。有效的代码审查平衡了彻底性和速度，在不成为部署瓶颈的情况下提供了有意义的反馈。

建立明确的审查标准。审查者检查：

• 正确性 - 代码是否如其声明的那样？
• 可维护性 - 未来的开发人员能否理解和修改这一点？
• 性能 - 此方法是否适当扩展？
• 安全性 - 是否存在注入风险或权限绕过？
• 一致性 - 这是否匹配项目模式和标准？

没有明确的标准，审查就会变得主观或肤浅。

对于生产绑定的更改，需要两次批准。单一审查者批准会创建 Knowledge 孤岛，并错过其他视角可能发现的问题。双重审查者要求分发 Knowledge，将总线因素保持在 1 以上，并发现更多缺陷。平衡批准要求与团队规模 — 在五人团队中需要三个批准会产生瓶颈。

保持拉取请求 (PR) 较小。包含数百行更改的 PR 会接受粗略的审核，因为审核者面临着巨大的认知负荷。对于在 200-400 行中更改一个功能的 PR，将进行彻底审查，并发现微妙的问题。将大型功能分为可审查的块，以增量方式交付。

自动化机械检查。代码格式化、命名约定合规性、测试覆盖率要求和静态分析检查应该自动运行，而不是消耗评审人员的注意力。评审人员应关注需要人为判断的逻辑、设计和可维护性问题。

测试提供了解决方案正常工作的信心，并随着更改的累积继续工作。有效测试平衡了覆盖率（代码和功能测试的工作量）与执行速度（测试套件完成的速度）和维护负担（维护测试需要的工作量）。

• **单元测试：**隔离验证单个组件。Apex 单元测试独立于现有组织数据和外部依赖性来验证方法和类。Lightning Web 组件测试在没有后端 API 的情况下验证组件逻辑和渲染。设计良好的单元测试可在数秒内执行，并在开发过程中提供即时反馈。目标为仅单元测试的最低要求代码覆盖率高于 75%，将覆盖率视为下限而不是上限。
• **集成测试：**验证组件之间的交互。集成测试练习实际的数据库操作、对模拟外部系统的真实标注和真实的调控器限制行为。集成测试捕获单元测试错过的假设 — 意外数据状态、权限问题、批量操作限制和触发订单依赖性。集成测试以每次测试的秒到分钟为单位执行。
• **端到端 (E2E) 测试:**验证从登录到任务完成的完整用户旅程。E2E 测试在完全 Sandbox 环境中运行，练习 UI 交互、后端流程、异步操作和集成接触点。E2E 测试发现仅在整个系统运行时出现的问题 — 竞赛条件、意外的用户工作流、环境配置问题。对于综合套件，E2E 测试的执行时间从几分钟到几小时不等。
• **性能测试:**验证加载下的解决方案行为。性能测试衡量响应时间、吞吐量、资源消耗和调控器限制在实际流量模式下的邻近性。性能测试会阻止发布降低性能的更改，在生产前捕获 N+1 个查询模式，并在高峰季节前验证容量剩余空间。性能测试需要类似生产的数据量，并在专用测试环境中运行。

实施测试棱锥策略：许多快速单元测试、更少的集成测试、选择性 E2E 测试以及在负载下单独验证的性能测试。这种平衡支持快速迭代（快速单元测试提供即时反馈），同时确保集成点正常工作（集成测试发现跨组件问题），用户体验仍然可以接受（E2E 测试验证完整的过程）。

在 CI 漏斗中自动化测试执行。不要在提交前手动运行测试套件，而是让 CI 在每次提交前自动运行测试套件。自动测试会立即发现回归，一致地执行质量标准，并防止在截止日期压力期间手动测试成为可选时出现的逐渐质量下降。

持续集成 (CI) 和持续部署 (CD) 漏斗自动化了从代码提交到生产部署的路径。CI/CD 减少了人为错误，加快了反馈，提供了一致的质量检查，并实现了快速发布节奏。

• 持续集成会自动构建、测试和验证每个代码提交。当开发人员将提交推送到版本控制时，CI 系统会拆分新的组织，部署更改，运行自动测试套件，执行静态代码分析，检查测试覆盖率要求，并在几分钟内报告结果。快速反馈使开发人员能够在上下文更新时修复问题，而不是几天后在手动集成测试期间发现问题。

在允许合并到主分支之前，需要 CI 成功。这种纪律（通常称为“保护主要”）防止损坏的代码在共享分支中累积，从而阻止其他开发人员。具有 CI 网关的受保护分支使主分支始终可以部署，从而支持按需发布，而不是当主发生工作时发布。

• 连续部署会自动将经过验证的更改通过环境部署到生产环境。在 CI 验证隔离环境中的更改后，CD 漏斗会部署到集成 Sandbox，运行其他测试，部署到暂存，运行最终验证，还可以自动或手动批准后部署到生产。

在生产部署期间实施限制爆破半径的渐进式部署策略：

• 蓝绿色部署: 维护两个相同的生产环境。当绿色环境收到新部署时，流量会路由到蓝色环境。验证后，流量会切换到绿色环境。蓝色环境仍作为即时回滚目标运行。
• **金丝雀部署：**在完全部署前，将更改发布到小用户子集。初始金丝雀接收一小部分流量，同时监控错误率、延迟和用户行为。成功的金丝雀会逐渐扩展（例如，从 5% 扩展到 25%，然后是 50%，最后是 100%）。在金丝雀部署期间检测到的问题会在影响所有用户之前中止发布。金丝雀部署非常适合具有外部路由层或功能标记的 Salesforce 解决方案，这些层或标记支持选择性功能公开。
• **功能标记：**启用独立于部署时间的运行时功能可见性控制。新功能会部署到生产环境，但在明确启用前仍隐藏在标记后。通过切换标记，而不是部署代码，功能标记支持金丝雀部署、A/B 测试、逐步推出和即时回滚。

备注:通过资源分配和流量分配控制，金丝雀和蓝绿色部署模式适用于托管在 Heroku 上的自定义应用程序，或部署在 CloudHub 2.0 上的 MuleSoft 应用程序。核心 Salesforce 平台元数据部署是“全有或全无”事务。

基础设施即代码 (IaC) 将环境的定义（组织形状、元数据、依赖性以及使其正常运行的配置和种子数据）视为版本控制的源，而不是在每个组织中手动进行的设置。在 Salesforce 中，没有服务器要配置，因此 IaC 控制环境的组装方式，而不是环境下方的硬件。编码的环境是可复制的、可比较的和可丢弃的，这正是避免它们漂移的原因。

环境从源配置定义，而不是手动配置。临时组织定义文件指定了版本、启用的功能和设置，因此任何人或漏斗都可以按需启动相同的一次性组织。Sandbox 采用不同的路径：从为复制类型和模板命名的定义中配置它们，然后从它们复制的生产组织中继承配置，为集成和暂存提供更高的保真度环境。软件包定义声明解决方案的组件和依赖性，使构建可从源复制，而不是依赖于长期存在组织的累积状态。

每个环境假设的基准也是版本的。自定义元数据、命名凭据配置和自定义设置定义作为元数据部署，而设置值和参考记录从版本化的种子数据加载。将两者与代码一起放在源代码控制中意味着每个环境都从已知、一致的基准开始，而不是手动配置的基准。

以这种方式编码环境会从源头攻击配置偏差。当环境的定义存在于版本控制中时，环境之间的差异表现为可见的差异，而不是静默的差异，重建干净的环境比调试已经偏移的环境更快。当环境损坏时，从源重新配置会缩短恢复时间，并且它允许漏斗为每次更改建立一次性环境，而无需手动设置。

Sandbox 为开发、测试和培训提供了隔离的环境，无需承担生产数据或配置的风险。有效的 Sandbox 策略平衡了环境保真度（Sandbox 与生产的匹配程度）与成本和刷新频率。

• Developer Sandbox 为单个功能开发提供了轻量级的隔离环境。开发人员使用开发人员 Sandbox 进行具有共享依赖性的集成测试，从源代码控制中创建临时组织进行日常工作。Developer Sandbox 和临时组织经常刷新，以保持配置与生产同步。
• 集成 Sandbox (Developer pro 或 Partial copy) 提供了多个功能集成和交互的共享环境。集成 Sandbox 包含足够的生产数据来测试现实的工作流，而无需完整数据复制的成本和复杂性。在升级到暂存之前，集成测试针对集成 Sandbox 运行。
• 暂存 Sandbox(完整副本)镜像生产配置和数据，在生产部署前提供最终验证。暂存 Sandbox 会在生产前收到版本，从而支持对部署程序、性能特征和数据迁移脚本进行类似生产的测试。暂存 Sandbox 每季度刷新一次，或在主发布之前刷新一次。
• 培训 Sandbox 为用户培训和演示提供了真实的环境，而不会暴露真正的客户数据。训练 Sandbox 可能包含合成数据或匿名生产数据。培训环境保持稳定，以支持一致的培训材料和认证流程。

自动化 Sandbox 刷新和数据加载。手动 Sandbox 刷新成为阻止频繁测试类似生产数据的瓶颈。自动刷新程序与数据加载脚本相结合，支持按需环境重置，支持持续集成漏斗和手动测试需求。

注意：“Sandbox”在代理企业中有两个不同的含义。上面的 Sandbox 是环境：组织的隔离副本，团队在更改到达生产环境之前进行构建和测试。Sandbox 客服人员的操作不同。运行时边界通过范围权限、有限的对象和集成访问权限以及受控的执行来约束自主操作的执行位置和方式，因此客服人员不能超出预期范围。两者是相辅相成的:Developer Sandbox 是您针对非生产数据验证客服人员操作的地方，而操作 Sandbox 是在生产中包含这些操作的地方。

即使使用自动化漏斗，部署也会带来风险。安全部署实践通过验证、监控和受控执行来降低风险：

• **部署验证：**以干运行方式运行部署，无需提交更改。验证会在实际部署前发现部署错误 — 缺少依赖性、组件冲突、引用无效。Salesforce 支持通过 UI 和 CLI 进行验证部署，即使在实际部署等待维护时段时，也能在工作时间在生产中验证。
• **部署监控:**在部署期间和之后观察关键度量。监控错误率、性能度量、用户流成功率和 API 消耗。部署后的突然变化表明回归需要调查和可能的回滚。自动监控会比较部署前和部署后度量，并在统计偏差超过阈值时发出警报。
• **部署手册：**记录部署程序，包括先决条件、执行步骤、验证检查、回滚程序和通信计划。Runbook 将部署从紧张的部落 Knowledge 仪式转变为任何人都可以执行的日常程序。Runbook 通过部署回顾来发展，总结经验教训并防止重复出现问题。
• **回滚功能:**在部署失败时提供转义路径。Salesforce 元数据回滚需要重新部署以前的版本，而不是本地回滚命令，这使得版本控制变得至关重要。为每个生产版本维护部署软件包，支持快速部署。对于数据更改，请保留启用还原的部署前备份。对于配置更改，请在设置审计跟踪中跟踪以前的值。

在部署影响影响较少用户时，在低流量期间计划部署。周末和晚上的部署最大限度地减少了业务风险，但增加了运营负担。平衡用户影响与团队可持续性。具有强大的部署实践和全面的监控的解决方案可以在工作时间安全地部署，但是未经验证的解决方案受益于非工作时间的部署，直到建立信任。

配置是管理解决方案行为的元数据 — 组织设置、功能、权限、集成和自定义。配置更改会影响在不部署代码的情况下立即运行解决方案，因此配置管理对运行稳定性至关重要。

源代码控制中的版本配置与代码。简档定义、权限集分配、自定义设置、平台事件定义、命名凭据和远程站点设置都属于版本控制。版本化配置支持部署自动化、变更跟踪、环境一致性和回滚功能。

检测并修复配置偏差。随着时间的推移，随着管理员的直接更改、热修复绕过正常的部署流程以及未记录的解决方法的累积，生产组织会偏离文档化配置。生产配置和版本控制之间的自动比较显示了偏差。计划每季度的偏差检测和补救，以防止配置债务累积到部署变得不可预测的地步。

记录配置决策及其理由。未来的维护人员不仅需要了解配置的内容，还需要了解原因。将组织范围的默认设置设置为客户专用，但联系人公用需要文档，以解释导致此决策的业务需求。如果没有记录的理由，未来的变化就有可能打破业务流程中隐藏的假设。

自动化消除了重复的手动工作，减少了人为错误，并使操作能够扩展，而无需按比例增加员工数量。对于 Salesforce 解决方案，自动化业务机会跨越声明性平台功能、编程自动化和操作程序。

Salesforce 的声明性自动化工具 Flow Builder、公式字段、验证规则、审批流程 — 使非开发人员能够在没有代码的情况下实施复杂的业务逻辑。声明性自动化提供了治理优势（管理员无需部署即可修改）、透明度（可视化设计文档本身）和平台优化（声明性操作的执行效率通常高于等效代码）。

• Flow Builder: 自动化结合了用户交互、数据操纵、业务逻辑和集成的复杂流程。流处理常见模式，包括使用依赖查找创建记录、条件批准路由、多步骤数据导入、计划清理作业和错误通知工作流。自动启动的流会对记录更改、计划的时间间隔或从代码中显式调用执行。屏幕流通过基于用户输入的分支逻辑来指导用户完成多步骤流程。

设计可重用性和可维护性的流。子流封装了多个父流重用的通用模式（例如错误处理或记录锁定逻辑）。命名良好的流变量和显式描述会创建未来维护人员可以理解的自文档逻辑。模块化流设计允许在集成之前测试单个组件。

• **公式字段：**从其他字段动态计算值，无需代码或数据库更新。公式支持复杂计算、条件逻辑、日期算术和文本操作。公式字段适用于报表、列表视图、验证规则和流，在不同上下文中提供一致的计算。公式可以高效执行，因为它们不会消耗数据库存储，并且在记录访问期间可以实时计算。
• **验证规则：**在保存时强制执行数据质量。验证规则捕获数据输入错误，强制执行业务规则，并防止无效的状态转换。将验证规则放在标准和自定义对象上，以发现错误，而不管数据源是什么 — UI、API、Data Loader、集成。精心制定的验证规则错误消息会指导用户纠正问题，而不是使用加密技术消息让他们感到沮丧。
• **审批流程:**在状态升级之前，将记录路由到所需的批准。审批流程实施签名机构层次结构、合规性审查、法律批准和多方同意工作流。审批流程会自动提供审计跟踪，记录谁在没有自定义开发的情况下批准了什么以及何时批准了什么。

虽然声明自动化处理许多场景，但复杂的要求或性能约束有时需要在 Apex 中实现编程自动化。有效的 Apex 自动化平衡了功能和灵活性与可维护性和治理挑战。

• 触发器框架为数据库触发器逻辑提供了一致的结构。设计良好的触发器框架可以分离问题（逻辑何时执行、逻辑执行的内容、依赖性的顺序），在不更改代码的情况下启用/禁用单个处理器，并通过上下文跟踪防止递归问题。触发器框架通过防止不相关逻辑累积成不可维护的整体的“一个大触发器”反模式，使 Apex 自动化更具可维护性。
• Batch Apex 异步分块处理大量数据,遵守调控器限制,同时执行同步执行中超时的操作。批处理作业处理数据清理、跨越对象边界的批量更新、需要每条记录多次查询的复杂计算以及数据迁移操作。为幂等性设计批处理作业 - 运行两次相同作业应产生相同的结果，而不会重复工作或损坏。
• 可排队的 Apex 通过明确的工作序列将异步工作联系起来。当未来的方法被触发并被遗忘时，Quueable Apex 支持一个作业完成触发下一个作业的结构化序列。可排队作业支持复杂的编排，包括 API 标注，然后是数据处理、多阶段数据转换和具有指数回退的重试逻辑。
• 计划 Apex 以固定的时间间隔执行任务。计划作业处理定期清理、夜间数据同步、每小时集成轮讯和一天结束时的处理。在低流量期间计划作业并实施监控，以检测错过的执行。考虑计划的时间间隔是否真正满足业务需求，或者事件驱动的触发是否会更快地响应。

为操作可见性设计编程自动化。记录开始/结束时间、处理的记录计数、遇到的错误和性能度量。当批处理作业无声地失败时，它通常会被忽视，直到用户几天后注意到数据问题。主动日志记录和警报将静默故障转化为可诊断的事件。

平台事件支持事件驱动的架构，生产者在不了解消费者的情况下发布事件，消费者在不依赖生产者的情况下订阅事件。事件驱动的架构解耦组件，支持异步处理，并支持多语言集成模式。

• **平台事件发布：**通知感兴趣的订阅者重要的业务事件。订单下订单、付款处理、履行完成、SLA 违约和错误条件都代表值得发布的事件。事件负载包含足够的上下文，以便订阅者做出适当的反应，而无需额外的查询。从触发器、流、Apex 或 API 调用发布事件，为事件源提供灵活性。
• **平台事件订阅:**通过 Apex 触发器、流或外部集成平台对发布的事件作出反应。订阅者异步处理事件，这意味着发布者无需等待订阅者完成。事件驱动的处理通过在单独的执行上下文中分配工作而不是在大规模同步事务中消耗限制来遵守调控器限制。
• **事件重放：**使订阅者能够处理历史事件。使用平台事件重放 ID 从特定点重放事件。外部订阅者必须管理自己的重放 ID 状态。由于交付至少一次，因此重复处理是可能的 — 在订阅者逻辑中处理。根据用户恢复要求配置事件保留 — 高用量平台事件为 72 小时，原有标准事件为 24 小时，足以实现快速恢复，更长的保留期支持灾难恢复场景。

为稳定性设计事件。事件模式成为生产者和消费者之间的合同。模式更改需要跨多个团队和系统进行协调。在扩展事件时添加新字段，而不是修改现有字段。当破坏性更改变得不可避免时，显式的版本事件。

事件是服务的计划外中断或降级，需要响应才能恢复正常操作。有效的事件管理可以快速发现问题，将它们发送给合格的响应者，有效地解决问题，并吸取经验教训以防止再次发生。

• **检测速度：**确定事件影响持续时间。您发现问题的速度越快，在响应开始前累积的损害就越小。检测机制包括自动监控警报（来自可观察性系统）、用户报表（支持票证和直接上报）和外部监控（来自网络外部的合成事务和正常运行时间服务检查）。

根据用户影响而不是技术严重性确定事件的优先级。例如，影响内部批处理作业的 API 错误与阻止所有用户访问的登录失败的紧迫性不同。

事件严重性指导响应时间和升级路径：

建立清晰的事件响应程序，包括谁响应、如何升级、要保持什么通信节奏以及如何在团队之间协调。记录随叫随到的工程师在高压力事故期间可以遵循的 Runbook 中的程序。当人们确定要打电话给谁以及要采取的步骤时，未记录的部落 Knowledge 会产生响应延迟。

• 随叫随到的**轮换:**在团队成员之间分配运营负担,而不是消耗掉一些应对每个事件的英雄。随叫随到的轮换平衡了覆盖范围要求（始终有人可用）、公平性（每个人都分担负担）和可持续性（在出现激烈事件后，人们需要恢复时间）。

通过清晰的切换和记录的责任，构建随叫随到的轮换。主要随叫随到处理初始响应，次要随叫随到在主要需要帮助时提供升级，或在主要不可用时接管。随叫随到的轮班应该大小合适。例如，从一周开始，不要超过两周 — 较短的轮班会产生持续的上下文切换，而较长的轮班会增加倦怠的风险。计划轮换，允许提前计划个人义务。

• **升级路径：**定义何时及如何涉及额外资源。明确的升级标准可以防止两种失败模式：过早升级，这会将高级工程师的时间浪费在初级工程师可以处理的问题上；延迟升级，初级工程师会努力处理超出他们经验的问题，而专家援助却无所事事。升级标准通常分为三类 - 基于时间的触发器，例如 30 分钟没有进展；复杂性触发器，例如目前不需要专家的问题；严重性触发器，例如严重性 1 事件，它们总是升级为领导。

为随叫随到的工程师提供必要的访问权限、工具和信息。在人员等待访问时，没有生产访问权限的随叫随到状态会产生挫折感，并延长事件持续时间。随叫随到的工具包包括生产访问凭据、Runbook 访问权限、监控仪表板链接、上报联系人、供应商支持程序和通信模板。

公平补偿随叫随到的关税。随叫随到的工作会打乱个人时间并造成压力。补偿方法包括额外工资、代替休假或减少其他责任的轮换积分。如果没有公平的报酬，随叫随到的轮换会给尊重工作与生活平衡的组织带来不满和质量工程师离职。

• 无怨无悔: 从事件中获取最大教训,而不会造成妨碍诚实讨论的恐惧。无怨文化承认人们在复杂的系统中犯错误，并关注防止未来事件的系统改进，而不是因为过去的事件惩罚个人。

对所有 1 级和 2 级严重事件以及任何揭示新模式或系统问题的事件进行尸检。事后审查的时机至关重要:过早进行审查有可能造成信息不完整,而过迟进行审查则有可能造成记忆模糊。在事件解决后的合理时段（24-48 小时）内安排尸检，以便有时间收集数据，同时保持详细信息新鲜。

格式一致的文档尸检捕获：

• **时间线：**事件从初始检测到解决的时间顺序。包括时间戳、采取的行动、观察到的结果和做出的决定。时间线重建揭示了响应的有效性并确定了延迟。
• **根本原因：**允许事件发生的潜在系统弱点。超越近因（直接触发器），进入系统原因（导致触发器后果的设计或流程差距）。“工程师部署错误代码”是近因。“部署漏斗缺少捕获此错误类的自动化测试”是系统原因。
• **影响：**用户影响持续时间、受影响的用户数量、收入影响、数据完整性问题和声誉损害。量化的影响指导预防工作的优先级 - 预防具有 10 万美元影响的事件比预防 1000 万美元影响的事件值得更多投资。
• **预防：**防止重复发生的具体行动项目。有效的预防项目是具体的，包括行动、被分配人和计划完成。例如，将集成烟雾测试添加到 CI 漏斗，所有者：Jane，完成人：下一个冲刺。“改进测试”等模糊的预防项目被忽视，因为没有人知道要采取什么行动。
• **检测改进：**如何更快地检测类似事件。通过用户报表发现的事件表明存在监控差距。改进项目可能包括新警报、更好的仪器或关键路径的综合监控。

广泛分享死后发现。组织学习需要直属团队之外的共享。尸检会在公司范围内共享有关系统行为、常见故障模式和有效响应程序的分发 Knowledge。公开尸检（在外部发布）显示了透明度，并帮助客户了解服务质量承诺。

卓越运营是一种持续的实践，需要持续投资于衡量、学习和改进。随着系统变得复杂和操作 Knowledge 的扩散，将操作视为一次性设置的团队会随着时间的推移而退化。接受持续改进的团队会提高运营能力，通过可持续努力提供不断增长的价值。

DORA 度量来自 DevOps 研究和评估 (DORA) 计划，基于 2025 年 AI 辅助软件开发状况报告，它提供了经过研究验证的软件交付和运营性能评测。交付业绩强劲的团队在以下五个关键指标上表现出明显更好的结果：

DORA 将这五个度量组织成两个因素：吞吐量和不稳定。吞吐量由变更的提前期、部署频率和失败的部署恢复时间组成 — 它衡量变更进入生产阶段的程度。不稳定性有剩余的变更失败率和返工率度量 — 它衡量这些部署的进展。

• **部署频率：**衡量发布到生产环境的频率。移动最快的团队按需部署 - 通常每天多次。频繁部署支持快速反馈，通过较小的更改降低部署风险，并与更快的功能交付相关联。低部署频率表明团队避免了部署难题，并形成了一种恶性循环，即不频繁的部署会使每次部署的风险更高。
• **更改准备时间：**衡量从代码提交到生产部署的时间。子日提前期是高绩效交付的强烈信号，子小时提前期表示卓越的交付能力。较短的交付时间实现了对用户需求、竞争威胁和安全漏洞的快速响应。提前期长表示流程开销过大、自动化不足或组织功能失调。
• **更改失败率：**衡量导致需要补救的生产事件的部署百分比。最可靠的团队始终将这一比率保持在较低水平，这只占所有部署的一小部分。更改失败率高表明测试不足、部署验证不足或更改仓促而没有适当的质量检查。
• 失败部署恢复时间 (FDRT) 衡量您从需要立即干预的失败部署中恢复的速度。不到一小时的恢复是交货到期的强烈信号。较短的恢复时间表明成熟的事件响应、有效的回滚功能和实践良好的运行手册。恢复时间长表明部署验证不足、缺乏自动回滚或生产事件的所有权不明确。
• **部署返工率：**衡量由于生产事故而发生计划外部署的频率。低返工率表示稳定、经过良好测试的版本不会生成下游修复工作。高返工率表明，生产事件经常推动紧急部署，表明生产前测试、发布验证或更改管理实践存在差距。

持续测量 DORA 度量，并随时间变化趋势。改进轨迹比绝对值更重要。在保持质量的同时，团队从每月部署改进到每周部署，这证明了进步。跟踪对整个组织可见的操作仪表板中的度量，实现运营绩效和改进目标进度的透明度。

• **缩短回顾时间:**从最近的工作中提取经验教训，包括运营事件、部署挑战、流程摩擦和团队动态。回顾应定期进行（每次冲刺或每月），为持续反思创造节奏，而不是等待危机。

使用鼓励参与和可操作结果的结构化格式运行回顾。常见格式包括：

• 开始/停止/继续 - 我们应该开始做什么、停止做什么、继续做什么？
• 疯狂/悲伤/高兴 - 对最近经历的情绪反思
• 时间线 - 重建冲刺事件并识别模式）。

将回顾性见解转换为包含所有者和完成日期的具体行动项目。引起长时间讨论但没有行动的回顾会浪费时间并滋生犹 ⁇ 。有效的回顾在每个会话中产生 2-3 个可行的改进。跨回顾跟踪操作项目的完成情况，使团队对跟进负责。请确保轮换主持人，防止一个人主导讨论。

• **运营审查:**通过季度或月度业务审查评估总体运营状况。运营审查检查趋势数据，与目标进行比较，确定改进机会，并分配改进投资。这些审查还吸引领导参与，为与功能开发竞争的运营改进工作争取资源。

在审查中包含操作度量：

• **可用性：**实际与目标，按用户旅程和整体
• **性能：**按百分比和关键流划分的延迟趋势
• **事件：**按严重性、平均检测时间、平均解决时间计数
• **部署运行状况：**频率、成功率、回滚频率
• **操作负载：**呼叫页面、手动干预、工作时间

审查为卓越运营建立了问责制，而不是将运营视为无形的背景工作，只在危机期间得到关注。定期业务审查表明组织对可持续业务的承诺。

回顾最近的工作进展，运营审查向领导报告总体健康状况。工程审查是团队将运营信号转化为交付决策的重复节奏。他们介于两者之间，将仪表板、事件趋势和系统产生的错误预算与团队承诺的发布计划和待办事项联系起来。运行此审核会使运行状况保持为从事工作的人员所有，使其成为计划的内置部分，而不是事后的想法。

• **发布计划：**将操作就绪与功能范围、限制爆破半径的顺序更改一起视为一流的输入，并在错误预算用完时暂停发布。这样，部署纪律和业务优先级就会有意协调，而不是迫于最后期限的压力。
• **待办事项分类：**将业务工作（例如，事件操作项目、预防任务、技术债务、监控差距）与功能工作放在相同的待办事项中，以便竞争容量。定期分类会分配所有者和优先级，从而关闭从死后到提交工作的循环。

• 运营就绪审查 (ORR) 在生产发布前评估新功能或系统是否满足运营要求。ORR 通过在开发过程中发现操作缺陷来防止运营灾难，因为修复比启动后补救更便宜。

在生产推出新解决方案、主要功能或具有运营影响的架构更改之前，请执行 ORR。ORR 时间很重要 — 太早，实施仍然不完整，太晚，操作问题就像部署障碍一样，造成跳过修复的压力。

以下是执行 ORR 时需要记住的注意事项和问题：

• **监控和提醒：**是否有足够的度量?是否存在失败场景的警报？是否配置显示健康状态的仪表板？
• **文档：**常见操作是否存在 Runbook？架构是否记录在案，使响应者能够了解系统？升级程序是否清楚？
• **部署和回滚：**部署能否可靠执行？是否存在回滚程序？部署是否已在暂存中验证？
• **性能和可扩展性：**性能目标是否已在实际负载下验证？是否有增长的空间？是否存在调控器限制风险？
• **安全性与合规性：**是否已完成安全审查？是否满足审计要求？访问控制是否匹配要求？
• **依赖性：**是否识别了外部依赖性？集成合作伙伴是否有 SLA？依赖失败是否有回退行为？

在 ORR 完成时启动大门生产。当运营问题成为部署要求时，团队会认真对待，而不是尽力而为。ORR 大门防止运营债务的累积，这使得未来卓越运营变得越来越困难。

学习型组织系统地获取运营经验，并将其转化为改进的实践。学习文化取决于：心理安全，人们可以毫无恐惧地报告问题；衡量，数据可以揭示模式；承诺，领导可以分配时间来改进。

• 心理安全: 能够诚实地讨论问题、错误和濒临失误，而不必担心受到惩罚。缺乏心理安全的团队会隐藏问题，直到它们变成灾难，从而阻止早期干预。通过无懈可击的事后分析、庆祝问题发现和通过讨论自己的错误来领导建模脆弱性来建立心理安全。
• **测量：**使运行状态可见。运营度量、事件趋势、DORA 指标和用户满意度分数揭示了运营的实际表现与预期表现。测量可以根据影响而不是最大声的投诉或最近的事件来客观地确定改进工作的优先级。
• 改进时间: 承认卓越运营需要投资。在功能上花费 100% 容量的团队没有时间进行运营改进，从而产生技术和运营债务，并最终迫使他们做出危机响应。有意为运营改进、技术减债、工具和自动化投资预留工程能力。该规则防止了长期性能下降，同时实现了可持续的特征速度。

创建反馈循环，将运营体验与设计决策联系起来。当事件显示架构弱点时，优先考虑架构改进，以防止类似事件。当监控发现性能下降时，优先考虑优化工作。当部署失败发现测试差距时，优先考虑测试覆盖率改进。反馈循环创造了良性循环，其中运营不断改善，而不是逐渐退化。

卓越运营要求设计可观察性解决方案，通过自动化漏斗进行部署，有效响应事件，并从运营经验中不断学习。查看此核对清单，以评估您的运营成熟度：

可观察性和监控

• 解决方案包括全面的日志记录，捕获分布式跟踪的相关 ID
• 启用 Event Monitoring 和 Event Log Files 导出到外部平台，以进行超出本机限制的保留
• Proactive Monitoring 配置的阈值与组织基准一致
• 在每个版本后建立和审查的规模中心基准
• 设置审计跟踪导出以保留 180 天以上
• 为敏感和受监管的数据字段启用字段审计跟踪]
• 数据检测扫描识别并分类字段中的敏感数据，发现有助于合规性分类和补救
• 每季度根据安全基准检查一次健康检查，并根据风险优先级修复检查结果
• 使用重大事件标记和成功率监控来检测关键用户流程
• 集成监控跟踪所有外部依赖性的双向运行状况
• 为可用性、延迟、成功率和吞吐量定义的服务级别目标
• 警报架构包括严重级别、可操作的上下文和明确的升级

DevOps 实践

• 所有元数据版本控制启用从源的可复制生成
• 临时组织或开发人员 Sandbox 支持隔离开发
• 配置更改遵循与代码更改相同的审查流程
• 配置偏差检测每季度运行一次，并记录补救措施
• Sandbox 策略包括开发人员、集成、暂存和培训环境
• Sandbox 刷新和数据加载自动化
• CI 漏斗通过自动测试验证每个提交
• 受保护的主分支需要在合并前 CI 成功
• CD 漏斗通过渐进式验证在环境中部署
• 部署验证在生产部署之前运行
• 部署监控跟踪部署期间和之后的关键度量
• 部署 Runbook 文档程序、验证和回滚
• 测试金字塔包括单元测试、集成测试和端到端测试
• CI 漏斗中的测试执行自动化
• 代码审查需要两个具有明确审查条件的批准
• 拉取请求保持较小（200-400 行），以便进行彻底审查

自动化和效率

• 适用时使用的声明性自动化（流、公式、验证、批准）
• 使用可重用子流模块化设计的流
• 触发器框架为 Apex 自动化提供了一致的结构
• 批处理作业实施 idempotency 和全面的日志记录
• 带监控的计划作业在低流量期间运行
• 平台事件为异步处理启用事件驱动的架构
• 使用版本控制策略为稳定性设计的事件模式
• 自动化操作可见性包括记录、监控和提醒

事件管理

• 自动监控提供主要事件检测
• 通过明确的响应时间要求定义的事件严重级别
• Runbook 中记录的事件响应程序
• 随叫随到的轮换在团队之间公平分配运营负担
• 使用基于时间和基于复杂性的触发器清除升级路径
• 随叫随到的工程师拥有必要的访问权限、工具和信息
• 随叫随到的职责得到公平补偿
• 对所有严重 1 级和 2 级事件进行了无可指责的尸检
• 事后记录时间线、根本原因、影响、检测改进和特定预防操作
• 为组织学习广泛分享死后发现

持续改进

• 持续跟踪 DORA 度量（部署频率、提前期、变更失败率、恢复时间、返工率）
• 通过结构化格式和可操作的结果定期进行冲刺回顾
• 运营审查每季度或每月评估一次整体运行状况
• 运营就绪审查网关生产推出新功能
• 心理安全允许诚实讨论问题和错误
• 专为运营改进保留的工程能力
• 反馈循环将运营体验与设计改进联系起来
• 卓越运营被视为每个人的责任，而不仅仅是运营团队

分享您对良好架构框架的反馈。