北京
2025年9月，我负责的一个应用在某个区域的延迟开始持续攀升。不是断崖式下跌，也没有彻底宕机，就是一点点变糟。这个平台跑在金融服务领域，是多租户的SaaS系统，跨两个AWS区域做双活，底层是Aurora全球数据库，上层用Route 53地理位置路由。我们手里每一块仪表盘都是绿的，目标组健康，容器在跑，数据库连接正常。但那个区域里相当一部分用户确实体验很差，而Route 53地理位置路由还在忠实地把他们送回那个正在出问题的区域——因为地理位置路由不知道什么叫“痛”，它只知道你在哪里。
核心难题：是我们，还是云厂商？
于是我们卡在一个关键问题上：这到底是我们的问题，还是云服务商的问题？如果是云厂商的问题，答案就是把流量迁出这个区域。如果是我们自己的变更导致的，那迁出流量就是最差的选择——我们会把问题一起带走，放弃一个本来健康的区域，把所有负载压到幸存的那一边，结果还是坏的，而且选项更少，数据库故障切换还不可逆。我们判断不了。甚至分不清这到底是DNS问题还是应用问题。结果就是：没人愿意拍板，因为没人能证明这不是我们的问题。
我们为这件事争论了将近两个小时。最先做的是回滚最近的变更，因为这是可逆的操作，而且至少能排除两种可能性中的一种。回滚之后什么都没变。这确实给了我们一些信息，但给得很慢，我们仍然在猜。最终原因出在云服务商那一侧。我们花了两个小时去证明一个“否定”，而唯一能缩短这两个小时的东西，是我们从来没有提前准备好的证据。
这不是工具缺口，是证据缺口
这不是工具链的问题。我们几分钟内就能切换流量，操作手册是现成的，路由控制也早就配好了。我们做不到的，是快速、可辩护地给出一个使用这些控制措施的理由。这篇文章就是我为解决这个问题而构建的方案：整体架构、AI在其中的位置、AI明确不该出现的位置，以及演练教会了我们什么。它写成一份参考模式。如果你在任何地方跑双活，应该都能直接拿去用。
为什么这不是又一篇智能体AI文章
在你花十分钟读下去之前，有个合理的问题：现在满屏都是AI运维内容，为什么还要读这篇？因为那些内容几乎都是同一个东西——一个智能体拿着工具和凭证，被塞了一个目标，然后循环执行，直到它宣布自己完成了。演示里很惊艳。但在基础设施领域，演示不是最难的部分。最难的是凌晨三点，生产流量握在你手里，而你是错的。这不是把传统AI硬塞进一个聊天框。这是一个语言模型被放进基础设施的决策路径里，而且这里几乎每一个设计选择都是为了约束它：它不持有任何凭证，不调用任何API，不能执行任何动作，只读取结构化的证据。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
