SLO Basics - a conversation about reliabilityの意訳
Qiita Advent Calendar 2025の海外SRE関連セッション意訳の6日目です。ひとりアドベントカレンダーですが、完走できるように頑張ります。
このアドベントカレンダーでは、海外のSRE関連のセッションを翻訳しながら、私の意見や疑問や補足を追加したものです。私の誤解から誤った説明になっている箇所は、コメントでご指摘お願いします。
前回は、Unified Theory of SRE in SRECon22 Europe/Middle Asia/Africa の意訳でした。GoogleやFacebookのSREではなく、私たちのSREを再構築する必要がある、という問題提起をするようなセッションでした。
このアドベントカレンダーでは、私の意見やコメントは可能な限り、下記の記法で要約と区別します。ただ、そこまで厳密にできないため、要約文中に私の思想が混じってしまうことはご容赦ください。(気がついたらご指摘ください)
紹介するセッションについて
セッション詳細: SLO Basics - a conversation about reliability | SLOconf 2021
今回のセッションでは、SLOやエラーバジェットやカオスエンジニアリングといったプラクティスにも触れていきたいと思っています。そのため、その基礎となるSLO Basicsのセッションを紹介します。かなり基本的な内容ですので、SRE本やSLO本を読んでいる方にとっては退屈な内容かもしれませんが、原点に戻ることはいつだって価値がありますね。
要約
SREとSLO/SLIの関係
最初に用語の確認から。
- SRE: Site Reliability Engineer
- SLO: Service Level Objective
- SLI: Service Level Indicator
多くの人は「SRE=プロダクトの信頼性を守る人」というイメージを持っていると思うが、それだけではない。
SREの大きな責任の1つは、社内のさまざまなグループ(開発,プロダクト,ビジネス,サポートなど)の間にあるギャップを埋めることだ。
SLOは、そのギャップを埋めるための「会話を始めるためのツール」として位置付けられる。
オブザーバビリティとSLO
SLOに特に関連が深い概念として、オブザーバビリティがある。
オブザーバビリティとは:
外部に観測できる出力から、システム内部の状態を理解する能力
ここには例えば次のようなものが含まれる。
- システム統計
- 可用性
- 依存サービスの状態
- エラー数
SREとしての目標は、これらの計測手段を整えたうえで
プロダクトの状態を把握し、どこに力を入れるべきかについてさまざまなチームと意味のある会話ができるようにすること。
その中心にある問いが
ユーザー体験に悪影響を与えることなく、新しい機能をリリースできる状態にあるか?
であり、ここに答えるための枠組みがSLOだ。
SLO,SLI,そして少しの数学
SLOを計測するために使うのがSLIだ。
SLIは「どれだけ上手くやれているか」を具体的な数字で表す指標で、そこには少しだけ数学が入ってくる。
SLOの良いところは、計測のためのデータさえあれば
とても一般的な目標にもできるし、かなり具体的で局所的な目標にもできる。
そしてSLOはあくまで内部向けの目標なので、気軽に変えてよい。
99.99%可用性など非現実的なSLOを掲げていて、それを全く達成できていないなら
素直にSLOを見直して、現実的なところから始めるほうがよい。
小さなゴールを積み重ねるほうが成果を出しやすい、という意味では、SLOも他の目標設定と同じだ。
ここが、顧客と契約するSLAとの大きな違いになる。
SLAは顧客との約束だが、SLOは顧客から独立した内部の道具として、試行錯誤に使える。
具体例:99.95%が200ms以内に完了する
セッションでは具体例として、次のようなSLOが出てくる。
99.95% of requests on a service will be completed in under 200ms
これに「どれくらいの期間でそのSLOを評価するか」を加える必要がある。
例えば1日,1ヶ月,4ヶ月,1年など、自分たちにとって都合のよい期間を選ぶ。
ここでは1ヶ月を選んで、こう書き換える。
99.95% of requests on a service will be completed in under 200ms every month
このとき、1ヶ月あたりどれくらいのダウンタイム(失敗)が許容されるかを計算できる。
- 可用性99.95%ということは、許容される失敗率は
1-.9995=.0005 - 1ヶ月を平均30.42日とすると:
.0005*30.42*24*60=21.9024
- つまり、1ヶ月あたり約21.9分のダウンタイムが許容される
この21.9分がエラーバジェットだ。
エラーバジェットが意味するもの
エラーバジェットとは、ユーザーが気づいて苦情を言い始める前に、ある期間内でサービスが「消費してよいエラー量」と捉えられる。
これは特に次のような意思決定に役立つ。
- 最近ダウンタイムが続いている
- エラーバジェットを大きく超過している
といった状況では、プロダクトチームやSREチームは、新しい機能をどんどん投入し続けるのか、それとも信頼性改善や根本原因調査にフォーカスするのかを選ばなければならない。
エラーバジェットは、その判断をデータに基づいて行うための指標になる。
顧客は常に「常に使えるサービス」と「新しい機能」の両方を望んでいる。
理想は「バグのない新機能を継続的にリリースすること」だが、現実はそうはいかない。
- エラーバジェットが十分に残っているときは、新機能にGoを出しやすい
- エラーバジェットを使い切っている場合は、リリースではなく信頼性改善を優先すべきだ、というシグナルになる
場合によっては、リリース前QAにもっと投資すべきだと示してくれることもあるし、その優先度調整にはマネージャーや経営陣の支持が必要になる。
そのとき「感覚」ではなく「SLO/エラーバジェット」という数字を使えるのが強みだ。
100%可用性が危険な理由とカオスエンジニアリング
経営陣と話すとき、多くのエンジニアは「なぜ100%可用性が現実的でないか」を説明するのに苦労する。
しばしば「我々も100%を目指している」と思われてしまうからだ。
実際には100%を掲げることは自分たちを追い詰めることになる。
- 現実のコンピュータやネットワークは必ず壊れる
- 累積20分程度のダウンタイムなら、ユーザーはそもそも気づかないかもしれない
エラーバジェットとして「少しの余白」を用意することで:
- エンジニアの満足度やワークライフバランスを保ちつつ
- 敢えてシステムを壊すカオスエンジニアリングを試す余裕も生まれる
カオスエンジニアリングを安全に行うには、制御されたストレスの低い環境が必要だ。
エラーバジェットは、そのための「遊び」を生み出す役割も果たせる。
もっと学びたい人へ
最後に、より深く学びたい人へのリソースとしてSLO サービスレベル目標の本を紹介する。
- SLOの概念
- 良いSLOの選び方
- 他チームに受け入れてもらうための伝え方
などを学びたい人にはおすすめだが、1つだけ数学が重い章があるので、そこは飛ばしてもいい。
まとめ
このセッションで語られていたポイントをまとめると:
- SREはプロダクトの信頼性だけでなく、社内のさまざまなグループ間のギャップを埋める役割を持つ
- SLOはそのための「会話を始めるツール」であり、オブザーバビリティとセットで考える
- SLOは内部目標であり、現実に合わせて変えてよい。SLAとは違う
- エラーバジェットは「どれだけ壊してもよいか」の指標であり、新機能と信頼性改善のバランスを取るのに使える
- 100%可用性は現実的ではなく、エラーバジェットとしての余白がエンジニアの健全さやカオスエンジニアリングにもつながる
全体を通してコメント
非常に基本的な内容を、必要十分なコンパクトなセッションで、基礎を理解する上でとても役に立ったと思います。
今回、このアドベントカレンダーを進めるにあたって、Keys to SRE in SRECon14の意訳では、SLOはリリースチェックリストの代わりに使おうと提示した。これはつまり、リリースするチーム単位でSLOを持つべきだというニュアンスです。続いて、SLO Math in SLOconf 2021の意訳では、コンウェイの法則に惑わされず、サービスの玄関口でSLOを持つことを提案していました。そして前回のUnified Theory of SRE in SRECon22 Europe/Middle Asia/Africa の意訳では、スタートアップではSLOの数字を追うのをやめようという提言まで飛び出しました。
そして、この基礎まで戻ってみるとSLOの良さとはSLAと異なり、柔軟で自分たちに役に立つ形に柔軟に変えるべきということなようです。つまり、SLOは今組織やサービスが直面している課題の形をしているのが正しいのでしょう。
Discussion