SRE Book 第2版はアラーティングについてどこで何を述べているか

# SRE Book 第2版はアラーティングについてどこで何を述べているか ## 結論 [[Site Reliability Engineering 2nd Edition]] には、アラーティング(alert / alerting / page / paging / pager)への言及が前付けを含む 39 ファイル中 27 ファイルにあり、節単位でまとめると **145 箇所** になる。アラート設計を正面から論じるのは次の 4 か所である。 - **第8章「Service Level Objectives」**: SLO 定義からアラートルールを自動生成する仕組み。fast burn(エラーバジェットの 2% を 1 時間で消費するとページ)と slow burn(10% を 3 日で消費するとチケット)の 2 段構成、低トラフィック向けの二項検定、顧客単位 SLO のアラート。 - **第9章「Observability and Monitoring」**: 静的閾値から統計的なアラーティングへの移行。高カーディナリティ次元の生カウント閾値がアラート疲労を生む仕組みと、二項分布の信頼区間(エラー率)およびコホートと z スコア(レイテンシ)による解法。 - **付録 F・G**: 第9章の手法の数理。レイテンシアラートの定式化(F)、Wilson 区間による二項モデルと周期的メトリクスへの機械学習(G)。 - **第10章「Incident Management and On-Call」と第13章「Automation and Tooling」**: ページング負荷、応答時間、アクションにつながらないアラートの測定、ページの転送というアンチパターン。それ以外の約 110 箇所は、別の主題を論じる途中でアラートに触れている。用語について: 原文では「ページ(page)」が「オンコール担当者を呼び出す緊急アラート」を指し、「チケット」と対になる。「ページャーを持つ(hold the pager)」は「オンコール責任を負う」の言い換えである(第2章の脚注は、呼称が物理的なポケベルに由来すると説明している)。以下の抜粋はこの意味の page / paging をすべて含み、"web page" のような無関係な用法は除いた。 ## 横断して見える論点章をまたいで繰り返し出てくる主張を、関連箇所とあわせて整理する。 1. **アラートは実行可能で、ユーザーが感じる症状に基づくべきだ**。第2章「Observability」、第9章「From Static Thresholds to Intelligent Alerting」(第1版の症状ベース原則に、症状が本当に重大かを判定する層を加えた)、第22章「Prioritization is key」「Heterogeneity and silos」で繰り返される。関連: [[アクショナブルアラート]] 2. **静的閾値から統計的な閾値へ**。第8章(二項検定、Wilson score interval)、第9章(二項分布の信頼区間、コホートと z スコア)、付録 F・G。トラフィック量に応じて許容幅が自動的に変わる点が静的閾値との違いである。関連: [[確率的アラート設計]] 3. **アラートは SLO とエラーバジェットから導く**。第8章のバーンレートアラートと自動生成、第14章の品質 SLI へのバーンレートアラート適用。ただし第8章の結論は「すべての SLO にアラートが要るわけではない」とも述べる。関連: [[サービスレベル目標]]、[[エラーバジェット]] 4. **ページ負荷は持続可能性とトイルの指標である**。第1章(ページ対応は運用過負荷の最もわかりやすい形)、第4章(インシデント当たりのページ数)、第10章(1 シフト最大 2 件)、第13章(20 件に 1 件しか重大障害を示さないアラート)、付録 D(週次のページ数レビュー)。関連: [[トイル]]、[[アラート疲労]] 5. **ページャーの所在は組織設計の論点になる**。第2章・第4章(ページャーを開発チームへ返す)、第6章(Spotify では所有チームがアラートを管理する)、第7章(「誰がページャーを持つか」を中心に組んだ階層型モデルの失敗)。関連: [[オンコール]] 6. **アラート発火後の調査と緩和を自動化する**。第9章(アラートに応じて自動生成されるダッシュボードとオートプレイブック)、第13章(アラートの拡充と自動緩和)、第21章(AI Operator がアラートの最初の対応者になる)。 7. **アラートの誤発報は自動化の危険要因になる**。第13章は、誤検知による全面アラートが完全自動化を危険にする例を挙げ、安全閾値を超えたら自動化を止めて人間にアラートする仕組みを説く。 ## 章別の抜粋各項目は「節見出し(原文の行番号)」のあとに、その箇所が言っていることと、なぜそこでアラートが出てくるかを書く。**太字** はアラート設計そのものを論じる箇所である。行番号は `.raw/books/site-reliability-engineering-2e/` 配下の Markdown のもの。 ### 前付け(Preface、Part III 扉) - *Practitioners: Technical Implementation and Operations*(preface L85): 実践者向けに第8章を紹介する文で、SLI の定義やエラーバジェットの設定と並べて「アラートルールの書き方」を挙げる。 - *Part III*(part-3 L7): 第9章を紹介し、インテリジェントなアラーティングと機械学習、動的に生成されるダッシュボードがトイルの削減と緩和までの時間の短縮に効くと述べる。 - *Part III*(part-3 L9): 予防策が破れてアラートが発火したら人間の対応者が引き継ぐとし、第10章のオンコールとインシデント対応へ読者を導く。Part III は SLO → 監視 → オンコール → ポストモーテムの順に並び、アラートは観測と対応をつなぐものとして置かれている。 ### 第1章 Introduction: Modeling What We Do and Why 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 1 Introduction - Modeling What We Do and Why]] - *Situational Awareness*(L165): アラーティングを、SLO 違反などの重要なメトリクス変化を自動で知らせる仕組みとして説明し、ダッシュボードと並ぶ状況認識の手段に位置づける。 - *Situational Awareness*(L167): 運用過負荷の最もわかりやすい形として、オンコール(ページ対応)とオンデューティ(チケット処理)を挙げる。トイルを測る重要性を論じる段落の例示である。 ### 第2章 The Value of Reliability 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 2 The Value of Reliability]] - ***Within the SRE Team*(L93、脚注 L249)**: インシデントのアラート(ページ)が頻発してチームの健全性を損なうなら、SRE はページャーを開発チームへ返せる。品質の低いサービスが士気に与える影響を論じる節で、深夜の呼び出しの苦痛に触れたうえで、開発と運用の利害をそろえる仕組みとして説明される。 - ***Observability*(L183)**: 監視は機械に任せ、問題があるときだけエンジニアにアラートを送るべきだとする。アラートは実行可能で、ユーザー体験の悪化を反映するものに絞る。CI/CD の話題に続く小節で、計装の重要性とあわせて述べられる。 - *What to Consider When Adopting SRE*(L227): SLO、実行可能なアラーティング、トイル削減といった基本実践を、まず重要サービス 1 つで試すことを勧める。 ### 第3章 Trends in Production - *The AI Infrastructure Explosion*(L197): デプロイ済み AI モデルを継続的に監視し、データドリフトやモデル劣化を検知したら自動でアラートと再学習を起動すると述べる。AI 運用の各段階を概観する中での言及である。 ### 第4章 The Cultural Context of SRE 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 4 The Cultural Context of SRE]] - *Data-driven mindset*(L49): メトリクスを整える目的の一つに「問題が起きたらアラートする」を挙げる(ほかは目標達成度の測定と根本原因のデバッグ)。 - *Data-driven mindset*(L57): ポストモーテムの初稿作成や公開の遅れを直すため、所要時間に SLO を設け、その遵守をダッシュボード・アラート・経営層向けレポートで追跡した Google の例。測定文化が信頼性以外の業務にも及ぶ例として出てくる。 - ***Data-driven mindset*(L71)**: インシデント関連メトリクスの一つに「インシデント当たりのページ数」を挙げる。1 件のインシデントにアラートが多すぎると、オンコール担当者の注意が散って状況把握が難しくなる。「実行不能なインシデントの割合」「手動で検知したインシデントの割合」と並ぶ。 - *Empowerment*(L182): 手作業が多すぎるとき、SRE マネージャーは開発側と協議して新機能のリリースを止められる。極端に不安定な場合はページャーを開発チームへ返す判断もできる。 - *Benchmarking Culture Through Confidence*(L309、L332): SRE EDU の効果測定アンケートに「監視とアラーティングを使ってサービスについて合理的な判断を下す」という設問がある。表 4-3 はこの項目の自信度の伸びを、研修直後 +49pp、1 か月後 +26pp、6 か月後 +43pp と示す。 - *Tailoring Training to Different Audiences*(L352): 変化を広める人が語る成功談の例として、SRE の導入で深夜にページで起こされる回数が大きく減った話を挙げる。 - *Establish operational readiness from the start*(L504): 新規プロジェクトで最初から整えるべき実務として、アラートへの対応方法を含むランブックとプレイブックの文書化を挙げる。 ### 第5章 SRE Hiring, Training, and Career Management 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 5 SRE Hiring, Training, and Career Management]] - *Types of SRE training*(L322): SRE EDU の障害演習環境には、監視・コード・ネットワークに加えて、オンコールローテーションつきのページャーキューが組み込まれている。 - *Types of SRE training*(L342): 「Going On-Call」カリキュラムの目的は、これからページャーを持つエンジニアに知識と自信を与えることだとする。 - ***The Keys to a Successful SRE Career / Breadth*(L442)**: ジュニア SRE の仕事の例として「担当サービスのアラート品質を改善する」、シニア SRE の例として「プロダクト領域全体のアラーティングの原則・テンプレート・ライブラリの設計を主導する」を挙げ、キャリア段階による影響範囲の差を示す。 - ***Initiative*(L452)**: 同じ例を続け、ジュニアはメトリクスと閾値の調整をチームに提案して合意を取り、シニアは複数チームとリーダーを巻き込んで新しい標準を採用させる、と主体性の違いを説明する。 ### 第6章 Organizational Structures for SRE 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 6 Organizational Structures for SRE]] - *Reliability Ownership Without a Centralized SRE Organization*(L117): Spotify では、サービスを所有するチームがオンコールローテーション、ハンドブック、アラート、監視を自分たちで管理する。 - ***同節*(L127)**: 自分たちで作ったものにオンコールするなら、ノイズの多いアラートや遅い緩和がそのチームの時間コストとして直接見える。開発と運用の所有権を一体にするとフィードバックループが閉じる、という主張の根拠である。 - *Scaling the Model*(L185): Spotify のプラットフォームは、標準の監視とアラーティング設定を通じて、既定のダッシュボード、標準アラート、一貫したサービスレベルのシグナルを各チームに配る。 - *Case Study: ProdEx*(L458): Google の本番運用評価プログラム ProdEx が集計する指標の一つに「アラーティング品質」がある。オンコール負荷やポストモーテム、SLO と並ぶ。 ### 第7章 SRE Engagement Models 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 7 SRE Engagement Models]] - *Scoping SRE Engagements*(L111): 組織構造とエンゲージメントモデルを分けて考えるための問いとして、「SRE はページャーを持つか」を後者の論点に挙げる。 - ***Scoping Considerations*(L161)**: エンベデッド方式で入った SRE がインシデント対応の唯一のページャー保持者になるべきではない。サービスが専任モデルへ移るにつれてオンコールの構成も変わる。 - *The Early Engagement Model (PRRs)*(L261): PRR の典型的な改善項目の一つに「ページャーとチケットの負荷削減」がある。 - ***A Tiered Engagement Model*(L308)**: 3 段階の階層型モデルの最大の問題は、オンコール責任を軸に組まれていたことだと総括する。議論が常に「誰がページャーを持つか」に集中し、SRE のフルサポートが「最良」と見なされてしまった。 - *Persistent Disk / Old Model*(L343): 旧モデルでは、SRE は相手側のマネージャーから直接仕事を割り当てられ、その中にアラーティングや可観測性の機能追加が含まれていた。 - ***Persistent Disk / Evolution*(L355)**: 新モデルへ移る際、SRE が常に提供する基盤的な責務として「経験のあるインシデント対応チームがプロダクトの SLO アラートに対応すること」が合意された。 - ***Persistent Disk / Results*(L370)**: 移行期に最も目立った摩擦はアラート設定だった。開発チームがこれまで SRE に任せていた機能のアラートを自分で作る必要が生じ、SRE は開発チームがアラートを作ってデプロイしやすくする仕組みづくりに取り組んだ。 - ***The Azure SRE Playbook*(L418)**: Azure のエンゲージメント第 3 段階「運用効率」では、緩和までの時間やインシデント件数と並んで、アラーティングのノイズと「正しいオンコールキューへ振り分けられたアラートの割合」を改善対象にする。 - ***How Disney Organizes On-Call*(L543)**: Disney の SRE は、アラート品質の改善、エスカレーション経路の明確化、トイルの削減によって、人間的で持続可能なオンコールを設計する。 - ***Service Lifecycle Engagement*(L631)**: 開発チームが去ったあとも SRE がオンコールを続けて保守に縛られる状態を「ページャーを持ち続ける」と呼び、アンチパターンとして退ける。計画的な引き継ぎの必要性を説く文脈である。 ### 第8章 Service Level Objectives 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 8 Service Level Objectives]] - *The Basics of SLOs*(L59): 用語集でバーンレートを定義する。1 はエラーバジェットが想定どおりの速さで減る状態を指す。バーンレートで SLO のアラートを出せば、恣意的でノイズの多い閾値から離れ、インシデントの実際の深刻度に基づいてアラートできる。 - *Why Not 100%?*(L115): 図 8-1 で、信頼性に割く工数の例としてページャーローテーションと週次のバグトリアージを挙げる(定常業務として工数の 10〜15%)。 - *Pitfalls and Remedies in SLO Adoption*(L137): SLO の監視・アラーティング・報告に使うソフトウェアは多くの組織ですでに手に入る。難しいのはソフトウェア以外の部分(テンプレートや指針の整備)だ、という主張の一部である。 - ***Per-Customer SLOs*(L159、L161)**: 従来の定石は、サービス全体の CUJ ベース SLO とサービス全体のアラートで足りるというものだった。しかし重要な顧客が偏って存在すると、その顧客の障害は全体向けの SLO アラートを発火させないまま顧客を苦しめ、事業を損なう。 - ***The Motivation for Per-Customer Reliability*(L169、L171)**: 顧客単位 SLO があれば、顧客が気づく前に提供側から問題を検知できる(Google Cloud で早期検知と緩和につながった例が多数ある)。顧客単位のアラートは影響範囲の絞り込みが速く、サポート・SRE・開発のオンコールを素早く動員できる。 - ***How to Implement Per-Customer SLOs*(L177)**: 顧客単位 SLO の実装では、対象範囲・閾値・アラートの仕組みを、効率と運用負荷の両面から意図して選ぶ必要がある。 - *Scope: Selecting workloads and SLIs*(L185): 監視とアラートのカバレッジは顧客の重要なワークロードを優先する。どれが重要かは顧客自身が教えてくれるのが理想である。 - ***SLO thresholds and burn rate*(L197、L205)**: ノイズを許容範囲に収めるには、「少し劣化している」ではなく「本当に落ちている」状態を表すアラートを定義する。顧客単位でもバーンレートアラートは使えるが、小さな顧客では統計的なゆらぎだけでノイズが増える。 - ***Operationalizing Per-Customer SLOs*(L209)**: 運用上の課題の一つはアラートの忠実度を保つことだ。個々の顧客のワークロードが変わるとアラートはすぐ古くなってノイズになる。トイルを避けるには質が高く実行可能なアラートが要る。 - *High Noise Floor*(L261): クライアント側 SLO はノイズフロアが高く、非常に緩い目標にせざるを得ない。その結果、ページを伴う fast burn アラートがそもそも発火しえない状況が生じる。サーバー側の前提(エラーバジェットの大半は本物の障害で消費される)が崩れる、という文脈である。 - *SLO Tooling and Support Mechanisms*(L285): 可観測性製品ごとに SLO の実装は違うが、バーンレートに基づくアラーティングについては業界で合意ができている。 - ***Automatic Alert Configurations on SLOs*(L291〜L301)**: Google は SLO 定義からアラートルールを自動生成する集中型のアラート設定サービスを作った。生成されるのは 2 種類で、fast burn はエラーバジェットの 2% を 1 時間で消費したらオンコールをページし、slow burn は 10% を 3 日の窓で消費したらチケットを起票する(SLO 全体の窓は 30 日)。ルールはマルチウィンドウ・マルチバーンレート型の計算を多く含み、サービスが回復すればアラートも収まるように作られている。1 時間 100 リクエスト未満のような低トラフィックのサービスには、二項検定(Wilson score interval)で「SLO を満たせない確信度」を測る方法を使い、トラフィック帯ごとに手で決めていたバーンレート閾値を置き換えた。本書で最もまとまったアラート設計の記述の一つである。 - *Conclusion*(L345): すべての API やユーザー操作に SLO を置くべきではなく、すべての SLO にアラートが必要なわけでもない。SLO の目的は組織の合意形成にある、という結びの主張を補強する一文である。 ### 第9章 Observability and Monitoring 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]] - ***From Monitoring to Observability: A Modern Approach*(L87、L92)**: マイクロサービスの時代には、サービスごとにダッシュボードとアラートを手で設定するのは事実上不可能になった。複雑さへの対処として、既製のダッシュボード、インテリジェントなアラーティング、自動緩和の 3 本柱を示し、以下の節の予告とする。 - ***From Static Thresholds to Intelligent Alerting*(L107〜L117)**: サービスごとの個別設定は死角を生む。RPC エラー率に一律の静的閾値(例: 0.05%)を置くと、低トラフィックのサービスではオンコール担当者を無駄に起こし、高トラフィックのサービスでは検知が甘くなる。そこで統計や機械学習で正常なベースラインを学び、逸脱をアラートする方式へ移った。第1版の「症状でアラートする」原則に、その症状が本当に重大かを判定する層を加えたことで、アラート疲労を大きく減らしたという。Google で全社共通に設定したアラートは、SRE が扱うアラート全体のほぼ 5 分の 1 を占める。TPU や共有認証ライブラリのような特定の部分集合に対する「水平アラート」を専門チームが整えて全社に展開する体制や、AI による異常検知でノイズを減らし閾値を動的に調整する取り組みにも触れる。前節のダッシュボード自動化を受けて、次はアラートだという流れで始まる。 - ***From Investigation to Automatic Mitigation*(L121、L123、L125)**: 従来はアラートが発火すると SRE が複数のダッシュボードを手で見て回っていた。今はアラートに応じて、その発火時によく確認される症状をまとめたダッシュボードを自動生成し、調査時間を縮める。可能なら緩和策まで提案し、発火のたびにその場で「オートプレイブック」を作る。トイル削減の原則の直接の応用と位置づけられる。 - *High-Availability Telemetry*(L141、L149〜L151、L167、L181): 高可用性テレメトリの目的は遅延の小さいデータ配信であり、即時のアラートを可能にする。用途の一つとして、重要メトリクスが閾値を超えたらアラートを出すことを挙げ、パイプラインは重要なアラートや制御信号を失わない信頼性を要すると述べる。テレメトリを高可用性系と分析系に分ける議論の中での言及である。 - *Design Considerations(Tip)*(L261): メモリや SSD、階層型メモリを使った低遅延の構成を勧め、アラートのクエリ遅延はインデックス、ヘッジドリード、マテリアライズドビューでさらに縮められるとする。 - *Seamless User Experience*(L275): 利用者は 2 種類のテレメトリを意識せず、単一のライブラリと UI でデータ保持やアラートを一貫して設定できるべきだとする。 - *Case Study: Waze Telemetry over Time*(L362): テレメトリの移行では、アラートとダッシュボードを壊さないよう慎重に進めるか、痛みを短くするため速く進めるかの判断が繰り返し問題になった。 - *Present Challenges and the Future*(L368): OpenTelemetry を使っていても基盤ごとに挙動が違うため、バックエンドを乗り換えるとダッシュボードやアラートの作り直しに大きな手間がかかる。 - *クライアントテレメトリの節*(L490): 端末の母数が十分大きければ、多数の端末から届く障害シグナルでリアルタイムのアラートが可能になる。アラート用のテレメトリを別の層に分けて鮮度を上げる案にも触れる。 - *Measuring Experienced Reliability / Defense in Depth / Automated CUJ change supervision / Supporting infrastructure*(L538、L556、L564、L572、L601、L603): CUJ に基づく顧客中心の監視の文脈で繰り返し現れる。CUJ・SLI・SLO を統合した基盤は時宜を得たアラートを可能にする(L538)。CUJ に関わる異常を見つけた自動化はアラートを出すか変更管理の措置を取る(L556)。ロールアウトの自動監視は、止めるべきときにエンジニアへアラートする(L564)。早く自動で検知すれば、本来ならオンコールがページされたはずの緊急インシデントの修正コストが下がる(L572)。CUJ が劣化してアラートが発火したときに関連情報をすぐ結びつけて見せることが、統合の最も重要な点だ(L601)。AI の進歩で、より精密で実行可能なアラートを異常検知から出せるようになる(L603)。システムの指標は正常なのにユーザーが重要な操作を終えられない、という失敗様式を捉えるための議論であり、アラートのルール設計そのものは論じていない。 - *Google's Strategic Approach to Data Retention*(L651): アラートや SLO 違反の調査に使う重要な時系列は、高い頻度で収集して保持すべきだとする。 - *Data Categorization*(L700): テレメトリ全体を顧客データに分類すると、社内向けアラートのツールまで最も機微な顧客データと同じ厳しい基準に縛られてしまう。 - ***Variation-Based Monitoring and Statistics / Understanding the Limits: Cardinality and Noise*(L786、L802〜L806)**: ページングのシグナル対ノイズ比を大きく改善する統計的な手法を導入すると宣言する。高カーディナリティ次元の生カウントに基づくルール(例: あるクライアントバージョンのエラーが毎分 10 件を超えたらページ)は、低トラフィックのクライアントの偶然のゆらぎで頻繁に誤発火する。ページされたエンジニアはやがてそれを無視し、アラート全体の価値が損なわれる。対策は、生カウントではなく統計的に有意な逸脱でアラートすることだ。 - ***Alerting with the Binomial Distribution*(L808〜L833)**: 各リクエストの成否をベルヌーイ試行と見なし、区間ごとの試行数 n と失敗数 k から真の失敗率 p の信頼区間を計算する。SLO から許容できない失敗率 p_slo を決め、信頼区間の下限が p_slo を上回ったときだけページする。「エラーが 10 件を超えたら」のような静的閾値に比べ、低トラフィック時の誤検知を自動で除ける。図 9-7 は、エラー率が閾値の上下を何度も行き来しても誤発火せず、統計的に有意な変化のときだけ発火する様子を示す。章内で最もアルゴリズムに踏み込んだ節である。 - *Composing SLOs*(L837): 二項分布によるアラートは単一サービスを対象にしたもので、この節からは同じ考え方を依存関係をまたぐ SLO の設計に広げる、とつなぐ。 - ***Extending Confidence Intervals to Relative Metrics: Alerting on Latencies*(L861〜L871)**: レイテンシのように良し悪しの絶対基準がない指標に「8 時間を超えたらアラート」のような固定閾値は意味がない。問いを「このクエリはいつもより遅いか」に変える。性能の似たクエリをコホートにまとめ、過去 30 日の平均と標準偏差からコホートごとのベースラインを作る。あるコホートで平均から大きく外れる(z スコアの大きい)クエリが急に増えたら、リグレッションの強いシグナルとしてアラートする。数理は付録 F にある。 - *Observability and AI / AI Approaches to Proactive Monitoring*(L881、L887、L891): 従来の運用は、SLI を作り、静的な SLO を決め、アラートを設定し、ダッシュボードを作るという受け身のものだった。AI の異常検知は微妙な変化を見つけ、SRE とアラートシステムの両方に知見を渡して早期の検知と緩和を助ける。従来ならアラートに値しないとされた、特定地域の特定タスクでの小さく持続するレイテンシ増加を、障害の予兆として捉える例を挙げる。 ### 第10章 Incident Management and On-Call 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]] - *Foundations of On-Call*(L31): オンコールローテーションが担う仕事の筆頭に、自動アラートへの応答を挙げる(ほかは緊急の運用作業とインシデント管理)。 - *Structuring an On-Call Rotation*(L39): ローテーション設計の考慮事項の一つにページング負荷を挙げる(ほかは稼働時間、応答時間、システムの特性、顧客の要求)。 - ***Optimal Paging Load*(L41〜L47)**: SRE 1 人が扱うのは 1 シフトあたり最大 2 件のインシデント(1 件 4〜6 時間)が理想だとする。多すぎると対応が遅れ、アラート疲労で重大なアラートを見落とす。少なすぎても経験不足で対応の質が落ちる。めったにページされないサービスは、そもそも SRE の支援を正当化できないとも述べる。 - ***Response Time to Notifications*(L71〜L77)**: 5 分以内に通話へ加わる必要のあるサービスもあれば、30〜60 分で足りるものもある。3 分以内の応答が要るローテーションには当番が最低 2 人要る。ページを全員に同時に送る構成と、一次対応者から順に送る「アラート順序」を決める構成がある。応答時間の要件は、サービスの財務・評判上のリスクや SLO から決まる。 - *Escalation Rotations*(L99): 複雑で長引くインシデントでは、エスカレーション用のローテーション、特にインシデント対応チーム(IRT)が呼び出される。 - *Incident Response Teams*(L105、L123): IRT は、インシデントが複数のサービスやチームにまたがるか初動の手に余るときにエスカレーションで入り、条件によっては直接呼び出される。IRT の役割の一つに「誰を呼び出すべきかを知っている」ことを挙げる。 - ***Small organizations: Bootstrapping the first IRT*(L175、L177)**: 小さな組織では専任の IRT を置くほどページが来ない。シニアエンジニアが有志でエスカレーションローテーションに入り、大きなインシデントのときに呼び出される「インシデントごとに集まる方式」を勧める。 - ***Potential Drawbacks: Engagement latency*(L219)**: IRT を呼ぶのをためらい、自力で直そうとして事態を悪化させるチームがあると警告する。IRT は早く関与させるほど価値が大きい。 - *Detection*(L261): インシデント検知の典型として、SLO などの監視に基づく自動アラートを挙げる(ほかは顧客からの問い合わせとエンジニアの気づき)。 - *Triage*(L284): トリアージの精度を上げる実践として、自動アラートを顧客サポートへの報告と突き合わせ、影響範囲をはっきりさせることを勧める。 - *Investigation: OODA*(L309): OODA による調査で、対応者は状況把握にアラート、ダッシュボード、ログ、構成図を使う。 - *Learning*(L364): 事後の学習のため、発火したアラートやシグナルを記録しておくと振り返りの質と速さが上がる。参加者と役割、メモとチャットログ、タイムラインと並ぶ記録項目である。 - ***Collaboration and Communication*(L368〜L376)**: 理想は、アラートが最適な対応者(将来はエージェント)へ直接届くことだ。人を巻き込むのをためらって誰をページすべきかわからなくなる問題を指摘し、呼び出し先の明確な一覧を整えるよう勧める。ページされた人は対応に集中し、不要になれば抜ける。気軽なチャットより明示的なページのほうが「緊急に必要とされている」ことをはっきり伝えられる。ページを基本とする規範には、呼ばれるまでは集中作業に入っていられる利点もある。 - *Training and Development*(L418): 定例のプロダクションレビュー会議で、直近の障害の分析とあわせてページングイベントを振り返る。 - *The Role of AI in Incident Response: Investigation*(L502): AI が調査用のダッシュボードを動的に作るとき、発火したアラートの意図を分析材料の一つに使う。 - ***Case Study: Etsy / Detection and declaration*(L582)**: Etsy のインシデントツールは監視アラートからの自動起票に対応し、手動起票は「何かおかしいが目立つアラートがない」ときに使う。 - ***The LSE coordinator role*(L590)**: 重大度の高いインシデントでは、Etsy のツールが大規模イベント(LSE)のオンコール担当者を自動でページして体制に加え、判断の負担を減らす。 ### 第11章 Learning from Incidents 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 11 Learning from Incidents]] - *Timeline: Tuesday, 25 April 2023*(L177〜L189): パリのデータセンターの浸水・火災による停電の時系列。17:25 に最初の自動アラートが発火し、エンジニアは数分で確認して調査を始めた。19:17 には顧客向け連絡を担う Cloud のプロダクトコミュニケーションリードが呼び込まれた。 - ***Analysis*(L253、L259)**: 対応体制の最大の穴は、単一プロダクトでもオンコールローテーションが複数あり、担当者が段階的に呼び込まれたことだった。一方、コミュニケーションリードを呼び込んだことは顧客連絡の改善に効いた「うまくいった点」と評価される。 - ***Action Items*(L267)**: その成功を受けて、以後すべての重大障害でコミュニケーションリードを自動でページする仕組みを入れた。手作業でうまくいった対応を、恒久的な自動ページングに格上げした例である。 ### 第12章 Safety Engineering for SRE with STPA and CAST 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 12 Safety Engineering for SRE with STPA and CAST]] - *章冒頭*(L5): 2019 年の Google マップ日本の障害で、SRE がページされて開発チームと協力して緩和したと述べる。本章の題材紹介であり、分析の主題はページングではない。 - *Step 2: Model the System*(L120): STPA の制御構造の例として、エンジニアの判断規則「アラートと顧客からのエスカレーションが本番の不調を示すなら、直近のバージョンとの相関を確かめてロールバックする」を示す。 - *Applying STPA: Results and return on investment*(L242): STPA で見つかった改善の一つに、データ不整合の監視とアラートの実装がある。 - *Applying CAST*(L427): 都市名の誤表記インシデントへの CAST 分析から、よく描画される地図要素(都市に限らない)ごとにプローブアラートを作り、安定しているはずのデータの変化をすぐ知らせる案が出る。 - *Why STPA?*(L438): 将来の障害シナリオを先に見通せるなら、どのアラートをどの閾値で出すべきかも正確にわかるはずだ、という思考実験の中での言及である。 ### 第13章 Automation and Tooling 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 13 Automation and Tooling]] - ***Example: Incident Management / Automating impact analysis and contextual insights*(L152)**: インシデント対応管理の基盤では、アラートをあらゆる可観測性ソースの相関シグナルで補強し、顧客影響の印付け、異常パターンの強調、依存先の関連インシデントの結びつけを自動化する。 - *Facilitating action*(L156): アラートの性質に応じて、ロールバックやトラフィック切り替えといった自動緩和を提案・実行できる。 - ***Automated hardware fault mitigation*(L246、L250)**: 手作業ではオペレーターがアラートを見てネットワーク機器の設定を変えていたが、これを自動化する例。誤ったシグナル(全機器に誤ってアラートするバグなど)は健全な設備からトラフィックを逸らしてもっと大きな障害を招くため、安全閾値を超えたら自動化を止めて人間にアラートする仕組みを組み込んでいる。 - *From Toil to Automation: A Practical Framework*(L272): 定例のプロダクションレビューで、前期間のページや割り込みなど繰り返し起きるトイルの原因を分析することが、自動化のフィードバックループになる。 - ***Important Early Considerations*(L298)**: アラートに反応して動く自動化を例に、初期段階では安全機構・監視・監督を足すべきだとする。自動化が動くたびにチームへアラートを送り、誤検知と見逃しを確かめながら段階的に導入する。 - ***Measuring Operational Workload*(L358、L360)**: トイルの測定として、アクションにつながらないアラートを数えるべきだとする。20 件に 1 件しか重大障害を示さないアラートは改善が要る。どれだけのアラートがアクションにつながったかを定期的に見直し、その比率を上げる。Google の最重要サービスの一部は長年の改善でページ負荷が非常に低く、ページが来ること自体が重大な問題を意味する。 - ***Identify issues early*(L374、L376)**: 新サービスの立ち上げ時に「監視とアラートはどう設計されているか」「直近 1 か月にページ対象のイベントは何件あったか」を問う。立ち上げ後は、来たページ(過敏でないか)と、来るべきだったのに来なかったページ(例: トップページ全体が落ちたのにロールアウト失敗としか通知されなかった)の両方を見る。 - ***Recognize the real problem*(L390)**: 通知を読んで別チームに回すだけの「中継役」になるアンチパターンを批判する。ページや割り込みは受けた本人が対処できるものであるべきで、別チームの対応が必要ならそのチームが直接ページを受けるべきだ。 - *"Someone else will take care of it."*(L420): トイルを担当サービスのオンコールでないチームに外注すると、そのチームは制御できない問題でページされ、成果も見えないまま働くことになると警告する。 - ***Toiling to apply human judgment*(L452)**: データベース復旧をあえて完全自動化しなかった判断を裏付ける例。監視系の不具合でシステム中のすべてのアラートが誤発火したことがあり、完全自動化していたら不要な復元が走って最新のユーザー更新が失われていた。 ### 第14章 Testing 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 14 Testing]] - *Configuration basics*(L148): 本番の状態と構成管理の値がずれる構成ドリフトについて、成熟した組織は差分を検知したらアラートし、さらに進むとアラートの代わりに自動で差分を直す仕組みへ移る。 - *Monitoring pre-production*(L171〜L173): テストは「本番前の監視」であり、監視が何を検知しているかを見てその条件をテストに翻訳せよとする。テストが揃っていれば、アラートが発火したときの仮説検証の足場になる。 - *Modeling service-level tests*(L237〜L239): DiRT 用のテスト分類表に「監視とアラーティング」の項目があり、適切なアラートが発火するかを確かめる。実際の DiRT ではしばしば監視不足が見つかり、この領域は発見の多い調査対象だったと振り返る。 - *Benefits Realized by Google*(L335): 変更監督の効果として、全クライアントに全リリースについて一律にアラートする方式をやめ、各クライアントが決めたメトリクスをカナリア分析に組み込む方式へ移ったと述べる。 - *Agents generating code, data, content: Quality monitoring*(L868): エージェントの生成物の品質監視では、ゴールデン評価を本番でも走らせて品質 SLI を追い、バーンレートアラートまで検討すべきだとする。 ### 第15章 Capacity Planning 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 15 Capacity Planning]] - *Business-Driven Demand*(L91〜L92): インフラ使用量と製品需要の比率をグラフにし、比率が大きく変わったらアラートする。使用量が予測から外れたときのアラートも勧める。サービスが過負荷にうまく耐えられないうちはオンコールへの緊急アラートとし、耐えられるようになったらチケットに切り替えてよい。 - *Planning for Outages and Incidents*(L233): キャパシティ問題に備えたプレイブックは、ページャーが鳴ったときにすぐ取り出せるものであるべきだとする。深夜の手動承認をなくすため、増強の自動化も勧める。 - *Autoscaling with Flex*(L306): Flex オートスケーリングは設定上限に達するとスケーリングを止め、基盤サービスを守りつつ、制約に達したことを SRE にアラートする。SRE はそれを受けてトラフィックを抑えるか資源を足すかを判断する。 - *Case Study: Google Meet During COVID-19*(L346): 2020 年 2 月 17 日、Meet の SRE がアジアのキャパシティ不足と過負荷タスクで最初のページを受けた。当初は通常の供給不足として資源を足したが、アラートの頻度が増えたことで問題がアジアに留まらないと気づいた。 - *Increasing Elasticity via AI Agents*(L499): キャパシティ危機の際に AI エージェントがアラートを自律的にトリアージし、複数システムのシグナルを突き合わせて根本原因を特定する。 ### 第16章 Data Management 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 16 Data Management]] - ***Application-level verification*(L167)**: バグ由来の想定外の不整合修復(repair)は記録・監視し、件数が閾値を超えたらアラートすべきだとする。閾値を 1 件にする(どんな修復も重大)場合と、一定の背景件数を許して増加時だけアラートする場合がある。 - *Restore Testing*(L487): 自動化したリストアテストは、適切な監視とアラートを伴えば RTO の達成を確かめ、劣化を検知できる。 - ***Decide How You Will Perform Restore Testing*(L583)**: 手動のリストアテストも無いよりはよいが、リストア失敗や RTO 未達でアラートする自動リストアテスト(と復旧後の自動検証)が「最高水準」だと結論する。 ### 第17章 Designing for Resilience 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 17 Designing for Resilience]] - *Risk Management*(L183): 事後的なリスク把握で追うべき項目の一つに「アラーティングと監督の効率」を挙げる。 - *Probabilities*(L204): 発生確率が高〜中程度の障害には自己修復の仕組みを優先すべきで、その効用として解決が速くなるだけでなく、エンジニアがページされる回数が減ることを挙げる。 - ***Change Supervision*(L257)**: Google の Canary Analysis Service(CAS)による自動のカナリア監督と対比して、より単純な方法として「監視アラートがプレイブックを参照する」形を勧める。プレイブックにはロールアウトの一時停止、原因調査、再開かロールバックかの判断手順を書く。 - *Defense in Depth*(L323): 独立した複数の仕組みでスタック全体の健全性を監視し、異常時に進行中の変更を減速・停止させるべきだとする。直近の基準と比べて障害宣言の頻度が増えたらアラートできれば、自システム外の要因をチームが先回りして調べられる。 - ***Representations and Controls*(L349)**: 依存関係の統制として、許可されていない依存が持ち込まれたら知らせる「違反アラート」を設定すべきだとする。 - ***Resilience to Dependency Failures*(L355、L357)**: 任意の依存に障害を注入しても重要な機能に新たな障害が出ないことを定期的に確かめ、アラートが出たら穴として対処する。必須の依存では、注入時に出るアラートは想定した機能に限られ、注入をやめたら自動で収まるべきだとする。こうしたアラートの挙動の確認そのものを、耐障害性の検証方法と位置づける。 - *Actionable Hardening*(L676): 堅牢なシステムは不正な入力を受けたらアラートすべきだとする。手動対応が要る場合のためだけでなく、障害の傾向のデータを集めてリスク管理を改善するためでもある。 ### 第18章 Platform Engineering in SRE 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 18 Platform Engineering in SRE]] - *Curating Solutions*(L46): SRE の初期には、各チームが必要に応じて独自の監視・デプロイ・アラートの仕組みを作っていたと振り返る。「要件だけを渡す」から「要件と厳選した解決策を渡す」への統治の転換を説明する節の冒頭である。 - *Control: Direct and Indirect*(L107): 間接的な統制の例として、ユーザー向けトラフィックを受けるジョブの起動時にオンコールローテーションの存在を確かめ、そのローテーションのアラートの経路とエスカレーション設定が組織の基準を満たすかを自動でチェックする仕組みを挙げる。 - *Paths and Guardrails*(L139): 「ゴールデンパス」の例として、CI/CD パイプラインと並んで監視とアラートのテンプレートを挙げる。 - ***Legibility and Introspection*(L241)**: SRE の知見を明文化した原則の一つとして、「顧客向けサービスは、アラートを虚空ではなく稼働中のチームへ送る設定を持つべきだ」を挙げる。 ### 第20章 How SRE Supports AI 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 20 How SRE Supports AI]] - *Service Level Objectives in AI Systems: Dependency tracking*(L101): データの系譜から依存関係を洗い出し、重要な上流テーブルの鮮度や量が閾値を下回ったら自動でアラートを出し、下流の機械学習処理を止める。 - *AI Reliability*(L123): AI であっても、SLO、監視とアラーティング、キャパシティプランニング、変更管理、自動化、インシデント対応といった従来の SRE の規律は依然必要だと述べる。 - *Qualification of Candidate Models: Performance and quality*(L215): モデルのロールアウトでは、サービングのレイテンシやスループットに基づく自動アラートと停止基準がよく使われる。 ### 第21章 How AI Supports SRE 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]] - ***From Metrics to Meaning*(L115、L127)**: AI 以前の検知は既知の故障様式に偏り、アラートの論理が製品の寿命を通じて場当たり的に積み上がるため、規模を広げにくい。ユーザーの自由記述の報告を AI でクラスタリングすると、クラスタの大きさが自然に深刻度を表し、書く手間そのものがノイズの濾過になる、と従来のアラートとの違いを論じる。 - *Case Study: Detectr*(L157): ユーザー報告から作った構造化レポートは、メールやチケットに加えてページングでも配信できる。 - *Managing Incident Complexity: Playbook context*(L197): インシデント時にダッシュボードに出すグラフを AI が選ぶ方法の一つに、アラートが起動したプレイブックの中で言及されているグラフを抜き出す方法がある。 - *Mitigation Versus Root Cause Analysis*(L209): Google のインシデント対応 AI は、アラートの種類、エラーコード、メトリクス、時刻などを分析し、ロールバック・ドレイン・スケールアップといった定義済みの対応から最適なものを選ぶ。 - *Learning from Failure*(L221): AI がプレイブックの陳腐化を実際の対応と突き合わせて見直し、プレイブックのないインシデントには草案を自動生成する。目的は、次にページャーが鳴ったときにオンコールがよりよく備えられるようにすることだ。 - *The Path to Autonomy: L0 Manual Execution*(L313): 自律性の最低段階 L0 では、アラートの調査、対応方針の承認、変更の実行をすべて人間が行う。 - ***Case Study: AI Operator*(L346、L348、L350、L356)**: AI Operator は本番アラートの「最初の対応者」として設計されたエージェントで、アラートを取り込み、拡張可能な複数のモジュールで調査する。自律性レベル 1(支援)では、届いたアラートの監視と調査を自動で行い、過去の類似インシデントを確かめて所見を要約し、オンコールにすぐ文脈を渡す。 ### 第22章 SRE in Diverse Environments 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 22 SRE in Diverse Environments]] - ***Prioritization is key: Alerting*(L57〜L59)**: 最初の SRE が 90 日で可視性を確立する際、アラートは原因(例: CPU 使用率 90%)ではなく症状(例: レイテンシ悪化)に向け、実行可能でノイズの少ないものにすべきだとする。新しいアラートはテストするか、少なくとも夜ではなく業務時間の始まりに有効化する。 - *Playbooks*(L96〜L98): プレイブックを SRE 以外にも読めるように書く理由として、対応するのがページされた運用担当者かもしれないことを挙げる。 - ***Heterogeneity and silos*(L221)**: 技術スタックが混在する環境で監視を揃えるには、症状ベースのアラーティングを導入する。レイテンシや可用性のようなユーザー体感に直結する指標にアラートを絞れば、内部実装の違いを吸収し、インシデント対応の体験を標準化できる。 - *The results*(L281): 急成長する B2B SaaS 企業の事例で、症状ベースのアラートにより平均検知時間が縮み、プレイブックと一貫したトリアージで緩和・復旧までの時間も改善した。対象の CUJ で全体のダウンタイムは約 60% 減った。 ### 第23章 Future of SRE - *Risk as a Leading Indicator of Reliability*(L27): 「インシデントとニアミスはリスクに気づかせてくれる」という一般的な意味で alert が使われている。アラートシステムの話ではない。 ### 付録 D Example Production Meeting Minutes 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Appendix D Example Production Meeting Minutes]] - ***Paging Events*(L22〜L26)**: 週次の本番運用会議の議事録例。`AnnotationConsistencyTooEventual` アラートが今週 5 回ページした。原因はリージョン間の Bigtable レプリケーション遅延と見られ、根本修正の見込みがないため、許容する一貫性の閾値を上げて実行不能なアラートを減らす。 - *Toil Check*(L34): 今週のページは 5 件で許容範囲内だったと記録する。ページとチケットがそれぞれ応答・解決時間の目標内に処理されたことも併記する。 - *Monitoring Changes and/or Silences*(L41): 上記アラートの許容遅延を 60 秒から 180 秒に引き上げた変更を記録する。過剰なページへの対処として閾値そのものを変えた具体例である。 ### 付録 F The Mathematics of Latency Alerting 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Appendix F The Mathematics of Latency Alerting]] - ***付録全体*(L1〜)**: 第9章のレイテンシアラートを定式化する。ワークロード集合 $W$ と性能指標 $m$(レイテンシなど)を定義し、ワークロードを互いに素なコホート $C_i$ に分ける。コホートが「意味がある」とされる条件は、要素数が閾値 $B$(例: 10,000)以上で、変動係数 $CV(C_i) \le K$($K \le 0.5$)を満たすこと。意味のあるコホートで全ワークロードの 65% 以上を覆うことを目標にする。各コホートの性能は正規分布 $N(\mu_i, \sigma_i^2)$ に従うと仮定し、過去 30〜60 日から $\mu_i$ と $\sigma_i$ を推定して、観測ごとの z スコア $z_w = (m(w)-\mu_i)/\sigma_i$ を計算する。z スコアが閾値(例: 2)を超えるワークロードの割合を検知指標とする。正規分布なら理論値は 2.28% だが、実測では約 4% とやや高い。この割合が有意に増えれば性能劣化の強い兆候とみなし、アラートの根拠にする。レイテンシは対数正規に従うことが多いので経験分布を使う拡張や、小さなコホートを階層ベイズでまとめる拡張にも触れる。 ### 付録 G Modern Observability: Statistics and ML 出典: [[@2026__OReilly__Site Reliability Engineering 2E - Appendix G Modern Observability - Statistics and ML]] - ***冒頭*(L1、L3)**: 第9章で述べたインテリジェントなアラーティングを支える統計と機械学習のモデルを詳しく説明する付録だと位置づける。 - ***A Statistical Approach for Error Rates*(L7〜L13)**: 静的閾値をやめるため、エラー率を二項分布でモデル化する。直近 2 週間のトラフィックから基準のエラー確率を求め、Wilson の信頼区間で期待されるエラーの幅を記述し、その最大値を超えたらアラートする。トラフィック量に応じて幅が自然に変わるため、低トラフィックでは少数の偶発的な失敗でアラートせず、高トラフィックでは数千人に影響しうる小さな上昇にも敏感になる。実装は、監視のクエリ言語で二項検定を直接書く方法から、信頼区間の上限を定期ジョブで計算して基準メトリクスとして出す方法まである。第8章の低トラフィック向け二項検定と同じ手法の詳細にあたる。 - ***Handling Cyclical Metrics with Machine Learning*(L17〜L21)**: CPU やメモリの使用率には日次・週次の周期があり、単純な統計手法では異常を検知できない。過去の観測から現在の期待値を予測する機械学習モデル(TimesFM のような汎用時系列モデルを含む)を訓練し、観測値が予測から外れたらアラートする。ただし説明可能性とコストに難があるため、どこにでも展開すべきではない。 ## 抽出の方法と範囲 - 対象: `.raw/books/site-reliability-engineering-2e/` の章別 Markdown 30 本(本文 23 章と付録 A〜G)と、前付けのうち preface と part-1〜6。 - 抽出語: `alert`(alerting、alerts を含む)、`pager`、`paging`、`paged`、および「人を呼び出す」意味の動詞 `page`。"web page" のような無関係な用法は除いた。 - 言及がなかったのは、第19章 SRE at the Tipping Point、付録 A(研修投資の ROI)、B・C(チーム憲章)、E(SLO 合成の数学)と、前付けのうち序文・編者紹介・Part I/II/IV/V/VI の扉である。 - 同じ段落で同じ論点を扱う複数のヒットは 1 項目にまとめた。そのため項目数(145)は、ヒットした行の数(約 230)より少ない。 - 原文は著作物なので、逐語引用は避けて要約と言い換えで書いた。正確な文言は各行番号から原文を参照すること。