f:id:joe0000:20190924000124j:plain

こんにちは、6月にサーバーサイドチームからSREチームに異動した高山です。

私がSREチームにジョインすることとなり、SREのチームメンバーが増えることをきっかけに、現状のSREチームを見直すという取り組みを行っています。

弊社の開発組織にはもともとSREという職種が存在しています。しかし、実態としては、ソフトウェアも書けるインフラエンジニアがSREという名で活動しているというだけで、「一般的なインフラエンジニアの責務+困った時に頼られるなんでも屋」という曖昧なものでした。

その結果、

SREチームが実際には何をすべきチームなのか他のチームに正しい認識をしてもらえていない
メンバーによって認識しているSREとしての責務境界がバラバラ
降ってくるタスクが多すぎて足元解決型のチーム
優先順位が定まらず本来SREチームがやるべきことに着手できていない(のでは)

という状況になっていました。

これでは、SREチームの役割や責務範囲が属人的になり、本来のSREが発揮するべきバリューがチームとして効率よく発揮できないという問題が発生してしまいます。また、今後さまざまなバックグラウンドを持つメンバーが増えていくにあたり、さらに責務範囲の属人化が進むことが懸念されました。

そこで、SREチームとしてのミッションや役割、優先順位を明文化することで本来のSREチームとしてのバリューを発揮できるようにチームを見直す取り組みをはじめました。

取り組みについて

取り組み1: SRE本輪読会開催

問題点としてあげた通り、弊社のSREチームは本来のSREチームに対する理解がチームメンバーによって様々でした。 (ここでいう本来のSREチームとは、Googleが提唱しているSREチームのこと)

そもそもSREチームとは、「どのような問題を解決するために」「なにを目的として生まれたチームなのか」ということを全員が理解できていないと、足並みの揃わない、目的がブレたチームを発足することになります。ミッションや役割、優先順位を決めて執行したとしても、全員がその内容を理解できていないと本来時間を費やすべきでないことに時間を費やしたり、正確な意思決定ができなくなったり、納得感のないままミッションを遂行することになってしまうかもしれません。

そこで、SREチーム見直しの第一歩として本来のSREチームを知るべく、SRE本の輪読会を開催することにしました。

www.oreilly.co.jp

輪読会のやり方は以下のような方法で進めました。

### 進め方

頻度: 週1
時間: 1時間
ルール: 1章ずつ持ち回り制で輪読会を開催

### 事前準備

- 担当者
  - 内容のサマリーと気づきをまとめ当日他のメンバーにドキュメントをシェア
  - 読んだだけで理解できなかったところは可能な限りググってまとめる
- 全員
  - 章の内容を読んでくる
  - 章の中で特に議論したい内容を担当者があげたドキュメントに追記

### 当日

- 担当者がまとめてきた内容を各自読む（１０分）
- 共有内容と議論したい内容に基づいて議論する（５０分）

輪読会をやってみてわかったことは、

SRE本から得られる学びがとても多い
輪読会の効果がすさまじい

ということです。

まず、SRE本に書いてあること自体、とても勉強になります。今まで感覚的に「こうあるべき」と思っていたことが、実はそうでもなく、無駄なことに時間や神経をすり減らしていたと気付かされたり、逆に感覚的にこうだと思っていたことがきちんと明文化されて解決策が提示されていたりします。

また、SREという職種は会社ごとに役割にバリエーションがあったり、ふわっとしがちというイメージがありましたが、SRE本を読んでその責任範囲にかなり明確な定義があるということがわかりました。

さらに、輪読会のすばらしい効果を実感しました。そもそも誰かに読まれることを前提にまとめを作成することで、一人で読むのと比べて理解度が上がりました。また、メンバーの半分はSRE本をあらかじめ読んだことがあり、理解度の違うメンバー同士で議論することで、新しく読んだメンバーは効率よく理解が深まり、すでに読んでいるメンバーは認識が違っていた箇所や理解が曖昧だった箇所を潰すことでチームで認識を揃えることができました。

取り組み2: ミッションの決定

SRE本には、私たちのような少人数のチームでは真似できなかったり、サービスの特徴によって起こるGoogleならではの問題に対するアプローチや取り組みも含まれています。それゆえ、そのままGoogleのSREチームの概念を自分たちに投影して運用を試みても、無駄があったり、そもそも真似できない部分があります。

なので、自分たちが抱えている問題とGoogleが抱えている問題をきちんと切り分けて考え、自分たちに必要なルールを取捨選択したり、形を変えて自分たちのルールに落とし込んでいく必要があります。

そこで、弊社のSREチームでは共通の認識によって必要なルールを選定する意思決定ができるように、ミッションの策定を行いました。

まずは、こちらが決定したミッションです。

クラシルの信頼性や事業継続性を担保しつつ、ユーザーに価値を素早く提供できるように設計と運用を改善し続ける

信頼性とは：サービスに求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こすことなく実行する確率

ミッションの決定で行なったこと

SRE本の理解 (SRE輪読会)
現状のタスクの洗い出し
他社のSREチームミッションの事例を集めて共通点や違いを分析

まずは、最低限SRE本の1章を理解してミッションを決定するのがいいと思います。 SRE本の中にも出てきますが、1章がSREチームの役割を理解するために一番大事な章となっています。全てを読んで理解するのは時間がかかるので、まずはこの1章を最低限全員が理解した段階でミッションの決定を行いました。

次に、現状のタスクの洗い出しをして、SREチームがどのような責務を持っているかを明確にし、ミッションを決める際の参考にしました。

最後に、他社のSREチームのミッションの事例を集めて、SREチームが生まれた背景の分析や弊社のチームとの共通点の分析を行いました。

また、この時点でミッションはあとから柔軟に変化させていくという方針で決定しました。ミッションは最初に最適なものをピンポイントに決めるということはとても難しいです。あとから形を変えることができるので、悩みすぎずにこれと決めて事業ニーズの変化や次にお話しする役割のスコープ決定などに合わせて都度話し合っていくことが重要かと思います。

取り組み3: SREチームの役割のスコープの決定

取り組みの3つめとして、SREチームの役割のスコープを決定しました。まず、こちらが弊社のSREチームが現状考えている役割のスコープです。

可用性の担保
パフォーマンス（レイテンシなど）
リソースの効率的な活用
素早く安全な変更管理
モニタリング
緊急対応
キャパシティプランニング
セキュリティ

スコープの決定で行なったこと

スコープを決定するにあたって、下記の手順を踏みました。

SRE本に挙げられているSREの責務のスコープと、現状の弊社SREチームのタスクのマッピング
マッピングした上で、それぞれのスコープが弊社の今後のSREチームに必要か議論
スコープからはみ出した責務をSREチームが担うべきか議論
決定したスコープがミッションに沿ったものになっているかを見直す

まずは、SRE本の第1章に登場する「SREの信条」として出てくるスコープと現状のSREチームのタスクをマッピングしました。現状のタスクがSRE本で挙げられているSREの責任範囲にマッピングできないものは、弊社のSREチームが過度に持っている責務として分類しました。そして、それぞれのスコープが弊社のSREチームに必要かどうかを議論しました。ここでは、SRE本で挙げられていたスコープになにかしらのタスクが当てはまる結果となり、どのスコープも必要であるという結論になりました。

f:id:joe0000:20190918184750p:plain

次に、GoogleのSREの責務からはみ出した責務をSREチームが担うべきか議論を行いました。

前述したように、Googleと弊社ではチーム構成も人数も違います。例えば、SRE本に列挙されている責務のスコープにはセキュリティがありません。 GoogleにはSREチームとは別にセキュリティのスペシャリストチームがいる可能性が高いです。弊社は、セキュリティチームがないのでその責務をSREチームが兼任する必要がある、といったように、GoogleのSREチームの責務に加えて持たなければならない責務についても議論しました。

最後に、最終的に決まったスコープが、SREチームのミッションに沿ったものであるかどうかを確認しました。必要なスコープがチームのミッションに即していない場合は、スコープを見直すか、チームミッションを見直す必要があります。

f:id:joe0000:20190918182153p:plain