CloudOps・FinOps・SecOpsのために
私たちが話を聞くエンジニアリングチームはどこも、バラバラのシグナルに埋もれています。監視ツールは「Podが落ちた」と言い、FinOpsツールは「Snowflakeのコストが急増した」と叫び、セキュリティスキャナーは「ポートが開いている」と警告する。 しかし「何かが壊れた」と気づくのは、仕事のほんの入り口にすぎません。その後の手作業のトリアージを肩代わりするために、私たちはこのエージェントを開発しました。
CloudOps / SRE
監視・デプロイ・コードの各ツールを手作業で突き合わせる必要はもうありません。エージェントがシグナルを関連付け、修正案まで提示します。
FinOps
コスト異常はレポートで指摘して終わりではなく、原因となった特定のデプロイや設定変更まで遡って特定します。
SecOps
セキュリティ検出結果をインフラのコンテキストと関連付け。永続アクセスゼロのモデルなので、エージェント自体がリスク要因になることもありません。
SREの業務時間がインシデントの原因特定に費やされている
インシデント1件あたりに照合されるツール数(平均)
設計段階から貫かれたゼロアクセスポリシー
仕組み
イベントメッシュと変更台帳
コスト異常やエラー急増が発生すると、エージェントは影響範囲(ブラストラディウス)を自動でマッピング。統合された変更台帳を参照し、直近のインフラ変更とインシデントを突き合わせて根本原因を診断します。
単なるアラート通知では終わりません。具体的なコード修正や設定変更を生成し、承認するだけのプルリクエストとして提案します。
必要なのは、もう一つのダッシュボードではなく、頼れる同僚。
エンジニアが働く場所で、仕事を完結させる
永続アクセスはゼロ
本番環境への永続的な書き込み権限は、一切持たせない。
AIエージェントに本番環境への永続的な書き込み権限を与えるなど、論外です。私たちもそう考えています。
エージェントは内部のクレデンシャルブローカーを通じて、その時々のタスクだけにスコープを絞った短命のジャストインタイムトークンをリクエストします。タスクが終われば、クレデンシャルは即失効。常時有効な権限も、万一侵害された場合の影響範囲も残しません。
環境を学習する
エピソード記憶・意味記憶・手続き記憶
記憶がなければ、インシデントは毎回ゼロからのスタートです。同じ教訓を、エージェントは何度でも学び直すことになります。
このエージェントは3層のメモリを備えています。たとえば一度「このサービスは今、チェックアウトチームが担当している」と修正すれば、意味記憶が更新され、次からはきちんと覚えています。過去のインシデントは将来の診断に活き、ランブックは実行可能な手続き知識になります。
そのギャップを、埋める。
アラートを、承認済みの修正へと自動で変える。
Frequently asked
questions
エージェントは本番環境への書き込み権限を持っていますか?
いいえ。永続アクセスゼロのモデルを採用しています。修復タスクだけにスコープを絞った短命のジャストインタイムトークンをリクエストし、タスク完了と同時にクレデンシャルは失効します。常時有効な権限は一切ありません。
既存の監視ツールやアラートツールを置き換える必要はありますか?
いいえ。エージェントはDoiT Cloud Intelligence、PerfectScale、Kubernetes、そしてすでにお使いのアラートツールの上で動作します。既存のスタックからシグナルを取り込み、相関分析・診断・自動修復を上乗せする形です。
エージェントはどうやって自社環境を学習するのですか?
エピソード記憶(過去のインシデント)、意味記憶(チームの担当関係、サービスマップ)、手続き記憶(ランブックやプロセス)の3層を維持します。修正を加えるたびにメモリが更新され、その知識が以降のインシデント対応に反映されます。
検出結果はどこに届きますか?
Slackのスレッド、CLI、そしてGitHubのプルリクエスト上に届きます。もう一つのダッシュボードを作ることは、意図的に避けました。エージェントは、エンジニアがすでに働いている場所に出向きます。
対応しているクラウドやプラットフォームは?
DoiT Cloud Intelligence経由でAWS、Google Cloud、Azureに対応。PerfectScale経由でKubernetes環境にも対応します。主要なオブザーバビリティツールやデプロイツールとも連携可能です。