Development Division / Platform Team の伊豆です。

Repro では数年前から組織横断した SLO 運用の取り組みを進めています。

これらの記事で紹介した通り、SLO 推進チームを発足し、主要機能に対する SLO の策定を進めてきました。今回はその次のステップとして、機能開発チームが SLO を自律的に策定・運用できるようになるまでの取り組みと、SLO を考慮した新機能開発プロセスの整備について紹介します。

SLO 活用の理想像

前回までの取り組みにより、2024 年の中頃には SLO 推進チームの主導でいくつかの主要機能について SLO が策定されていました。運用負荷の軽減や意思決定の改善といった明確なメリットを確認できたため、SLO 推進チームとして Repro における SLO 活用の理想像を以下のように定めました。

機能開発チームが SLO を策定・運用できるようになっている
新機能に対して初期段階から SLO を考慮した開発が行われる

機能開発チームが SLO を策定・運用できるようになっている

Repro では様々な機能を提供しており、それらの運用責任は機能開発チームが負っています。そのため、ユーザーにとって重要な体験や許容できる信頼性レベルについても、機能開発チームが最も適切に判断できると考えています。

こうした背景から、SLO 推進チームに頼らず、機能開発チームがユーザー体験の洗い出しから SLI/SLO の策定、エラーバジェットポリシーの設定、そして継続的な運用まで一連の流れを主導できる状態を目指しました。

新機能に対して初期段階から SLO を考慮した開発が行われる

SLO を策定する過程では「ユーザーにとって重要な体験は何か」という議論が行われます。新機能開発においてはこの議論がアーキテクチャや設計など技術選定にも大きく影響します。開発の早い段階でこれを把握することで、信頼性を考慮した設計が可能になり、より良い機能開発ができると考えています。そのため、新機能開発プロセスに SLO 策定を組み込むことにしました。

これらの理想像を実現するため、次の 2 つの取り組みを実施しました。

機能開発チームによる既存機能の SLO 策定
SLO を考慮した新機能開発プロセスの整備

機能開発チームによる既存機能の SLO 策定

理想像実現の第一歩として、機能開発チームが自分たちで既存機能に SLO を策定できるようになるよう支援しました。

SLO 策定は、SLO 推進チームで SLO を策定したときと同じように以下の3ステップで進めてもらいました。

重要なユーザー体験を見つける
ユーザー体験から SLI を決定する
SLO の策定

Repro における組織横断した SLO 運用のはじまりで紹介した通り、社内向けの SLO 説明会は実施済みで、機能開発チームは SLO のコンセプト自体は理解している状態でした。ただし、コンセプトを理解していても妥当な SLO を設定するのは難しいことを私たち自身が実感していたため、キックオフで各ステップのアウトプット具体例を提示し、SLO 推進チームを含めてレビュー¹しながら妥当な SLO を一緒に探って策定していきました。

SLO 策定で難しかったポイント

実際に SLO 策定を支援する中で、以下の2つが共通して難しいという声が挙がりました。

SLI や SLO の目標値をどう決めるか
複数コンポーネントにまたがる SLI の計測

1. SLI や SLO の目標値をどう決めるか

過去の実績に基づくデータがある場合はそれを基準に、ない場合は外部公開されている汎用的な指標（e.g. SRE Workbook）や社内の類似サービスを参考に出発点となる値を決めつつ、運用していくなかで継続的に改善してもらうようにしました。

2. 複数コンポーネントにまたがる SLI の計測

現状、複数コンポーネントをまたいだメトリクスを取得するのが難しいため、重要なユーザー体験に直接対応する SLI を設定できないケースがあります。この課題については、ユーザー体験に最も近い代替指標を用いることで対処しています。具体的には、ユーザー体験に関わるコンポーネント毎に SLO を策定する方法や、起点となるコンポーネントでタイムスタンプ等をメタデータとして付与し、終点でそのメタデータをもとにメトリクスを生成する方法などです。複数コンポーネントにまたがる SLI の計測は、今後の課題として残っています。

こうした複数のチームで共通する課題を FAQ にまとめ、各チームが自律的に SLO を策定・運用できる状態を目指しています。

SLO を考慮した新機能開発プロセスの整備

ここまでの取り組みにより、機能開発チームは SLO を策定・運用できるようになり、策定された SLO は実際にロードマップの優先順位決定に活用されたり、信頼性を改善する活動のきっかけになったりしました。

また、SLO 策定を通じて、機能開発チームが提供するサービスの「重要なユーザー体験は何か」について議論するきっかけになり、ビジネスサイドを巻き込んだ対話が積極的に行われるようになりました。

こうした「ユーザーにとって重要な体験は何か」といった議論は、アーキテクチャや設計など技術選定に大きく影響するため、リリース後ではなく開発のできるだけ早い段階で把握することが重要だと考え、新機能開発プロセスに SLO 策定を組み込むことにしました。

Repro では機能をリリースする前にβリリースなどいくつかのフェーズを経て公開されることが多いため、各開発フェーズで段階的に SLO を洗練させていく方針を採用しました。具体的には、β以前のリリースでは暫定的な SLO を設定し、少数のユーザーからのフィードバックをもとに現実的な値へ調整していきます。そして、最終的にリリース時には正式な SLO とエラーバジェットポリシーが運用される状態を目指します。

また、上記の SLO は、プロダクトフィードバック会で機能紹介の一部として発表し、ビジネスサイドからのフィードバックも取得する仕組みを構築しました。

ただし、現時点ではこの新しい開発フローに沿って開発された機能はまだありません。プロセスは整備できたものの、実際の運用を通じた検証と改善が今後の課題です。

今後の課題

本記事で紹介した取り組みを通じて、機能開発チームが SLO を策定・運用できる体制は整いつつありますが、いくつかの課題が残っています。

複数コンポーネントにまたがる SLI の計測

現状では複数コンポーネントをまたいだメトリクスを取得するのが難しく、ユーザー体験に直接対応する SLI を設定できないケースがあります。代替指標を用いることで運用は可能ですが、ユーザー体験との乖離が生じるため、分散トレーシングなどを活用し、複数コンポーネントにまたがる SLI を計測できるような仕組みを整えたいと考えています。