システム障害が起きたとき、どのように初動するべきか?

アウトプットがしたくなって2回目の投稿は、過去の経験を可視化する試みです。
備忘録としての意味合いが半分、残り半分はもしかするとこの記事が役に立つ人も居るかも知れないな、という感じです。

形あるものはいずれ壊れる。例えそれがクラウドでも。

どれだけ綺麗に作ったシステムでも例外なく壊れるのです。綺麗に作っておくと、障害の規模が小さくできるのが利点ですが、それでもやっぱりたまに何か起きます。

なんかアラート出たけど実は壊れてなかったってこともある

むしろその方が多いかも。システム運用のたちの悪いところはそこで、とりあえず怪しい事象は一応アラート飛ばしとこーという設計になるのが普通です。
たまに、設計が面倒とか時間がないとか、割と怠慢な理由でアラートが無差別に飛びまくるシステムがありますが、運用を引き取ってしまった以上そこはグッとこらえて、アラートの波をかきわけながら正しくシステムを運用していく必要があります。そもそも監視の仕組みを入れていないシステムもあるかもですが、その場合も割と厳しい戦いになるかも知れません。
いずれにせよ、システムを作った人を恨むのは後からでもできますが、障害対応を後回しにはできません。

まずはアラートの内容をよく見よう

何のためにアラートが出ているか?そりゃ当たり前ですよ運用者に分かりやすくするためです。だからちゃんと見る。たまに難解なワードがありますが、マニュアル等を駆使してちゃんと読む。複数出てたら全部読む。時系列順に読むのもオススメ。
これが出来てない人が意外に多いんです。
アラートがない!って人はとりあえず次項に行きましょう。あと、アラートが多すぎてわからん!って人も次項でよいです。20〜30件ぐらいなら読んだ方がよいとは思いますが。

次に、各種ログを読んでみよう

アラートが出た箇所、もしくは問題が出た箇所のログを見てみましょう。システムにはログが残るように基本的にはなっているはずです。こちらにもたまに難解なワードがあるかも知れませんが、マニュ(以下略
障害が起きた前後の時間帯は必ず読みましょう。障害が起きていないときと起きたあとの比較ができるとなおよいです。
サーバーで起きた障害なら、アプリのログだけでなくミドルウェアとかOSやハードウェアのログも追う必要がでることもあります。
アプリ→ミドル→OS→ハードの順番で見ていくのが定石です。
ログがあればトラブルシューティングはそれなりに捗るものと思います。

アラートを見てもログを見ても原因がわからない!そんなときはどうする?

たまにあるんですよね。そういうの。
監視設計が悪いのか運が悪いのか、それはケースバイケースですが、障害が起きてしまったことは仕方がないので、淡々と対応を進めましょう。
ポイントは、障害が再発可能かどうか?です。再発可能だとか障害が継続中とかであれば、後からでもログを集めることができますので、まだ対処可能です。
アプリでログを取るなり、パケットキャプチャするなり、準備をしてから再現させましょう。
どう再発させて良いかわからないのであれば、まずは障害が起きる条件とか法則性を探ってみましょう。障害が発生したときの周辺環境はどうだったのか?システム負荷はどうだったのか?など、確認するとよいと思います。

なぜか通信できなくなってしまった!そんなときはどうする?

ネットワーク周りの問題は、確認すべき範囲が広くなるため大変です。しかもログがなかなか残らないときた。割と手強い問題なこともあります。
そんなときは、OSIの7層モデルの下から調べていくとよいと思います。具体的には以下のようなやりかたです。
1. わかる範囲でよいので、通信経路を把握する
2. 物理層→データリンク層→ネットワーク層→トランスポート層の順に問題がないか確認する
3. ネットワークのホップ的に近い順に問題がないか確認する

ちなみに確認方法としては、
物理層:リンクアップしてるか?speed duplexが合ってるか?tx-rx合ってるか?
データリンク層:ARPやMACアドレステーブルで見えているか?
ネットワーク層:ルーティングが正しい方向に向いているか?pingでも何でもいいので通信が届くか?tracerouteでどこまで到達できるか?
トランスポート層:想定したプロトコルで通信が届くか?

最後に

ここまできたら、だいたい何が起きているか把握できているはずです。
問題が把握できたら、トラブルシューティングの8割ぐらいが終わったようなものです。
もちろん、再発防止など面倒な仕事が残っているとは思いますが、何が起きているかわからない状態よりはずっと良いでしょう。

この記事が、障害が起きて大変な思いをしている人に届きますように。

この記事が気に入ったらサポートをしてみませんか?