✨
SRE組織の分類
はじめに
SREとは？
What exactly is Site Reliability Engineering, as it has come to be defined at Google? My explanation is simple: SRE is what happens when you ask a software engineer to design an operations team.
組織の構成として、大きくは以下の2つに分かれる
- SREがチームに埋め込まれている - Embeded SRE
- 外部のチームとして構成されている - Dedicated SRE
Embeded SRE
SREがチームに埋め込まれている
以下の2つに分かれるが、同じ意味で使ったりする
- Embeded SRE
開発もSRE業務もやる - Product SRE
SRE業務を実施
Dedicated SRE
SREが外部のチームとして構成されている
- Everything SRE
SREに関することを全部やる
（外部SREチームを作成した時の初期状態→組織が成熟するとこのパターンはなくなる？） - Platform SRE
サービス基盤を担当する- Infrastructure
- Tools
- Enabling SRE
SREの知見を共有・支援する
このチームのメンバーが開発チームにジョインするケースもあって
Embeded SREと同義に使われることもある（ややこしい）- Center of Practice
- Consulting
- Evangelist
- DBRE(Database Reliability Engineering)
データベースに特化したチーム
ポエム的な何か
SREは役割でなく技術
とはいえ、、、
- 認知負荷を下げる
- 役割として与えることによってSREを実践しやすくする
- 機能開発のタスクをアサンされてるメンバーがSREタスクを提案して進めるのはハードルが高いのでは？
- 理解を得られていないと評価がされなかったり、関係ないことをやっている人という評価になったりする
（事前に認識をそろえて枠組みとして用意しておく）
- 開発とSREで必要なスキルが違うので、スキル不足により開発メンバーだけでは実践が難しい
のような理由で役割として与えるケースがわりとある気がする
（エンジニアがフロントやバックに分かれたように、分業が進んできたという考え方もできる）
なので、みんなでやっていこうというEnablingとかEvangelistの共通認識が必要
最初からSREのスキルが高いメンバーが多ければどの体制でも問題ないが、
そうでない場合はCenter of PracticeとなるEnablingSREをいきなり立ち上げるのではなく、
最初はEmbeded SREの構成でメンバーの技術を向上していくといった取り組みが必要になってくる
参考
Discussion