SLO（Service Level Objective）とは？

service level objective（SLO）は信頼性の内部目標であり、例えば「30日間の移動期間でリクエストの99.9%が成功する」といったもので、チームがコミットして測定の基準とするものです。

SLOは「サービスは信頼できるべきだ」という曖昧な目標を、精密で測定可能な目標に変えます。それはチームが舵取りに使う数値です。信頼性がSLOを下回れば安定性を優先し、健全であればそのマージンを機能の出荷に使えます。

SLOの構造

SLOは、service level indicator（測定する対象）、目標値、時間枠を組み合わせます。例えば「APIリクエストの99.95%が成功で返る、移動期間28日間で測定」です。それぞれの要素が重要で、同じ指標でも期間が長かったり目標が高かったりすると、別の、しばしばはるかに難しい目標になります。

SLO対SLA対SLI

SLIは測定、SLOはその測定に対する内部目標、SLAは達成できなかった場合に（多くは金銭的な）結果を伴う外部契約です。SLOは通常SLAより厳しく設定され、顧客への約束を破る前に問題を修正できる余裕を残します。

なぜ100%ではないのか

完璧な信頼性はとてつもなく高くつき、通常は不要です。ユーザーは99.99%と100%の違いにめったに気づかず、最後の一部を追い求めるには膨大な労力がかかります。良いSLOは、ユーザーを満足させるのにちょうど十分な高さに設定され、それ以上は高くしません。これによりイノベーションの余地が保たれます。

現実的な目標を選ぶ

有用なSLOは、ユーザーが実際に必要とするものと、システムが持続的に提供できるものを反映します。チームはしばしば現在のパフォーマンスを測定することから始め、達成不能にならない範囲で改善を促すよう、SLOを少しだけ厳しく設定します。常に達成されるSLOは何も教えてくれず、常に達成できないものは信頼を損ないます。

意思決定ツールとしてのSLO

SLOの真の力は、行動を駆動することです。リリースペースを統制するerror budgetに供給し、alertingをユーザーに見える問題に集中させ、信頼性の作業を新機能に対して優先付けするための、共有された客観的な基準をチームに与えます。

重要なポイント

SLOは、ある時間枠にわたる信頼性の測定に対する内部目標です。
それは生のSLIと、外部的に拘束力のあるSLAの間に位置します。
良いSLOは、速度を維持するために100%ではなく「十分に信頼できる」を目指します。