コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

サーバアプリケーションのトラブルシュート時の心構え

自分が普段思っていることを明文化する系雑記です。

トラブルシュート時の心構え

アプリケーションサーバという共有の資源に関して複数の開発者が入るような環境でのトラブル発生時に、気にかけておきたいことが3つほどある

  • トラブルが起きているサーバには誰が主で作業しているか?
  • トラブルが起きているサーバに直接入って問題ないか?
  • トラブルが起きている環境に変更が加える人は決まっているか?

トラブルが起きているサーバには誰が主で作業しているか?

もしトラブルに遭遇したとき、自分が第一発見者なのか、はたまた誰かが対応していてたまたま第二発見者になったかはちゃんと周りを見て確かめるべきである。もし先にやっている人がいればそこに対して情報のヒアリングや、後方支援に回るほうがトラブル解決につながるときもある。

トラブルが起きているサーバに直接入って問題ないか?

基本的には何かしらのツールでサーバの状態を確認できるようにはしているはずである。AWSしかり、Zabbixしかり。それらのツールでまずは状態を見れるのであればそこの数値の変化を見てトラブル判断をしていく。

もしとっている数値で判断が不可能な場合、次にサーバに入って調査となるが、果たして自分がそれを行うべきか、それをする適任者かは考える。サーバーに複数人sshすればそれだけリソースを取られるということなので、それで予期せぬ動作を引き起こす場合すらある。なのでそこに対して慎重になるべきシーンも有る。

トラブルが起きている環境に変更が加える人は決まっているか?

もし、トライアンドエラーの段階になってもログインと同様に自分が適格者か、誰が操作しているかなどは把握すべきである。もし方向性の違う変更をお互いして状況が変わってしまったら事態はさらに混迷を深めていくからである。

これらが抜け落ちると起こること

これらが抜け落ちると二次災害的なことが発生することがある。

  • すでにトラブルシューティングを始めようとしていたのに二重に報告をはじめ連絡系統が混乱する
  • ログインしてログを見たがためにメモリが限界に達しサーバダウン
  • 同じ作業をやってしまい、予期せぬ二重作業でバグを生み出す

などなど、このため作業するときは「モブ障害対応」のようにドライバーとブレインでシュートにあたるのとかなりスムーズに行くのかもしれない

関連リンク

ウチのチームがモブってるとき - PoohSunny's blog