More than 5 years have passed since last update.

新卒2年目のインフラエンジニアがAWS障害でやったこと

Last updated at 2019-09-02Posted at 2019-09-02

8/23(金)に起きたAWSの東京リージョンでの障害について、
新卒2年目のインフラエンジニアとしてやったことをまとめておきます。
同様の障害が起きた時の備忘録代わりです。

障害発生時

監視しているサーバーでのステータスチェックエラーが広い範囲で生じたため、
障害の範囲を特定するために先輩エンジニアを参考に、以下を行いました。

Twitterで「AWS」と検索した時のツイートから、
されている言語/報告されている障害発生中のサービスを特定します。
記憶の限りでは、日本語で幅広いサービスで障害が確認できました。
（「AWS障害中？」「弊社のAWSサーバーが〜」みたいなツイートです。）

ここから日本限定で、かつ弊社の東京リージョンのサーバーの障害範囲から、
AWSの東京リージョンの一部で障害が発生していると仮説を立てました。
（この時点でAWSからの障害報告はありませんでした。）

AWSの障害情報がわかるダッシュボートの監視です。
AWS Service Health Dashboard

障害が発生してから数十分後に第一報がありました。
こちらを障害発生中に定期的に監視しておくことで、把握していない障害についても
検知できる可能性が高まります。
（今回だとEBS, RDSのエラー）

日中だったので手作業で監視していましたが、障害がいつまで続くか不明であったため、
SlackにRSSを使って自動投稿できるよう設定しました。
ただし、Slackへの投稿について以下のような条件で作成しています。

これらの条件は部署や近辺の人と相談して作成するのがいいと思います。

監視設定を入れていないサーバーが少なからずあったり、
同時多発的に発生したことで漏れたサーバーがないか実際にアクセスするなどして、
正常動作しているか確認しました。

監視から漏れているサーバーについては、サーバーの保有者に報告し対応していただくなど、
必要な復旧対応をおこないました。

そもそもとして、監視設定を重要度ごとに分けつつ、漏れなく全サーバーに入れることが
必要なのかもしれなかったです。（監視の負荷と兼ね合いですが）

障害範囲が複数アカウントで1a/1cと変化していたため、AZの仕組みを検索しました。
その際に共有したのが以下のリンクです。
AWSアカウントに因らずアベイラビリティゾーンを識別できるAZ IDを利用しよう #reinvent

また、所有しているRDSがマルチAZ構成になっているか、
フェイルオーバーしたさいの挙動などについても適宜共有しました。

実際に担当しているサーバーでも障害が起きていました。
こちらも先輩社員を参考に、現状と今後の方針の共有と復旧確認後の対応をしました。
あくまで先輩社員を参考にすることと、そこからの応用がメインでしたが、
障害に対して素早く状況把握と対応ができたと思います。

また、障害後にはqiitaなどで以下の内容の記事が多く出され、大変勉強になりました。

この記事も、備忘録兼、対応内容の参考になればと思っています。

まず、タイトルに新卒2年目とつけるか悩んだのですが、新卒2年目の姿勢として、
これからインフラエンジニアを目指す方の参考になればとつけました。

反省点も多くあるので、障害がまた発生した際は今回以上の対応ができるよう励みます。
（今回は、AWSの主要サービスで障害が起きた場合の対策知識の不足を感じました。）
あとは、１週間後に記事を書かずに直後に書けるよう頑張ります。。。