炎上しないオブザーバビリティの極意：Datadog SLOバーンレートアラートの数学的完全調律
夜中の3時に鳴り響く、意味のない「CPU使用率80%超え」のアラートでエンジニアを叩き起こす時代は終わった。
真にモダンなSRE組織において、監視とは「システムの健康状態をデータで語る行為」であり、アラートとは「ユーザー体験が破壊されつつある瞬間にのみ、人間を動かす最終防衛線」であるべきだ。
Google SRE本が提唱して以来、SLO（サービスレベル目標）とエラーバジェット（Error Budget）の概念は浸透したものの、現場では依然として「とりあえずエラーレートが1%を超えたらPagerDutyを鳴らす」という原始的な静的しきい値アラートが跋扈し、アラート疲弊（Alert Fatigue）によるバーンアウトが後を絶たない。
本稿では、DatadogのSLO機能とマルチウィンドウ・マルチバーンレート（Multi-window, Multi-burn-rate）アラートを組み合わせ、「偽陽性（誤検知）をゼロにしつつ、真の障害のみを最速で検知する」ための数学的アプローチと、それをDatadog上で極限まで自動化・最適化する実践知を叩き込む。
—
1. 従来の静的しきい値の死と、マルチバーンレートの数学的必然
悪しき「静的しきい値」の構造的欠陥
「HTTP 5xxエラー率が5分間平均で1%を超えたらアラート」という設計を考えてみよう。
- トラフィックが少ない深夜帯：ごく少数のリクエスト失敗で簡単に1%を超え、無駄な深夜コールが発生する（偽陽性）。
- 巨大なトラフィックがあるピークタイム：1%のエラーは数千人のユーザーに影響を与えているにもかかわらず、全体母数が大きいために平均値が薄まり、アラートの閾値に届かない（偽陰性）。
システムの規模やトラフィックの変動を無視した静的しきい値は、数学的に破綻している。
バーンレート（Burn Rate）とは何か
バーンレートとは、「設定されたエラーバジェットをどのくらいの速度で消費しているか」を示す指標である。
SLOが `99.9%`（30日間で許容されるダウンタイム / エラーバジェットは `0.1%`）であるシステムを考える。
もしエラーバジェットのすべてを正確に 30日間 かけて使い果たした場合のバーンレートを `1` とする。
- バーンレート = `1`：30日かけてバジェットが枯渇する。
- バーンレート = `14.3`：わずか 50時間（約2日） でバジェットが枯渇する計算になる。
Google SREが推奨するマルチウィンドウ・マルチバーンレート戦略の核心は、「短期間の急激なバジェット消費」と「長期間のじわじわとしたバジェット消費」の両方を監視することにある。
—
2. 開発チームを救う：バジェット枯渇計算とアラートマトリクス
では、どのくらいのバーンレートで、どの程度のウィンドウ（時間幅）を取れば、誤検知なく重大障害を捉えられるのか。以下のマトリクスが現場の黄金律となる。
| 深刻度 / アクション | バジェット消費率 (1時間) | バジェット消費率 (6時間) | バーンレート | 許容される見逃し時間 | 発生するシナリオ |
| :— | :— | :— | :— | :— | :— |
| P1 (緊急・即時対応) | 2% | 5% | 14.3 | ~50分で枯渇 | 全面停止、DBコネクション枯渇 |
| P2 (準緊急・翌営業日) | 1% | 10% | 6.0 | ~5時間で枯渇 | 一部の依存サービス障害、高レイテンシ |
数学的アプローチ：なぜ「1時間で14%」なのか？
Google SREワークブックに基づき、エラーバジェットの2%を1時間で消費するシナリオ（バーンレート 14.3）を設計する。
- ウィンドウ1（短時間・高感度）：5分間
- 目的：瞬発的な大規模障害を即座に検知する。
- 検出感度：バジェットの 5% を消費する速度。
- ウィンドウ2（長時間・低感度）：1時間
- 目的：じわじわと進行するメモリリークや、特定のエンドポイントの連鎖的失敗を、偽陽性を排除して捉える。
- 検出感度：バジェットの 10% を消費する速度。
この「短窓（Quick Window）と長窓（Long Window）のAND条件（または複合条件）」をDatadogに実装することで、瞬間的なスパイクによる誤検知を完全に排除しつつ、確実なバジェット侵食を検知できる。
—
3. Datadogにおける高度なSLOアラート構築とチューニングの極意
DatadogのUIからポチポチと設定するフェーズは卒業しよう。大規模なマイクロサービス群を運用する場合、SLOの定義やアラートはすべてコード（TerraformやDatadog API）で管理されるべきだ。
ここでは、Datadog API / Terraformを用いた、最も堅牢なSLOモニターの構築手法を解説する。
Terraformによる完全自動構成コード
以下のTerraformコードは、前述の数学的モデルに基づいたマルチバーンレート（1時間でバジェットの14%消費を検知）をコード化したものである。
resource “datadog_service_level_objective” “api_availability” {
name {
type = “metric”
numerator = “sum:trace.http.request.hits{env:production,service:core-api,status:2xx}.as_count()”
denominator = “sum:trace.http.request.hits{env:production,service:core-api}.as_count()”
}
thresholds {
timeframe = “30d”
target = 99.9 # SLO 99.9%
warning = 99.95 # 早期警戒ライン
critical = 99.9
}
tags = [“team:core-sre”, “service:core-api”, “tier:1”]
}
resource “datadog_monitor” “slo_burn_rate_alert” {
name = “[P1] SLO Burn Rate High: core-api Availability”
type = “service level objective”
message = <
直ちにダッシュボードを確認し、インシデント対応を開始してください。
{{/is_alert}}
EOT
# DatadogのSLOバーンレート監視構文
# 5分の短窓 と 1時間の長窓 の両方で閾値を超えた場合のみ発火
query = “error_budget(\”${datadog_service_level_objective.api_availability.id}\”).burn_rate(‘hour’, 1) > 14.3 AND error_budget(\”${datadog_service_level_objective.api_availability.id}\”).burn_rate(‘minute’, 5) > 14.3″
monitor_thresholds {
critical = 14.3
}
options {
evaluation_delay = 900 # メトリクスの遅延（15分）を考慮
new_group_delay = 60
no_data_timeframe = 2880
notify_no_data = false
renotify_interval = 60
include_tags = true
enable_samples = true
}
}
チューニングの極意：`evaluation_delay` の最適化
分散トレーシングやメトリクス収集において、ネットワーク遅延やバッチ処理のフラッシュ間隔により、データがDatadogに届くまでには必ずタイムラグ（Ingestion Lag）が存在する。
もしこのラグを考慮せずにアラート評価を行うと、「データが届いていない＝エラーが無い」と誤認され、データ到着後に一斉にアラートが評価されて誤作動（または遅延発火）を起こす。
`evaluation_delay = 900`（15分）を設定し、直近15分間の未着データによる計算揺らぎを完全にシャットアウトするのが、エキスパートの常道である。
—
4. 低レイヤ＆エキスパートハック：APIを用いたSLO自動生成パイプライン
数百のマイクロサービスを抱える組織で、手動でSLOを設定・管理することは不可能である。CI/CDパイプラインに組み込み、サービスのデプロイ時に自動的にDatadog SLOを同期・検証するPythonスクリプトの核心部分を公開する。
このスクリプトは、サービスのOpenTelemetryメトリクスから自動的に命名規則に則ったSLOをDatadogへ登録する。
import os
from datadog_api_client import ApiClient, Configuration
from datadog_api_client.v1.api.service_level_objectives_api import ServiceLevelObjectivesApi
from datadog_api_client.v1.model.service_level_objective_request import ServiceLevelObjectiveRequest
from datadog_api_client.v1.model.slo_type import SLOType
from datadog_api_client.v1.model.slo_target import SLOTarget
from datadog_api_client.v1.model.slo_threshold_timeframe import SLOThresholdTimeframe
configuration = Configuration()
configuration.api_key[“apiKeyAuth”] = os.environ[“DD_CLIENT_API_KEY”]
configuration.api_key[“appKeyAuth”] = os.environ[“DD_CLIENT_APP_KEY”]
def create_or_update_slo(service_name: str, numerator_query: string, denominator_query: string):
with ApiClient(configuration) as api_client:
api_instance = ServiceLevelObjectivesApi(api_client)
body = ServiceLevelObjectiveRequest(
name=f”{service_name} Availability SLO”,
type=SLOType.METRIC,
description=f”Automated SLO for {service_name} generated by CI/CD pipeline”,
target=[
SLOTarget(
target=99.9,
timeframe=SLOThresholdTimeframe.THIRTY_DAYS,
warning=99.95
)
],
query={
“numerator”: numerator_query,
“denominator”: denominator_query
},
tags=[f”service:{service_name}”, “managed_by:terraform_or_api”]
)
try:
response = api_instance.create_slo(body=body)
print(f”Successfully created SLO for {service_name}: {response.data[0].id}”)
except Exception as e:
print(f”Exception when calling ServiceLevelObjectivesApi->create_slo: {e}”)
if __name__ == “__main__”:
# 例: サービスメッシュからのメトリクスを自動マッピング
svc = “payment-service”
num = f”sum:trace.http.request.hits{{env:production,service:{svc},status:2xx}}.as_count()”
den = f”sum:trace.http.request.hits{{env:production,service:{svc}}}.as_count()”
create_or_update_slo(svc, num, den)
—
5. 結び：監視から「文脈のオブザーバビリティ」へ
静的しきい値の呪縛から逃れ、マルチバーンレートによるSLOアラートを導入した組織は、劇的な変化を経験する。
「夜中に叩き起こされてログの海を彷徨う苦痛」から解放され、「エラーバジェットがどれだけ残っているか」という共通の言語で、開発チームとSREがプロダクトの信頼性と機能開発のトレードオフを冷静に議論できるようになる。
真のオブザーバビリティとは、ツールを入れることではない。
データから「ノイズ」を極限まで削ぎ落とし、人間の認知負荷を最適化することそのものなのだ。今夜から、その場しのぎのCPUアラートをすべて消し去り、数学に裏打ちされたバーンレート監視への移行を始めよ。