本番サーバにSSHしてトラブル対応をするのは、フロントエンド出身のエンジニアにとって緊張する場面のひとつだ。
「このコマンド、本当に打っていいのか」「何かを壊しそうで怖い」——そういう感覚は、Linuxの仕組みが分かっていないから生まれる。「サーバ/インフラを支える技術」を読んで、その「怖さ」がかなり薄れた。本番で絶対に知っておくべき知識を、実務で使う文脈に絞って整理する。
プロセス管理——何が動いているかを把握する
トラブル発生時にまず確認するのが「何が動いているか」だ。
# 全プロセスを確認
ps aux
# リソース消費の多い順に並べる（CPUなら 1 キー）
top
htop # インタラクティブで見やすい
# 特定プロセスを名前で探す
ps aux | grep nginx
# プロセスIDを指定して終了（丁寧に）
kill -TERM <PID>
# 強制終了（最終手段）
kill -KILL <PID>kill コマンドは名前から「殺す」という印象があるが、実際にはプロセスにシグナルを送るコマンドだ。-TERM（15番）は「終了してください」というお願いで、プロセスはクリーンアップ処理をしてから終了できる。-KILL（9番）はOS側が強制終了させるため、ファイルの書き込み途中でも即座に止まる。最初に -TERM を試し、応答がなければ -KILL という順序が正しい。
systemctl を使うサービスなら、こちらの方が安全だ。
# サービスの状態確認
systemctl status nginx
# 再起動（graceful）
systemctl restart nginx
# 設定リロード（プロセスを落とさずに設定を読み直す）
systemctl reload nginxrestart と reload の違いは意識しておく価値がある。restart はプロセスを一度落として起動し直すため、その間にリクエストを受け付けられなくなる。reload は設定ファイルを再読み込みするだけなので、Nginxなどは無停止で設定変更を適用できる。
ログ監視——問題の手がかりはここにある
サーバで何か問題が起きたとき、最初に見るべきはログだ。
# ログをリアルタイムで追う
tail -f /var/log/nginx/error.log
# 直近100行を表示
tail -n 100 /var/log/nginx/access.log
# 特定の文字列を含む行を抽出
grep "ERROR" /var/log/app/application.log
# タイムスタンプと合わせてgrepする
grep "2026-05-18 14:" /var/log/app/application.log
# ログをページングして見る
less /var/log/syslogless は長いファイルを見るときに便利で、/検索文字列 で検索、n で次の一致箇所へ移動できる。本番サーバで cat を大きなログファイルに使うと端末が固まるので、less か tail を使う習慣をつけた方がいい。
systemdを使っているサーバでは journalctl も重要だ。
# 全サービスのログ
journalctl
# 特定サービスのログ
journalctl -u nginx
# 直近1時間のログ
journalctl --since "1 hour ago"
# リアルタイムで追う
journalctl -fディスク・メモリの状況確認
「サーバが重い」という報告を受けたとき、まず確認するコマンドをまとめておく。
# ディスク使用状況（人間に読みやすい単位）
df -h
# 特定ディレクトリ以下のサイズ
du -sh /var/log/*
# メモリ使用状況
free -h
# 総合的なリソース確認
vmstat 1 # 1秒間隔で表示ディスクがフルに近い場合、原因はログの肥大化であることが多い。du -sh /var/log/* で各ログのサイズを確認して、logrotate の設定を見直すか、一時的に古いログを圧縮・削除する。
ファイルシステムとパーミッション
Linuxのパーミッションは rwxr-xr-x という表記を見て一瞬で読めるようになっておきたい。
-rwxr-xr-x 1 deploy www-data 4096 May 18 10:00 app.sh
^^^ : ファイルオーナーの権限（読み・書き・実行）
^^^ : グループの権限（読み・実行のみ）
^^^ : その他ユーザーの権限（読み・実行のみ）数値表記との対応は以下のとおりだ。
| 記号 | 数値 | 意味 |
|---|---|---|
| r | 4 | 読み取り |
| w | 2 | 書き込み |
| x | 1 | 実行 |
chmod 755 は rwxr-xr-x、chmod 644 は rw-r--r-- と読める。Webサーバからアクセスするファイルを chmod 777 にするのは権限を与えすぎで、適切な設定は 644 や 755 だ。
# 所有者とグループを変更
chown deploy:www-data /var/www/app
# ディレクトリ以下を再帰的に変更
chown -R deploy:www-data /var/www/app/
# パーミッションを変更
chmod 644 /etc/nginx/nginx.confシンボリックリンクとマウントポイント
ログのローテーション設定や、デプロイのBlue-Green切り替えでシンボリックリンクが使われることがある。
# シンボリックリンクの作成
ln -s /var/www/releases/v1.2.3 /var/www/current
# シンボリックリンクか実体かを確認
ls -la /var/www/current
# 実際のパスを確認
readlink -f /var/www/currentls -la の出力で -> が表示されていればシンボリックリンクだ。デプロイツール（Capistrano、Deployerなど）の仕組みはこのシンボリックリンクの張り替えで成り立っていることが多い。
治験システムの本番対応で「Linuxの怖さ」が消えた瞬間
医療系スタートアップで治験管理システムの保守を担うようになったとき、本番サーバへのSSHが避けられない状況が初めて来た。
被験者データのインポート処理がタイムアウトで止まっているという報告だった。「何が動いているか」も「どこで止まっているか」も最初はわからなかった。だがここで ps aux | grep import と打ってプロセスを特定し、tail -f でログを追って、スロークエリが原因だと特定できたときの感覚は今でも覚えている。
「コマンドが怖い」のではなく「何を確認すれば状況がわかるかわからない」ことが怖さの本質だと、その経験で理解した。
治験システムの特性として、処理が途中で止まることへの許容がゼロに近い。被験者のデータが中途半端な状態で残ることは、規制上も倫理上も許されない。kill -TERM でクリーンアップを待つか、kill -KILL で強制終了するかの判断が、データ整合性に直結する。本書で「シグナルの違い」を体系的に理解していたことで、迷わず判断できた。
ログについてもそうだ。医療系システムは**監査証跡（Audit Trail）**の要件が厳しく、誰がいつ何をしたかをログで証明できなければならない。journalctl でのタイムスタンプ付きログ確認と、ログファイルの改ざん防止設定は、CSV（Computer System Validation）の要件として実装した経験がある。
まとめ
Linuxのコマンドは種類が多すぎて全部を覚えようとすると気が遠くなる。だが実務で必要になる場面は限られていて、「プロセス確認」「ログ確認」「ディスク確認」「パーミッション修正」の4つをしっかり理解しておけば、大半のトラブル対応に参加できる。
「コマンドを覚える」より「今何を確認したいか」を考える習慣をつけると、ターミナルへの苦手意識はかなり薄れる。最初は怖くて当然だが、仕組みを理解すれば怖さは消えていく。
