継続的なチューニングを実行して無意味なアラートを減らす
このユニットでは、サイトの信頼性を監視するために実装できるプロセスについて説明します。 また、アラートを継続的にチューニングして、無意味なアラートを減らす方法についても説明します。
監視とアラート
監視とアラートを使用すると、システムが破損したときにユーザーに通知したり、またおそらく、破損しそうであることを通知したりすることができます。 だれかが問題を調査する必要があるとき、アラートには関連情報が記載されているはずなので、どこから開始すればよいかがわかります。
既存のアラートをレビューしたり、新しいアラート ルールを作成したりする場合は、次のガイドラインを考慮してアラートの関連性を保ち、オンコールのローテーションが健全になるようにします。
- 人の注意を引きつけるアラートは、緊急の、重要な、アクション指向の、リアルなものである必要があります。
- アラートでは、サービスに関する進行中または差し迫った問題が表されている必要があります。
- ノイズの多いアラートを削除します。 過度な監視は、不十分な監視よりも解決するのが困難な問題です。
- 次のいずれかのカテゴリに問題を分類します。
- 可用性と基本機能。
- Latency。
- 正確さ。
- 機能固有の問題。
- 症状は、問題を包括的かつ確実に、より少ない労力で把握するためのより優れた方法です。
- 症状ベースのページまたはダッシュボードには原因ベースの情報を含めます。ただし、原因について直接アラートすることは避けます。
- より上のサービス スタックに進むにつれて、1 つのルールでキャッチする問題がより明確になります。 ただし、何が起こっているのかを十分に識別できないほど上に進まないでください。
- 平穏なオンコールのローテーションを実現したい場合は、タイムリーな対応が必要だが差し迫って重大ではない問題に対処するためのシステムを用意します。
ユーザーを監視する
ユーザーの監視は、"症状ベースの監視" とも呼ばれます。これは、"原因ベースの監視" とは対照的です。 ユーザーはデータ プッシュが失敗するかどうかを気にすることはありません。結果が新しいかどうかを気にします。
一般に、ユーザーは次のことを気にします。
- 基本的な可用性と正確さ: 何らかの形でコア サービスが中断された場合は、利用不可と見なされます。
- 待ち時間: ページはすばやく読み込まれる必要があります。
- 完全性、鮮度、持続性: ユーザーのデータは安全であり、すぐに返され、検索インデックスは最新の状態である必要があります。
- アップタイム: サービスが一時的に利用できない場合でも、サービスはすぐにバックアップされるという完全な信頼感をユーザーに与える必要があります。
- 機能: ユーザーは、サービスのすべての機能が動作することを気にします。 コア機能でないとしても、サービスの重要な側面であるすべてを監視します。
利用不可になっているデータベース サーバーと、利用不可になっているユーザー データとの間には、わずかですが重要な違いがあります。 前者は直接の原因であり、後者は症状です。
原因ベースのアラートの役割
場合によっては、アラートすべき症状はなくても、ある状況に対してアラートを受け取る必要があります。 たとえば、メモリが不足している場合です。 症状を引き起こす前に、問題になる可能性のある懸念事項について通知するルールが必要です。 この場合は、この条件に対してアラートを生成するルールを作成できます。
ただし、他の方法でキャッチできる症状に対してオンコールのアラートをトリガーする原因ベースのルールは作成しないでください。
チケット、レポート、および電子メール
早期に対処が必要だが直ちに必要ではないアラートは、"サブクリティカル アラート" です。 後でフォローアップするためにサブクリティカル アラートをログに記録しておくための、いくつかの提案を次に示します。
- バグまたはチケット追跡システムは、この種類のアラートに役立つ場合がある: アラートは、1 つのチケットまたはバグに同じアラートが正しく配置されていれば、バグを開くことができます。 これらのバグは、次にトリアージ プロセスを通過して、フォローアップのためにだれかに割り当てることができます。 クリティカルになる前に、これらの種類の問題に対処することが重要です。 バグの修正に、チーム メンバーの時間をどの程度割り当てることができるかを考慮してください。
- 日単位の (またはより頻繁な) レポートが役に立つ場合がある: 有効期間が長いサブクリティカル アラート (たとえば、データベースの使用率が 90% を超えている場合) を、すべてのアクティブなアラートを示すレポートに対して記述します。 このレポートを毎日トリアージするように、だれかを割り当てます。
- すべてのアラートをワークフロー システムを通じて追跡する必要がある: これにより、確実に表示されて対処されます。
一般に、応答に対する説明責任を促進するシステムを作成しますが、即時に人間が介入する高コストはかけないようにします。
プレイブック
プレイブック (Runbook とも呼ばれます) は、アラート システムの重要な部分です。 症状をキャッチする各アラートまたはアラートのファミリに対して、対処方法が説明されたエントリをプレイブックに用意します。
追跡と説明責任
だれかがアラートを受け取って、問題がないと判断した場合、それはそのルールを削除するか、降格するか、または他の方法でデータを収集する必要があることを示しています。 正確性が 50% 未満のアラートは、破損していると見なされます。 10% の確率で擬陽性がトリガーされるアラートでも、再評価する価値があります。
トリガーされたすべてのオンコール アラートを週単位でレビューし、アラートの統計情報を四半期ごとに分析することで、個々のアラートに焦点を当てた場合には見逃されてしまうパターンを確認できます。
ルールの例外を求める条件
上記のガイドラインを破ることがある理由を、次にいくつか示します。
症状のノイズの下に、既知の原因が実際にある: たとえば、サービスの可用性が 99.99% であっても、0.001% の要求が失敗する原因となる一般的なイベントがある場合、それはノイズに含まれるため症状としてアラートすることはできませんが、原因となるイベントをキャッチすることはできます。
データの解像度が失われるため、エントリ ポイントで監視することができない: たとえば、クレジット カードの検証など、一部のエンドポイントでは低速であることが許容されます。 ロード バランサーでは、この区別が失われる可能性があります。 区別できる最も高い場所からスタックとアラートを進んでいく必要があります。
もう手遅れになるまで症状が現れない: たとえば、クォータが不足しているとします。 手遅れになる前にだれかにアラートを通知する必要があり、それは場合によっては、アラートする原因を見つけることを意味します。 たとえば、使用量が 80% を超えていて、過去 1 時間の増加率では 4 時間以内に不足が発生する場合です。
ただし、緊急度の低い同様の原因も見つけられる必要があります。 たとえば、クォータが 90% を超えていて、過去 1 日の増加率では 4 日以内に不足が発生する場合です。 そのような一連の状況では、ほとんどのケースがキャッチされます。 その後、アラートによって表される土壇場のエスカレーションではなく、チケットや電子メール アラートや毎日の問題レポートとして問題を処理できます。
アラートのセットアップが、それによって検出しようとしている問題より複雑になる: 目標は、シンプルで堅牢な自己防衛システムに向かって進むことであるべきです。