8/23(金)に起きたAWSの東京リージョンでの障害について、
新卒2年目のインフラエンジニアとしてやったことをまとめておきます。
同様の障害が起きた時の備忘録代わりです。
障害発生時
監視しているサーバーでのステータスチェックエラーが広い範囲で生じたため、
障害の範囲を特定するために先輩エンジニアを参考に、以下を行いました。
Twitter監視
Twitterで「AWS」と検索した時のツイートから、
されている言語/報告されている障害発生中のサービスを特定します。
記憶の限りでは、日本語で幅広いサービスで障害が確認できました。
(「AWS障害中?」「弊社のAWSサーバーが〜」みたいなツイートです。)
ここから日本限定で、かつ弊社の東京リージョンのサーバーの障害範囲から、
AWSの東京リージョンの一部で障害が発生していると仮説を立てました。
(この時点でAWSからの障害報告はありませんでした。)
AWS Service Health Dashboard 監視
AWSの障害情報がわかるダッシュボートの監視です。
AWS Service Health Dashboard
障害が発生してから数十分後に第一報がありました。
こちらを障害発生中に定期的に監視しておくことで、把握していない障害についても
検知できる可能性が高まります。
(今回だとEBS, RDSのエラー)
日中だったので手作業で監視していましたが、障害がいつまで続くか不明であったため、
SlackにRSSを使って自動投稿できるよう設定しました。
ただし、Slackへの投稿について以下のような条件で作成しています。
- suffixに障害発生日を設定してチャンネルを作成すること
- 障害が終了した時点でRSS連携を外し、チャンネルを削除すること
- 任意参加のチャンネルであること
これらの条件は部署や近辺の人と相談して作成するのがいいと思います。
監視外で障害が起きているサーバーの探索
監視設定を入れていないサーバーが少なからずあったり、
同時多発的に発生したことで漏れたサーバーがないか実際にアクセスするなどして、
正常動作しているか確認しました。
監視から漏れているサーバーについては、サーバーの保有者に報告し対応していただくなど、
必要な復旧対応をおこないました。
そもそもとして、監視設定を重要度ごとに分けつつ、漏れなく全サーバーに入れることが
必要なのかもしれなかったです。(監視の負荷と兼ね合いですが)
必要そうな技術知識の共有
障害範囲が複数アカウントで1a/1cと変化していたため、AZの仕組みを検索しました。
その際に共有したのが以下のリンクです。
AWSアカウントに因らずアベイラビリティゾーンを識別できるAZ IDを利用しよう #reinvent
また、所有しているRDSがマルチAZ構成になっているか、
フェイルオーバーしたさいの挙動などについても適宜共有しました。
その他
実際に担当しているサーバーでも障害が起きていました。
こちらも先輩社員を参考に、現状と今後の方針の共有と復旧確認後の対応をしました。
あくまで先輩社員を参考にすることと、そこからの応用がメインでしたが、
障害に対して素早く状況把握と対応ができたと思います。
障害終了後
また、障害後にはqiitaなどで以下の内容の記事が多く出され、大変勉強になりました。
- マルチAZ構成についての記事
- 今回の障害でマルチAZ構成でも影響が出た原因
- このような障害に対する対策
この記事も、備忘録兼、対応内容の参考になればと思っています。
まとめ
まず、タイトルに新卒2年目とつけるか悩んだのですが、新卒2年目の姿勢として、
これからインフラエンジニアを目指す方の参考になればとつけました。
反省点も多くあるので、障害がまた発生した際は今回以上の対応ができるよう励みます。
(今回は、AWSの主要サービスで障害が起きた場合の対策知識の不足を感じました。)
あとは、1週間後に記事を書かずに直後に書けるよう頑張ります。。。