こんにちは！日々のシステムの安定稼働のために、夜中も休日のアラート対応も頑張っているあなたへ。
「またこの夜間アラートか……原因を調べたら、大したことのない一時的なスパイクだった……」
そんな、エンジニアの魂をすり減らす「アラート疲れ」に悩まされていませんか？
かつての私もそうでした。CPU使用率が80%を超えたら発砲、エラーログが5件出たら深夜に召喚。そんな「静的しきい値」の亡霊のような監視に怯える日々と、今日で終わりにしましょう。
今回は、世界中のモダンなSREたちが実践している「Datadog SLOとバーンレート（Burn Rate）アラートを用いた、誤検知撲滅の数学的アプローチ」を、初心者の方にもすんなり腑に落ちるように優しく、しかし本質を突いて解説します。
これをマスターすれば、あなたのチームのPagerDutyが鳴り響く回数は劇的に減り、本当に対応すべき「ユーザー体験を損なう障害」にだけ集中できるようになりますよ。さあ、一緒に扉を開けましょう！
—
1. 従来の静的しきい値アラートの限界と、SLOの真実
「CPU 80%」が教えてくれないこと
まずは、私たちが今までやってきた監視（静的しきい値）の何がダメだったのかを振り返りましょう。
- 「CPU使用率が90%を超えたらアラート」
- 「HTTP 5xxエラーが1分間に10件超えたらアラート」
一見、正しそうに見えますよね。しかし、これには致命的な欠陥が2つあります。
1. ユーザーにとってどうでもいいノイズで起こされる： 夜中にCPUが90%に跳ね上がっても、バックグラウンドのバッチ処理が元気に動いているだけなら、ユーザーは何の不利益も被っていません。
2. 本当にやばい障害を見落とす： しきい値を「5件」にしていたら、大規模なトラフィックの裏で「ひっそりと決済APIの半数が失敗している」というクリティカルな状況をスルーしてしまうかもしれません。
ユーザーの痛みに寄り添う「SLO（サービスレベル目標）」
ここで登場するのが SLO（Service Level Objective） です。
SLOは、「ユーザーにとってサービスがどれくらい正常に使えてほしいか」を数字で定めた約束事です。
例えば、「今月、すべてのリクエストのうち、99.9%はエラーなく（または正常なレイテンシで）処理できなければならない」と定めたとします。
この時、許容される「エラーの失敗分（0.1%）」のことをエラーバジェット（Error Budget：許容不全予算）と呼びます。
アラートを鳴らすべき本当の瞬間とは、「CPUが高い時」ではなく、「この大切なエラーバジェットが、通常ではあり得ないスピードで猛烈に削り取られている時」なのです。
—
2. 開発チームを救う「マルチウィンドウ・マルチバーンレート」の数学
では、エラーバジェットがどれくらいのスピードで消えたらアラートを出すべきでしょうか？ ここで「バーンレート（Burn Rate）」という概念を使います。
バーンレートとは？
バーンレートとは、「エラーバジェットが何倍の速さで消費されているか」を示す指標です。
- バーンレート = 1: SLOのペースぴったりでバジェットが消費されている（30日間の期限ぴったりに予算を使い果たすペース）。まったく焦る必要はありません。
- バーンレート = 14.4: 恐ろしいスピードです。このペースが続くと、なんとたったの5時間で1ヶ月分のエラーバジェットが完全に消滅します。即座に対応が必要です。
鉄板の「マルチウィンドウ・マルチバーンレート」戦略
GoogleのSRE本でも推奨されている、誤検知をゼロにしつつ見逃しを防ぐ黄金律があります。それが「長短2つの時間窓（Window）」を組み合わせる方法です。
- 1時間窓（速報）： バーンレートが大きい（例: 14.4）場合、「5%のエラーバジェットがわずか1時間で消えそうになっているか？」を監視します。大きな障害が発生した瞬間に数分で検知できます。
- 6時間窓（確報）： バーンレートが中程度（例: 6）の場合、「2%のエラーバジェットが6時間かけてじわじわ削られていないか？」を監視します。一時的なネットワークの揺らぎなどのノイズを完全に無視し、本当のプチ障害だけを捉えます。
> 💡 先輩からのアドバイス：
> 「1時間でエラーバジェットの14%を消費するペース（バーンレート 14.4）」をトリガーに据えると、人間の睡眠を邪魔するような無駄なアラートを劇的に減らしながら、致命傷を防ぐ絶妙なバランスが取れます。
—
3. Datadogでの具体的なSLO・アラート構築手順
お待たせしました！ここからが実践パートです。Datadogを使って、この理論を具現化してみましょう。
Datadogの優れたところは、面倒な計算を裏側でやってくれて、数クリックとシンプルなクエリで美しいSLO監視が作れる点です。
Step 1: DatadogでSLO（サービスレベル目標）を作成する
まずは基準となるSLOを定義します。
1. Datadogのメニューから [Service Level Objectives] を開きます。
2. [+ New SLO] をクリックします。
3. Metric-based（メトリクスベース） を選択します（APMのサービスやカスタムメトリクスを使っている場合、最も安定します）。
4. 以下のように設定します：
- Target（目標値）: `99.9` % （30日間のローリングウィンドウ）
- Numerator（分子 / 成功数）: 成功したリクエストのメトリクス
- Denominator（分母 / 総数）: すべてのリクエストのメトリクス
これで、あなたのサービスの「お財布（エラーバジェット）」がDatadog上に生まれました！
Step 2: 誤検知ゼロのバーンレートアラートを設定する
次に、先ほど解説した「マルチバーンレート」のアラートを構築します。DatadogのSLOアラート機能を使うと、これが非常に簡単に行えます。
1. 作成したSLOの詳細画面から、[Alerts] タブを開きます。
2. [+ New Alert] をクリックします。
3. アラート条件として、Google SREスタイルのプリセットである「Burn Rate（バーンレート）」を選択します。
設定画面で以下のようにパラメータを調整します（これが一番ノイズの少ない鉄板設定です）：
- クリティカルアラート（即座に対応すべき大規模障害）:
- 条件: 過去 1 時間 のバーンレートが 14.4 を超過
- 意味: 1ヶ月分のバジェットの5%以上が1時間で消えるとき。
- 警告アラート（日中に原因調査すべきプチ障害）:
- 条件: 過去 6 時間 のバーンレートが 6 を超過
- 意味: じわじわとバジェットを削っている根深いバグがあるとき。
実際の通知メッセージの書き方（超重要）
アラートの通知（SlackやPagerDuty）が飛んできた時、エンジニアがパニックにならないために、メッセージテンプレートには必ず「今、何が起きているのか（文脈）」を添えてあげましょう。
🚨 【SLOアラート: バーンレート高騰】
サービス名: {{service.name}}
SLO名: {{slo.name}}
【状況】
現在、エラーバジェットが通常の約14倍の速度で急激に消費されています！
このままでは、約5時間後に今月のバジェットが底をつきます。
【次にとるべきアクション】
1. 下記のダッシュボードを開き、直近のエラーログやレイテンシのスパイクを確認してください。
👉 {{slo.url}}
2. デプロイ直後であれば、ロールバックを検討してください。
3. 外部依存API（DBやS3など）の障害がないかステータスを確認してください。
親切な通知メッセージは、夜中に起きたエンジニアの心を救います。「CPU 90%」とだけ言われるより、何倍も建設的に動けますよね。
—
4. 精度高い「HelloWorld」的動作確認（テスト方法）
「設定はできたけれど、本当にちゃんとアラートが飛ぶか不安……」
本番環境に適用する前に、正しく検知されるかテスト（火入れ）をしてみましょう。これができれば完璧です。
テスト用スクリプトで意図的にエラーを発生させる
テスト用の簡単なPythonスクリプト（またはお好みの言語）を使い、一時的にエラーレスポンスを故意に大量発生させてみます。
import time
import requests
あなたのサービスのテスト用エンドポイント（またはステージング環境）
URL = “https://staging.your-service.example.com/api/v1/health”
print(“🔥 バーンレートテスト用のエラー負荷を送信します…”)
短時間で集中的にエラーを発生させ、バーンレートを跳ね上げる
for i in range(100):
try:
# あえて存在しないパスを叩いて404/5xxを発生させるなど、
# 分母と分子（エラーカウント）に影響を与えるリクエストを送る
response = requests.get(f”{URL}/force-error-test”)
print(f”Request {i}: Status {response.status_code}”)
except Exception as e:
print(f”Request {i}: Error {e}”)
time.sleep(0.1) # 0.1秒間隔で高速リクエスト
print(“✨ テスト負荷の送信が完了しました。DatadogのSLO画面を確認してください！”)
動作確認のチェックポイント
1. DatadogのSLO画面を見る： エラーバジェットのグラフ（燃えカスのように減っていくグラフ）が、ガクッと下がっていることを確認します。
2. アラートの状態を見る： 設定した「1時間窓のバーンレート」が閾値を超え、Datadog上で `Alert` ステータスに変わるのを確認します。
3. 通知の確認： Slackなどの連携先に、先ほど設定したメッセージが綺麗に飛んできたら大成功です！
テストが終わったら、エラーを止めてバジェットが回復（または安定）するのを待ちましょう。
—
まとめ：もう夜中に無駄なアラートで悩まないために
お疲れ様でした！ここまで読み進めたあなたは、単なる「ツールをポチポチ設定する人」から、システムの信頼性を数学的にデザインする「オブザーバビリティ・アーキテクト」への一歩を踏み出しました。
- 静的しきい値（CPU 80%など）の監視はもう卒業する。
- ユーザー体験に直結する「エラーバジェット」を監視の中心に据える。
- 「マルチウィンドウ・マルチバーンレート」で、ノイズを完全に消し去りながら致命傷だけを確実に捉える。
この設計を取り入れるだけで、あなたのチームの心理的安全性は劇的に向上します。無駄なアラートに起こされる夜はもう終わりです。明日からの監視設計に、ぜひこのアプローチを取り入れてみてくださいね。
あなたのプロダクトが、ユーザーにとっても、そして何よりあなた自身にとっても、健全で穏やかなものでありますように。それでは、また次の技術の深淵でお会いしましょう！