こんにちは！技術部プラットフォームグループの @r_nakamine , @h0mirun_deux, @ryuichi_1208 です。 今回は、社内で取り組んだ SREの探求 の読書会について紹介したいと思います。
読書会を始めた経緯
私たちが所属している技術部プラットフォームグループ(以下PFG)では「ソフトウェアを用いたサービスの運用効率化」や「SLOに基づいたパフォーマンス改善」といったSREに関連する業務を行っています。さらに詳しい話は先日開催された SRE Gaps#2「SREの実践」 にて発表された資料がありますのでご参照ください
PFGでは過去にオライリー社から出版されている SRE サイトリライアビリティエンジニアリング と サイトリライアビリティワークブック の読書会を開催していました。しかしそれらの2冊で語られた多くはGoogleのような大規模での開発や運用にまつわるプラクティスが多く自分たちには当てはまらない内容も少なくありませんでした。自分たちと似た境遇の規模でのSREの実践について学びたいと考え SREの探求 の読書会を開催しました。
読書会の進め方
前回の Kubernetes完全ガイドのときの読書会 の進め方と同様に以下の方法で進めました。
- 週1回のペースで1時間オンラインで開催
- 週替わりでファシリテーターを決める
- 毎回2~3章くらいを全メンバーで読みつつファシリテーターが当日は要約を読み上げる
- 読む章の数は次回のファシリテーターが決定し事前に通知をする
- 会で出たコメントなどはNotionにまとめる
読書会のNotionページ
SREの探求は章ごとに内容が独立しておりタイトルや内容を読んで自分たちの今の境遇に合う点が多い章を選抜して読む章を絞ったり、ファシリテーターの休暇や業務都合での欠席などで議論する章を前後できると行ったメリットがありました。
印象に残った章
gurasan
一番印象に残った章は30章の「オンコール反対論」です。この章は開幕から「私たちにはよく分かっているように、オンコールは終わりにしなければなりません」と力強い言葉から始まっておりオンコール自体の再評価の必要性を説いている。
オンコールに対するアプローチとして「強いオンコール反対」と「弱いオンコール反対」という言葉を用いて説明されている。前者は「障害に強いシステムを構築する」、後者はオンコールの対応へ人手は必要とするが、ソフトウェアでフェールセーフを実現する方法。それぞれ自分たちが抱えている課題でどう適用すると良いだろうと考えるきっかけとなりました。
naryo
4章の「インシデントメトリクスを用いたSREの大規模な改善」について、インシデントに関わるさまざまなメトリクスから virtuous cycle モデル (バグが混入してから修正が世界中にロールアウトされるまでの時間をサイクルのKPIとするモデル) を用いて信頼性を向上させる取り組みが非常に参考になりました。
中でもインシデントのバグの改善の機会（修復アイテム）をログとして継続的に記録し、それらを修復負債として扱って改善に取り組んでいくプロセスや、修復負債が安定しているのにもかかわらず信頼性が向上しない場合には、修復アイテムが欠落している（サービス改善の機会を失っている）とみなし、それに対するアプローチの仕方など、あらゆるものを計測して次に取るべき適切なアクションを見いだす手法がとても印象に残りました。
homirun
自分は9章の「25ページでシステム管理者からSREへ」が特に印象に残りました。この章はSREの定義やSREで用いられる用語の意味、従来のシステム管理者とSREの違いについて書かれていました。
「SRE サイトリライアビリティエンジニアリング」の読書会は入社前に行われていたということで読んでいなかったこともあり、自分の中であやふやだったものがしっかりとどういうものか理解できました。
また、冒頭にかかれていた「計測できないものは改善できない。」という言葉はデータ駆動を重要視しなければならないという観点でとても共感することができました。
読書会を通して新たに実践した取り組み
SREチームと開発チームが密接に関わり、ソフトウェアエンジニアリングを用いて信頼性の問題に取り組むアプローチがより加速するようになりました。
中でも、もともと主にアプリケーションが動作するプラットフォームのレイヤーを守備範囲としていたSREチームもアプリケーションに手を加えてパフォーマンスの向上に取り組んだり、逆に開発チーム側でも信頼性の向上に向けたSREの取り組みに対して積極的に関心を示すようになりました。さらに、SLI・SLOに対してチーム内で共通の認識が生まれたことにより、これらの値を今まで以上に意識した上で改善活動を実施することができました。
また、参加メンバーが読書会を通して学んだことを生かしたアウトプットも生まれました。
- 「Pepabo Tech Talk -入社1年以内のメンバーが語る、ペパボのSREチームの取り組み-」開催レポート
- アクセス数に連動してDNSの重み付けを自動制御する仕組みをAWSで作った話
- 「オンコール対応するエンジニアの睡眠時間を確保せよ」GMOペパボSREチームの6つの取り組み
参加メンバーの感想
読書会に参加したメンバーの感想を紹介します。
gurasan
他社のSREの実践事例をまとめて読むのは今回が初めてで普段自分たちがやっている内容が論理的に説明されている章があったりで面白かったです。今回の読書会で得た知見を元に実際の業務でも活かしてその結果をアウトプットできればよいなと思いました。
homirun
SREとして今まであやふやだった点の理解が深まりました。現在の自分たちと本の中で紹介されている各ケースの比較、ディスカッションができたのが特に良かったと感じています。ページ数が多く一人で読むには大変だったので、分担して読めたのが助かりました。
masaki
個人で読んでいた場合には拾い切れなかったであろうポイントが章ごとのディスカッションで理解が深まった点が良かった。資料作成には毎回頭を悩ませたが学びに繋げられたものと思いたい。
naryo
他社の事例と自分たちの取り組みを照らし合わせながら、課題を再認識できたり、また新たな発見があったりとで非常に学びが多く、これからSREを実践していく上でさらに視野が広がりました！一人で読み切るのは大変だと思ったのですが、読書会という形式でそれぞれの章についてSREに関わるチームのメンバーでディスカッションしながら進めていけたので、理解度が深まりとても良かったです。
ressy
独力で読むのは大変なボリュームだったので勉強会のおかげで読み切ることができました。また章ごとにディスカッションすることで新しい気づきを得られ、理解を深めることができました。 各社でのSREの導入事例を通じてSREの文化を醸成するまでの過程でやるべきことを知ることができました。
shibatch
この本はわりと読書会向きの本だと思います。技術者の立場だけでなく、マネージャーの立場から書かれていたり、内容もタスク管理、組織論、珍しいところだと心身の健康についても描かれています。このような複数の軸がある内容をまたチームでディスカッションすることで立体的な視野を得ることができたと感じます。
私個人は技術者の立場から、自分の仕事をなくして時間をつくるために、他の人が自分のタスクをできるようにセルフサービス化させる内容はなるほどと思いましたし、アンチパターンの章ではこれはできている、できていないといった話をわいわいできたのは楽しかったです。
また、各自担当章をnotionにまとめ、気づいた点を読書会の中でみんなでコメントしていくやり方は非常にワークしたと思います。後から見返すこともでき、気づきがありました。
sugy
SRE についてさまざまな視点で書かれており視野が広がりました。月並みな感想ではありますが、１人で読んでいたらⅡ〜Ⅲ部あたりで息切れしていそうなボリュームなので、読書会を通して参加メンバーの意見も聞きつつ内容が把握できてよかったです。SRE と一口に言っても、組織の規模や風土によってさまざまな形があることが分かったので、私たちの組織に合いそうなものを取り入れて実践できればと思います。
tora
章のまとめは担当せず耳とコメントで参加させていただきました。 冒頭で書かれているように本書はさまざまな企業や組織で SRE を導入した体験や経験が語られており、本書で取り上げられている SRE のふるまいと現状の差分を発見できて襟を正される思いでした。 組織/チームとして取り組む SRE という分野だからこそ、読書会の意味がありました。改めまして、会の開催ありがとうございます！
まとめ
今回の読書会は「NO SRE NO LIFE」というテーマを持って取り組んできました。SREの探求では多くの企業の事例がまとまっておりSREに関する実践例を学びSREの必要性などを再認識することができました。今後も読書会で得た知見を元にSREを実践していきバリューを出していきたいと思います。