SRE サイトリライアビリティエンジニアリング Googleの信頼性を支えるエンジニアリングチーム

詳細目次

本書への推薦の言葉
監訳者まえがき
序文
はじめに
第Ⅰ部　イントロダクション
1章　イントロダクション
1.1　サービス管理へのシステム管理者のアプローチ
1.2　サービス管理への Googleのアプローチ：サイトリライアビリティエンジニアリング
1.3　SREの信条
1.3.1　エンジニアリングへの継続的な注力の保証
1.3.2　サービスの SLOを下回ることなく、変更の速度の最大化を追求する
1.3.3　モニタリング
1.3.4　緊急対応
1.3.5　変更管理
1.3.6　需要の予測とキャパシティプランニング
1.3.7　プロビジョニング
1.3.8　効率とパフォーマンス
1.4　始まりの終わり
2章　SREの観点から見た Googleのプロダクション環境
2.1　ハードウェア
2.2　ハードウェアを「組織化」するシステムソフトウェア
2.2.1　マシン群の管理
2.2.2　ストレージ
2.2.3　ネットワーク
2.3　他のシステムソフトウェア
2.3.1　ロックサービス
2.3.2　モニタリングとアラート
2.4　Googleのソフトウェアインフラストラクチャ
2.5　Googleの開発環境
2.6　シェークスピア：サンプルのサービス
2.6.1　リクエストのライフサイクル
2.6.2　ジョブとデータの編成
第Ⅱ部　原則
Ⅱ.1　Google SREが推奨する参考文献
3章　リスクの受容
3.1　リスクの管理
3.2　サービスリスクの計測
3.3　サービスのリスク許容度
3.3.1　コンシューマサービスにおけるリスク許容度の明確化
3.3.2　インフラストラクチャサービスのリスク許容度の明確化
3.4　エラーバジェットの活用
3.4.1　エラーバジェットの形成
3.4.2　メリット
4章　サービスレベル目標
4.1　サービスレベルに関する用語
4.1.1　指標
4.1.2　目標
4.1.3　アグリーメント
4.2　指標の実際
4.2.1　サービスの提供者とユーザーの関心事
4.2.2　指標の収集
4.2.3　集計
4.2.4　指標の標準化
4.3　目標の実際
4.3.1　目標の定義
4.3.2　ターゲットの選択
4.3.3　計測値のコントロール
4.3.4　SLOによる期待の設定
4.4　アグリーメントの実際
5章　トイルの撲滅
5.1　トイルの定義
5.2　トイルは少ない方が良い理由
5.3　エンジニアリングであるための条件
5.4　トイルは常に悪なのか？
5.5　まとめ
6章　分散システムのモニタリング
6.1　定義
6.2　モニタリングの必要性
6.3　モニタリングにおける妥当な期待値の設定
6.4　症状と原因
6.5　ブラックボックスとホワイトボックス
6.6　4大シグナル
6.7　テイルレイテンシに関する懸念（あるいはインスツルメンテーションとパフォーマンス）
6.8　適切な計測の粒度の選択
6.9　可能な限りシンプルに、ただしやり過ぎないこと
6.10　原則のとりまとめ
6.11　長期間にわたるモニタリング
6.11.1　Bigtableの SRE：過剰なアラートの物語
6.11.2　Gmail：スクリプト化された予測可能なレスポンスの手動送信
6.11.3　長期的な視点
6.12　まとめ
7章　Googleにおける自動化の進化
7.1　自動化の価値
7.1.1　一貫性
7.1.2　プラットフォーム
7.1.3　高速な修復
7.1.4　素早いアクション
7.1.5　時間の節約
7.2　Google SREにとっての価値
7.3　自動化のユースケース
7.3.1　Google SREによる自動化のユースケース
7.3.2　自動化のクラスの階層
7.4　自分の仕事の自動化：何もかも自動化する
7.5　苦痛の緩和：クラスタのターンアップへの自動化の適用
7.5.1　Prodtestでの不整合の検出
7.5.2　不整合の冪等な解消
7.5.3　特化する傾向
7.5.4　サービス指向のクラスタのターンアップ
7.6　Borg：ウェアハウススケールコンピュータの誕生
7.7　基本的機能としての信頼性
7.8　自動化のすすめ
8章　リリースエンジニアリング
8.1　リリースエンジニアの役割
8.2　哲学
8.2.1　セルフサービスモデル
8.2.2　高速性
8.2.3　密封ビルド
8.2.4　ポリシーと手順の強制
8.3　継続的ビルドとデプロイメント
8.3.1　ビルド
8.3.2　ブランチ
8.3.3　テスト
8.3.4　パッケージ化
8.3.5　Rapid
8.3.6　デプロイメント
8.4　設定管理
8.5　まとめ
8.5.1　Googleだけに限った話ではない
8.5.2　リリースエンジニアリングは初期の段階から始めよう
9章　単純さ
9.1　システムの安定性とアジリティ
9.2　退屈の美徳
9.3　自分のコードはあきらめないぞ！
9.4　削除した行の計測
9.5　最小限の API
9.6　モジュラー性
9.7　リリースの単純さ
9.8　単純な結論
第Ⅲ部　実践
Ⅲ.1　モニタリング
Ⅲ.2　インシデント対応
Ⅲ.3　ポストモーテムと根本原因分析
Ⅲ.4　テスト
Ⅲ.4.1　キャパシティプランニング
Ⅲ.5　開発
Ⅲ.6　プロダクト
Ⅲ.7　Google SREが推奨する参考文献
10章　時系列データからの実践的なアラート
10.1　Borgmonの誕生
10.2　アプリケーションのインスツルメンテーション
10.3　エクスポートされたデータの収集
10.4　時系列のアリーナにおけるストレージ
10.4.1　ラベルとベクタ
10.5　ルールの評価
10.6　アラート
10.7　モニタリングのトポロジーのシャーディング
10.8　ブラックボックスモニタリング
10.9　設定のメンテナンス
10.10　10年が経過して
11章　オンコール対応
11.1　イントロダクション
11.2　オンコールエンジニアの日常生活
11.3　バランスの取れたオンコール
11.3.1　量におけるバランス
11.3.2　質におけるバランス
11.3.3　補償
11.4　安心感
11.5　不適切な運用負荷の回避
11.5.1　運用の過負荷
11.5.2　油断ならない敵：低すぎる運用負荷
11.6　まとめ
12章　効果的なトラブルシューティング
12.1　理論
12.2　実践
12.2.1　問題のレポート
12.2.2　トリアージ
12.2.3　検証
12.2.4　診断
12.2.5　テストと対応
12.3　否定的な結果の素晴らしさ
12.3.1　対策
12.4　ケーススタディ
12.5　トラブルシューティングを容易にするために
12.6　まとめ
13章　緊急対応
13.1　システムが壊れた際に行うこと
13.2　テストによって引き起こされた緊急事態
13.2.1　詳細
13.2.2　レスポンス
13.2.3　障害から分かったこと
13.3　変更が引き起こした緊急事態
13.3.1　詳細
13.3.2　対応
13.3.3　障害から分かったこと
13.4　プロセスが引き起こした緊急事態
13.4.1　詳細
13.4.2　対応
13.4.3　障害から分かったこと
13.5　解決できない問題は存在しない
13.6　過去から学び、繰り返さない
13.6.1　サービス障害の歴史を残す
13.6.2　大きな、むしろありそうもない問いかけをしてみよう
13.6.3　予防的なテストのすすめ
13.7　まとめ
14章　インシデント管理
14.1　管理されていないインシデント
14.2　管理されていないインシデントの詳細分析
14.2.1　技術的な問題への極端な集中
14.2.2　貧弱なコミュニケーション
14.2.3　勝手な動き
14.3　インシデント管理のプロセスの構成要素
14.3.1　責任の再帰的な分離
14.3.2　明確な司令所
14.3.3　ライブインシデント状況ドキュメント
14.3.4　はっきりとした引き継ぎ
14.4　管理されたインシデント
14.5　インシデントと宣言すべき場合
14.6　まとめ
15章　ポストモーテムの文化：失敗からの学び
15.1　Googleにおけるポストモーテムの哲学
15.2　コラボレーションと知識の共有
15.3　ポストモーテムの文化の導入
15.4　まとめと改善の継続
16章　サービス障害の追跡
16.1　Escalator
16.2　Outalator
16.2.1　集計
16.2.2　タグ付け
16.2.3　分析
16.2.4　予想外のメリット
17章　信頼性のためのテスト
17.1　ソフトウェアテストの種類
17.1.1　伝統的なテスト
17.1.2　プロダクションテスト
17.2　テストの作成と環境の構築
17.3　大規模なテスト
17.3.1　スケーラブルなツールのテスト
17.3.2　ディザスタのテスト
17.3.3　速度の重要性
17.3.4　プロダクションへのプッシュ
17.3.5　予想されるテストの失敗
17.3.6　結合
17.3.7　プロダクション環境におけるプローブ
17.4　まとめ
18章　SREにおけるソフトウェアエンジニアリング
18.1　SRE内でのソフトウェアエンジニアリングの重要性
18.2　Auxonのケーススタディ：プロジェクトの背景と問題の領域
18.2.1　旧来のキャパシティプランニング
18.2.2　Googleにおけるソリューション：インテントベースのキャパシティプランニング
18.3　インテントベースのキャパシティプランニング
18.3.1　インテントを示すもの
18.3.2　Auxonの紹介
18.3.3　要求と実装：成功と学んだこと
18.3.4　認知の向上と採用の推進
18.3.5　チームの力学
18.4　SREにおけるソフトウェアエンジニアリングの推進
18.4.1　SREにおけるソフトウェアエンジニアリング文化の構築の成功：採用と開発期間
18.4.2　達成
18.5　まとめ
19章　フロントエンドにおけるロードバランシング
19.1　パワーは解答にあらず
19.2　DNSを使ったロードバランシング
19.3　仮想 IPアドレスでのロードバランシング
20章　データセンターでのロードバランシング
20.1　理想的なケース
20.2　不良タスクの特定：フロー制御とレイムダック
20.2.1　健全ではないタスクに対するシンプルなアプローチ：フロー制御
20.2.2　不健全なタスクへの確実なアプローチ：レイムダック状態
20.3　サブセットの設定によるコネクションプールの制限
20.3.1　適切なサブセットの選択
20.3.2　サブセットの選択アルゴリズム：ランダムなサブセットの選択
20.3.3　サブセット選択のアルゴリズム：決定的なサブセット選択
20.4　ロードバランシングのポリシー
20.4.1　シンプルなラウンドロビン
20.4.2　最小負荷ラウンドロビン
20.4.3　重み付きラウンドロビン
21章　過負荷への対応
21.1　「クエリ /秒」の落とし穴
21.2　顧客単位での制限
21.3　クライアント側でのスロットリング
21.4　重要度
21.5　利用率のシグナル
21.6　過負荷によるエラーへの対応
21.6.1　リトライの判断
21.7　接続によって生じる負荷
21.8　まとめ
22章　カスケード障害への対応
22.1　カスケード障害の原因及び回避のための設計
22.1.1　サーバーの過負荷
22.1.2　リソースの枯渇
22.1.3　利用できないサービス
22.2　サーバーの過負荷の回避
22.2.1　キューの管理
22.2.2　ロードシェディングとグレースフルデグラデーション
22.2.3　リトライ
22.2.4　レイテンシとタイムアウト
22.3　起動直後の低パフォーマンスとコールドキャッシュ
22.3.1　スタックは常に下っていくようにすること
22.4　カスケード障害を引き起こす条件
22.4.1　プロセスの停止
22.4.2　プロセスのアップデート
22.4.3　ロールアウト
22.4.4　自然な利用の増大
22.4.5　計画済みの変更、ドレイン、ターンダウン
22.5　カスケード障害に備えるためのテスト
22.5.1　テストによる障害の発生とその後の観察
22.5.2　一般的なクライアントのテスト
22.5.3　重要度の低いバックエンドのテスト
22.6　カスケード障害に対応するためにすぐに行うべき手順
22.6.1　リソースの追加
22.6.2　ヘルスチェックが障害を引き起こさないようにする
22.6.3　サーバーの再起動
22.6.4　トラフィックのドロップ
22.6.5　デグレーデッドモードへの移行
22.6.6　バッチの負荷の排除
22.6.7　問題のあるトラフィックの排除
22.7　まとめ
23章　クリティカルな状態の管理 :信頼性のための分散合意
23.1　合意を利用する目的：分散システムの協調障害
23.1.1　ケーススタディ 1：スプリットブレイン問題
23.1.2　ケーススタディ 2：人間の介入を必要とするフェイルオーバー
23.1.3　ケーススタディ 3：問題のあるグループメンバーシップアルゴリズム
23.2　分散合意の動作
23.2.1　Paxosの概要：サンプルのプロトコル
23.3　分散合意のためのシステムアーキテクチャパターン
23.3.1　信頼性を持つ複製ステートマシン
23.3.2　信頼性を持つ複製データストア及び設定ストア
23.3.3　リーダー選出を利用する高可用性を持つ処理
23.3.4　分散協調及びロックサービス
23.3.5　信頼性を持つ分散キュー及びメッセージング
23.4　分散合意のパフォーマンス
23.4.1　Multi-Paxos：詳細なメッセージフロー
23.4.2　読み取り負荷が大きいワークロードのスケーリング
23.4.3　クォーラムのリース
23.4.4　分散合意のパフォーマンスとネットワークのレイテンシ
23.4.5　パフォーマンスに関する考察：Fast Paxos
23.4.6　安定したリーダー
23.4.7　バッチ処理
23.4.8　ディスクアクセス
23.5　分散合意ベースのシステムのデプロイ
23.5.1　レプリカ数
23.5.2　レプリカの配置
23.5.3　キャパシティとロードバランシング
23.6　分散合意システムのモニタリング
23.7　まとめ
24章　cronによる分散定期スケジューリング
24.1　cron
24.1.1　イントロダクション
24.1.2　信頼性という観点
24.2　cronジョブと冪等性
24.3　大規模環境における cron
24.3.1　拡張されたインフラストラクチャ
24.3.2　拡張された要求
24.4　Googleにおける cronの構築
24.4.1　cronジョブの状態の追跡
24.4.2　Paxosの利用
24.4.3　リーダーとフォロワーの役割
24.4.4　状態の保存
24.4.5　大規模な cronの実行
24.5　まとめ
25章　データ処理のパイプライン
25.1　パイプラインのデザインパターンの起源
25.2　シンプルなパイプラインパターンでのビッグデータの初期の効果
25.3　定期的なパイプラインパターンでの課題
25.4　不均衡な負荷の配分によるトラブル
25.5　分散環境における定期パイプラインの欠点
25.5.1　定期パイプラインにおけるモニタリングの問題
25.5.2　“Thundering Herd”問題
25.5.3　モアレ負荷パターン
25.6　Google Workflowの紹介
25.6.1　Model-View-Controllerパターンとしての Workflow
25.7　Workflowにおける実行のステージ
25.7.1　Workflowの正しさの保証
25.8　ビジネスの継続性の保証
25.9　まとめ、そして終わりに
26章　データの完全性：What You Read Is What You Wrote
26.1　データの完全性への厳格な要求
26.1.1　データ完全性をきわめて高くするための戦略の選択
26.1.2　バックアップとアーカイブ
26.1.3　大局的な視点から見たクラウド環境の要件
26.2　データの完全性及び可用性の管理における Google SREの目標
26.2.1　データの完全性は手段であり、目標とするのはデータの可用性である
26.2.2　バックアップシステムよりもリカバリのシステムを提供しよう
26.2.3　データの損失につながる障害の種類
26.2.4　深く、そして広くデータの完全性を管理することの難しさ
26.3　データ完全性の課題への Google SREの対処
26.3.1　データ完全性の障害の形態の 24種の組み合わせ
26.3.2　第 1のレイヤー：論理削除
26.3.3　第 2のレイヤー：バックアップと関連するリカバリの方法
26.3.4　包括的な階層：レプリケーション
26.3.5　テラバイト対エクサバイト：大きい「だけ」ではなくなるバックアップ
26.3.6　第 3のレイヤー：早期の検出
26.3.7　データリカバリがうまくいくことの確認
26.4　ケーススタディ
26.4.1　Gmail - 2011年 2月：GTapeからのリストア
26.4.2　Google Music - 2012年 3月：暴走した削除の検出
26.5　データの完全性に対する SREの一般原則の適用
26.5.1　初心者の心構えを忘れないこと
26.5.2　信頼しつつも検証を
26.5.3　願望は戦略にあらず
26.5.4　多層防御
26.6　まとめ
27章　大規模なプロダクトのローンチにおける信頼性
27.1　ローンチ調整エンジニアリング
27.1.1　ローンチ調整エンジニアの役割
27.2　ローンチプロセスのセットアップ
27.2.1　ローンチチェックリスト
27.2.2　収束と単純化の推進
27.2.3　予想外のローンチ
27.3　ローンチチェックリストの開発
27.3.1　アーキテクチャと依存関係
27.3.2　統合
27.3.3　キャパシティプランニング
27.3.4　障害の形態
27.3.5　クライアントの動作
27.3.6　プロセスと自動化
27.3.7　開発のプロセス
27.3.8　外部の依存対象
27.3.9　ロールアウトの計画
27.4　信頼性のあるローンチのためのテクニック
27.4.1　逐次的かつ段階的なロールアウト
27.4.2　機能フラグフレームワーク
27.4.3　攻撃的なクライアントの挙動への対処
27.4.4　過負荷時の挙動とロードテスト
27.5　LCEの発展
27.5.1　LCEチェックリストの進化
27.5.2　LCEが解決しなかった問題
27.6　まとめ
第Ⅳ部　管理
Ⅳ.1　Google SREが推奨する参考文献
28章　SREの成長を加速する方法：新人からオンコール担当、　　　そしてその先へ
28.1　自分の後継 SRE（たち）を雇用した後にすべきことは？
28.2　初期の学習経験：混沌ではなく構造を提供する
28.2.1　順序立てて積み重ねる学習の道筋
28.2.2　単純作業ではなく、目的のはっきりしたプロジェクトの作業を受け持ってもらうこと
28.3　優れたリバースエンジニアリングと柔軟な思考の育成
28.3.1　リバースエンジニアリング：システムの動作を理解する
28.3.2　統計的及び比較的思考：プレッシャーの下での科学的手法の活用
28.3.3　即興の芸術家：予想外の事態への対応
28.3.4　総合的なトレーニング：プロダクションサービスのリバースエンジニアリング
28.4　上を目指すオンコール担当者の 5つのプラクティス
28.4.1　障害への渇望：ポストモーテムの読み込みと共有
28.4.2　ディザスタロールプレイング
28.4.3　本物の破壊と修復
28.4.4　徒弟関係としてのドキュメンテーション
28.4.5　早期からの頻繁なオンコールのシャドウイング
28.5　オンコールの担当、そしてその先：通過儀礼と継続的な教育の実践
28.6　まとめ
29章　割り込みへの対処
29.1　運用負荷の管理
29.2　割り込みへの対処を決定する要素
29.3　不完全なマシン
29.3.1　認知的フロー状態
29.3.2　1つのことをうまく行う
29.3.3　真剣な解決策
29.3.4　割り込みの削減
30章　SREの投入による運用過負荷からのリカバリ
30.1　フェーズ 1：サービスの学習と状況の把握
30.1.1　最大のストレス発生源の特定
30.1.2　発火点の特定
30.2　フェーズ 2：状況の共有
30.2.1　チームのために良いポストモーテムを書く
30.2.2　火事を種類別に並べる
30.3　フェーズ 3：変化の推進
30.3.1　基本からのスタート
30.3.2　発火点の掃除の手助けを求める
30.3.3　根拠を説明すること
30.3.4　導く質問を投げかけること
30.4　まとめ
31章　SREにおけるコミュニケーションとコラボレーション
31.1　コミュニケーション：プロダクションミーティング
31.1.1　アジェンダ
31.1.2　出席者
31.2　SRE内でのコラボレーション
31.2.1　チームの構成
31.2.2　効率的な作業のための手法
31.3　SRE内でのコラボレーションのケーススタディ：Viceroy
31.3.1　Viceroy登場
31.3.2　課題
31.3.3　推奨事項
31.4　SRE外でのコラボレーション
31.5　ケーススタディ：DFPにおける F1へのマイグレーション
31.6　まとめ
32章　進化する SREのエンゲージメントモデル
32.1　SREのエンゲージメント：その対象、方法、理由
32.2　PRRモデル
32.3　SREのエンゲージメントモデル
32.3.1　代替サポート
32.4　プロダクションレディネスレビュー：単純 PRRモデル
32.4.1　エンゲージメント
32.4.2　分析
32.4.3　改善とリファクタリング
32.4.4　トレーニング
32.4.5　オンボーディング
32.4.6　継続的な改善
32.5　単純 PRRモデルの進化形：早期エンゲージメント
32.5.1　早期エンゲージメントの候補
32.5.2　早期エンゲージメントモデルのメリット
32.6　進化するサービス開発：フレームワークと SREプラットフォーム
32.6.1　学んだ教訓
32.6.2　SREに影響を及ぼす外部要因
32.6.3　構造的なソリューション：フレームワーク化に向かって
32.6.4　サービスや管理に関する新たなメリット
32.7　まとめ
第Ｖ部　まとめ
33章　他の業界からの教訓
33.1　業界のベテランたち
33.2　準備とディザスタテスト
33.2.1　安全への徹底した組織的集中
33.2.2　細部への注意
33.2.3　余剰キャパシティ
33.2.4　シミュレーションと実地訓練
33.2.5　トレーニングと認定
33.2.6　詳細な要求の収集と設計への集中
33.2.7　広範囲にわたる多層防御
33.3　ポストモーテムの文化
33.4　反復業務と運用のオーバーヘッドの自動化
33.5　構造化された合理的判断
33.6　まとめ
34章　まとめ
付録A　可用性の一覧
付録B　プロダクションサービスのためのベストプラクティス
B.1　処理の適切な中止
B.2　段階的なロールアウト
B.3　SLOの定義はユーザーの観点で
B.4　エラーバジェット
B.5　モニタリング
B.6　ポストモーテム
B.7　キャパシティプランニング
B.8　過負荷と障害
B.9　SREチーム
付録C　インシデント状況ドキュメントの例
付録D　ポストモーテムの例
付録E　ローンチ調整チェックリスト
付録F　プロダクションミーティングの議事録の例
参考文献
訳者あとがき
索引