tjinjin's blog

インフラ要素多めの個人メモ

SRE本を読んだ(簡略編)

About

この記事は 積読本 AdventCalendar の8日目です!

adventar.org

やっと消化したので軽くまとめます。

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

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

SREとは

定義が結構ぶれているかもしれないですが、SRE本を読んだりいろんなところで話を聞いたのを含めるとこんな感じの印象です。

  • 開発チームがサービスに集中できるような基盤を作る
  • サービスの信頼性向上に責任を持つ
  • サービス運用のスペシャリスト(スケールする仕組みを作っていく)

全般の感想

SREというとめっちゃ強いギーク集団みたいなイメージありましたが、本のところどころに垣間見える思いやりみたいのがすごく印象的でした。例えば28章のSREの教育の章では下記のような文言があります。

研修中の SRE は、以下のような疑問を抱くことでしょう。 ● 私は何の作業をしているのだろう? ● 私はどれだけ前進できているのだろう? ● オンコールを担当するのに十分な経験を積むには、この活動をどのくらい続けなければならないのだろう? それまでの会社や大学から飛び出して、仕事の役割を(従来のソフトウェアエンジニアやシステム管理者から)この漠然とした SRE という役割に変えることが、自信を打ち砕くのに十分であることは珍しくありません。性格が内省的であれば(特に 2番目と 3番目の質問に関係します)、漠然とした答えによって引き起こされる不安感は、進歩を遅くしたり、停滞させたりするという問題 につながることがあります(p.415)

上記のように人の性格や考え方にまで配慮したメンバー各人が力を発揮しやすい環境づくりをしっかりしている印象でした。自分が内向的な人間だと思っているので、成果が出にくい作業だとアウトプットできている感がなくてどうしようと思うことが多く、google最高かよと本を読みながら思いました。

またトイルの話がありますか、これが抑えることができたらどんなによいことか。。。せめてコンテキストスイッチを減らすようにはチームを促していかないと自分の作業が進まないのでなんとかしていきたいところ。

オンコールはこれまで業後時間帯のことを指しているかな?って思ってましたが、そうではなくて業務時間中にもオンコール当番がいるのかなー?と思いました。チーム全員がオンコール当番は効率悪いですよね。。。

技術的なところで言うと19章からのGoogleが大規模なトラフィックをどうしているかという話が面白かったです。22章のロードシェディングとグレースフルデグラデーションの話は、知らなかった話だったので勉強になりました。

他にもたくさん学びはあって説明しきれないのでぜひ読んでみて下さい。時間あればまとめてチーム内に共有とかしたいな。

まとめ

SREやっぱりかっこいいっすね。やっていきみがあります。SRE本はSREだけじゃなくて運用に関わるようなメンバーにも細かい技術的な話は除いて読んで欲しい本でした。