実用的なアラート
このモジュールではこれまで、システムの信頼性を検討し、測定し、それに対処する方法を探ってきました。 しかし、その信頼性と私たちが対話する方法もあります。それがアラートです。 前述の SLI や SLO などのさまざまなメトリックとシグナルに基づいてアラートを送信するように、Azure Monitor とその他のツールを設定することは簡単です。 Azure を使用すると、Azure Service Health 機能により、サービスの問題に基づくアラートを送信することもできます。
アラートは簡単に送信できますが、そこには潜在的な危険が存在します。 ここで、前述の SRE の定義にある "持続的に" という言葉が関係してきます。
サイト信頼性エンジニアリングとは、組織がシステム、サービス、製品で適切なレベルの信頼性を持続的に達成できるようにすることを目的としたエンジニアリング分野です。
アラートは、システムに問題がある場合に通知するように設計されています。 ただし、アラートが正しく構成されていないと、持続可能な運用プラクティスを作成するという目標が損なわれる可能性があります。 SLI と SLO を組織に導入するために費やしたすべての労力を詳細情報に反映することは可能ですが、それは担当者に対する大量のアラートに変わる可能性があります。 "アラート疲れ" は、運用コミュニティではよく知られた病です。 このユニットは、組織内でそれが発生しないようにすることを意図しています。
アラート疲れの主な要因は、実用的でないアラートです。 それらを作成しないようにする方法を見てみましょう。
何がアラートであり、アラートではないのか
不適切なアラートが問題につながる理由を理解するには、アラートの目的と、アラートが他の運用シグナルとどのように異なるかを検討する必要があります。
実用的なアラートで "ない" もの:
ログ: アラートはイベントのレコードではありません。これはログのジョブです。 イベントの発生を記録しようとしているだけの場合は、ポケットベルではなく、ログ ファイルに書き込みます。
通知: アラートは、ソフトウェアのビルドの完了など、重大ではないできごとを通知するためのものではありません。 ちょっとしたお知らせを配信するためだけに、だれかの邪魔をして、集中力を途切れさせる必要はありません。
ハートビート: システムが引き続き実行中であることを通知するために、アラートを使用するべきではありません。 "あのシステムから 1 時間に少なくとも 1 ページは受け取らないと、何かがおかしいので、それに対処しなければならない" と人々が口にする状況を見たことがあります。ひどい話です。
実用的なアラートは、問題を修復するために人間が調査および対処する必要がある状況で使用されます。 アラートは、だれかの注意を必要とする例外的なまたは予期しない何かが発生したことを知らせるものであるべきです。
イベントがシステムで自動化プロセス (事前設定された制限内でのリソースのスケーリングなど) によって処理できるものである場合、アラートは必要ありません。 システムではこれを処理し、行をログに書き込む必要があります。 正常に処理された状況であることを午前 2 時に通知すべきではありません。
実用的なアラートを作成する
アラートを実用的なものにするには、次の内容が必要です。
単純化: 受信者が頭を悩ませてから初めて何をすべきかわかるようなアラートは、作成しないようにします。 アラートが複雑すぎると、真夜中に起こされてしまったユーザーが、単にその意味を解明するために貴重な時間を失うことになります。
スコープ: メッセージを受信するユーザーが、効果的にトリアージするために最初に行うべきことの 1 つは、問題のスコープを判断することです。 問題は、1 つのサーバーに関するものですか? 1 つのサービスに関するものですか? リージョン全体に関するものですか? 世界全域? 受信者がわかりやすいよう、この情報をアラートに追加します。
コンテキスト: アラートを受信するユーザーが、そのアラートの処理を開始するために知っておくべきことは何でしょうか。 この点について詳しく説明します。
アラートのコンテキストを提供する
必要なコンテキストを受信者が把握できるように、実用的なアラートに常に含める必要があるいくつかの要素を見てみましょう。
アラートの発信元? 多くの組織は、一度に複数の監視システムを使用しており、相互接続された多数のシステムを備えています。 たとえば、"この給与システム THX-1138 のアラートは、Azure Monitor サブスクリプション 'prod' に起因します" というアラートが表示された場合、多大な時間を節約できます。
違反された期待値 現在の状態を単に説明するアラートは、それほど役には立ちません。 "データベース サーバーが 80% の負荷で実行されています" を、"60% 以下の負荷で実行する必要があるが、過去 2 時間、データベース サーバーが 80% の負荷で実行されています" と比べてみてください。
問題となる理由 状況によって顧客にもたらされたか、またはもたらされる可能性のある効果または影響に関する情報により、重要度を判断し、反応を適切に評価することができます。
次に実行する手順 可能であれば、アラートには、応答者が次に行うべき内容を含める必要があります。この問題の診断と修復に関するヘルプを見つけるためのトラブルシューティング ガイドまたはその他のドキュメントへのポインターである場合でも、同様です。
このような役に立つコンテキストを含めて、アラートを実用的なものにすることで、運用プラクティスをより確実に維持し、これらのアラートに容易に対応できるようになります。