🔵

【概念編】SLI/SLOとは何か - ユーザー体験から信頼性を定義する

2026/07/27に公開

SRE

SLO

tech

【概念編】SLI/SLOとは何か——ユーザー体験から信頼性を定義する

この記事は、SLI/SLOを「定義し、実践し、運用で育てる」までを扱う3部作の1本目・概念編です。

【概念編】SLI/SLOとは何か——ユーザー体験から信頼性を定義する(この記事): SLI/SLOの基本的な考え方と作り方
【実践編】GitLab Self-hosted(AWS)のSLI/SLOを定義し、CloudWatchで表現する: 実際のインフラ構成に当てはめる
【運用編】SLI/SLOをチームに定着させ、運用で育てる: 定義したSLI/SLOをチームに定着させ、育てていく方法

想定読者

SLI/SLOという言葉は知っているが、実際にどう作ればよいか分からない方
「稼働率99.9%」のような数値だけが独り歩きしていて、もっと納得感のある指標を作りたい方
CPU使用率やエラーレートといったサーバー目線の監視だけで信頼性を語ることに違和感がある方
SREやプロダクト開発に携わっていて、チームでSLI/SLOを新しく導入・見直ししたい方

前提となる専門知識は不要ですが、Webサービスの一般的な仕組み(HTTPリクエスト、API、ログなど)がイメージできると読みやすくなります。

この記事のゴール

読み終えたときに、以下の状態を目指します。

SLI / SLO / SLA / エラーバジェット / Burn Rateの違いを説明できる
ユーザー体験からSLIを考えられる
SLIを「測れそうなメトリクス名」ではなく、仕様と実装に分けて考えられる
SLOに必要な目標値・測定期間・成功条件を書ける
悪いSLI/SLOを見て、どこが悪いか指摘できる
レイテンシを見るときに、平均ではなくp95/p99を使う理由を説明できる

この概念を押さえたうえで、実践編・運用編で実際の環境への適用と、チームへの定着までを見ていきます。

はじめに

「このサービスは安定していますか?」と聞かれたとき、何を根拠に答えるでしょうか。ありがちな回答は次のようなものです。

サーバーが落ちていない
アラートが鳴っていない
CPU使用率が高くない
障害報告が来ていない
なんとなく大丈夫そう

しかし、これらは必ずしもユーザーがサービスを使えていることを意味しません。たとえば、次のような状態は十分にあり得ます。

サーバーは起動しているが、ログインできない
APIは200を返しているが、レスポンスの中身が空
CPUは低いが、決済完了まで10秒以上かかる
アラートは鳴っていないが、ユーザーは投稿に失敗している

SLI/SLOは、信頼性を「サーバー目線」ではなく、ユーザーが目的を達成できているかという観点で測るための考え方です。この記事では、SLI/SLOの基本から、実際にどう作っていくか、そしてよくある失敗パターンまでを一つの例を通して整理します。

SLI / SLO / SLA / エラーバジェットの基本

SLIとは

SLIはService Level Indicatorの略で、サービスレベルを測るための指標です。

Google Cloudのドキュメントでは、SLIはサービスのパフォーマンス測定、SLOは望ましいパフォーマンスの表明、エラーバジェットは1 - SLOから始まり実績がSLOを下回ることで消費されるもの、と整理されています。(Google Cloud Documentation)

SLIの例としては、次のようなものが挙げられます。

ログイン成功率
投稿成功率
検索API成功率
決済完了率
レスポンスタイム
データ処理の完了率
最新データが反映されるまでの時間

重要なのは、単に「測れるもの」を選ぶのではなく、ユーザー体験に近い指標を選ぶことです。

SLOとは

SLOはService Level Objectiveの略で、SLIに対する目標値です。

過去30日間において、画像投稿リクエストの99.5%以上が5秒以内に成功する。

SLOには次の要素が必要です。

対象となるSLI
目標値
測定期間
成功・失敗の定義
除外条件

Google Cloudのドキュメントでも、SLOはSLIに対する目標値であり、SLI・パフォーマンス目標・測定期間によって構成されると説明されています。(Google Cloud Documentation)

SLAとは

SLAはService Level Agreementの略で、顧客や外部利用者との契約上の約束です。

月間稼働率99.9%を下回った場合、返金対象とする。

SLOは内部目標、SLAは契約上の約束です。SLO未達だから必ず返金、というわけではありません。ただし、SLOを適切に設定しておくことで、SLA違反になる前に検知・改善するための早期警戒として使えます。

エラーバジェットとは

エラーバジェットは、SLOで許容している失敗量です。
たとえばSLOが99.9%であれば、許容される失敗量は0.1%です。この0.1%がエラーバジェットにあたります。
エラーバジェットが十分に残っていれば、ある程度リスクのあるリリースや改善を進めやすくなります。逆に使い切りそうであれば、新機能リリースよりも信頼性改善を優先する判断ができます。

Burn Rateとは

エラーバジェットの残量だけを見ていると、判断が遅れることがあります。たとえば30日間のエラーバジェットが50%残っていても、直近1時間で急激に消費されていれば、そのままでは残りの期間を待たずに枯渇してしまいます。この消費速度を表す指標がBurn Rateです。

Burn Rate = 実際のエラー率 ÷ 許容エラー率(エラーバジェット)

たとえばSLOが99.9%(許容エラー率0.1%)のとき、実際のエラー率が1.4%であれば、Burn Rateは14です。Burn Rate 1は「ちょうど測定期間(30日など)でエラーバジェットを使い切るペース」を意味し、1より大きいほど、期間の途中で枯渇するペースで消費していることになります。

エラーバジェットの残量は「今どれだけ余裕があるか」を表す指標であるのに対し、Burn Rateは「このペースが続いたらいつ枯渇するか」を表す指標です。残量が十分にあっても、Burn Rateが高ければ近いうちに枯渇することが分かりますし、逆に残量が減っていてもBurn Rateが1未満であれば、そのペースのままなら期間内には枯渇しません。両方を合わせて見て初めて、「まだバジェットは残っているが、このままでは今週中に枯渇する」といった早期の判断ができます。

Google SREのSRE Workbookでは、瞬間的なエラー率だけでアラートを出すと、月間SLOにはほとんど影響しない事象でも大量に通知されてしまうため、短い時間ウィンドウと長い時間ウィンドウを組み合わせてBurn Rateを評価する手法(マルチウィンドウ・マルチバーンレートアラート)が紹介されています。(Google SRE) この具体的な実装は実践編で扱います。

残量と消費速度が別の軸であることを図にすると、次のようになります(数値は説明用のイメージです)。

Burn Rate = 1は30日かけてちょうど0になりますが、Burn Rate = 6や14.4では、期間のごく初期(5日、2日程度)で枯渇してしまうことが分かります。残量だけを見ていると、この「早期に枯渇するペースで進んでいる」状態に気づけません。

The Art of SLOs式:ユーザージャーニーからSLIを作る

ここがSLI/SLOを考えるうえで一番大事なポイントです。
SLI/SLOは、いきなり「API成功率を99.9%にしよう」と決めるのではなく、まず重要なユーザージャーニーから考えます。
GoogleのParticipant Handbookでは、ユーザーはサービスを使って何らかの目的を達成しようとしており、その目的達成のための一連の操作をユーザージャーニーと呼んでいます。
また、SLIはそのジャーニーにおけるユーザーとサービスのやりとりを測るべきものとして説明されています。(Google SRE)

Critical User Journeyとは

Critical User Journey、略してCUJは、ユーザーにとって重要な一連の体験です。たとえば画像投稿SNSであれば、次のような体験があります。

ログインする
タイムラインを見る
画像を投稿する
投稿された画像を見る
コメントする
いいねする

この中で、サービス価値に直結するものを優先します。最初に考えるべきCUJは、たとえば次のようなものです。

ユーザーが画像を投稿できる

または

ユーザーがタイムラインを表示できる

SLIを作る4ステップ

The Art of SLOsのハンドブックでは、重要なユーザージャーニーをビジネス影響順に並べたうえで、以下の4ステップでSLI/SLOを作る流れが示されています。(Google SRE)

SLI Specificationを選ぶ
詳細なSLI Implementationに落とす
ユーザージャーニーをたどり、計測漏れを探す
過去実績またはビジネス要求からSLOを設定する

これを噛み砕くと、次のような流れになります。

ユーザーが何を達成したいか決める
その体験を測るSLIの種類を選ぶ
何を成功・失敗として、どこで測るか決める
目標値と期間を決める

この記事全体を通して繰り返し登場する型を、図にすると次のようになります。

SLI SpecificationとSLI Implementation

SLI/SLOでよくある失敗は、いきなりメトリクス名を書いてしまうことです。

http_requests_total
nginx_status_code
api_latency

これらはメトリクスとしては大事ですが、まだSLIとしては不十分です。
The Art of SLOsのワークシートでは、SLIにはイベント、成功条件、成功・失敗をどこでどう記録するかが必要であり、SLIは「良いイベントの割合」として表現することが推奨されています。
また、SLOには目標値と測定期間が必要です。

SLI Specification

SLI Specificationは、ユーザー期待を表す大まかな仕様です。

有効な画像投稿リクエストが成功した割合

有効なタイムライン表示リクエストが一定時間以内に完了した割合

有効なログインリクエストが成功した割合

この段階では、まだ「どのログで測るか」「どのHTTPステータスを成功にするか」までは細かく決めていません。

SLI Implementation

SLI Implementationは、実際にどう測るかまで具体化したものです。

ALBのアクセスログを使い、
POST /api/posts へのリクエストのうち、
HTTP 2xx を返したものを成功、
HTTP 5xx とタイムアウトを失敗として集計する。
ただし、認証エラー、画像サイズ超過、バリデーションエラーは除外する。

ここまで書くと、実際に計測・実装・レビューができるようになります。

SLIの種類

The Art of SLOsの資料では、SLIの種類として、Request/Response系ではAvailability、Latency、Quality、Data Processing系ではFreshness、Coverage、Correctness、Throughputなどが示されています。
下記以外にもありますが、まずは以下を中心に押さえておきましょう。

種類	何を見るか	例
Availability	使えるか	投稿成功率、ログイン成功率
Latency	速いか	95%のリクエストが1秒以内
Quality	品質が落ちていないか	低画質化せず画像を返せた割合
Freshness	新しいか	投稿が10秒以内にタイムラインへ反映
Correctness	正しいか	集計結果が正しい割合
Throughput	処理量を満たせるか	1分あたりN件以上処理できる割合

例題:画像投稿SNSのSLI/SLOを作ってみる

ここまでの考え方を、実際の例で追ってみます。対象サービスは画像投稿SNS、対象ユーザージャーニーは「ユーザーが画像を投稿できる」です。

Step 1: ユーザー期待を言語化する

ユーザーは、画像を選択して投稿ボタンを押したら、投稿が完了し、自分や他のユーザーがその投稿を見られることを期待しています。

Step 2: SLI Typeを選ぶ

このユーザージャーニーでは、まず以下が候補になります。

Availability: 投稿できるか
Latency: 投稿が一定時間以内に完了するか
Freshness: 投稿後、タイムラインに反映されるか

ここではまずAvailabilityとLatencyに絞って考えます。

Step 3: SLI Specificationを書く

Availability SLI Specification

有効な画像投稿リクエストが成功した割合

Latency SLI Specification

有効な画像投稿リクエストが5秒以内に完了した割合

Step 4: SLI Implementationに落とす

Availability SLI Implementation

POST /api/posts へのリクエストのうち、HTTP 2xx を返し、投稿IDが生成されたものを成功とする。
HTTP 5xx、タイムアウト、DB書き込み失敗は失敗とする。

ただし、以下はサービス失敗から除外する。
- 未ログイン
- 画像サイズ超過
- 不正なファイル形式
- 必須項目不足

Latency SLI Implementation

POST /api/posts への有効なリクエストのうち、リクエスト受信からレスポンス完了までが5秒以内だった割合。
計測地点はALBまたはアプリケーションログとする。

Step 5: SLOを書く

Availability SLO

過去30日間において、有効な画像投稿リクエストの99.5%以上が成功する。

Latency SLO

過去30日間において、有効な画像投稿リクエストの95%以上が5秒以内に完了する。

Step 6: 計測漏れを確認する

最後に、The Art of SLOsの考え方に沿って、ユーザージャーニーを実際にたどってみます。
画像投稿の場合、次のような流れになります。

ユーザーが画像を選ぶ
投稿ボタンを押す
フロントエンドがAPIへ送信する
APIが画像を受け取る
ストレージへ保存する
DBに投稿情報を書き込む
レスポンスを返す
タイムラインに表示される

ここで、次のような点を確認します。

APIの成功だけで、本当に投稿成功と言えるか
ストレージ保存失敗を検知できるか
DBには書けたが画像が表示できないケースは拾えるか
投稿後にタイムラインへ出ないケースは別SLIが必要ではないか
ALBログだけで十分か、アプリログやクライアント計測も必要か

この確認は非常に重要です。実際のSLI/SLO設計では、この「計測漏れの洗い出し」に多くの時間を使うことになります。

このユーザージャーニーを図にし、それぞれのステップがどの計測手段で見えるかを重ねると、次のようになります。

APIの成功(S4〜S6)まではALBログやアプリログで追えますが、S7〜S8の「保存後に本当にタイムラインへ反映されたか」は、多くの場合どちらのログにも現れません。これが「計測漏れ」の典型的な発生箇所です。

SLIの測定方法

SLIは「何を測るか」だけでなく、「どこで測るか」も重要です。
The Art of SLOsのハンドブックでは、SLIの測定方法として、ログ処理、アプリケーションサーバーメトリクス、フロントエンドインフラメトリクス、Synthetic Clients / Probers、Client Instrumentationなどが紹介されています。
一般にSLIはユーザー体験に近い場所で測ることが望ましい一方、それぞれにトレードオフがあります。(Google SRE)

測定方法	例	良い点	注意点
サーバーログ	Nginx / アプリログ	後から集計しやすい	サーバーに届かない失敗は見えない
アプリメトリクス	成功/失敗カウンタ	業務ロジックに近い	実装が必要
LB / ALBメトリクス	2xx/5xx、Latency	導入しやすい	レスポンス内容までは見えない
外形監視	定期的にアクセス	ユーザーに近い	全ユーザーの体験ではない
クライアント計測	ブラウザ/アプリから送信	最もユーザー体験に近い	実装・同意・ノイズの扱いが必要

それぞれの測定方法が、リクエストの通り道のどの位置で計測しているかを図にすると、次のようになります。

クライアントに近いほどユーザー体験そのものに近づきますが、実装や同意取得のコストが上がります。逆にロードバランサに近いほど導入は簡単ですが、「届いたリクエストの結果」しか分からず、クライアントに届く前の失敗は見えません。

よくあるアンチパターン

1. CPU使用率やメモリ使用率をSLIにする

悪い例

CPU使用率が80%未満であること

CPUやメモリは重要な監視項目ですが、ユーザーがサービスを使えているかを直接表していません。CPUが低くてもログインできない場合はありますし、逆にCPUが高くてもユーザー体験に問題がない場合もあります。

良い例

有効な画像投稿リクエストの99.5%以上が成功する

2. SLOを100%にする

悪い例

ログイン成功率100%
投稿成功率100%

100%にするとエラーバジェットがなくなり、少しの失敗も許容できなくなります。その結果、リリース判断が過剰に保守的になる、開発速度が落ちる、コストが増える、改善活動よりも失敗ゼロが優先される、現実的な運用判断ができなくなる、といった問題が起きやすくなります。

SLOでは、一定の失敗を許容する考え方が重要です。たとえばSLOが99.9%であれば、残りの0.1%は許容できる失敗量、つまりエラーバジェットとして扱えます。

Google Cloudのドキュメントでも、有用なSLOは100%未満であり、100%のSLOはエラーバジェットを持たないため悪いプラクティスだと説明されています。(Google Cloud Documentation)

良い例

過去30日間で、ログインリクエストの99.9%以上が成功する

3. 測定期間がない

悪い例

API成功率99.9%以上

いつからいつまでで99.9%なのかが分かりません。1時間で見るのか、1日で見るのか、30日で見るのかによって意味が変わります。

良い例

過去30日間で、APIリクエストの99.9%以上が成功する

4. 成功・失敗の定義が曖昧

悪い例

ログインが成功すること

何を成功とみなすかが曖昧です。ログインの場合でも、パスワード間違い、存在しないユーザー、5xxエラー、タイムアウト、認証基盤のエラー、Botによる大量アクセスなど、さまざまなケースがあります。これらをすべて同じ「ログイン失敗」として扱うと、サービスの信頼性を正しく測れません。

良い例

正しい認証情報を送信したログインリクエストのうち、5秒以内に認証成功レスポンスを返した割合。

5. 重要でない機能まで全部SLO化する

悪い例

ログイン、投稿、検索、通知、管理画面、CSV出力、プロフィール編集など、すべてにSLOを設定する

最初から全部やろうとすると、設計も運用も重くなります。SLOは作って終わりではなく、監視・レビュー・改善判断に使うものです。

良い例

まずは重要なユーザージャーニーに絞ります。

ログインできる
投稿できる
タイムラインを見られる

6. ユーザージャーニーを分解しない

悪い例

画像投稿APIが200を返していれば投稿成功とする

APIが200を返しても、画像が保存されていない、タイムラインに出ない、画像が壊れている、というケースがあります。

良い考え方

投稿ボタン押下から、画像が保存され、投稿IDが作られ、ユーザーが投稿を確認できるまでを分解する。

7. SLI Specificationのみ設定

悪い例

投稿が成功した割合

どのリクエストを対象にするのか、どこで測るのか、何を成功にするのかが不明です。

良い例

POST /api/posts への有効なリクエストのうち、HTTP 2xxを返し、投稿IDが生成されたものを成功として、アプリケーションログから集計する。

8. 平均レスポンスタイムだけを見る

悪い例

平均レスポンスタイムが500ms以内

一部のユーザーだけ極端に遅い体験をしていても、平均では見逃すことがあります。

良い例

リクエストの95%以上が1秒以内に完了する

9. 作っただけで運用しない

悪い例

SLOを定義したが、ダッシュボードもない。レビューもしない。リリース判断にも使わない。

SLOは資料に書くためではなく、運用判断に使うためのものです。

良い例

毎週SLO達成状況を確認する。エラーバジェットが減っている場合は信頼性改善を優先する。SLO未達の機能を改善対象にする。

まとめて直してみる

最後に、上記のアンチパターンを詰め込んだ悪い例を一つ通しで直してみます。

悪い例

サーバーのCPU使用率を常に80%未満にし、画像投稿が100%成功すること。

この例には、次のような問題があります。

CPU使用率はユーザー体験に近いSLIではない
画像投稿100%成功は現実的ではなく、エラーバジェットがない
測定期間がない
何を成功・失敗とするかが不明
ユーザー起因エラーをどう扱うかが不明
投稿API成功後に画像保存やタイムライン反映まで見るのかが不明

改善例

過去30日間において、有効な画像投稿リクエストの99.5%以上が5秒以内に成功する。
有効な画像投稿リクエストとは、認証済みユーザーが、許可された画像形式・サイズで、必須項目を満たして送信したPOST /api/postsリクエストとする。

成功とは、HTTP 2xxを返し、投稿IDが生成され、DBへの投稿情報保存と画像ストレージへの保存が完了した状態とする。

失敗とは、HTTP 5xx、タイムアウト、DB書き込み失敗、画像保存失敗、投稿ID生成失敗とする。

未ログイン、画像サイズ超過、不正な画像形式、必須項目不足は、ユーザー起因エラーとしてサービス失敗から除外する。

コラム1:パーセンタイルとは

SLI/SLOでレスポンスタイムを見るとき、平均値よりもp95やp99がよく使われます。
パーセンタイルとは、データを小さい順に並べたときに、全体の何%がその値以下に収まっているかを表す考え方です。
たとえばp95 レスポンスタイム = 1秒なら、「95%のリクエストは1秒以内に完了している」という意味です。逆に言うと、残り5%は1秒を超えている可能性があります。

平均値との違い

以下のレスポンスタイムがあったとします。

100ms, 120ms, 130ms, 150ms, 180ms, 200ms, 220ms, 250ms, 300ms, 5000ms

ほとんどは速いですが、最後の1件だけ非常に遅いです。平均だけを見ると、この極端に遅い1件に影響されます。一方で、「どのくらいのユーザーが遅かったのか」は平均だけでは分かりにくいです。そこで、p95やp99を使います。

10件を小さい順に並べたグラフにすると、次のようになります。

n=10の場合、9件目あたりがp90、10件目(最大値)がp99〜p100に近い位置にあたります。1件だけ突出して遅いリクエストがあっても、平均はこの1件に強く引っ張られる一方、パーセンタイルは「全体の何%がどこまで速いか」という分布の形を保ったまま表現できます。

表現	意味
p50	50%がその値以下。中央値
p90	90%がその値以下
p95	95%がその値以下
p99	99%がその値以下

SLOでの使い方

過去30日間において、投稿APIリクエストの95%以上が5秒以内に完了する。

過去30日間において、検索リクエストの99%以上が3秒以内に完了する。

ただし、p99ばかりを追うと改善コストが大きくなります。一例としては、次のような感覚で使い分けると良いです。

対象	指標例
一般的な画面表示	p95
主要なAPI	p95 / p99
決済・認証・重要業務	p99も検討

コラム2:自分たちらしいSLOを作る

SLI/SLOを学ぶと、つい「正しいSLOを作らなければいけない」「GoogleのSRE本や資料に書いてある形に合わせなければいけない」と考えてしまうことがあります。

もちろん、Google SREの考え方は非常に有用です。The Art of SLOsでも、SLI/SLOはサービスの信頼性を客観的に測定し、信頼性について意味のある会話をしやすくするためのものとして説明されています。
また、SLOとエラーバジェットを使い、データ駆動・客観的・ユーザー重視で信頼性を測定、管理する考え方が紹介されています。(Google SRE)

一方で、SREの本や資料に書かれている状態そのものを再現することがゴールではありません。

SREはあるソフトウェアエンジニアがシステム運用を任され、長い時間をかけて理想を形にした結果であり、SRE本の状態を目指すこと自体が真のゴールではないです。

そこでは、SREのプラクティスを自分たちなりに解釈し、組織やサービスと向き合い続けることで、その組織らしいSREが生まれます。これはSLI/SLOにもそのまま当てはまります。

SLI/SLOで大事なこと

SLI/SLOは、きれいな数値を作るためのものではありません。大事なのは、以下をチームで考え続けることです。

自分たちのサービスにとって、守るべきユーザー体験は何か

その体験が壊れていることを、どうすれば早く・客観的に気づけるか

どこまでの失敗は許容でき、どこからは改善を優先すべきか

たとえば、同じ「画像投稿サービス」でも、サービスの性質によって重視するSLOは変わります。

サービスの性質	重視するSLI/SLOの例
SNS	投稿成功率、タイムライン反映時間
業務報告アプリ	投稿内容の保存成功率、データ欠損なし
ECサイトの商品画像投稿	登録成功率、商品ページへの反映時間
災害・医療系の報告システム	送信成功率、通知到達率、遅延の少なさ

つまり、正解のSLOがどこかにあるのではなく、自分たちのサービス価値に合ったSLOを作ることが重要です。

ただし、好き勝手に決めてよいわけではない

「自分たちらしいSLO」とは、雑に決めるという意味ではありません。最低限、以下の型は守る必要があります。

User Journey
→ SLI Specification
→ SLI Implementation
→ SLO
→ 計測漏れ確認
→ 運用判断

たとえば、次のようなSLOは不十分です。

投稿機能を安定させる

これでは、何を測るのか分かりません。より良い形にすると、以下のようになります。

過去30日間において、有効な画像投稿リクエストの99.5%以上が5秒以内に成功する。

成功とは、POST /api/posts がHTTP 2xxを返し、投稿IDが生成され、画像保存が完了した状態とする。
HTTP 5xx、タイムアウト、DB書き込み失敗、画像保存失敗は失敗とする。

ただし、未ログイン、画像サイズ超過、不正なファイル形式、必須項目不足はサービス失敗から除外する。

型は守る。でも、何を守るかは自分たちのサービスから考える。このバランスが大切です。
SLI/SLOは、Googleのやり方をそのまま真似るためのものではありません。自分たちのサービス、自分たちのユーザー、自分たちの組織の状況に合わせて、信頼性を考えるための道具です。

完璧なSLOを最初から作る必要はないです。まずは重要なユーザージャーニーを1つ選び、そこから測れる形に落としていきましょう。

まとめ

SLI/SLOは、監視項目を増やすためのものではなく、ユーザーにとって重要な体験を守れているかを測るための考え方です。
大切なのは、サーバーやシステムの状態だけを見るのではなく、「ユーザーがやりたいことを達成できているか」を基準にすることです。
そのために、まず重要なユーザージャーニーを選び、何を成功とするか、どこで測るか、どの程度を目標にするかを決めます。

SLI/SLOを考えるときは、次の点に注意します。

ユーザー体験に近い指標を選ぶ
SLOを100%にしない
測定期間を決める
成功・失敗の定義を明確にする
残量だけでなく消費速度(Burn Rate)も見る
作って終わりにせず、運用判断に使う

また、SLI/SLOに絶対的な正解はありません。Google SREの考え方は参考にしつつも、自分たちのサービス・ユーザー・組織に合った形で考えることが重要です。
SLOを作ることがゴールではなく、SLOを使って、ユーザー体験と向き合い続けることがゴールです。

【概念編】SLI/SLOとは何か——ユーザー体験から信頼性を定義する

想定読者

この記事のゴール

はじめに

SLI / SLO / SLA / エラーバジェットの基本

SLIとは

SLOとは

SLAとは

エラーバジェットとは

Burn Rateとは

The Art of SLOs式:ユーザージャーニーからSLIを作る

Critical User Journeyとは

SLIを作る4ステップ

SLI SpecificationとSLI Implementation

SLI Specification

SLI Implementation

SLIの種類

例題:画像投稿SNSのSLI/SLOを作ってみる

Step 1: ユーザー期待を言語化する

Step 2: SLI Typeを選ぶ

Step 3: SLI Specificationを書く

Step 4: SLI Implementationに落とす

Step 5: SLOを書く

Step 6: 計測漏れを確認する

SLIの測定方法

よくあるアンチパターン

1. CPU使用率やメモリ使用率をSLIにする

2. SLOを100%にする

3. 測定期間がない

4. 成功・失敗の定義が曖昧

5. 重要でない機能まで全部SLO化する

6. ユーザージャーニーを分解しない

7. SLI Specificationのみ設定

8. 平均レスポンスタイムだけを見る

9. 作っただけで運用しない

まとめて直してみる

コラム1:パーセンタイルとは

平均値との違い

SLOでの使い方

コラム2:自分たちらしいSLOを作る

SLI/SLOで大事なこと

ただし、好き勝手に決めてよいわけではない

まとめ

関連記事

参考文献

Discussion