障害対応を「事務作業」から「エンジニアリング」へ：Datadog Incident Management 完全自動化の真髄
「障害発生」の通知が届いた瞬間、君たちは何をしている？
Slackで専用チャンネルを手動作成し、関係者を招待し、監視画面のURLを貼り付け、事象をメモする……。もしこの「儀式」に5分以上費やしているなら、それはMTTR（平均復旧時間）をドブに捨てているのと同じだ。
真のオブザーバビリティとは、監視することではない。「システムが異常を検知した瞬間、人間が最もクリエイティブな解決に集中できる状態を自動構築すること」にある。
本稿では、Datadog Incident Managementを核とした、障害対応の「完全自動化ワークフロー」を構築する極限の知見を授ける。
—
1. 脳直結のショートカットと「神」ワークスペース設定
DatadogのUIをマウスでカチカチ操作している時間は、障害対応においては「死」を意味する。
必須のキーボードショートカット
- `Shift + Space`: Datadogのどこからでもコマンドパレットを呼び出す。ダッシュボードへの移動や特定のモニター検索をミリ秒で実行せよ。
- `G` + `D`: ダッシュボード一覧へ即時遷移。
- `G` + `I`: インシデント管理画面へ即時遷移。
現場で導入すべき「神」プラグイン
- Datadog Slack Appの「Incident Channels」設定: これを入れない理由はない。トリガー条件（例：High Severityのアラート）に一致した瞬間、自動でSlackチャンネルを作り、その中に「ダッシュボードのリンク」「Runbook（運用手順書）」をピン留めする。これだけで「状況把握のタイムラグ」がゼロになる。
—
2. 障害発生をトリガーにした「自動ワークフロー」の設計
インシデント発生時のワークフローは、人間が介入する余地を最小限に削る。Datadogの Workflow Automation を使って、以下のステップを自動化する。
1. Slackチャンネル生成: チーム名とインシデントIDを冠したチャンネルを生成。
2. 関係者自動招待: `on-call` ローテーションに基づき、オンコールエンジニアを自動でチャンネルへアサイン。
3. コンテキスト注入: 該当するサービスの「直近のデプロイメント情報」と「関連するログの直近10分間」をチャンネルに投げる。
構成例：Workflow Automation（JSON定義）
このワークフローは、モニターのステータス変更を検知して自動でコンテキストを収集する。
{
“name”: “Incident Auto-Response”,
“steps”: [
{
“action”: “slack.create_channel”,
“inputs”: { “name”: “incident-{{incident.id}}” }
},
{
“action”: “datadog.get_recent_deployments”,
“inputs”: { “service”: “{{incident.service}}” }
// インシデントの直近の変更履歴を自動取得し、Slackへポスト
},
{
“action”: “slack.post_message”,
“inputs”: {
“channel”: “incident-{{incident.id}}”,
“text”: “🚨 障害発生: {{incident.title}}\n🔗 ダッシュボード: {{incident.dashboard_url}}\n🔍 関連ログ: {{incident.log_search_url}}”
}
}
]
}
—
3. ポストモーテム作成を自動化する「ベストプラクティス」
多くのチームが「ポストモーテムを書くのが面倒で、記憶が風化する」という罠に陥っている。これを防ぐ唯一の解は、「インシデント中に情報を蓄積し、終了時にボタン一つでドキュメント化する」ことだ。
実践テクニック：Event Streamの活用
インシデント対応中にSlackでやり取りした「重要な決定事項」や「復旧コマンド」を、DatadogのEventにタグ付けして残せ。
- `#incident-123` というハッシュタグをSlackで打つだけで、Datadogのインシデントタイムラインに自動同期される設定を入れるのだ。
ポストモーテム生成の自動化ルール:
1. インシデントクローズ時に、ワークフローから自動的にGoogle Docs/Notion APIを叩く。
2. タイムライン（Slackのやり取り）、影響範囲、復旧までに実行したコマンドの一覧をテンプレートに埋め込んで生成する。
3. エンジニアは「なぜ起きたか（Root Cause）」と「再発防止策（Action Items）」を追記するだけで終わる。
—
4. チームで共有すべき「設定の掟」
バラバラな設定は、障害時の混乱を招く。以下のルールをチームの `Terraform` や `Pulumi` でコード化して管理せよ。
- モニターの階層構造化: `service:auth`, `env:prod`, `severity:critical` といったタグ付けを強制する。これがないと、自動生成されるインシデントの優先度が判定できない。
- Runbookのコード管理: 監視ツール上のURLではなく、リポジトリ内の `/docs/runbooks/` への相対パスを全モニターに記述せよ。
モニター設定のYAML例（Infrastructure as Code）
良いモニター設定の例：コンテキストが明確
name: “Service Auth: High Error Rate”
type: “query alert”
query: “sum(last_5m):sum:trace.auth.errors{env:prod} > 10”
message: |
🚨 認証エラー多発中
{{#is_alert}}
Runbook: https://github.com/my-org/service-auth/blob/main/docs/runbook.md
担当: @slack-auth-team
{{/is_alert}}
tags:
- “service:auth”
- “team:identity”
- “severity:critical”
—
最後に：エンジニアへのメッセージ
ツールは単なる手段だ。しかし、Datadog Incident Managementを使いこなすことは、「障害という名のノイズ」を最小化し、君たちが「本来書くべきコード」に集中するための究極の投資となる。
今日から、手動で行っている作業を一つずつ、Workflow Automationへ移せ。MTTRが短縮され、ポストモーテムが自動で完成する未来は、君たちの手元にある。
さあ、次は君たちがコードで監視をハックする番だ。