障害発生時に抑えておきたい基礎知識

2,461 views

Published on

NODE-Setagaya#0 ( http://www.zusaar.com/event/650010 )
の発表&ディスカッションをした際に使った資料です。

障害発生時に抑えておきたい基礎知識

  1. 1. 障害発生時に抑えておきたい基礎知識Linuxサーバ編@laugh_kNODE-Setagaya#0 2013.04
  2. 2. Profile• 名前Kei Iwasaki• Twitter@laugh_k• 職業MSP(監視運用代行)の会社でサーバ・ネットワークエンジニア的なもの
  3. 3. 3月某日のこと
  4. 4. 参加してきました!
  5. 5. そして痛感しました...自分のホーム以外の環境だと思ったように対応できないと。
  6. 6. しかもこの「トラしゅ」は6月にもう一度開催予定とのことで色々おさらい&予習をしておきたい!
  7. 7. 障害発生時の基本確認編
  8. 8. 障害発生時の基本確認編誰がログインしているか?していたか?作業影響によるものなのか?ログインしているユーザーを確認# wこれまでログインしていたユーザー&リブートがあったかどうかを確認# last# w# last
  9. 9. 障害発生時の基本確認編以前にどういう作業が行われたか?特にrootユーザーでやると効果絶大# history※ただし、Ubuntuサーバのようなrootユーザー以外がsudoで管理するようなOSだとroot以外のユーザーでもやったほうがいいかも# history
  10. 10. 障害発生時の基本確認編聞き耳を立てているポート・プロセスはないか?※プロセスの情報もセットで追いかける場合はrootで実行する。# netstat -nplt# netstat -nplu# netstat -nplx
  11. 11. 障害発生時の基本確認編CPU、MEMなどのシステムリソースはどうなっているか?Mem# free -mLoad Average(CPU)# uptime# free -m# uptime
  12. 12. 障害発生時の基本確認編CPU、MEMなどのシステムリソースはどうなっているか?入っていたら# sar -A現状のプロセスと照らし合わせながら# top※topは表示中にfを押すと詳細な表示オプションが選択できる!# sar -A# top
  13. 13. 障害発生時の基本確認編何かシステムがエラーを吐いていないか?システムログの確認※ /etc/rsyslog.conf,/etc/syslog.confを確認すると他にもどこかに吐かれていることがわかる!# dmesg# less /var/log/messages# less /var/log/syslog# less /var/log/secure# less /var/log/auth
  14. 14. 障害発生時の基本確認編何かバッチ処理が動いていないか?Cronの確認※ cronは管理者によって書き方が色々なので注意!# ls /var/spool/cron/crontab/*# cat /etc/crontab# ls /etc/cron*## /etc/cron* のファイルを全部表示# find /etc/cron* -type f -exec cat {} ;
  15. 15. 障害発生時の基本確認編何かバッチ処理が動いていないか?atコマンドジョブの確認# atq# at -c [ジョブ番号]# atq | awk {print $1} | xargs at -c※ 「トラしゅ」ではこいつに苦しめられましたね。。# atq# at -c [ジョブ番号]## 一行で確認# atq | awk {print $1} | xargs at -c
  16. 16. 障害発生時の基本確認編ミドルウェアは何が入っている?必ずしもyumやaptで行儀よく入っているとは限らない※ ソースコンパイルでインストールする際は/usr/local/[ミドルウェア名]に突っ込むことが多い。というかほぼ暗黙の了解。また、モノによっては /opt配下も好まれる場合もあり# ls /usr/local# ls /opt
  17. 17. 障害発生時の基本確認編ミドルウェアのログを見よう!単純にエラーを探すだけでなく、タイムスタンプが不自然に切れていないかなども重要 Apacheだと大体はこんな感じ※vimが入っている場合はハイライトが効いて見やすくなることもある。## yumやaptなどの場合# less /var/log/apache2/access.log## ソースコンパイルの場合# less /usr/local/apache2/logs/access.log
  18. 18. 障害発生時の基本確認編自動起動しているプロセスはあってる? 意図しているもの 今起動しているもの※ちゃんと意図したとおりに動いているのか確認# chkconfig –list# cat /etc/rc.local# ls /etc/rc{1..5}.d/# ps auxwww# pstree -p
  19. 19. 障害発生時の基本確認編さてここまではコマンドを使ってサーバの情報の探り方を中心に見てきましたが、
  20. 20. 障害発生時の基本確認編NagiosZabbix
  21. 21. 障害発生時の基本確認編MuninCacti
  22. 22. 障害発生時の基本確認編このような監視に特化したツールを予め導入しておくと楽です。というより台数増えると使わないと無理です。
  23. 23. 障害発生時、技術以外に気をつけなきゃいけないこと
  24. 24. 技術以外に気をつけなきゃいけないこと障害の着地地点の確保として以下のことを確認しておかないと判断に迷いが生じてよろしくないです。• 最終的な意思決定は誰が行うか• 意思決定者へは何を使ってどこに連絡をするか判断に迷った時は誰に相談?電話?メール?IRC?アドレスは?番号は?チャンネルは?
  25. 25. 技術以外に気をつけなきゃいけないことシステム障害の発生時のHowToのようなものを見ているとついつい「技術的にどこが問題だったのか?」という視点に陥りがちです。確かにそれは最終的に対応しなければならないです。
  26. 26. 技術以外に気をつけなきゃいけないことけど、障害対応というのは「問題が発生しているサービスをどうするか」という事であって「技術的に原因を取り除かなければならない」とは限りません。
  27. 27. 技術以外に気をつけなきゃいけないこと1秒でもダウンタイムを減らせるならコンソールに張り続けてApacheやMySQLの再起動を手動で何度も続けたほうがサービス提供者にとってもサービスユーザーにとってもいい結果になることだってあります。それは立派な障害対応です。
  28. 28. 技術以外に気をつけなきゃいけないこと「障害対応」はサービス提供者側が受けるダメージを最小限に食い止めることであると思っています。そのためにはまず、サービス提供者への状況報告・相談・提案を行い、目の前で発生している問題を解決することが最優先です。
  29. 29. 技術以外に気をつけなきゃいけないこと技術的にその場で根本対応ができてしまうのはそれはそれで本当にすごいことなのですが、もしかしたらそれはサービス提供者が望んでいない方針かもしれません。サービス提供者に余計なコストを発生させることにつながるかもしれません。
  30. 30. 技術以外に気をつけなきゃいけないこと「障害対応」は一種の問題解決です。そのために必要な技術力。提案力。報告力などなど。。必要なスキルを必要な場所で使い分けることが対応者もサービス提供者もハッピーになれる対応への一歩ではないかと思います。

×