Datadog Incident Managementの「その先」へ：Webhookで構築する自律型インシデント応答システム
世の中には「Datadogのインテグレーションを設定したから安心だ」と満足しているチームが多すぎる。しかし、PagerDutyやSlackの標準連携だけで満足しているのなら、それは「障害の発生を通知しているだけ」のレベルだ。
真のオブザーバビリティとは、障害発生から対応までの平均時間（MTTR）を極限まで削り取り、人間の判断コストを「自動化」で排除することにある。
今日は、Datadog Incident Managementを単なる「通知のハブ」から「自律型エスカレーションエンジン」へと進化させる、プロの現場で使われる実装テクニックを伝授する。
—
1. なぜ標準インテグレーションを超えなければならないのか？
標準のSlack/PagerDuty連携は便利だが、組織がスケールするにつれ以下の課題が露呈する。
- コンテキストの欠如: アラートが飛んできても、「誰が責任者か」「どのドキュメントを見るべきか」の紐付けに時間がかかる。
- 「とりあえず通知」の弊害: ノイズの多いアラートでエンジニアが疲弊し、本当に重要なインシデントを見逃す。
我々が目指すべきは、「Datadogのインシデント発生をトリガーに、必要なコンテキストをすべて付与した状態で、適切な担当者の作業環境にタスクを生成する」というパイプラインだ。
—
2. Webhook実装のベストプラクティス：Payloadの再定義
Datadogから送信されるJSONは膨大だ。これをそのまま受け取るのではなく、中継サーバー（AWS LambdaやGoogle Cloud Functions）でフィルタリングと強化を行い、社内システムへ流すのが鉄則だ。
推奨のペイロードハンドリング例 (Python/FastAPI)
中継サーバーで受け取るDatadog Webhookのデコード例
from fastapi import FastAPI, Request
app = FastAPI()
@app.post(“/webhook/datadog-incident”)
async def handle_incident(request: Request):
payload = await request.json()
# 1. 必要な情報の抽出
incident_id = payload.get(“id”)
title = payload.get(“attributes”, {}).get(“title”)
# 2. 独自の「重要度変換ロジック」を噛ませる
# Datadogのseverityを社内ランクに変換し、通知先を動的に決定
severity = payload.get(“attributes”, {}).get(“severity”)
# 3. 独自のSlackボット/Jiraへペイロードを再構築して転送
# ここで「Runbookへの直接リンク」や「過去の類似インシデント検索結果」を付与する
return {“status”: “dispatched”}
—
3. 開発スピードを加速させる「エンジニアの生存戦略」
隠れたキーボードショートカット (Datadog UI)
- `Cmd + K` (Mac) / `Ctrl + K` (Win): コマンドパレットの起動。これを知らないとDatadogの操作は永遠に遅い。インシデントの検索、監視の切り替えはここから行う。
- `?`: キーボードショートカット一覧。実はこれを見直すだけで、毎日5分の無駄が消える。
絶対入れるべき「神」設定：タグの強制化
チーム開発における最大の敵は「タグの不一致」だ。`team:xxx` や `env:xxx` がないメトリクスは、インシデント時に「誰が直すべきか」を特定不能にする。
- TerraformによるIaC管理: 設定をWeb UIでポチポチするのは禁止。必ずTerraformで定義する。
Terraformでの監視設定例（タグの強制）
resource “datadog_monitor” “high_latency” {
name = “Service Latency High”
type = “metric alert”
query = “avg(last_5m):avg:http.request.duration{env:production,team:core} > 500”
message = “Critical: {{#is_alert}}@slack-channel-alerts{{/is_alert}} \n Runbook: https://docs.internal/runbooks/latency”
# インシデント管理を自動紐付け
notify_audit = true
}
—
4. チームで共有すべき「オブザーバビリティ・マニフェスト」
1. Dashboard as Code: ダッシュボードは `datadog-terraform` 等で管理し、リポジトリに存在しない監視は「存在しない」と見なす。
2. アラートは「アクション」に直結させる: 「様子を見る」というアラートは即削除。必ず「何をすれば解決するか」をメッセージに含める。
3. Webhookをハブにする: インシデント発生時は、PagerDutyだけでなく、Jiraのチケット自動起票、社内Wikiの該当ページ更新までをWebhookで一気通貫させる。
—
結びに：監視は「作業」ではなく「エンジニアリング」である
監視を「単なる見張り番」と捉えているうちは、あなたのチームのプロダクトは成長しない。
DatadogのWebhookをハックし、障害対応フローをコードで記述し始めた時、初めてインシデントは「排除すべきノイズ」から「システムの改善ポイントを教えるシグナル」へと変わる。
まずは今日、あなたのWebhookエンドポイントに「何が足りないか」を問いかけるところから始めてほしい。それが、世界最高峰のオブザーバビリティを構築するための第一歩だ。