AI-translated from English; not yet reviewed by a fluent editor.
# Claude 已恢复服务，企业仍需要恢复计划
> Claude 于 9 月 22 日发生的服务事故现已解决。本实用指南说明，AI 服务中断时，企业如何维持有限服务、保存未完成工作，并恢复自身积压任务。
By BIG CHANGE Editorial
Published: 2026-09-22T08:51:37.833Z
Updated: 2026-09-22T08:51:37.833Z
Canonical: https://bigchange.ai/blog/claude-outage-ai-business-continuity
AI-generated conceptual illustration by BIG CHANGE. When an AI service pauses, a business still needs accessible records of unfinished work. The bookmarked ledger represents preserving the stopping place. Conceptual illustration, not evidence of damaged equipment or lost data.
9 月 22 日，Claude 多个模型出现错误率升高。Anthropic 最终的事件更新将影响时段定为 UTC 时间 00:50 至 02:10，共 80 分钟，并于 UTC 时间 02:35 将事件标记为已解决。列出的受影响组件包括 claude.ai、API、Code 和 Cowork。记录并未说每个请求都失败，也没有公布根本原因。[Anthropic 事件记录](https://status.claude.com/incidents/7g1qpkyz5gxh)
对于在工作流程中使用 AI 的企业而言，服务恢复只解决了部分问题。客户请求可能仍在等待处理；有人可能已开始手动处理案件，而自动尝试仍在运行。主管需要知道哪些工作可以恢复，哪些必须先检查。
如果 AI 助手只是偶尔用来集思广益，无法使用时会让人不便。如果同一服务还用于分类新案件、起草回复和更新记录，中断就会变成运营问题。有用的准备工作，是制定一份简明的连续性计划，让员工即使无法使用 AI 服务也能遵循。
本指南用一个假设的客户服务台说明计划可以如何运作。这些流程是供调整和演练的建议，并非 BIG CHANGE 执行过的测试，也不是对这次事件中受影响客户的描述。
## 选择一种不依赖 AI 也能维持的服务方式
设想一家小型设备供应商使用 AI 助手为收到的支持邮件分类，并依据经过批准的产品信息准备回复。员工会在发送前审核回复。尽管答复仍由人负责，但企业依赖该系统来整理待处理队列。
如果助手停止响应，经理首先需要决定服务台还能承诺提供什么。员工可以继续确认收到请求，并处理截止时间迫近的案件，同时暂缓常规产品说明。他们必须能够在助手以外访问原始消息和经批准的参考资料。否则，“改为手动处理”就只是没有配套手段的指令。
应提前选择这种降级服务方式。明确指定谁可以启动降级服务、哪些工作应暂停，以及由哪些员工负责剩余任务。安排复查时间，以免临时安排整个下午都没有人重新评估。面向客户的通知应解释延迟情况、紧急求助的可用渠道，并只承诺团队能够兑现的内容。
Google 的工程指南在讨论过载处理时，建议在资源受限时提供功能降级的服务、限制流量并优先处理重要请求。这些是成熟的可靠性技术，并非对 Claude 本次事件的诊断。应用到服务台时，它们支持在常规处理无法继续时有计划地缩小服务范围。[Google SRE：处理过载](https://sre.google/sre-book/handling-overload/)
降级服务也需要容量上限。两名员工不可能悄无声息地接手一套通常服务更多请求的自动化系统所承担的工作。记录他们能处理多少、哪些工作需要等待，以及何时需要额外帮助。与其发送让客户以为服务照常运行的自动确认，不如提供可信的响应时限。
## 在对话之外记录工作状态
服务台需要一份在模型无法使用时仍可读取的案件记录。这可以是现有支持系统。关键在于，企业无需让发生中断的助手重建过程，也能查明发生了什么。
每个案件都应保留原始请求、负责处理的人员或流程，以及最后确认的操作。已保存的草稿不同于已发送的回复。对客户记录提出的变更建议，也不同于该系统已确认完成的变更。应保存足以区分两者的证据，并采用与底层客户信息相同的访问限制。
发生中断期间，可将工作分为以下几类：
- 尚未开始：尚未进行任何处理，也未采取外部操作。
- 部分准备：已完成分类或起草，但后续步骤尚未完成。
- 确认完成：目标系统已记录预期操作。
- 状态不确定：已尝试操作，但缺少确认。
将状态不确定的案件交给能够检查相关系统的人，再决定是否恢复处理。如果连接中断时助手正在准备回复，重新起草一份可能没有问题；但若是另一个工具正在发送回复，重做整个任务可能导致重复发送。工作流程记录应明确区分这些情况。
Anthropic 的 API 文档指出，即使数据流式响应一开始返回 HTTP 200 成功状态，之后仍可能失败。收到首段文本或初始状态码，并不能证明完整答案已经送达。应要求集成机制识别任务何时完成，并将部分工作明确保留为未完成状态。[Claude API 错误文档](https://platform.claude.com/docs/en/api/errors)
## 为重试设定上限，并指定负责人
重试可以解决暂时性故障；但如果每一层都独立重复同一任务，也可能延长不确定状态。添加另一个重复按钮或自动循环之前，先询问软件供应商，其客户端库内部是否已经会重试。
Anthropic 的文档指出，其官方 SDK 默认会对暂时性故障自动重试两次，间隔时间逐步增加，并在有重试间隔指示时遵循该指示。其错误文档也区分了暂时性的服务器问题，与认证、权限及请求格式错误。不能假设重复发送相同请求就能修复所有类别的问题。[Claude 文档所述的重试行为](https://platform.claude.com/docs/en/api/errors)
对于服务台，应在运营规则中明确何时停止自动尝试，以及之后由谁接手案件。保留请求标识符以便排查问题。让员工能看到任务是在等待、正在重试，还是等待人工处理，避免他们不知情地启动互相冲突的尝试。
AWS 解释过一种情况：操作可能已经成功，但响应却未能送达。其幂等 API 使用明确的请求标识符识别重复请求并防止产生额外副作用。接收服务必须落实这项约定；仅附上内部案件编号并不能提供这种保护。[AWS：如何安全地重试](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
针对工作流程执行的具体操作进行询问。重复尝试会不会再创建一张支持工单或再发送一封邮件？如果无法防止重复，计划就应要求先检查目标系统中的记录，再尝试一次。重试文本生成，与重复执行整个业务流程，需要不同的决策。
## 备用模型应有范围更窄的工作说明
替代 AI 服务可以帮助工作继续进行，但另开一个账户并不等于已经建立备用方案。替代服务需要正确的指令、经批准的参考资料和处理相关数据的权限；企业需要它时，该服务还必须具备容量。
先决定备用服务承担哪项有限任务，再考虑全面替换。在我们假设的服务台中，另一种模型可以为常规消息分类，面向客户的回复则继续由员工处理。团队可以用有代表性的案例评估它，包括含糊的产品名称和必须转交人工的请求。仅仅回答流畅，并不能证明它遵守了公司的支持规则。
应在事件发生之前确定哪些信息可以发送给替代服务。员工不应临时将客户记录粘贴到个人账户中。采购时，除输出质量和价格外，也应核查替代服务的数据处理条款和访问安排。
不同的模型名称本身并不能证明服务可以独立运行。备用方案可能仍依赖同一个登录账户、网络连接、文档存储库或编排软件。应列出你所提议的替代方案实际绕开了哪些依赖项。这样或许会发现，提供可访问参考文档的人工队列，比部署在同一故障连接之后的另一种模型更能提供保护。
随着指令变化和产品知识过时，替代方案也需要维护。员工应练习自己很少使用的流程。小企业合理的选择可能是保留速度较慢的人工服务，而不是花钱复制整套运营体系。选择应依据工作延误的成本和错误答复可能造成的损害。
## 在审核过的队列中恢复处理
服务提供商报告系统恢复后，先抽查自家工作流程中的少量案例，再恢复正常处理。抽查时应包括一个需要查询文档和更新记录的业务案例。模型成功生成回复，并不能证明每个连接系统都已准备就绪。
然后检查等待处理的工作。移除已经由人工处理的案件，检查状态不确定的操作，并识别情况已发生变化的请求。中断期间，客户可能提供了新信息。根据较早版本的案件起草回复，可能在技术故障结束后再次引发问题。
分批、有控制地释放剩余工作。为新的紧急请求保留处理能力，并观察队列是否缩短。如果新需求占用了所有可用处理能力，即使每次新尝试都成功，积压仍会持续。要完成追赶处理，可能需要增加人手、临时降低服务范围，或诚实地延长响应时间。
再举一个单独的数字例子：假设每小时收到 24 个案件，处理工作停止了 30 分钟，那么将有 12 个案件等待处理。之后，如果服务台每小时处理 36 个案件，同时每小时继续收到 24 个新案件，那么清空积压需要一小时。这些是说明性假设，并非对 Claude 事件的测量结果。
Google 关于服务级目标的指南建议，从用户真正关心的结果和交付该结果所需的依赖项入手。对于这个服务台，一项有用的指标可以是：在承诺时限内得到适当响应的紧急案件占比。服务提供商的可用性固然重要，但企业还需要了解客户是否实际获得了服务。[Google SRE：实施服务级目标](https://sre.google/workbook/implementing-slos/)
记录客户服务恢复正常的时间、未解决案件数量，以及事后需要作出的任何更正。这些指标能够揭示服务提供商状态页面无法观察到的恢复工作。
## 扩大自动化范围前，先演练一次中断
简短的桌面推演可以揭示访问权限或责任归属方面的缺口，而且不会影响真实客户。使用几个虚构的支持案例，按以下步骤逐项演练：
1. 假设模型在准备回复的过程中变得不可用。询问由谁启动降级服务，以及员工在哪里可以找到原始请求。
2. 一项案件的回复已确认发送，另一项则只有一次状态不确定的发送尝试。检查团队是否知道哪个系统可以确认结果。
3. 假设服务提供商已经恢复，但新案件仍在不断到来。决定先恢复处理哪些工作，以及如何将人工完成的案件移出积压队列。
4. 请一名不是计划作者的人员讲解流程，并指出自己缺少哪些权限或记录。
记录这次演练无法回答的问题。之后需要做的修正可能很小：开放现有队列的访问权限、设置清晰的暂停控制、保存确认信息，或指定恢复负责人。这些做法都无法保证服务永不中断，但每一项都有助于在不中断自动化优势的前提下，更容易控制中断的影响。
再给助手一项运营职责之前，请同事说明发生服务中断时该职责如何处理。如果答案依赖发生中断的助手记得自己正在做什么，连续性计划就还有工作要做。
## Sources
- [Claude 状态页：多个模型错误率升高](https://status.claude.com/incidents/7g1qpkyz5gxh) — 服务提供商的事件记录给出了 80 分钟的影响时段，以及之后的解决时间。我们独立读取了公开 JSON。记录报告的是错误率升高，并非所有请求都失败，也没有公布根本原因。
- [Claude 平台：API 错误](https://platform.claude.com/docs/en/api/errors) — 当前文档涵盖各类错误、SDK 默认重试，以及数据流开始后发生的失败。这些机制不能证明业务任务已完成，也不能防止连接工具产生重复操作。
- [AWS Builders’ Library：使用幂等 API 安全重试](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) — Malcolm Featonby 解释了响应状态不确定和防止重复操作的问题。接收服务必须实现相应的 API 约定；只有标识符并不足够。
- [Google SRE：处理过载](https://sre.google/sre-book/handling-overload/) — 有关功能降级、优先级和有限次重试的成熟工程指导。本文将这些原则用于假设的服务台情形，并未据此诊断 Anthropic 事件的原因。
- [Google SRE 工作手册：实施服务级目标](https://sre.google/workbook/implementing-slos/) — 介绍了以用户结果和关键依赖项为基础的可靠性目标。建议采用的客户服务指标和积压案例是说明性应用，并非实测结果或普遍适用的目标。