3 AMのPagerDutyアラートにうんざりしたので、眠っている間にクラウド障害を直すAIエージェントを作った(GLM-5.1で構築)

Reddit r/artificial / 2026/4/7

💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsIdeas & Deep AnalysisTools & Practical Usage

要点

  • オンコール時の手作業による復旧を減らすため、Z.aiハッカソンで「障害を解析→構造的に提案→実行」するAIエージェント型の自律回復オーケストレータVyuha AIを構築しました。
  • VyuhaはAWS/Azure/GCPのトリプルクラウド環境をFastAPIのコントロールプレーンと動的リバースプロキシで統合し、5秒ごとのモニターループで障害を検知してコンテキストを収集します。
  • 推論にはGLM-5.1(ZhipuAI API)を用い、DEAD/FLAKYのような障害の性質の違いを踏まえて、残存ノードに過負荷をかけない形でトラフィック再ルーティングを提案します。
  • 改変の暴走を避けるためHuman-in-the-Loopを採用し、GLM-5.1は厳格なJSONで理由・重大度・実行用APIコマンドを生成した上で、ダッシュボード上で人が「Approve」してからオーケストレーションを進めます。
  • 「99%のAI DevOpsは通知要約止まり」という課題意識に対し、実行まで踏み込むエージェント設計(モック環境のChaos Lab含む)を具体的なアーキテクチャとして示しています。

オンコールをやったことがあるなら、この悪夢がわかるはずです。午前3時15分。us-east-1 の負荷の高いデータベースノードが、ランダムにパケットを落としているせいでアラートが飛んできます。ぼんやりしながらラップトップを開き、サーバーに ssh で入り、Grafana のチャートを見つめ、ヨーロッパのフォールバック・クラスターへ手動でトラフィックを付け替えます。

直している間に睡眠を1時間分失い、会社はダウンタイムでかなりの金額を失っています。

この週末の Z.ai ハッカソンでは、こうした特定のつらさを自動化できないか試してみたかったんです。「アラートを送るだけの"異常検知"」ではなく、失敗を分析し、構造的な修正案を提案し、それを実行する実際のエージェントです。

最終的に、Vyuha AI-a を作りました。これは、トリプルクラウド(AWS、Azure、GCP)の自律的なリカバリ・オーケストレーターです。

以下に、裏側で実際にどう動いているのかを示します。

スタック

コントロールプレーンには Python(FastAPI)を使い、ダッシュボードには Next.js、独自のダイナミック・リバースプロキシ、そして推論エンジンの重い処理には GLM-5.1 を使用しました。

99% の「AI DevOps」ツールにある問題

多くのAIモニタリングツールは、ログを取り込んで要約し、Slack メッセージにして終わりです。インフラが実際に燃え上がっているときには、それでは役に立ちません。

私は、長期的な推論を行えるエージェントが必要でした。完全にノードがクラッシュしたケース(DEAD)と、ただ様子がおかしいノード(FLAKY、あるいはパケットの25%を落としているだけ)の違いを理解できる必要がありました。

Vyuha の仕組み(トリアージループ)

AWS、Azure、GCP の3つのモック環境を、ダイナミックな FastApi プロキシの背後にセットアップしました。バックグラウンドの監視ループが、5秒ごとにそれらをプローブします。必要に応じて障害を注入できるように、ダッシュボードに「Chaos Lab」を組み込みました。

GCP ノードを強制 kill したときに何が起きるか:

検知:監視が、ポーリングサイクル中の 503 Service Unavailable、またはタイムアウトを捕捉します。

コンテキスト収集:すぐには動きません。プロキシの現在の「フォーメーション」を集め、生き残っているノードの応答時間を確認し、そのコンテキストをまとめます。

推論(GLM-5.1):ここで私は GLM-5.1 に大きく頼りました。ZhipuAI の API を使い、エージェントには上級 SRE として振る舞うようプロンプトを与えます。失敗を解析し、深刻度を評価し、残りのノードを過負荷にせずにどうトラフィックを再バランスするかを決めます。

提案:推論、深刻度、そしてプロキシをリルーティングするために必要なリテラルな API コマンドを含む、厳密な JSON ペイロードを生成します。

ならず者AIはなし(Human-in-the-Loop)

もちろん、LLM が生産ネットワークのテーブルを盲目的に書き換えるのは信用できません。

そこでエージェントは、厳密な Human-in-the-Loop の方針で動作します。GLM-5.1 モデルが修正案を提案し、それを選んだ理由を説明して、ダッシュボードに提示します。人間が「Approve(承認)」をクリックすると、オーケストレーターが新しいプロキシのフォーメーションを適用します。

進化的メモリ(いちばんクールな機能)

これは私が作っていて一番好きだった部分です。インシデントが起きるたびに、システムは学習します。

人間が GLM のフェイルオーバー提案を承認すると、エージェントは別の「Reflection Phase(振り返りフェーズ)」を実行します。何が壊れて何が直ったのかを分析し、「Evolutionary Memory Log(進化的メモリログ)」として働くローカルの SQLite データベースに記録を書き込みます。

次に別の失敗が起きたとき、オーケストレーターは SQLite から関連する過去のインシデントを取り出して GLM-5.1 のプロンプトに投入します。AI は、新しい問題を診断する前に文字通り自分の履歴を読みます。だから同じミスを二度としないようになります。

苦労

スムーズではありませんでした。フロントエンドの Chaos ボタンが文字列「dead」を渡していた一方で、バックエンドの Enums は厳密に「DEAD」を期待していたため、まったく無言の Pydantic のバリデーションバグで約4時間失いました。エージェントは何もせずにただ座っていました。LLM は賢いですが、スタック全体にまたがる型安全性の不一致は、結局あなたを謙虚にします。

試してみてください

私は、SRE の未来は単により良いダッシュボードではなく、自律的でエージェント的なインフラだと証明するためにこれを作りました。

Render/Vercel でライブ公開しています。GCP の「Hard Kill」ボタンを押して、AI がリアルタイムにどう反応するか見てみてください。

ここにいる実際の SRE や DevOps エンジニアから、容赦ないフィードバックをぜひもらいたいです。実際のデータセンターでは、どんなエッジケースがこれを壊してしまうでしょうか?

submitted by /u/Evil_god7
[link] [comments]