恐怖から解放されるための「SLO駆動開発」：Datadogでエラーバジェットを武器に変える技術
多くのチームが監視ツールを導入しているが、その実態は「障害が起きたら鳴るアラート」という名の心霊現象に怯える日々ではないか。
もし君たちが「99.9%の可用性」を神に祈るように守ろうとしているなら、それはSREではない。単なる「保守係」だ。真のオブザーバビリティとは、「システムが壊れることを前提に、いかに素早く、かつ安全に価値を届けるか」という哲学を体現することにある。
今日は、DatadogのSLO（Service Level Objectives）を単なる「管理ダッシュボード」から「開発チームのアクセル」へと昇華させる、現場の極限の知見を授ける。
—
1. SLOの定義：ユーザー体験を「数値」に落とし込むプロの流儀
SLOは「システムの健康状態」ではない。「ユーザーの幸福度」だ。
- SLI（Service Level Indicators）は「体験」を測れ
- `CPU使用率 < 80%` はゴミだ。ユーザーはCPUなんて見ていない。
- `HTTP 5xx率` や `P99レイテンシ`、あるいは「ログイン成功率」こそが真のSLIだ。
- エラーバジェットは「挑戦の権利」だ
- 1ヶ月のバジェットが「5分」なら、その5分は「新しい機能を攻めるために使い切るべきコスト」である。バジェットが余っているなら、もっと尖ったリリースをすべきだ。
—
2. Datadog SLO：設定のベストプラクティス（Terraform構成）
GUIでポチポチするのは一度きりにしろ。SREの神髄は「コードとしての監視（Monitoring as Code）」だ。以下は、実務で使えるTerraformの構成例だ。
Datadog SLOリソース定義のベストプラクティス
resource “datadog_service_level_objective” “checkout_slo” {
name = “Checkout Success Rate”
type = “metric”
description = “決済成功率（ユーザーの購買体験を保護する）”
# ターゲットは99.9%。これ以下になるとバジェットが溶ける
thresholds {
timeframe = “30d”
target = 99.9
warning = 99.95 # 警告ラインを早めに引き、チームの意識を向けさせる
}
# SLIの定義：成功リクエスト / 全リクエスト
query = “sum:trace.checkout.request{status:success}.as_count() / sum:trace.checkout.request{}.as_count()”
tags = [“team:checkout”, “env:production”, “tier:1”]
}
【テックリードからの助言】
`warning`閾値を必ず設定せよ。バジェットが尽きてからアラートを鳴らすのは遅い。「バジェットを消費するペースが異常に速い」こと（Burn Rate）を検知して、リリースを即時停止させるのが現代のSREだ。
—
3. エラーバジェット管理：リリース判断の「赤信号」
バジェットが残り何％か？ を判断基準にすることで、「リリースしていいですか？」という無意味な会議は消滅する。
- Burn Rateベースのアラート設定
- Datadogの `SLO Burn Rate Alert` を使い、「現在の消費ペースだと24時間でバジェットが枯渇する」という異常を検知せよ。
- チームのルール：バジェットが20%を切ったら機能開発凍結
- 残り20%になったら、全エンジニアが「信頼性向上（技術負債返済・テスト強化）」に全振りする。このルールさえあれば、マネジメント層からリリースを急かされても「バジェットがないので無理です」と論理的に拒絶できる。
—
4. 知る人ぞ知るDatadogの「神」テクニック
① 爆速操作のためのキーボードショートカット
- `Shift + ?` ：キーボードショートカット一覧を表示。これを暗記していないエンジニアは、マウスを触る時間を減らせ。
- `Ctrl + K` (Mac: `Cmd + K`) ：コマンドパレットを呼び出せ。ここからSLO名やダッシュボード名を入力すれば、メニューを潜る必要はない。
② 必須の「神プラグイン/設定」：`Service Map` と `Trace Query`
- SLOが違反した際、`Trace ID` を見て犯人を探すのは古い。`Service Map` 上で、どの依存サービスがSLIを押し下げているかを視覚的に特定せよ。
- 「Traceタグの活用」: 開発者は、Traceに `deployment_id` や `feature_flag` を埋め込め。Datadog上で「どのリリースがバジェットを溶かしたか」を一瞬で相関させられる。
③ チームでの共有化ルール
- 全てのアラートには 「Runbook（障害対応手順書）」へのリンクを必ず含めろ。
- `message` フィールドに `@pagerduty-team-name` だけでなく、`{{slo.url}}` を埋め込め。通知を受けた瞬間にSLOの詳細画面に飛べる環境を作ることが、MTTR（平均修復時間）を劇的に下げる。
—
最後に：エンジニアの誇りについて
SLOを導入するのは、監視を厳しくするためではない。「エンジニアが安心して失敗できる環境を作るため」だ。
バジェットという明確な指標があれば、私たちは「勘」でデプロイせず、「数値」を盾にして攻めることができる。もし君たちが今、何となくのアラートに追われているなら、今日からSLOを定義し直せ。
バジェットを使い切り、誰よりも速く走り、かつ誰よりも安定したシステムを構築する。それが我々、オブザーバビリティ・エンジニアの矜持だ。
さあ、コードを開け。まずは最も重要な一つのSLIから定義を始めよう。