Linuxサーバーにおけるトラブル調査と解決 研修コースに参加してみた

今回参加した研修コースは Linuxサーバーにおけるトラブル調査と解決 です。
参加してみると実際に様々なシーンで擬似的にトラブルを起こし、その解決を実際やってみる、という演習中心のコースでした。
またそのトラブルシーンもサーバーでよく起こりがちなもののうち、緊急性の低いトラブルから重要度の高いトラブルにレベルアップしていったので、ゲーム感覚で演習することができました。 本番では起こってほしくないことですが、とても良い疑似体験ができました。
発生してしまったトラブルへの対策で一番効くのは訓練なので、サーバーに携わるエンジニアにはぜひ一度体験して頂きたいコースです。
では、どんな内容だったのか、レポートします!!
もくじ
想定している受講者
- ネットワーク技術(主要なハードウェアとプロトコル)に関する基礎知識があること
受講目標
- Linuxサーバで発生する問題の原因調査をする基本的な手法を習得する
講師紹介
サーバー、ネットワークのカテゴリではお馴染みの 岩木 慎一さん が登壇されました。お天気の話題からアイスブレイクするのも、いつものお馴染みです。
今日は実機で色々トラブルシュートしましょう、ということで早速、コースがスタートです。
トラブルシューティングの基本
- 解決策の中で再発防止策を考える
- 正常性の確認が出来なければ、また原因の切り分けをやる
- 切り分けしながら調査対象を絞り込んでいく
- 記録取ることは重要
- あとあと効いてくる
- ときどき手書きで乱雑になっていたりするので、読めるようにしましょう
原因の調査方法
- 階層ごとに調査していく
- ハードウェア
- 特に電源など物理的なもの: ケーブルが抜けていたり、間違って刺さっていたり
- OS・ネットワーク設定
- DNSなど
- ハードウェア
- なぜ下から?
- 下のレイヤーで起こった問題は、当然ながら上のレイヤーで解決できない
- 下のほうが深刻度が高い。とくにハードウェア周りは忘れがち
アプリケーションエラーも嫌ですが、インフラがトラブルになると、ゴソッとシステムが死ぬので、恐怖でしかありません。監視とアラート通知で予め回避したいものです。
ちなみに、2017年2月にGitLab (GitHubのようなリポジトリ管理のOSS/有償版もある) で本番データベースを失うという、見もけもよだつトラブルがありましたが、なんとYoutubeでトラブルシューティングの模様を中継するということがありました。
強すぎる。。とはいえ、Twitter上では応援メッセージが飛び交うなど、開発者に愛されているサービスとはこういうことなんだなぁ、と感じます。
原因の調査で使うディレクトリやログファイル
/etc
で設定ファイルをよく見に行きます- CentOS6等の場合
/etc/udev
の配下のディレクトリに自動認識した eth0 や eth1 などのデバイスを定義したファイルがあるので確認できます(/etc/udev/rules.d/
の中) /var/log
でログファイル、いわゆるシスログを確認します- CentOSのApacheの場合、
/var/www
の下にホームページのファイルがあります
原因の調査 ~ログファイル
ログを見ることは必須ですね。
調査するときのコマンド ~システム
続いて、よく使うコマンドを紹介いただきました。
なお、ネットワーク系ではCentOS 7で使えなくなっているコマンドがあります。
また、そのほかよく使うコマンドを紹介いただき、実際紹介されたコマンドを使って、いよいよトラブルシューティング演習です。
トラブルシューティング演習
みっちり、シーン別に2時間トラブルシューティングです。
なお、最初に講師からアドバイスがあるのではなく、まずは自分で調べながら解決します。
ここではそのシーンをいくつかピックアップします。
root パスワードが不明
- そもそもパスワードはユーザーを識別するため
- linux ではシングルユーザーモードを使う
- 起動中に
e
を押して起動メニューを編集し、シングルユーザーモードで起動する
CPU高負荷
top
などのコマンドで負荷の掛かっている処理を確認kill
で処理をストップ
急ぎ、トラブルを解消した後、そのあとでなぜ高負荷になったのか原因を追求すること。
サーバーに接続できない
ps aux | grep httpd
で httpd があるか確認- 無いので、
service httpd status
でステータスを確認 -> 動いてなかった! service httpd start
で起動 -> まだ表示されない- 通信制限が掛かっているかどうか確認
ldd /usr/bin/sbin/sshd | grep libwrap
- 特に掛かってない
(以降は講座参加されてからのお楽しみ)
よくあるパターンですが、このシーンでは多段階でトラブルを仕込んでいました。テスト -> 移行時に起こりがちというヒントでした。
その他アプリケーション (MySQL) でトラブルが発生したシーンを演習して、このコースは終了となりました。
まとめ
このコースでは実際にサーバートラブルを疑似体験し、極力、自力で解決してみるという演習中心のコースでした。
なかなかトラブルは起こしたくないものの、実際、起こったときに対処できるよう訓練が必要です。演習してみると、やはり色々なことを調査しなくてはならず、総合力が問われるものでした。
訓練という意味では、Netflixという動画配信サービスでは Chaos testing という、実際にトラフィックや何かを突然カオス状態にするという訓練を行っていて、実際、AWSのトラブルを回避したという事例があります。
このコースの延長線で、講座形式ではなく、時間制限を設けて、ノーヒントでトラブルシューティングするコンテストがあっても面白いかも知れませんね。
いずれにせよ、トラブルシューティングの訓練として、またインフラエンジニアの総合力テストとしても、とてもオススメのトレーニングです!

SEプラスにしかないコンテンツや、研修サービスの運営情報を発信しています。