酩酊エンジニアの酔話

アウトプットを増やして思考実験をしてます。優しいまさかりは受け付けてます

SRE読書会をやってました

ちょっと時間があいてしまったが、今年の1月から7月にかけて、SREの読書会を行っていました。
注意)SRE自体がどうだったかというと話は特に書いてません!

詳細
DevOps@Lodge - connpass

なぜ読書会をしたのか

もうこの本が出てからするとだいぶ経ってしまって今更ですが、 SREとはGoogleから生まれてきた「Site Reliability Engineering」の略称で自社サイトの信頼性向上を目的としたエンジニアリングを行うこと。実際にここ数年の変化をみていると、webサイトを作るだけなら誰でもができてしまうし、それをサポートする形で言語もインフラとしてのクラウドも進化していると感じている。
そういう環境変化の中で、
- より早くより安定して、かつよりスケールするシステムをどう作って行ったらいいんだろうか?
- 自分たちが考えてるものが通じるのだろうか?
などの疑問を確認するために、この本を読もうと思いました。

また、正直この本は分厚くて一人で読んでいると理解するのも時間がかかるし、読みきれる自信がなかったので読書会を実施してみたものです。

どんな読書会をしていたのか

読書会を行う時に考えたのは、自分が無理しないことです。コミュニティとか運営するには結構な体力がいると思います。人が来なかったらどうするかなども含めて不安もあるのですが、まあ人がいなくなったら一人で読もうぐらいの気持ちではじめました。

読書会の個人的な分類

今回どんな読書会を実施したかのために、私の読書会を分類を出すと

読んでくるか集まって読む と 講義を聞くか議論するの組み合わせになると思う

  • 読んで来て、講義を聞く これは事前に読む範囲を決めておいて、その範囲を事前に担当を決めた人がまとめて紹介するなど輪読会的な読書会です。
    メリットは、事前に読んでくるので短時間かつ短期間で進めることができる。
    デメリットは、講義を聞くだけなので実際に読んでなくても良いので、本を読みきったという実感がなくても良い。 あと自分の担当の時に休みにくいという点もある

  • 読んで来て、議論する これも事前に読書してくるのは同じだが、議論として自分が感じた疑問や気になった点をお互いに話すことで理解を含めるものです。 メリットは、事前に読んでくるので毎回集まる時間は短時間でも十分に進めることができる。
    デメリットは、事前に読んで来ないと話が進まず、少人数で読書会を実施していると誰かが読んで来ないだけで開催が難しくなると思います。

  • 集まって読んで、講義を聞く これは事前に本を読むのではなく、集まってから決められた範囲を読み、そのあと講義を聞くものです。
    やり方は様々あり、担当決めておいてその人が講義をする場合や、詳しい人が解説する場合などもあると思う。
    メリットは集まって読むので、確実に参加すれば読むことができる。 デメリットは、詳しい人や講義できる人がいないとなかなか深い理解につながらない場合があるのと、集まってから読むので時間がかなり必要となる

  • 集まって読んで、議論する これも集まってから決められた範囲を読み、そのあとは講義ではなく議論をするものです。
    メリットは集まって読むので、どの回でも参加すれば何を話すのか理解する時間が取れる。
    デメリットは理解を深めるために議論が必要なのでファシリテーターが重要だったり、最低3人ぐらいいないと話に広がりがなくなると思う。

今回実施した方法

今回実施した方法は、「集まって読んで、議論する」方法でした。
毎回決めた1・2章を読んで、その場で感じた疑問や気になった事から話、実際の自分たちだったらどういうアプローチが出来るかを話しました。

  • 集合時間から60分間は自由に読書会を実施
  • 読み終わった人は、slackに読み終わった事を記述する
  • 全員読み終わったら最低30分間の枠で議論する

という方法をとりました。

やってどうだったのか

何とかSRE本のだいたいを読むことができたと思います。だいたいというのは、1部・2部・4部は読んだのですが、Googleが実践した3部については一部読んでないところがあります。読んでないのも自分たちが知っていても現状経験がなく議論が難しいスケールの話が出て来たので、その辺を除いた感じです。
SRE自体を理解したいのであれば、特に2部を読めばいいと思いますし、4部を合わせて読むとどうやってそれを広げるかがわかると思います。

運営自体で苦労したのは場所取りです。今回はYahooのLodgeを予約して使いましたが、こういう読書会をするにはある程度のスペースがあり、ホワイトボードがある場所を定常的に借りれると楽でいいなと思いました。(夜中に予約するの大変ですよね)

lodge.yahoo.co.jp

ただ実際にこういう読書会を運営してみて思ったのは、確実に一人で読むよりも途中で諦めることはないと思いました。仲間がいることで、取り組み方が変わりますし継続しやすくなるものだと思います。また、こういう重い本だと自分だけの視点だと理解できないものや、現状どうなってるのかわからないものも多くあるので、チームや同じ会社の人と集まって実施すると、良い気づきが得られると思います。

今後も何か同じ課題を持ってる人がいたら、集まって読書会やハンズオンのあるようなものは続けていければと考えてます。

読んだ感想

SRE自体がどうだったかというと、「エラーバジェット」「トイル」「SLO」など真似してみたい考えなどはあるが、これを今の自分が実践するためには足りてないものとしてメトリクスをどう取るかだという理解をしました。
手段はなんでも良いのだけど、自分たちの現状を客観的に理解できる可視化がないと、そもそもこういう活動を取り組むことは難しく、また必要性を話すことは難しいものだと思います。何がボトルネックになるのか、例えば新機能を出す時には企画決定のための不要な議論の時間かもしれないし、セキュリティ対応かもしれないのだけども、そういうことも含めてサービスのパフォーマンスをユーザ視点で計測したり、提供してるサービスのSLOとして計測したりができていないと、不満はあれど改善活動ができないのは変わらないなと感じたものだったので、まずはどうやって自分達のチームの状態やプロダクトの状態を計測するのか試したいと思ったものでした。


最近は社内ではあるが、この辺の読書会を実施しています。

また、個人的にはこの辺読んでます。

どこかで、この辺読んで思ったことまとめたいなと考えてる次第です。