こんにちは。オブザーバビリティの世界へようこそ。
「監視」というと、多くの現場では「障害が起きたら通知が飛んでくる設定」程度で止まっています。しかし、真のオブザーバビリティは違います。それは、「今、私たちのサービスはユーザーに対して誠実か？」をデータで証明する技術です。
今日は、DatadogのSLO（Service Level Objectives）を用いて、開発チームが疲弊することなく、かつ爆速でリリースを回すための「エラーバジェット管理」の神髄を伝授します。
—
1. なぜ「監視」ではなく「SLO」なのか？
初心者の方がまず陥る罠は、「CPU使用率が80%を超えたらアラート」といった「システム視点の監視」に執着することです。しかし、CPUが80%でもユーザーが快適なら、それはアラートにすべきではありません。
重要なのはSLI（Service Level Indicator：サービス品質指標）です。
- 「ユーザーがログインボタンを押してから、画面が表示されるまで2秒以内か？」
- 「決済リクエストに対して、500エラーは出ていないか？」
これらを定義するのがSLOです。そして、エラーバジェット（失敗を許容する枠）こそが、開発と運用の間の「不毛な対立」を解消する魔法の杖になります。
—
2. DatadogでのSLO定義：最初の一歩
DatadogでSLOを定義する際は、複雑なダッシュボードを作る前に「何がユーザーにとっての成功か」を絞り込みます。
ステップ1：SLIの選定
まずは「HTTPリクエストの成功率」から始めましょう。DatadogのAPM（Application Performance Monitoring）を使っているなら、`trace.http.request`のステータスコードを指標にするのが最も確実です。
ステップ2：SLOの作成手順
1. Datadogコンソールから `Service Level Objectives` を選択。
2. `New SLO` をクリック。
3. Monitor-based ではなく、Metric-based を選ぶのがプロのコツです。
- `Monitor-based` はアラートの「点」しか見ませんが、`Metric-based` は過去のログやメトリクスを遡って集計できるため、精度が圧倒的に高いからです。
設定コードのイメージ（Datadog APIによる定義）
手動ポチポチも良いですが、Infrastructure as Code（IaC）として管理するのが現場の鉄則です。
{
“name”: “Checkout Service Success Rate”,
“type”: “metric”,
“thresholds”: [
{
“timeframe”: “7d”, // 過去7日間の平均で評価
“target”: 99.9, // 目標成功率
“warning”: 99.95 // 警告ライン（余裕を持って設定）
}
],
“query”: “sum:trace.http.request.hits{service:checkout-service, !status:5xx}.as_count() / sum:trace.http.request.hits{service:checkout-service}.as_count()”
// 成功数 / 全リクエスト数 で「成功率」を算出
}
—
3. エラーバジェットによる「リリース判断」の自動化
ここからが本題です。「エラーバジェット」とは、サービスが許容できる「失敗の合計数」のことです。
例えば、目標を99.9%（スリーナイン）とすると、0.1%分の失敗は許されます。この「0.1%分の予算」が残っている間は、開発チームは自信を持って新しい機能をリリースして良い。逆に、バジェットが尽きたら「新機能のリリースを停止し、信頼性向上（リファクタリングなど）に全力を注ぐ」という合意をチーム内で作ります。
現場で震えるほど役立つ運用ルール
- バジェットが80%残っている時： 爆速でデプロイせよ。
- バジェットが残り20%になった時： リリースは慎重に。パイプラインのテストを強化せよ。
- バジェットが0になった時： 新機能のデプロイを即座に凍結。信頼性の修正以外は許可しない。
これをチームの「共通言語」にすると、エンジニアは「アラートに追われる恐怖」から解放され、「ユーザーのために何を作ればいいか」という本質に集中できるようになります。
—
4. 今日から始める「Hello World」的アクション
まずは、あなたのサービスで最も重要なエンドポイントを1つだけ選び、DatadogでSLOを1つだけ作ってみてください。
1. Metric-based SLO を作成する。
2. Timeframe を `30d`（30日間）に設定する。
3. Dashboard にそのSLOウィジェットを貼り付け、チームのSlackチャンネルに毎日朝9時に「現在のエラーバジェット残量」を自動通知させる。
これだけで、チームの景色は劇的に変わります。「今、バジェットをどれくらい消費したか？」という客観的な数字があるだけで、議論が感情論ではなく「データ駆動」になります。
—
最後に：オブザーバビリティは「文化」である
どんなに高価なツールを入れても、それを扱うエンジニアが「アラートを無視する文化」に染まっていれば、それはゴミと同じです。
SLOを設定することは、「私たちはこれくらいの品質を約束します」というユーザーへのラブレターです。そしてエラーバジェットは、チームが健やかに働き続けるための防波堤です。
まずは小さく始めて、データと共にチームの自信を育てていってください。何か詰まったら、いつでもまた聞きに来てくださいね。あなたの運用ライフが、より創造的で静かなものになることを願っています。