構想の終わりと設計の始まり
こんにちは、SRE (Service Reliability Engineering) の多田です。
この記事は「ゼロから始める SLO 設計」という連載の初回になります。
SLO をゼロから設計する機会を得たことをきっかけに、そのプロセスを実務に即した連載形式で記録していこうと思います。
この記事では、プロダクト参画前の構想フェーズで、「自分は何を考えたのか」「どうやって設計の軸をつくったのか」についてまとめています。
SLO をゼロからやるということ
私は紆余曲折はあったのですが、SRE として活動し始めて 1 年強位になります。
これまでいくつかのプロダクトで SLO に関わってきましたが、それはいずれも「途中から」の参加でした。設計が済んだあとの運用や改善が主で、ゼロから SLO を設計するという経験はありませんでした。
そして今回、自分が向き合うのは CREATIVE BLOOM PLANNING（CBP）という社内プロダクトになります。
SRE としての関与は今回が初めてで、SLO の文化もまだ根付いていないプロダクトになります。
なぜ構想フェーズを書き残そうと思ったか
私は SLO 設計を「ゼロから」始めるのは今回が初めてになります。
だからこそ、参画前の段階で “何を考えたのか／どう構想を立てたのか“ を整理しておくことが大切だと考えました。
あとで見返したとき、現実とのギャップを捉えるためにも、最初の思考の軌跡は残しておくべきだと思いました。
また、この記事は自分自身の構想の整理であると同時に、同じように SLO をこれからやる人にとって、足がかりになればという思いも込めています。
われわれの SRE はこういうことを考え、実務としてこういうステップで動いている──そんな視点で、実践的な記録として残していければと思います。
構想した SLO 設計のステップ
まず、SLO が初めてという方もいるかもしれないので用語について整理しておきましょう。
- CUJ
Critical User Journey。ユーザーがサービス内で達成すべき重要な操作の流れ。SLO 設計では、守るべき体験の単位として使われる。
例：予約完了まで、投稿完了まで - SLI
Service Level Indicator。SLO を定量的に評価するための指標。
例：リクエスト成功率、レイテンシー - SLO
Service Level Objective。ユーザー体験の信頼性を測るための目標値。SRE の活動方針を決める基準になる。
例：成功率 99.9% - Error Budget
許容される失敗の余地。改善やリリース判断に活用される。
例：月に 0.1% の失敗は OK - Burn Rate
エラーバジェット（許容された失敗枠）をどれだけ速く使い切っているかを示す指標。
Burn Rate＝1.0 で計画通り、2.0 なら倍速で消費。
そして、まずは「そもそも SLO 設計とはどういうプロセスか」を自分なりに整理しました。
その結果、以下のような構成に着地しました。
参画
- プロダクト理解（KPI、ユースケース、チーム構成、アーキテクチャなど）
- ユースケース整理
設計
- CUJ 選定
- SLI の論理設計（守るべき体験は何か）
- SLI の物理設計（どこでどう計測するか）
- Datadog 連携設計（タグ設計、ログ構造、メトリクス設計）
- 仮 SLO の定義と検証
実装と運用設計
- SLI 実装
- SLO ダッシュボード構築
- エラーバジェットポリシー策定
- Burn Rate 設計とアラート整備
- 運用開始と継続的改善
こうして段階に分けて構想を整理しておくことで、「どこから始めるべきか」「何が先に決まっていないと詰まるか」が明確になり、設計の道筋が自分のなかに見えたのは大きかったです。
書き出した問いと考察の深まり
ステップを見出したあと、自分が疑問に感じたこと・判断が分かれそうなことを洗い出していきました。
この問い出しの時間が、結果として一番思考が深まったフェーズだったと感じます。
たとえば──
設計・設計順序に関すること
- SLO はいつ定めるべきか？ SLI の実装前？計測後？
- CUJ をどう選ぶか？KPI に直結するものだけでよいのか？
- SLI の論理設計と物理設計のズレをどう扱うか？
SLI・データ収集・可視化
- フィードバックログ（Good/Bad）は SLI に使えるのか？
- Datadog へのログ送信・タグ設計はどの粒度で設計すべきか？
- Burn Rate の設計は初期に必要か？運用を見てからか？
目的意識・ビジネスとの接続
- SLO と KPI はどう関係するのか？
KPI と SLO の関係
この最後の問いは特に、SLO を何のために設計するかという目的意識そのものに関わるものでした。
実はこの問い、以前 SRE チーム内でも話題に上ったことがあります。
「SLO って KPI になり得るの？」「SLO と KPI って直結させられるの？」という議論です。
当時は明確な答えは出ませんでしたが、今回あらためて構想フェーズに向き合う中で、ようやく自分なりの整理ができたように思います。
結論としては、
SLO は KPI には “なり得ない” し、“直結しない”。
ただし、KPI とは切っても切り離せない密接な関係にあります。
KPI が「どれだけ価値があったか／使われたか」を測るのに対し、
SLO は「その価値が “正しく提供されたか”」を担保します。
SLO は KPI の前提条件であり、信頼性という土台を測るものです。
CBP でも、たとえば「生成できる」「遅延がない」「結果が消えない」といった体験に問題があれば、それはユーザー体験に直接影響し、中長期的には KPI にも悪影響を及ぼしかねません。
たとえば「AI で案出しをしてから、画像生成 → 提案資料出力までを一気通貫で進める」
このような “実行されるべきクリエイティブフロー” が、CBP の核になる CUJ になり得えます。
そうした、KPI に強く関与する重要な体験を CUJ として定義し、SLI で観測し、SLO で保証する。
それにより、ユーザーが「安心して使える」状態を数値として担保していく。
それが SRE として、このフェーズで担うべき役割だと再認識しました。
SLO は KPI の “代替” ではなく、“土台” であり、KPI の失速を真っ先に気づかせてくれるセンサーのようなものかもしれません。
このあたりの整理は現時点での自分なりの捉え方ですが、チームとも対話を重ねながら、引き続き深めていければと思っています。
構想フェーズの思考トピック
構想フェーズでは本当に多くのことを考えましたが、ここでは一例として印象に残っている 3 つほど紹介します。
SLO はいつ定める？仮定義から正式化へ
最初に悩んだのが、“SLO はいつ定めるべきか？“ という問いでした。
定めないと SLI も設計しにくいが、実測してみないと実態がわからないというジレンマがあります。
このため、自分の中では「仮 SLO → 検証 → 昇格」という段階を意識するようにしました。
初期段階では、過去データの分析や PoC などから “現実的に満たせそうな範囲” で仮の SLO を定め、Datadog で収集・可視化しながら妥当性を検証し、正式な SLO に昇格していくイメージです。
SLI の論理設計と物理設計のギャップ
SLI についても、構想してみると二層に分かれると感じました。
1 つは「どんな体験を守るか」というビジネス視点での論理設計。
もう 1 つは「どこでどう計測するか」という技術的な物理設計。
この間にはギャップがあり、理想だけでは計測できないこともあるかと思います。
たとえば CloudFront や ALB では計測粒度が足りないこと、ECS 側でしか取れないレイテンシーがあることなど。
計測手段の現実と、設計意図のバランスをどう取るかは、初期から意識しておくべき重要な視点だと思います。
CUJ と SLI のバランス──どこまで細かく設計するか？
SLO 設計では、「どの CUJ にどれだけ SLI をつけるか」も難しいポイントです。
CUJ を細かくしすぎると管理が煩雑になり、SLI の設計・運用コストも跳ね上がります。
かといって粗すぎると、重要な体験を取りこぼすことになりそうです。
「CUJ 1 つに SLI は多くて 2〜3 つ」が目安だが、それでも CUJ が多すぎれば設計や運用の負担は増えます。
さらに、CUJ の優先順位付けを誤ると、本当に守るべき体験ではないものにリソースを割いてしまうリスクもあります。
自分としてはまず「KPI に強く関与するもの」「ユーザーにとってクリティカルなもの」だけに絞って CUJ を定義し、他は SLO とは切り離して監視として扱うようなバランス設計を想定しています。
最後に
この記事は、まだプロダクトにも入っておらず、ダッシュボードも何一つ作られていない段階での記録です。
けれど、自分にとってはこのフェーズがとても活きるのではと感じています。
構想フェーズで一番得られたものは、「信頼性をどう定義するか」に対する視座でした。
自分たちのプロダクトにとって、何が壊れたら致命的か、何が守られるべきか。
それを問うこと自体が、もうすでに “SLO の第一歩“ だったのではないでしょうか。
そして同じように SLO を始める人たちにとっても、「どう構想し、どう考えて動き始めたか」という実例のひとつになればうれしいです。
SLO は単なる指標ではなく、「どんな信頼性を私たちは提供したいのか」を言語化する営みそのものです。
その中で、構想フェーズで描いた思考がどう活きていくのかを追っていきます。
次回からは、いよいよプロダクトに参画し、設計フェーズに踏み出していく予定です。
次回の記事 → ゼロから始める SLO 設計 #2