AWS Direct Connect (東京リージョン) 障害について
何が起きたか？
この9月2日の障害は、オンプレ→クラウド移行している弊社でも大きな影響がありました。原因についてはサーバーワークスさんの記事にAmazonからの公式発表がまとまっています。
原因は、「AP-NORTHEAST-1 リージョン内のすべての Availability Zone の Direct Connect に使用されているいくつかの主要なネットワーク機器が故障したことが原因です。」ということで、東京リージョン側のみの障害でした。ハードウェア障害はしょうがないと思いますが、時間がかかるのは、大規模であるがゆえの宿命ですかね。。。
サービスが順番に使えなくなっていく。。。
今、弊社側では多くのサービスがAWSに依存していますが、一番の発端はワークフローシステムでした。これは完全にSaaSなので、すぐに使えなくなりました。次に社内のクライアント系のサービスが順番に不安定になっていきました。
一番痛かったのは、弊社の基幹業務の一つで使っているシステム（Webサービス）が利用不能になったことです。業務停止。
緊急ミッション：バックアップ回線に切り替えろ！
障害の影響が顕著になってきたのが11時頃。基幹業務にも影響が出ていることが確認できましたので、業務システム（私）とインフラチームの間で対応についての緊急MTGがもたれました。こういうとき、業務システム側はマネージャーしか出ません。前任者もみなそうでした。機能担当者を混ぜるとみんな「大変だ、すぐ対応しろ！」しか言わないし。
・基幹業務への影響が大きいと判断する
・13時までに仮復旧できれば影響は最小限にできる
→副回線に切り替えよう！
15分くらいのMTGでバックアップ回線に切り替えるという判断をしました。当時はまだ復旧目途が発表されていませんでしたから、このままの状況で継続するよりも不安定でも復旧を優先する方が影響が大きいと判断しました。方針を決めたらトップマネジメント層と実施について報告し、切り替えを進めることになります。
起きていることを明示化することで安心させる
以前はこういったときには大混乱になっていましたが、今はこちらもある程度ノウハウがそろっています。
今回の場合、私とインフラチームのマネージャーは、やることを決めたら、後は全社向けの広報としては「広範囲に障害が起きている」→「バックアップ回線に切り替える（不安定になるかも）」までしか出しませんでした。そのうえで、部内向けの情報共有としては、どのシステムがどういった状況なのか（不稼働、不安定、稼働）機能担当者に状況を聞きながら障害共有のプロジェクト（部内限り）に書き出して共有を続けました。現場間の会話は、各機能担当者に任せます。
これを行うことで、部内では「可視化されている」という安心感を得られますし、復旧したときの動作確認に大変役立ちました。
なお、この情報共有をやっている限り、部課長は何も聞かずにチケットから勝手に情報を収集して上層部とのやり取りをしてくれます。これで、我々は対応に注力することができます。
＜このときの役割分担＞
・インフラチーム：実対応のコントロール
・業務システム：影響範囲の確認と可視化
・トップマネジメント層：外部との交渉・報告役
あとは、切り替えや復旧時のマイナートラブルはいろいろありましたが、まあなんとか切り戻しまで無事に終了。
いろいろとしんどい数日間でしたが、これもクラウドの宿命ですね、ということで、経験則を積んでいきたいと思います。
この記事が気に入ったらサポートをしてみませんか？