誰もが知っているように、Amazonは2月に事実上すべてのECXNUMXインスタンスを再起動しました。 彼らは人々に通知するために電子メールを送りましたが、誰もが電子メールを読んだわけではなく、Amazonは顧客に気付かずに自分のスケジュールで再起動を実行しました。
一部のSaaS企業では、これにより何時間ものダウンタイムが発生しました。 他の人にとっては、短い影響がありました。 違いは何でしたか？
通知までの時間
主な差別化要因の2つは、監視が実行されていた場所でした。 一部の企業はECXNUMX内で独自のモニタリングを実行していました。そのため、インスタンスが再起動されると、モニタリングも再起動されました。 自動的に回復しなかった場合、問題があることに気付く前に数時間の停止が発生しました。 （監視がダウンしているため、インフラストラクチャの残りの部分もダウンしていることを警告するものは何もありませんでした。）
修復までの時間
サーバーがダウンしていることを知ると、EC2でホストされているモニタリングを行っている人々は、問題があることを知っていましたが、モニタリングシステムを復旧するまで、他のシステムのステータスについては知らされていませんでした。 聞いたところによると、これにより回復時間が数時間長くなりました。 使用している方 サービスとしての監視 どのシステムとサービスが回復したか、どれが回復しなかったか、注意が必要かを即座に把握できました。そうすれば、データベースの回復、システムの再構築、または必要なものすべてにすばやく集中できます。
クラウドまたはデータセンター？
もちろん、まったく同じ問題が独自のデータセンターの停止にも当てはまります。 最高のデータセンターでさえ、電力やネットワーク接続を失う可能性があります。 A / B電源と冗長ネットワークでは発生しないはずですが、発生します。 2つのデータセンター（ECXNUMXリージョンに類似）を使用している場合でも、複数のデータセンターを使用している場合でも、モニタリングをサービスとして使用することも同様に重要です。 すべてのデータセンターの外部で監視する必要があります（そうしないと、トーストの落下ジャムサイドダウンの法則に従って、監視をホストしているのは失敗することは間違いありません）。
また、電源またはネットワークが回復するとすぐに監視を利用できるようにして、サービスを復元するために何に焦点を当てるべきかを知ることができます。
修復をスピードアップするために整理する
インフラストラクチャには依存関係があります。 データベースがクラスター障害状態にあるNetAppに保存されている場合、データベースを起動しようとしても意味がありません。 したがって、監視機能を表示して、機能グループごとに物事を確認し、前提条件のシステムが稼働しているかどうかを評価できます。
練習に
ことわざにあるように、練習は完璧になります。 DRドリルを実行します。 クラウドベースのレプリカをスピンアップし、無礼にシャットダウンします。 システムの依存関係の順序を知っていることを確認してください。 回復するのにかかる時間を確認してください。 モニタリングを使用して、次に何に対処するかをガイドすることに慣れてください。
ここで、可視性を監視せずに回復するのにかかる時間を想像してみてください。
重要なポイント：次のデータセンターまたはクラウドに影響を与えるイベントの前に、監視を構内ベースのシステムからサービスとしての監視に移動します。