book

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

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.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.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.1　リスクの管理　　3.2　サービスリスクの計測　　3.3　サービスのリスク許容度　　　3.3.1　コンシューマサービスにおけるリスク許容度の明確化　　　3.3.2　インフラストラクチャサービスのリスク許容度の明確化　　3.4　エラーバジェットの活用　　　3.4.1　エラーバジェットの形成　　　3.4.2　メリット　　　重要な知見
　　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.1　トイルの定義　　5.2　トイルは少ない方が良い理由　　　トイルの計算　　5.3　エンジニアリングであるための条件　　5.4　トイルは常に悪なのか？　　5.5　まとめ
　　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.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.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.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.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.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.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.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.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.1　Googleにおけるポストモーテムの哲学　　　ベストプラクティス：非難を避け、建設的であり続けること　　15.2　コラボレーションと知識の共有　　　ベストプラクティス：ポストモーテムをレビューされないままにはしない　　15.3　ポストモーテムの文化の導入　　　ベストプラクティス：正しいことを行った人には目に見える報酬を　　　ベストプラクティス：ポストモーテムの効果に対するフィードバックを求める　　15.4　まとめと改善の継続
　　16.1　Escalator　　16.2　Outalator　　　独自のOutalatorを作りましょう　　　16.2.1　集計　　　16.2.2　タグ付け　　　16.2.3　分析　　　16.2.4　予想外のメリット
　　　テストと平均修復時間との関係　　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.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.1　パワーは解答にあらず　　19.2　DNSを使ったロードバランシング　　19.3　仮想IPアドレスでのロードバランシング
　　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.1　「クエリ/秒」の落とし穴　　21.2　顧客単位での制限　　21.3　クライアント側でのスロットリング　　21.4　重要度　　21.5　利用率のシグナル　　21.6　過負荷によるエラーへの対応　　　21.6.1　リトライの判断　　21.7　接続によって生じる負荷　　21.8　まとめ
　　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　まとめ
　　　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.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.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.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.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.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.1　運用負荷の管理　　29.2　割り込みへの対処を決定する要素　　29.3　不完全なマシン　　　29.3.1　認知的フロー状態　　　29.3.2　1つのことをうまく行う　　　29.3.3　真剣な解決策　　　29.3.4　割り込みの削減
　　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.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.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.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　まとめ
　　B.1　処理の適切な中止　　　事例　　B.2　段階的なロールアウト　　B.3　SLOの定義はユーザーの観点で　　　事例　　B.4　エラーバジェット　　B.5　モニタリング　　B.6　ポストモーテム　　B.7　キャパシティプランニング　　B.8　過負荷と障害　　B.9　SREチーム
　　　教訓　　　タイムライン　　　参考情報

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

編者紹介

Betsy Beyer（ベッツィ・ベイヤー）: Googleに勤めるニューヨーク在住のテクニカルライターで、サイトリライアビリティエンジニアリングを専門としている。これまで、マウンテンビューのGoogleのデータセンター及びハードウェア運用チームや、世界中に配置されているデータセンターのためのドキュメントを書いてきた。ニューヨークに移る前はスタンフォード大学のテクニカルライティングの講師を務めていた。現在の職に就くまでに国際関係及び英文学を学び、スタンフォード大学とテュレーン大学から学位を得ている。
Chris Jones（クリス・ジョーンズ）: Google App Engine担当のサイトリライアビリティエンジニア。Google App Engineは、1日に280億以上のリクエストをさばくクラウドのPlatform-as-a-Serviceである。彼はサンフランシスコ在住で、以前はGoogleの広告統計の処理とフィード、データウェアハウジング、カスタマーサポートシステムを担当していた。その他に、アカデミアのIT、選挙運動のデータ分析の仕事、BSDのカーネルハックなどに携わり、その過程でコンピュータエンジニアリング、経済学、技術政策の学位を取得した。彼はまた公認技術士でもある。
Jennifer Petoff（ジェニファー・ペトフ）: アイルランドのダブリン在住のGoogleのSREチームのプログラムマネージャー。科学研究、エンジニアリング、人材、広告運用を含む幅広い領域でグローバルな大規模プロジェクトを管理してきた。化学産業界で8年を過ごした後にGoogleに加わった。彼女はスタンフォード大学から化学の博士号を、そしてロチェスター大学から化学と心理学の学位を取得している。 ...