Fictional teardown 02 / Monitoring
通知数は多いが、顧客影響と初動判断が結び付かない監視構成。
月3,000件の通知が発生する架空Webサービス。CPU・ディスク閾値はある一方、SLI/SLO、通知所有者、Runbook、サイレンス期限が揃っていない前提です。
架空構成／実在顧客の事例ではありませんDecision
最初に何を決めるか
ツール刷新や通知件数削減より先に、利用者影響・エラーバジェット消費・実行可能な初動の3条件で、人を起こす通知を定義します。
優先
SLI/SLOに接続しないページング
部品閾値だけでなく、成功率・待ち時間・主要導線の可用性を候補化。即時対応で利用者影響を変えられる事象だけをページング対象にします。
優先
複数時間窓バーンレートの不在
短い急激な劣化と長い緩慢な劣化を分け、短時間窓と長時間窓の組合せでエラーバジェット消費を判断します。
要確認
所有者・Runbook・サイレンス期限
通知名から責任チーム、確認順序、切り分け、エスカレーション先へ到達できる状態にし、抑止には理由・所有者・失効日時を必須化します。
維持
変更イベントの相関表示
デプロイや設定変更との相関確認に有効なため維持し、通知の重複抑止と親子関係を追加確認します。
30-day direction
次の30日で行うこと。
非保証
通知件数、障害件数、復旧時間の削減を保証しません。実際のSLOは事業影響、許容損失、運用体制を踏まえて合意が必要です。