エレノア・ルーズベルトは、「他人の過ちから学びなさい。 それらをすべて自分で作るのに十分な長さで生きることはできません。」 その精神で、私たちはあなたが学ぶことができるように私たちが犯した間違いを共有しています。
先週末、サービスに影響を与える問題が約90分間発生し、東海岸の一部の顧客に影響を及ぼしました。 ご想像のとおり、これはサーバーを非常に徹底的に監視しているにもかかわらずです。 エラーレベルのアラート（ユーザーのポケットベルにルーティングされる）は、問題の発生中に繰り返しトリガーされました。 エラーアラートのエスカレーションには複数の段階があります。 また、常に連絡可能なアラートへの対応を担当するオンコールスタッフが常にいることを保証します。
これらの条件はすべて今週末に当てはまりましたが、最初のアラートがトリガーされてからXNUMX時間以上、誰にもアラートが送信されないという問題がありました。 これはどのようにして可能でしたか？
それは（ほとんどの失敗がそうであるように）複数の条件が相互作用した結果でした。
まず、その週のプライマリオンコールエンジニア（エスカレーションチェーンのステージ1）は、24時間連絡が取れなくなりました。 彼はこれを知っていましたが、ステージ2に移動する代わりに、ステージ2の相手に連絡が取れないことを通知し、LogicMonitorのアラートシステムのエスカレーションに依存していました。 これは、そのようなアラートが5分遅れて、5分の再送間隔が次の段階にエスカレートするのを待つことを意味しましたが、これは許容できるリスクであると彼は考えました。アラートが発生する可能性が低い場合でも、遅延が長すぎるようには見えません。
次に、発生したエラーは「電圧低下」状態のようなものでした。 エラーがトリガーされ、アラートがステージ1に送信されましたが、5分のエスカレーション間隔が経過し、エラーがステージ2のエンジニアに送信される前に、状態がクリアされ、サービスが数分間回復しました。 その後、状態が再発し、アラートが送信され、再びクリアされました。 アラートがステージ2にエスカレートされる前にクリアされた、数分のサービスへの影響のこのパターンは、何度も繰り返されました。 アラートがステージ2にエスカレートするのに十分な時間持続した場合にのみ、応答できる誰かにアラートが送信されました。 （彼は数分以内にそれを行い、問題のあるサービスを再開し、サービスを復元しました。）
第三に、これは日曜日に発生しました。 週の半ばに発生した場合は、ダッシュボードまたはHip Chat統合を介して、エラーのアラートまたはTechOpsチャットルームに重大なアラートを投稿することで通知されます。 （これについては後で詳しく説明します。）
将来これを防ぐ方法は？ これはあなたが私たちの過ちから学ぶことができる場所です。 短いアラート/アラートクリアサイクルがアラートが適切な人に適切なタイミングで届くのを妨げないようにする方法は1つあります。 XNUMXつ目は、単純なプロセスです。ステージXNUMXのアラート受信者が利用可能になるようにします。 （振り返ってみると「duh」プロセスの種類…）XNUMX番目：アラートに影響を与えるサービスについては、 アラートクリア間隔 は、エスカレーション間隔の前にアラートがクリアされないように十分に長く設定されています。
アラートクリア間隔を少なくとも6分に設定していた場合、生データがアラートをトリガーしなくなった場合でも、アラートは5分のエスカレーション期間で有効になります。 ステージ2のエンジニアは、最初のアラートを受け取ります。 （コンピューターの前にいなかった場合は、XNUMX分後にアラートがクリアされたため、何もしなかった可能性がありますが、次に問題が発生したときにXNUMX回目のアラートを受信していました。しばらくして、間違いなく調査し、問題を解決したでしょう。）
アラートクリア間隔を少なくともエスカレーション間隔と同じ長さに設定すると、ステージ1がボールをドロップした場合（または意図的にボールをドロップすることを計画している場合でも）、短い「フラッピング」アラートが引き続き注目されます。もちろん、ステージ2がアラートを確認、スケジュールダウン、またはその他の方法で処理する場合、アラートはまったくエスカレーションされないため、ステージ1は気付かないままになる可能性があります。
（別のオプション：各ステージで常に複数の人に連絡するようにしますが、責任の拡散の問題があるため、一般的にはお勧めしません。）
更新します アラート応答のベストプラクティス これを反映するための文書ですが、ブログを介してより早く情報を発信すると考えました。