SLO
エスエルオー
サービスの信頼性目標を数値で定めたもの。SLIという指標で測り、運用判断の基準にする。
概要
SLO（Service Level Objective、サービスレベル目標）は、「このサービスはどれくらい信頼できるべきか」を数値で定めた目標です。たとえば「直近30日間で、リクエストの99.9%が成功する」「95%のリクエストが300ミリ秒以内に応答する」のように、期間・指標・目標値の組で表現します。
ここで重要なのが SLI（Service Level Indicator、サービスレベル指標）との関係です。SLI は「実際に測る指標」、SLO は「その指標が満たすべき目標値」です。「リクエスト成功率」というメトリクスが SLI で、「それが99.9%以上であること」が SLO — 測るものと目指す水準を分けて考えるのが出発点です。SLO は単なる数値目標ではなく、アラートの閾値、リリース可否の判断、インフラ投資の優先度まで、運用のあらゆる意思決定の基準線として機能します。
「100%を目指さない」ことが SLO の思想の核心です。完璧な信頼性は原理的に不可能であるだけでなく、目指すこと自体が有害になり得ます。SLO はあえて「ここまで壊れてよい」という許容量を明示することで、信頼性と開発速度のバランスを設計可能にする道具です。
なぜ生まれたか
SLO という考え方が整理される以前、サービスの信頼性目標は「安定稼働に努める」「障害を起こさない」といった曖昧な言葉で語られていました。曖昧な目標は測定できず、測定できない目標は達成も判断もできません。障害が起きるたびに「どこまでやれば十分なのか」の基準がないまま、開発チームは「もっと速くリリースしたい」、運用チームは「もう変更を入れないでほしい」と綱引きを続ける — この対立を裁く客観的な物差しがなかったのです。
もうひとつの問題は「100%神話」でした。信頼性は高いほど良いという素朴な前提のもと、際限なくコストを注ぎ込んでも、ユーザーの体感はある水準を超えると変わりません。ユーザー自身のスマートフォンや Wi-Fi の信頼性が99.9%程度しかない世界では、サーバ側を99.999%にしても差は雑音に埋もれます。しかも信頼性は「9」をひとつ増やすごとにコストが桁で増えていきます。
Google の SRE はこの2つの問題に対して、「信頼性を明示的な数値目標として定義し、それを超える部分は開発速度に投資する」という解を与えました。SLI で測り、SLO で目標を定め、目標との差分をエラーバジェットとして運用に組み込む — この一連の体系の土台が SLO です。
詳細
SLI を選ぶ — 何を測れば「ユーザーの体験」になるか
SLO の質は SLI の選び方で決まります。良い SLI の条件は「ユーザーが体感する品質に近いこと」です。代表的なのは、可用性（リクエストのうち成功した割合）、レイテンシ（一定時間内に応答した割合）、スループット、データの鮮度・正確性などです。逆に、CPU 使用率やメモリ使用量はモニタリングには重要でも SLI には向きません。CPU が90%でもユーザー体験が良好なら問題はなく、CPU が10%でも応答が遅ければ問題だからです。
測定点もユーザーに近いほど正確になります。サーバ内部のログで測ると、ロードバランサより手前で落ちたリクエストが数えられません。可能ならロードバランサのログや、クライアント側の計測も組み合わせて「ユーザーから見た成功率」に近づけます。
SLI・SLO・SLA の三層関係
SLI・SLO と混同されやすいのが SLA です。SLA は顧客との「契約」であり、違反すると返金などの補償が発生します。三者の関係は「SLI で測り、SLO を内部目標として運用し、SLA はそれより緩い水準で外部に約束する」という三層構造で捉えると整理できます。
SLO を SLA より厳しく設定しておけば、SLO を割り込んだ時点で社内に警報が鳴り、契約違反（＝補償の発生）に至る前に手を打つ余裕が生まれます。SLO は「早期警戒線」、SLA は「防衛ライン」という関係です。
目標値の決め方と「9の数」
SLO の目標値は「現状の実績」と「ユーザーの期待」の両方から決めます。よく使われるのが可用性の「9の数」で、99%（月に約7時間の停止を許容）、99.9%（月に約43分）、99.99%（月に約4分）と、9がひとつ増えるたびに許容停止時間は10分の1になり、達成コストはおおむね桁で増えます。冗長化・多重化・自動フェイルオーバーと、スケーリングや分散システムの設計難度が段階的に上がっていくためです。「うちのサービスに本当に4つ目の9が必要か」を問い直すことが、SLO 設計の最初の仕事になります。
なお、期間の取り方にも設計があります。「直近30日間のローリングウィンドウ」なら常に最新の実績を反映でき、「四半期ごと」なら事業計画と揃えやすい、といった使い分けです。
「9の数」がどれほど急峻な要求かは、実際に動かしてみると腑に落ちます。
※ ここで動かしているのは内部目標のSLO。顧客と結ぶSLA（契約）はこれより緩い水準に置き、SLO超過の時点で社内警報が鳴るようにします。
SLOの「9の数」を切り替えて、許容ダウンタイムの変化を見てみてください。障害ボタンで予算を燃やせます。
運用への組み込み — SLO は決めて終わりではない
SLO は掲げるだけでは機能しません。実務では、SLO の残り許容量であるエラーバジェットを追跡し、消費ペース（バーンレート）に基づいてアラートを設定します。「エラー率が1%を超えた」という瞬間値ではなく、「このペースが続くと月内に SLO を割る」という予測でアラートを鳴らすことで、誤報を減らしつつ本当に危険な兆候を捉えられます。
典型的な落とし穴は、達成できて当然の緩すぎる SLO（何の判断にも使われない）、逆に恒常的に未達の厳しすぎる SLO（警報が常態化して無視される）、そしてユーザー体験と乖離した SLI（数字は良いのに苦情が来る）です。SLO は一度決めたら固定ではなく、実績とユーザーの声を見ながら定期的に見直す「生きた合意」として扱うのが健全な運用です。