Googleの大規模な著者チームが執筆した「 サイト信頼性工学 」という本に興味があるだけではありません。 それだけでなく、彼女はAmazonのさまざまな評価の第一線を占め続けています。 最も興味深いのは、あらゆる複雑なシステムの完璧な運用に関する、真にアクセス可能な包括的な情報を提供することです。
さらに、将来的には、DevOps方法論に関するより一般的なレビューブックに興味があります。
モニターのトカゲと雄牛が完璧なペアを作ると実質的に確信しているので、読者がSREとDevOpsに興味を持たれることを期待しています。 本サイト信頼性工学のやや短縮されたレビューを研究することをお勧めします。 この記事の著者であるマイク・ダウアーティは、この本の共著者の一人であり、部分的にそれを読んでいます。
Googleは約2年間、サイト信頼性エンジニアリングの書籍に取り組んできました。 これは、Googleがすべての巨大なシステムのスムーズでスムーズな運用を保証する特別な規律とワークフローの組織です。 この本はオリジナルでリリースされたばかりです。 そのボリュームは500ページ以上あり、そのページにはGoogleの仕組みが詳しく説明されています。 著者は非常に率直に書き、プロジェクトとシステムの名前を隠さないで、これらのシステムがどのように機能するかを説明します。 はい、ソースコードはページにありませんが、Googleだけでなく便利な多くのトリックを使用できます。 この本は、大企業を成長させたいスタートアップの従業員や、サービスの信頼性を高めたい中小テクノロジー企業の従業員にとって非常に興味深いものになるでしょう。
私はGoogleでSREエンジニアとして働いており、非技術分野でSREの原則をどのように適用できるかを説明する第33章の小さな断片の執筆に参加したことをすぐに認めます。
もちろん、この本は私にアメリカを明らかにしませんでした、なぜなら私はそれが生まれた腸のまさにその組織で働いていたからです。 しかし、Googleが他の技術コミュニティに伝えようとしていることに興味があります。 Googleは、SREとは何かを明確に説明しようとしてきました。 この専門分野でGoogleに就職したとき、この種の不確実性が私を困惑させました。 しかし、Googleは巨大システムの操作に非常に優れており、SREは、同様のパフォーマンスを提供するテクノロジーカルチャーを作成することを可能にした一連のプラクティスと方法です。
お急ぎください。BorgやChubbyのようなシステムを持っていなくても、GoogleのSREエンジニアが行う多くのことができます。 この本には、そのような作品を適切に構築する方法、何をすべきか、何をすべきでないかに関する多くの実用的なヒントが含まれています（ちなみに、この本は、ミスをどれだけ適切に検討しているかに驚かされます）。
私の知る限り、この本で言及されているすべての技術はすでにオープンソースに登場しています。 近年、パイパー、ボルグ、マグレブなどに関する記事や講義が登場しているので、著者もそれらについて自由に話しています。 特定の技術はケーススタディの資料として興味深いものですが、最も興味深いのは個々の製品やシステム自体ではなく、SREの原則に従ってGoogleがこれらのプロジェクトを実装した方法に関する情報です。 したがって、これは特定のシステムに関するものではなく、SREに関する本です。 この本のほとんどの資料は、既製のシステムではなく、読者が使用できる原則と実践に当てられています。 確かに、これらの原則と実践は個々にうまく機能するのではなく、単一の一貫した全体として機能します。 幸いなことに、この本にはさまざまな読者への優れたアドバイスが含まれているため、このレビューの最後の部分で対象読者について詳しく説明します。
概要
本は5つの部分に分かれています：はじめに、原則、実践（最もボリュームのあるセクション、本のボリュームの約60％を占める）、管理と結論。 読者にとって特に興味深いまたは価値があると思われる個々の章について簡単に説明したいと思います。 この部分に興味がない場合は、スキップして「A Little Reflection」セクションに進んでください。ここでは、SREに関する本が特定の読者にとってどのように役立つかを説明します。
「はじめに」を読むことは重要です。これは、それ以降のすべてのトピックのディスカッションのコンテキストを設定するため、スキップしないことを強くお勧めします。 最初の章では、SREとは何か、SRE、システム管理、DevOpsの違いについて説明します。 2番目の章では、Borgからデータウェアハウス、ネットワーク、開発環境まで、Googleの作業環境の構築方法について概説します。
原則セクションは、第1章の資料に基づいており、リスク管理のトピックから始まります。 この資料は、SREシステムの強度と復元力を理解するために重要です。 100％の安定性が必要な場合、開発者が何も変更できないようにします。 しかし、それはビジネスを殺します。 現実には、自分自身が取るリスクのレベルを管理し、できる限り迅速に取り組むことを学びます。 同時に、故障は除外されません。主なことは、故障が修理予算に収まることです。
引き続き第6章と第10章で、Googleがその巨大なシステムの動作を監視する方法と、発生した問題に関するアラートを受信する方法について詳しく説明します（これは「間違った」という用語の意味も説明します）。 おそらく、監視の問題は、追跡する必要のあるシステムそのもののインストールと同じくらい複雑であり、この問題の解決策は（システム）プログラマーの技術です。
第7章では、SREにおける自動化の重要性について説明します。 私たちのシステムと同じ大きさのシステムでは、自動化の価値を過大評価することはできませんが、Googleの成長に伴い、自動化をはるかに超える機能を持つ新しいシステムの作成に努めています。 このようにして初めて、現在の最大規模のシステムと将来登場するシステムの運用に対処できることを期待できます。
SREの最も重要な側面の1つは、関連する文化です。 このトピックは本書全体で時々触れられますが、この文脈では「解剖学の文化」が最も重要です。 第15章では、それが何であるか、なぜ解剖学に欠陥がないのかを説明します。
第17章では、信頼性テストについて説明します。 これは、私の期待を裏切った数少ない章の1つです。 ストレステストや「ベルとホイッスル」などの重要なトピックを扱っていますが、これらのトピックについては詳しく説明していません。 著者は単に詳細を調べたくなかったかもしれませんし、資料を減らす必要があったかもしれません（もしそうなら、私はむしろ他の断片を減らしたほうがいいでしょう）が、とにかく、堆積物は残りました。
4つの章が続き、Googleがさまざまなレベルで負荷分散を整理する方法（19章と20章）、輻輳を処理し、連鎖障害を回避する方法（21章と22章）を説明します。 これらのトピックはすべて非常に相互に関連しており、確実にそれらに専念する60ページに値します。 標準のサーバーおよびクライアントバックプレッシャーの実装、バランスの取れたカルーセルロードバランシング、部分的なデータベースバックアップ（サブセット）、リクエストの優先度と重要度、ロードセグメンテーション、リクエストのコストなどがあります。 これらのメカニズムはすべて、過負荷とカスケード障害を回避するために重要です。したがって、自分の間違いから学ぶよりも、そのような本からそれらを解析する方が適切です。
次の2つの章23と24では、分散一貫性システムと、そのような調整に基づいて動作する分散Google cronサービスであるBorgcronについて説明します。 分散cronを使用するのは見た目よりも難しいため、読者は単一マシンからどのcronをBorgcronに変換するかを構築する際に、複数レベルの構造についての有益なツアーを見ることができます。
パート4では、SREチームの管理について説明します。 この資料は本の技術的な部分ほど興味深いものではなかったため、すぐに第32章「開発中のサービスの開発：フレームワークとSREプラットフォーム」に目を向けます。 プラットフォームを標準化するためのこのような作業は、SRE、したがってGoogleのシステムを拡大するために重要であると考えています。
第5部では、他の業界でどのように高い信頼性が達成されているかを説明します。 出版前にレビューを依頼されたのはこの章でした。 本がどれだけ充実しているかはわかりませんが、さまざまなシステムの信頼性を確保するための一般的な機能を追跡することは重要です。これにより、著者はGoogle SREが正しい方向に開発していることを証明します。
反射
それで、本の最も重要な部分の簡単な概要の後、それが特に価値がある理由についてお話したいと思います。 たぶん、Googleは自慢しているのでしょうか、それとも読者はまだこの本から何かを取っているのでしょうか？ この本で説明されているテクニックは、中小企業の従業員にとって有用でしょうか？ そうだと思います。 ここには、オープンソースプロジェクトを実施するため、Googleのような成熟したSREシステムがまだない中小企業や大企業で働くための多くの実践的なアドバイスがあります。
本で説明されている開発およびテスト手法の多くは、無料のプロジェクトで簡単に実装できます。 システムはフィードバックを念頭に置いて設計し、洗練された劣化、透過的な監視、広範なテスト、単体テストなどに限定する必要はありません。
このような本は、典型的なシステム管理者である少数のエンジニアだけがシステムの運用を担当している小企業でどのように役立つのでしょうか？ まず、別のパスが表示される場合があります。 これらすべての可能性を実現することではなく、私にはそのような不可能な仕事のようです。 しかし、原則そのものを学ぶことは重要です。 これらの従業員が不足している可能性のあるプログラムの要素を追加し始めるように、システム管理者の雇用とトレーニングを変更する必要があります。 システム管理者は、エラーを完全に解剖し、システムがクラッシュした場合に機能しない可能性のあるアクティブな要素をすべて修正する必要があります。 バグを修正する予算が尽き始めたら、リリースシーケンスを遅くする必要があります。 特に、第30章「運用上の過負荷を円滑にするためにSREを採用しています」に注意してください。 第1章と第28章も参照してください。
大企業では、十分な才能のあるエンジニアがいますが、SREプロセスが適切に編成されていない場合、本はさまざまな方法で役立ちます。 それはすべて、あなたの意見では、組織がエンジニアリングの観点から到達していないものに依存します。 たぶん、あなたはまだ特別な運用部門を持っているかもしれませんし、すでにDevOpsをやっているかもしれませんが、組織のエンジニアリング構造を変更する必要があるときがいつか来るかもしれません。 輻輳やカスケード障害に対処するための標準がないと仮定します。そして、そのようなインフラストラクチャを作成できる開発サイクルの作成に投資します。 負荷分散に問題がある場合は、Googleでどのように行われるかをお読みください。
最後に、本は非常に簡単に読めることを言及しなければなりません。
この本は、DevOpsのすべての専門家、サポート、信頼性、および大規模なソフトウェアプロジェクトの開発に強くお勧めします。 この本は、Googleの裏側を見るのに役立ちます。Google自体は高価ではありませんが、Googleの専門家からの文字通りの直接的なアドバイスも含まれています。 私を信じて、そこに提示されているすべてのアイデアは絶対に実現可能です。