# SRE ## 定義 SRE（Site Reliability Engineering）は、ソフトウェアエンジニアリングの手法を運用の問題に適用するディシプリンである。[[Ben Treynor Sloss]] が 2003 年に [[Google]] で創設し、「ソフトウェアエンジニアに運用システムの設計を任せたときに生まれるもの」と定義した。従来の運用チームが手動作業と組織的対立（開発チームとの速度/安定性のトレードオフ）に悩んでいたのに対し、SRE はエンジニアリング的手法——[[エラーバジェット]]による共通インセンティブ、[[サービスレベル目標]]（SLO）による定量的な信頼性定義、[[トイル]]の計測と削減——でこれらの構造的問題を解消する (Source: [[@2016__OReilly__SRE Book - Chapter 1 Introduction]])。 ### 核心原則 1. **100% の可用性を追求しない**: ユーザーは 99.99% と 99.999% の差を検知できず、信頼性改善のコスト曲線は非線形（各増分が前回の 100 倍）。[[エラーバジェット]]で「許容される障害量」を予算化し、開発速度と信頼性の対立を解消する 2. **50% ルール**: SRE の作業時間の 50% 以下を[[トイル]]に抑え、残りをトイル削減のエンジニアリングに充てる。トイル率が 50% を超えた場合は開発チームにチケットを戻す 3. **SLI/SLO/SLA 体系**: SLI（定量的サービス計測）→ SLO（SLI の目標値）→ SLA（帰結付き契約）の 3 段階でサービスの信頼性を定義・運用する 4. **4 つのゴールデンシグナル**: レイテンシ、トラフィック、エラー率、サチュレーションの 4 指標でサービスの健全性を監視する 5. **変更管理**: 障害の約 70% はライブシステムへの変更に起因する。段階的ロールアウト、迅速な問題検知、安全なロールバックで変更のリスクを制御する 6. **ブレームレスポストモーテム**: 障害から学習するための文化的基盤。人ではなくシステムの欠陥に焦点を当てる ### サービス信頼性ヒエラルキー SRE Book は Maslow の欲求階層にならい、サービスの信頼性を 7 層のヒエラルキーで構造化する (Source: [[@2016__OReilly__SRE Book - Part III Practices]]): 1. **モニタリング**: 4 つのゴールデンシグナルの計測 2. **インシデント対応**: プレイブックによる MTTR の 3 倍改善 3. **ポストモーテムと根本原因分析**: ブレームレス文化での学習 4. **テストと信頼性**: カナリアリリース、負荷テスト 5. **キャパシティプランニング**: 需要予測とプロビジョニング 6. **プロダクト開発**: SRE が設計レビューに参加 7. **ローンチ**: Launch Readiness Review ### 自動化ヒエラルキー 自動化の成熟度を 5 段階で定義する (Source: [[@2016__OReilly__SRE Book - Chapter 7 Automation at Google]]): 1. **手動**: オペレータがドキュメントに従い手動で実行 2. **文書化された自動化**: 手順がスクリプト化されるが人間が起動 3. **外部的に管理された自動化**: 汎用自動化ツールが実行 4. **内部的に管理された自動化**: システム自体が自己管理ロジックを持つ 5. **完全自律**: 人間の介入なしにシステムが自己修復する ## 横断的知見 - **DORA の実証データが示す「SRE は DevOps の一部を実装する」という精緻化**: [[Dave Stanke]] は SREcon22 Americas で SRE Book の "class SRE implements DevOps" を "SRE implements **part of** DevOps" に修正する視点を提示した。DevOps が Business-Product-Dev-Test-Deploy-Operate の全体を対象とするのに対し、SRE は主に Deploy-Operate 周辺に集中しており、DevOps のスコープクリープ（BizDevOps、DevSecOps 等）とは別軸に立つ。また DevOps 文化≈SRE 文化≈TPS≈心理的安全性という等式は、名称の違いを超えた共通文化基盤を示す。(Source: [[@2022__SREcon22Americas__DO RE Me - Measuring the Effectiveness of Site Reliability Engineering]]) - **DORA 2021 年調査による SRE 有効性の定量的裏付け**: DORA が 2021 年に初めて SRE を調査対象とし、(1) 52% の回答者が SRE を何らかの形で実践、(2) SRE はバーンアウトを緩和し運用の共有責任は信頼性成果を予測する、(3) 信頼性は Software Delivery Performance がビジネス成果（市場シェア・収益性・従業員定着）に与える影響を乗算的に増幅する「力積数（force multiplier）」である、という 3 つの知見が得られた。SRE の測定にはサービス劣化検知・共有責任・インシデント対応プロトコル・信頼性レビュー・キャパシティ計画を含む 10 項目のサーベイ尺度を使用した。(Source: [[@2022__SREcon22Americas__DO RE Me - Measuring the Effectiveness of Site Reliability Engineering]]) - **「制御」というフレームは SRE の能動性を言語化する**: [[Yuuki Tsubouchi]] は 2019 年に SRE を「サイト信頼性を**制御する**ための技術」と再定義した（[[@2019__yuuk.io__2019-SRE-Thinking]]）。SRE Book の描写的定義（「ソフトウェアエンジニアに運用を任せたら生まれるもの」）に対し、この目的論的定義は「信頼性は設計上のパラメータとして意図的に選択できる」という[[エラーバジェット]]の核心思想を一言で捉えている。「信頼性を維持・意図的に低下させることも含む」という包含関係は、[[SRE AI Autonomy Levels]] L3/L4 における「エージェントが信頼性目標を維持するよう自律的に行動する」枠組みとも整合する。 - **SRE と DevOps は対立ではなく補完関係にある**: DevOps が文化・組織原則（サイロの除去、失敗の受容、段階的変更）を提唱するのに対し、SRE は同じ哲学に具体的な実装——エラーバジェット、SLO、トイルの定量化、50% ルール——を与える。SRE Book の序文は SRE を「DevOps の具体的実装の一つ（class SRE implements DevOps）」と位置づける (Source: [[@2016__OReilly__SRE Book - Chapter 1 Introduction]], [[@2016__OReilly__SRE Book - Foreword]])。 - **SRE Workbook は SRE を「約束の設定・評価・修復」の実装系へ引き戻す**: Foreword I は SRE を、明確な約束を立て、メトリクスと予算で継続評価し、オンコールと自律性を守りながら約束を修復する人間・コンピュータ系として要約する。How SRE Relates to DevOps は DevOps の文化語彙に対して、SRE が SLO・エラーバジェット・トイル上限という運用可能な制約を与えると整理する。SRE Book の原則が「何を信じるか」なら、SRE Workbook は「どの文書・アラート・会議・訓練で行動へ落とすか」を担う (Source: [[@2018__Google SRE Workbook__Foreword I]], [[@2018__Google SRE Workbook__Chapter 1 How SRE Relates to DevOps]])。 - **「class SRE implements DevOps」という定式化自体が、DevOpsに起きた「文化→職種・技術レイヤーへの縮約」を反復する危険を持つ**: [[DevOps]] は元々、開発部門と運用部門という組織の分断を解消する文化運動であり、技術レイヤーやツール群を指す語ではなかった(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]])。SRE Workbookの「class SRE implements DevOps」はSREをDevOps哲学の具体的実装として肯定的に位置づけるが、mizzy(2026)はこの整理自体が「SREは運用の問題をソフトウェアエンジニアリングで解決するプラクティスではなく、インフラレイヤーを担当する職種である」という受け取られ方を助長しうると指摘する。これはDevOpsが辿った、文化運動から職種・ツール名への縮約と同じパターンであり、SREという語についても「開発の時系列上の役割」「技術レイヤー」「組織上のロール」という3軸を混同しないことが、同じ轍を踏まないための鍵になる。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **自動化ヒエラルキー（2016）は [[SRE AI Autonomy Levels]]（L0–L4）の直接の前駆である**: SRE Book の 5 段階（手動→完全自律）は、Google が 2026 年に提示した AI の自律度 5 段階（L0 全手動→L4 完全自律）と構造的に対応する。10 年の間に変わったのは自動化の主体——スクリプトと管理ツールから LLM エージェントへ——であり、「段階的に自律度を上げ、各段階で安全制御を前提とする」という統治の骨格は継承されている (Source: [[@2016__OReilly__SRE Book - Chapter 7 Automation at Google]], [[SRE AI Autonomy Levels]])。 - **SRE Book の結論で提示された航空アナロジーは [[自動化のアイロニー]]（Bainbridge 1983）のテーゼを独立に再発見している**: 結論の章は「自律が進むほど人間の訓練投資が必要になる」と航空業界の教訓を引き、Bainbridge が 33 年前に提示した「自動化がオペレータのスキルを劣化させる」パラドクスと同じ洞察に到達する。SRE Book は解決策として継続的な訓練投資と Wheel of Misfortune（障害シミュレーション演習）を処方する (Source: [[@2016__OReilly__SRE Book - Chapter 34 Conclusion]], [[自動化のアイロニー]])。 - **Borgmon → Prometheus の系譜が、宣言型ルール評価によるモニタリングの保守コスト劣線形化を実証する**: Ch10 は Google の内部モニタリングシステム Borgmon を題材に、命令型チェックスクリプトから宣言型ルール評価への転換を記述する。ラベルセットによる多次元時系列モデル、代数的アグリゲーション、for 節によるフラッピング防止、Alertmanager による重複排除・抑制という設計は、そのまま Prometheus に受け継がれた。この設計思想は、本 wiki の [[テレメトリ]] が整理する計装→保持→分析の 3 層のうち分析層の基盤にあたり、[[異常検知]] のサーベイが指摘する「常時稼働には LLM が重すぎる」制約を、宣言型ルール評価が LLM 以前から解いていた先例として位置づけられる (Source: [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]], [[テレメトリ]], [[異常検知]])。 - **オンコールの量的・質的均衡原則は、agentic SRE のオンコール吸収後に再定義を迫られる**: Ch11 はオンコール業務にエンジニアリング 50%・オンコール最大 25% の量的均衡と、12 時間シフトあたりインシデント上限 2 件の質的均衡を設ける。フォロー・ザ・サンによる夜間シフト排除と、心理的安全性に基づく認知モード管理（熟慮的思考の優先）も処方する。これらは人間 SRE のバーンアウト防止として設計されたが、[[agentic SRE]] がオンコールを吸収した場合、「量的均衡」は無意味になり、残るのはエージェント監督のための人間の認知負荷管理という別の問題になる。Wheel of Misfortune 演習と DiRT は、Ch28 の体系的オンボーディングと合わせ、運用過少負荷による知識劣化への処方であり、[[自動化のアイロニー]] の訓練投資の逆説と直接接続する (Source: [[@2016__OReilly__SRE Book - Chapter 11 Being On-Call]], [[@2016__OReilly__SRE Book - Chapter 28 Accelerating SRE On-Call]], [[agentic SRE]], [[自動化のアイロニー]])。 - **仮説演繹法に基づくトラブルシューティングは、agentic SRE の hypothesis-driven RCA の直接の前史である**: Ch12 はトラブルシューティングを生得的才能でなく学習可能な技能と位置づけ、仮説演繹法・分割統治法・トリアージと安定化優先の 3 原則を体系化する。この「仮説を立て→テレメトリで検証→棄却→再定式化」のループは、[[根本原因分析]] で [[Bits AI SRE]] や [[Stratus]] が実装する hypothesis-driven investigation と構造的に同型であり、SRE Book が人間の SRE のために言語化した推論手順が、LLM エージェントの設計仕様として 10 年後に再利用されている (Source: [[@2016__OReilly__SRE Book - Chapter 12 Effective Troubleshooting]], [[根本原因分析]])。 - **インシデントコマンドシステム（ICS）に基づく役割分離は、マルチエージェント SRE の役割設計と対応する**: Ch14 は非管理型インシデントの最大の悪化要因を「善意に基づく独断行動（フリーランシング）」と特定し、ICS に基づくインシデントコマンダー・オペレーション・コミュニケーション・プランニングの 4 役を処方する。[[Stratus]] の 4 エージェント構成（Commander/Investigator/Executor/Undo）や [[OpsAgent]] の MAS 設計（Anomaly Sentinel/Failure Diagnoser/Root Detective）は、この人間チームの役割分離をエージェントの専門化として写像している (Source: [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]], [[インシデント管理]])。 - **ブレームレスポストモーテム文化は、LLM が生成する RCA レポートの「非難なき説明」要件の思想的基盤である**: Ch15 はポストモーテムの核心を個人の非難でなくシステムの欠陥への焦点にあると説き、経営層の参加・正しい行動への可視的報奨・定期的な効果測定で文化を定着させる。Ch33 は航空（CHIRP）・医療・製造業（CAPA）から非難なき振り返りが業界横断で有効であることを確認する。LLM エージェントが生成する RCA レポート（[[根本原因分析]] の root cause report generation）においても、「証拠の忠実性 > 物語のもっともらしさ」という設計命題は、ブレームレス文化の「人でなくシステムに焦点」という原則の自動化版として読める (Source: [[@2016__OReilly__SRE Book - Chapter 15 Postmortem Culture - Learning from Failure]], [[@2016__OReilly__SRE Book - Chapter 33 Lessons Learned from Other Industries]], [[根本原因分析]])。 - **SRE 組織変革の中心課題は「設計フェーズへの参加」と「割り込み吸収の構造化」である**: SIE（Sony Interactive Entertainment）の事例では、SRE が設計段階から排除されたことによるフィードバック遅延（Months）が最大の課題だった。CFT（クロスファンクショナルチーム）により SRE を設計ループに組み込み、TOS（Technical Operations Support）という割り込み吸収レイヤーで SRE を Interruptions から解放した。これは SRE Book Ch29「時間の二極化」と Ch32「エンゲージメントモデルの早期関与」の原則を組織設計として実装した事例として位置づけられる。Reliability Meetup（2.5 年 22 回、600+ 参加者）という定期的な非 SRE との対話の場が信頼性文化の浸透に有効だった点も注目される。(Source: [[@2023__SREcon23 EMEA__From Sysadmins to (almost) Flying Unicorns]], [[@2016__OReilly__SRE Book - Chapter 29 Dealing with Interrupts]], [[@2016__OReilly__SRE Book - Chapter 32 The Evolving SRE Engagement Model]]) - **古典的信頼性工学は SRE の前史として「曖昧な高信頼」を測定可能な要求へ変換していた**: [[@2012__Wiley__Practical Reliability Engineering|Practical Reliability Engineering]] は、信頼性要求に「できるだけ高く」「99%」のような曖昧な文言を書かず、故障定義・環境条件・検証可能な信頼性要求を明示せよと述べる。これは SRE Book/Workbook の SLI/SLO/SLA と同じく、信頼性を価値判断ではなく仕様・測定・フィードバックの対象にする設計である。(Source: [[@2012__Wiley__Practical Reliability Engineering]] ch.17 §17.6, [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]]) - **複雑システム時代の SRE は、固定計画より「実験で学ぶ計画」へ寄る**: Brush の SREcon26 講演は、AI エージェントによってソフトウェア作成が安く速くなるほど作られるものも増え、SRE が扱うシステムがさらに複雑になると論じる。SRE Book が SLO・エラーバジェット・プレイブックで信頼性を制御可能な対象へ落としたのに対し、この講演は「予測可能性は複雑システムの性質ではない」として、計画を実験列として組み、汎用緩和をシステム要求として継続テストする方向を強調する。(Source: [[@2026__SREcon26 Americas__Taming the Unpredictable - Reliability in Chaos]], [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]], [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]]) - **開発者体験(DX)は SRE の信頼性システム特性であり、計測可能な先行指標がある**: [[Nicole Forsgren]] の SREcon26 講演は、SRE のツール・プロセス・認知上の「摩擦(friction)」を感情問題ではなくシステム特性として定義し、3 種類に分類する: 認知負荷(アラートノイズ・状態不透明・メンタルモデルギャップ)・ツール摩擦(戦闘モードの UI・発見しにくい CLI フラグ・深夜に遅いダッシュボード)・プロセス摩擦(調整遅延・インシデント中の承認ゲート・解釈を要するランブック)。摩擦は速度を落とすだけでなく**圧力下でのエラー率を上げる**——認知摩擦は作業記憶を狭め、ツール摩擦はインシデントのメンタルモデルを破壊し、プロセス摩擦はクリティカルループを遅延させる。北極星メトリクスとして [[MTWTF]](アラートから「状況を理解した」までの時間)を提案し、[[DORA]] と [[SPACE]] フレームワークを SRE チーム自身の計測に内側向きに適用することを推奨する。(Source: [[@2026__SREcon26 Americas__The WTF Problem - Developer Experience as a Reliability Property]]) - **テストと信頼性の定量的関係（MTTR→0 と MTBF 延長）は、SRE Benchmark の評価設計に通底する**: Ch17 はテストを信頼性の確信度を定量化する手段と位置づけ、カナリアテストにおける障害の次数（U）と段階的ロールアウトの原則を示す。21,000 テストに対して個々の信頼性を 99.9999% 以上に保つ必要があるという統計的制約は、[[SRE Benchmark]] が大量の障害シナリオに対しエージェントの信頼性を測定する課題と構造的に相似する (Source: [[@2016__OReilly__SRE Book - Chapter 17 Testing for Reliability]], [[SRE Benchmark]])。 - **SRE におけるソフトウェアエンジニアリング（Auxon）は、agentic SRE のキャパシティプランニング自動化の前史である**: Ch18 は意図ベースのキャパシティプランニングシステム Auxon を詳述し、サービス要件を機械可読な意図として記述して混合整数計画法で最適リソース配分を自動生成する設計を示す。「要件を実装から分離する」原則は、[[agentic SRE]] のエージェントが SLO を入力としてリソース調整を自律的に行う構想の直接の先駆である (Source: [[@2016__OReilly__SRE Book - Chapter 18 Software Engineering in SRE]], [[agentic SRE]])。 - **AI 時代の SRE は「生成物の制御」と「本番での観測・担保」の二面を同時に扱う**: Yoshikawa は、AI により開発速度が上がる一方で DORA 2024-2025 の不安定さ、AI コード品質、生成 AI サービスの検知困難性が信頼性課題を増やすと整理し、SRE が速度と信頼性のバランスを取り直す必要を論じる。SRE Book のエラーバジェットと SLO は速度制御の古典的仕組みだが、この資料は出力品質スコア・ハルシネーション率・RAG 検索精度のような AI サービス固有 SLI と、人間承認付きの AI 補助を同じ運用ループに載せる方向を示す。(Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]], [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]], [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]]) - **SRE 導入において「コンテキスト」抽出はベストプラクティス適用の前提条件である**: [[Aaron Bowden]] は SRE 導入支援の現場（Google Cloud Professional Services JAPAC）から、「どのケイパビリティを次に取得するか」という問いに答えられる地図（[[Reliability Map (r9y.dev)]]）が存在しないことを問題提起した。SRE Book は「何を信じるか」の原則体系であり、SRE Workbook は「どの文書・アラート・会議で行動へ落とすか」を担う。これに対し Reliability Map は「ケイパビリティ取得の順序」という実装ロードマップのギャップを埋める補完的位置づけにある。「ベストプラクティスはコンテキスト依存」という主張は、カーゴカルティング（コンテキスト不理解のまま手順を踏む）への構造的警告であり、Ch32 の「ケイパビリティ取得を自組織のプラットフォームコンテキストに対応させる」エンゲージメントモデルと接続する。(Source: [[@2022__SREcon22 APAC__Introducing the Reliability Map – r9y.dev]], [[@2016__OReilly__SRE Book - Chapter 32 The Evolving SRE Engagement Model]]) - **2022 年の DICOMO 構想は、SRE を「信頼性を制御する技術」から「利用者が信頼性を制御する未来」へ延長していた**: [[Yuuki Tsubouchi]] は [[@2019__yuuk.io__2019-SRE-Thinking]] で SRE を信頼性制御の技術と捉えたが、[[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]] では 2040 年代の [[セルフクラフト]] において、利用者が AI と対話的・体験的に信頼性・コスト・変更速度の均衡点を決める未来像へ拡張した。これは SRE の「事業者が SLO を決める」実践を、将来的には「利用者が個別の信頼性目標を調整する」問題へ押し広げる。(Source: [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]], [[@2019__yuuk.io__2019-SRE-Thinking]]) - **埋め込み SRE の 3 フェーズモデルは、SRE 原則の組織的浸透のメカニズムを体系化する**: Ch30 は運用過負荷チームへの介入として、学習→文脈共有→変革推進の 3 フェーズで SRE 原則に基づくメンタルモデルを構築する。SLO の確立が最も重要なてこであり「これなしに他の改善は機能しない」と断言する。この知見は、[[サービスレベル目標]] の概念ページで Hamilton (2007) が SLA を設計段階の酸性試験としたのと同じ「定量的目標を先に置く」原則の組織実装版として接続する (Source: [[@2016__OReilly__SRE Book - Chapter 30 Embedding an SRE to Recover from Operational Overload]], [[サービスレベル目標]])。 - **エンゲージメントモデルの進化（PRR→早期関与→フレームワーク）は、SRE の影響範囲の拡張パターンを示す**: Ch32 は SRE のエンゲージメントを単純 PRR→早期エンゲージメント→フレームワーク/プラットフォームの 3 段階で整理し、フレームワーク化により個別 SRE 配置なしに本番品質を担保できると説く。この進化は、Ch18 の Auxon がスプレッドシートからソルバへ移行した過程、および [[プラットフォームエンジニアリング]] が SRE の知見を共通基盤に体現する動向と整合する (Source: [[@2016__OReilly__SRE Book - Chapter 32 The Evolving SRE Engagement Model]], [[プラットフォームエンジニアリング]])。 - **時間の二極化と認知的フロー状態は、SRE の生産性を割り込み管理の問題として定式化する**: Ch29 はコンテキストスイッチのコストを正面から認め、エンジニアの時間を「プロジェクト専念」か「割り込み専念」に二極化することを提唱する。割り込みに専念すればそれ自体がフロー状態の対象になるという逆説は、Ch11 のオンコール均衡原則と合わせ、SRE の作業設計における認知科学的な基盤を構成する (Source: [[@2016__OReilly__SRE Book - Chapter 29 Dealing with Interrupts]], [[@2016__OReilly__SRE Book - Chapter 11 Being On-Call]])。 - **SRE の原則体系は [[agentic SRE]] が自動化しようとしているタスクの構造そのものである**: エラーバジェットの消費判断、トイルの識別と削減、4 つのゴールデンシグナルに基づく監視、プレイブックに沿ったインシデント対応——これらは SRE が人間のために体系化したプラクティスであると同時に、現在の LLM エージェントが自律化を試みている処理の仕様書でもある。agentic SRE の評価ベンチマーク（[[SREGym]]・[[AIOpsLab]]）が測定しているのは、エージェントがこの仕様をどこまで実行できるかという問いにほかならない (Source: [[@2016__OReilly__SRE Book - Chapter 1 Introduction]], [[agentic SRE]])。 - **Hamilton (2007) の「SLA を設計段階の酸性試験とする」原則は、SRE Book に先行する思想的土台である**: Hamilton は SRE Book の 9 年前に、SLA をサービス設計の制約として組み込む原則を提示した。SRE Book の SLI/SLO/SLA 体系と[[エラーバジェット]]は、Hamilton の設計原則を運用プロセスとして制度化したものと位置づけられる (Source: [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]], [[@2007__LISA__On Designing and Deploying Internet-Scale Services]])。 - **「プレイブックは MTTR を 3 倍改善する」知見は、agentic SRE における手続き的実演の優位性と接続する**: SRE Book はプレイブック（構造化された対応手順）がインシデント対応の MTTR を 3 倍改善すると報告する。[[agentic SRE]] の横断知見では、手続き的実演（ICL）が宣言的知識（RAG）を一貫して上回ることが示されており（Cloud-OpsBench: GPT-4o 0.49→0.70）、「何を知っているか」より「どう動くかの実演」がエージェントの性能を決めるという方向と整合する (Source: [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]], [[agentic SRE]])。 - **SREcon14 の 13 のキー（2014）は SRE Book（2016）の要約ではなく、より操作的な規則として先行する**: [[Ben Treynor Sloss]] が 2014 年に初めて公開した 13 のキーは、SRE Book より 2 年早く、かつより実施規則に近い形で提示されている。SRE Book が「なぜそれが正しいか」の理論と原則を展開するのに対し、この講演は「ローンチオンブラック（SLA 遵守中なら自由にローンチ、違反中は全凍結）」「最低 8 名のオンコール体制」「1 シフトあたり最大 2 件」のような具体的な閾値と意思決定ルールを直接提示する。また「コーダーだけ採用する理由は飽き性だから自動化する」という動機付けの構造は、SRE Book の 50% ルール・トイルの章で理論化される前に口頭説明として先に提示されていた。(Source: [[@2014__SREcon14__Keys to SRE]], [[@2016__OReilly__SRE Book - Chapter 1 Introduction]], [[@2016__OReilly__SRE Book - Chapter 5 Eliminating Toil]]) - **SRE Book は 2400+ インフラエンジニア規模の組織を想定して書かれており、それ以外の文脈への無批判な適用はカーゴカルティングになる**: [[Emil Stolarsky]] は SREcon22 EMEA で、SRE Book が 70+ 名の著者・複数十チームの貢献者を擁し、2016 年時点で 1200+ SRE（さらに少なくとも 1200+ の SWE）が存在する Google のインフラ組織——合計 2400+ エンジニア——の観点から書かれていることを示した。この規模は大多数の組織にとって「教典」として適用できる前提ではない。Facebook の命名変遷（SRE 2009→SRO+AppOps 2010→Production Engineering 2012→SRO 廃止 2014）も、単一の理想形が存在しないことを裏付ける歴史的証拠として提示された。(Source: [[@2022__SREcon22 EMEA__Unified Theory of SRE]]) - **スタートアップ（Default Dead）では、SRE の最大の価値貢献は信頼性ではなく開発速度の向上である**: Stolarsky は組織を「Default Alive（Real Business™ ＝ 顧客があり信頼性の向上が SRE の存在を正当化する）」と「Default Dead（スタートアップ ＝ Product-Market Fit 未達、プロダクト速度が全て）」の 2 種類に分けた。Default Dead フェーズでは、SRE の最優先は開発者インフラ（開発環境・インテグレーションテスト/CI・デプロイ）であり、本番運用は最低限に抑えるべきである。「Boring Technology の原則」（innovation token を消費しない枯れた技術を使う）と「Kubernetes は不要」という処方は、この文脈で提示される。SLO も純粋な SLO の議論をするのではなく、まず「プロダクトの価値観」（古いデータを返すか、エラーを返すか等のトレードオフ）を定義する方が有益だとされる。(Source: [[@2022__SREcon22 EMEA__Unified Theory of SRE]]) - **FAANG は技術フロンティアで運用しているが、大多数の組織のニーズははるかにシンプルである**: Stolarsky は手書き風のグラフで、y 軸に「edge of technology」、x 軸に time を取り、上昇曲線の最先端に Google/Facebook/etc.、曲線よりはるか下方に「Most of us」を配置した。SRE Book が提示する設計・ツール・実践は最先端でのオペレーションに最適化されており、大多数の組織が扱うサービスは「本質的に同じでシンプル」だとし、コミュニティとして設計を標準化できる余地があると主張した。(Source: [[@2022__SREcon22 EMEA__Unified Theory of SRE]]) ## 未解決の問い - SRE Book が想定する「SRE エンジニアが運用の 50% をエンジニアリングに充てる」モデルは、[[agentic SRE]] でエージェントが運用作業を代替した場合、どう再定義されるか。エージェントにとっての「トイル」と「エンジニアリング」の区別は存在するか（[[トイル]]の未解決の問いと連動）。 - SRE Book の変更管理原則（障害の 70% は変更に起因）は、エージェントが自律的に変更を加える [[SRE AI Autonomy Levels]] L3 以上で、変更の承認・追跡・ロールバックの責任所在をどう定義するか。 - SRE の原則は Google 規模（数千〜数万のサービス、専任 SRE チーム）を前提に設計されている。Stolarsky は中小規模組織でのカーゴカルティングを警告したが、では「SRE Book のどの原則が規模非依存で適用可能」で「どれがスケールダウンを要するか」の体系的な整理は存在するか。 - SRE Book は人間の SRE チームのバーンアウト防止（トイル率管理、オンコール負荷）を重視する。agentic SRE がオンコール負荷を吸収する将来、SRE エンジニアの役割はエージェントの監督・訓練・安全制御の設計に移行するか、それとも SRE という職種自体が再定義されるか。 - Ch12 が体系化した仮説演繹法に基づくトラブルシューティングは「学習可能な技能」と位置づけられるが、LLM エージェントにとっての「学習」は人間と同じ経験蓄積なのか、それともコンテキスト長の拡大や ICL で代替可能なのか。Ch28 の体系的オンボーディング（Shadow → On-Call → Project Owner）は人間の成長パスとして設計されており、エージェントの段階的権限拡大モデルへの翻案には何が必要か。 - Ch14 の ICS に基づくインシデント管理はフリーランシングの抑制を主目的とするが、マルチエージェント SRE（[[Stratus]]、[[OpsAgent]]）における「フリーランシング」（エージェントの独断行動）は人間チームのそれと同じメカニズムで発生するのか、それとも調整プロトコルの設計で構造的に排除可能か。 - Ch15 のブレームレスポストモーテムは「文化」に依存する（経営層の参加、正しい行動の報奨）。LLM エージェントが自動生成するポストモーテムは人間の「非難への誘惑」から解放されるが、同時に「証拠の忠実性 vs 物語の整合性」のトレードオフで系統的なバイアスを持つか。 - Ch32 のエンゲージメントモデルの進化（PRR→早期関与→フレームワーク）が示す「フレームワーク化により個別 SRE 配置を不要にする」方向は、[[プラットフォームエンジニアリング]] の台頭と合わせ、SRE の役割を「個別サービス運用」から「信頼性プラットフォーム構築」へと不可逆に移行させるか。 - Ch33 が引く航空・医療・製造業の教訓は、業界横断で「非難なき振り返り」「防御の深さ」「正常化された逸脱の検知」が有効であることを示す。ソフトウェアシステムの障害特性（変更頻度が桁違いに高い、ロールバック可能、人命に直結しにくい）を踏まえたとき、他業界の教訓のどこまでが直接適用可能で、どこからがアナロジーの限界か。 - AI エージェントによって小さな修正やテスト生成の限界費用が下がるとき、SRE は「最重要バグだけを直す」優先順位付けから、どの程度まで「低コストで直せるリスクを広く減らす」方針へ移るべきか。 - [[セルフクラフト]] のように利用者がアプリケーションと信頼性目標を個別調整する未来では、SRE の責任主体はサービス事業者、利用者、AI のどこに置かれるか。利用者が選んだ低信頼性・低コスト設定で障害が起きた場合の説明責任はどう分配されるか。 ## 関連 - ソース: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]] / [[@2026__SREcon26 Americas__The WTF Problem - Developer Experience as a Reliability Property]] / [[@2019__yuuk.io__2019-SRE-Thinking]] / [[@2024__yuuk.io__SRE-NEXT-2024]] / [[@2016__OReilly__SRE Book - Foreword]] / [[@2016__OReilly__SRE Book - Preface]] / [[@2016__OReilly__SRE Book - Chapter 1 Introduction]] / [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]] / [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]] / [[@2016__OReilly__SRE Book - Chapter 5 Eliminating Toil]] / [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]] / [[@2016__OReilly__SRE Book - Chapter 7 Automation at Google]] / [[@2016__OReilly__SRE Book - Part III Practices]] / [[@2018__Google SRE Workbook__Chapter 1 How SRE Relates to DevOps]] / [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] / [[@2018__Google SRE Workbook__Incident Response]] / [[@2018__Google SRE Workbook__Conclusion]] / [[@2007__LISA__On Designing and Deploying Internet-Scale Services]] / [[@2026__SREcon26 Americas__Taming the Unpredictable - Reliability in Chaos]] / [[@2022__SREcon22 EMEA__Unified Theory of SRE]] - エンティティ: [[SRE Book]] / [[Google]] / [[Ben Treynor Sloss]] / [[Betsy Beyer]] / [[Niall Murphy]] / [[Margaret Hamilton]] / [[Emil Stolarsky]] / [[Wave Mobile Money]] - 概念: [[エラーバジェット]] / [[トイル]] / [[サービスレベル目標]] / [[agentic SRE]] / [[SRE AI Autonomy Levels]] / [[インシデント管理]] / [[自動化のアイロニー]] / [[AIOps]] / [[根本原因分析]] / [[テレメトリ]] / [[異常検知]] / [[障害緩和]] / [[障害注入]] / [[根本原因分析]] / [[プラットフォームエンジニアリング]] / [[SRE Benchmark]] / [[DORA]] / [[SPACE]] / [[MTWTF]] - 関連 MOC: [[structures/SRE - MOC]] / [[structures/LLM4SRE - MOC]] ## 出典 - [[@2016__OReilly__SRE Book - Foreword]]（Mark Burgess による序文、SRE と DevOps の関係） - [[@2016__OReilly__SRE Book - Preface]]（書籍の構成と対象読者） - [[@2016__OReilly__SRE Book - Chapter 1 Introduction]]（SRE の定義、50% ルール、エラーバジェット、DevOps との関係） - [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]]（100% 可用性の非追求、コスト曲線の非線形性、リスク許容度の定量化） - [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]]（SLI/SLO/SLA の体系、パーセンタイル原則） - [[@2016__OReilly__SRE Book - Chapter 5 Eliminating Toil]]（トイルの 6 特性、50% ルール） - [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]]（4 つのゴールデンシグナル、プレイブックによる MTTR 改善） - [[@2016__OReilly__SRE Book - Chapter 7 Automation at Google]]（自動化ヒエラルキー 5 段階、Decider、変更管理の自動化） - [[@2016__OReilly__SRE Book - Part III Practices]]（サービス信頼性ヒエラルキー 7 層） - [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]]（Borgmon の設計、時系列ルール評価、Prometheus への系譜） - [[@2016__OReilly__SRE Book - Chapter 11 Being On-Call]]（量的・質的均衡、フォロー・ザ・サン、認知モード管理） - [[@2016__OReilly__SRE Book - Chapter 12 Effective Troubleshooting]]（仮説演繹法、分割統治、トリアージ優先） - [[@2016__OReilly__SRE Book - Chapter 13 Emergency Response]]（テスト誘発型障害 vs 訓練なし障害、人間の創造性と冷静さ） - [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]]（ICS 4 役割、フリーランシングの害、非管理型インシデントの悪化要因） - [[@2016__OReilly__SRE Book - Chapter 15 Postmortem Culture - Learning from Failure]]（ブレームレス文化、経営層参加、アクションアイテムの追跡） - [[@2016__OReilly__SRE Book - Chapter 16 Tracking Outages]]（Outalator、パッシブ集約、タグベースのメタデータ管理） - [[@2016__OReilly__SRE Book - Chapter 17 Testing for Reliability]]（テストと信頼性の定量関係、カナリアテスト、障害の次数 U） - [[@2016__OReilly__SRE Book - Chapter 18 Software Engineering in SRE]]（Auxon、意図ベースのキャパシティプランニング、混合整数計画法） - [[@2016__OReilly__SRE Book - Chapter 28 Accelerating SRE On-Call]]（Shadow→On-Call→Project Owner、逆ハンドオフ、DiRT 演習） - [[@2016__OReilly__SRE Book - Chapter 29 Dealing with Interrupts]]（時間の二極化、コンテキストスイッチコスト、フロー状態） - [[@2016__OReilly__SRE Book - Chapter 30 Embedding an SRE to Recover from Operational Overload]]（3 フェーズモデル、SLO が最重要のてこ、チーム力学の変革） - [[@2016__OReilly__SRE Book - Chapter 31 Communication and Collaboration in SRE]]（プロダクションミーティング、ハンドオフ手法、チームの構成と連携） - [[@2016__OReilly__SRE Book - Chapter 32 The Evolving SRE Engagement Model]]（PRR→早期関与→フレームワーク、SRE プラットフォームチーム） - [[@2016__OReilly__SRE Book - Chapter 33 Lessons Learned from Other Industries]]（航空 CHIRP、医療、製造 CAPA、正常化された逸脱） - [[@2016__OReilly__SRE Book - Chapter 34 Conclusion]]（航空アナロジー、自律と訓練の逆説、SRE の持続的原則） - [[@2018__Google SRE Workbook__Chapter 1 How SRE Relates to DevOps]]（SRE と DevOps の補完関係、SLO・トイル・エラーバジェットを実装制約として位置づけ） - [[@2018__Google SRE Workbook__Conclusion]]（SRE の企業導入拡大、隣接領域への展開、SRE Book からの補正） - [[@2026__mizzy.org__DevOpsとは何だったのか]]（DevOps の起源と変遷、「class SRE implements DevOps」への批判的視点）