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

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

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

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

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

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

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

# Webhook通知の設定例
curl -X POST https://api.miterl.com/v1/alerts \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "monitor_id": "mon_abc123",
    "channel": "webhook",
    "endpoint": "https://your-app.example.com/webhook/incident",
    "events": ["monitor.down", "monitor.recovery"]
  }'

監視間隔は1分に設定しておけば、最大でも1分以内に障害を検知できます。

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

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

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

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

初動チェックリスト

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

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

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

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

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

テンプレート例:

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

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

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

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

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

復旧後、24時間以内にインシデントレポートを作成します。以下の項目を含めましょう。

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

まとめ

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

ドキュメントでMiterlの通知設定を確認し、Playgroundでアラートの動作をテストしてみてください。他の制作会社の運用事例はブログでも紹介しています。