こんにちは、マネーフォワード サービス基盤本部 インフラ部に所属している中谷です。
先日、鈴木のブログにもあったように、サービス基盤本部では体制を変えていっている真っ最中です。(今までの組織体制の課題や、これからの本部としての目指す方向の詳細については、是非そちらのブログを参照してみてください。)
その新しい体制の中で “Enabling SRE” というチームが生まれるのですが、Enabling SREとはどういうチームなのか?どういう背景で生まれたのか?何をやっていくのか?ということを紹介したいと思います。SREの文化を根付かせたいけど、どうアクションすればいいかわからないといった方の参考になればいいなと思っています。
はじめに
まずは背景を簡単に説明して、なぜEnabling SREが必要になったのかを知ってもらいたいなと思います。
サービス基盤本部の体制変更の背景
マネーフォワードでは、初めは中央のインフラチームのみで全てのプロダクトの運用を行い、プロダクトの開発チームは機能開発に集中するという体制でした。しかしながら、プロダクトの数が増えていくにつれて、インフラチームのリソースが不足し始め、インフラチームがプロダクト開発のボトルネックになってきました。
このままでは中央のインフラチームのスケールに合わせる形でしかプロダクト開発のスピードが出せないということになってしまいます。それを回避するために、プロダクト開発の各プロダクトの開発チームに権限を渡していき、自分たちで開発のサイクルを回せるようにする必要があると考えました。そこで、権限を渡しやすいような新しい基盤を作り、プロダクト開発チームが自分たちで開発のサイクルを一貫してみれるように新しい基盤に移行をすすめていきました。
ただそういった中で、下のような別の課題が出てきました
1. 基盤をまだ作り込めていないということもあり、プロダクトの開発チームで開発サイクルを閉じていくにはまだまだ基盤上でのアプリケーションの開発/運用の技術的な難易度が高い。
2. 各プロダクトの開発チームは、自分たちで開発のサイクルを回し、非機能面も含めて見るべきだと考えている。しかしながら、権限を渡されても非機能面を見ていくための知見がないので、自分たちでみれるようになるまでにGapが存在している。
現在、一部のプロダクトは実際に中にSREチームを作り、自分たちで非機能面まで見ることができるようになってきています。しかしながら、自分たちでSREチームを作ったり、SREを実践できないチームがまだ存在しています。SREチーム立ち上げのための知見がなかったり、リソースが割けなかったり、といった課題が存在しています。
そして、主に上記の2.
の課題を解決するためにEnabling SREが必要と考えました。(1.
の課題に関してはPlatform SREの内容になってくるので本記事では詳細は割愛します)
こういった背景があってサービス基盤本部は体制を変えていこうと考えています。