仕組み
どのステージも手動の引き継ぎを必要とせず、各レイヤーが自動的に次に渡ります：- 収集 — AWS、Datadog、Slack、PagerDuty などのソースから 1 つの Pulse フィードにイベントがストリームされます。
- フィルタリングと相関 — 抑制レイヤーが重複、レート制限されたバースト、フラッピングするリソースを削除します。関連するシグナルはクラスターにグループ化されるため、同じノードプールに関する 9 つのアラートが 1 つのアイテムになります。
- 分類とエスカレーション — すべてのシグナルにカテゴリ、正規化された深刻度、実行可能性スコアが付与されます。クラスターが Critical または High の場合、または AI が実行可能とマークした場合、自動的にインシデントにエスカレーションされます。
- 調査 — AI エージェントが明示的な仮説を立て、メトリクスとログに対してそれぞれを検証し、構造化されたレポートを生成します：最も可能性の高い根本原因、エビデンスチェーン、除外された仮説。
- 解決と記憶 — エージェントが設定した自律モード（Manual または Auto）のもと、ランブック を根本原因に対応付けて実行します。各解決は インシデントメモリ に記録され、次の調査を高速化します。
できること
| 機能 | 説明 | ガイド |
|---|---|---|
| シグナルソースの接続 | AWS、Slack、Teams、Webhook イベントを Pulse に流し込む | Pulse セットアップ |
| シグナルクラスターの管理 | 相関されたシグナルグループをレビュー、マージ、対応する | Clusters |
| AI 根本原因分析の実行 | 仮説駆動の調査を構造化された RCA レポートまで追う | 仕組み |
| 監視 Webhook の取り込み | PagerDuty、Datadog、CloudWatch などのアラートをルーティングする | Webhook 統合 |
| 修復の自動化 | エージェントに対応するランブックの手順を実行させる | Runbooks |
| 手動のインシデント記録 | Pulse の外で始まったインシデントを記録する | 手動ロギング |
| すべてのインシデントから学ぶ | 使えたものを再利用する — クエリ、テクニック、ランブックのステップ | インシデントメモリ |
| ループを測定する | ノイズ削減、クラスターの MTTR、コンバージョン率を追跡する | Pulse Analytics |
キーコンセプト
| 概念 | 意味 |
|---|---|
| Signal（シグナル） | 接続された任意のソースからの単一の正規化されたイベント |
| Cluster（クラスター） | 1 つのアイテムとして扱われる相関シグナルのグループ |
| Incident（インシデント） | クラスターがエスカレーションしたときに作成される調査オブジェクト |
| Runbook（ランブック） | 修復時にエージェントが対応付けて実行できる運用手順 |
| Incident memory（インシデントメモリ） | 過去のインシデントを解決したテクニック、クエリ、ステップの記録 |
はじめる
シグナルソースを接続する
AWS、Slack、Teams、Webhook ソースを接続して Pulse へのフィードを開始する。
Webhook 統合を設定する
PagerDuty、Datadog、CloudWatch などのアラートをレスポンスループに流し込む。
Runbooks を追加する
修復時にエージェントが実行できる手順を提供する。
調査の仕組みを確認する
仮説駆動の根本原因分析をエンドツーエンドで追う。