本番サーバーの定期メンテナンス手順（毎日・毎週・毎月のチェック項目）

本番サーバーの定期メンテナンスは、「障害が起きる前に兆候を見つける作業」と「更新を安全に適用する作業」の2つに分けて考えると整理できます。この記事では、WordPress を載せた Linux サーバー（Ubuntu / Debian 系）を例に、毎日・毎週・毎月に行う確認項目と、更新作業を行うときの手順を、実際に使うコマンドとともに説明します。

メンテナンスを始める前の準備

定期作業を始める前に、次の3つを用意しておくと、作業のたびに迷わずに済みます。

• 作業記録: いつ・誰が・何を変更したかを残す場所。障害が起きたとき、直前の変更を追えるかどうかで復旧の速さが変わります。
• バックアップと復元手順: バックアップが取れていることと、そこから実際に戻せることは別の話です。復元手順を文書にしておきます。
• 検証環境: 本番と同じ構成の検証環境（ステージング）があれば、更新を先に試せます。無い場合は、少なくともサーバーのスナップショットを取れる状態にしておきます。

毎日の確認項目

毎日の確認は、異常がないかを短時間で見ることが目的です。可能な部分は監視ツールに任せ、人は通知を確認する形にすると続けやすくなります。

サービスとリソースの状態

systemctl --failed
uptime
df -h
free -h

systemctl --failed で停止しているサービスがないかを見ます。uptime の load average が仮想CPU数を継続して超えている場合は、処理が追いついていません。df -h ではディスク使用率を見ます。ディスクが一杯になると、データベースの書き込みやログの出力が止まり、サイト全体が表示できなくなることがあります。

バックアップの成否

バックアップのジョブが正常に終わったか、作成されたファイルのサイズが前日と比べて極端に小さくないかを確認します。サイズが急に小さくなっている場合は、途中で失敗しているか、対象のパスが変わっている可能性があります。

毎週の確認項目

パッケージの更新状況

sudo apt update
apt list --upgradable

セキュリティ更新は unattended-upgrades で自動適用している環境も多いと思います。その場合も、自動適用が実際に動いているかをログ（/var/log/unattended-upgrades/）で確認します。自動適用にしていない更新は、後述の手順で計画的に適用します。

カーネルやライブラリの更新後は再起動が必要な場合があります。

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs

ファイルが存在すれば、再起動待ちのパッケージがあります。再起動は利用者の少ない時間帯を選んで行います。

ログの確認

sudo journalctl -p err --since "7 days ago"
sudo tail -n 100 /var/log/nginx/error.log

エラーレベルのログを週単位で見て、繰り返し出ているものを拾います。WordPress の PHP エラーは、WP_DEBUG_LOG を有効にしている場合は wp-content/debug.log に出ます。本番で常時有効にする場合は、ログファイルがWebから読めない場所にあることを確認してください。

不審なログインの確認

sudo journalctl -u ssh --since "7 days ago" | grep -i "failed" | tail -n 20
last -n 20

サービス名は環境によって ssh または sshd です。見覚えのないアカウントでのログイン成功があれば、すぐに調査が必要です。WordPress の管理画面へのログイン失敗が多い場合は、ログイン試行の制限やWAFの導入を検討します。

毎月の確認項目

SSL証明書の有効期限

sudo certbot renew --dry-run
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate

Let's Encrypt は2025年に有効期限切れの通知メールを終了すると発表しています。自動更新が止まっていても通知が来ないことを前提に、--dry-run での更新確認と、外部の監視サービスによる期限チェックを組み合わせておくと安心です。

ディスクとログの肥大化

df -i
sudo journalctl --disk-usage
sudo du -sh /var/log/* | sort -h | tail

df -i は inode の使用率です。容量に余裕があっても、細かいキャッシュファイルが大量にあると inode が尽きてファイルを作れなくなります。journal が大きい場合は sudo journalctl --vacuum-time=30d で古いものを削除できます。ログローテーションの設定は sudo logrotate -d /etc/logrotate.conf で、実際には変更せずに動作を確かめられます。

アカウントと鍵の棚卸し

退職者や外部委託先のアカウント、使われていないSSH公開鍵（~/.ssh/authorized_keys）、WordPress の管理者ユーザーを見直します。不要なものは削除し、必要なものも権限が最小限かを確認します。

復元テスト

バックアップから検証環境へ実際に復元し、サイトが表示されるかを確かめます。復元できないバックアップは、障害時に役に立ちません。少なくとも数か月に一度は行います。

更新作業の手順

OSパッケージやWordPressの更新を計画的に行うときは、次の順に進めます。

1. 事前の告知とバックアップ

作業時間を関係者に伝え、作業直前にバックアップを取ります。WordPress のデータベースは WP-CLI で書き出せます。

cd /var/www/example.com
wp db export /backup/db-$(date +%F).sql
tar czf /backup/files-$(date +%F).tar.gz wp-content

VPS のスナップショット機能が使える場合は、あわせて取得しておくと、問題が起きたときにサーバーごと戻せます。

2. 検証環境で更新を試す

wp core check-update
wp plugin list --update=available
wp theme list --update=available

更新対象を確認し、検証環境で先に更新して、主要なページ・フォーム・決済などの動作を確認します。

3. 本番に適用する

sudo apt upgrade
wp core update
wp plugin update --all
wp core update-db

プラグインの一括更新は手軽ですが、問題が起きたときに原因の特定が難しくなります。重要なプラグインは個別に更新し、そのたびに表示を確認する方法も検討してください。

4. 更新後の確認

サービスの状態（systemctl --failed）、エラーログ、トップページと主要ページの表示、問い合わせフォームの送信を確認します。問題があれば、手順1で取得したバックアップやスナップショットから戻します。最後に、作業記録へ更新内容と結果を残します。

自動化と監視で手作業を減らす

ここで挙げた確認の多くは、監視ツールや cron で自動化できます。外形監視でサイトの応答を見る、ディスク使用率が一定を超えたら通知する、証明書の期限が近づいたら通知する、といった仕組みを用意すると、人が毎日コマンドを打つ必要は少なくなります。ただし、通知が届くこと自体も定期的に確認してください（2026年10月現在、監視サービスやツールの機能・無料枠は変わりやすいため、導入時に各サービスの最新情報を確認してください）。

まとめ

• 毎日はサービス・リソース・バックアップの成否を短時間で確認する
• 毎週は更新状況・再起動の要否・ログ・不審なログインを見る
• 毎月は証明書の期限・ディスクとinode・アカウント棚卸し・復元テストを行う
• 更新はバックアップ → 検証環境 → 本番 → 動作確認 → 記録の順に進める
• 確認作業は監視と自動化に任せ、通知が届くことも定期的に確かめる

• サーバー更新後の監視ポイント
• WordPressを安全に更新する方法