SLO (Service Level Objective)

概要

Datadog の SLO は、成功した割合や規定の速さで返せた割合といった指標に対して「この期間でどれだけ満たせていればよいか」を宣言し、達成度と残りの猶予を同じ画面で追えるようにする機能です。目標を置いた時点で、満たさなくてよい量 (エラーバジェット) も自動的に決まります。指標の件数から計算する型、既存モニターの正常時間から計算する型、時間帯ごとに良否を塗り分ける型の三つがあり、期間は移動する 7 日・30 日・90 日などから選びます。達成しているかどうかだけでなく、残りをどの速さで使っているかまで見えるため、安定化と機能追加のどちらに手を割くかを話し合うときの共通の物差しになります。

指標・目標・約束・残り猶予の四語を分ける

土台になるのは SLI と呼ばれる測る側の指標です。応答が成功した割合、規定の秒数より速く返せた割合のように、良し悪しを一つの数値で表せる形にします。その SLI に対して「移動する 30 日で 99.9%」のような水準を置いたものが SLO で、同じ水準を客との約束として明示し、満たせなかったときの結果まで定めたものが SLA です。公式の用語集はこの三語を分けて定義しており、混ぜて使うと社内の目標と対外的な責任が同じ重さで扱われてしまいます。四つめがエラーバジェットで、公式には目標値から導かれる「許容される不調の量」、すなわち 100% から目標を引いた分と定義されています。30 日で 99.9% を狙うなら残りは 0.1% ぶんで、障害でも改修の副作用でも、不調が起きた時間や件数はここから引かれます。達成度を一つの割合として見るのではなく、減っていく残高として扱えることが、この四語をそろえる利点です。

三つの型は SLI の作り方で選ぶ

Datadog で SLO を作るとき、最初に決めるのは型です。三つの違いは達成度をどう計算するかにあり、手元にすでにある監視資産から選ぶと迷いません。

時間帯型はモニターを必要とせず、作成画面で絞り込みとしきい値を変えながら不調だった時間をその場で確かめられます。目標に書ける小数点の桁数は型と期間で違い、モニター型は 7 日と 30 日で 2 桁、90 日で 3 桁、メトリクス型はどの期間でも 3 桁までです。桁数の上限は「99.95% は書けるが 99.995% は書けない期間がある」という形で設計に効いてくるため、水準を決めてから型を選ぶと行き詰まります。

目標を 100% に置けない理由

公式ドキュメントは、エラーバジェットとその通知の利点を得るには目標値を 100% より厳密に低く設定しなければならないと明記しています。理由は二つ挙げられています。100% にするとエラーバジェットが 0% になり、許容できるリスクを表す量が消えるため、顧客に見える信頼性の維持と機能開発への投資という相反する優先度のあいだで合意を作れなくなること。もう一つは、目標が 100% だと通知の評価で 0 による除算が起きることです。ここが SLO を置いて嬉しい部分でもあります。エラーバジェットは公式の定義でも「製品開発に投じられることを意図した」量であり、余っているなら新機能や移行のような不確実な変更に踏み込んでよい、使い切ったなら安定化を先にするという判断を、印象ではなく残量で言えるようになります。慎重派と推進派の議論を毎回やり直さずに済むのは、目標を一つの数字に固定した副産物です。

残高だけでなく減る速さを見る

一覧画面には SLO 名の隣にバーンレートの表示が出ます。これは直近 2 時間の移動窓で、エラーバジェットを速く使いすぎている SLO を見分けるためのものです。過去 2 時間のバーンレートが 6 を超えると重大を示す赤、1 から 6 のあいだなら高めを示す黄が付き、重大・高め・健全で絞り込めます。service タグが付いた SLO では、表示から該当サービスの画面へ直接たどれます。通知として飛ばすには SLO とは別に監視を作ります。用意されているのは二種類で、エラーバジェットアラートは残高のうち指定した割合が使われた時点で知らせるもの、バーンレートアラートは消費の速さが指定した水準を超え、一定時間続いたときに知らせるものです。文面に入れられる変数も分かれており、消費した割合はエラーバジェットアラート専用、短い窓と長い窓のバーンレート値はバーンレートアラート専用です。「今月はもう危ない」と「いまの勢いがまずい」は別の問いなので、両方を使い分けます。

予定していた停止を残高から外す

計画的な保守で止めた時間まで残高から引かれると、目標は運用の実態を映さなくなります。これに対しては状態の訂正という仕組みがあり、指定した期間を達成度とエラーバジェットの計算から落とせます。公式が挙げる用途は、予定された停止で残高を減らさないこと、SLO を守る前提のない営業時間外を無視すること、デプロイ由来の一時的な問題を持ち込まないことです。落とし方は型ごとに違い、モニター型は訂正した期間を数えず、メトリクス型はその期間の良い事象も悪い事象も数えず、時間帯型は訂正した期間を正常だった時間として扱います。訂正には一度だけのものと定期的に繰り返すものがあり、いずれも理由の区分 (予定された保守、営業時間外、デプロイ、その他) を選ぶ必要があります。区分が残るので、後から「なぜこの期間を外したのか」をたどれます。

作っただけでは鳴らない、月初には戻らない

一つめは、SLO を作っただけでは何も鳴らないことです。達成度は計算され画面には出ますが、通知はエラーバジェットアラートかバーンレートアラートを別に作って初めて届きます。モニター型で使ったもとのモニターが鳴ることと、SLO の残高が危ないことは別の出来事です。二つめは期間の数え方です。移動する 30 日を選んだ SLO は、いつ見ても「その時点から遡った 30 日」を評価しているので、月初にリセットされる数字ではありません。暦の区切りで振り返りたい場合は、一覧画面で日次・週次・月次の暦表示に切り替えると 12 か月ぶんの履歴を追えます。ただしこの表示に対応するのはメトリクス型と時間帯型で、モニター型は対象外です。