形骸化しないSLOを設計する
こちらはTechCommit AdventCalendar2024の20日目の記事になります。
はじめに
「SLOを設定したものの、数値が現実に即していない」「SLOが形骸化して運用されていない」といった課題に対してどのようなアプローチが適切なのか、悩むことがありました。
ただこれらは「設定された数値が意味する内容」に対する解像度が荒かったことで起きていたように今では思います。そこで最近考えたSLO設定の思考プロセスをまとめます。
なお、ここで紹介する内容はあくまで個人的なアイディアであり、すべての状況で適用できる保証はありません。詳しくは必要に応じて関連書籍をご参照ください。
SLOを再考する
SLO（サービス・レベル目標）は、システム運用における重要な指標であり、サービスの信頼性を数値化し、運用の改善に役立てるための基準です。以下はIBMの記事にあるSLOの説明です。
サービス・レベル目標（SLO）は、一定期間の特定のサービスに対して合意されたパフォーマンス目標です。SLOはサービスの期待されるステータスを定義し、関係者が特定のサービスの健全性を管理し、イノベーションと信頼性のバランスを取りながら意思決定を最適化するのに役立ちます。
ref. https://www.ibm.com/jp-ja/topics/service-level-objective
内容を見ると「期待されるステータスを定義」とありますが、具体性が欠けています。この曖昧さが、SLOの形骸化を招く一因と考えています。そこで以下のポイントを明確化し、より実用的なSLOを設計します。
- 誰に対する期待なのか
- ステータスはどのような形式（数値、カテゴリなど）で表現されるべきか
誰に対する期待なのか
結論から言うと、システム利用者にあたります。システム利用者が満足していれば「期待の範囲内」と捉えることが出来ますし、満足していなければ「期待に答えられていない」となります。
しかし「満足」を測定するのは難しいため、別の視点として「満足していない状態」、すなわち「不満がある状態」に着目するアプローチを検討しました。
つまり「本来なら提供するべき機能が提供できていない状態」を「不満がある状態」と捉える方法です。
「不満」をSLIで捉える
不満の具体例
システム利用者が「不満」と感じる状態を仮説ベースで考えたものが以下です。
- 画面のローディングが遅い
- APIのレスポンスがタイムアウトする
これらの不満は、SLI（サービス・レベル指標）として計測可能なものです。例えば、画面のローディング速度については、Core Web Vitalsを基準に考えることができます。
不満の情報源を広げる
「不満」は技術指標だけでなく、様々な情報を掛け合わせることでより効果的な情報になる場合があります。
- 過去のユーザー問い合わせ
- 営業やカスタマーサポートからのフィードバック
情報の取得範囲を広げ、より具体的な「不満」の情報を取得することで、実際の利用者体験に即した指標の設定に繋がります。
優先順位をつけたSLO導入
全ての不満点に対してSLOを導入する必要はありません。
不満が多発する箇所やシステムの主要な価値提供に影響する部分に優先的に導入することで、効率的な改善が可能になります。
エラーバジェット
不満が1件でも発生した場合、即対応すべきでしょうか？それとも許容範囲内と考えるべきでしょうか？
この判断には「エラーバジェット」が役立ちます。
簡単に言うと、エラー バジェットは、ユーザーが不満を感じ始めるまでの一定の期間にサービスで累積できるエラーの量です。これをユーザーの忍耐度と考えることができますが、可用性やレイテンシなどサービスの特定のディメンションに適用されます。
（略）
次に例を示します。ホームページの可用性を測定するとします。可用性は、エラーで終了したリクエスト数をホームページが受信した有効なリクエスト総数で割って測定し、パーセンテージで表されます。例えばその可用性の目標を 99.9% に設定すると、エラー バジェットは 0.1% になります。これにより、エラーが 0.1% に達するまで（0.1% より少な目が望ましい）エラーが許容され、ユーザーに不満なくサービスの利用を続けてもらえます。
ref. https://cloud.google.com/blog/ja/products/management-tools/sre-error-budgets-and-maintenance-windows
「ユーザーの忍耐度」は「利用者の不満をどの程度無視するか」というふうにも解釈できます。これが「エラーバジェット」として設定する内容になります。
一定の基準値を超えたら「ユーザーが耐えられない不満をもっている無視できない状態」を示していることになるので、エラーバジェットが尽きた場合、即時対応が必要なものと判断できます。これにより信頼性のあるサービスを継続的に提供できるようになります。
おわりに
SLOは「不満」と「許容度」を基軸に設計することで、形骸化せず、実用的な指標となります。本記事で紹介した思考プロセスを参考に、現場の課題解決や改善活動に活用してみてください。
サービス利用者に寄り添ったSLO設計を目指す一助となれば幸いです。
Discussion