SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
- オライリージャパン (2017年8月12日発売)
- Amazon.co.jp ・本 (590ページ)
- / ISBN・EAN: 9784873117911
作品紹介・あらすじ
大規模なサイトを運用・構築していくための手法「SRE」について詳述!
Google社内で発展した、大規模なサイトを運用・構築していくための手法「サイト リライアビリティ エンジニアリング」について、様々な場面での実践的なストーリーを紹介します。
感想・レビュー・書評
-
濃い。分厚い。サービス運用という側面でここまで網羅的にまとめた本ってこれまでなかったんではなかろうか。内容的には、従来のいわゆる「運用」とも異なるわけではあるが。全部が全部でなくていいので、取り入れられるところから実践してみたい。
詳細をみるコメント0件をすべて表示 -
SREをやるなら一度は読んでおくべき。ただし重厚長大なので、すべて覚えるというよりはプラクティスとして頭の片隅に入れておくレベルに抑えておき、実践していく中でリファレンスするのが良いと思う。
-
内容が網羅的で用語の解説も丁寧なので、SRE について知りたいと思った時に読む本としておすすめできる。
本書は 34 の章から構成されていて、さらに 5 つの部でまとめられている。
第Ⅰ部 イントロダクション 1章 ~ 2章
第Ⅱ部 原則 3章 ~ 9章
第Ⅲ部 実践 10章 ~ 27章
第Ⅳ部 管理 28章 ~ 32章
第Ⅴ部 まとめ 33章 ~ 34章
第Ⅱ部 原則 ではトイル、サービスレベル目標など、他の書籍でも SRE に関連して紹介される考え方についての詳しい説明があったり、モニタリングや自動化、コードの単純さなどについて書かれている。この部では技術的に込み入った内容の記述は少なく、概要を知るのに適している。
サービスレベル目標は『SLO サービスレベル目標』にも書かれているが、概要を掴むのであれば本書籍でも十分だと感じた。
第Ⅲ部 実践 では、ロードバランシングに関する章では分散合意アルゴリズムや異なる環境におけるロードバランシングについてなど技術的な内容が書かれていたり、モニタリングシステムである Borgmon やポストモーテム、ローンチチェックリストなど様々な取り組みについて紹介されている。
ポストモーテムはテンプレートも掲載されていて、参考になる。分散合意アルゴリズムについては『データ指向アプリケーションデザイン』に詳しく書かれていて、併せて参照すると役に立つ。
第Ⅳ部 管理 と 第Ⅴ部 まとめ には組織的な話や運用観点の話が書かれている。
全体を通じて情報量と詳細な説明のバランスが取れていて、すぐには導入できない技術的な箇所はあるにせよ、文化的だったり組織の仕組み的な部分は短期的にも参考になる記述があり、とてもいい本だった。 -
ようやく読み終えました。
社内への技術支援に携わる身としては、読んでおいてよかった、かつ、全体的に復習もしておきたい良書でした。 -
SREについて詳しく書かれた本
他のSRE系の本や記事は、この本を読んでいることを前提に話が進んでいく
そのため、SREという分野で特に重宝されている -
SREの考え方から実際にGoogle SREの実践事例が書かれている。
翻訳の問題かもしれないが、章ごとに著者が異なるためか、内容のわかりやすさに差があるように感じた。
とはいえまずはこれを読んでSREの概念や役割、責任などを理解した上で業務導入を進めるのがよいと思われる。 -
GoogleのSREがSREとは何かを説明している本。SLA/SLO、モニタリング、パフォーマンスチューニング、分散システム、自動化、リリース、ページ・オンコール対応、ポストモーテム、負荷分散、カスケード障害、パイプライン、バッチ処理、データの完全性、コミュニケーションなど幅広い領域におけるGoogleの努力が綴られている。一部、具体的すぎるツール名などが出てきて、全容を把握していない読者には想像するしかないような内容もあるが、基本的には広範に適用可能な原則について書かれている。それらは、記録・ロギング・モニタリングなどを行いデータを取得する、データに基づいて意思決定する、意思決定のルールは体系化する、失敗を記録する、事前に予防可能なことは予防する、自動化する、段階的なリリース・ロールアウトのやり方、安定性と変更容易性のトレードオフ(エラーバジェットをどう使うか)の扱いといった広範に及ぶが哲学は「いかに小さい労力で、安定していて高速な開発を行える環境を作るか」と一貫している。日曜日に読んで翌日からすぐに役に立つような本ではないが、システムに対する向き合い方を考えさせられる良い本だと思う。
-
『#SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム』
ほぼ日書評 Day441
「ソフトウェアシステムが完全に安定するのは、捨て去られた時だけです。コードベースの変更をしなければ、バグを生じさせることもなくなります(…)ユーザベースを現在の状態で固定できるのであれば、システムをスケールさせる必要もありません」
本書中盤にあるこの一節が示すように、システム(ITに限らず、すべての「仕組み化」されたもの)はフェイルし、人もまた必ず間違いを起こす。その前提で、如何に信頼性(リライアビリティ)を上げるかを解く。
具体的には
・目標設定
・都度作業の削減と自動化
・単純化、モジュール化
・本番移行とモニタリング、警告発信
・緊急対応、ドリル
・障害対応の優先付け 等々
大型本かつ500頁に上る大著のため、評者自身かなりの斜め読みだが、さらにITに馴染みのない方でも、章立てと各章の「まとめ」を読むだけでも、趣旨とするところは十分に理解できる優れた構成。
https://amzn.to/3wAcXDZ -
手元に置いてリファレンスとして読み返す価値のある本(付録も実践に使えそうなほど充実している)
これを読むまでSREを履き違えていた。
クラウドインフラのベストプラクティスくらいに捉えていたが、システムの信頼性に対する思想や原則と広義に捉えるべきだと認識。
以下メモ
・過度の信頼性はコストに跳ね返る
・自動化のメリットは設計時間を確保でき、標準的な優れた役立つプラクティスを導入できること
・優先度の低いアラートは疲弊を招き、重大なアラートに注意を払えなくなる(出力調整が大事)
・人は修正できないが仕組みを修正して人が正しい選択をすることを支援することは可能
・SLOの定義はユーザ観点で
・エラーバジェットにより開発への力の入れ方をコントロール
-
SRE実践本。
SREの視点に限らずGoogleが体験した様々なケーススタディを見事に落とし込んでいる。
これからSREを始める人も前作を読んで、何からはじめればいいのか?が見えてくる一冊。
すでに実践していれば該当するシチュエーションにたくさん遭遇するだろう。 -
2年越くらいに読み終わった。
自分はSREという立場ではないけど役に立つ知見がいくつかあった。書かれている内容が結構バラバラなので、目的意識を持って読みたい部分だけつまみ食いする読み方がよさそう。
SREというロールは「技術面での最強のなんでも屋」みたいな印象。 -
SERという考え方。よいと思う。次世代のスタンス。よい文化を作っていこう
-
サイトリライアビリティエンジニアリング(SRE)
グーグルの信頼性を支えるエンジニアリングチーム -
請求記号 007.61/B 39
-
"SRE" というワードのバイブルとなる本。
単に信頼性を保つシステムという側面だけを薄く紹介しているのではなく、SREに関するあらゆる要素(システム・原則・組織など)が網羅的に紹介されているので、とにかく情報量が多いです。
全くシステムに関わったことのない初学者よりは、システム開発や運用にある程度関わった経験のある人が読むと、自分の立場と照らし合わせて見ることができるのでより理解が進むと思います。ただ、それだけ考えさせられる内容が多いので、読むのはとても大変だと思います。
システム開発と運用に関わるあらゆる人が読むべき本だと思います。個人で読んで納得するより、これを複数人で読んで理解を共有し、真の仲間となってプロダクトに関わっていくと良いのかなと思いました。 -
SRE のための指南書
自分にとってバイブルとなる一冊になった。
非常に幅広い情報が網羅されていて、飽きなかった。
SRE は1日にしてならず、 Google SRE が積み重ねてきた日々を感じることができた。 -
かなりのページ数で内容的にも重厚、
だが開発者、運用者、企画者問わずITに関わる人間にはぜひ通読することを薦める。
ものすごくかいつまんでいうと、エンジニアリングによって可用性を高めようという話だが
それを実現するためにはエンジニアリング以外の側面、すなわち文化の醸成などが必要になる。また、エンジニア自身が発生したオンコールさえも明日への資産と考えるマインドチェンジも必須。
そういったことを伝えるためにはこの分厚さが必要だったんだろう。 -
勤務先で(ほぼ)毎週読書会を開き、半年ほどかけて読了。複数人集まってワイワイ議論していたので、1人でもくもくと読む以上に内容への理解が深まったと思う。
全部をエイヤッと始めることはムリだけど、メトリクスの収集・可視化やSLO, SLI, SLA の設定、ポストモーテムなど真似できるところから真似していこう。 -
すさまじくカバー範囲が広い
・クラスタ管理システム (Borg)
・サービスレベル策定
・モニタリング
・時系列データベース
・ビルド/デプロイ/リリース
・テスト
・リファクタリング
・ディサスタリカバリ
・ジョブのスケジュール (cron)
etc.
以前Kubernetesを触ってみて、あまりに複雑で、一体どんなシステムの運用に使うんだと思っていた。
この本の内容を読んで、Kubernetes(Borg)が必要とされるシナリオが少し理解できた。
それでもまだ一般エンジニアには早すぎる。