サイト障害発生時の対応フロー完全ガイド｜検知から復旧・報告までの5ステップ

障害発生時に「何から手をつけるか」決まっていますか？

クライアントのサイトがダウンしたとき、対応手順が明確でないと、復旧が遅れるだけでなく、クライアントからの信頼も失います。制作会社として、障害対応フローを事前に整備しておくことは、保守サービスの品質を左右する重要なポイントです。

この記事では、検知→初動→連絡→復旧→報告の5ステップで障害対応の流れを解説します。

ステップ1: 検知 — 障害をいち早く把握する

障害対応は「気づく速さ」で決まります。人手による確認では限界があるため、自動監視ツールの導入が必須です。

Miterlを使えば、サイトの異常を自動検知し、Slack・メール・Webhookなど複数チャネルで即座に通知を受け取れます。

通知先（アラート連絡先）はダッシュボードで作成し、各モニターに紐付けます。APIからモニターを作成する場合は、GET /alert-contacts で取得した通知先のIDを alert_contact_ids に指定します。

# 登録済みの通知先（アラート連絡先）の一覧とIDを取得
curl -s https://miterl.com/api/v1/alert-contacts \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '.data[] | {id, type, name}'

取得したIDをモニター作成時に渡せば、ダウン・復旧の通知先として紐付けられます。監視間隔（interval_seconds）を60秒に設定しておけば、最大でも1分以内に障害を検知できます。

検知の最も基本となるのがHTTPステータスコードによる応答チェックです。コード別（4xx/5xx）にどうアラートを設計するかは「HTTP応答障害を検知する監視設定ガイド」で詳しく解説しています。

ステップ2: 初動 — 状況を確認する

アラートを受け取ったら、まず以下を確認します。

1. 影響範囲: 単一サイトか、複数サイトか
2. 障害の種類: サーバー応答なし、SSL期限切れ、DNS異常など
3. 直前の変更: デプロイやDNS変更を行っていないか

Miterlのダッシュボードで、障害が発生したモニターのステータスとレスポンスログを確認すれば、原因の切り分けを素早く行えます。

初動チェックリスト

□ アラートの内容を確認（どのサイト、どの監視項目か）
□ 影響範囲を特定（他サイトへの波及はないか）
□ 障害種別を判定（サーバー / DNS / SSL / ネットワーク）
□ 直近の変更履歴を確認
□ インシデント担当者をアサイン

ステップ3: 連絡 — クライアントに状況を伝える

障害を認識してから15分以内にクライアントへ第一報を送りましょう。この時点で原因が分かっていなくても構いません。

第一報に含める内容は以下の3点です。

• 障害を認識していること
• 現在調査中であること
• 次回の報告予定時刻

テンプレート例:

○○様のWebサイトにおいて、現在アクセスしづらい状況を確認しております。原因を調査中です。次回ご報告は30分後を予定しています。

連絡が届かないリスクをエスカレーションで防ぐ

ステップ3の連絡フローを設計する際、「担当者がSlackを見ていない」「スマホが圏外」というケースも想定する必要があります。通知が1経路しかない場合、その経路が使えないだけで初動が大幅に遅れます。こうしたリスクを防ぐのがエスカレーション設計です。最初はSlackに通知し、10分応答がなければLINEに、それでも応答がなければ別の担当者へ——という段階的な引き上げルールを事前に決めておくことで、夜間・休日の担当者不在時でも障害を取りこぼしません。エスカレーションの具体的な組み立て方は「監視アラートのエスカレーション設計｜夜間・休日障害を誰に・どう通知するか」を参照してください。

ステップ4: 復旧 — 問題を解決する

原因に応じた復旧作業を行います。よくある障害パターンと対応例を紹介します。

復旧作業中もクライアントへの経過報告を忘れないようにしましょう。

ステップ5: 報告 — 事後レポートを作成する

復旧後、24時間以内にインシデントレポートを作成します。MiterlのAPIを使えば、障害の発生日時・ダウンタイム・復旧日時を自動で取得し、レポート作成の手間を大幅に削減できます。

# インシデント履歴をAPIで取得（対象モニターの解決済みインシデント）
curl -s "https://miterl.com/api/v1/incidents?monitor_id=1&status=resolved" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '[.data[] | {cause, started_at, resolved_at, duration_seconds}]'

レポートに含めるべき項目は以下の5つです。

1. 発生日時と復旧日時（ダウンタイムの長さ）
2. 影響範囲（影響を受けたサイト・機能）
3. 原因（技術的な原因を分かりやすく説明）
4. 対応内容（時系列での対応ログ）
5. 再発防止策（具体的なアクション項目）

まとめ

障害対応は事前準備がすべてです。フローを明文化し、チーム内で共有しておくことで、いざというときに冷静に対応できます。Miterlの自動検知と通知機能を活用して、「検知→対応」のサイクルを高速化しましょう。

ただし、検知フローを強化するほど「アラート疲れ」のリスクも高まります。誤検知や計画停止中の通知が増えると、本番の重大アラートが埋もれて初動が遅れます。quiet hours・メンテナンスウィンドウ・リトライ設定を組み合わせて通知を絞る方法は「アラート疲れを防ぐ監視設定」で詳しく解説しています。

対応フローを整備したら、定期的にドリル（擬似障害訓練）を実施してチームの練度を保つことも重要です。Miterlのドリル機能では、ステータスページには表示されない社内限定の擬似障害を発生させ、通知〜初動対応〜報告までの実動確認が可能です。フローを「知っている」から「体で動ける」状態に高めておくと、深夜・休日の本番障害でも慌てずに対処できます。

ステップ5の事後レポートを効率よく作成するためには、フォーマット化されたテンプレートがあると便利です。「インシデントレポートのテンプレートと書き方——制作会社向け障害報告書の実例」では、クライアントへ提出できる完成度の障害報告書のフォーマットをコピペ可能な形式で提供しています。発生・進捗・復旧の各タイミングでクライアントへ送るメール文面は「障害通知メールのテンプレート集」にまとめてあり、報告書と組み合わせて使えます。

ドキュメントでMiterlの通知設定を確認し、無料で登録してアラートの動作をテストしてみてください。障害対応をWebhookでさらに自動化したい場合は「Webhook連携でDevOpsを強化する」も参考にしてください。新規サイト公開前の監視設定チェックリストは「Webサイト公開前の監視設定チェックリスト」にまとめています。障害時にメール通知が届かない・迷惑メール扱いになるトラブルはSPF/DMARC設定の崩れが原因である場合が多く、障害対応フローとあわせて「SPF・DMARC・DKIM・MXレコードの設定と常時監視の方法」で確認しておくと安心です。他の制作会社の運用事例はブログでも紹介しています。

障害対応フローの第一歩は「検知してから何分で初動できるか」で決まります。HTTP応答の障害を早期に検知するための監視設定——レスポンスタイムの閾値・ステータスコードのチェック・異常時のアラートトリガー——については「レスポンスタイム監視ガイド：HTTP応答障害を早期検知する方法」で詳しく解説しています。