LESSON 30分

ストーリー

田
田中VPoE
異常検知の手法を学んだ。次は「アラート設計」だ。TaskFlow社の現状を教えよう。月間アラート発報数は約3,200件。そのうちオンコール担当者が実際に対応したのは約200件。つまり偽陽性率が約94%だ
あなた
94%のアラートがノイズだと、本当に重要なアラートも見逃しますよね
あ
田
田中VPoE
まさにその通りだ。これを「アラート疲れ（Alert Fatigue）」という。ノイズが多すぎるとオンコール担当者はアラートを無視するようになり、本当に深刻な障害でも対応が遅れる。アラートシステムへの信頼が崩壊した状態だ
あなた
どうすればノイズを減らせますか？
あ
田
田中VPoE
3つのアプローチだ。「アラートの体系的な設計」「ノイズフィルタリング」「継続的な改善サイクル」。個別のアラートをチューニングするだけでは限界がある。組織としてのアラート設計戦略が必要だ

アラート設計の原則

アラートの3分類

分類説明通知先応答時間
ページアラート（Page）即時の人的対応が必要PagerDuty → オンコール5分以内
チケットアラート（Ticket）次営業日までに対応Jira/Linear → チーム24時間以内
情報アラート（Inform）対応不要だが認識が必要Slack通知 → チャネル認識のみ

アラート設計の5原則

原則説明悪い例良い例
アクショナブルアラートを受けた人が対処行動を取れる「CPU使用率が高い」「Payment ServiceのCPUが90%超過。スケールアウトまたはリクエスト制限を検討」
症状ベース原因ではなく症状（ユーザー影響）でアラート「Pod再起動が発生」「エラーレートが0.5%を超過。ユーザーの5%がエラーを経験中」
重複排除同じ問題の複数アラートをグルーピング10台のPodそれぞれからアラート「サービスXのPod 10台中8台でメモリ不足」
適切な緊急度緊急度に応じた通知チャネル全てPagerDutyページページ/チケット/情報を使い分け
コンテキスト付与ランブック、ダッシュボードリンクを含む「エラー発生」のみエラー詳細 + ランブックURL + 関連ダッシュボードリンク

SLOベースのアラート設計

バーンレートアラートの実装

アラート名条件分類意味
Critical Burn1hバーンレート > 14.4 AND 5mバーンレート > 14.4ページ2時間でバジェット2%消費する速度
High Burn6hバーンレート > 6 AND 30mバーンレート > 6ページ5日でバジェット100%消費する速度
Medium Burn1dバーンレート > 3 AND 2hバーンレート > 3チケット10日でバジェット100%消費する速度
Low Burn3dバーンレート > 1 AND 6hバーンレート > 1情報月末までにバジェット枯渇の可能性

マルチウィンドウの重要性

なぜ2つのウィンドウを組み合わせるか:

長ウィンドウのみ:
  6hバーンレート > 6
  → 6時間前に1回の短いスパイクがあっただけでも発報
  → スパイクが既に収束していてもアラートが継続

短ウィンドウを追加:
  6hバーンレート > 6 AND 30mバーンレート > 6
  → 「過去6時間で高バーンレートがあり」かつ「直近30分でも継続中」
  → 既に収束した問題では発報しない
  → 精度（Precision）が大幅に向上

ノイズ削減の手法

手法1: アラートの階層化とグルーピング

手法説明効果
サービスグルーピング同一サービスの複数アラートを1つに集約アラート数60-70%削減
依存関係フィルタ下流障害が原因の上流アラートを抑制連鎖アラートの排除
集約ウィンドウ5分以内の同一アラートを1件に集約フラッピング対策
依存関係フィルタの例:

DB障害が発生した場合:
  ✗ 設計前:
    アラート1: DB接続エラー
    アラート2: Task Service 500エラー増加
    アラート3: API Gateway エラーレート上昇
    アラート4: ジャーニーSLO「タスク作成」違反
    → 4件のアラートがオンコールに飛ぶ

  ○ 設計後:
    アラート1: DB接続エラー（根本原因）
    アラート2-4: 「DB障害による派生影響」として抑制
    → 1件のアラート + コンテキスト情報

手法2: アラートの品質管理

指標計算式目標現状（TaskFlow）
偽陽性率ノイズアラート / 全アラート< 20%94%
アクション率対応が必要だったアラート / 全アラート> 80%6%
ページ精度真のページ / 全ページ> 90%不明
MTTA（応答時間）アラート発報から確認までの時間< 5分15分
カバレッジアラートで検知したインシデント / 全インシデント> 90%69%（31%は顧客報告）

手法3: 動的閾値の導入

手法適用対象説明
時間帯別閾値トラフィック系平日昼間と深夜で異なる閾値を設定
曜日別閾値ビジネスメトリクス平日と週末で基準を変更
デプロイ後抑制デプロイ直後デプロイ後15分間は一部アラートの感度を下げる
メンテナンスウィンドウ計画メンテナンスメンテナンス中はアラートをミュート

アラートのランブック設計

ランブックの標準テンプレート

セクション内容
アラート概要このアラートが意味すること、ユーザーへの影響
確認手順真の問題かノイズかを切り分ける手順
緩和手順即座に影響を緩和する手順（スケールアウト、ロールバック等）
根本対応根本原因の調査と恒久対策の手順
エスカレーションいつ、誰にエスカレーションすべきかの基準
関連リンクダッシュボード、ログクエリ、アーキテクチャ図

ランブック例: Payment Service エラーレート上昇

アラート: Payment Service エラーレート上昇
重大度: ページ（Tier 1サービス）
SLO: 可用性 99.95%
バーンレート: Critical（> 14.4）

■ 確認手順:
  1. Payment Service ダッシュボード確認
     → [リンク]
  2. エラーの種類を確認
     → 外部ゲートウェイタイムアウト? → 手順A
     → DB接続エラー? → 手順B
     → アプリケーションエラー? → 手順C

■ 手順A: 外部ゲートウェイタイムアウト
  1. 外部ゲートウェイのステータスページ確認
  2. タイムアウト設定の一時的引き上げ（30s→60s）
  3. サーキットブレーカーの状態確認
  4. 改善しない場合: フォールバック処理の有効化

■ エスカレーション:
  - 15分以内に改善しない場合: SREリードに連絡
  - 30分以上継続する場合: VPoEに報告

組織レベルのアラート改善サイクル

アラートレビューの定期実施

レビュー頻度内容
週次ノイズレビュー毎週先週のノイズアラートTOP5を特定し、チューニング
月次アラート品質レポート月次偽陽性率、アクション率、MTTA、カバレッジの測定
四半期アラート棚卸し四半期全アラートの棚卸し。未使用・低品質アラートの削除

アラート改善の目標（TaskFlow社）

指標現状3ヶ月目標6ヶ月目標12ヶ月目標
月間アラート数3,2001,500800500
偽陽性率94%50%25%15%
アクション率6%50%75%85%
顧客報告率31%20%10%5%
MTTA15分10分5分3分

「最高のアラートシステムとは、少ないアラートで高い検知率を実現するものだ。1日100件のアラートより、1日5件のアラートの方がはるかに価値がある — ただし、その5件で本当に重要な問題を漏れなく捉えている場合に限る」 — 田中VPoE

まとめ

ポイント内容
アラート3分類ページ（即時対応）、チケット（計画対応）、情報（認識のみ）を使い分ける
SLOベースバーンレートアラートとマルチウィンドウで精度の高い検知を実現
ノイズ削減グルーピング、依存関係フィルタ、動的閾値で偽陽性を大幅削減
継続的改善アラート品質指標を定期的に測定し、組織的に改善サイクルを回す

チェックリスト

  • アラートの3分類（ページ/チケット/情報）の使い分けを理解した
  • バーンレートアラートとマルチウィンドウの仕組みを理解した
  • ノイズ削減の3手法（グルーピング、品質管理、動的閾値）を理解した
  • ランブック設計と継続的改善サイクルを理解した

次のステップへ

次は「AIOpsの活用」を学びます。異常検知とアラート設計をさらに発展させ、AIと機械学習を活用した高度な運用自動化を組織レベルで実現する手法を身につけましょう。

推定読了時間: 30分