ストーリー

アラート疲れ（Alert Fatigue）

悪いアラート設計:
  1日に100件のアラート → 95件は誤報 → チームがアラートを無視 → 本当の障害を見逃す

良いアラート設計:
  1日に2-3件のアラート → すべてアクションが必要 → チームが即座に対応

アラート設計の原則

1. すべてのアラートはアクションを伴う

// 良いアラート: 具体的なアクションがある
interface GoodAlert {
  name: 'API Error Rate > 5%';
  action: 'オンコール担当者がダッシュボードを確認し、原因を調査';
  runbook: 'https://wiki.example.com/runbook/high-error-rate';
}

// 悪いアラート: アクションが不明確
interface BadAlert {
  name: 'CPU usage > 50%';
  action: '???';  // 何をすればいいかわからない
}

2. SLOベースのアラート

// 症状ベース（推奨）: ユーザーに影響があるときにアラート
const symptomBasedAlert = {
  name: 'SLO Burn Rate Alert',
  condition: 'エラーバジェットの消費速度が通常の14.4倍',
  meaning: 'このペースだと1時間で月間エラーバジェットの2%を消費',
};

// 原因ベース（非推奨）: インフラの状態変化でアラート
const causeBasedAlert = {
  name: 'High CPU Alert',
  condition: 'CPU使用率 > 80%',
  problem: 'CPUが高くてもユーザーに影響がない場合がある',
};

3. Multi-window, Multi-burn-rate

# Burn Rate アラートの例
# 短期間で急激にバジェットを消費 → 即座にアラート
- alert: SLO_HighBurnRate_Critical
  expr: |
    (
      error_rate_5m > (14.4 * 0.001)
      and
      error_rate_1h > (14.4 * 0.001)
    )
  for: 2m
  labels:
    severity: critical

# 長期間でじわじわ消費 → 警告レベル
- alert: SLO_HighBurnRate_Warning
  expr: |
    (
      error_rate_30m > (3 * 0.001)
      and
      error_rate_6h > (3 * 0.001)
    )
  for: 15m
  labels:
    severity: warning

アラートの分類

ランブック（Runbook）

// すべてのアラートにランブックを紐づける
interface AlertWithRunbook {
  alertName: string;
  severity: 'critical' | 'warning';
  runbookUrl: string;
  runbookContent: {
    description: string;      // アラートの意味
    impact: string;           // ユーザーへの影響
    diagnosis: string[];      // 原因調査の手順
    mitigation: string[];     // 暫定対応の手順
    escalation: string;       // エスカレーション先
  };
}

const exampleRunbook: AlertWithRunbook = {
  alertName: 'PaymentService_HighErrorRate',
  severity: 'critical',
  runbookUrl: 'https://wiki.example.com/runbook/payment-error',
  runbookContent: {
    description: 'Payment Serviceのエラー率が5%を超えています',
    impact: '一部のユーザーが決済を完了できません',
    diagnosis: [
      '1. Grafanaダッシュボードでエラーの種類を確認',
      '2. 外部決済APIのステータスページを確認',
      '3. 直近のデプロイ履歴を確認',
      '4. トレースで具体的なエラー箇所を特定',
    ],
    mitigation: [
      '1. 外部API障害の場合: フォールバック決済に切り替え',
      '2. デプロイ起因の場合: 前バージョンにロールバック',
      '3. 負荷起因の場合: スケールアウト',
    ],
    escalation: 'Payment Team Lead → CTO',
  },
};

アラート設計のアンチパターン

まとめ

チェックリスト

• アラート疲れの原因と対策を説明できる
• SLOベースのアラート設計を理解した
• Burn Rateアラートの考え方を把握した
• ランブックの必要性と構成を理解した

次のステップへ

次は演習「ダッシュボードを設計しよう」です。これまで学んだメトリクスとアラートの知識を使って、実際にダッシュボードを設計してみましょう。

推定読了時間: 25分