この記事は、モバイルファクトリー Advent Calendar 2015 18日目の記事です
昨日は
@yashims85さんのAndroid drawableは画像を入れておくだけじゃないでした。今日は障碍の話です。
普段障碍対応しているときにやってること考えてることをざっくりと時系列を追って書いていきたいと思います。
コンテキストとしてはLinuxサーバでwebサービスをやっていると思っていただければと思います。
障碍の検知
webサービスを運営していれば、何かしらの監視システムからSlackなりIRCなりメールなり電話なりでアラートの通知が来ると思います。
対応報告
障碍対応をしている旨をメールなり、何かの連絡手段で伝えます。同じく見ている人がいれば調査作業の分担もできます。
状況把握
どこで障碍?
アラートの通知内容にどのサーバで何が起きた的なことが書いてあるはずなので、それを確認します。
だいたいの組織に於いてはサーバ管理表的なものがwebなりExcelなり設定ファイルなりにあるはずなので、そこと照らし合わせてどのプロジェクトのどのロールなのかを把握します。
直前に何をした? いつもと違うことは何?
webアプリケーションであれば直前に入れた変更が原因かもしれません。また、ちょっと前に入れていた変更だが、cronで時限発火したというケースも考えられるかも知れません。
イベント開始で急にトラフィックが上がったと言うことも考えられるかも知れません。普段と変わったことは何かということが把握出来れば対処の幅が広がります。
影響範囲は?
サービス全体なのか、サービスの1機能の障碍なのか、ミドルウェア障碍なのか、影響がどの範囲に及んでいるのかを見ます。
ミドルウェア障碍であれば、最近であれば、冗長化されてるのが普通なので、サービスから切り離して、監視から外せば終わりというパターンも多いです。
サービス全体が落ちている場合は、ひとまず重要な関係者に状況の1次連絡すぐにした方が良いでしょう。
接続出来る?
そもそも、該当サーバに接続出来ない場合は、できることはほぼないので、該当サーバをサービスから外した上で、監視対象から外します。(単体のサーバ障碍の場合)
ping ${IP}
ssh ${IP}
ログの確認
該当サーバ上で動いているミドルウェアやアプリケーションサーバのエラーログを主に見ます。だいたいこの辺に重要な情報が出力されている可能性があります。
システムのログも確認した方が良いです。主にsyslogやkernelログを見ると良いでしょう。
less /var/log/syslog
less /var/log/kern.log
dmesg
サーバ状態の確認
負荷の関係で障碍が起きているのであれば、現在のサーバの状態を確認しましょう。
以下のようなコマンドが現状把握に役立つでしょう。
w
ps -ef
ps auxwwww
netstat -tlnp
netstat -taopen
top
dstat -tamsl 5
sar
sar -r
sar -q
対処
直前のコミットにバグを入れ込んでしまったのであればリバートすれば解決するでしょうし、特定のサーバ落ちたのであれば、サービスから外してあげるだけで良いかも知れません。
障碍の内容によって対処方法は様々です。ここで気を付けたいのは二次災害を起こさないことです。
可能であれば、コマンドなり対処スクリプトのレビューをしてもらったり、現状認識に間違いがないかを周りの人にしてもらうと良いでしょう。
(往々にして一人で障碍対応せざるを得ない場合もありますが。。)
事後報告
障碍対応が終わったら、記憶が新鮮なうちに下記の内容をまとめてしかるべき場所に投稿します。
この辺の報告のフォーマットはだいたいの組織において決まっていることが多いでしょう。
面倒くさがらずに事実をなるべく詳細に書いておくと未来の自分や自組織のためになると思います。
私の組織でも過去の障碍報告がだいぶ良い感じにデータベースになっており、たまに読み返すと気付きが得られます。
また、この障碍報告を元に、同種の障碍をなるべく起こさない仕組み作りをしていくことが肝要だと思います。
終わりに
自分が障碍対応しているときにやってること、考えてることをざっくり書いてきました。
誰にやり方を教わったわけでもないので、そこは違うとかこうした方がいいとかあれば、いただけると幸いです。
明日は、@lycoris102さんのGameJam部 活動年間活動報告です。きっと面白い話なのではないでしょうか。
