留意这些常见的反模式，并使用这些策略来避免它们以提高组织中的可用性。
回想一下您的解决方案未按预期工作的时间。也许您的用户在更新具有大量 Apex 触发器的记录时性能不佳，或者与 Salesforce REST API 的集成因事件而被大量调用淹没。这些体验可能是任何地方，从轻微的不便到用户的服务完全中断。好消息：通常，这些可用性受限的事件是可以通过提前思考和高效编码以及将可用性和弹性放在首位来预防的。
什么是可用性？
可用性是服务成功处理请求的时间百分比。Salesforce测量并跟踪此百分比，以确保我们的服务器和服务对每个客户都高度可用。
虽然服务器和服务可用性对 Salesforce 至关重要——客户体验的可用性更是如此——这直接关系到用户如何体验 Salesforce。例如，用户能否快速可靠地登录到您的组织并更新记录？数据是否通过 API 高效无误地更新？
客户体验的可用性很难衡量，因为每个组织、用户和公司都是独一无二的。用户的体验可能会因许多因素而有很大差异，例如 Apex 代码和 Lightning 组件设计、地理区域和网络连接。尽管这些因素各不相同，但 Salesforce 将可用性视为重中之重，作为我们信任核心价值的一部分。
我为什么要关心可用性？
可用性或缺乏可用性会影响每个人：您、您的用户和您的公司。高度可用的组织意味着您的用户能够在支持公司发展的同时继续履行职责。表现不佳或不可靠的组织会造成挫败感，在极端情况下，可能会在财务或声誉上影响您的公司。
作为开发人员，您对 Salesforce 解决方案进行编码的方式会直接影响用户的体验。重要的是，您的代码不仅要满足功能和业务需求，而且您的用户可以在需要时自信地与您编写的代码进行交互并执行。
我应该避免哪些常见的可用性反模式？
作为开发人员，请注意这些常见的反模式并提出关键问题以避免它们。
反模式 #1：脆弱的集成设计
虽然很容易专注于集成的“快乐之路”并编写一些简单的代码，但您的集成如何抵御异常或压力？以下是在编写集成代码之前要问的几个常见问题：
- 将通过集成的预期数据量是多少，以什么速率进行？Salesforce REST API 一次可以插入或更新 200 条记录。进行一次 API 调用以更新 200 条记录比使用 200 个 API 调用每次更新一条记录要快得多并且使用的服务器容量要少得多。
- 您的集成能否根据传入的数据量和速率在 REST 和批量 API 之间切换？
- 如果将来 Salesforce 中的验证、触发器或流逻辑发生变化，然后拒绝 API 中的记录更新怎么办？
- 如果 Salesforce 停机维护怎么办？集成能否保留挂起的 API 调用并在 Salesforce 可用时重新处理它们？积压的订单能否有效处理大量交易？
- 如何处理意外错误？是否记录并报告了来自 Salesforce API 的错误以供您的团队调查？
在集成设计中预先解决这些问题，并确保在不可预见的情况下更可靠、更有弹性和适应性更强的集成。
反模式 #2：“触发框架”中缺乏 Apex 逻辑可见性
如此多的开发人员采用触发器框架的概念来模块化和轻松管理 Apex 逻辑，真是太棒了。然而，我们已经看到这种类型的框架也可以是一把双刃剑，例如：
- 多个开发团队正在研究调用同一对象的前/后触发器的 Apex 逻辑。但是，这些团队看不到其他团队的工作。因此，组合的 Apex 逻辑使用了更多的 Apex 限制并超过了调控器限制。
- 逻辑分布在流程、流程构建器、工作流和 Apex 代码中的组织。这在执行时会消耗大量服务器容量，并可能导致逻辑冲突和调控器限制违规，更不用说带有大量技术债务的维护噩梦了。
为避免冲突，每当您或您的团队计划向触发器框架中添加新逻辑或流程时，请提出以下问题：
- 除了我要编写的代码之外还有哪些其他逻辑？他们已经消耗了多少调控器限制，我可以使用多少？
- 我的逻辑可以与其他逻辑结合吗？例如，我们可以共享任何现有的 SOQL 查询并向查询添加一两个字段吗？记录字段更新是否可以捆绑在具有现有 DML 语句的其他逻辑中？
- 其他开发人员或管理员是否会在组织中添加更多逻辑，有或没有触发器或流程？我们如何协调，使额外的逻辑不与我所做的冲突？
- 我可以事半功倍吗？保存一个 SOQL 查询或一个 DML 语句可能看起来没什么。但是，如果您的组织在一小时内有数千个交易，您可以节省数以千计的数据库查询并释放服务器容量，这意味着您的组织不太可能出现性能下降。
反模式 #3：高峰时段的非结构化部署
大多数可用性事件发生在对生产中的组织设置进行更改时。您可能认为这些是因为未经测试的更改。但是，部署引起的最常见问题是由于元数据更改而运行的后台作业。例如：
- 更改具有数百万条记录的对象上的自定义字段会导致整个数据库表在后台触发这些记录。
- 部署新代码会使现有编译的 Apex 代码无效，并触发 Apex 重新编译中的后台作业。
这些后台作业还会消耗可用于为用户交互和 API 调用提供服务的服务器容量。当它们在贵组织的高峰营业时间运行时，服务器紧张和损害用户体验的风险会增加。
非结构化元数据更改可能会进一步加剧此问题，例如通过设置 UI 手动更改自定义字段，然后继续对不同的自定义字段进行另一次手动更改。
下次计划部署代码时，请考虑如何更有效地进行部署，并提出以下问题：
- 何时是部署可最大限度降低用户中断风险的代码的最佳时间？
- 我如何捆绑所有要同时部署的更改？（提示：Salesforce DX和DevOps Center！）
- 是否还有其他团队的其他部署？我们能否在不相互冲突的情况下高效部署？
反模式 #4：缺乏有意义的调试日志或警报
在开发 Salesforce 解决方案时，您是在满足业务用户、管理员和 IT 运营团队的需求。他们正在运行和管理您的组织，他们了解组织的运作方式以及在发生错误时何时做出响应至关重要。他们需要了解您引入组织的任何复杂逻辑。提供这一点的最佳方法是通过调试日志记录并确保错误警报到达它们。
问自己这些问题，让您的管理员和 IT 操作人员了解您的代码操作：
- 他们怎么知道我的代码是否按预期运行，以及我的代码被用户使用了多少？
- 我的代码中会出现什么样的错误？我如何有效地向管理员和 IT 运营团队提醒这些错误？
- 如果他们想对潜在问题进行分类和诊断，他们如何才能看到我的代码是如何执行的，而又不会被每一行代码压得喘不过气来？
反模式 #5：紧急情况下的“先解决”心态
当组织遇到阻止用户执行关键业务功能的问题时，通常会呼叫开发人员。他们通常专注于“解决问题”，将服务重新提供给用户。但是，在紧急可用性事件期间，这可能是有害的。
在事件期间，操作的优先顺序应该是最大限度地减少业务影响、恢复系统操作，然后找到并修复根本原因。
当要求在事件中查看问题时，问问自己：
- 用户现在如何受到该事件的影响？我怎样才能快速减少它们的影响？
- 该事件是由最近的变化引起的吗？如果是，我可以撤消更改吗？
- 如何让管理员和 IT 运营团队对事件进行分类？他们能否收集有关该事件的有价值的详细信息，以便我可以直接进入问题并在线开展业务？
不要忘记在事件发生后进行事后分析，以调查根本原因并解决问题。这应该在事件得到补救之后发生。
有关提高组织可用性的更多提示
这是关于您作为开发人员和您的代码如何提高组织可用性的速成课程。我们不希望您立即成为专家，但您现在可以通过以下方式开始提高可用性：
- 对您的组织及其设计感到好奇。如果您发现现有的低效率，请将其添加到待办事项列表中进行调查。
- 问问题。如果您对代码有要求，但它涉及的解决方案可能会在未来产生可伸缩性问题，请在设计审查期间主动指出潜在的可用性风险，以便您可以确保在编写代码时涵盖这些风险。
- 使用Salesforce 帮助和Salesforce 开发人员网站了解最新的最佳实践。如果找不到答案，请查看开拓者社区。
- 保持学习。使用Trailhead了解最新信息并熟悉 Salesforce 的最新和最重要的成果。
我们有多种资源可以在整个过程中为您提供帮助。查看Salesforce Availability，这是一个新网站，旨在帮助您提高实施的可用性。此外，新的可用性帮助和培训更详细地涵盖了可用性最佳实践。我们还与Well-Architected密切合作，以确保将这些概念很好地嵌入到一个单一框架中，供所有 Salesforce 专业人员遵循。请留意我们推出更多工具和资源以帮助在不久的将来提高可用性。
关于作者
Jsun Pe 是 Salesforce 可用性和基础设施工程服务的产品管理总监，专注于帮助 Salesforce 客户构建高度可用且有弹性的 Salesforce 解决方案。自 2009 年进入 Salesforce 生态系统以来，他见证了 Salesforce 平台的成长，同时获得了 Salesforce 认证技术架构师证书。Jsun 帮助澳大利亚和新西兰的顶级咨询合作伙伴建立技术实践，然后于 2016 年加入 Salesforce。在此期间，他发现了自己对平台性能和可用性的高级架构考虑因素的兴趣，最终促成了他目前的职位。
