book

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

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

by Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, 澤田武男, 関根達夫, 細川一茂, 矢吹大輔, Sky株式会社玉川竜司

August 2017

Intermediate to advanced

590 pages

8h 40m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

　大扉
　原書大扉
　クレジット
　本書への推薦の言葉
　監訳者まえがき
　　謝辞
　序文
　はじめに
　　　本書の読み方　　表記　　コードサンプル　　お問い合わせ先　　謝辞
第Ⅰ部　イントロダクション
　1章　イントロダクション
　　1.1　サービス管理へのシステム管理者のアプローチ　　1.2　サービス管理へのGoogleのアプローチ：サイトリライアビリティエンジニアリング　　　DevOps？　それともSRE？　　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　目標　　　Chubbyのグローバルな計画的サービスの停止　　　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の誕生　　　Google以外での時系列データのモニタリング　　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　　　独自の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章　クリティカルな状態の管理:信頼性のための分散合意
　　　CAP定理　　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　プロダクションミーティングの議事録の例
　参考文献
　訳者あとがき
　編者、監訳者、訳者紹介
　カバーの説明
　奥付

Overview

GoogleのSREチームの主要メンバーによって書かれた本書は、ソフトウェアのライフサイクル全体にコミットすることで世界最大規模のソフトウェアシステムがどのように構築、導入、監視、維持されているのかを解説します。はじめにリスク管理やサービスレベル目標、リリースエンジニアリングなどSREの行動の基礎となる原則について解説し、次にインシデント管理や障害の根本原因分析、SRE内でのソフトウェア開発など大規模分散コンピューティングシステムを構築し運用するSREの実践について詳述します。急速にスケールするサービスを高い信頼性で運用する方法を解説する本書はエンジニア必携の一冊です。

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9784873117911Other

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills