アラート設計 あらーとせっけい
アラート監視設計アラート疲れSLOオンコールインシデント
アラート設計について教えて
簡単に言うとこんな感じ！
「何かあったら通知する」だけじゃなくて、「本当に人が見るべきものだけ通知する」ように作るのがアラート設計だよ。アラートが多すぎると「アラート疲れ」で本物の障害を見逃す事故につながるから、質と優先度の設計がすごく重要なんだ。
アラート設計とは
アラート設計とは、監視システムで「いつ・誰に・何を通知するか」を定義するプロセスです。単に閾値を設定するだけでなく、アクショナブル（担当者が即座に対応できる内容か）かどうかを重視します。
最大の敵はアラート疲れ（Alert Fatigue）です。重要度の低いアラートが大量に届き続けると、担当者は通知を無視するようになり、深刻な障害のアラートを見落とすリスクが高まります。Googleのサイトリライアビリティエンジニアリング（SRE）では「すべてのアラートはオンコール担当者が実際にアクションを取る必要があるものでなければならない」と定義しています。
良いアラート設計の原則は「症状ベースのアラート（Symptom-based alerting）」です。CPU使用率90%という内部指標より、「ユーザーが感じるエラー率が1%を超えた」という症状にアラートを張るほうが本質的です。原因の数は無数にありますが、症状は限られているためです。
アラート設計の原則
| 原則 | 説明 |
|---|---|
| アクショナブル | 受け取った人が即座に対応できる内容のみ通知 |
| 症状ベース | ユーザー影響（エラー率・遅延）でアラートを張る |
| 誤検知を最小化 | 閾値・ウィンドウを調整してノイズを減らす |
| 優先度分け | P1（即時対応）・P2（数時間以内）・P3（翌営業日）を明確に |
| エスカレーション | 一定時間未対応なら自動でエスカレート |
| 自己完結した通知 | 通知だけで「何が・どこで・なぜ」が分かるようにする |
| 定期的な見直し | 不要なアラートは削除または調整 |
アラートレベルの例
| レベル | 条件例 | 通知先 | 対応時限 |
|---|---|---|---|
| Critical（P1） | エラー率 > 5% が5分継続 | オンコール担当者（電話） | 15分以内 |
| Warning（P2） | エラー率 > 1% が15分継続 | チームSlack | 2時間以内 |
| Info（P3） | CPU > 80% が30分継続 | チームSlack | 翌営業日 |
歴史と背景
- 2000年代：Nagios・Zabbixによる閾値ベースアラートが主流。誤検知が多かった
- 2016年：Google SRE本の出版でアラート設計のベストプラクティスが普及
- 2018年ごろ：SLOベースのアラート（エラーバジェット燃焼率） が注目を集める
- 2020年代：AIOps（AI運用）による自動異常検知がアラートノイズ削減に活用される
SLOベースアラートのイメージ
関連用語
- SLI・SLO・エラーバジェット — アラートのトリガーとなるSLOの定義
- メトリクス・カスタムメトリクス — アラートの判断に使うデータソース
- ダッシュボード — アラート状況を俯瞰する可視化ツール
- CloudWatch・Azure Monitor・Cloud Monitoring — アラートを設定するクラウド監視サービス
- SOC — アラートを受信して対応するチーム