Sentrix：AI SRE Copilot 对自己的扩容决策进行辩论

Source: Dev.to

每个 SRE 团队都有同样的噩梦：凌晨 3 点，流量突增，且没有人预料到。等到 CloudWatch 警报触发时，客户已经不满，收入也已经流失。

我构建了 Sentrix —— 一个 AI 驱动的 SRE 副驾驶，能够在问题发生前预测基础设施故障，并自主扩展你的云资源。它与众不同的地方不仅在于预测——更在于辩论。

三个代理，一个决策

Sentrix 并不是让单一 AI 做决定，而是让三个 Bedrock Claude 代理就每一次扩容调用进行争论：

• AGENT_SRE 为可靠性而战：“立刻扩容，我们不能冒停机风险。”
• AGENT_FINANCE 从成本角度反驳：“这相当于 5 倍的副本——我们真的需要这么多吗？”
• AGENT_ARBITER 综合两者：“先扩容到 3 倍，监控 5 分钟后再重新评估。”

结果是能够在可靠性和成本之间取得平衡的决策，并且每个决策在五分钟后通过 Step Functions 反馈回路进行评分。评分会成为 思考签名，反馈到后续分析中，使 AI 能够学习适用于你特定基础设施的最佳做法。

实际效果展示

我让 Sentrix 经过完整的事故生命周期：

1. 流量突增 →
2. 成本优化 →
3. 区域降级 →
4. AWS 连锁故障 →
5. 跨云 GCP 故障转移 →
6. 自动恢复。

在一次 4 536 % 的流量激增 中，大脑在毫秒级检测到突增，并将 EKS 从 2 个 pod 扩容到 10 个——无需人工。当流量恢复正常时，Finance 代理主张缩容，系统将 pod 数量从 10 缩回 5。当 AWS 区域出现连锁故障时，三个代理一致同意进行 GCP 故障转移。反馈回路为该决策打出了 100/100 的分数。

整个系统只需一个 AWS CDK 堆栈——Lambda、Bedrock、EKS、DynamoDB、Step Functions、EventBridge、CloudFront——五分钟即可部署完成。

完整写作

完整的文章包括：

• 架构细节
• 基于严重程度的模型选择（低严重度使用 Haiku，关键时使用 Sonnet）
• 思考签名自我进化机制
• 分阶段演示 walkthrough，附截图

在 Build Signals 上阅读完整写作

我已将 Sentrix 提交至 AWS 10,000 AIdeas 大赛。前 300 篇点赞最高的文章将进入下一轮。如果你觉得这篇文章有趣，点个赞真的能帮上大忙——只需两秒钟。

在 AWS Builder Center 为文章点赞