本書への推薦の言葉
序文1
序文2
はじめに

1章 SREとDevOpsとの関係
1.1　DevOpsの背景
1.1.1　サイロの抑制
1.1.2　アクシデントは普通のこと
1.1.3　変化は徐々に起こすべきもの
1.1.4　ツールと文化は相互に関係する
1.1.5　計測は必須
1.2　SREの背景
1.2.1　運用はソフトウェアの問題
1.2.2　サービスレベル目標（SLO）による管理
1.2.3　トイルの最小化のための作業
1.2.4　今年のジョブの自動化
1.2.5　失敗のコストの削減による速度の向上
1.2.6　開発者との共有オーナーシップ
1.2.7　役割や仕事の肩書きに関わらず同じツールを使うこと
1.3　比較と対照
1.4　組織のコンテキストと成功する採用の促進
1.4.1　狭く硬直したインセンティブは成功を狭める
1.4.2　修正は自分で行う。他の誰かを責めない
1.4.3　信頼性に関する作業を特化した役割として考える
1.4.4　「やるかどうか」は「いつやるか」に置き換えられる
1.4.5　評価の同等性のための努力：キャリアと金銭
1.5　まとめ

第Ⅰ部 基礎

2章 SLOの実装
2.1　SREにSLOが必要な理由
2.2　始めてみよう
2.2.1　信頼性のターゲットとエラーバジェット
2.2.2　何を計測するか：SLIの利用
2.3　うまく行った例
2.3.1　SLIの仕様からSLIの実装への移行
2.3.2　SLIの計測
2.3.3　SLIを使った最初のSLOの計算
2.4　適切な時間ウィンドウの選択
2.5　ステークホルダーの同意を得る
2.5.1　エラーバジェットポリシーの確立
2.5.2　SLOとエラーバジェットポリシーのドキュメント化
2.5.3　ダッシュボードとレポート
2.6　SLOターゲットの継続的改善
2.6.1　SLOの品質の改善
2.7　SLOとエラーバジェットを使った意思決定
2.8　高度なトピック
2.8.1　ユーザージャーニーのモデリング
2.8.2　インタラクションの重要性の段階付け
2.8.3　依存関係のモデル化
2.8.4　SLOを緩めてみる
2.9　まとめ

3章 SLOエンジニアリングのケーススタディ
3.1　EvernoteにおけるSLOの物語
3.1.1　EvernoteがSREモデルを採用した理由
3.1.2　SLOの導入：進行中の旅路
3.1.3　顧客とクラウドプロバイダーの間にあるSLOの壁を壊す
3.1.4　現状
3.2　Home DepotのSLOの物語
3.2.1　SLO文化プロジェクト
3.2.2　最初のSLO群
3.2.3　SLOの普及
3.2.4　VALETデータ収集の自動化
3.2.5　SLOの急増
3.2.6　バッチアプリケーションへのVALETの適用
3.2.7　テストでのVALETの利用
3.2.8　将来的な野望
3.2.9　まとめ
3.3　結論

4章 モニタリング
4.1　モニタリング戦略における望ましい機能
4.1.1　速度
4.1.2　計算
4.1.3　インターフェース
4.1.4　アラート
4.2　モニタリングデータのソース
4.2.1　例
4.3　モニタリングシステムの管理
4.3.1　設定をコードとして扱う
4.3.2　一貫性の推進
4.3.3　疎結合の優先
4.4　目的を持ったメトリクス
4.4.1　意図された変更
4.4.2　依存性
4.4.3　飽和
4.4.4　ユーザートラフィックの状態
4.4.5　目的を持ったメトリクスの実装
4.5　アラートのロジックのテスト
4.6　まとめ

5章 SLOに基づくアラート
5.1　アラートについて考慮すべきこと
5.2　重大なイベントに対するアラートの方法
5.2.1　1：ターゲットのエラーレート? SLOの閾値
5.2.2　2：より長いアラートウィンドウ
5.2.3　3：アラートの期間のインクリメント
5.2.4　4：バーンレートに対するアラート
5.2.5　5：複数バーンレートのアラート
5.2.6　6：複数ウィンドウ、複数バーンレートのアラート
5.3　低トラフィックのサービスとエラーバジェットによるアラート
5.3.1　人工的なトラフィックの生成
5.3.2　サービスの組み合わせ
5.3.3　サービスとインフラストラクチャに対する変更の実施
5.3.4　SLOの引き下げあるいはウィンドウの拡大
5.4　極端な可用性のゴール
5.5　大規模環境におけるアラート
5.6　まとめ

6章 トイルの撲滅
6.1　トイルとは何か？
6.2　トイルの計測
6.3　トイルの分類学
6.3.1　ビジネスプロセス
6.3.2　プロダクションへの割り込み
6.3.3　リリースの世話
6.3.4　マイグレーション
6.3.5　コストエンジニアリングとキャパシティプランニング
6.3.6　不明瞭なアーキテクチャのトラブルシューティング
6.4　トイル管理の戦略
6.4.1　トイルの特定と計測
6.4.2　システムから発生するトイルに対するエンジニアリング
6.4.3　トイルの拒否
6.4.4　SLOを使ったトイルの削減
6.4.5　人が背後に控えるインターフェースから始める
6.4.6　セルフサービスメソッドの提供
6.4.7　上司及び同僚から支援を得る
6.4.8　トイルの削減を機能に格上げする
6.4.9　小さく始めて改善する
6.4.10　一様性の増加
6.4.11　自動化に内在するリスクの評価
6.4.12　トイルへのレスポンスの自動化
6.4.13　オープンソース及びサードパーティツールの利用
6.4.14　改善のためのフィードバックの利用
6.5　ケーススタディ
6.6　ケーススタディ1：自動化によるデータセンター内のトイルの削減
6.6.1　背景
6.6.2　問題の内容
6.6.3　実行すると決めたこと
6.6.4　最初の活動の設計：Saturnラインカードの修理
6.6.5　実装
6.6.6　2番目の活動の設計：Saturnラインカードの修理対Jupiterラインカードの修理
6.6.7　実装
6.6.8　学んだこと
6.7　ケーススタディ2：ファイラーを背後に持つホームディレクトリの廃止
6.7.1　背景
6.7.2　問題の内容
6.7.3　実行すると決めたこと
6.7.4　設計と実装
6.7.5　主要なコンポーネント
6.7.6　学んだこと
6.8　まとめ

7章 単純さ
7.1　複雑さの計測
7.2　単純さはあらゆる場面で目指すべきことであり、SREはその追求に適している
7.2.1　ケーススタディ1：エンドツーエンドのAPIの単純さ
7.2.2　ケーススタディ2：プロジェクトのライフサイクルの複雑さ
7.3　単純さの再獲得
7.3.1　ケーススタディ3：Display Ads Spiderwebの単純化
7.3.2　ケーススタディ4：共有プラットフォーム上での数百のマイクロサービスの実行
7.3.3　ケーススタディ5：pDNSはもう自分自身に依存しない
7.4　まとめ

第Ⅱ部 実践

8章 オンコール
8.1　『SRE サイトリライアビリティエンジニアリング』の「オンコール対応」の章の振り返り
8.2　Google内外でのオンコールの構成例
8.2.1　Google：新しいチームの形成
8.2.2　Evernote：クラウドへの順応
8.3　実用的な実装の詳細
8.3.1　ページャーの負荷の解剖学
8.3.2　オンコールの柔軟性
8.3.3　オンコールチームの力学
8.4　まとめ

9章 インシデント対応
9.1　Googleにおけるインシデント管理
9.1.1　インシデントコマンドシステム
9.1.2　インシデント対応における主な役割
9.2　ケーススタディ
9.2.1　ケーススタディ1：ソフトウェアのバグ――ライトはついているのに誰も（Googleの）ホームにいない
9.2.2　ケーススタディ2：サービスの障害――できるものなら捕まえて
9.2.3　ケーススタディ3：電源喪失――雷に2回打たれるなどということは起こらない……それが起こるまでは
9.2.4　ケーススタディ4：PagerDutyにおけるインシデント対応
9.3　ベストプラクティスの実践
9.3.1　インシデント対応のトレーニング
9.3.2　事前準備
9.3.3　練習
9.4　まとめ

10章 ポストモーテムの文化：失敗からの学び
10.1　ケーススタディ
10.2　良くないポストモーテム
10.2.1　このポストモーテムが良くない理由
10.3　良いポストモーテム
10.3.1　このポストモーテムが良い理由
10.4　組織的なインセンティブ
10.4.1　非難のない振る舞いのモデル化と実施
10.4.2　ポストモーテムの成果に対する報酬
10.4.3　ポストモーテムのオープンな共有
10.4.4　ポストモーテム文化の失敗への対応
10.5　ツールとテンプレート
10.5.1　ポストモーテムのテンプレート
10.5.2　ポストモーテムのツール
10.6　まとめ

11章 負荷の管理
11.1　Google Cloudのロードバランシング
11.1.1　anycast
11.1.2　Maglev
11.1.3　Global Software Load Balancer
11.1.4　Google Front End
11.1.5　GCLB：低レイテンシー
11.1.6　GCLB：高可用性
11.1.7　ケーススタディ1：GCLB上でのPokemon GO
11.2　オートスケーリング
11.2.1　不健全なマシンの処理
11.2.2　ステートフルなシステムの扱い
11.2.3　保守的な設定
11.2.4　設定の制約
11.2.5　キルスイッチと手動オーバーライドの取り込み
11.2.6　バックエンドの過負荷の回避
11.2.7　トラフィックの不均衡の回避
11.3　負荷の管理のための戦略を組み合わせる
11.3.1　ケーススタディ2：ロードシェディングが自らの首を絞める
11.4　まとめ

12章 非抽象的な大規模システム設計の紹介
12.1　NALSDとは何か？
12.2　なぜ「非抽象的」なのか？
12.3　AdWordsの例
12.3.1　設計プロセス
12.3.2　初期の要件
12.3.3　1台のマシン
12.3.4　分散システム
12.4　まとめ

13章 データ処理パイプライン
13.1　パイプラインアプリケーション
13.1.1　データの並び替えあるいは構造化のためのイベント処理/データ変換
13.1.2　データ分析
13.1.3　機械学習
13.2　パイプラインのベストプラクティス
13.2.1　サービスレベル目標の定義と計測
13.2.2　依存性障害のための計画
13.2.3　パイプラインのドキュメンテーションの作成と管理
13.2.4　開発ライフサイクルのマッピング
13.2.5　ホットスポットの低減とワークロードパターン
13.2.6　オートスケーリングの実装とリソース計画
13.2.7　アクセス制御とセキュリティポリシーの遵守
13.2.8　プランのエスカレーションパス
13.3　パイプラインの要求と設計
13.3.1　必要な機能は？
13.3.2　冪等と2フェーズの変換
13.3.3　チェックポイント処理
13.3.4　コードのパターン
13.3.5　パイプラインのプロダクションレディネス
13.4　パイプラインの障害：回避と対応
13.4.1　潜在的な障害の形態
13.4.2　潜在的な原因
13.5　ケーススタディ：Spotify
13.5.1　イベント配信
13.5.2　イベント配信システムの設計とアーキテクチャ
13.5.3　イベント配信システムの運用
13.5.4　顧客の統合とサポート
13.5.5　まとめ
13.6　結論

14章 設定の設計とベストプラクティス
14.1　設定とは何か？
14.1.1　設定と信頼性
14.1.2　哲学と仕組みの分離
14.2　設定の哲学
14.2.1　ユーザーに質問する設定
14.2.2　質問はユーザーの目標に近いものであるべき
14.2.3　必須の質問とオプションの質問
14.2.4　単純さからの脱却
14.3　設定の仕組み
14.3.1　設定と結果データの分離
14.3.2　ツールの重要性
14.3.3　所有権と変更追跡
14.3.4　安全な設定変更の適用
14.4　まとめ

15章 設定の詳細
15.1　設定が引き起こすトイル
15.2　設定が引き起こすトイルの削減
15.3　設定システムの重要な属性と落とし穴
15.3.1　落とし穴1：設定をプログラミング言語の問題と認識しない
15.3.2　落とし穴2：偶然あるいはアドホックな言語機能の設計
15.3.3　落とし穴3：過剰なドメイン固有の最適化
15.3.4　落とし穴4：「設定の評価」への「副作用」の混入
15.3.5　落とし穴5：Python、Ruby、Luaのような既存の汎用スクリプティング言語の利用
15.4　設定言語の統合
15.4.1　特定のフォーマットでの設定の生成
15.4.2　複数のアプリケーションの駆動
15.5　既存のアプリケーションの統合：Kubernetes
15.5.1　Kubernetesが提供するもの
15.5.2　Kubernetesの設定の例
15.5.3　設定言語の統合
15.6　カスタムアプリケーション（インハウスソフトウェア）の統合
15.7　効果的な設定システムの運用
15.7.1　バージョニング
15.7.2　ソース管理
15.7.3　ツール
15.7.4　テスト
15.8　いつ設定を評価するか
15.8.1　非常に早い段階：JSONのチェックイン
15.8.2　途中の段階：ビルド時点での評価
15.8.3　終盤：実行時の評価
15.9　不正な設定に対するガード
15.10　まとめ

16章 カナリアリリース
16.1　リリースエンジニアリングの原則
16.2　リリースの速度と信頼性のバランス
16.3　カナリアとはなにか？
16.4　リリースエンジニアリングとカナリア
16.4.1　カナリアプロセスの要求
16.4.2　サンプルのセットアップ
16.5　ロールフォワードデプロイメント対シンプルなカナリアデプロイメント
16.6　カナリアの実装
16.6.1　SLOとエラーバジェットに対するリスクの最小化
16.6.2　カナリアの対象数と期間の選択
16.7　メトリクスの選択と評価
16.7.1　メトリクスは問題を示すものであるべき
16.7.2　メトリクスは代表的で起因を示すものであるべき
16.7.3　事前/事後の評価はリスクを含む
16.7.4　より優れたメトリクス選択のための段階的なカナリアの利用
16.8　依存関係と隔離
16.9　非インタラクティブなシステムでのカナリア
16.10　モニタリングデータに対する要求
16.11　関連する概念
16.11.1　ブルー/グリーンデプロイメント
16.11.2　人工的な負荷生成
16.11.3　トラフィックティーイング
16.12　まとめ

第Ⅲ部 プロセス

17章 過負荷の特定と回復
17.1　負荷から過負荷へ
17.2　ケーススタディ1：チームの半分が去った時点での作業過負荷
17.2.1　背景
17.2.2　問題の表明
17.2.3　実行すると決めたこと
17.2.4　実装
17.2.5　学んだこと
17.3　ケーススタディ2：組織及び作業負荷の変更後の認知過負荷
17.3.1　背景
17.3.2　問題の表明
17.3.3　実行すると決めたこと
17.3.4　実施
17.3.5　効果
17.3.6　学んだこと
17.4　過負荷の緩和のための戦略
17.4.1　過負荷の症状の認識
17.4.2　過負荷の低減とチームの健全性の回復
17.5　まとめ

18章 SREのエンゲージメントモデル
18.1　サービスのライフサイクル
18.1.1　フェーズ1：アーキテクチャと設計
18.1.2　フェーズ2：活発な開発
18.1.3　フェーズ3：限定公開
18.1.4　フェーズ4：一般公開（GA）
18.1.5　フェーズ5：非推奨化
18.1.6　フェーズ6：放棄
18.1.7　フェーズ7：サポート終了
18.2　関係性のセットアップ
18.2.1　ビジネスとプロダクションの優先順位のコミュニケーション
18.2.2　リスクの特定
18.2.3　目標を揃える
18.2.4　基本原則の設定
18.2.5　計画と実行
18.3　効率的な継続的関係性の維持
18.3.1　よりうまく共同で働けるようになることへの時間の投資
18.3.2　オープンなコミュニケーション経路の維持
18.3.3　定期的なサービスレビューの実施
18.3.4　基本原則がずれ始めた時点での再評価
18.3.5　SLOとエラーバジェットに基づく優先順位の調整
18.3.6　適切なミスの処理
18.4　より大規模な環境へのSREのスケール
18.4.1　単一のSREチームでの複数サービスのサポート
18.4.2　複数のSREチーム環境の構造化
18.4.3　変化する環境へのSREチームの構造の適応
18.4.4　まとまりのある分散SREチームの運営
18.5　関係性の終了
18.5.1　ケーススタディ1：Ares
18.5.2　ケーススタディ2：データ分析パイプライン
18.6　まとめ

19章 SRE：壁の向こうへの到達
19.1　我々が自明だと考える真実
19.1.1　信頼性は最も重要な機能
19.1.2　モニタリングではなくユーザーが信頼性を決める
19.1.3　プラットフォームを動作させるなら、信頼性はパートナーシップである
19.1.4　重要なものはすべていつかプラットフォーム化する
19.1.5　顧客が苦労しているなら、速度を落とさなければならない
19.1.6　SREは顧客と共に実践しなければならなくなる
19.2　ハウツー：顧客とのSRE
19.2.1　ステップ1：SLOとSLIが会話の手段
19.2.2　ステップ2：モニタリングの監査と共有ダッシュボードの構築
19.2.3　ステップ3：計測と再交渉
19.2.4　ステップ4：設計レビューとリスク分析
19.2.5　ステップ5：実践、実践、実践
19.2.6　思慮深く規律を守る
19.3　まとめ

20章 SREチームのライフサイクル
20.1SRE　なしでのSREの実践
20.2SRE　ロールの開始
20.2.1　最初のSREを見つける
20.2.2　最初のSREの配置
20.2.3　最初のSREの立ち上げ
20.2.4　分散SRE
20.3　最初のSREチーム
20.3.1　形成期
20.3.2　混乱期
20.3.3　統一期
20.3.4　機能期
20.4　さらなるSREチームの形成
20.4.1　サービスの複雑さ
20.4.2　SREの展開
20.4.3　地理的な分割
20.5　多数のチームの運営のための推奨プラクティス
20.5.1　ミッションコントロール
20.5.2　SRE Exchange
20.5.3　トレーニング
20.5.4　横断的プロジェクト
20.5.5　SREの流動性
20.5.6　出張
20.5.7　ローンチ調整エンジニアリングチーム
20.5.8　プロダクションエクセレンス
20.5.9　SREへの投資と雇用
20.6　まとめ

21章 SREにおけるIT変更管理
21.1　SREは変化を抱擁する
21.2　変更管理の紹介
21.2.1　Lewinの3ステージモデル
21.2.2　マッキンゼーの7-Sモデル
21.2.3　Kotterの変更をリードするための8ステッププロセス
21.2.4　ProsciのADKARモデル
21.2.5　感情ベースのモデル
21.2.6　デミングのサイクル
21.2.7　これらの理論のSREへの適用
21.3　ケーススタディ1：Wazeのスケーリング――アドホックな変更から計画された変更へ
21.3.1　背景
21.3.2　メッセージキュー：信頼性をメンテナンスしながらのシステムの置き換え
21.3.3　変更の次のサイクル：デプロイメントプロセスの改善
21.3.4　学んだこと
21.4　ケーススタディ2：SREにおける共通ツールの採用
21.4.1　背景
21.4.2　問題の状況
21.4.3　実行すると決めたこと
21.4.4　設計
21.4.5　実装：モニタリング
21.4.6　学んだこと
21.5　まとめ

まとめ
この先……
将来は過去に属する
SRE + ＜他の分野＞
しずく、細流、そして奔流
SREは私たち全員のもの
謝意

付録A SLOドキュメントの例
付録B エラーバジェットポリシーの例
付録C ポストモーテム分析の結果

索引

コラム目次
プロダクションの知恵
事例：トイルに対する手作業でのレスポンス
レガシーシステム
運用作業の定義（プロジェクトの作業とオーバーヘッドとの対比）
プレイブックのメンテナンス
適切なレスポンスタイム
シフトの長さ
とても短いJsonnetの紹介
異なるレートで変更されるコンポーネントの分離
共有の目標：New York TimesにおけるSREのエンゲージメント
既存のチームのSREチームへの転換