サイト障害発生時の対応フロー完全ガイド｜検知から復旧・報告までの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分以内に障害を検知できます。
ステップ2: 初動 — 状況を確認する
アラートを受け取ったら、まず以下を確認します。
- 影響範囲: 単一サイトか、複数サイトか
- 障害の種類: サーバー応答なし、SSL期限切れ、DNS異常など
- 直前の変更: デプロイやDNS変更を行っていないか
Miterlのダッシュボードで、障害が発生したモニターのステータスとレスポンスログを確認すれば、原因の切り分けを素早く行えます。
初動チェックリスト
□ アラートの内容を確認（どのサイト、どの監視項目か）
□ 影響範囲を特定（他サイトへの波及はないか）
□ 障害種別を判定（サーバー / DNS / SSL / ネットワーク）
□ 直近の変更履歴を確認
□ インシデント担当者をアサイン
ステップ3: 連絡 — クライアントに状況を伝える
障害を認識してから15分以内にクライアントへ第一報を送りましょう。この時点で原因が分かっていなくても構いません。
第一報に含める内容は以下の3点です。
- 障害を認識していること
- 現在調査中であること
- 次回の報告予定時刻
テンプレート例:
○○様のWebサイトにおいて、現在アクセスしづらい状況を確認しております。原因を調査中です。次回ご報告は30分後を予定しています。
ステップ4: 復旧 — 問題を解決する
原因に応じた復旧作業を行います。よくある障害パターンと対応例を紹介します。
| 障害パターン | よくある原因 | 対応 |
|---|---|---|
| HTTP 503 | サーバー過負荷 | プロセス再起動、スケールアップ |
| SSL証明書エラー | 証明書の期限切れ | 証明書の再発行・更新 |
| DNS解決失敗 | DNS設定ミス | レコードの修正、TTL確認 |
| タイムアウト | ネットワーク障害 | ホスティング事業者へ確認 |
復旧作業中もクライアントへの経過報告を忘れないようにしましょう。
ステップ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つです。
- 発生日時と復旧日時（ダウンタイムの長さ）
- 影響範囲（影響を受けたサイト・機能）
- 原因（技術的な原因を分かりやすく説明）
- 対応内容（時系列での対応ログ）
- 再発防止策（具体的なアクション項目）
まとめ
障害対応は事前準備がすべてです。フローを明文化し、チーム内で共有しておくことで、いざというときに冷静に対応できます。Miterlの自動検知と通知機能を活用して、「検知→対応」のサイクルを高速化しましょう。
対応フローを整備したら、定期的にドリル（擬似障害訓練）を実施してチームの練度を保つことも重要です。Miterlのドリル機能では、ステータスページには表示されない社内限定の擬似障害を発生させ、通知〜初動対応〜報告までの実動確認が可能です。フローを「知っている」から「体で動ける」状態に高めておくと、深夜・休日の本番障害でも慌てずに対処できます。
ステップ5の事後レポートを効率よく作成するためには、フォーマット化されたテンプレートがあると便利です。「インシデントレポートのテンプレートと書き方——制作会社向け障害報告書の実例」では、クライアントへ提出できる完成度の障害報告書のフォーマットをコピペ可能な形式で提供しています。
ドキュメントでMiterlの通知設定を確認し、無料で登録してアラートの動作をテストしてみてください。他の制作会社の運用事例はブログでも紹介しています。