理論的なSLOから実践的なバーンレートアラートへの移行。ユーザー体験が実際に劣化している時だけオンコールエンジニアを呼び出します。
アラート疲労を排除するための取り組みの中で、多くのチームが閾値ベースのアラートには根本的な欠陥があることに気づきます。エラー率が2%に達した時にアラートを出しても、トラフィックが非常に少なくて2%が失敗した単一の合成プローブに相当する場合、統計的な異常のためにエンジニアをページングしてしまいます。
レガシーの閾値に代わる業界標準は、サービスレベル目標（SLO）ベースのアラートです。厳格なSLIを定義し、エラーバジェットを交渉し、バーンレートのみでアラートを出すことで、SREはユーザーが意味のある持続的な苦痛を受けている時だけページングされることを保証します。
エンジニアリングで克服するのが最も難しい心理的障壁の一つは、アプリケーションが100%の稼働時間を必要としないことを受け入れることです。100%の信頼性を追求すると、機能デプロイメントの速度が止まり、微小な問題で際限なくページングストームが発生します。
通常、99.9%（スリーナイン、月に約43分のダウンタイム）から99.99%の間の目標が理想的です。残りの0.1%があなたの エラーバジェット です。これは許容可能な不信頼性の許容量です。バジェット内であれば、デプロイメントは継続し、ページャーは沈黙したままです。消耗が速すぎると、ページャーが鳴って出血を止めます。
サービスレベル指標（SLI）は、ユーザー体験を表す厳密に定義された測定可能なメトリクスです。Google SREの本は、ほぼすべてのSLI計算を簡素化する汎用的な公式を定義しています：
Good Events / Total Events * 100
これをWeb APIに適用してみましょう：
10,000件のリクエストを受け取り、9,900件が高速かつ成功した場合、SLIは99%です。
静的閾値アラートを設定したとします：SLIが5分間のウィンドウで99%を下回ったら通知してください。
2つの障害モードに遭遇するでしょう：
データベースがハードクラッシュしてSLIが0%まで急落した場合、5分間のウィンドウは遅すぎます！停電開始から30秒でページングされる必要があり、5分も経ってからではありません。
遅いメモリリークによって一貫してリクエストの1.5%が失敗する場合、SLIは98.5%です。劇的に落ちることがないため、アラートは発火しません。しかし30日間、ユーザーは常にフラストレーションを経験し、月次エラーバジェットを密かに破壊しています。
これらの障害モードの解決策は バーンレートアラート です。絶対的な閾値をチェックする代わりに、月次エラーバジェットがどの速度で消耗されているかを計算します。
バーンレート1は、バジェットがちょうど30日で使い果たされることを意味します。
バーンレート14.4は、バジェットがちょうど2日で完全に使い果たされることを意味します。
高速と低速の両方の燃焼を捕捉するためにマルチウィンドウバーンレートアラートを設定します：
以下は99.9% SLOに対して1時間のウィンドウで高速燃焼アラート（レート14.4）のPromQLスニペットの例です。これらを手動で生成するのは複雑なため、SlothやPrometheus Operatorなどのツールが推奨されます。
sum(rate(http_requests_total{status=~"5.."}[1h]))
/
sum(rate(http_requests_total[1h]))
> (1 - 0.999) * 14.4これはあなたが気にしていることを正確にクエリします：月を乗り切るために許容されている障害許容量を速く消費しすぎていないか？
生の閾値からSLOバーンレートアラートへの移行は、監視文化の成熟が必要です。小さな問題は許容可能であるという現実を受け入れながら、実際のユーザーの痛みに直接比例した即時対応を保証します。
SLIを自信を持って構築するには、インフラストラクチャの真の限界を測定する必要があります。Heimdallのグローバル合成HTTPチェックとDNS異常プローブは完璧なトップオブファネルSLIメトリクスを生成し、HeimdallがSLO違反を報告する時にユーザーが実際に影響を受けていることを絶対的に確信できます。
可用性、インシデント対応、そしてユーザーが気づく前に問題を表面化させるモニタリングシステムの構築に焦点を当てた、シニアシステム信頼性エンジニア（SRE）。
