全力で怠けたい

怠けるために全力を尽くしたいブログ。

AWS で障害が発生したときにチェックしているページをまとめてみた。

はじめに

先週は AWS の東京リージョンで大規模な障害が発生した。

piyolog.hatenadiary.jp

AWS に関わるようになって初めて体験した AWS の大規模な障害だったのだが、オンプレミスのシステムが障害を起こしたときと同じように AWS というかクラウドで障害が発生したときも情報収集が非常に重要になる。

たとえば、障害が発生した AZ のリソースを止めて別の AZ にリソースを立ててトラフィックを新しく立てたリソースに回して業務継続する……などの対応は障害の原因と影響範囲が分からないとできないし、クラウド上で動いているシステムがお客様のもので自分たちがその運用会社であるなら、状況をお客様へ報告をするためにも障害の原因と影響範囲は分かっていなければならない。

AWS で障害が発生したときにチェックしているページ

前フリが長くなったが先週 AWS の障害が発生したときにチェックしていたページをまとめておく。

AWS Personal Health Dashboard

AWS Personal Health Dashboard は情報が見やすいし探しやすいのがよい。

ただ、先週 AWS の東京リージョンで発生した障害では AWS コンソールを表示できなくなることがしばしばあったので、AWS Personal Health Dashboard 以外のページもチェックしておくほうがよさそうだった。

AWS Service Health Dashboard

AWS Service Health DashboardAWS の全サービスのステータスを見ることができる。

自分が関係しそうなリージョンは東京リージョンくらいなので Asia Pacific のタブだけを見ていたが、Asia Pacific という名前のとおり東京リージョン以外にも香港リージョンとかソウルリージョンなどのサービスステータスが一緒に掲載されている。東京リージョンにしか関心がない自分にはやや冗長さは感じたがページの性格上仕方なさそう。

Twitter

AWS 公式以外からの情報収集手段としては Twitter. It's what's happening. をチェックしていた。

先週の東京リージョンの障害は AWS 公式の発表は「単一の AZ で発生」ということだったが「単一の AZ ってどこなの?」というのが分からなかったのだが、Twitter で「AZ ID が apne1-az4 の AZ で障害が発生してる (らしい)」という情報を得られたので「あ、自分のところも影響ありそう」ということが分かったのは大きかった。

あと、インフラ業務を担当している人との謎の連帯感を感じられるので Twitter はチェックしておいたほうがいいと思う。

AWS Service Health Dashboard] の RSS フィードを Slack に追加

AWS Service Health DashboardRSS フィードを Slack に追加すると AWS のステータスが更新されたときに Slack のチャンネルに post してくれるようになる。

AWS Service Health Dashboard をチェックするのは pull 型の情報収集手段だがこの方法は push 型の情報収集手段になる。 障害発生中といえどダッシュボードに張り付くわけにもいかないことが多いと思うので push 型の情報収集手段はかなり便利。

さいごに

障害は起きないに越したことはないがそんなことはありえないし、最低限これくらいはチェックしておいたほうがよさそうなページをまとめてみた。