メンテナンスと障害を分ける
更新作業の予定、実行中の処理、サーバー障害情報を確認します。公開ページと管理画面、静的ファイルで違いがあるか確認し、応答ヘッダーやエラー画面からCDN・接続元・アプリケーションのどこが返したかを調べます。
負荷の原因を探す
CPU、メモリ、ディスク、同時実行制限、PHP-FPM、DB接続、アクセス数を同じ時刻で確認します。少数の重い処理でも停止することがあるため、訪問者数だけで過負荷を否定しません。バックアップやWP-Cronの重複も確認します。
一時復旧と恒久対策を分ける
異常な処理や通信を限定して抑え、必要に応じてサーバー会社へ連絡します。無制限のリソース増強やプロセス再起動の繰返しは原因を隠すことがあります。キャッシュや実行条件の改善、重い処理の修正、適切なプラン変更を比較します。
再開後の確認
負荷が下がったこと、正常応答が続くこと、予約処理やフォームが滞留していないことを確認します。障害時間と原因、暫定策、恒久対応を記録し、同じ兆候を検知する監視を加えます。
一時的な負荷を調べる実務例
毎晩同じ時間に発生するなら、バックアップ、ウイルス検査、定期同期、キャッシュ削除などの実行時刻を重ねます。重い処理が同時に走る場合は、実行時間の分散や処理の分割を検討します。アクセスが増えていなくても、DBや外部APIの遅延で同時処理が滞留することがあります。
再起動の前に記録を確保する
再起動で一時復旧する場合も、実行中処理や負荷の手掛かりが失われることがあります。業務停止を長引かせない範囲で、ログ、メトリクス、時刻を保存し、実施理由と結果を残します。
よくある質問
サーバープランを上げれば解決しますか？
容量不足が原因なら有効な場合がありますが、製品不具合や外部待ちなどは残る可能性があります。何が上限へ達しているかを先に確認します。
メンテナンス表示の解除だけでよいですか？
更新が動いているか、独自メンテナンス機能かを確認します。過負荷や基盤障害を、残留ファイルの問題と取り違えないようにします。