两小时僵持的云故障：谁来为决策背书？

2025年9月，我负责的一个面向金融的多租户SaaS应用在某一区域出现了持续上升的延迟。不是断崖式故障，也没有彻底宕机，只是体验一点点变差。平台在两个AWS区域做双活，底层用的是Aurora全球数据库，上层用Route 53按地理位置路由。仪表盘上几乎所有监控指标都是绿的：目标组健康、容器运行、数据库连接正常。但该区域内大量用户实际感受很差，而Route 53仍按地理位置把流量送回那个“有问题”的区域——因为地理路由只按位置决策，不会感知“痛感”。

关键的僵局在于一个简单但致命的问题：这是我们的问题，还是云厂商的问题？如果是云厂商的故障，最合理的操作是把流量迁出该区域；但如果是我们最近的变更导致了问题，迁出流量等于把故障带到另一区域，可能导致更严重的后果（例如不可逆的数据库故障切换）。我们既不能快速判断是DNS层面的问题，还是应用或网络层面的变更引起的，也无法拿出能让人放心拍板的证据。结果是现场没人敢下决断。

团队为此争论了近两个小时。我们先做了可逆的尝试：回滚最近的变更，既能快速执行又能排除一种可能。回滚后情况并未改善，这倒是排掉了一种假设，但信息来得太慢，很多判断仍是猜测。最终排查出来的原因在云厂商一侧——但我们为证明“不是我们”的结论耗费了两小时。缩短这种排查时间的关键，不在于更多的切换按钮或更复杂的工具，而在于预先准备好的、可辩护的证据链。 龙8国际登录

这不是工具短板，而是证据短板。操作手册、路由控制、流量切换机制等我们几分钟之内就能触达；做不到的是在短时间内给出一个足够有说服力的理由去使用这些控制项，让团队在风险与不确定性之间有可追溯的判断依据。基于这次事件，我整理了一套参考方案：整体架构要如何设计、在哪些环节可以让AI参与判断、在哪些环节绝对不能让AI直接操作，以及通过演练我们学到的教训。目标是为任何运行双活部署的团队提供一套能直接套用的模式。

为什么这不是另一篇“智能体接管一切”的AI运维文章？很多演示展示的是一个拥有凭证与工具的智能体反复执行直到完成任务，效果很炫。但在基础设施故障的真实场景里，最难的不是自动执行命令，而是在凌晨三点掌握生产流量时做出正确判定——而你可能是错的。基于此，我们的设计原则是刻意约束AI：它不持有任何凭证，不被授权调用API或执行更改，只能读取结构化的、可审计的证据来辅助人做决定。几乎每一个设计选择的出发点都是如何把决策留给有责任的人，同时用证据和受限的AI来加速、规范判断过程。