AWSの停止後、バックアップとDRプロセス全体を再構築するにはどうすればよいか!?

先日は、BDRチームだけでなく、怒りの顧客メールや受信トレイの混乱に目を覚ました幹部からも、この質問を何十回も聞いたに違いありません。

それを理解しています。AWSがこのようにダウンすると、本能的にすべてに疑問を抱く。数字を見てください:Amazon自体は1時間あたり~$73Mを失ったと伝えられています。初期のレポートによると、Snapchat、Fortnite、Zoom などの企業は、時給 500 ドル前後のヒットを記録しました。これは、保険や訴訟費用が発生する前に、ダウンタイムとして 7 桁、場合によっては 8 桁のダウンタイムになります。

そうです、パニックは理解できます。しかし、人々に言い続けたことは次のとおりです。
ゼロから再構築する必要はありません。ただ、より良く実行する必要があります。

実際のところ、ほとんどのチームは、リージョン全体の停止を計画していませんでした。不注意だったからではなく、そのような出来事がほとんど理論的に感じられたからです。

復元の約 80% は単純で、いくつかのファイルが削除され、場合によっては重要なインスタンスが 1 つか 2 つあります。ほとんどのクラウドチームは、これらを手動で処理します(N2WSなどのツールを使用して次に進むチームもあります)。

しかし、今回は違った。すべてが一度にダウンした場合、「手動回復」が実際にいかに脆弱であるかが明らかになりました。

何を復元すればよいか推測する必要はありません。その場で優先順位を把握する必要はありません。手順書が重要です。

また、データを回復するだけでなく、サブネット、ルーティングテーブル、セキュリティグループなど、ネットワークスタック全体を回復しました。すでにクローンが作成されており、起動する準備もです。

N2WSでこれらのシナリオを簡単に構築してテストできるようになり、回復が筋肉の記憶になりました。

あるグローバルなSaaSのユーザは、その後次のように語っています。

「幸いなことに、US-East-1がダウンしたときに、地域を越えた回復シナリオはすでに整っていました。私たちは計画をトリガーしただけで、約15分で完全な環境を別の地域に稼働させました。」

それがレジリエンスとはそういうものです。

先週教えてくれたことが 1 つあるとすれば、最高の DR 計画は最も複雑ではなく、考えすぎずにプレッシャーの下で実際に実行できる計画であるということです。

Posted in: N2WS