アラート設計

良いアラートの条件

アラート（Alert） は、人間の介入が必要な状態をオペレーターに通知する仕組みです。 良いアラートには 3 つの性質があります：対処可能（actionable）、適時的（timely）、十分な文脈がある（contextual）。 これらを満たさないアラートはノイズとなり、本当に重要な通知を見落とす原因になります。

アラート疲れ

アラート疲れ（Alert Fatigue） は、大量の不要な通知によってオペレーターの注意力が低下する現象です。 『入門監視』第 3 章が指摘するとおり、メール通知はアーカイブされるだけの「アラートの墓場」になりがちです。 対処不要なアラートは削除するか情報レベルに下げ、通知チャネルを PagerDuty や Slack に限定しましょう。

SLI/SLO ベースのアラート

CPU 使用率やメモリ量のような原因指標ではなく、SLI（Service Level Indicator） に基づいてアラートを設計します。 「レスポンスの 99% が 300ms 以内」という SLO を定義すれば、ユーザー影響に直結した通知が可能です。

# Prometheus alerting rule: 30分間のバーンレートが閾値超過
groups:
  - name: slo_alerts
    rules:
      - alert: HighErrorBurnRate
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m]))
          ) > 14.4 * 0.001
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "エラーバーンレートが SLO を超過しています"
          runbook_url: "https://wiki.example.com/runbooks/high-error-rate"

バーンレートアラート

バーンレート（Burn Rate） は、現在のエラー率で SLO のエラーバジェットを消費し尽くす速度を表します。 バーンレート 1 なら予算ちょうど消化、14.4 なら 1 時間で 1 日分のバジェットを消費することを意味します。 短い窓（5 分）と長い窓（1 時間）を組み合わせた Multi-Window アラートにより、精度と速度を両立させます。

Runbook の整備

アラートごとに Runbook（対応手順書） を紐づけ、アラート通知に URL を含めます。 Runbook には「何が起きたか」「確認すべきダッシュボード」「初期対応コマンド」「エスカレーション先」を記載します。 深夜 3 時に起こされたオペレーターが迷わず動けることがゴールです。

まとめ

📖 参考: 『入門監視』第 3 章 — アラート、オンコール、インシデント管理