- はじめに
- この記事を読むことで得られること
- CUJと信頼性スタック
- SLOの設定
- シナリオに沿ったSLO設定方法
- エラーバジェットの考え方
- で、結局何をしたらいいのよ？
- 参考書籍と各社事例紹介
- 最後に
はじめに
こんにちは。ACS事業部谷合です。
今回はサービスレベル目標（以降SLO）について、紐解いていきます。
各社の事例や実践的な記事は検索すると沢山できますので、今回はSLOとは？から社内普及するまでのプラクティスをSLOの導入をしていない場合を対象にご紹介します。
また、今回は参考書籍や、より実践的な取り組みはこのブログの最後にご紹介しております。
なお、こちらが直近でこのイベントが開催されるとのことで各社の取り組みを覗ける機会ですので、個人的に非常に楽しみにしています。
この記事を読むことで得られること
- CUJと信頼性スタック（SLI/SLO）の考え方
- シナリオに沿ったSLOの設定例
- エラーバジェットの考え方とアラートの設定
- ステークホルダの存在と、SLOを導入する際の連携
- SLO定義テンプレートの理解
CUJと信頼性スタック
まずはSLOに関する各用語を理解しましょう。
CUJ（クリティカルユーザジャーニー：Critical User Journey）
Critical User Journeyの頭文字をとった用語となります。
ユーザがサービス上で行う操作の内、特に重要なものです。
例えば、サイトへログイン→記事の検索→記事の閲覧 などです。
このCUJを基に、SLIを実装します。
SLI（サービスレベル指標：Service Level Indicator）
Service Level Indicatorの頭文字をとった用語となります。
CUJの元にした、「良いイベント」を数値化したものです。
例えば、レスポンスタイム、正常な戻り値（ステータスコード）、スループットなどあります。
項目ごとに評価内容のSLIを定義するとよいでしょう。
項目はSLO定義テンプレートでご紹介します。
SLO（サービスレベル目標：Service Level Objective）
Service Level Objectiveの頭文字をとった用語となります。
SLIで定義したものの内、どのくらいの割合でユーザに提供できるか を定義したものです。
例えば、過去30日間のレスポンスのP99が、2xxまたは3xxのステータスコードを返す などがあります。
なお、SLOはSLAと混同されることがありますが、似て非なるものです。
SLAはサービスレベルを公表し、それに基づくサービスを提供する契約です。
契約というためサービスレベルの低下は法の下で、賠償の責任なども伴います。
一方SLOは公表の義務はなく、信頼性における目標値を内部で定めたものとなります。
とはいっても、内部で信頼性といっても、信頼性が高い状態を決めるのはユーザなので、ユーザからのクレームや
ご意見などはSLOに跳ねてくると思ってもいいでしょう。
エラーバジェット
開発と運用のバランスを取るための考え方です。
開発チームはは絶えず新規機能を実装してリリースしたい、運用はサービスの安定稼働のために変更を可能な限り加えられたくないと思うものです。
双方バランスを取るために、SLOを満たている場合は、リリースができるようにします。
一方エラーバジェットを使い切った場合はリリースを止めて、改善に当たります。
SLOの設定
SLOは ビジネス状況の定義 -> SLIの定義 -> CUJの定義 -> SLIの実装 -> SLOの決定 の順で定義します。
SLOの設定までを順を追ってみていきましょう。
ビジネス状況の定義
まず、CUJの定義から、SLIの定義、実装に移りたいと思うかもしれませんが、まず自社のビジネスの状況を正確に把握する必要があります。
この時、以下のように定義すればよいでしょう。
- 毎日yyy回のアクセスがある
- 毎月xxxユーザの増加がある
SLIの定義
ビジネス状況の定義を基にSLIを定義します。
上記の場合のは以下のようになるでしょう。
| No | SLI項目 | 評価内容 |
|---|---|---|
| 1 | リクエスト、レスポンス | 可用性、レイテンシ |
| 2 | ストレージ | 耐久性、障害復旧時間（MTTR） |
1の場合は、アクセスを常時受け付ける可用性と、転送スピードの指標であるレイテンシを評価すればよさそうです。
2の場合は、ユーザ登録のための、DBやストレージに対しての耐久性やMTTRを評価すればよさそうですね。
CUJの定義
CUJとは前述した通り、ユーザがサービス上で行う操作の内、特に重要なものであり、例えば、サイトへログイン→記事の検索→記事の閲覧 などです。
自社のサービスに合わせて、定義しましょう。この時、SREだけでなく、開発チームも巻き込むと、より正確なCUJが定義できます。
SLIの実装
このフェーズでは、SLIをどのように計測するかを決定します。
ただ、計測する際は最小の計測に留めたいですよね。
今回の場合は、CUJを、サイトへログイン→記事の検索→記事の閲覧 とすると、SLI定義1が当てはまりそうですね。
更に、SLI定義1では以下の項目を計測する必要がありそうです。
- サービスは稼働できているか？
- サービスは使用可能か？
- レスポンスは十分な速度か？
- レスポンスは正しいデータを返すか？
このうち、実はすべてを計測する必要はありません。
4の「レスポンスは正しいデータを返すか？」を計測すれば、サービスは稼働できており使用可能と分かるので、1と2の計測は不要です。
3については、パフォーマンス観点で計測が必要ですが、今回の場合は、3と4を計測すればいいことになります。
計測を行うツールは、TSDBやログ解析ツールがありますが、昨今であれば優れたObservabilityツールがあり、どちらの機能も実装されているのがほとんどです。
そのため、自社で利用しているツールを用いて、各種 xQLなどで計測に利用可能なデータをSLIとして実装しましょう。
SLOの決定
いよいよSLOを決定します。
SLOは、ビジネス状況やSLIの定義に基づいて行います。
また、SLOは目標と計測期間を含めて定義します。
例えば、過去30日間のレスポンスのP99（99パーセンタイル）が、2xxまたは3xxのステータスコードを返す などがあります。
この場合、P99のレスポンスが2xxまたは3xxであることを保証することがSLOとなります。
このSLOを選択することで、ユーザに対して、サービスが安定していることを保証することができます。
さらにSLOには、以下のルールのもと、定義するといいでしょう。
厳しい目標を設定しない
- 達成可能で現実的な目標を設定する
- チームのモチベーションを維持できる水準を考慮する
最初から完璧を目指さない
- 段階的な改善を計画する
- 小さな成功を積み重ねる方式を採用する
計測期間は、1ヶ月から3ヶ月程度が望ましい
- 期間終了後にレビューと見直しを行う
- 必要に応じて柔軟に調整する
可能な限りシンプルに分かりやすく
- 具体的な数値目標を設定する
- 全てのステークホルダーが理解できる指標を使用する
現行のパフォーマンスに基づいてターゲットを設定しない
- ユーザー体験を基準に目標を設定する
- ビジネス目標との整合性を確保する
定期的なモニタリングと報告を実施する
- 進捗状況を可視化する
- 問題の早期発見と対応を可能にする
ここでいう厳しい目標を設定しないというのは、達成可能で現実的な目標を設定するということです。
経営者目線やユーザ目線からしたら、99%や99.9%よりかは100%を目指すのが望ましいと考えるでしょう。
しかし、この1%や0.1%を目指すために努力やコストが見合うのかは、ビジネス目標との整合性を確保することで判断できます。
以下の表は、可用性目標とそれに伴う日単位の停止時間を示しています。
この表を参考に、自社のビジネス目標との整合性を確保しながら、SLOを設定しましょう。
| 可用性目標 (%) | 日単位の停止時間 | 週単位の停止時間 | 月単位の停止時間 | 年単位の停止時間 |
|---|---|---|---|---|
| 99.9% (3-nines) | 1.44分 | 10.08分 | 43.8分 | 8.76時間 |
| 99.95% | 43.2秒 | 5.04分 | 21.9分 | 4.38時間 |
| 99.99% (4-nines) | 8.64秒 | 1.01分 | 4.38分 | 52.56分 |
| 99.999% (5-nines) | 864ミリ秒 | 6.05秒 | 26.28秒 | 5.26分 |
| 99.9999% (6-nines) | 86.4ミリ秒 | 604.8ミリ秒 | 2.63秒 | 31.56秒 |
上記数値は以下のGoコードで算出可能です。
なお、計算の基準となる「1ヶ月」「1年」の定義の違いや、秒単位の丸め誤差で、他記事と若干の誤差が出る可能性があります。
可用性目標数値算出コード
package main import ( "fmt" "time" ) // 可用性目標と計算基準 var availabilityTargets = map[string]float64{ "99.9%": 99.9 / 100, "99.95%": 99.95 / 100, "99.99%": 99.99 / 100, "99.999%": 99.999 / 100, "99.9999%": 99.9999 / 100, } // 時間の単位 const ( secondsPerDay = 24 * 60 * 60 secondsPerWeek = 7 * secondsPerDay secondsPerMonth = 30.4375 * secondsPerDay // 平均的な月の日数 secondsPerYear = 365.25 * secondsPerDay // 平均的な年の日数 ) // 時間を適切な単位でフォーマットする関数 func formatDuration(seconds float64) string { if seconds < 1 { return fmt.Sprintf("%.2fミリ秒", seconds*1000) } else if seconds < 60 { return fmt.Sprintf("%.2f秒", seconds) } else { return fmt.Sprintf("%.2f分", seconds/60) } } func main() { // 結果を格納するスライス results := [][]string{} // 各可用性目標に対して計算 for label, availability := range availabilityTargets { downtimePerDay := (1 - availability) * secondsPerDay downtimePerWeek := (1 - availability) * secondsPerWeek downtimePerMonth := (1 - availability) * secondsPerMonth downtimePerYear := (1 - availability) * secondsPerYear // 結果を追加 results = append(results, []string{ label, formatDuration(downtimePerDay), formatDuration(downtimePerWeek), formatDuration(downtimePerMonth), formatDuration(downtimePerYear), }) } // 結果を表示 fmt.Printf("%-10s %-15s %-15s %-15s %-15s\n", "可用性目標 (%)", "日単位の停止時間", "週単位の停止時間", "月単位の停止時間", "年単位の停止時間") fmt.Println(strings.Repeat("-", 80)) for _, row := range results { fmt.Printf("%-10s %-15s %-15s %-15s %-15s\n", row[0], row[1], row[2], row[3], row[4]) } }
シナリオに沿ったSLO設定方法
ここまでSLOの設定方法を順を追って、説明しました。
次からは、ユーザ公開をするWebシステム（動画公開サイト）と、外部公開しない社内システムを取り上げ、それぞれSLOを設定する例をご紹介します。
1. ビジネス状況の定義 まず、CUJの定義やSLIの定義に移る前に、動画配信サービスのビジネス状況を正確に把握する必要があります。
以下のように定義できます。 このような動画配信サービスでは、
「ユーザがスムーズに動画を視聴できること」 が最も重要なビジネス要件になります。 2. SLIの定義 ビジネス状況の定義を基に、適切なSLIを選定します。
以下のSLIを定義することで、ユーザ体験とシステムの安定性を監視できます。 3. CUJの定義 CUJ（クリティカル・ユーザ・ジャーニー）とは、
ユーザがサービス上で行う特に重要な操作です。 本システムの主要なCUJは以下のとおりです。 このCUJをもとに、SLIとの関連を整理します。 4. SLIの実装 SLIをどのように計測するかを決定します。 5. SLOの決定 SLOは 目標と計測期間 を定義します。 ユーザへ公開するWebシステム（動画公開サイト）のSLO定義シナリオ
No
SLI項目
評価内容
1
可用性
動画が正常に再生開始できる割合（HTTP 2xx 成功率）
2
バッファリング率
動画視聴中にバッファリングが発生する割合
3
レイテンシ
P99の動画再生開始時間（スタートアップレイテンシ）
4
画質の安定性
視聴中に自動で解像度が低下した回数（ビットレートスイッチング）
5
エラー率
5xxエラーの発生率
6
MTTR（平均復旧時間）
システム障害時の復旧時間
CUJ
関連するSLI
影響
サイトへログイン
可用性、レイテンシ、エラー率
ログインできないと、サービス利用不可
動画の検索・選択
可用性、レイテンシ、エラー率
検索が遅いと、コンテンツ探索が困難
動画の再生開始
可用性、レイテンシ、エラー率
再生が遅れると、UXが低下
視聴中のスムーズな再生
可用性、バッファリング率、画質の安定性
バッファリングが多いと、離脱率が増加
視聴完了とレコメンド
可用性、レイテンシ、データ整合性
視聴後の流れが悪いと、次の視聴に影響
SLI
計測方法
可用性（HTTP 2xx成功率）
ログ解析、APM
バッファリング率
クライアントログ解析（ストリーミングプレイヤーのエラーログ）
レイテンシ（P99の動画再生開始時間）
動画プレイヤーのロード時間を計測
画質の安定性
CDNログ解析、ビットレート変化のモニタリング
エラー率（5xxエラー率）
ログ集計、APM
MTTR（障害復旧時間）
インシデント対応ログの解析、自動化ツール
指標
SLO
可用性
過去30日間のHTTP 2xx成功率が 99.9%以上 であること
バッファリング率
過去30日間の視聴中バッファリング率が 1%未満 であること
レイテンシ
過去30日間のP99の動画再生開始時間が 2秒以下 であること
画質の安定性
視聴中のビットレート変更率が 10%未満 であること
エラー率
過去30日間の5xxエラー率が 0.2%未満 であること
MTTR
障害発生時の平均復旧時間を 30分以内 に抑えること
1. ビジネス状況の定義 まず、CUJの定義やSLIの定義に移る前に、社内システムのビジネス状況を正確に把握する必要があります。
以下のように定義できます。 このような社内システムでは、 2. SLIの定義 3. CUJの定義 本システムの主要なCUJは以下のとおりです。 4. SLIの実装 5. SLOの決定 社内システムのSLO定義シナリオ
「業務がスムーズに遂行できること」 が最も重要なビジネス要件になります。
No
SLI項目
評価内容
1
可用性
システムが正常にリクエストを処理できる割合（HTTP 2xx 成功率）
2
レイテンシ
P99のレスポンス時間
3
エラー率
5xxエラーの発生率
4
データ整合性
データの正確性、欠損・重複チェック
5
MTTR（平均復旧時間）
システム障害時の復旧時間
CUJ
関連するSLI
影響
勤怠打刻の記録
可用性、レイテンシ、エラー率
遅延や障害が発生すると、勤務実績に影響し給与計算ミスの原因となる。
経費申請・承認
可用性、レイテンシ、エラー率
承認フローが止まると、経費精算の遅延が発生する。
顧客情報の更新（CRM）
可用性、レイテンシ、データ整合性
データ更新に遅延や不整合が生じると、営業活動に影響を与える。
在庫管理・発注
可用性、レイテンシ、データ整合性
データの遅延や誤登録が発生すると、欠品や過剰発注につながる。
バッチ処理の実行（給与計算・データ集計）
データ整合性、MTTR
定期処理が失敗すると、給与計算やレポート作成が遅れる。
SLI
計測方法
可用性（HTTP 2xx成功率）
ログ解析、APM
レイテンシ（P99レスポンス時間）
ログベースのメトリクス、APM
エラー率（5xxエラー率）
ログ集計、APM
データ整合性
SQLクエリによるデータ整合性チェック、異常データ監視
MTTR（障害復旧時間）
インシデント対応ログの解析、自動化ツール
指標
SLO
可用性
過去30日間のHTTP 2xx成功率が 99.95%以上 であること
レイテンシ
過去30日間のP99レスポンス時間が 800ms以下 であること
エラー率
過去30日間の5xxエラー率が 0.1%未満 であること
データ整合性
データ不整合率が 0.01%未満 であること
MTTR（障害復旧時間）
障害発生時の平均復旧時間を 30分以内 に抑えること
エラーバジェットの考え方
SLOを設定して終わりではありません。
エラーバジェットを設定することで、開発と運用のバランスを取ることができます。
エラーバジェットが枯渇した場合は、リリースを止めて、改善に当たるなどの使い方をします。
また、エラーバジェット枯渇によりリリースを止める決断をすると前述しましたが、実際にはエラーバジェットの枯渇によるリリース停止は、
多くはありません。例えば、深刻なバグが発生してそれのBugfixのリリースを止めるべきでしょうか？ビジネスに取って革新的な新機能のリリースを止めるべきでしょうか？
あくまでもパフォーマンスを改善する優先度の指標としての使ってもよいと考えます。
しかしながら、深刻なパフォーマンス劣化が発生しており、信頼性が脅かされている場合はどうでしょうか？
その場合は、エラーバジェットを枯渇させることで、リリースを止めてでも改善に当たることを推奨します。
ビジネスとのバランスを取ることで、よりよいサービスを提供することができるため、時には新規リリースの止める決断も必要であり、
この部分は後述する経営層に納得して貰う必要があります。
ただ、誤解してほしくないのは、すべてのリリースを止める というわけではありません。
パフォーマンス劣化で信頼性の低下を招いている部分のリリースのみを停止することで、ビジネスに取って重要な機能を維持することができます。
その他のリリースは今まで通り行い、パイプラインを止めずにユーザ満足度向上に当たればよいでしょう。
次にエラーバジェットの計測方法を解説します。
エラーバジェットの計測方法は、時間ベースとイベントベースの2種類があります。
どちらを選択しても構いませんが、計算方法としては時間ベースの方が複雑です。
しかし、ステークホルダに報告する際は、「後、n%のエラーバジェットがある」というよりも、「後、n分のエラーバジェットがある」という方が現在の状況を定量的に伝えることができるようになります。
なお、SLO本では、レイテンシの計測といった概念については、イベントベースの方が分かりやすいと紹介しています。
一方、時間ベースでは、可用性やデータ処理など時間に対してパフォーマンスを計測するものに有用です。
アプローチ
イベントベース
イベントベースでは、全体のイベント件数に対して、失敗したイベントの割合を計算します。
例えば、先月は合計で、20,000,000件の観測をしており、期間内で36,513件の失敗があった場合は、以下のように計算します。
イベントペースは、レイテンシの計測といった概念については有用であると前述しました。
これは、レイテンシの問題は、全イベントの「悪い」イベントとして露呈してくるからです。
例えば、20,000,00件のリクエストがあったとして、そのうち350件はレイテンシが10秒かかったとします。
この場合、レイテンシが10秒かかったリクエストは、350 / 20,000,000 = 0.0000175 = 0.00175% です。
というように、イベントの件数でエラーバジェットを計算できます。
時間ベース
時間ベースでは、以下のように計算します。
計測ウインドウを決めます。
エラーバジェットポリシー
エラーバジェットポリシーは、エラーバジェットの消費に対する対応ポリシーを定義します。
例えば、エラーバジェットの消費が多い場合はどのような対応をするか、消費は少ないが消費比率が高い場合はどうするかなどを定義します。
エラーバジェット消費ポリシー
「エラーバジェットが30%消費したら、チームの2人が作業を中断して、改善に当たる。」などを定義します。
さらに、「エラーバジェットが50%消費したら、チームの4人が作業を中断して、改善に当たる。」なども定義して、段階的に対応します。
なお、ポリシー定義には、must, mey, should、needの観点で記載するとよいでしょう。
エラーバジェット超過ポリシー
エラーバジェットが枯渇した場合は、どのような対応をするかを定義します。
消費ポリシーと同様のポリシーとなりがちですが、枯渇した場合は、どのような対応をするかを 強制力をもつ アクションを定義します。
この時、must, shouldで定義しますが、その時のビジネス状況を考慮してとれるようアクションに柔軟性を持って定義するとようでしょう。つまり枯渇時に、ビジネスに重要な新機能やBugfixのリリースと、信頼性を天秤に掛けて最良のアクションの決定や、議論ができるようなポリシーを定義するとよいでしょう。
Alertを出そう
「メトリクスでなく、SLOで出そう！」以上！ としたいですが、そうもいかないので、しっかり解説します。
上記のようにメトリクスでなく、SLOで出そうと書いた背景にはAlertでの疲弊と、不要なAlertによるノイズの発生を防ぐためです。
例えば、CPUが、80%を超えたらAlertを出すとします。
この時、毎回トリアージまたは原因究明を強いる現場では勤務時間の大半をそれに費やすでしょう。
その結果、ビジネスに貢献できる時間が減少してしまいます。
なんなら、CPUが100%でも安定稼働しているなら、100点のチューニングという考えもありますよね。
そのため、メトリクスでなくSLOで出すことで、Alertの発生頻度を減らすことができます。
そこで、以下のエラーバジェットに沿ってAlertを出すとよいでしょう。
例えば、一定のエラーバジェットを消費したらや、枯渇する前、枯渇したらAlertを出すといいかと思います。
これを実現するのがバーンレートアラートです。
例えば、SLO の 30日間目標に対して、14.4 以上のバーンレートが測定された場合にアラートを設定できます。
| 許容可能なバジェット消費率 | 時間ウインドウ | 基準時間 | 計算式 | バーンレート | 評価 |
|---|---|---|---|---|---|
| 2% | 30日 | 1時間 | 0.02 × (30 × 24 / 1) = 0.02 × 720 |
14.4 | 🚨 非常に危険 |
| 5% | 30日 | 6時間 | 0.05 × (30 × 24 / 6) = 0.05 × 120 |
6.0 | ⚠️ 警戒レベル |
| 10% | 30日 | 3日 | 0.10 × (30 / 3) = 0.10 × 10 |
1.0 | 🟢 安全 |
計算結果の解釈は以下の通りです。
- 2% の 30日 / 1時間 → バーンレート 14.4
- 非常に速い消費（14.4倍の速度でエラーバジェットを消費）
- すぐにSLO違反のリスク 🚨
- 5% の 30日 / 6時間 → バーンレート 6
- かなり速い消費（6倍の速度）
- 警戒レベル、対応を検討すべき 🟠
- 10% の 30日 / 3日 → バーンレート 1
- SLO通りの消費（理想的なペース）
- 問題なし、安定している ✅
これに沿って、バーンレートの消費率でAlertを出すとよいでしょう。
で、結局何をしたらいいのよ？
ここまで、SLI/SLOについて説明してきました。
次に、社内でSLO文化を広めるためのポイントを解説します。
SLOを広めるためにステークホルダーの理解を得る
SLOを社内に広め、適切に運用するためには、関係するステークホルダーの理解を得ることが不可欠です。
各ステークホルダーの役割や関心に応じたアプローチをとることで、スムーズな導入と定着が可能になります。
まず、自社におけるステークホルダーの洗い出しを行いましょう。
以下に代表的なステークホルダーを挙げますが、これがすべてではないため、組織ごとに適切な対象を特定することが重要です。
一度の説明で全員の同意を得ることが難しい場合もあります。その際は、複数回の説明機会を設けるなど、継続的な対話を通じて理解を深めていきましょう。
主なステークホルダーとその対応ポイント
経営幹部
経営幹部にSLOの重要性を理解してもらうためには、以下のポイントを押さえることが重要です。
ビジネスのスピードに関与
- 経営幹部は、組織の戦略やリリーススピードの方向性を決定する権限を持っています。
- そのため、SLOの導入が新規リリースの速度向上につながることを示す必要があります。
定量的なデータを活用
- SLOのバーンレートを適切に管理することで、信頼性の向上を図れることを説明します。
- 例えば、障害による損失や、SLOを適用した場合の改善効果などを数値で示すと説得力が増します。
上位役職者を巻き込む
- 経営会議などの場で、データを用いたプレゼンテーションを行い、SLOの導入が経営にとって有益であることを伝えましょう。
開発者
開発者にSLOの理解を促すためには、以下のポイントを押さえましょう。
SLO導入の意義を共有
- 開発者にとってSLOは新しい概念であり、特に初期段階では抵抗感を持たれることがあります。
- 信頼性を向上させることで、結果的に開発スピードが向上し、チームの負担を軽減できることを説明します。
エラーバジェットポリシーのバランス
- SLOを適用すると、場合によってはリリースが一時的に停止されることがあります。
- これは開発者にとって不都合に感じるかもしれませんが、エラーバジェットポリシーを活用することで、信頼性とリリースのバランスを取れることを強調しましょう。
実際の適用方法を明確にする
- SLOを日々の開発プロセスにどう組み込むかを具体的に示すことが重要です。
- 例えば、SLOのモニタリング方法や、SLO違反時の対応フローなどを明確にし、実践しやすい環境を作りましょう。
SLOを広めていこう
SLOを社内に浸透させるには 時間と工夫が必要 です。
SREが「SLOを導入します！」と宣言しただけでは、多くのチームがその意義を理解せず、なかなか定着しません。
信頼性向上の文化を根付かせるには、 根気強い説明と継続的な取り組み が不可欠です。
特に、最初の段階では抵抗や誤解が生じることが多いため、粘り強く説明し、少しずつ組織に浸透させていきましょう。
以下のポイントを意識することで、SLOを円滑に導入し、組織全体に定着させることができます。
1. ステークホルダーの同意を得る
SLOの導入には、経営層、開発チーム、運用チーム、ビジネスチームなど、多くの関係者の理解と協力が必要です。
しかし、彼らの関心はそれぞれ異なり、SLOが どのような価値をもたらすのか を適切に説明しなければ、単なる負担と捉えられる可能性があります。
✅ ポイント
- 経営層: 信頼性の向上がビジネス成果に直結することを示す
- 開発チーム: SLOが過度な負担にならないようにしつつ、運用負荷を減らせることを説明する
一度の説明で理解を得られるとは限らないため、定期的に対話の機会を設け、徐々にSLOの価値を伝えていくことが重要です。
2. 明確なSLOを定義する
SLOは抽象的な理想論ではなく、具体的で測定可能な目標でなければなりません。
「サービスの信頼性を向上させる」という曖昧な目的ではなく、 何をどの程度のレベルで維持するのか を明確にする必要があります。
✅ ポイント
- ユーザー視点を重視: 技術的な指標だけでなく、ユーザー体験に直結するSLI（サービスレベル指標）を基にする
- ビジネスと整合性を取る: 可用性99.999%のような極端な目標ではなく、事業のコストと利益のバランスを考慮した現実的な数値を設定する
- 測定可能にする: 実際にデータを取得できる方法を考え、ツールを活用する
SLOがあいまいだと、運用するうえで混乱を招きやすく、チームの負担が増える要因になります。
シンプルかつ実践的な指標を定め、チームが納得できる形で運用できるようにしましょう。
3. SLOを活用した運用を確立する
SLOは設定するだけでは意味がなく、日々の運用の中で活用する仕組み を整えることが重要です。
具体的には、SLO違反が発生した際の対応ルールや、エラーバジェットの管理方法を明確にする必要があります。
✅ ポイント
- エラーバジェットを活用: 許容されるエラー範囲を定め、開発と運用のバランスを取る
- アラート設定: 単なるメトリクスではなく、SLOの観点から重要な問題のみ通知する
- 定期レビュー: SLOの適用状況を振り返り、改善の余地があるかを確認する
SLOは運用の指針であり、単なるKPIではありません。
現場が 「SLOがあることで意思決定がしやすくなった」 と感じられる仕組みを作ることが成功の鍵となります。
4. SLOの反復と改善
SLOは 一度決めたら終わりではなく、継続的に見直すべきもの です。
ビジネス環境やシステムの変化に応じて、適切なSLOを維持できるよう、定期的な振り返りと改善が必要です。
✅ ポイント
- 短期間でのテスト運用: 初期段階では試験的にSLOを運用し、課題を洗い出す
- フィードバックを反映: 実際にSLOを利用する開発・運用チームの意見を定期的に収集し、現実に即したものに調整する
- ビジネス成長に応じた見直し: ユーザー数やトラフィックの増加に合わせて、より適切な目標を再設定する
また、SLOを導入する過程で発生する問題点をドキュメント化し、他のチームが同じ課題に直面したときに参考にできるようにする ことも有効です。
SLO定義テンプレートを活用しよう
SLOを適切に設計・運用するためには、一貫性のあるフォーマットで定義をまとめることが重要です。
ここでは、Architecture Decision Record (ADR) に似た形式 でSLOを整理するためのテンプレートを紹介します。
このテンプレートを活用し、明確な指標設定・運用ポリシー・改善フローを整備 することで、SLOを「形だけの目標」ではなく、実際に運用の意思決定に活かせるツール にしていきましょう。
1. SLOの基本情報
SLOの概要を整理し、関係者が容易に参照できるようにします。
✅ 記載項目
- ダッシュボードリンク: SLOのモニタリングツールのURL
- 定義日 / 更新日: 初回設定日と最新の更新日
- 責任者: SLOの管理責任を持つチームまたは担当者
2. サービス概要
SLOが適用されるサービスの概要を簡潔に説明します。
✅ 記載項目
- サービス名: [サービス名]
- 主要機能: [サービスの主要な役割や対象ユーザー]
- ビジネス価値: SLOがこのサービスの信頼性向上にどう貢献するか
📝 ポイント:
1〜2段落程度で、誰が読んでもサービスの目的とSLOの重要性が理解できる内容 にすることが理想です。
3. SLI（サービスレベル指標）とSLO（サービスレベル目標）
SLOの具体的な指標を定義し、どのように測定・評価するのかを整理します。
✅ 記載項目
| 指標名 | 測定対象 | SLIの定義 | SLOの目標値 | データ取得方法 |
|---|---|---|---|---|
| 可用性 | APIリクエスト | 成功リクエスト数 / 総リクエスト数 | 99.9%以上 | CloudWatch, Prometheus |
| レスポンスタイム | HTTPレスポンス | P99の応答時間 | 500ms以下 | Datadog, New Relic |
| エラーレート | APIリクエスト | 5xxレスポンス率 | 0.1%未満 | ELK Stack, Splunk |
📝 ポイント:
- 表形式 でまとめると、関係者が一目で理解しやすくなります。
- 測定可能で明確な目標値を設定 することが重要です。
4. SLI/SLOの選定理由
設定したSLIやSLOの背景を明記し、なぜその指標が選ばれたのかを説明します。
✅ 記載項目
- ユーザー体験との関連: 例）「応答時間が500msを超えると、コンバージョン率が低下するため」
- ビジネスインパクト: 例）「エラーレート0.1%超過でカスタマーサポートの問い合わせが急増する」
- 過去データの分析結果: 例）「過去6ヶ月の平均可用性を考慮し、99.9%を目標とする」
📝 ポイント:
SLI/SLOを決定する際に参考にしたデータやビジネス判断の根拠を明示することで、
「なぜこのSLOなのか？」という質問に対して明確な回答ができる ようにしておきます。
5. SLOの見直しスケジュール
SLOは一度決めたら終わりではなく、定期的に再評価し、改善していくことが重要 です。
✅ 推奨スケジュール
| 頻度 | 内容 |
|---|---|
| 月次レビュー | SLO違反の有無を確認し、改善点を検討 |
| 四半期レビュー | SLOの目標値や測定方法の適切性を評価 |
| 年次レビュー | ビジネス要件やシステム変更に応じたSLOの見直し |
📝 ポイント:
- 運用開始初期は頻繁にチェック し、安定したら長期スパンで評価
- 関係者との振り返りを定期的に実施 し、必要に応じてSLOを更新
6. エラーバジェットポリシー
エラーバジェットの消費ルールと、SLO違反時の対応方針を明確にします。
✅ 記載項目
| エラーバジェット消費率 | 対応アクション |
|---|---|
| 30%消費 | 軽微な改善を検討 |
| 50%消費 | 新機能リリースを一時停止し、改善を優先 |
| 100%消費 | リリースを完全停止し、信頼性向上に注力 |
📝 ポイント:
- エラーバジェットの消費状況を可視化し、関係者と共有 する
- 開発と運用のバランスをとるための指針 として活用する
参考書籍と各社事例紹介
本ブログは以下の書籍を参考にしています。 www.oreilly.co.jp
より実践的な取り組みは以下の3社様の事例が参考になるかと思います。
最後に
いかがでしたでしょうか？
SLOを定義することで、ビジネスとエンジニアのバランスを取ることができるようになります。
最初はとてもハードルが高く、難しいかと思いますが、是非自社組織に導入してみてください。
また、弊社でも人月でのSREのご支援を行っておりますので、SLOの導入を一緒に進めることも可能です。
是非お気軽にお問い合わせください。
また、ACS事業部のご紹介開発者ポータルBackstage、Azure AI Serviceなどを活用し、Platform Engineering＋AIの推進・内製化のご支援をしております。 www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
我々の事業部のCultureDeckはコチラ。
www.ap-com.co.jp
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
