--- title: "SRE本 第2版の変更点：初版との違いと読む章、SLOアラートの実装例" url: "https://www.issoh.co.jp/tech/details/18340/" published: 2026-10-14 updated: 2026-10-14 categories: ["開発"] publisher: "株式会社一創" --- # SRE本 第2版の変更点：初版との違いと読む章、SLOアラートの実装例 Googleは2026年10月13日、通称「SRE本」こと『Site Reliability Engineering』の第2版を発表しました。初版の刊行から10年での、全面的な書き直しです。本記事では、公式発表とsre.googleの記載から、第2版で何が変わったのか、初版やWorkbookとどう読み分けるのか、日本語版や無料公開の状況はどうなっているのかを整理します。あわせて、第2版が「動的なバーンレートアラート」と表現しているSLO監視の手法を、手元のPrometheusで試せる設定例として示します。 ## まとめ：SRE本第2版で変わった6領域と、今すぐ手を動かす順番 第2版は初版の改訂ではなく、全面的な書き直しです。公式ブログは、SLOとエラーバジェット、監視、自動化、信頼性テスト、キャパシティ管理、組織モデルの6領域で、初版の時代から実践がどう変わったかを対比で示しています。加えて、AIインフラをどう運用するか、AIでSRE業務をどう効率化するかという新しい論点が入りました。 2026年10月14日時点で、第2版はsre.google上で無料公開されておらず、紙版はGoogle Books、電子版はO’Reillyでの購入が案内されています。初版とWorkbookは引き続き無料で読めます。 実務の順番ははっきりしています。SLOがまだ無いチームは、第2版を待たずにWorkbookのSLO実装とアラートの章から着手してください。SLOを運用済みで、プラットフォーム化やAIワークロードの運用に悩んでいるチームは、第2版を買う価値が大きい層です。 ## 2026年10月13日のGoogle公式発表から第2版の事実関係を確認する まずは一次情報で確定している事実だけを押さえます。章立ての細部は販売ページ側でまだ確定していない部分があるため、ここでは公式ブログとsre.googleに書かれている内容に絞ります。 ### 初版から10年の全面改訂として発表された第2版の位置づけと編者6名 [Google Cloud Blogの発表記事](https://cloud.google.com/blog/products/devops-sre/sre-book-second-edition)は、2026年10月13日付でBetsy Beyer氏とDavid Huska氏が執筆したものです。初版の公開から10年の節目に、全面的に書き直した第2版を出すと説明しています。[sre.googleの書籍一覧](https://sre.google/books/)では第2版に「New!」の表示が付き、新たに扱うテーマとして信頼性の価値、クラウドの信頼性、AIの影響が挙げられています。編者はBetsy Beyer、Chris Jones、Christof Leng、David Huska、Jennifer Petoff、Niall Richard Murphyの6名です。 SREという職種や考え方そのものの定義を確認したい場合は、[SREの意味とDevOpsとの違いを整理した解説](https://www.issoh.co.jp/column/details/3080/)を先に読むと、本記事の比較が追いやすくなります。 ### 無料公開の有無と購入先、2026年10月時点の日本語版の状況 初版『Site Reliability Engineering』と『The Site Reliability Workbook』、『Building Secure and Reliable Systems』の3冊は、sre.googleで全文を無料で読めます。一方、第2版の欄には「Read online」のリンクが無く、購入リンクだけが置かれています。公式ブログが示す購入先も、紙版のGoogle Booksと電子版のO’Reillyの2つだけです。 日本語版について整理しておきます。初版の日本語訳『SRE サイトリライアビリティエンジニアリング』は[オライリー・ジャパンから2017年8月12日に発行](https://www.oreilly.co.jp/books/9784873117911/)され、590ページ・5,280円です。Workbookの日本語訳『サイトリライアビリティワークブック』は2020年6月15日の発行です。第2版の日本語訳については、2026年10月14日時点の検索で刊行情報を確認できませんでした。英語版を読むか、翻訳を待つかの判断材料として押さえておいてください。 ## 初版と第2版の違いをSLO・監視・自動化など6領域の対比表で読む 公式ブログは、初版の時代と現在の実践を6領域で並べています。表の内容をそのまま日本語に置き換えると次のとおりです。 ### 公式ブログが示した初版当時と現在の実践を6領域で並べた比較表の読み方 | 領域 | 初版の時代 | 現在の実践（中心） | 現在の実践（付随） | | ------------ | ------------------- | ---------------------- | --------------------- | | SLO・エラーバジェット | 基本的な可用性指標・手動ポリシー | ユーザー中心の多層SLO | 動的バーンレートアラート・ポリシー自動適用 | | 監視 | 静的ダッシュボード・手動のアラート対応 | OpenTelemetry | 分散トレーシング・異常の自動相関 | | 自動化 | 個別作業向けのスクリプト | Infrastructure as Code | 社内開発者プラットフォーム・自己修復 | | 信頼性テスト | 定期的なゲームデイ・合成負荷試験 | 継続的な回復性チェック | 本番環境でのカナリア検証 | | キャパシティ管理 | 手動プロビジョニング・静的な予測 | 動的オートスケーリング | FinOps・GPU/TPU向けの調整 | | 組織モデル | 特定アプリ専任のチーム | プラットフォームエンジニアリング | ハイブリッド型・信頼性チャンピオン | 表を読むと、6領域すべてで「人が手で回していた作業を、仕組みに埋め込む」方向へ寄っています。初版の原則が否定されたわけではありません。原則を実装する道具立てが入れ替わった、と読むのが正確です。 ### 監視の章で主役がOpenTelemetryと分散トレーシングに移った意味 初版の監視の考え方は、レイテンシ・トラフィック・エラー・飽和の4指標で知られています。この4指標そのものは今も有効で、[Golden Signalsの監視指標とアラート設計の実装解説](https://www.issoh.co.jp/tech/details/15714/)で具体的な計測方法を扱っています。 第2版の対比表で変わったのは、指標を集める手段です。OpenTelemetryで計装し、分散トレーシングでリクエストの経路を追い、異常の相関付けを自動化する構成が前提になりました。計装の入口は[OpenTelemetry CollectorをLinuxで動かす手順](https://www.issoh.co.jp/tech/details/3625/)で確認できます。[OpenTelemetry公式のSignalsの説明](https://opentelemetry.io/docs/concepts/signals/)にあるトレース・メトリクス・ログの3種類を、同じ仕組みで集める設計に切り替えるのが第一歩です。 ### 組織モデルの章でプラットフォームエンジニアリングが前面に出た背景 初版は、特定のサービスに専任SREチームを付ける形を中心に描いていました。第2版の対比表では、ハイブリッド型の体制、プラットフォームエンジニアリング、開発チーム内の信頼性チャンピオンが並びます。SREが全サービスを直接見るのではなく、SLOや監視、デプロイの仕組みを社内プラットフォームとして提供し、各チームが自分で使う形です。 自動化の領域にある「社内開発者プラットフォーム」と組織モデルの変化は、同じ流れの表裏です。Backstageなどで社内プラットフォームを立ち上げる手順は[プラットフォームエンジニアリングの導入手順](https://www.issoh.co.jp/tech/details/12609/)にまとめています。 ## AI時代のSREとして第2版が新たに扱うGPU運用とAI支援の論点 初版に無かった論点のうち、最も大きいのがAIです。公式ブログは「AIを運用する側」と「AIで運用する側」の2方向で整理しています。 ### GPU/TPUクラスタと非決定的な出力を監視対象にするときの論点 AIインフラの運用として挙げられているのは、GPU/TPUクラスタの信頼性、非決定的な出力とレイテンシの監視、継続的なモデル学習パイプラインの信頼性です。従来のWebサービスなら、同じリクエストには同じ応答が返る前提でエラー率を測れました。生成AIは同じ入力でも出力が変わるため、HTTPの成功率だけでは品質の劣化を検知できません。 実務上は、まずレイテンシと失敗率を従来どおりSLOで守り、出力品質は別の評価指標として切り分けるのが現実的です。両者を1つのSLOに混ぜると、どちらが悪化したのか判別できなくなります。 ### インシデント対応とポストモーテム作成に生成AIを使う範囲と人が決める部分 AIで運用を効率化する側では、インシデントのトリアージやポストモーテムの作成に生成AIを使うこと、自然言語でテレメトリを調べること、予測モデルでボトルネックを事前に見つけることが挙げられています。 ここで線を引いておくべき点があります。初版の[ポストモーテム文化の章](https://sre.google/sre-book/postmortem-culture/)が強調したのは、個人を責めずに原因を学ぶ文化でした。文章の下書きをAIに任せても、何を学び何を直すかを決めるのはチームです。公式ブログも、文化と人的要素は変わらない原則として改めて強調しています。 ## 第2版の動的なバーンレートアラートをPrometheusで試す設定手順 第2版の対比表にある「動的なバーンレートアラート」は、Workbookの[Alerting on SLOs](https://sre.google/workbook/alerting-on-slos/)で紹介された多ウィンドウ・多バーンレート方式が土台です。この章は無料で読めるため、第2版を待たずに手元で試せます。ここではPrometheusでの最小構成を示します。 ### 99.9%のSLOで使うWorkbook推奨の3組のウィンドウとバーンレート バーンレートとは、エラーバジェットを消費する速さです。30日で予算をちょうど使い切る速さを1とします。Workbookは99.9%のSLOに対して、次の3組を出発点として推奨しています。 | 通知の種類 | 長いウィンドウ | 短いウィンドウ | バーンレート | 発火時の予算消費 | | ---------- | ------- | ------- | ------ | -------- | | 呼び出し（Page） | 1時間 | 5分 | 14.4 | 2% | | 呼び出し（Page） | 6時間 | 30分 | 6 | 5% | | チケット | 3日 | 6時間 | 1 | 10% | 14.4という値は計算で確かめられます。30日は720時間なので、1時間で予算の2%を使う速さは720×0.02＝14.4です。短いウィンドウは長いウィンドウの12分の1にするのが目安とされ、障害が収まった後にアラートが早く解除される効果があります。SLOの数値そのものの決め方は[SLOの設定方法の解説](https://www.issoh.co.jp/tech/details/6080/)を参照してください。 ### エラー率の記録ルールとアラートルールを書いてpromtoolで検証する 次の設定は、`http_requests_total`というカウンタに`code`ラベルでHTTPステータスが入っている前提の例です。[Prometheusの記録ルール](https://prometheus.io/docs/prometheus/latest/configuration/recording%5Frules/)でウィンドウごとのエラー率を事前計算し、[アラートルール](https://prometheus.io/docs/prometheus/latest/configuration/alerting%5Frules/)で長短2つのウィンドウが同時に閾値を超えたときだけ発火させます。 ``` # slo-rules.yml（99.9% SLO・ページ通知の2組） groups: - name: slo-recording rules: - record: job:slo_errors_per_request:ratio_rate5m expr: sum by (job) (rate(http_requests_total{job="myjob",code=~"5.."}[5m])) / sum by (job) (rate(http_requests_total{job="myjob"}[5m])) - record: job:slo_errors_per_request:ratio_rate30m expr: sum by (job) (rate(http_requests_total{job="myjob",code=~"5.."}[30m])) / sum by (job) (rate(http_requests_total{job="myjob"}[30m])) - record: job:slo_errors_per_request:ratio_rate1h expr: sum by (job) (rate(http_requests_total{job="myjob",code=~"5.."}[1h])) / sum by (job) (rate(http_requests_total{job="myjob"}[1h])) - record: job:slo_errors_per_request:ratio_rate6h expr: sum by (job) (rate(http_requests_total{job="myjob",code=~"5.."}[6h])) / sum by (job) (rate(http_requests_total{job="myjob"}[6h])) - name: slo-alerting rules: - alert: ErrorBudgetBurnFast expr: | ( job:slo_errors_per_request:ratio_rate1h{job="myjob"} > (14.4 * 0.001) and job:slo_errors_per_request:ratio_rate5m{job="myjob"} > (14.4 * 0.001) ) or ( job:slo_errors_per_request:ratio_rate6h{job="myjob"} > (6 * 0.001) and job:slo_errors_per_request:ratio_rate30m{job="myjob"} > (6 * 0.001) ) labels: severity: page annotations: summary: "myjob のエラーバジェットが速いペースで減っています" ``` 保存したら、Prometheusに読み込ませる前に構文を検証します。 ``` promtool check rules slo-rules.yml ``` 「SUCCESS: 5 rules found」のように規則数が表示されれば読み込み可能です。`0.001`は99.9%のSLOにおける許容エラー率なので、99.5%なら`0.005`に置き換えます。チケット通知の組を足すときは、6時間と3日の記録ルールを追加し、同じ形で`severity: ticket`のルールを書きます。エラー率に何を数えるかで迷う場合は、[SLIの選び方とPromQLでの測り方](https://www.issoh.co.jp/tech/details/9177/)で指標の定義から決めてください。 ### トラフィックが少ないサービスで誤発報が増えるときの見送り判断 この方式には弱点があります。1時間に数十リクエストしか来ないサービスでは、数件の失敗だけでエラー率が跳ね上がり、夜中に呼び出しが鳴る事態になりがちです。Workbookも「Low-Traffic Services and Error Budget Alerting」という節を設けて、この問題を扱っています。 Workbookの例では、1時間に10リクエストのサービスだと1件の失敗でエラー率は10%です。判断を言い切ります。1時間あたりのリクエストが数百件に満たないサービスには、この方式をそのまま入れません。Workbookが挙げる対処のうち、合成リクエストを定期的に送って分母を増やす、障害の影響範囲を共有する複数サービスを1つのSLOにまとめる、SLOを下げるかウィンドウを長くする、のいずれかを先に決めてください。 ## SRE本第2版を待たずに初版とWorkbookから着手する章の選び方 第2版は全面改訂ですが、初版とWorkbookの基礎章は今も有効です。チームの状況別に、最初に読む章を決めておくと迷いません。 ### SLOが未整備のチームが無料公開の初版とWorkbookから読む4章の順番 SLOを持っていないチームは、次の順で無料公開の章を読み、読むたびに自分のサービスで1つ作業を終えるのが効率的です。 1. 初版の[Embracing Risk](https://sre.google/sre-book/embracing-risk/)で、100%を目指さずエラーバジェットで判断する考え方を押さえる 2. 初版の[Service Level Objectives](https://sre.google/sre-book/service-level-objectives/)で、SLI・SLO・SLAの区別を決める 3. Workbookの[Implementing SLOs](https://sre.google/workbook/implementing-slos/)で、最初のSLOを1つ書いて合意を取る 4. WorkbookのAlerting on SLOsで、前章の設定例を自分のメトリクスに合わせて入れる ここまでなら費用はかからず、数週間で運用に乗ります。第2版はこの土台ができてから読むほうが、変更点の意味が理解しやすくなります。 ### 第2版を購入して読むべきチームと、まだ購入が不要なチームを分ける条件 購入を勧めるのは、SLOとアラートを既に運用していて、次の壁に当たっているチームです。具体的には、サービス数が増えて各チームにSLOを配る仕組みが要る、GPUを含むAIワークロードを本番で動かし始めた、SREチームと開発チームの役割分担を見直したい、のいずれかに当てはまる場合です。第2版の対比表も、まさにこの領域を厚く書いています。 逆に、本番サービスが1〜2個で監視も始めたばかりの段階なら、まだ買う必要はありません。初版とWorkbookの無料章で足ります。英語の長い書籍を読み切ることより、最初のSLOを1つ動かすほうが成果に直結します。 SLOの設計やアラート運用を社内だけで回す余力が無い場合は、[保守運用と内製化支援のサービス](https://www.issoh.co.jp/service/system/maintenance/)で、監視基盤の構築から運用の引き継ぎまでを一緒に進める方法もあります。 ## よくある質問 SRE本の第2版について、検索されやすい疑問に短く答えます。 ### SRE本の第2版はいつ発表され、どこで購入できますか？ Googleが2026年10月13日にGoogle Cloud Blogで発表しました。初版の公開から10年の節目に、全面的に書き直した版という位置づけです。公式ブログでは、紙版はGoogle Books、電子版はO’Reillyでの購入が案内されています。sre.googleの書籍一覧にも第2版の購入リンクがあります。価格や発売日の詳細は販売ページ側で確認してください。 ### SRE本の第2版は初版のように無料で読めますか？ 2026年10月14日時点で、sre.googleには第2版のオンライン閲覧リンクがありません。初版、The Site Reliability Workbook、Building Secure and Reliable Systemsの3冊は従来どおり無料で全文を読めます。SLOやアラートの基礎は無料の章で学べるため、まずそちらから読み、必要になった段階で第2版を購入する順番で問題ありません。 ### SRE本の第2版に日本語版はありますか？ 2026年10月14日時点の検索では、第2版の日本語訳の刊行情報は確認できませんでした。初版の日本語訳は2017年8月、Workbookの日本語訳は2020年6月にオライリー・ジャパンから出ていますが、いずれも英語版の刊行から1年以上後でした。日本語で基礎を固めたい場合は、初版とWorkbookの日本語版を読むのが現実的です。 ### SRE本の初版は第2版が出た今でも読む価値がありますか？ あります。公式ブログの対比表は、SLOとエラーバジェットを6領域の先頭に置いたまま、その運用方法の変化を示す構成です。文化と人的要素も変わらない原則として改めて強調されています。第2版の変化は主に、原則を実装する手段がOpenTelemetryや社内プラットフォームに移ったことです。原則を初版で理解してから第2版を読むと、何が変わったのかを区別しやすくなります。 ### SRE本の第2版は何から読み始めるのがよいですか？ 自分のチームの課題に近い領域から読むのが近道です。SLOが未整備なら、第2版より先にWorkbookのSLO実装とアラートの章を読み、設定を1つ動かしてください。プラットフォーム化やAIワークロードの運用が課題なら、公式ブログの6領域比較で該当する領域を確認し、第2版の対応部分から読み始めると効率的です。 ## 関連記事 - [SREとは？サイト信頼性エンジニアリングの意味・DevOpsとの違い](https://www.issoh.co.jp/column/details/3080/)：SREの定義と役割を整理した入門記事です。 - [Golden Signals（4つのゴールデンシグナル）とは？SREの監視指標と実装](https://www.issoh.co.jp/tech/details/15714/)：初版由来の4指標を計測・アラートに落とす手順です。 - [SLIとは？SLOとの違いと指標の選び方・PromQLでの測り方](https://www.issoh.co.jp/tech/details/9177/)：バーンレートの分母と分子に何を数えるかを決める記事です。 - [Platform Engineering（プラットフォームエンジニアリング）とは？](https://www.issoh.co.jp/tech/details/12609/)：第2版の組織モデルの変化に対応する実装手順です。 - [保守運用 / 内製化支援](https://www.issoh.co.jp/service/system/maintenance/)：SLO設計と監視基盤の構築・運用移管の相談窓口です。 --- 出典: [SRE本 第2版の変更点：初版との違いと読む章、SLOアラートの実装例]()（株式会社一創）