# 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. **完全自律**: 人間の介入なしにシステムが自己修復する ## 横断的知見 - **「制御」というフレームは 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]])。 - **自動化ヒエラルキー（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]], [[根本原因分析]])。 - **テストと信頼性の定量的関係（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]])。 - **埋め込み 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]])。 ## 未解決の問い - SRE Book が想定する「SRE エンジニアが運用の 50% をエンジニアリングに充てる」モデルは、[[agentic SRE]] でエージェントが運用作業を代替した場合、どう再定義されるか。エージェントにとっての「トイル」と「エンジニアリング」の区別は存在するか（[[トイル]]の未解決の問いと連動）。 - SRE Book の変更管理原則（障害の 70% は変更に起因）は、エージェントが自律的に変更を加える [[SRE AI Autonomy Levels]] L3 以上で、変更の承認・追跡・ロールバックの責任所在をどう定義するか。 - SRE の原則は Google 規模（数千〜数万のサービス、専任 SRE チーム）を前提に設計されている。中小規模の組織では SRE のどの原則が「そのまま適用可能」で、どれが「規模に応じた翻案」を要するか。 - 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 が引く航空・医療・製造業の教訓は、業界横断で「非難なき振り返り」「防御の深さ」「正常化された逸脱の検知」が有効であることを示す。ソフトウェアシステムの障害特性（変更頻度が桁違いに高い、ロールバック可能、人命に直結しにくい）を踏まえたとき、他業界の教訓のどこまでが直接適用可能で、どこからがアナロジーの限界か。 ## 関連 - ソース: [[@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]] / [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]] / [[@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]] / [[@2016__OReilly__SRE Book - Chapter 14 Managing Incidents]] / [[@2016__OReilly__SRE Book - Chapter 15 Postmortem Culture - Learning from Failure]] / [[@2016__OReilly__SRE Book - Chapter 16 Tracking Outages]] / [[@2016__OReilly__SRE Book - Chapter 17 Testing for Reliability]] / [[@2016__OReilly__SRE Book - Chapter 18 Software Engineering in SRE]] / [[@2016__OReilly__SRE Book - Chapter 28 Accelerating SRE On-Call]] / [[@2016__OReilly__SRE Book - Chapter 29 Dealing with Interrupts]] / [[@2016__OReilly__SRE Book - Chapter 30 Embedding an SRE to Recover from Operational Overload]] / [[@2016__OReilly__SRE Book - Chapter 31 Communication and Collaboration in SRE]] / [[@2016__OReilly__SRE Book - Chapter 32 The Evolving SRE Engagement Model]] / [[@2016__OReilly__SRE Book - Chapter 33 Lessons Learned from Other Industries]] / [[@2016__OReilly__SRE Book - Chapter 34 Conclusion]] / [[@2007__LISA__On Designing and Deploying Internet-Scale Services]] - エンティティ: [[SRE Book]] / [[Google]] / [[Ben Treynor Sloss]] / [[Betsy Beyer]] / [[Niall Murphy]] / [[Margaret Hamilton]] - 概念: [[エラーバジェット]] / [[トイル]] / [[サービスレベル目標]] / [[agentic SRE]] / [[SRE AI Autonomy Levels]] / [[インシデント管理]] / [[自動化のアイロニー]] / [[AIOps]] / [[根本原因分析]] / [[テレメトリ]] / [[異常検知]] / [[障害緩和]] / [[障害注入]] / [[根本原因分析]] / [[プラットフォームエンジニアリング]] / [[SRE Benchmark]] - 関連 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 の持続的原則）