🎯

SLI/SLOってなんだ？から始めた運用体験記

ムラ

2025/10/06に公開

 はじめに私は今年1月に入社し、2ヶ月後の3月にチームのSLI/SLOリードを任されました。

SLI/SLO自体は別チームであるSREチームによって既に設定されていましたが、それを実際に運用し、チーム内に浸透させていく役割を私が担うことになったのです。
普段はアプリケーションエンジニアとして開発業務を担当しており、特別にSREの専門知識があったわけではありません。正直に言えば、「SLI/SLOって何？」「SREってどんな役割？」という状態からのスタートでした。
本記事は、そんな私がSLI/SLOリードとして運用を推進してきた“体験記”です。

設定だけで放置されがちなSLOをどうチームに根付かせたのか、その取り組みと効果をまとめてみたいと思います。
キーワードは「初めは小さく、我慢強く、チーム開発に溶け込ませる」です。

 0. SLI/SLOとは？サービスの信頼性を高めるには、ユーザ体験を「数値」で捉えることが大切です。そのための概念がSLI/SLOです。

SLI（Service Level Indicator） とはサービスのパフォーマンスを測定する指標のことです。

SLO（Service Level Objective） とはSLIに基づいた、達成すべき目標値のことです。

文字だけでもわかりにくいですよね？
例として、快適なお風呂を想像してください。

快適なお風呂が何かを表すために指標がSLIです。このお風呂が１ヶ月のうち98%以上保ち続けられることを目標にします。これがSLOです。

また、SLOは100%で定義することはせず、余白を持たせることが一般的です。

なぜ余白があるのか？

それはユーザにとって、98%も100%も大抵誤差だからです(例外はあります)。
この2％はエラーバジェットと呼ばれており、この2％を消費しない範囲で新しい変更を加えても良いとされています。例えば、ジェットバス機能を付けてみる、などです。

もしそれでお風呂の快適さが安定しなくなったら、SLO違反＝やりすぎた、ということですね。
実際のプロダクト開発におけるSLI/SLOは
SLIは、成功したリクエストの割合やレスポンスの平均時間などを測定する
SLOは、「99%以上のリクエストは500ms以内に応答する」と定義する
この場合エラーバジェットは1%となる
エラーバジェット1%を消費すると、SLO違反になる
本記事では、これらの概念を踏まえ、私が実際にチームでSLI/SLOを運用を推進していく中で行ってきたことをご紹介します。

 やってきたこと知識をつける
自分でプロダクトの状況を理解する
PdMやメンバーにSLI/SLOについて理解を深めてもらう
PdMやメンバーでもメトリクスが見れるように整備する
実際にチームで運用し、改善してみる

 1. 知識をつける取り組み始めた当初は全く知識がなかったため、自身のインプットからスタートしました。

以下は私がインプットのために活用した書籍、サイト、勉強会です。

 書籍
 サイト
 勉強会さらに、別チームのSREエンジニアの方からも知見やアドバイスをいただきました。

特に「今の指標はリンクウェルが抱えるユーザ体験を本当に反映しているのか」「アラートが鳴ったとき、ユーザ体験はどう悪化しているのか」といった観点です。

こうしたサポートのおかげで、独学では見落としがちなユーザ体験とSLI/SLOを結びつける視点を持てるようになり、実践的な理解へとつながりました。

 2. 自分でプロダクトの状況やその監視設計を理解する私達はシステム監視ツールとしてDatadogを利用しており、各種システムメトリクスを確認できるようになっています。

私が参画した時点でチームでは既にSLI/SLOが策定されていました。そのため、まず策定されたSLI/SLOについて以下の事項を理解するようにしました。
何を監視しているのか？
監視対象の機能はどこの画面で使われている機能なのか？
何が起こるとエラーバジェットが枯渇するのか？
現状監視しているアプリケーションが今どのような状況なのか？
また、SREエンジニアの方とモブプロを行い、監視設計の背景やSLI/SLOの設定内容を一緒に確認しました。

実際にメトリクスを追いながら議論することで、単に「何を監視しているか」を知るだけでなく、「なぜその指標を選んだのか」「どんなユーザ体験を守るためか」といった設計思想まで理解することができました。

このように、私が「チームに根付かせる役」として学び、SREが「専門知識で支える役」として補完してくれる関係性ができたのは、とても大きな支えになりました。

この体験が以降の運用やチームへの説明に大きく役立ちました。

 3. PdMやチームメンバーにSLI/SLOについて理解を深めてもらうSLI/SLOはプロセスでありプロジェクトではない
O'reilly サービスレベル目標 より
自身の理解を深めましたが、SLI/SLOは一人で運用していくものではなくチームで運用していくプロセスです。私だけが理解を深めても意味がありません。

そのためPdMやチームメンバーに対してSLI/SLOを運用していく意義やメリットについてLT形式で説明しました。


スライド１
スライド２





どうしても横文字が多くなってしまうため、最初はSLI、SLO、エラーバジェットという言葉に限定し理解してもらうように心がけました。またイメージしやすくするために「お風呂」の例を使って説明しました。完璧に理解してもらおうとは思わず、こういうものがあるんだぐらいに理解していれば良いなと思いました。

 4. PdMやメンバーでもメトリクスが見れるように整備し運用するメトリクスが見れるようにドキュメントを作成しました。なるべく図や実際の画面のスクショを活用し、一目でわかるように努めました。しかし、ドキュメントを作成しただけでは、誰も見ようとはしませんでした。

ドキュメントを作成しただけになっており、チームメンバーに任せて放置！のような状態を作っていました。ここについては反省です。
O'reilly サービスレベル目標 の「13章：SLO文化の構築」にも以下のような記載があります。
SLOが受け入れられるまでには、しばらく時間がかかるかもしれません。

一晩で変化が現れなくても落胆してはいけません。

継続的にチームのメンバーとこれらのツールおよび概念について議論し、

考え方を試し、より良い監視と信頼性の合意を目指してください。
私は「ドキュメントを作ってチームに渡せば、あとは各自がメトリクスを見て運用してくれるだろう」という考えを変え、作成したドキュメントを活用しながら運用するために毎週決まった曜日のデイリースクラムの時間を活用しメトリクスを見るようにプロセスを見直しました。このようにすることで少しずつ関心を持ってもらうように努めました。

最初は何に役立つのか直感的にはわからなかったと思います。

そのため初めは小さく、我慢強く、チームと開発と密接に関わることを少しずつ説明していきながら運用を進めていきました。

これが後に大きな成果につながります。

 5. 実際にチームで運用し、改善してみる運用事例を２つ紹介します。

 １： 異常状態の検知診療科のランディングページ(LP)に載っているカレンダーから予約が可能なのですが、現在はファーストビューで３日間表示されます。これを７日間表示に変更するという施策が走りました。以下がその画面です。


３日間表示の場合
7日間表示の場合





施策の進め方としては、A/Bテストを実施しながら、徐々に適用範囲を広げていく想定でした
しかし、誤って100%適用してしまい、APIの負荷が一時的に上昇しました。ここでSLI/SLOの出番です。アラートを通知する仕組みがあったおかげで気づくことができ、障害を未然に防ぐことができました。

 2： 応答速度の遅延(レイテンシー)の改善３日間表示を７日間表示に変更する際に扱うデータ量が増え、APIのレイテンシーが上昇してしまいました。その結果、おおよそ元々2.1秒 ~ 3.7秒以内に応答していたものが、2.5 ~ 4.9秒以内に応答するようになり、全体的に負荷が上がるようなっていました。
施策を続けていくとユーザ体験を悪化させてしまうため、改善を実施しました。Datadogの計測結果や実際のコードをチェックし、改善を進め、結果として1.6 ~ 2.9秒以内に応答するようになりました。
この結果はチームとしての成功体験に繋がり、メトリクスを見る姿勢が変わるようになりました。

サービスの品質管理は感覚ではなく、数値と目標で管理するが一気に浸透するきっかけになりました。

今ではSLI/SLOに関心を持つだけでなく、設定値の修正もチーム内で行い始めています。

 最後にSLI/SLOの運用を進める中で実感したのは、信頼性を数値化しチーム全体で共有することが、単なるモニタリング以上の意味を持つということです。

小さく始め、失敗や改善を積み重ねることで、メンバーの意識が変わり、数値を見て議論する文化が少しずつ根づいてきました。
これからは、運用に慣れてきた基盤を活かし、より高度な信頼性の改善サイクルを回していくことを目指します。たとえば、よりユーザ体験に直結する指標を追加したり、PdMやビジネスサイドとも連携して「サービスとしての理想的な体験」を数値化する試みに挑戦していきたいです。
信頼性は一度確立すれば終わりではなく、プロダクトの成長とともに変化し続けるものです。これからもSLI/SLOをチーム開発に溶け込ませながら、サービスを利用する人にとって「安心して使える体験」を継続的に提供できるよう挑戦を続けていきます。