Book description
GoogleのSREチームの主要メンバーによって書かれた本書は、ソフトウェアのライフサイクル全体にコミットすることで世界最大規模のソフトウェアシステムがどのように構築、導入、監視、維持されているのかを解説します。はじめにリスク管理やサービスレベル目標、リリースエンジニアリングなどSREの行動の基礎となる原則について解説し、次にインシデント管理や障害の根本原因分析、SRE内でのソフトウェア開発など大規模分散コンピューティングシステムを構築し運用するSREの実践について詳述します。急速にスケールするサービスを高い信頼性で運用する方法を解説する本書はエンジニア必携の一冊です。
Table of contents
- 大扉
- 原書大扉
- クレジット
- 本書への推薦の言葉
- 監訳者まえがき
- 謝辞
- 序文
- はじめに
- 本書の読み方
- 表記
- コードサンプル
- お問い合わせ先
- 謝辞
- 第Ⅰ部 イントロダクション
- 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 プロダクションミーティングの議事録の例
- 参考文献
- 訳者あとがき
- 編者、監訳者、訳者紹介
- カバーの説明
- 奥付
Product information
- Title: SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
- Author(s):
- Release date: August 2017
- Publisher(s): O'Reilly Japan, Inc.
- ISBN: 9784873117911
You might also like
book
データベースリライアビリティエンジニアリング ―回復力のあるデータベースシステムの設計と運用
テクノロジーの進化に合わせて、データベースもまた進化しています。従来のパフォーマンス、スケーラビリティが重要なことはもちろん、今日ではセキュリティ、インフラのコード化、CI/CD、クラウド活用といったタスクにも取り組んでいかなければなりません。 データベースの本質は、長期的に安定していること。つまりリライアビリティ（信頼性）です。時代とともにアーキテクチャやツールが変わってもこの原則は変わりません。本書はデータベースのリライアビリティを実現するための考え方を「データベースリライアビリティエンジニアリング」と定義して、その具体的な手法を紹介します。サービスのリライアビリティに関わるすべてのエンジニア必読の一冊です。
book
プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化
UberのSRE（サイト信頼性エンジニア、サイトリライアビリティエンジニア）として、マイクロサービスの本番対応向上を担当していた著者が、その取り組みから得られた知見をまとめたものです。モノリス（一枚岩）を複数のマイクロサービスに分割した後に、安定性、信頼性、スケーラビリティ、耐障害性、パフォーマンス、監視、ドキュメント、大惨事対応を備えたシステムにするために必要な原則と標準に焦点を当て、本番対応力のあるマイクロサービスを構築する手法を紹介します。本書で採用している原則と標準は、マイクロサービスだけなく多くのサービスやアプリケーションの改善にも威力を発揮します。
book
プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
本書は、顧客に価値を届けるプロダクトを作り出すプロダクトマネジメントについて学ぶ本です。プロダクトマネジメントを理解することで、企業がビジネス目標を達成しながら、顧客の課題を解決する方法を解説します。はじめにプロダクトマネージャーの役割と責任を定義し、優れた意思決定を促す戦略の立て方を紹介します。実験と最適化によって作るべきプロダクトを決めるプロセスを解説し、最後にプロダクト主導の組織を支えるための文化や方針を紹介します。ビルドトラップを避け、顧客の課題にフォーカスするプロダクトマネジメントの原則を解説する本書は、規模の大小を問わずすべてのプロダクトチーム、マネージャー、プログラマ、アーキテクト、デザイナ、マーケターに必携の一冊です。
book
大規模データ管理 ―エンタープライズアーキテクチャのベストプラクティス
データ管理と統合が急速に進化する中、複雑で緊密に結合したアーキテクチャから、現代のビジネスに対応できる、より柔軟なデータアーキテクチャへの移行が求められます。 本書は、変化が激しい時代でも長期的に持続可能な方法で大規模なデータ管理を行い、さまざまなユースケースに対応できる統合アーキテクチャを紹介します。この統合アーキテクチャを構成する、膨大なデータ利用に向けた「読み出し専用データストアアーキテクチャ」、リアルタイムなアプリケーションのための「APIアーキテクチャ」、大容量のスループットを実現する「ストリーミングアーキテクチャ」を詳述します。また技術開発、法規制、プライバシーに関する懸念など、データ管理全体を説明し、データガバナンスとセキュリティ、マスターデータ管理、セルフサービスとデータマーケットプレイス、メタデータの重要性について解説します。 企業のデータ戦略にかかわる本書は、アーキテクトはもちろん、経営者、ガバナンスチーム、データ分析・エンジニアリングチーム必携の一冊です。
