blogレシピ動画サービス「kurashiru」を運営するdelyのテックブログ2019-09-25SREはじめましたTweetこんにちは、6月にサーバーサイドチームからSREチームに異動した高山です。私がSREチームにジョインすることとなり、SREのチームメンバーが増えることをきっかけに、現状のSREチームを見直すという取り組みを行っています。弊社の開発組織にはもともとSREという職種が存在しています。実態としては、ソフトウェアも書けるインフラエンジニアがSREという名で活動しているというだけで、「一般的なインフラエンジニアの責務+困った時に頼られるなんでも屋」という曖昧なものでした。その結果、SREチームが実際には何をすべきチームなのか他のチームに正しい認識をしてもらえていないメンバーによって認識しているSREとしての責務境界がバラバラ降ってくるタスクが多すぎて足元解決型のチーム優先順位が定まらず本来SREチームがやるべきことに着手できていない(のでは)という状況になっていました。これでは、SREチームの役割や責務範囲が属人的になり、本来のSREが発揮するべきバリューがチームとして効率よく発揮できないという問題が発生してしまいます。今後さまざまなバックグラウンドを持つメンバーが増えていくにあたり、さらに責務範囲の属人化が進むことが懸念されました。そこで、SREチームとしてのミッションや役割、優先順位を明文化することで本来のSREチームとしてのバリューを発揮できるようにチームを見直す取り組みをはじめました。してあげた通り、弊社のSREチームは本来のSREチームに対する理解がチームメンバーによって様々でした。(ここでいう本来のSREチームとは、Googleが提唱しているSREチームのこと)そもそもSREチームとは、「どのような問題を解決するために」「なにを目的として生まれたチームなのか」ということを全員が理解できていないと、足並みの揃わない、目的がブレたチームを発足することになります。ミッションや役割、優先順位を決めて執行したとしても、全員がその内容を理解できていないと本来時間を費やすべきでないことに時間を費やしたり、正確な意思決定ができなくなったり、納得感のないままミッションを遂行することになってしまうかもしれません。そこで、SREチーム見直しの第一歩として本来のSREチームを知るべく、SRE本の輪読会を開催することにしました。www.oreilly.co.jp輪読会のやり方は以下のような方法で進めました。共有内容と議論したい内容に基づいて議論する(50分)輪読会をやってみてわかったことは、SRE本から得られる学びがとても多い輪読会の効果がすさまじいということです。SRE本に書いてあること自体、とても勉強になります。今まで感覚的に「こうあるべき」と思っていたことが、実はそうでもなく、無駄なことに時間や神経をすり減らしていたと気付かされたり、逆に感覚的にこうだと思っていたことがきちんと明文化されて解決策が提示されていたりします。SREという職種は会社ごとに役割にバリエーションがあったり、ふわっとしがちというイメージがありましたが、SRE本を読んでその責任範囲にかなり明確な定義があるということがわかりました。輪読会のすばらしい効果を実感しました。そもそも誰かに読まれることを前提にまとめを作成することで、一人で読むのと比べて理解度が上がりました。メンバーの半分はSRE本をあらかじめ読んだことがあり、理解度の違うメンバー同士で議論することで、新しく読んだメンバーは効率よく理解が深まり、すでに読んでいるメンバーは認識が違っていた箇所や理解が曖昧だった箇所を潰すことでチームで認識を揃えることができました。ミッションの決定SRE本には、私たちのような少人数のチームでは真似できなかったり、サービスの特徴によって起こるGoogleならではの問題に対するアプローチや取り組みも含まれています。それゆえ、そのままGoogleのSREチームの概念を自分たちに投影して運用を試みても、無駄があったり、そもそも真似できない部分があります。自分たちが抱えている問題とGoogleが抱えている問題をきちんと切り分けて考え、自分たちに必要なルールを取捨選択したり、形を変えて自分たちのルールに落とし込んでいく必要があります。そこで、弊社のSREチームでは共通の認識によって必要なルールを選定する意思決定ができるように、ミッションの策定を行いました。こちらが決定したミッションです。(SRE輪読会)現状のタスクの洗い出し他社のSREチームミッションの事例を集めて共通点や違いを分析まずは、最低限SRE本の1章を理解してミッションを決定するのがいいと思います。SRE本の中にも出てきますが、1章がSREチームの役割を理解するために一番大事な章となっています。全てを読んで理解するのは時間がかかるので、まずはこの1章を最低限全員が理解した段階でミッションの決定を行いました。次に、現状のタスクの洗い出しをして、SREチームがどのような責務を持っているかを明確にし、ミッションを決める際の参考にしました。最後に、他社のSREチームのミッションの事例を集めて、SREチームが生まれた背景の分析や弊社のチームとの共通点の分析を行いました。この時点でミッションはあとから柔軟に変化させていくという方針で決定しました。ミッションは最初に最適なものをピンポイントに決めるということはとても難しいです。あとから形を変えることができるので、悩みすぎずにこれと決めて事業ニーズの変化や次にお話しする役割のスコープ決定などに合わせて都度話し合っていくことが重要かと思います。取り組みの3つめとして、SREチームの役割のスコープを決定しました。こちらが弊社のSREチームが現状考えている役割のスコープです。素早く安全な変更管理モニタリング緊急対応キャパシティプランニングセキュリティスコープの決定で行なったことスコープを決定するにあたって、下記の手順を踏みました。決定したスコープがミッションに沿ったものになっているかを見直すまずは、SRE本の第1章に登場する「SREの信条」として出てくるスコープと現状のSREチームのタスクをマッピングしました。現状のタスクがSRE本で挙げられているSREの責任範囲にマッピングできないものは、弊社のSREチームが過度に持っている責務として分類しました。それぞれのスコープが弊社のSREチームに必要かどうかを議論しました。ここでは、SRE本で挙げられていたスコープになにかしらのタスクが当てはまる結果となり、どのスコープも必要であるという結論になりました。次に、GoogleのSREの責務からはみ出した責務をSREチームが担うべきか議論を行いました。前述したように、Googleと弊社ではチーム構成も人数も違います。SRE本に列挙されている責務のスコープにはセキュリティがありません。GoogleにはSREチームとは別にセキュリティのスペシャリストチームがいる可能性が高いです。弊社は、セキュリティチームがないのでその責務をSREチームが兼任する必要がある、といったように、GoogleのSREチームの責務に加えて持たなければならない責務についても議論しました。最後に、最終的に決まったスコープが、SREチームのミッションに沿ったものであるかどうかを確認しました。必要なスコープがチームのミッションに即していない場合は、スコープを見直すか、チームミッションを見直す必要があります。このスコープを決定することで、一気に弊社のSREチームの役割が明確になってきました。SRE本でわかりやすくスコープを切ってくれているため、スムーズに役割のスコープを決定することができました。これからやっていきたいことSREチームの役割のスコープを細かいアクションに落とし込むアクションごとの優先順位を決める他チームへのSREチームのミッションや役割の共有まとめSRE本の輪読会や、ミッションの決定、役割のスコープの決定、MTGの設立などを通して、だんだんとdelyのSRE像がみえてきました。この取り組みにより、チームで足並みが揃い始めていると実感しています!また、SREチームの責務を判断する際の明確な基準が生まれて、意思決定がスムーズになりました。現時点では、SREチームとしてスタート地点に立ったにすぎません。dely株式会社サーバーサイドチームの安尾です。月別アーカイブはてなブログをはじめよう!delyjpさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。