『アラート疲労』を回避するための設計
アラートは多すぎても少なすぎても問題で、SLO ベースの設計が現代の標準です。本記事では編集部の視点で、アラート運用を公開情報をもとに整理します。Observability 実践 もご参考に。
SLO の基本
(1) SLI (Service Level Indicator)：可用性/レイテンシ等の指標。(2) SLO (Objective)：目標値(99.9%等)。(3) SLA (Agreement)：顧客との契約。(4) エラーバジェット：SLO 違反の許容量。(5) 例：99.9% SLO = 月43分のダウンタイム許容。
アラートの3レベル
(1) P0 (critical)：即時対応必須・PagerDuty 起こす。(2) P1 (high)：1時間以内対応・Slack 等。(3) P2 (medium)：翌営業日対応。(4) info：参考情報・ダッシュボードで確認。(5) 明確な分類：誤検知防止。
エラーバジェット運用
(1) 残バジェット計測：月単位/週単位。(2) バジェット燃焼率：burn rate アラート。(3) バジェット切れ時：新機能停止・信頼性投資。(4) バジェット余り時：許容リスク内で投資。(5) SRE と PM の対話の基準。
通知の運用
(1) PagerDuty：オンコール管理の標準。(2) Slack 統合：チームへの即時共有。(3) ロテーション：週次の当番。(4) エスカレーション：応答なしで上位へ。(5) runbook リンク：対応手順を即参照。Prometheus+Grafana 実践 もご参考に。
アラートの質を保つ
(1) 誤検知率の計測：トリアージで分類。(2) 定期見直し：四半期に1回。(3) アラート削減：価値の低いものは削除。(4) ノイズフィルタ：相関するアラートをグループ化。(5) ポストモーテムでの改善。分散トレーシング も合わせて。
オンコール運用
(1) 1週間ローテが一般的。(2) 1次対応 + 2次バックアップ。(3) 休日/夜間の対応：手当の設計。(4) バーンアウト防止：負荷分散。(5) 引継ぎミーティング。燃え尽き予防 も合わせて。
失敗しがちなパターン
(1) アラート量多すぎ：オンコール疲弊。(2) 誤検知放置：信頼喪失。(3) runbook なし：対応時間長期化。(4) SLO 未定義：閾値の根拠なし。(5) P0/P1 区別曖昧。対策は、(1)定期削減、(2)誤検知優先で改善、(3)必須化、(4)SLO 制定、(5)分類基準明示、です。