本番へのリリース直後、Webサービスが本当に正常稼働しているかを「迷わず・素早く」確かめる方法。ブラウザではキャッシュやログイン状態の可否などで「実はうまく反映されていなかった」が起こりえます。
ここではデプロイ後の不安を最短で解消するために、Bashだけで回せるチェックリストを5分構成で提示します。
プロセス・ログ・ポート・リソース・疎通を順に確認し、手戻りや見逃しを減らす「定型手順（テンプレ）」として再現できる状態にします。
キーワードは“デプロイ後”“Bash”“チェックリスト”。これらを軸に誰でも同じ結果が得られる手順に整えます。
Bashについて不慣れな方は「Bashとは」の記事で最短で使いこなせる知識がまとまっているので参考にしてみてください。
詳細な流れを横断的に確認したい場合は Linuxトラブルシューティング総合ハブ から全体像をご覧いただけます。
デプロイ直後に「5分で回せる」チェック範囲を決める
本番デプロイ直後に確認すべき対象は、大きく分けて「プロセス」「ログ」「ポート」「リソース」「アプリ疎通」の5つです。これらを網羅するだけで、致命的な不具合を初期段階で拾える可能性が高まります。
対象：プロセス／ログ／ポート／リソース／アプリ疎通
- プロセス：アプリが起動しているか、再起動に失敗していないか。
- ログ：エラーが出ていないか、警告が繰り返し発生していないか。
- ポート：想定ポートで待ち受けているか、競合が発生していないか。
- リソース：ディスクやメモリが枯渇していないか。CPU過負荷はないか。
- 疎通：アプリに実際にアクセスして応答があるか。
この順番で回せば、最短時間でサービスの健全性を把握できます。
想定環境：systemd採用・journalctl利用・Bash標準ツール
多くのLinuxサーバーはsystemdベースで稼働しており、ログ確認は journalctl、プロセス管理は systemctl を使います。加えて ps, ss, df, free, curl といったBash標準的なツールが揃っていれば、追加のセットアップをせずに即座に確認が可能です。
この環境を前提とすれば、複雑な外部ツールを導入する前に、最小限の5分間チェックを実現できます。
すぐに実行する初動チェックリスト（コマンド付き）
デプロイ後の最初の5分間で実行すべきチェックを、具体的なBashコマンドとともに整理します。すべて順番に回しても数分で済むように設計しています。
プロセスの生存と再起動失敗の検知（systemctl, ps）
サービスが落ちていないか、再起動に失敗していないかを確認します。
# systemdで管理しているサービスの状態を確認
systemctl status myapp.service --no-pager
# プロセスが存在しているかを直接確認
ps -ef | grep myapp | grep -v grep
直近エラーログの走査（journalctl, tail -n, grep）
デプロイ直後は新しいエラーが発生していないかが最重要です。
# 直近10分のエラーログを確認
journalctl -u myapp.service --since "10 min ago" -p err
# アプリログファイルを直接 tail で確認
tail -n 50 /var/log/myapp/error.log
待受ポートと競合の確認（ss -lntp, lsof -i）
アプリがポートを正しく掴んでいるか、他プロセスと競合していないかを確認します。
# ポートの待受確認
ss -lntp | grep 8080
# プロセスごとのポート利用状況
lsof -i :8080
（詳しくは［ポート使用中の確認］も参考になります。）
ディスク・メモリ・CPUの余裕（df -h, free -h, top/uptime）
リソース不足は障害の主要因になるため、最初に余力を確認しておきます。
# ディスク使用率
df -h
# メモリ残量
free -h
# CPU負荷（1分平均がコア数を大幅に超えていないか）
uptime
ディスク逼迫時の詳細は［ログ肥大の対処］にまとめています。
環境変数と設定の読み込み確認（printenv, cat .env）
設定ファイルが反映されているかを見ます。
printenv | grep APP_ENV
cat /path/to/app/.env | head -n 5
アプリ疎通の基本チェック（curl /health, 200判定）
最後にアプリ自体がリクエストに応答できるかを確認します。
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8080/health
200が返ってくれば最低限の稼働は確認できます。より詳しい方法は［curlでの疎通確認］が参考になります。
つまずきやすいポイントと安全運用のコツ
デプロイ後のチェックは「コマンドを叩く」だけではなく、想定外のエラーや環境差異をどう扱うかが重要です。よくある落とし穴と、安全に運用するための工夫を押さえておきましょう。
権限・所有者・SELinux/権限周りの落とし穴
デプロイ直後に発生する典型的な不具合はファイル権限や所有者の不一致です。
特に /var/www 配下やログディレクトリに正しいユーザー権限が設定されていないと、プロセスは起動してもログが出力できず、すぐに停止します。
SELinuxやAppArmorを利用している環境では、ポート開放やファイルアクセスが制限されるため、許可設定が不足していないかをあらかじめ確認することが不可欠です。
ロールバック手順とログ保存（証跡化）をセットで用意
万一エラーが発生した場合に即座に戻せるよう、直前のリリースを残しておくことが大切です。
さらに、発生したエラーのログを保存して証跡化しておけば、原因調査や再発防止にも役立ちます。単に「戻す」だけでなく「残す」ことを意識しましょう。
ワンライナー→スクリプト化→CI/CD組み込みの順で自動化
チェックリストはまずワンライナーで習慣化し、次にシェルスクリプトにまとめると再現性が高まります。
最終的にはCI/CDのパイプラインに組み込み、デプロイと同時に自動実行される形にすると、人為的な抜け漏れを防げます。
この流れで進めると「最短5分の手動チェック」が「毎回自動で実施される安全ネット」へと進化します。
次にやること（恒常運用への接続）
初動チェックで最低限の稼働確認ができたら、そのままの手順を定期的に実行する仕組みに落とし込むことが重要です。短時間で済む確認だからこそ、日常の運用や監視に組み込むことで継続的な安心につながります。
ヘルスチェックの定期実行化（cron/systemd timer）
人が手動でチェックし続けるのは限界があるため、cron や systemd timer を使って定期的に /health を叩く仕組みを導入しましょう。
# 5分おきにヘルスチェック
*/5 * * * * curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8080/health | grep -q 200 || echo "health check failed" | logger
このようにログへ残すだけでも「正常稼働している証跡」として役立ちます。
監視・通知（メトリクス/ログ）への移行としきい値設定
初動チェックで扱ったコマンドは、そのまま監視システムに置き換えられます。
- プロセス監視 → systemd + 監視ツール
- ログ監視 → journalctl 出力を監視エージェントに転送
- リソース監視 →
df,freeの閾値を監視設定
特に、エラー率やディスク使用率は「しきい値を超えたら通知」が基本です。Slackやメールにアラートを飛ばせば、気付けないまま障害が進行するリスクを減らせます。
最終的には スクリプト設計の基本 を押さえて、これらの手順を再現性ある形で自動化するのがおすすめです。初動チェックを仕組みに組み込めば、手動の5分確認が「恒常的な安全運用」へとつながります。
まとめ
初動チェックを ワンコマンド化して再現性ある運用に組み込みたい方 は、ぜひ スクリプト設計の基本 をご覧ください。
関連して、ポート使用状況の確認は ssとlsofの使い方、ディスク逼迫時の対応は ログ肥大の対処、ログの確認は journalctlの基本、アプリ疎通の仕組み化は curlでの疎通確認 が役立ちます。
これらを押さえておけば、デプロイ直後の不安は最小限に抑えられ、運用に安心感が生まれます。
参考リンク
- Using journalctl – The Ultimate Guide to Logging — journalctl の使い方概要 (Log Analysis | Log Monitoring by Loggly)
- How to Use journalctl to View and Manipulate systemd Logs (DigitalOcean) — journalctl を時間・ユニットで絞る方法など (DigitalOcean)
- Checking Listening Ports and Services in Use — netstat/ss/lsof (Geuni Blog) — 待受ポートとプロセス確認方法 (geuni.tech)
- How to Manage Network Ports and Resolve Conflicts in Linux — ポート競合の診断・解消法 (LabEx)
