2 篇博文 含有标签「disaster-recovery」

询问基础设施团队，如果主数据库宕机会发生什么，你会得到一个演练过的答案：副本、故障转移运行手册、某人签字确认的 RTO 和 RPO 指标。询问同一个团队，如果模型 API 宕机会发生什么，你通常只会得到一个耸肩和指向供应商状态页面的链接。这种不对称性在 2023 年是有道理的，那时 LLM 只是驱动一个实验性的侧边栏。但在你的支持流程、搜索排名、代码审查机器人和入职助手都开始通过单一供应商的推理端点路由的那天起，这种不对称就不再合理了。

模型 API 现在是许多产品的 Tier-0 依赖项——对营收至关重要，且与数据库一样位于请求路径中——但大多数灾难恢复计划仍将其视为可有可无的集成。其结果是一种熟悉的故障形态：供应商服务降级，产品中的每个 AI 功能都显示相同的加载图标，值班人员盯着一个他们无法影响的状态页面，没人能回答唯一重要的问题：这个产品现在应该做什么？

你团队每季度演练的灾备 (DR) 操作手册是为了一套你已经不再完全运行的技术栈编写的。手册上写着：提升从库、重新指向 DNS、清空队列。它假设状态存储在数据库、队列和对象存储中 —— 这些是 SRE 团队已经管理、命名并测试了十年的地方。接着在上个季度，你上线了一个智能体 (agent)。现在，工作内存存在于推理提供商的会话缓存中、工作节点本地磁盘上的草稿文件里、尚未回写的在途工具调用结果中，以及仅存在于单次模型调用提示词历史中的部分“计划-执行”轨迹 (trace) 里。这些都不在资产登记簿上，也不在操作手册里。

当区域宕机时，智能体并不会干净利落地失败，而是处于一种“半完成”的状态。用户看到工作流已经开始，但故障转移后的区域无法恢复进度；客户收到了两次账单，或者根本没收到，因为幂等键存在于已经失效的工作节点上；值班工程师读着 Slack 频道里的讨论，开头是“编排器已启动，但是...”，六小时后以处理信用卡拒付队列告终。

这就是没人点破的鸿沟：智能体特性拥有现有灾备计划未曾描述的状态模型。如果团队还没有记录下这些状态表面，那么只需一次区域性停机，他们就能深刻体会到操作手册的缺失所带来的代价。