🌙 実戦ケース・中級・約15分

深夜2時、Webサーバが沈黙した

状況

あなたは従業員5人の小さな雑貨ECサイトを一人で支えるインフラ担当。サーバはVPS上のweb01が1台きりで、代わりに見てくれる人はいない。深夜2時3分、監視ツールからスマホに「応答時間が30秒を超過」の通知が届いた。眠い目をこすりながらノートPCを開き、web01にSSHでログインする。

SSHの接続にすらいつもより時間がかかる。プロンプトが返ってきた頃には胸騒ぎが確信に変わりつつあった。サーバの中で何かがリソースを食い尽くしている。だが憶測で動いてはいけない。まずは数字で全体像をつかむ。それが夜中の障害対応の鉄則だ。

uptime

top -b -n 1 | head -n 12

ps aux --sort=-%cpu | head -n 5

report.shは毎晩の売上レポートを作る自作スクリプトだ。いつもは1分で終わるはずが、今夜は7分たっても走り続けている。cronの設定では、出力を /var/log/app/report.log に書いているはずだった。プロセスを止める前に、まず何が起きているのかログを見に行く。

ls -lh /var/log/app/

tail -n 3 /var/log/app/report.log

ps -fp 4721

ls -l /var/tmp/report.lock

原因は見えた。残骸ロックによる無限リトライ。焦らず手順を決めてから動く。(1)暴走中の2プロセスを穏当に止める、(2)残骸ロックを消す、(3)負荷が下がることを数字で確認する。killの前にpsで正体を確認する——さっき済ませたあの一手が、ここで効いてくる。

kill 4721 4988

ps -p 4721 4988

rm /var/tmp/report.lock

uptime

crontab -l

[object Object]