こんにちは、 @mshibuya です。
広告代理店オプトで広告効果計測ツール「ADPLAN」のSREチームリーダーをやってます。
これまでプロダクト内に閉じたSREチームとして活動してきたのですが、今後の展開としてSREとしての活動を複数のプロダクトチームを横断する取り組みに変えていきたいという構想があり、その話をしたいと思います。
なおこの記事はSRE Advent Calendar 201814日目のエントリです。
これまでのあらすじ
ADPLANというプロダクトにおいて、信頼性や緊急対応への課題感からプロダクト内のいちチームとして3人からなるSREチームを立ち上げて約１年、多くの運用改善をして喫緊の課題も少なくなってだいぶ落ち着いてきたかなー…くらいな現状です。
SRE Lounge #5にて登壇した際の資料にSREチーム立ち上げの経緯がまとまっているので、あわせてどうぞ。
モチベーション
現状プロダクト内SREチームとして業務に当たる中で、こんな課題感があります。
- オンコール(緊急対応)当番のローテーションがタイト
- 現状3人のSREチームで一週間交代で当番を回しているのですが、わりと頻繁に回ってくるのであまり気が抜けないという声があります
- とはいえ実際に対応が必要となるような緊急事態は滅多に起きない
- これはSREとしては実際に緊急対応の経験を積む機会が得られず、十分スキルを高められないことに繋がってしまいます
- 良いプラクティスや学ぶべき教訓がプロダクトチームを超えて生かされない
- 現状では社内他プロダクトにおいてSRE的プラクティスを実践しているチームがないことも関係しています
- プロダクトチームごとに独立して緊急対応へ備えるのはリソースを浪費する
- 「有事に対して備えなければいけない」というのは当然精神的リソースを消費するので、負担を一箇所にまとめられればだいぶ楽になりそうです
- プロダクトによっては2-3人規模のチームもあり、「専業のSREを置く」という動きも取りづらい
- 「SRE的業務に人を部分アサインする」でうまくいくイメージも持てないので、「専業のSREが（他プロダクトを見つつ）部分的にそのプロダクトも見る」が解になるかなと…
構想内容
表題の通り、プロダクト横断でのSREチーム体制に変えようとしています。
- プロダクト内チームとしての「SRE専業チーム」を作るのではなく、プロダクト開発チームの一員としてSREメンバーが所属する形式に
- 同じチーム内で日々一緒に業務することで、新規の機能開発などがもたらす信頼性に対するリスクを早期にキャッチし、適切に手を打てるようにする
- 万一信頼性に大きな懸念が生じたような時に、開発チームメンバーが信頼性向上タスクに取り組むといったリソースの融通が可能に
- 加えて別のプロダクトにおいてもSREを立て、プロダクトチームとは別枠の横のつながりとして「組織横断SREチーム」を組成する
- SREのマトリックス的な配置についてはヌーラボさんの取り組みを参考にしています
- モニタリングやアラート、オンコール対応といったSRE的分野についてベストプラクティスを確立し、プロダクトチームを超えて活かしたい！
- わりと切実です。プロダクトが立ち上がるたびに運用体制をカスタムメイドするのもコストが掛かりすぎるので、型にはめたいですよね
乗り越えるべき壁
とはいえ、
- プロダクトによって技術スタックがまちまち
- SREの本家Googleのように全社的に統一された運用基盤があるわけでもないので、一人のSREが知るべき内容はすごく多岐に渡ってしまいそう
- バックログをどう管理していくか
- これまではSREチームとしてのバックログを持ちその中でタスクの優先度をつけていました。プロダクトとしてのバックログにSRE的タスクを積むことになるとして、ビジネス上求められる開発と信頼性向上のバランスをどう取っていけるかなと。。
- SREメンバーの評価はどうしよう…？
- これまでは評価上のライン＝SREチームでしたが、今後はプロダクトチームが評価ラインになるのでそこにSREとしての成果をどうやって反映させるのがよいか
あたりが課題で、解決していく必要がありますね。
まとめ
こう考えていくと、SREというプラクティスが対象にしているのは結局システムだけではなくて、人や組織・プロセスも視野に入れたエンジニアリング活動なんだなーという思いを新たにしています。
この取り組みは運用体制の構築事例としてきっと組織を超えて参考にしていただける内容になると思っているので、その後についてまたご報告できればと思っております。
最後までお読みくださりありがとうございました！