SLOは「守るための盾」ではない。「攻めるためのアクセル」だ。
オブザーバビリティの頂点を目指す諸君。DatadogのSLOダッシュボードを眺めて満足しているなら、それはまだ「監視」の域を出ていない。
SLO（Service Level Objectives）は、単なる可用性のレポートではない。「どの程度のリスクを取れば、開発速度を最大化できるか」という、プロダクトの生存戦略そのものだ。エラーバジェット（Error Budget）を枯渇させないように縮こまるのではなく、予算の範囲内でどれだけ大胆に攻められるか。その境界線を描くのが、真のSREの仕事だ。
今日は、DatadogのSLO機能を単なるGUI操作の範疇を超え、コードとして管理し、パイプラインに直結させる「エンジニアのための運用極致」を伝授する。
—
1. SLOの定義：メトリクスの海で「何」を測るべきか
多くのチームが陥る罠は、CPU使用率やメモリ使用量といった「システム寄りのメトリクス」をSLOにすることだ。ユーザーはCPUが80%であることなど気にしない。彼らが気にするのは「リクエストが完了するか否か」だ。
究極のSLI選定基準
- Availability（可用性）: 5xxエラー率ではなく、正常なレスポンスの割合。
- Latency（遅延）: 平均値で測るな。P95、P99のヒストグラムを用い、閾値を超えたリクエストの割合を追え。
- Correctness（正確性）: データベースの整合性や、キャッシュのミス率。
—
2. APIによるSLOの「コード化」：GUIからの脱却
運用が成熟するほど、SLO設定はTerraformやAPI経由で管理すべきだ。GUIでポチポチ設定した設定は、誰がいつ変えたか追えない「ブラックボックス」と化す。
以下のPythonスクリプトは、Datadog APIを叩き、環境ごとのSLOを自動構築するテンプレートだ。これをCI/CDパイプラインに組み込み、サービスのデプロイと同時にSLOが定義される状態を目指せ。
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
APIキーを環境変数で管理するのは基本中の基本
config = Configuration()
config.api_key[“apiKeyAuth”] = os.environ[“DD_API_KEY”]
config.api_key[“appKeyAuth”] = os.environ[“DD_APP_KEY”]
def create_slo(name, query, threshold):
with ApiClient(config) as api_client:
api = ServiceLevelObjectivesApi(api_client)
slo = ServiceLevelObjectiveRequest(
name=name,
type=”metric”,
thresholds=[{“timeframe”: “7d”, “target”: threshold}],
query=query, # ここにDatadogのクエリを直書きする
tags=[“team:core-platform”, “managed-by:terraform-or-api”]
)
return api.create_slo(body=slo)
実行例: P99レイテンシSLOを99.9%で設定
create_slo(“API P99 Latency SLO”, “sum:trace.http.request.duration{service:api}.as_count() / sum:trace.http.request.duration{service:api}.as_count()”, 99.9)
—
3. エラーバジェット管理による「リリース判断」の自動化
エラーバジェットの消費率をSlackに流すだけでは不十分だ。「バジェットが残り20%を切ったら、自動的にデプロイをブロックする」というゲートをCI/CDに設ける。
パイプラインでの活用術（擬似コード）
バジェット消費率を取得するコマンド (DD CLIなどを想定)
BUDGET_REMAINING=$(datadog-cli slo get-budget –slo-id “abc-123”)
if [ “$BUDGET_REMAINING” -lt 20 ]; then
echo “Error budget is critical. Release aborted.”
exit 1
fi
この「強制停止」こそが、開発チームに「トイレットペーパーを使い切る前に補充（修正・最適化）する」という規律を植え付ける。
—
4. 伝説的アーキテクトからの「極限のハック」
① 「バーンレート」を監視せよ
SLOの残り時間だけでなく、「バジェットを消費する速度（Burn Rate）」をアラート条件に含めろ。
「残りバジェットが減っている」ことよりも、「過去1時間でバジェットを急激に消費している」ことの方が異常事態だ。Datadogの`slo_burn_rate`アラートを使い、マルチウィンドウ（長期間と短期間）で異常を検知せよ。
② メモリ消費とコストの最適化
Datadogのカスタムメトリクスは課金対象だ。無闇に高解像度（1秒間隔など）でメトリクスを投げると、月末に請求書を見て絶叫することになる。
- タグのカーディナリティ（Cardinality）爆発を防ぐ: UUIDやタイムスタンプをタグに入れるな。それは死を意味する。
- サンプリングの活用: 100%のトレースが不要な場合は、Agent側で`trace_sampling_rate`を調整し、コストと可視性の最適バランスを極めろ。
—
結論：SREは「開発を止める人」ではない
SLOを正しく定義し、エラーバジェットを可視化することは、開発チームに「安心してアクセルを踏める根拠」を与えることと同義だ。
「バジェットが余っている？なら、今週は多少リスキーな新機能もリリースしよう」
「バジェットが尽きた？なら、今週は信頼性のためのリファクタリングに全力を注ごう」
このサイクルこそが、オブザーバビリティの真髄だ。ツールを使いこなすのではない。ツールを使って、エンジニアリングの意思決定の質を一段上の次元へ引き上げるのだ。
さあ、ダッシュボードを閉じて、コードを書け。ただし、そのコードがシステムにどう影響するかを、SLOという「真実の鏡」に映し出しながら。