誰もが知っているように、Amazonは2月に事実上すべてのECXNUMXインスタンスを再起動しました。 彼らは人々に通知するために電子メールを送りましたが、誰もが電子メールを読んだわけではなく、Amazonは顧客に気付かずに自分のスケジュールで再起動を実行しました。
一部のSaaS企業では、これにより何時間ものダウンタイムが発生しました。 他の人にとっては、短い影響がありました。 違いは何でしたか?
通知までの時間
主な差別化要因の2つは、監視が実行されていた場所でした。 一部の企業はECXNUMX内で独自のモニタリングを実行していました。そのため、インスタンスが再起動されると、モニタリングも再起動されました。 自動的に回復しなかった場合、問題があることに気付く前に数時間の停止が発生しました。 (監視がダウンしているため、インフラストラクチャの残りの部分もダウンしていることを警告するものは何もありませんでした。)
修復までの時間
サーバーがダウンしていることを知ると、EC2でホストされているモニタリングを行っている人々は、問題があることを知っていましたが、モニタリングシステムを復旧するまで、他のシステムのステータスについては知らされていませんでした。 聞いたところによると、これにより回復時間が数時間長くなりました。 使用している方 サービスとしての監視 どのシステムとサービスが回復したか、どれが回復しなかったか、注意が必要かを即座に把握できました。そうすれば、データベースの回復、システムの再構築、または必要なものすべてにすばやく集中できます。
クラウドまたはデータセンター?
また、電源またはネットワークが回復するとすぐに監視を利用できるようにして、サービスを復元するために何に焦点を当てるべきかを知ることができます。
修復をスピードアップするために整理する
練習に
ことわざにあるように、練習は完璧になります。 DRドリルを実行します。 クラウドベースのレプリカをスピンアップし、無礼にシャットダウンします。 システムの依存関係の順序を知っていることを確認してください。 回復するのにかかる時間を確認してください。 モニタリングを使用して、次に何に対処するかをガイドすることに慣れてください。
ここで、可視性を監視せずに回復するのにかかる時間を想像してみてください。
重要なポイント:次のデータセンターまたはクラウドに影響を与えるイベントの前に、監視を構内ベースのシステムからサービスとしての監視に移動します。