Incident Management

結論 - 宣言から振り返りまでを 1 つの画面に残し、人数で払う

イベントやアラートは「システムに何が起きたか」の記録で、インシデントは「人がどう対応したか」の記録です。Datadog Incident Management は後者を担い、障害を宣言した時刻から、誰が指揮し、何を決め、いつ収まり、何を学んだかまでを 1 つの画面に残します。導入にインストールは要らず、インシデントを宣言した時点から使えます (2026 年 9 月時点・出典: Incident Management)。モニターやダッシュボードと同じ場所にあるため、対応中に見たグラフをそのまま記録に貼れ、後から「あの時どのグラフを見て判断したか」を再現できます。料金は監視対象の台数ではなく、記録を書き換える人の数、つまりシート数で決まります。以下では、状態の進み方、宣言時に埋める項目、宣言の入口、記録の集まり方、On-Call との分業、シートの数え方、振り返りの回し方の順にたどります。

状態は 3 段で進む: Active / Stable / Resolved

インシデントの状態は既定で 3 つあり、意味が公式ドキュメントで定義されています。Active は他者に影響が出ている状態、Stable は影響は止まったが調査が終わっていない状態、Resolved は影響が止まり調査も完了した状態です。設定で Completed という状態を足すこともでき、各状態の説明文はカスタマイズできます (2026 年 9 月時点・出典: Describe an Incident)。Active と Stable を分けているのが要点です。「もう影響は出ていないが原因は分かっていない」という中間の状態を名前で持てるので、経営層への報告は Stable で一度落ち着かせ、技術側は Resolved に向けて調査を続ける、という切り分けが記録の上で成立します。

宣言のときに埋めるのは題名と重大度と指揮者

宣言のモーダルにある中心の項目は 3 つです。題名 (必須)、重大度 (必須)、そして対応を率いる Incident Commander です。重大度は既定で SEV-1 (最も重い) から SEV-5 (最も軽い) の 5 段階で、段階の数と説明は設定で変えられます。宣言の項目は設定で増やせ、状態や影響、根本原因、検知方法、影響を受けたサービスなどを後から更新できます。対応チームの編成には独自の対応者ロールを定義して使えます (2026 年 9 月時点・出典: Declare an Incident と Incident Management)。重大度の説明文は組織が決めるものなので、ここでは決め方の骨格だけを示します。

重大度で迷ったときの規則を 1 つだけ決めておくと宣言が速くなります。「迷ったら 1 段重くして宣言し、Stable にする時点で下げる」のように、後から下げられることを前提にした規則です。

どこから宣言できるか

宣言の入口は 1 つではありません。公式ドキュメントは、インシデント一覧の画面、モニター、セキュリティシグナル、漏えいしたシークレット、作業項目、グラフ、Synthetic テスト、Datadog クリップボード、On-Call のページ、Slack、Google Chat、引き継ぎ通知からの宣言を載せています (2026 年 9 月時点・出典: Declare an Incident)。実務で使う頻度が高いのはモニターと Slack の 2 つです。

入口が多い理由は、宣言の遅れが記録の欠けにそのまま繋がるからです。「後で正式に登録する」運用では最初の 30 分の判断が残りません。モニターからの自動宣言は、その 30 分を機械に埋めさせる手段です。ただし自動宣言を全モニターに付けると記録がノイズで埋まるので、重大度 high に値するモニターに限るのが順当です。

タイムラインと Slack が記録を 1 か所に集める

記録の本体はタイムラインです。コメント、グラフ、リンクを時刻つきで積み上げ、状態や重大度の変更もここに残ります。Slack から宣言するとインシデント専用のチャンネルが作られ、そのチャンネルでの発言はタイムラインに同期されます。関係者への通知は設定でき、対応の経過を利害関係者へ知らせ続けられます (2026 年 9 月時点・出典: Incident Management と Declare an Incident)。

ここで重要なのは、Slack を捨てなくて良いことです。対応の会話は Slack のまま、記録の正はインシデントのタイムラインに置く。この二層にすると、翌日に「誰が何を決めたか」を辿るために Slack を上下にスクロールする作業が消えます。

On-Call が呼び、Incident Management が記録して閉じる

On-Call と Incident Management は同じ Incident Response の枝にあり、役割で分かれます。On-Call は「今、当番の誰を呼ぶか」を決めて呼び出しを届ける機能で、Incident Management は「呼ばれた後に何が起き、どう閉じたか」を残す機能です。接点は双方向にあり、On-Call のページをインシデントへ昇格させることも、インシデントの中からチームを手動または自動で呼ぶこともできます (2026 年 9 月時点・出典: Incident Management)。

どちらか片方だけでも成立します。呼び出しは既存のツールで回っていて記録だけが欠けている組織は Incident Management から、逆に記録は Slack とスプレッドシートで足りているが夜間の呼び出しが人手の組織は On-Call から入るのが自然です。両方を使うなら次の節の一括 SKU が関わります。

料金はシート - 記録を書き換える人だけを数える

シートが必要になる操作と要らない操作は、公式ドキュメントが列挙しています。この区別は Datadog の画面でも Slack や Microsoft Teams の連携経由でも同じです (2026 年 9 月時点・出典: Incident Response Billing)。

読み方は 1 行で済みます。同じ人が呼び出しも受け、記録も書き換えるなら、両方を同梱する一括 SKU のほうが単独 2 つを足すより低く、片方しか行わない人にはその単独 SKU を当てます。料金全体の中での位置づけは料金体系の読み解きを参照してください。本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。

振り返りを回すための最小ルール

ポストモーテムは、何が起き、なぜ起き、再発を防ぐために何をするかを構造化した文書です。Resolved の後に Post-Incident タブでテンプレートを選んで生成すると、インシデントのデータが流し込まれ、Notebooks や Confluence など設定した先に文書ができてインシデントに紐づきます (2026 年 9 月時点・出典: Postmortems)。生成は 1 操作ですが、振り返りが回るかどうかは前後の規則で決まります。

最も効くのは 2 つ目です。ポストモーテムの品質は文章力ではなく、対応中に残した判断の行数で決まります。SLO を運用している組織なら、エラーバジェットを削った障害から順に振り返る優先順位も使えます。Error Tracking が「同じエラーの束」を追うのに対し、Incident Management が追うのは「1 回の障害への人の対応」です。原因の側は Error Tracking、判断の側はインシデントのタイムライン、と読み分けてください。