SLO とは？エラーバジェットの完全ガイド（Sheets テンプレート付き）
要約
SLO（サービスレベル目標）とは、サービスの信頼性目標を数値化したもので、例えば「30日間のリクエスト成功率99.9%」といった形で定義します。100%とターゲットの差がエラーバジェット（99.9%の場合、30日で43.2分のダウンタイムを許容）です。本ガイドでは SLI、SLO、SLA の違いを整理し、Google Sheets や Excel で直接使える計算式を提供します。
では、SLO とは何でしょうか？
サービスレベル目標（SLO）とは、サービスに対して設定する信頼性目標であり、時間枠を付けて数値化されます。「30日間のリクエスト成功率が99.9%」というのが SLO です。これにより、チームは曖昧な「信頼性が高い」という目標を、測定して追跡できる数値に変換できます。計算の核は単なる除算なので、スプレッドシートで十分に対応できます。
Biscuit はすでに計算式を取得してくれました。あなたが用意するのは数値だけです。
よく見かける3つの用語、整理します
SLI、SLO、SLA。会議で混同されることが多いので、ここで簡潔に説明します。
SLI（サービスレベルインジケーター）: 測定対象。リクエストがエラーなく返される割合、ページが300ms以下で読み込まれる割合、予定時刻までにジョブが完了する割合。
SLO（サービスレベル目標）: その測定値のターゲット。「SLI は30日間で99.9%以上を維持する」という形で定義します。
SLA（サービスレベルアグリーメント）: 通常は金銭的な返金や補償が伴う契約。ターゲットを達成できない場合の結果が決められています。
最もシンプルな区別方法は Google の SRE ブックにあります。ターゲットを逃した場合に契約上の結果が発生するかを問い、発生しなければ SLO（SLA ではない）です。SLO は設定した SLA より厳密にしておくことで、顧客が補償を受ける前に警告が発せられます。
スプレッドシートの言葉で言えば、SLI は測定値の列、SLO は単一セルのターゲット値、SLA は法務部が保管する PDF です。
99.9% と 99.99% がまったく別の約束である理由
小数点以下の各 9 は、許容ダウンタイムを10倍削減します。30日間（43,200分）の場合、各ターゲットで許容される時間は以下の通りです：
99%: 1% バジェット、30日で432分（7.2時間）のダウンタイム許容
99.5%: 0.5% バジェット、30日で216分（3.6時間）
99.9%: 0.1% バジェット、30日で43.2分
99.95%: 0.05% バジェット、30日で21.6分
99.99%: 0.01% バジェット、30日で4.32分
最後の行が落とし穴です。月4分のバジェットでは、人間がアラートを読み終わる前にバジェットがなくなります。ほとんどの社内ツール、ダッシュボード、小規模なSaaS製品ではこのレベルは必要なく、追い求めると実装と運用コストが膨大になります。
顧客がそれに対価を払っていなければ99.99%は避けるべきです。Google の助言も同じです。まずは緩いターゲットから始めて、後で厳しくしてください。達成不可能な厳密なターゲットを最初に設定すると、チーム全体が数値を無視するようになります。
エラーバジェット：チームが本当に議論する数値
エラーバジェットは SLO で残される部分です。99.9% をターゲットにすれば、バジェットは0.1%。30日間で43.2分の「悪い」時間を使用できるということです。
ガソリンのゲージとして考えてみてください。危険なデプロイはバジェットを消費します。データベースの問題のあるマイグレーションもバジェットを消費します。夜中3時の障害はたくさんのバジェットを消費します。タンクが満杯なら、より速くデプロイします。空になったら、機能追加を停止して信頼性を修正します。
Google 独自のサンプルポリシーは具体的です：4週間ウィンドウでサービスがバジェットを超過すれば、P0対応とセキュリティパッチを除くすべての変更は停止します（サービスが SLO 内に戻るまで）。バジェットは交渉ツールであり、懲罰ではありません。プロダクトマネージャーとエンジニアが同じセルの数値から議論できます。
複数のチームが同じサービスに触れているなら価値があります。ランディングページとお問い合わせフォームだけを持つ個人起業家なら、過度かもしれません。
ユーザーが認識できる SLI を選択する
最良の SLI は、人々が気づく瞬間を説明しています。ほとんどのサービスなら3つでカバーできます：
可用性: リクエスト成功の割合。測定と説明が簡単。
遅延: 閾値より速いリクエストの割合。「95%の検索が300ms以下で返される」は平均値よりも優れており、遅い部分を隠しません。
鮮度: データパイプラインとレポートについては、期限前に完了する実行の割合。これはスプレッドシートの人にぴったり合います。「朝の売上シートが営業日の99%で午前8時までに更新される」といった形です。
SLI を分数として書く習慣をつけてください。良いイベント÷有効なイベント。この1つの習慣により、すべての SLO が単一セルで計算可能になり、事前に「良い」とは何かを定義するよう強制されます（インシデント対応中ではなく）。
ウィンドウについては、ローリング30日が標準的です。暦月はシンプルですが、月初にバジェットがリセットされるため、月末に危険なリリースをプッシュするという誘惑が生じます。シート内では、ローリングウィンドウは最後30日へのフィルタリングを意味します（例：SUMIFS(Incidents!C:C,Incidents!A:A,">="&TODAY()-30)）。
Google Sheets または Excel で10分で SLO トラッカーを作成する
監視プラットフォームは不要です。2つのタブが必要です：Incidents と SLO です。
Incidents タブで、各障害について、開始時刻をA列、終了時刻をB列、期間をC列に記録します：
=(B2-A2)*24*60B2とA2: インシデントの終了と開始の日時。*24*60: 日ベースの差を分に変換します。
Excel と Sheets の全バージョンで動作します。
次は SLO タブです。A列にラベルを、B列に計算式を入れます：
B1: 0.999 (SLO ターゲット)
B2: 30 (ウィンドウ：日数)
B3: =B2*24*60 (ウィンドウ内の合計分数)
B4: =B3*(1-B1) (エラーバジェット：分)
B5: =SUM(Incidents!C2:C) (これまでのダウンタイム)
B6: =1-B5/B3 (実際の可用性)
B7: =B4-B5 (残りバジェット：分)
B8: =B5/B4 (消費したバジェットの割合)99.9% のターゲットでは、B3 は43200、B4 は43.2 を返します。12分の障害を記録して B8 は27.8% を表示します。実際のセルでどう見えるかはこんな感じです。
B5 の C2:C についての注記：開いた範囲は Sheets の構文です。Excel では Incidents!C2:C500 のような固定範囲またはテーブル参照を使用してください。
ステータスセルを追加して、誰もが数値を読む必要がないようにします：
=IF(B8>=1,"Freeze releases",IF(B8>=0.5,"Careful","Ship it"))B8>=1: バジェットが完全に使用されているか超過している。B8>=0.5: 半分が消費されているため、危険な変更をレビューします。その他：緑のライト。
独自のしきい値を選択します。50%は開始点であり、物理法則ではありません。
独自のバージョンでこの計算式に詰まっていますか？平易な英語で説明すれば、ツールが計算式を書いてくれます。
リクエストの数を時間ベースで数える代わりに
時間ベースの追跡は説明しやすいですが、粗雑です。午前4時で誰もオンラインでないときサービスが5分「ダウン」しているのと、正午に5分ダウンしているのでは、ダメージの大きさが異なります。真摯なチームはリクエストに基づいて SLI を定義しています。
リクエストログをタブにエクスポートして貼り付け、HTTP ステータスコードを B 列に入れます。その後：
=1-COUNTIF(B2:B,">=500")/COUNTA(B2:B)COUNTIF(B2:B,">=500"): サーバーエラーを返したリクエストをカウント。COUNTA(B2:B): すべてのリクエストをカウント。エラー割合を1から引くと成功割合が得られます。
結果はフラクションとしての可用性 SLI です。ターゲットセルと比較すれば、SLO 全体が1行で揃います。Excel 2016 と365 は COUNTIF を受け入れています。B2:B を制限された範囲に置き換えるだけです。
2つの正直な警告。スプレッドシートは数百万行で機能不全になるため、生ログではなく毎日の集計をエクスポートします。また、4xx レスポンスは通常ユーザーのミスであり、あなたの障害ではないため、そのルールを決定して書き留めてください。
バーンレート：遅すぎる前に警告する計算式
バジェットの27.8%を消費したことを知るのは良いことです。それをカレンダー以上の速度で消費していることを知るのは有用です。その比率がバーンレートです。
=B8/(B9/B2)B8: これまでに消費したバジェットの割合。B9: ウィンドウで経過した日数（手動で入力するか、=TODAY()-B10を使用し、B10 にウィンドウ開始日を入力）。B2: ウィンドウ内の合計日数。
バーンレートが1というのは、ウィンドウをちょうどゼロバジェットで終了することを意味します。1を超えているなら、フリーズに向かっています。1を下回っているなら、余裕があります。30日ウィンドウの10日目で既に60%消費しているなら、バーンレートは1.8です。これが画面に表示する数値です。
これは大きな監視ツールが使用している同じアイデアです。シートは午前3時にあなたをページングしませんが、レポートレイヤーとして扱い、アラームシステムとしてではなく使用します。
実数を使った実施例があります。99.9%の SLO で30日、バジェットは43.2分。1～8日目：悪いデプロイがチェックアウトページを14分ダウンさせます。バジェットの32.4%をウィンドウの4分の1で消費、バーンレート約1.2。火事は出ていませんが、シートは「Careful」と表示され、次の危険なマイグレーションは再検討されます。15日目：プロバイダー障害が30分追加。合計44分、101.9%消費。ステータスセルは「Freeze releases」に切り替わり、優先度の会話は数値を持つテーブルに基づいて行われます（感情ではなく）。
これが全体の価値です。9の数ではなく、誰もが指差せる共有セル。
スプレッドシートでは不十分になるとき
このようなトラッカーは1～2つのサービスと週次レビューに機能します。数十のサービス、自動データ収集、週次会議ではなく数分で起動するアラートが必要になると、失敗します。
適切な監視ツールの検討の時間です。Datadog と Grafana はどちらも SLO の本質的な機能を備えており、メトリクスから直接 SLI を引き出し、バジェットを描画します。
オープンソースを希望し、既に Prometheus を実行しているなら Grafana を選択します。ベンダーで何も実行したくなければ、Datadog を選択して報酬を払います。どちらでも、月次レビュー資料用にシートを保管してください。部屋の全員が開くことができ、ベンダーへのログインが必要な人はいません。
サービスの最初の SLI セットをドラフトするのに協力が必要なら、一般的なアシスタントは妥当なブレーンストーミングパートナーです。提供される数値はすべて検証してください。プラスに聞こえる目標を幸せに発明します。
SLO を無駄にする間違いと月曜日にすることは
Biscuit が悪く終わるのを見た事例があります：
現在のパフォーマンスをターゲットとしてコピーする。 前四半期に99.97%で実行していたなら、SLO を99.97%に設定すると、維持できないペースがロックされます。
SLO が多すぎる。 サービスごとに2～3個。それ以上では、誰も何が重要かを覚えていません。
測定が簡単なもの、ユーザーが感じることではない。 CPU使用率は SLI ではありません。チェックアウト失敗はそうです。
結果がない。 エラーバジェットポリシーのない SLO は願いです。50%、100%、150%消費時に何が起きるかを事前に決定してください。
ターゲットを再検討しない。 四半期ごとにレビューします。バジェットを消費することに近づかないなら、ターゲットは緩すぎます。
月曜日の部分。1つのサービスを選びます。エンジニアでない誰もが理解できる1文で1つの SLI を記述します。緩いターゲット99.5%または99.9%を設定します。上記の2つのタブを構築し、先月のインシデントをログし、バジェットが何を言うかを見ます。
答えが「300%消費した」なら、なぜみんながお疲れなのかを発見しました。答えが「4%消費」なら、ターゲットを厳しくするか、より速くデプロイしてください。どちらにしても、感情ではなく数値について議論するポイントがあります。
いい子です。さあ、それらのインシデントをログしてください。