はじめに
「うちのサービス、どのくらい落ちていいんでしたっけ？」
この問いに、根拠のある数字で答えられるチームは、思ったより多くありません。なんとなく「落ちてはいけない」ことになっていて、なんとなく監視の閾値が決まっていて、なんとなくアラートが鳴り続けている。そんな現場は珍しくないと思います。
本書『SLO サービスレベル目標』は、その「なんとなく」を、ユーザーを起点にした計測と、その計測に基づく意思決定へ置き換えるための一冊です。SLI（サービスレベル指標）、SLO（サービスレベル目標）、エラーバジェットという3つの概念を、定義・計算・実装・組織への導入まで通しで扱っています。
本記事では、設計やアーキテクチャに関心のあるエンジニア向けに、本書の構成と要点、そして実務にどう落とすかという観点で整理しました。
書誌情報
| 項目 | 内容 |
|---|---|
| 書名 | SLO サービスレベル目標 ―SLI、SLO、エラーバジェット導入の実践ガイド |
| 原書 | Implementing Service Level Objectives |
| 著者 | Alex Hidalgo |
| 監訳 | 山口 能迪 |
| 訳 | 山口 能迪、成田 昇司 |
| 出版社 | オライリー・ジャパン |
| 発行 | 2023年7月7日 初版第1刷 |
| ISBN | 978-4-8144-0034-8 |
寄稿者として Daria Barteneva、Blake Bisset、Niall Murphy、Ben Sigelman、Salim Virji ら業界の実務者が名を連ねており、全17章のうち8章が寄稿によるものです。単著の一貫性よりも、複数の現場の声が入ることを優先した構成になっています。
本書の位置づけ
SREの文脈でSLOに触れた本は、すでにいくつもあります。『SRE サイトリライアビリティエンジニアリング』でSLIが「定量的尺度」として定義され、『サイトリライアビリティワークブック』で「良いイベント÷全イベント」という比率としてより一般化されました。
本書はその延長線上にありつつ、SLOという単一のプラクティスに一冊まるごとを割いています。監訳者まえがきでも、SLOのあらゆる側面を網羅的に解説する本を待ち望んでいた、という趣旨のことが書かれています。
実際、SLOを起点に周辺トピックが芋づる式につながっていきます。
- SLIの計装 → オブザーバビリティ
- バーンレート → アラート戦略、オンコール戦略
- クリティカルユーザージャーニーの検証 → プロダクト・ビジネス側との協働
- SLOのビジネス指標化 → 全社的な合意形成
SLOは概念としてはシンプルですが、実際の開発運用プロセスに組み込もうとすると一筋縄ではいきません。本書はそこを埋めるための本です。
全体構成
3部17章 + 付録という構成です。
第Ⅰ部 SLOの開発（必読パート）
1章 信頼性スタック
2章 信頼性についての考え方
3章 意味のあるサービスレベル指標の開発
4章 適切なサービスレベル目標の選択
5章 エラーバジェットの使い方
6章 同意の獲得
第Ⅱ部 SLOの実装（寄稿中心・実践パート）
7章 SLIとSLOの計測
8章 SLOの監視とアラート
9章 SLIとSLOの確率と統計
10章 信頼性を得るためのアーキテクチャ
11章 データの信頼性
12章 適切に機能した例
第Ⅲ部 SLOの文化（組織・浸透パート）
13章 SLO文化の構築
14章 SLOの進化
15章 発見可能で理解可能なSLO
16章 SLOの提唱
17章 信頼性のレポート
付録A SLOの定義のテンプレート
付録B 9章の証明
著者は、第Ⅰ部だけは順番どおりに読むことを勧めており、第Ⅱ部・第Ⅲ部は自分の状況に合わせた順で構わないとしています。ただし最終章の17章は読み飛ばさないように、とも書かれています。
本書の核心：信頼性スタック
本書全体を貫く枠組みが「信頼性スタック（Reliability Stack）」です。
┌─────────────────────┐
│ エラーバジェット │ … 期間内にどれだけ許容できるか / 意思決定の材料
├─────────────────────┤
│ SLO │ … 目指すべき目標値（パーセンテージ）
├─────────────────────┤
│ SLI │ … ユーザー視点の計測値（良い/悪いの二値）
└─────────────────────┘
SLI：ユーザー視点で二値に落とす
SLIは、ユーザーの観点からサービスを計測した1つのデータです。ポイントは、各イベントを「良い」か「悪い」の二値に振り分けられる形にすることです。
たとえばページ読み込みなら、「2秒以内に読み込めたら良い、超えたら悪い」と決めます。すると、良いイベント数を総イベント数で割るだけで、割合が出せます。
SLI = 良いイベント数 / 全イベント数
例: 59,982 / 60,000 = 99.97%
裏側の計算がどれだけ複雑でも、SLIの定義文そのものは誰にでも理解できる平易な文章であるべきだ、というのが本書の立場です。書き方の例として、こういった一文が挙げられています。
レイテンシーの95パーセンタイルについて、400ミリ秒以内に正しいデータでレスポンスする
これは真偽が判定できる形になっているので、パーセンテージに変換できます。
SLO：その割合の目標値
SLOは、SLIから受け取った割合が目指すべき目標値です。「ページ読み込みの99.97%が十分な速さである」といった形で表現されます。
エラーバジェット：期間内の「許容できない量」
エラーバジェットは、一定期間の中でSLIがSLOに対してどう推移したかを計測する手段です。どれだけ信頼できない状態が許容されるかを定義し、是正措置が必要なタイミングを示すシグナルとして機能します。
「今SLOを満たしているか」を検出することと、「1ヶ月・1四半期の期間でどう推移したか」を報告できることは、まったく別の話です。後者があってはじめて、作業の優先順位づけができます。
SLOとSLAの違い
混同されがちなので、本書の整理を表にしておきます。
| SLO | SLA | |
|---|---|---|
| 性質 | 内部の目標値 | 有償顧客との契約 |
| 違反時 | 議論と意思決定のためのデータが生まれる | 補償義務が発生する |
| 対応 | 何をするか選択の余地がある | 選択の余地はない |
| 目的 | 学習と意思決定 | 明示的な約定 |
なお本書では、サービスに依存するものを広く「ユーザー」、有償で利用する人や組織を「顧客」と呼び分けています。ユーザーには人間だけでなく他のサービスも含まれます。
第Ⅰ部：SLOをどう決めるか
1章・2章：100%は必要ない、そしてコストがかかる
本書の出発点は「完璧である必要はない」という主張です。冒頭では、著者の担当美容師が完璧を目指すのをやめた話が紹介されます。基準を少し緩めたことで施術時間が短くなり、顧客の満足度もチップも、店の評判も上がった、という逸話です。
これはそのままサービス運用の話に読み替えられます。100%を目指す必要はなく、そもそもコストが見合いません。信頼性の水準を1段階上げるコストは、直感よりずっと大きくなります。
本書は、99.90%から99.95%への移行を「変更係数2」として説明しています。信頼できない割合が0.1%から0.05%へと半分になるからです。9を1つ増やすことの重さが、この言い方だとわかりやすくなります。
3章：意味のあるSLIをどう作るか
SLIは信頼性スタックの基礎です。ここが意味を成していなければ、その上に載るSLOもエラーバジェットも役に立ちません。
重要なのは、提供側が計測したいものではなく、ユーザーが必要としているものを計測することです。単純なリクエスト/レスポンスAPIから始まり、複数のマイクロサービスで構成される小売Webサイトのような複雑な例へと展開されます。
サービスによっては、外部から他サービスを観測するためだけの新しいサービスを作る必要が出てくる、とも書かれています。ここは実務的にかなり示唆的でした。
4章：目標値の選び方
この章は本書で最も実務に効くパートの一つだと感じました。
「9の数」から離れる
99.9%、99.99% といった「9を並べた数字」で考える癖に対して、本書は明確に否を唱えます。時間換算するとこうなります。
| 目標値 | 1日あたり | 1ヶ月あたり | 1年あたり |
|---|---|---|---|
| 99.999% | 0.9秒 | 26.3秒 | 5分15.6秒 |
| 99.99% | 8.6秒 | 4分23秒 | 52分35.7秒 |
| 99.9% | 1分26.4秒 | 43分49.7秒 | 8時間45分57秒 |
| 99% | 14分24秒 | 7時間18分17.5秒 | 3日15時間39分 |
99.7%、99.3%、98% といった中間の値も同様に提示されます。
本書は、99.97%でも98.62%でも、場合によっては87%でも構わないと言い切ります。むしろ「1ヶ月に2時間程度の信頼性の低さを許容する」といった時間側から入って、そこから逆算して99.7%を出発点にする、というアプローチも紹介されています。著者自身が97.2%という数値を運用して問題がなかった事例にも触れています。
依存関係の掛け算
自分より信頼性の低い依存対象がある以上、それを超える目標は約束できません。単純化した例として、99.9%のコンポーネントが40個あるサービスの計算が示されます。
0.999 ^ 40 ≈ 0.96
つまり全体としては96%程度しか保証できないことになります。実際の依存構造はもっと複雑ですが、「自分の願望を目標値にしても意味がない」という指摘としては十分に効きます。依存対象は「強い依存」と「弱い依存」に分けて考え、強い依存を弱い依存へ変換する設計手段も検討されます。
SLOは多すぎてもいけない
SLOを増やしたくなる誘惑への警告もあります。増やしすぎると次の問題が出ます。
- データポイントが多すぎて、意思決定がかえって難しくなる
- 他チームへの報告が困難になり、「わかりやすく伝える」というメリットが失われる
- 多重検定問題（multiple comparison problem）により、常にどこかにずれが見つかる
キャッシュのヒット/ミスに別々のSLOを置くのではなく、読み取りレイテンシー全体に1つ置けばよい、という具体例が挙げられています。目安として、外部に示すSLOは3〜5個程度が想定されています。
5章：エラーバジェットの計算と運用
エラーバジェットは信頼性スタックの中で最も到達が難しい部分だとされています。
イベントベースの計算
SLO = 99.8% → エラーバジェット = 0.2%
総観測数 = 20,000,000
失敗数 = 36,513
失敗率 = 36,513 / 20,000,000 = 0.18%
残バジェット = 0.2% - 0.18% = 0.02%
残割合 = 0.02% / 0.2% = 10%
失敗が153,872件だった場合は残りが負になり、バジェットを2.8回分使い切った、という表現になります。
時間ベースの計算
メトリクスの粒度を基本単位として積み上げます。粒度30秒、91.25日（1四半期）、SLO 99.99%なら、許容されるのは合計788.4秒（13分8.4秒）です。
ローリングウィンドウ vs カレンダー紐付けウィンドウ
| ローリング | カレンダー紐付け | |
|---|---|---|
| 挙動 | 時間経過とともに古い観測が抜けていく | 月初・週初にリセット |
| 利点 | 障害の影響が自然に減衰する | 報告しやすい、SLAの補償計算がしやすい |
| 欠点 | リセットタイミングが直感的でない | 月末の障害の印象が翌月にリセットされてしまう |
推奨されるウィンドウは28日または30日です。人間が慣れている単位を使うべきで、365÷12＝30.41666日のような厳密さは、同僚とユーザーを混乱させるだけだと釘を刺されています。ただし全社的に目立つサービスについては、90日や1年といった長めのウィンドウが推奨されています。
エラーバジェットポリシー
事前にドキュメント化しておくべき内容として、消費ポリシーと超過ポリシーが挙げられます。印象的だったのは、消費率に人員を連動させる例です。
- 6人チームでバジェットを33%消費 → 2人（33%）が信頼性作業に移る
- 66%消費 → 4人（66%）が移る
- 100%超過 → チーム全体が信頼性に集中
また、ポリシーの記述には MUST / SHOULD / MAY を使い分け、解釈の余地を残すべきだとされています。「エラーバジェットポリシーでは機能開発を止めなければならないが、CEOがリリースしろと言っている」場合の正解は書けないからです。SLOとエラーバジェットは、そうした要求に対して押し返す根拠となるデータを提供するものだ、という整理になっています。
6章：同意の獲得
技術ではなく合意形成の章です。開発・製品・運用・QA・法務・経営幹部という利害関係者ごとに、想定される反対意見と切り返しが列挙されます。
「うちはGoogleじゃない」「うちの人間はそこまで優秀じゃない」といった典型的な反対に対して、著者はロケットサイエンスではないと切り捨てます。基本的な算数と、わずかな統計と、規律があれば十分だという主張です。
第Ⅱ部：どう実装するか
7章：計測基盤の選択
SLIとSLOの計測は、複数段階にわたる計算になります。設計目標として、柔軟な目標値・テスト可能性・鮮度・コスト・信頼性・組織の制約が挙げられます。
実装の選択肢は大きく2つです。
| TSDB（メトリクス） | 構造化イベントDB（ログ） | |
|---|---|---|
| 得意 | 集中型の時系列統計、多次元分析 | 集計分析、後からの再定義 |
| 特徴 | 事前に集計軸を決める必要がある | イベント単位で残るため柔軟性が高い |
現状の多くの組織は、TSDBと構造化イベントDBを適切に組み合わせればSLOを実装できるとしつつ、より現代的なオブザーバビリティ基盤のほうが同等コストで柔軟性・テスト可能性・鮮度を高められるとも述べています。分散トレーシングとの統合にも触れられています。
8章：バーンレートによるアラート
個人的に最も収穫が大きかった章です。
単純な閾値アラートの短所が、まず徹底的に列挙されます。
- 閾値の妥当性が時間とともに変わる
- ユーザー体験の不完全な代用物でしかない
- 静的な閾値にはコンテキストが欠落している
- 閾値・振る舞い・範囲外アラートの相互関係が不明瞭
- アラート疲れと「戦場の霧」
代わりに提案されるのが、エラーバジェットのバーンレート、つまり「バジェットを消費している速度」でアラートを出す方法です。
バーンレート = 実際の消費速度 / 許容される消費速度
> 1 : 許容より速く消費している
< 1 : バジェット内に収まっている
ただし1を超えた瞬間に鳴らすと誤検知だらけになるため、ウィンドウを分けます。ベースライン（どれだけのデータを見るか）とルックアヘッド（どれだけ先を予測するか）の比率を適切に保つことが肝で、15分のベースラインで3日先を予測すれば些細な変動でも鳴る、と警告されています。
具体例（本書の画像サーバーの例）
SLO: 99.9% / 30日ウィンドウ
30日 = 2,592,000秒
エラーバジェット = 2,592秒（43.2分）
ファストバーン: 1時間で1%消費 → 2,592 × 1% = 25.92秒
スローバーン : 1週間で10%消費 → 2,592 × 10% = 259.2秒
つまり1時間ウィンドウでは完全障害が約25秒続いた時点、1週間ウィンドウでは約259秒続いた時点でアラートを発行します。
なお、経験則として『サイトリライアビリティワークブック』の値も紹介されています。ページ（即応）は1時間で2%消費、チケット（低優先）は3日で10%消費、という水準です。
このアプローチの短所として、同一事象に対する二重アラートの可能性も正直に書かれています。監訳注では、アラートにサービス名だけでなくバージョンやリージョンといったコンテキストを含めるべき、という補足が入っています。
低トラフィックのシステムや、すでに稼働中のブラウンフィールド環境への適用方法も扱われており、実務での持ち込みやすさに配慮された章です。
9章：確率と統計
ベルヌーイ試行、期待値と中央値、最尤推定（MLE）、最大事後確率（MAP）、ベイズ推定、最高密度区間（HDI）、ポアソン分布、指数分布、キューイング理論と、かなり踏み込んだ内容です。
とはいえ著者は、この章の価値を「チームメンバーが抱いている直感を検証できること」に置いています。何も変えなくても、数式で何がわかるかを試せる。そしてチームメイトに微積分をゼロから学んでもらう必要はない、と。
数学的厳密さより、議論の出発点を作る道具としての位置づけです。数式が苦手なら飛ばしても本書の主張は追えます。
10章：アーキテクチャへの折り込み
設計に関心のある方には、ここが刺さると思います。
画像提供サービスを題材に、ハードウェア構成、モノリスかマイクロサービスか、障害形態の予測、3種類のリクエスト（同期・非同期・バッチ）の分離といった検討が進みます。
主張は明確で、SLIとSLOは設計フェーズから会話の一部に含めるべきだ、というものです。ユーザージャーニーを設計の選択に反映させることで、次のような判断ができるようになります。
- 異なるクラスのリクエストをいつどこで分離するか
- どこにキャッシュを追加するか
- どこでグレースフルデグラデーションを行うか
「計装！ システムにも計装が必要である！」という節タイトルがあるとおり、可観測性を後付けにしない設計思想が繰り返し強調されます。
11章：データの信頼性
データサービス固有の章です。可用性のようなサービス属性は基本的に一時的ですが、データの属性は永続的であるため、SLOを外したときの危険性が高い、という指摘が本質だと感じました。機密性・整合性・耐久性が損なわれると取り返しがつきません。
データ属性として、鮮度・完全性・一貫性・厳密性・妥当性・整合性・耐久性が整理されます。加えてデータアプリケーション側の属性として、セキュリティ・可用性・スケーラビリティ・パフォーマンス・回復力・堅牢性が挙げられ、データリネージにも触れられます。
「データ品質」に取り憑かれた組織への批判も辛口です。定義して計測できない限り品質は主観的なものにすぎず、SLOはその会話を定量的な枠組みに再構築する手段だ、という位置づけになっています。
12章：実例
架空の犬用衣類ECを題材に、ユーザージャーニーをSLI/SLOへ翻訳していく章です。抽象論が続いた後にこれが来るので、理解が一気に具体化します。
サンプルとして提示されるSLOは、たとえばこういった形です。
Webサイトへのレスポンスの99.9%が、
2xx / 3xx / 4xx のHTTPステータスコードを
2,000ミリ秒以内に返す
4xxを「良い」に含めるかどうかの議論も入っています。SNSで存在しないページへのリンクが拡散された場合にエラーバジェットを食い潰すのを避けたい一方で、4xxが多いのはリンク切れの兆候でもある。どちらとも言い切れない難しさが率直に書かれています。
さらに、この99.9%という数字がどう正当化されるかも書かれています。1セッションあたり平均25リンクをクリックするなら、40人に1人が1回だけ不正なレスポンスを経験する計算になる。原因となるDBの問題を解くには数四半期かかる。ユーザーはエラー1回で離脱しない。だからエンジニア・製品・ビジネスの三者が99.9%で合意した、という筋道です。
数値の妥当性を「関係者が納得できる物語」として組み立てる過程が見えるので、自分のサービスに置き換えて考えやすくなっています。検索結果ページ、チェックアウト成功率、社内データ分析、社内Wiki、コンテナプラットフォームと、性質の異なる対象が並ぶのも実践的でした。
第Ⅲ部：どう組織に根付かせるか
13章：SLO文化の構築
SLIと監視はコードを書けば追加できるが、各チームの信頼性に対する考え方をプログラミングし直すには大きな労力を要する。この対比が本章の要約になっています。
同意を得る → SLO作業を優先事項に置く → ドキュメントから始める → SLI/SLOを実装する → 活用する → 反復する、という流れが示されます。
14章：SLOの進化
SLOは目標であって契約ではない、という点が繰り返されます。柔軟であるべきで、時間とともに変わるべきものです。
見直しのトリガーとして、利用率の変化、依存関係の変更、障害に誘発される変更、ユーザーの期待や要求の変化、ツールの変更などが列挙されます。「良すぎる実行状態」も見直し対象に入っているのが面白いところです。過剰な信頼性はユーザーの期待値を無用に引き上げてしまうからです。
重要なのは、変更することそのものではなく、変更について議論する時間を取ることだと述べられています。議論した結果「現状のままでよい」と判断するのも正しい結論です。
15章：発見可能で理解可能なSLO
SLOは、書かれていても見つからなければ意味がありません。SLO定義ドキュメントに含めるべき項目が具体的に列挙されます。所有権、承認者、定義の状態、サービス概要、SLOの定義と状態、論拠、再検討スケジュール、エラーバジェットポリシー、外部リンク。
付録Aにテンプレートがそのまま載っているので、自組織に持ち込むならここから始めるのが早いです。SLI/SLOの表には、対象コンポーネント、SLIの種類、人間が読める説明、SLO、実際のクエリを並べる構成になっています。
16章：SLOの提唱
クロール → ウォーク → ラン の3段階で、組織へ広げていく道筋が描かれます。
- クロール：自分で調査し、話す内容を準備し、ドキュメントとトレーニングを作り、単一サービスでパイロット実装する
- ウォーク：初期採用者と連携して対象を広げ、成功を祝い、ケーススタディを蓄積し、トレーナーを増やす
- ラン：ケーススタディを共有し、SLOエキスパートのコミュニティを作り、継続的に改善する
過剰なくらいコミュニケーションを取り、小さな成功も祝うこと。地味ですが、この手の取り組みが失敗する理由の大半がここにあるのも事実だと思います。
17章：信頼性のレポート
著者が「読み飛ばすな」と念を押す最終章です。
まず、よくある基本的なレポートの限界が指摘されます。インシデント件数、深刻度レベル、そして MTTR のような「平均X時間」の指標です。インシデントはそれぞれ固有であり、平均値に常に意味があるとは限らない、という批判が展開されます。
代わりにSLOの状態とエラーバジェットの状態を報告することで、チーム内、他チーム、そして有償顧客との会話がそれぞれ改善される、という締め方になっています。
設計・アーキテクチャの観点で持ち帰ったこと
1. SLOは非機能要件を「交渉可能な数字」に変える
「高可用性」という言葉は、それ自体では何も決められません。SLOに落とすと、依存関係の掛け算、冗長化のコスト、リリース頻度とのトレードオフが、同じ土俵の数字として比較できるようになります。アーキテクチャ判断の根拠として使える形になる、というのが最大の効用だと感じました。
2. 依存関係の可視化が前提条件になる
0.999^40 ≈ 0.96 という計算は、裏を返せば「自分のサービスの依存対象を数え上げられていないと、そもそもSLOを決められない」ということです。強い依存を弱い依存へ変換する設計（フォールバック、キャッシュ、グレースフルデグラデーション）は、そのままアーキテクチャの改善項目になります。
3. SLOは組織の境界とセットで考える必要がある
複数チームに所有されるサービスでは、全体のSLOと各コンポーネントのSLOの両方が必要で、さらに全体SLOの所有者を明示しなければならない、と本書は述べています。所有権が曖昧なSLOは機能しません。これは技術というよりコンウェイの法則の話に近く、設計と組織を分けて考えられないことを再確認させられました。
4. 観測できないものは設計できない
10章の主張どおり、計装を後付けにすると、SLIを定義したくてもデータがないという状況に陥ります。設計段階で「このユーザージャーニーをどう二値化するか」を決めておく必要があり、これはログ設計・トレース設計の要件そのものです。
実務にどう落とすか
本書の記述を踏まえて、導入の最小手順を整理するとこうなります。
- ユーザージャーニーを1つ選ぶ（全部やろうとしない）
- 平易な日本語でSLIを1文にする（例：「トップページのレスポンスの◯%が2秒以内に返る」）
- 過去データから目標値を出す（9の数から入らない。時間換算から入るのも可）
- ウィンドウを決める（迷ったら30日ローリング）
- エラーバジェットを計算する（残量ではなく残割合で見ると直感的）
- バーンレートアラートを2本用意する（ファストバーンとスローバーン）
- SLO定義ドキュメントを付録Aのテンプレートで書く（所有者と再検討日を必ず書く）
- エラーバジェットポリシーを決める（MUST / SHOULD / MAY を使い分ける）
- 月次で見直す（最初は毎月、安定したら四半期・年次へ）
いきなり全社導入を目指さないこと、まずは自分が扱える範囲の問題で価値を示すこと。本書が繰り返し述べているのはこの点です。
読んでいて印象に残ったこと
SLOはプロセスであってプロジェクトではない
チェックリストを消し込んで終わる類のものではなく、継続的に回すものだという主張が全編を通じて繰り返されます。これは導入を検討する側にとって、期待値を正しく設定するうえで重要な前提だと思います。
すべては人に関わる
書名はSLOですが、主題は人間である、と「はじめに」で宣言されています。数式も統計も、最終的には人間が良い議論をして良い意思決定をするための道具でしかない。この視点が最後まで一貫しています。
「本書で述べることはすべて1つのモデルにすぎない」
著者自身が、SLOは万能薬ではなくアプローチにすぎないと明言しています。この謙抑さがあるおかげで、本書は教条的にならずに済んでいます。モデルにはモデルなりの誤りがあることを理解したうえで使え、という姿勢です。
気になった点
- 9章の難度が突出している。確率統計の素養がないと通読はつらいです。ただし飛ばしても他章の理解には支障ありません。
- 寄稿章が多いぶん、章ごとの温度差がある。多様な声が入る利点と引き換えに、文体や踏み込み方に揺れがあります。
- 具体的なツールの実装コードはほとんどない。「どのSaaSでどう設定するか」を期待すると肩透かしになります。原理と考え方に振り切った本です。
こんな方におすすめ
| 対象 | おすすめ度 |
|---|---|
| SLOをこれから導入したいSRE・インフラ担当 | ◎ |
| アラート疲れを解消したい運用チーム | ◎ |
| 非機能要件を数字で議論したい設計者・アーキテクト | ◎ |
| データ基盤の品質指標を整理したいデータエンジニア | ○（11章が刺さります） |
| SREの全体像をまず知りたい | △（先にSRE本のほうがよいかもしれません） |
読み方としては、まず第Ⅰ部（1〜6章）を順に通し、次に自分の関心に応じて8章（アラート）か10章（アーキテクチャ）へ。最後に17章、という順序が効率的だと感じました。9章は必要になってから戻れば十分です。
まとめ
本書は、SLOを「決めて終わり」の数字ではなく、議論と意思決定を駆動するデータとして扱うための一冊です。
- 信頼性スタック（SLI → SLO → エラーバジェット）という一貫した枠組みが最初に提示される
- 9の数から離れる、依存関係を掛け算する、SLOを増やしすぎないという具体的な指針がある
- バーンレートアラートは、閾値アラートの問題を構造的に解決する実装可能なテクニックとして提示される
- 設計・組織・報告まで射程に入っており、技術書でありながら合意形成の本でもある
そして全編を通じた主張は一貫しています。完璧である必要はないし、誰もそれを求めていない。完璧を目指すのはコストがかかりすぎる。それを受け入れたほうが、結果的に全員が満足できる。
技術的な話をしているようでいて、最後まで人間の話をしている本でした。監視やアラートの設計に手を入れたい方、非機能要件の議論を前に進めたい方には、強くおすすめできる一冊です。