セクションナイン の 吉田真吾（@yoshidashingo）です。
SRE本の原書が出てから早1年半が経ちました。原書はすでにオンラインで無料で読めるようになっています。
Google - Site Reliability Engineering
前回このブログでSREについて書いたのが、原書の出る1ヶ月くらい前ですね。
国内でもSRE部署の設置が急速に進んでますが、運用部門をSREと看板を掛け替えただけの劣化コピーが大量生産されていることも否めなかったりなかったり。
そもそもSREは、従来のシスアドではなくソフトウェアエンジニアです。そして、開発／運用の分断による必然的な対立関係をインセンティブ設計で統合し、サービスの成長と運用コストが比例しないように切り離すための組織設計であり、そのための技術ノウハウです。
今日は今週末発売される翻訳版SRE本「SRE サイトリライアビリティエンジニアリング」が発売されるにあたり、サーバーレスSPA本のつながりでオライリー様より一足早くご恵贈いただきましたので、夏休みの読書感想文にさせていただきます。休んでないけどね。
ちなみにこの本、原書を読んだとき(2016/3)にこりゃスゴい良い本だと思い、オライリーさんに翻訳させて欲しいとお願いしようと思い玉川さん(この本の翻訳者)に相談してみたんですね。
その際すでに玉川さんが翻訳することが決まっていたのですが、そのつながりがあった流れでサーバーレスSPA本の監訳につながったというエピソードがありました。
なので、この本が翻訳されるのを本当に今か今かと楽しみに待っていました。（まぁ後で玉川さんに色々エピソード聞いたらやっぱやらなくて良かったなと思ったんですけどね、超大変だったそうで...）
全体的な感想
- 比較的ボリュームは多いが、Google SREのさまざまな原則とそこに行き着いた思考プロセスやエピソードが真摯な文章で書かれており、一文ごとに学びと共感があるため、つまづきポイントがありません。
- 概要から各テーマにブレイクダウンしていく形式は取っているが、基本的には34編がそれぞれ独立したエッセイにもなっているため、いったん9章の原則まで読んだら、そこから中盤〜後半は自分が好きな順番で読める感じです。
- よほど英語に慣れている人を除けば翻訳版で読むほうが明らかにいろいろと機微が理解できます。
- 実践編ではGoogleの内部ツールもたくさん出てきて、かつそれらは別名のOSSとなって発展していっているものも多いので、自分たちのシステムでも実践がしやすいです。
特に翻訳版を買う意味として推したいのは、原書だと理解しにくい原則やポリシーに対する思考プロセスなど機微な情報が翻訳版だとしっかり読めるという点です。
原書を何回か通読しているにも関わらず、Google SREでよく紹介される「50%ルール」や「エラーバジェット」「徹底的な自動化」というようなキャッチーな原則の裏にある思考プロセスについてほとんど忘れているという反省からもこれは熟読したうえで実践しないとなという気持ちになりました。
SRE本、原書も当然読んだけど、結局言葉の壁のせいでキャッチーなところばかり読んでしまってたなというのが反省で、その教訓に行き着くまでの前提条件や思考プロセスや仮説検証の内容を読まないと、それぞれの教訓がどれほど参考にできるか距離感がわからないわけですわ。なんでもそうだろうけど。
— Shingo(吉田真吾) (@yoshidashingo) 2017年8月5日
いわゆる「文化」というのは組織において共通認識になっている思考プロセスによって形成されるものなので、これを正しく把握することで、「文化」というなんとなく曖昧な表現で終わらず、自分や自分のいる組織ではどういう前提を置いてITサービスマネジメントをするべきか、そのためにSREから学び実践できることはどの項目なのかということが決定できるはずです。
各章の概要
第Ⅰ部イントロダクションから第Ⅱ部原則の9章までが基本部分で、それ以降が各トピックごとのエッセーになっているので、いったんこのエントリーでは9章まで紹介してみます。
1章 イントロダクション
ここではSREが必要とされる背景とGoogle内での歴史、また「SREの信条」として、その要求プロセスごとの概要が記載されています。
上でも記載しましたがそもそもSREはシスアドではなくソフトウェアエンジニアであり、対立しがちな開発スピードとSLO達成の両立を実現するために組織として実践するのが「50%ルール」「エラーバジェット」「アラート通知を最小化するレジリエント指向な運用」「ロールアウトな変更管理」などです。
また、運用作業が50%を上回らないように「保証する」点や、SREがそもそもソフトウェアエンジニアとして採用されているということで、社内のキャリアパスとしてプロダクトのエンジニアと行き来ができるという点は人材戦略上としても非常に有益です。
運用作業が50%を超えない範囲にとどめ、運用作業の自動化や信頼性の高いフェイルオーバー方式の設計や実装に注力できるようにすることで、基本的にSREが面倒を見るシステムは定常作業のない、内部トラブルが発生した場合も自動的に素早くフェイルオーバーや切り離しが行われるようになり、実際に人による判断や作業を伴う作業を最小化することで、サービスの成長と運用作業量が比例しないように切り離されたチーム体制が構築できるように目指すのです。
また、そもそもそういった設計や実装ができるエンジニアが必要なので、採用プロセスはプロダクトのエンジニアと同様にソフトウェアエンジニアの採用をする必要があり、これはキャリアパスとして双方が比較的簡単に行き来できるということです。
つまりSRE本はエンジニアのための大規模システムを高速で開発してかつ安定的に運用するためのノウハウ本であると同時に、現代のマネージャーがどういう課題認識とそれに対する思考プロセスでIT組織運営をすべきかを示している本でもあることを示しています。
また、ポストモーテムについても概要説明がありますが、この障害報告書は巻末にサンプルも掲載されており、これを使うことで何が起きたか正確に記録し、どう対応したか、今の状況はどうか、根本原因はなにか、どう取り組むかを記録するようにしています。
重要なのは原因を探って改善していくことに関して非難をすることは無意味なのでいっさいしないことが約束されていること。また、ページャーが使われたか（アラートが鳴ったか）どうかに関わらず、むしろならなかったインシデントのほうが、モニタリングできてなかった根本的ななにかが潜んでいるはずなので大事であるとされている点です。
2章 SREの観点から見た Googleのプロダクション環境
2章ではGoogleのデータセンター群上にBorgという分散クラスタオペレーティングシステムでサービスのリソーススケジューリングを行っていることや、DC内のスイッチとしてJupiterという独自の仮想スイッチを実装し1.3Pbpsの帯域を実現している話、Colossusという分散ストレージ管理サービス、モニタリングシステムBorgmonなど、Google独自のソフトウェアの紹介がされています。
また、こういったソフトウェアを使ったサービスがどうデプロイされて運用されるかを知るためのサンプルサービスとしてシェークスピアというサンプルのサービスが用意されていることも記載されています。これを例にしてGoogleにおけるDNSやロードバランサ、バックエンドサーバーの動きが理解でき、本章以降でのこれらのソフトウェアの説明の理解の助けになります。
3章 リスクの受容
ITサービスマネジメントにおいては一般的ですが、リスクはすべてを取り除けば良いというものではなく、正しく把握したうえで管理するこｔが大事です。でなければコストが無限に必要になるからです。
ここではコンシューマサービス／インフラサービスそれぞれにおいて、サービスリスクを計測し、その許容度を明らかにし可用性のターゲットレベルを定める方法を示しています。そのうえで、可用性の許容度をエラーバジェットとして扱います、これにより開発者とSREが同一のインセンティブのもとで活動できるようになるため、それぞれの相反する思惑を都度調整する必要がなくなるという仕組みです。
4章 サービスレベル目標
前の章ですでにSLOについての話が出ていますが、ここではその設定方法が記載されています。
基本的な考えとしては、SLOはエラーバジェット以上に達成しないようにすることも大事だということが大事と書かれています。利用者はSLOより実際の印象を優先してしまうので、常にSLO以上の稼働に安心してこのシステムに密に依存した連携システムができてしまったりすると、実際にダウンした場合の対応が大変なので、むしろそういった場合は定期的にダウンさせて依存関係を明らかにする必要があるとも。
SLOあるあるとして、SLOを決めるぞと気合を入れてしまって大量の項目を設定しまって辛くなるなどがありますが、SLOは最小にとどめようねと書いてあったり、SLOと違ってSLAには関係部署含めたペナルティがあるのでSLAは採用しない、あるいはSLOよりも緩い値を採用しようなどといったノウハウも記載されています。
5章 トイルの撲滅
自分が少し自分用に翻訳した際は「苦痛」と翻訳した「トイル」ですが、SREの文脈での定義はサービスの稼働に直接関係ない以下のような仕事を指します。「手作業」「繰り返される」「自動化できる」「戦術的（≠戦略的）」「長期的な価値を持たない」「サービスの成長に対して正比例している」
50%ルールのサービスの運用業務とエンジニアを切り離す話と同じで、結局このトイルはキャリアを停滞させたりモラルを低下させるなどという点でSREチームにとって悪であり、そのためのエンジニアリングとしてソフトウェアエンジニアを主体として自動化を行っていくべきということです。
6章 分散システムのモニタリング
6章にはモニタリングとアラートに関する原則がまとめられています。アラートはよく考えずに設定すると1つの事象に対して大量に通知がきてしまったり、ほぼ同じ通知内容なのにこちらは対応が必要でこちらは無視をしてよいというような非常に非効率的なものになりがちですよね。ここでの原則はそういったことを避けて効果的に対応ができるようにするための原則であり、非常に役に立ちそうです。
また、6.11.1には、BigTableのパフォーマンスイシューで大量のアラートによって真の対策に着手できなかった担当チームがSLOのターゲットを引き下げ短期的なパフォーマンス改善に加えて長期的な対策を取れるようにしたというエピソードが掲載してあり、文脈はそれますが、こういった内部事情を誠実に紹介してくれるのは非常に誠実だなと思いました。
7章 Googleにおける自動化の進化
7章はみんなだいすき自動化の章です。第Ⅱ部でも特に重要な章でしょう。この章の前までですでにサービスの成長と運用作業量を切り離す意味での自動化の必要性については何度も出てきてますが、この章ではそもそもの自動化の価値と、Google SREにおける自動化に対する姿勢の進化についてなどが書かれています。
まず自動化の価値は、手動と違った品質担保・再現性という意味での「一貫性」、対象を複数に拡張可能な「プラットフォーム」という点、手動では間に合わないような障害リカバリ時間を達成する「高速な修復」、フェイルオーバーやトラフィックのスイッチングといったもはや自動化があたり前である「素早いアクション」、そして自分だけでなくそのコードで関係者全員が労力を削減できる「時間の節約」です。
そして、自動化のためにグルーコードを持たなければならないシステムよりも、そもそもそれを保つ必要がないシステム、つまりシステム自身が自動的された機能を内包している状態を指向するのが進化です。それはたとえばデータベースにおいてロケーション間でのフェイルオーバーが手動で行われる状態から、SREがスクリプトを実行する段階、誰もがそのスクリプトを実行できるようになっている段階、データベースにスクリプトが内包されている段階、データベース自身が問題を検出して自動的にフェールオーバーする段階まで進化させる経過をたどります。
そしてこの章ではいくつかの自動化の実例を掲載しています。
Google Adsでは2008年にMySQLのインスタンスをBorg(分散クラスタオペレーティングシステム)上にデプロイできるようにし、2009年にはDeciderという自動F/Oデーモンを利用することで95%のF/Oを30秒以内に完了できるようにして、なんと運用タスクに費やす時間を95%削減でき、ハードウェアの利用率を60%も改善できたとのことです。
インフラストラクチャSREチームのクラスタのターンアップタスクについては、上記の自動化の進化の示すとおりのよい例です。クラスタが増えるごとに人手が必要だった状態から、クラスタ作成時の設定検証ツールProdTestという内部ソリューションを利用することで、設定ミスを見つけ出すユニットテストを実行する段階から、設定ミスをテストしNGなら自動で修復し再度テストするという状態になり、サーバーのデーモンプログラムでそれが自動実行される段階まで進化したそうで、1日に1000以上の変更が入り、1年でサービスなどが2倍に増える環境でも破綻しないターンアップタスクが実現できたそうです。
8章 リリースエンジニアリング
これもエンジニアリングで自動化されることの多い領域ですが、インシデントの7割が変更管理プロセスによって引き起こされるので、自動化によりビルド・デプロイの一貫性を保つことは有益です。
この章では、すでに広く一般的になったセルフサービスでデプロイできる仕組みから、ビルドプロセス内で利用されているコンパイラなどのツールのライブラリバージョンまで履歴管理することでいつでも過去のバージョンがビルドできるようにする密封ビルド方式でチェリーピックの管理をしている話や、変更〜デプロイまでの継続的ビルドや継続的テストのワークフローはRapidというシステムで一元的にパイプライン管理されているそうです。
また、リリースエンジニアリングのためのリソースは、後から改善しなければなるのは大変なので、プラットフォームやサービスの初期段階から優れたプラクティスやプロセスを適用しておくほうがトータルでコスト節約になるそうです。
9章 単純さ
さて、第Ⅱ部の最後9章は、ソフトウェアを単純に保つことが、信頼性を持たせるための前提条件であるという原則について完結に示しています。
1章にもあったとおり、開発者が得たいアジリティは安定性という観点で見れば不安定さを供給する原因になるため、つまりSREのアプローチは「アジリティと安定性のバランスを取る」ことです。実際には開発者のアジリティを上げることでバグが生じても素早く修正が反映できることで信頼性が高まります。
そしてソフトウェアを単純に保つためには不要なソースコードを削除し、APIを小さく単純に保ち、機能のモジュラー性を上げ、リリースを単純に保つ必要があると述べています。単純がゆえに非常に強力な指針だと思います。
第Ⅲ部、第Ⅳ部について
第Ⅲ部実践では、Borgmonを使った実践的なアラートの設計(10章)から、トラブルシューティングのケーススタディ(12章)や、過負荷に対するスロットリングやエラー／リトライ対策(21章)、分散合意を実装するためのアーキテクチャパターン(23章)など、エンジニアとして非常に有益な情報がたくさん載っています。
また、第Ⅳ部管理では、SREというチームを運営していくうえで有益な心がけ(29章)やミーティングの運営方法(31章)や、新たにサービスを受け持つときに上手にオンボードするためのエンゲージメントモデル(32章)などが示されています。管理職の人などはこちらを読むだけでもだいぶたくさんの知見が得られるはずです。
ここらへんはもう少しじっくり呼んで感想上げたいのでまた別の機会に細かい章単位で色々参考文献とかも調べながらやりたいと思ってます。
最後に
ということで、原書もいいけど翻訳版は機微まで追えてさらに超オススメですという感じです。
目次
目次を読むだけでもどんなことが書かれているか分かるようになっているため、かなり長いですが最後に目次を載せておきます。
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 プロダクションミーティングの議事録の例
参考文献
訳者あとがき
索引
