はじめに
この記事は、Linuxに一度も触ったことがない初心者向けの記事ではありません。
「SSHログインはできる」
「サーバに入ったことはある」
「でも、Linuxを体系的に勉強したことはない」
そんな過去の自分と同じような人に向けて書いています。
エンジニアとして数年働き、アプリケーション開発にはそれなりに自信がついてきた頃。
自分は、基礎を後回しにしていることの代償を、本番障害の現場で支払うことになりました。
障害は、準備ができていない人を正確に殴ってくる
平日の夕方、社内のチャットが急に騒がしくなりました。
- APIのレスポンスが不安定
- 一部の処理がタイムアウト
- 再起動しても改善しない
典型的な本番障害です。
オンコール担当ではありませんでしたが、調査メンバーの一人として呼ばれました。
SSHログイン後、思考が止まった
まずは本番サーバにSSHでログインします。
ssh user@production-server
プロンプトは正常に表示されました。
接続自体は問題ありません。
しかし、その瞬間に気づきました。
「で、次に何をすればいい？」
頭では「何か確認しないと」と思っているのに、具体的な行動が何一つ出てこない。
周囲のメンバーは淡々とコマンドを打っています。
ログを見ている人、負荷を確認している人。
自分だけが、**“ログインはできているのに、調査を始められていない”**状態でした。
当時の自分の認識
振り返ると、当時の自分はこんな考えでした。
- Linuxは「必要最低限分かっていればいい」
- コマンドは都度調べれば十分
- アプリケーションコードが分かっていれば何とかなる
結果として、障害対応で最も重要な「初動の型」を何も持っていませんでした。
本来、最初に確認すべきだったこと
障害対応では、「原因を特定する前に確認すべきこと」があります。
経験のある人は、ほぼ無意識に次のような確認をしています。
1. システム全体の負荷状況
uptime
top
- ロードアベレージは異常値か
- CPUやメモリを食い潰しているプロセスはないか
ここで**「そもそもシステム全体が苦しんでいるか」**を把握します。
当時の自分は、この確認を最初に行う発想がありませんでした。
2. プロセスの状態把握
ps aux
- 想定外のプロセスが動いていないか
- 明らかにリソースを食っているものはないか
ps aux は知っていました。
でも、
- 各カラムの意味を説明できない
- 何を見れば「異常」なのか判断できない
結果、見ているのに理解できない状態でした。
3. ログの確認
tail -n 100 application.log
less application.log
ログは、障害対応における一次情報です。
にもかかわらず当時の自分は、
- どのログを見るべきか即答できない
-
lessでの検索操作が曖昧 - エラーの流れを追えない
「ログを見ているフリ」をしているだけでした。
4. ディスク使用量の確認
df -h
du -sh /var/*
実際、この障害ではディスク使用量の逼迫が一因でした。
しかし当時の自分は、
- ディスクフルが障害原因になり得るという経験が浅い
- 確認コマンドが即座に出てこない
結果として、初動対応が遅れました。
一番の失敗は「調べればいい」という姿勢だった
一番の問題は、Linuxコマンドを知識としてしか持っていなかったことです。
- 名前は知っている
- 何をするかは何となく分かる
それでも、
即座に打てなければ、使えないのと同じ
障害対応では、
- 思い出す時間
- 調べる時間
そのすべてが、状況を悪化させるリスクになります。
そこから、どう学び直したか
この経験をきっかけに、Linuxを「障害対応のための技術」として学び直しました。
初動対応のチェックリストを作った
まず、迷わないために必ず最初に打つコマンドを固定しました。
uptime
top
ps aux
df -h
free -m
考える前に手が動く状態を目指しました。
ログ操作を“使えるレベル”まで落とし込んだ
less
tail
grep
-
lessでの検索・ジャンプ操作 -
grepでのエラー抽出
ログを「眺める」から「読む」へ変える意識を持ちました。
疑似障害で練習した
検証環境で、
- CPU負荷を意図的に上げる
- ディスクを埋める
- プロセスを暴走させる
といった 疑似障害 を作り、自分で原因を追う練習をしました。
この経験から学んだこと
- Linuxは後回しにすると必ず詰む
- 障害対応は基礎力がそのまま出る
- コマンドは「反射」で打てて初めて武器になる
そして何より、
「もっと勉強しておけば」と思う瞬間は、
必ず“手遅れ”の後にやってくる
ということです。
おわりに
もし過去の自分に一言だけ言えるなら、こう言います。
Linuxは、
本番障害の現場で初めて触るものじゃない。
この記事が、
- Linuxを避けてきた人
- 自分はもう分かっていると思い始めた人
にとって、今日1コマンドでも触ってみるきっかけになれば嬉しいです。
最低限、これだけは体に入れておきたいコマンド
uptime
top
ps aux
df -h
du -sh
less
tail
grep
基礎は地味ですが、いざという時に確実に自分を助けてくれます。