Welcome

島田則幸のポートフォリオ Noriyuki Shimada's Portfolio

Linux Operation Lab Linux 一次運用メモ

Ubuntu / RHEL family Scenario

「サーバーが重い」「ログインできない」を同じ順で確認するLab

Linuxサーバー（Ubuntu / RHEL系）の一次運用で、まず見るべきところを 負荷・ディスク・サービス・ログ・ネットワーク・認証・ファイアウォール の順に整理しました。すべて読み取り操作のみで構成し、設定変更や再起動は手順を分けています。

systemd journalctl cron SSH rsync
Linux 一次切り分けコマンド早見表
対象 確認観点 主なコマンド 判断基準 / 引き継ぎ目安
負荷 load average / CPU / プロセス上位 uptime
top -bn1 | head -n 20
ps -eo pid,user,pcpu,pmem,etime,comm --sort=-pcpu | head		 load5 が CPU 数を超えていれば負荷高。常駐プロセスが特定のものに偏る場合はそのサービスを担当へ。
メモリ 使用量 / available / swap free -h
vmstat 1 5		 available が物理の 10% を切る、swap が継続的に増える場合は OOM 注意。
ディスク 使用率 / inode / I/O df -hPT -x tmpfs
df -hPi -x tmpfs
iostat -x 1 3		 使用率 90% 以上、inode 80% 以上、await が継続的に高い場合は要対応。
サービス 失敗ユニット / 起動順序 / 自動起動 systemctl --failed
systemctl status sshd
systemctl list-unit-files --state=enabled		 failed があれば即チケット。enabled だが inactive のサービスは設計と照合する。
ログ 直近のエラー / 該当サービス / 起動失敗 journalctl -p err --since "30 min ago"
journalctl -u nginx -n 50
dmesg -T --level=err | tail		 同一エラーの反復、kernel oops、OOM killer 発火は重大として上位担当へ。
ネットワーク 経路 / DNS / リスニングポート ip route
resolvectl status
ss -tulnp		 同一セグメントから到達できない場合は L2/L3 の問題として切り出す。
認証 SSH 失敗 / ログイン履歴 / ロックアウト journalctl -u ssh -p warning
last -n 20
lastb -n 20		 同一IPからのbrute force兆候があれば fail2ban / firewall 担当へエスカレーション。
ファイアウォール 許可ポリシー / 適用状態 ufw status verbose
firewall-cmd --list-all
iptables -L -n -v		 申請にない解放、想定外の許可、ルールの空状態は即確認対象。
SSH / 権限 / cron 設計メモ

SSH 鍵運用

  • 鍵は ssh-keygen -t ed25519 で作成し、パスフレーズを必ず設定する。
  • サーバー側 ~/.ssh/authorized_keys は chmod 600、ディレクトリは 700。
  • /etc/ssh/sshd_config で PasswordAuthentication no、PermitRootLogin no、Port は必要に応じて変更。
  • 退職・異動時は authorized_keys の該当行を削除し、運用台帳と突合する。

権限・ファイルシステム

  • chown / chmod は最小権限。共有は POSIX ACL（setfacl）で個別付与。
  • 機密ファイルは chmod 640 + 専用グループ。ls -la で確認。
  • ディレクトリの SUID/SGID は棚卸し対象（find / -perm /6000 -type f 2>/dev/null）。

cron / systemd timer

  • OS全体: /etc/cron.d/ / /etc/cron.daily/、ユーザー: crontab -l。
  • 新規はできるだけ systemd timer を選び、ログを journalctl -u xxx.timer で追えるようにする。
  • ジョブ追加時は実行ユーザー、出力先、リトライ、タイムアウトを設計書に明記。

logrotate

  • /etc/logrotate.d/ 配下にサービス単位で配置。サイズ / 日付ローテ、保持世代、圧縮を指定。
  • 新規アプリ追加時は logrotate 設定とディスク使用率監視を同時に追加。
  • 動作確認は logrotate -d /etc/logrotate.d/xxx (dry-run)。
rsync によるバックアップ例

日次差分バックアップのワンライナー

同一ホスト内の別ディスクへ /etc と /var/www を日次でバックアップし、削除も同期する例です。実運用ではバックアップ先を別筐体 / オフサイトにすること、定期的にリストアテストを行うことが前提です。

# /usr/local/sbin/daily-backup.sh
SRC1=/etc
SRC2=/var/www
DST=/mnt/backup/$(hostname)/$(date +%Y-%m-%d)
LOG=/var/log/daily-backup.log

mkdir -p "$DST"
rsync -aHAX --delete --numeric-ids \
      --link-dest=/mnt/backup/$(hostname)/latest \
      "$SRC1" "$SRC2" "$DST"/ 2>&1 | tee -a "$LOG"

ln -snf "$DST" /mnt/backup/$(hostname)/latest
find /mnt/backup/$(hostname) -maxdepth 1 -type d -mtime +30 -exec rm -rf {} +

systemd timer 例（毎日 03:00 実行）:

# /etc/systemd/system/daily-backup.service
[Unit]
Description=Daily rsync backup
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/daily-backup.sh

# /etc/systemd/system/daily-backup.timer
[Unit]
Description=Run daily-backup.sh at 03:00
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
[Install]
WantedBy=timers.target

詳しいリストア手順とテスト計画は バックアップ/リストアRunbook に分けて記載しています。

bash 一次切り分けスクリプト

ここまでの確認項目を1本にまとめた読み取り専用 bash です。問い合わせ受付直後に流して、結果をテキストでチケットに添付します。

linux-triage.sh を見る support-scripts/ へ

自動化 / 監視への入口

初期構築のIaCと、運用後の監視を別フォルダにまとめています。bashスクリプトで状態を確認し、Ansibleで設定を揃え、Prometheusで継続的に観測する流れです。

Ansible playbook Prometheus + Grafana Backup Runbook Postmortem 実例