SLO導入でアラートノイズが減る理由 — SREの監視設計

「アラートが多すぎて誰も見なくなった」。SREの相談で、いちばんよく聞く症状です。原因はだいたい監視ツールではなく、設計の出発点にあります。SLO（Service Level Objective）を入れると、アラートの本数は意図せず減ります。仕組みを整理します。

アラートが鳴りすぎる本当の理由

アラートが多すぎる現場には、共通点があります。何を守るかが決まっていないまま、ツールを入れていること。CPU使用率、メモリ、ディスク残量、エラー件数、レスポンスタイム——監視ツールが出してくれる指標を全部見ようとして、しきい値を勘で設定する。これだと、業務に関係ない数字でも鳴ります。

すると、対応する人は「またか」と思って慣れていきます。本当の障害が起きたとき、見逃します。アラートの数を減らすことは、業務的にも安全に直結する設計判断です。

SLI / SLO / エラーバジェットの関係

SREの基本は、Google が広めた3つの概念から始まります。SLI（測れる指標）、SLO（達成したい目標）、エラーバジェット（許容できるエラー量）。これを順番に決めると、アラートの設計が自然と引き出されます。

SLOベースのアラート設計

具体的には burn rate アラート を使います。「エラーバジェットをこのペースで使うと、SLO期間内に使い切ってしまう」状態だけアラートを鳴らす設計です。瞬間的なエラー増は無視し、継続的に問題があるときだけ通知が来ます。

この設計に切り替えると、しきい値ベースで100本鳴っていたアラートが10本以下になる、ということが普通に起きます。鳴ったときは本当に業務影響があるので、対応する側の集中度が上がります。

何を守るかを先に決める

SLOを決めるためには、「何を守るか」を業務側と合意する必要があります。Webサイトなら「ログインができること」「商品検索が3秒以内」「注文確定が成功すること」、API なら「主要エンドポイントの応答が500以内」など。

守りたいものはサービスによって違うので、テンプレートをコピーするだけでは決まりません。「これが守れていれば、お客様は使えている」 と業務側が判断できる指標を、対話で決めます。私たちが入る案件では、エンジニアと業務担当の合同ワークショップから始めることが多いです。

運用に乗せるまで

SLO設計の難しさは、初期設計ではなく定着フェーズにあります。SLOは固定ではなく、運用しながら見直し続けるものです。最初に決めた数字が厳しすぎると現場が疲れ、緩すぎると意味がない。月次か四半期ごとに SLOレビュー を開き、達成状況とビジネス要求を照らして調整します。

このレビューが回り出すと、運用の議論が「アラート対応」から「サービスをどう良くするか」に変わります。これがSREを入れる本当の効果です。