アラート疲れとは？原因と、通知を減らす具体的な手順

監視のチャンネルに通知が流れ続け、誰も読まなくなっている。夜中に呼び出されたのに、行ってみると何もする必要がなかった。こうした状態が続くと、本当に重要なアラートも見落とすようになります。この記事ではアラート疲れとは何か、なぜ起きるのかを説明したうえで、今あるアラートを棚卸しして通知を減らす手順を、設定例とあわせて紹介します。

アラート疲れとは

アラート疲れ (alert fatigue) とは、対応の必要がない通知を大量に受け取り続けた結果、通知に慣れてしまい、重要な通知への反応が鈍くなる状態のことです。監視やインフラ運用だけでなく、セキュリティ運用や医療の現場でも同じ言葉が使われます。

アラート疲れは担当者の注意力や気構えだけの問題ではありません。通知の設計に原因があり、設計を直すことで減らせます。

次のような様子があれば、アラート疲れが起きている可能性があります。

• 監視のチャンネルが通知で埋まり、ミュートしている人がいる
• 「あのアラートはいつも出るから無視してよい」という申し送りがある
• 障害のあとで振り返ると、アラートは出ていたのに誰も反応していなかった
• 1 つの障害で数十件の通知が届き、どれから見ればよいか分からない
• オンコール (当番として呼び出しを受ける役) の担当者が、夜間の呼び出しで翌日の仕事に支障をきたしている

アラート疲れが問題になる理由

最も大きな問題は、本当の障害への反応が遅れることです。100 件の通知のうち 99 件が対応不要なら、残りの 1 件も「どうせまた同じ」と読み流されます。障害の振り返りで「アラートは出ていた」と分かるのは、アラート疲れの典型的な結末です。

もう 1 つは、担当者への負担です。Google の SRE の資料では、低い優先度のアラートが 1 時間に 1 回以上鳴るような状態は生産性を下げ、深刻なアラートへの注意も薄れさせる、と指摘しています。夜間の不要な呼び出しが続けば睡眠が削られ、当番を嫌がる空気が生まれ、特定の人に負担が偏ります。

アラート疲れの主な原因

通知が増えすぎる原因は、だいたい次のどれかにあてはまります。

アラートは足すのは簡単ですが、消すのは「何かあったら困る」という不安から後回しにされがちです。その結果、一度作られたアラートが積み重なっていきます。

減らし方 1：今あるアラートを棚卸しする

最初にやるべきことは、今のアラートが実際にどれだけ鳴り、どれだけ役に立っているかを知ることです。過去 30 日分の通知を集め、アラートごとに次のような表を作ります。通知を Slack などに送っているなら、チャンネルの履歴から数えられます。

表ができたら、アラートごとに 4 つの処置のどれかを選びます。

上の表の例なら、ディスクの空きのアラートは「直す」か「消す」の候補です。毎日発火しているのに容量が増えていないなら、閾値の 20% がそのディスクの普段の水準に合っていません。「残り何日で埋まるか」の判定に変えれば、本当に増え始めたときだけ通知できます。DB の CPU は 46 回中 1 回しか対応が要らなかったので、継続時間を延ばすか、症状側の指標 (応答時間やエラー率) に置き換えることを検討します。

毎回同じ手順で対応しているアラートは、対応を自動にできないかも考えます。SRE の資料には「機械的な対応で済むなら、人を呼ぶべきではない」という考え方があります。

減らし方 2：重大度と通知先を分ける

すべての通知が同じ場所に同じ形で届くと、緊急のものとそうでないものの区別がつきません。重大度を決め、重大度ごとに通知先と期待する対応を変えます。

重大度を決めるときの問いは「これが夜中の 3 時に鳴ったら、起きて対応すべきか」です。答えが「朝で間に合う」なら、それは緊急ではありません。

緊急として扱うものは、利用者が感じる症状 (エラー率、応答時間、注文や決済の失敗) を中心にします。CPU 使用率や接続数のような原因側の指標は、ディスクが数時間で埋まるといった確実で差し迫った場合を除き、警告か情報に回します。症状と原因の区別は アラートの閾値の決め方 で詳しく説明しています。

減らし方 3：まとめる・抑止する・止める

1 つの障害で何十件も通知が届く問題は、通知をまとめる仕組みと、関連する通知を抑止する仕組みで減らせます。Prometheus の Alertmanager を例に、主な設定を紹介します。

route:
  receiver: chat-monitoring
  group_by: [alertname, cluster]   # 同じアラート名・同じクラスターの通知を 1 通にまとめる
  group_wait: 30s                  # 最初の通知の前に、関連する通知が届くのを待つ
  group_interval: 5m               # まとめた通知の続報を送る間隔
  repeat_interval: 4h              # 状態が変わらない通知を再送するまでの間隔
  routes:
    - receiver: oncall-phone
      matchers:
        - severity = critical
    - receiver: chat-monitoring
      matchers:
        - severity = warning
      mute_time_intervals: [weekend]   # 警告は週末は送らない

time_intervals:
  - name: weekend
    time_intervals:
      - weekdays: ['saturday', 'sunday']
        location: Asia/Tokyo

inhibit_rules:
  - source_matchers:
      - severity = critical
    target_matchers:
      - severity = warning
    equal: [alertname, cluster]    # 同じ問題で緊急が出ている間は、警告を送らない

receivers:
  - name: oncall-phone
  - name: chat-monitoring

group_by は同じ種類の通知を 1 通にまとめます。Alertmanager の公式ドキュメントでは、ネットワークの分断で多数のサービスが DB に接続できなくなった場合に、何百もの通知ではなく 1 通のまとまった通知にできる、という例を挙げています。group_wait、group_interval、repeat_interval の既定値はそれぞれ 30 秒、5 分、4 時間です。

inhibit_rules はある通知が出ている間、関連する別の通知を止めます。上の例は「同じ問題で緊急の通知が出ているなら、警告は送らない」というルールです。同じ仕組みで、「DB が止まっている間は、DB に依存するアプリのエラー率の通知を止める」といった抑止もできます。

計画したメンテナンスの間は、サイレンス (一定時間、条件に合う通知を止める機能) を使います。メンテナンスのたびに大量の通知が届く状態は、通知を読み流す習慣をつくる原因になります。

Amazon CloudWatch を使っている場合は、複合アラーム (composite alarm) で複数のアラームの状態を ALARM("...") AND ALARM("...") のような式で組み合わせ、通知を複合アラームだけから送る構成にできます。個々のアラームは状態の判定だけに使い、通知は複合アラームにまとめれば、1 つの障害で届く通知の数を減らせます。

発火と解除を繰り返すフラッピングには、継続時間の条件 (Prometheus の for、CloudWatch の --datapoints-to-alarm) と、発火後しばらく解除しない設定 (Prometheus の keep_firing_for) が効果的です。

減らし方 4：通知の中身を変える

通知の数を減らしても、届いた通知を読んで何をすべきか分からなければ、対応は遅れます。通知の本文には少なくとも次の内容を入れてください。

• 何が起きているか (指標と、現在の値、普段の値)
• 利用者や業務への影響 (どの機能が、どの範囲で)
• 最初に見る場所 (ダッシュボードのリンク、調べるためのクエリ)
• 対応の手順書 (ランブック) へのリンク
• このアラートの持ち主

たとえば「CPUUtilization > 80」だけの通知と、次のような通知とでは、受け取った人の動き出しの速さが違います。

[緊急] 決済の失敗率が 30 分続けて 25% (普段は 1% 前後)
影響: クレジットカード決済のみ。コンビニ決済は正常
確認: 決済ダッシュボード https://example.com/dash/payments
手順: https://example.com/runbook/payment-failure
持ち主: 決済チーム

手順書を書けないアラートは、何をすべきかが決まっていないということです。そうしたアラートを緊急の通知として残す必要があるかは、もう一度考える価値があります。

オンコールへの影響と、負担の目安

アラート疲れの影響を最も強く受けるのは、オンコールの担当者です。Google の SRE の資料では 1 件のインシデントの対応 (原因の調査、復旧、事後の作業) に平均で 6 時間ほどかかるとして、12 時間の当番で扱えるのは 2 件までという目安を示しています。また、呼び出しは日によって偏らないようにし、1 日あたりの中央値は 0 件であるべきだとしています。

この目安に照らすと、毎晩のように呼び出されている状態は、担当者の努力では解決できない量だと分かります。オンコールの負担を次のような数字で見える化し、チームで共有してください。

SRE の資料には、通知と障害の数の比を 1 対 1 に近づける、という考え方があります。1 つの障害に通知が 1 通なら、受け取った人は迷わずに対応を始められます。

障害のあとの振り返りでは、原因と対処に加えて「アラートは適切だったか」も話し合ってください。気づくのが遅れた、通知が多すぎた、通知の中身が足りなかった、という点はそのまま次の改善になります。振り返りの進め方は ポストモーテム の記事で扱っています。

減らした状態を保つには

棚卸しで通知を減らしても、新しいアラートを足すたびにまた増えていきます。アラートを追加するときは、持ち主、重大度、発火したらすること、の 3 つを決めることを決まりにすると、持ち主のいないアラートが積み重なるのを防げます。そのうえで、月に 1 回か四半期に 1 回、発火の記録を見返して棚卸しをくり返します。

AI に任せる方法もあります。Scandock は AI がデータベースを監視するサービスで、固定の閾値ではなく、値の推移、過去の発火とその結末、プロジェクトに蓄積した知識を踏まえて異常かどうかを判断します。異常と判断すると、読み取り専用のクエリで関連するデータを調べて原因を追い、原因・影響・根拠・対処案をつけて通知し、誤検知と分かれば閉じます。通知先は Slack、Microsoft Teams、メール、LINE WORKS など 10 種類から選べます。

参考

• Google SRE Book: Monitoring Distributed Systems
• Google SRE Book: Being On-Call
• Prometheus: Alertmanager
• Prometheus: Alertmanager configuration
• Prometheus: Alerting rules
• Amazon CloudWatch: Create a composite alarm