はじめに
SRE (Service Reliability Engineering) 部の村上です！
#2 から「監視・モニタリング」「インシデント対応」といった運用設計から 「SLO（SLI）」 の設計までのシナリオを辿ることで、SRE の世界観を掴む試みをしていました。
そして、前回 #3 の記事では、CUJ (Critical User Journey) と UJ (User Journey) という概念に基づいて、具体的な運用設計を行いました。
本記事ではこのシリーズの最終回として、この概念を更に SLO まで応用することで、SRE の主要素である「監視・モニタリング」「インシデント対応」「SLO（SLI）」を統一的に取り扱えるということを示していければと思います。
SLO に想いを馳せる
まず、SLO について考える前に、なぜ SLO が必要なのかを振り返ってみましょう。
#1 でお伝えした通り、「現場の運用をエンジニアリングする」だけでは SRE は完結しません。
ビジネスの要求に対して必要十分な信頼性を提供できるようにすることが SRE の目的です。
それでは、「現在、必要十分な信頼性を満たしているか否か」をどうやって判断すれば良いでしょうか？
ありがちなのは、
「この機能重要だけどなんとなくエラー多くない？」
「最近インシデント対応多いよね」
といった感覚的な判断です。
しかし、感覚的な判断は人によって異なりますし、時間が経つと忘れ去られてしまいます。
なので、できれば「定量的」に判断できる仕組みが欲しいですよね。
ですが、それには以下のような疑問が浮かびます:
- どの指標を使えば良いのか？
- その数値がどのくらいなら良いのか？
- これらをどう決めるか？
この疑問に対しては、
- 重要な機能についての信頼性を定量化し、指標とする
- 指標とビジネスインパクトの関係を分析し、閾値を設定する
というアプローチを取るのが良いと考えられます。
…なんか、どこかで聞いたようなアプローチですね。
そうです、#2 の「運用設計に想いを馳せる」でも重要な機能をビジネス視点で整理・特定し、運用設計を行いましたよね。
そして、その際に採用した概念が CUJ でした。
これを SLO に流用すれば一貫した視点が得られそうですし、検討や設計、実装も少なくて済みそうです。
つまり、CUJ をベースに SLO を設計すれば良いのです。
信頼性の定量化・可視化 〜SLI の設計〜
それでは、実際に信頼性を定量化していきましょう。
しかし、その定量化のためには測定を行う必要があります。
測定の仕組みを作るのは大変ですよね。やりたくない。
しかし、以前それっぽいものを作りませんでしたっけ？
ここで、#3 の記事で作った「監視・モニタリング」の仕組みが役に立ちます。
#3 の記事で、CUJ / UJ を使って「監視・モニタリング」を設計しました。
その際、CUJ に関連する何らかのログやメトリクスを作ったはずです。
そうです、この監視のために既に計測しているデータを、そのまま流用すれば良いのです。
つまり、CUJ をベースに設計を進めていれば、定量化に必要な計測基盤は監視・モニタリングの段階で既に整っているということになります。
新たに何かを作り込む必要はありません。
CUJ / UJというコンセプトを軸に、「インシデント対応」「監視・モニタリング」「SLO（SLI）」を1本の線で繋げられるというのがお分かりいただけたでしょうか。
そして、この信頼性を定量化した指標のことを SLI (Service Level Indicator) と呼びます。
SLI の具体例
それでは、具体的に SLI がどのように定義されるかを見ていきましょう。
例えば EC サイトで「購入手続きを完了する」という CUJ があった場合、今回のシナリオに従っていれば、運用設計時に以下のような「監視・モニタリング」の設計・実装を既に行っているはずです:
- 決済処理の成功/失敗を監視している
- エラーが発生したら SEV-High として通知される
そして、そのエラーの発生状況はログやメトリクスで計測されているはずで、そのデータを使って SLI を定義できます。
例えば、上記の CUJ に対する SLI は以下のように定義できます:
SLI = ある期間内での購入手続きの成功数 / ある期間内での購入手続きの総リクエスト数
そして、この SLI が 99.8% であれば「ある期間内で1,000回中998回は成功している」ということになります。
閾値の設定 〜SLOの設計〜
SLI が決まったら、次は「目標値をいくつにするか」を決める必要があります。
SLI はあくまで「指標」であり、それ単体では良し悪しの判断ができません。
そこで、SLI に対して「あるウィンドウ期間で集計した際にこの値以上を維持する」という目標を設定します。
この目標値のことを SLO (Service Level Objective) と呼びます。
それでは、この目標値をどう決めれば良いでしょうか？
「とりあえず 99.9% にしておこう」としたくなる気持ちは分かります。
しかし、根拠のない数値は、いざという時に「本当にこれで良いのか？」という疑問を生んでしまいます。
あるいは、初期的には経験則で決定されても問題ありませんが、やや説得力に欠けます。
そこで、ここでも CUJ のビジネスインパクトを起点に考えましょう。
#3 の記事で、運用体制を設計する際に「CUJ が止まるとどれくらいの影響があるか」を試算しました。
この試算を SLO の閾値設定にも応用できます。
具体的には、以下のステップで進めます:
- 許容できる損失（金額や KPI への影響）を決める
- 例: 月間で売上の 0.1% までの機会損失は許容できる
- その損失に相当するエラー率やダウンタイムを逆算する
- 例: 0.1% の機会損失 ≒ 月間約43分のダウンタイム ≒ 99.9% の可用性
- これを SLO として設定する
- 例: SLO = 99.9%
このように、ビジネスインパクトから逆算することで、根拠のある閾値を設定できるわけです。
もちろん、全ての CUJ について精緻な金額試算ができるわけではありません。
その場合は、KPI への影響度合いや、ユーザー体験への影響を定性的に評価して決めることになります。
重要なのは、「この数値にした根拠は何か」を説明できることです。
さて、この設定した閾値をどう活用するべきでしょうか？
一番シンプルなのは、閾値を割り込んだら「新規機能開発を停止する」という考え方です。
上記の例「購入手続きを完了する」が目標を達成できていなかったら、非常にまずそうですよね。
ビジネスインパクトに則って計算されていれば尚更で、新規機能開発を停止させることは合理的です。
一方で、プロダクトの要求される信頼性によってはそこまで強いアプローチを取る必要がないかもしれません。
あるいは閾値までの割合でグラデーションで行動を変えるということもできます。
そしてこれらは、エラーバジェット（Error Budget）という考えに繋がっていきます。
まとめ
本記事では、CUJ / UJ という概念を SLO にも適用できることを示しました。
CUJ / UJ という概念から運用設計を済ませておけば、SLO 設計においては新たに何かを作り込む必要がなく、既存の監視・モニタリング基盤をそのまま流用できる点がこのアプローチの優れた点だと思います。
最後に、このシリーズの内容を振り返ってみましょう:
- #1: SRE とは何か
- SRE は「インフラ屋」ではなく、「組織が適切なレベルの信頼性を持続的に達成できるよう支援するための工学」
- 運用をエンジニアリングするところから始まり、ビジネスを意識した定義へ拡張された
- 「合意」と「継続性」が重要
- #2: CUJ / UJ の導入
- 運用設計のコンセプトとして、ビジネス視点で「機能」と「その機能の重要性」を整理し、その整理をベースに設計する
- UJ (User Journey): ユーザーがサービスを利用する際の体験の流れ
「ユーザーがそのサービスで達成・到達したいゴール」と捉えるのが簡単 - CUJ (Critical User Journey): UJ の中でも特にビジネス上重要なもの
- #3: CUJ / UJ を使った運用設計
- 運用体制: CUJ のビジネスインパクトを起点に設計
- インシデントレベル: CUJ / UJ への影響度合いで決定されるものと定義する
- 通知・エスカレーション: インシデントレベルに応じた濃淡をつける
- #4: CUJ / UJ を使った SLO 設計（本記事）
- SLI: 通知の実装でで既に CUJ に対しての計測が実装されているため、そのデータを流用して定義可能
- SLO: 損失金額や KPI への影響度合いをベースに閾値を決定
このように、CUJ / UJ というビジネスを考慮した概念を採用することで、「監視・モニタリング」「インシデント対応」といった現場の運用から、「SLO」といったビジネス判断までを統一的に扱うことができます。
これによって、運用から、開発から、企画、経営、そしてユーザーまでを1本の線で繋げることができるということを、このシリーズを通じて感じられたのではないでしょうか。
SRE は、このような横断的な視点でシステムやビジネス、そして組織を捉え、ユーザーへ適切な信頼性を提供し続けているというところに意義があるのだと考えています。