本ページは、バックエンド／インフラの現場で「まず何をすれば状況が見えるか」を、迷いなく実行できる最短ルートにまとめた“橋渡し”となるページです。
閲覧者からの不具合報告、500エラー、レスポンス遅延、ポート競合、ディスク逼迫――そうした“よくある事象”を入口にして、状況を把握するためのコマンドと最小手順を一直線に提示します。深掘りの学習は後回しにし、まずは安全に現状把握と初動対応ができることを狙います。
対象は、Linux 運用に不安のあるバックエンドエンジニアの初学者や、日常的にサーバをさわる機会が出てきた開発者、あるいはインフラ担当に移りつつあるエンジニアです。SSH でサーバに入れる、sudo が使える、基本的なファイル操作は分かる――この程度を前提にしています。各セクションは「状況 → 使うコマンド → 最小手順 → 落とし穴 → 次の一歩」の順で構成し、必要になったら実務レシピやコマンド索引へリンクで橋渡しします。
読み進めるときは、まず自分のケースに近い“状況”を選び、示された最小手順どおりに事象を見える化してください。原因を一気に特定しようとせず、ログ・状態・疎通の三点から事実を積み上げるのが近道です。変更が必要になったときは影響範囲を先に見極め、取り返しのつく最小単位から手を付けます。できる限りステージングで再現し、--dry-run できる操作は必ず試し、作業前にロールバックの準備を整えておきましょう。実行した内容と結果は簡潔でよいので記録しておくと、次の一手と共有が速くなります。
ここは“全集”ではありません。必要十分なコマンドに絞り、現場で役立つ順に並べました。細かなオプションや派生テクニックは、本文中のリンクから実務レシピとコマンド索引へ進んでください。最短で「分かる・動かせる」に到達し、その先の「深く理解する」は次のページで積み上げる――それが bash道の橋渡しです。
対象読者・前提
このページは、Linux 運用の経験が浅い バックエンド／インフラ志望者・初学者、あるいは開発の延長でサーバに触れるようになった アプリケーションエンジニア を主な対象にしています。
前提としては、以下が最低限できる想定です。
- SSH でサーバへログインできる（公開鍵認証の基本を理解している）
sudoを用いた権限昇格ができる（実行の意味を理解している）cd / ls / cat / less / tailなどの基礎コマンドに抵抗がない- 本番とステージングの違い、変更前のバックアップと記録の重要性を知っている
もし上記が不安なら、学習ハブ内の「Linux超入門」を先に確認してから進むと、ここでの“最小手順”が理解しやすくなります。
進め方（3ステップ）
- 状況を選ぶ
下の「よくある状況」から、自分のケースに最も近いものを選びます。 - 最小手順で“見える化”
状況に対応する“最小手順”を上から順に実行し、ログ／プロセス／疎通／資源のいずれで異常が起きているかを観測します。 - 橋渡しで深掘り
原因の当たりがついたら、対応する 実務レシピ と コマンド索引 へ移動して詳細な選択肢や落とし穴回避策を確認します。必要に応じてステージングで再現し、ロールバック経路を確保してから修正に踏み込みます。
心構え（安全運用の基本）
- 読む→測る→比べる：いきなり直さず、まずログと状態を“読む”。通常時との比較で異常を特定します。
- 影響範囲の把握が先：再起動や設定変更は最小単位から。依存関係（DB／キュー／リバプロ）を先に確認。
- 確実な退路：設定バックアップ・ダンプ・ロールバック手順を先に用意。
--dry-runできる操作は必ず試す。 - 記録と共有：打ったコマンドと結果を簡潔にメモ。次の一手とチーム共有が速くなります。
よくある状況から探す（橋渡しマップ）
1. デプロイ直後の動作確認
- 使うコマンド：
systemctl/journalctl/ps/ss - 最小手順
- サービス状態：
systemctl status <svc> - ログ確認：
journalctl -u <svc> -n 200 -e - プロセス確認：
ps -ef | grep <app> - ポート待受：
ss -lntp | grep :<port>
- サービス状態：
- 落とし穴：ユニット名の誤り、環境変数未読込、SELinux制御
- 次の一歩：実務レシピ「デプロイ後の初動チェック」
2. API が重い・レスポンス遅延
- 使うコマンド：
top/vmstat/iostat/ss - 最小手順
- 負荷確認：
top - I/O 確認：
iostat -x 1 5 - コネクション数：
ss -s
- 負荷確認：
- 落とし穴：スパイクと恒常負荷の混同、I/O 待ちを CPU 負荷と誤解
- 次の一歩：実務レシピ「高負荷の初動対応」
3. 500 エラーが出る
- 使うコマンド：
journalctl/tail/grep - 最小手順
- サービスログ：
journalctl -u <svc> -n 200 - Web サーバログ：
tail -f /var/log/nginx/error.log - アプリログ検索：
grep -iE "error|exception" app.log | tail
- サービスログ：
- 落とし穴：片方のログしか見ない、設定差分の見落とし
- 次の一歩：実務レシピ「500 の原因切り分け」
4. ポートが開かない／競合している
- 使うコマンド：
ss/lsof/systemctl - 最小手順
- 待受確認：
ss -lntp | grep :<port> - 使用プロセス確認：
lsof -i :<port> - サービス再起動：
systemctl restart <svc>
- 待受確認：
- 落とし穴：IPv4/IPv6 の違い、監視系プロセスの先占
- 次の一歩：実務レシピ「ポート競合の解消」
5. ディスクがいっぱい
- 使うコマンド：
df/du/logrotate/lsof - 最小手順
- 使用率確認：
df -h - 容量探索：
du -xh /var/log --max-depth=1 | sort -h - ログローテート：
logrotate -f /etc/logrotate.conf - 削除済みファイル確認：
lsof | grep deleted
- 使用率確認：
- 落とし穴：削除しても容量が戻らないケース
- 次の一歩：実務レシピ「ディスク逼迫の初動」
6. 権限や所有権の問題
- 使うコマンド：
ls -l/namei -l/chown/chmod - 最小手順
- パス権限確認：
namei -l /path/to/file - 所有者変更：
chown -R app:app /path - 権限調整：
chmod 640 file
- パス権限確認：
- 落とし穴：ディレクトリ実行権（x）の不足
- 次の一歩：実務レシピ「権限エラーの対応」
7. サービスが落ちる／起動しない
- 使うコマンド：
systemctl/journalctl -xe - 最小手順
- 状態確認：
systemctl status <svc> - エラーログ：
journalctl -u <svc> -xe
- 状態確認：
- 落とし穴：作業ディレクトリや ExecStart の設定不整合
- 次の一歩：実務レシピ「systemd ユニットの基本」
8. ネットワーク疎通の問題
- 使うコマンド：
ping/traceroute/curl/dig - 最小手順
- 到達確認：
ping -c 4 host - 経路確認：
traceroute host - HTTP 応答：
curl -I https://host - DNS 解決：
dig host +short
- 到達確認：
- 落とし穴：DNS キャッシュや FW 設定の見落とし
- 次の一歩：実務レシピ「ネットワーク切り分け」
9. バックアップと復元
- 使うコマンド：
tar/mysqldump/pg_dump/rsync - 最小手順
- 設定保存：
tar -czf conf_$(date +%F).tgz /etc/... - DB ダンプ：
mysqldump --single-transaction - 退避：
rsync -av data backup:/path
- 設定保存：
- 落とし穴：復元テストをしていない
- 次の一歩：実務レシピ「夜間バックアップの自動化」
10. 定期実行・監視
- 使うコマンド：
crontab -e/at - 最小手順
- 定期実行設定：
crontab -e - 単発ジョブ登録：
at now + 5 minutes
- 定期実行設定：
- 落とし穴：環境変数未設定、PATH 問題
- 次の一歩：実務レシピ「失敗検知メールの定型」
付録：最小ワンライナー集（コピー用）
ログ／サービス
直近のエラー行だけ確認する
journalctl -u <svc> -n 1000 --no-pager | grep -iE 'error|fail|exception' | tail
サービス状態をざっと見る
systemctl status <svc> --no-pager | tail -n +1
Nginx の直近エラーを追う
tail -F /var/log/nginx/error.log | grep --line-buffered -iE 'error|crit|alert'
プロセス／CPU／メモリ
CPU 使用率の上位を確認
ps -eo pid,comm,%cpu --sort=-%cpu | head -n 6
メモリ使用量の上位を確認
ps -eo pid,comm,%mem,rss --sort=-%mem | head -n 6
ゾンビプロセスの有無を調べる
ps aux | awk '$8 ~ /Z/ {print}'
ディスク／ファイル
ファイルシステムの使用率を確認
df -h | grep -v tmpfs
ディレクトリの容量トップ10を探す
du -xha /path | sort -h | tail -n 10
“削除済みオープンファイル”を検知
lsof | grep deleted
ネットワーク／疎通
80/443 の待受プロセスを確認
ss -lntp | egrep ':80|:443'
確立済み TCP コネクション数を数える
ss -ant state established | wc -l
DNS 解決結果を簡易確認
dig +short <host>
ポート競合の切り分け
特定ポートの使用プロセスを特定
lsof -i :<port>
LISTEN のみ抽出
ss -lntp | awk 'NR==1 || $1=="LISTEN"'
権限・所有権
パスを辿って権限を確認
namei -l /path/to/file
配下ディレクトリの実行権不足を検知
find /path -type d ! -perm -u=x -ls
バックアップ／復元の最小セット
設定のスナップショットを取得
tar -czf etc_nginx_$(date +%F).tgz /etc/nginx
MySQL を論理バックアップ
mysqldump --single-transaction --routines --triggers <db> > dump_$(date +%F).sql
PostgreSQL をカスタム書式でダンプ
pg_dump -Fc <db> > dump_$(date +%F).dump
リモートへ退避
rsync -avz /path user@backup:/backup/path
監視／通知（例）
エラーログ件数があればメール通知（mailx 想定）
c=$(grep -ci 'error' /var/log/nginx/error.log); [ "$c" -gt 0 ] && echo "$c errors" | mail -s 'nginx errors' you@example.com
プレースホルダ
<svc>：systemd ユニット名<port>：ポート番号<host>：ホスト名／FQDN<db>：データベース名
本番適用前にステージングで試験し、必要に応じて --dry-run やバックアップを先に準備してください。
次の学習（内部リンク想定）
- Linuxトラブルシューティング総合ハブ
- コマンド索引（調べる）
systemctl / journalctl / ps / top / vmstat / iostat / ss / lsof / df / du / grep / awk / sed / tar / rsync / mysqldump / pg_dump / namei / chmod / chown - 環境＆ワークフロー（整える）
- 過去コマンドの履歴を効率的に使う方法｜historyと!番号の活用 ─（履歴）
- シェルの設定を整理する｜.bashrcと.profileを正しく使い分ける方法 ─（エイリアス・設定まわり）
- 「rootで慣れる前に」：Docker時代でも効く Linux 権限設計と sudo の原則 ─（本番・検証の運用設計／権限と記録の考え方）
