サーバー障害対応チェックリスト - ダウン発生時の7ステップ
サーバーダウン・障害発生時の対応手順を7ステップで解説。影響範囲の特定、ログ確認、再起動、バックアップ復旧、ポストモーテムまでのベストプラクティス。
TL;DR
サーバー障害発生時は、①影響範囲の特定 → ②ログ確認 → ③再起動試行 → ④バックアップ復旧 → ⑤外部サポート → ⑥ステータス更新 → ⑦ポストモーテムの順で対応します。このチェックリストを印刷して、緊急時にすぐ参照できるようにしましょう。
障害対応の7ステップ
ステップ1: 影響範囲の特定（最初の3分）
まず、何が影響を受けているかを確認します。
- ✅ サイト全体がダウンしているか、特定ページのみか？
- ✅ 外部からアクセスできないか、内部からもアクセスできないか？
- ✅ ブラウザで直接IPアドレスにアクセスできるか？（DNS問題の切り分け）
- ✅ SSL証明書エラーが出ていないか？
- ✅ 他のサービス（API、管理画面）は正常か？
ツール: UpGuardianのダッシュボードで、複数サイトの状態を一覧確認
ステップ2: ログの確認（3〜10分）
サーバーログ、アプリケーションログ、エラーログを確認します。
- ✅ Webサーバーログ（Nginx/Apache）でHTTPエラーコードを確認
- ✅ アプリケーションログで例外スタックトレースを確認
- ✅ データベースログで接続エラーやクエリエラーを確認
- ✅ システムログ（syslog/journald）でメモリ不足やディスク満杯を確認
よくあるログの場所:
- Nginx:
/var/log/nginx/error.log - Apache:
/var/log/apache2/error.log - Node.js:
pm2 logs - Docker:
docker logs [container_id]
ステップ3: 再起動の試行（10〜15分）
ログでエラー原因が特定できない場合、再起動を試みます。
- ✅ Webサーバーの再起動:
sudo systemctl restart nginx - ✅ アプリケーションの再起動:
pm2 restart app - ✅ データベースの再起動:
sudo systemctl restart postgresql - ✅ サーバー全体の再起動（最終手段）:
sudo reboot
注意: 再起動前に、必ず影響範囲を確認し、本番環境では慎重に実施しましょう。
ステップ4: バックアップからの復旧（15〜60分）
再起動で解決しない場合、バックアップから復旧します。
- ✅ 最新のバックアップの日時を確認
- ✅ データベースのバックアップを復元
- ✅ アプリケーションコードを前バージョンにロールバック
- ✅ 設定ファイル（nginx.conf等）を復元
復旧後の確認:
- トップページが表示されるか
- ログイン機能が動作するか
- 主要APIエンドポイントが200を返すか
ステップ5: 外部サポートへの連絡（30分〜）
自力で解決できない場合、外部サポートに連絡します。
- ✅ ホスティング会社のサポート（AWS、さくら、エックスサーバーなど）
- ✅ 開発ベンダーやフリーランスエンジニア
- ✅ SaaSツールのサポート（Cloudflare、Vercelなど）
連絡時に伝える情報:
- 障害発生時刻
- 影響範囲（全体ダウン / 特定ページのみ）
- エラーメッセージやログの抜粋
- 直前の変更内容（デプロイ、設定変更など）
ステップ6: ステータスページの更新（障害発生後すぐ）
ユーザーに障害を通知し、対応中であることを伝えます。
- ✅ ステータスページを「障害発生中」に更新
- ✅ Twitterやメールで障害を通知
- ✅ 復旧見込み時刻を伝える（分からない場合は「調査中」）
テンプレート例:
【障害のお知らせ】
現在、当サービスで障害が発生しており、アクセスできない状態となっております。
復旧作業を進めておりますので、今しばらくお待ちください。
ご迷惑をおかけし、誠に申し訳ございません。
（2026年2月17日 14:30）
ステップ7: ポストモーテム（障害復旧後24時間以内）
障害が復旧したら、必ず振り返りを実施します。
- ✅ 障害の原因を特定
- ✅ 再発防止策を策定
- ✅ チーム内で共有（ドキュメント化）
- ✅ 顧客に報告（必要に応じて）
ポストモーテムに含めるべき項目:
- 障害発生時刻と検知時刻
- 影響範囲（ダウンタイム、影響ユーザー数）
- 根本原因（Root Cause）
- 対応のタイムライン
- 再発防止策
障害の主な原因と対処法
1. メモリ不足（OOM Killer）
症状: サーバーが突然応答しなくなる、プロセスが強制終了される
対処法:
- メモリ使用量を確認:
free -h - プロセスを再起動
- 長期的: サーバーのメモリを増やす、メモリリークを修正
2. ディスク満杯
症状: ログファイルが書き込めない、データベースが書き込めない
対処法:
- ディスク使用率を確認:
df -h - 不要なログファイルを削除:
sudo journalctl --vacuum-size=1G - 長期的: ログローテーション設定、ディスク容量を増やす
3. SSL証明書の期限切れ
症状: ブラウザで「接続がプライベートではありません」エラー
対処法:
- 証明書の有効期限を確認:
openssl s_client -connect example.com:443 | openssl x509 -noout -dates - Let's Encryptの場合:
sudo certbot renew - 長期的: UpGuardianでSSL証明書監視を有効化
4. DNS設定ミス
症状: ドメイン名でアクセスできないが、IPアドレスではアクセスできる
対処法:
- DNS解決を確認:
dig example.com - DNSレコードが正しいか確認（A、CNAME、MXレコード）
- DNSキャッシュのクリア:
sudo systemd-resolve --flush-caches
5. データベース接続エラー
症状: 「Database connection failed」エラー
対処法:
- データベースが起動しているか確認:
sudo systemctl status postgresql - 接続数制限を確認:
SHOW max_connections; - 接続プールを再起動
障害対応を効率化するツール
1. アップタイム監視ツール
UpGuardianで、障害を即座に検知し、Slack・メール・Webhookで通知します。
2. ログ管理ツール
Better Stack（旧Logtail）やDatadogで、複数サーバーのログを一元管理し、検索・分析できます。
3. インシデント管理ツール
PagerDutyやOpsGenieで、オンコール体制を構築し、担当者へのエスカレーションを自動化します。
4. ステータスページツール
Statuspage.ioやAtlassian Statuspageで、ユーザーに障害状況をリアルタイムで通知します。
障害対応のベストプラクティス
1. Runbook（手順書）を作成
障害が発生する前に、対応手順をドキュメント化しておきます。深夜のアラートでパニックにならないよう、手順を明確にしましょう。
2. オンコール体制の構築
週ごとに担当者を決め、深夜・休日のアラートに対応できる体制を作ります。1人に負担が集中しないよう、ローテーションを組みましょう。
3. 定期的な障害訓練
実際に本番環境の一部を停止させ、復旧手順が機能するかテストします（カオスエンジニアリング）。
4. アラートの優先度設定
すべてのアラートを「Critical」にすると、重要な障害を見逃します。以下のように優先度を設定しましょう：
- Critical: 全サービスダウン、決済システムダウン
- Warning: レスポンスタイム3倍、SSL証明書30日前
- Info: デプロイ成功、定期メンテナンス完了
よくある質問
Q: 障害対応の平均時間（MTTR）はどれくらいですか？
A: 日本企業の平均は6時間12分ですが、グローバル平均は175分（約3時間）です。監視ツールと自動復旧を導入すると、1時間以内に短縮できます。
Q: 深夜のアラートにどう対応すべきですか？
A: まず影響範囲を確認し、Critical（全体ダウン）なら即対応、Warning（一部遅延）なら翌朝対応でOKです。優先度を明確にしましょう。
Q: 障害対応の練習はどうすればいいですか？
A: ステージング環境で意図的にサーバーを停止させ、復旧手順を実践しましょう。四半期に1回の訓練が推奨されます。
まとめ
サーバー障害は避けられませんが、迅速な検知と明確な対応手順があれば、ダウンタイムを最小限に抑えられます。UpGuardianで障害を即座に検知し、このチェックリストに沿って対応しましょう。