「サイトが開かない」という緊急事態に備えて、5分でできる応急処置と根本的な対策を神奈川のWeb制作会社が実案件をもとに解説。中小企業のWeb担当者向けの実践的なマニュアルです。
こんな状況で困っていませんか?
朝一番にオフィスに着いて、いつものようにWebサイトを確認してみると「このサイトにアクセスできません」の表示が。お客様からも「サイトが開かない」という問い合わせが数件届いている。
神奈川で20年以上Web制作を手がけてきた私たちFivenine Designでも、様々なクライアント様から緊急連絡をいただくことがあります。特に中小企業のWeb担当者の方は「何から手を付ければよいかわからない」「専門用語が難しくて...」というお悩みを抱えることが多いのではないでしょうか。
実際、あるクライアント様(製造業)では、展示会当日の朝にサイトが落ちてしまい、商談機会を逸する危険性がありました。その時の緊急対応で学んだのは、適切な初動対応ができれば、5分程度で復旧の道筋が見えてくるということです。
今回は、サーバー障害発生時の緊急復旧手順と、二度と同じ問題を起こさないための予防策を、実際の案件で効果があった方法をもとにお伝えします。
サーバー障害の主要な原因と影響度
まず、なぜサーバー障害が発生するのか、そして放置するとどんな影響があるのかを整理しましょう。
私たちがこれまで対応したケースを分析すると、障害原因の約6割がリソース不足(メモリ・CPU・ディスク容量)、約2割がアプリケーションエラー、残りがネットワークやハードウェア障害でした。
特に深刻なのは、障害が長引くことで生じるビジネスへの影響です。あるECサイトクライアント様では、1時間のダウンタイムで約50万円の売上機会損失が発生しました。また、採用サイトの場合、求職者が「会社が不安定なのでは?」という印象を持ってしまい、採用活動に悪影響が出たケースもあります。
障害レベルの分類
効果的な対応のため、障害を3段階に分類することをお勧めします:
- レベル1(軽微): 一部機能の不具合、表示速度の低下
- レベル2(重大): サイト全体がアクセス困難、断続的なエラー
- レベル3(致命的): 完全にアクセス不可、データ破損の可能性
今回解説するのは、レベル2〜3に該当する緊急事態への対処法です。
5分でできる緊急復旧手順
緊急時は冷静さが何より大切です。以下の手順を順番に実行してください。
1. 状況確認(1分)
最初に現状を正確に把握します。
# サーバーへの接続確認
ping your-domain.com
# HTTPレスポンスの確認
curl -I https://your-domain.com
複数のデバイス・ネットワークから確認することも重要です。社内ネットワークの問題の可能性もあるからです。
2. サーバーログの確認(1分)
# エラーログの確認(最新50行)
tail -50 /var/log/apache2/error.log
# または
tail -50 /var/log/nginx/error.log
# システムログの確認
tail -50 /var/log/syslog
実際のクライアント様の事例では、ログを確認することで「ディスク容量不足」が原因と即座に判明し、不要なログファイルを削除することで復旧できました。
3. リソース使用状況の確認(1分)
# CPU・メモリ使用率の確認
top
# ディスク使用量の確認
df -h
# プロセス一覧の確認
ps aux --sort=-%cpu | head -10
4. 緊急対応の実行(2分)
確認結果に基づいて、以下の対応を実行します:
# 一時ファイルの削除
sudo rm -rf /tmp/*
sudo rm -rf /var/tmp/*
# 古いログファイルの圧縮・削除
sudo find /var/log -name "*.log" -mtime +7 -exec gzip {} \;
sudo find /var/log -name "*.gz" -mtime +30 -delete
実際の成功事例
あるクライアント様(不動産会社)では、WordPressサイトが突然「データベース接続エラー」を表示するようになりました。上記の手順で確認したところ、MySQLサービスが停止していることが判明。サービスを再起動したところ、3分で完全復旧しました。
その後の調査で、サーバーの自動更新により一時的にサービスが停止していたことがわかり、更新設定を見直すことで再発を防止しました。
よくある失敗パターンと対処法
緊急時こそ、よくある失敗を避けることが重要です。私たちが経験した「やってはいけない」パターンをご紹介します。
失敗パターン1: パニック状態での設定変更
事例: あるクライアント様が、サイトダウン時に慌ててサーバー設定を複数箇所変更してしまい、復旧後に別の不具合が発生した。
対処法: 変更前に必ず設定ファイルのバックアップを取得する
# 設定変更前のバックアップ
sudo cp /etc/apache2/apache2.conf /etc/apache2/apache2.conf.backup.$(date +%Y%m%d_%H%M)
失敗パターン2: 原因調査を飛ばして再起動連発
事例: 「とりあえずサーバー再起動」を繰り返し、根本原因が特定できずに同じ障害が再発。
対処法: 必ずログ確認とリソースチェックを先に行い、原因を特定してから対応する。
失敗パターン3: バックアップなしでの復旧作業
事例: 緊急復旧中にデータベースを破損させてしまい、サイト全体を再構築することになった。
対処法: 作業前に現状のバックアップを必ず取得する
# データベースのバックアップ
mysqldump -u root -p database_name > backup_$(date +%Y%m%d_%H%M).sql
# ファイルのバックアップ
tar -czf website_backup_$(date +%Y%m%d_%H%M).tar.gz /var/www/html/
根本的な予防策の実装
緊急対応ができても、同じ問題が繰り返し発生しては意味がありません。ここでは、私たちが実際にクライアント様に提案して効果があった予防策をご紹介します。
1. 監視システムの導入
ZabbixやNagiosなどの監視ツールを導入し、問題発生前にアラートを受け取れるようにします。
# 簡易的な監視スクリプト例
#!/bin/bash
SITE_URL="https://your-domain.com"
EMAIL="[email protected]"
if ! curl -f -s $SITE_URL > /dev/null; then
echo "Site down: $SITE_URL" | mail -s "Alert: Site Down" $EMAIL
fi
2. 自動バックアップの設定
# 毎日午前2時にバックアップを実行するcronジョブ
0 2 * * * /usr/local/bin/backup-script.sh
3. リソース使用量の定期チェック
#!/bin/bash
# disk-check.sh
USED=$(df / | grep -vE '^Filesystem' | awk '{print $5}' | sed 's/%//g')
if [ $USED -gt 80 ]; then
echo "Disk usage is above 80%: ${USED}%" | mail -s "Disk Space Alert" [email protected]
fi
実際に、あるクライアント様(製造業)では、監視システム導入後、障害発生前にアラートを受け取れるようになり、ダウンタイムを90%削減することができました。
4. 定期的なパフォーマンステスト
月1回、負荷テストを実行してサーバーの限界値を把握しておくことをお勧めします。
# Apache Benchを使った簡易負荷テスト
ab -n 1000 -c 10 https://your-domain.com/
まとめと次のステップ
サーバー障害は「いつ起こるかわからない」からこそ、事前の準備と冷静な対応が重要です。私たちの経験では、適切な手順を踏むことで、復旧時間を大幅に短縮し、ビジネス影響を最小限に抑えることができています。
特に中小企業では、IT専任者がいないケースも多いため、「誰でもできる」手順書を作成しておくことが重要です。あるクライアント様では、非技術者のマーケティング担当者でも初動対応ができるよう、手順書を整備したところ、夜間・休日の障害にも迅速に対応できるようになりました。
すぐに実行すべきアクション:
- 現在のサーバー環境の把握(契約プラン、管理画面のログイン情報の整理)
- 緊急連絡先リストの作成(サーバー会社、制作会社、社内責任者)
- 基本的な監視設定の導入
- バックアップ体制の見直し
「まだサーバー障害を経験したことがない」という方も、いざという時に慌てないよう、今のうちに準備を整えておくことをお勧めします。また、「一度障害を経験したが、また同じことが起こりそうで不安」という方は、根本的な予防策の導入を検討してみてください。
Fivenine Designでは、緊急時サポートや予防的なインフラ改善のご相談も承っております。「うちのサーバー環境で大丈夫かな?」「もっと安定したシステムにしたい」といったお悩みがございましたら、お気軽にご相談ください。20年の実績をもとに、あなたのビジネスに最適なソリューションをご提案いたします。