こんにちは、永尾です。
今回は Product SRE についての話をします。
Product SRE とは
私たちは現在、Product SRE として各プロダクトへ個別に SRE メンバーを配置し、信頼性に対する取り組みを行っています。
まずは Product SRE について簡単に説明します。
Product SRE は、SRE が特定のプロダクトやサービスに専念し、その信頼性、可用性、パフォーマンスを専門的に管理・改善する SRE の実装モデルです。
– SREの知識地図 (技術評論社) 第8章 SREの組織構造
文字通り、プロダクト専任の SRE ということですね。
Product SRE のデメリット
Product SRE について、少し掘り下げてみましょう。
個別最適というメリットがある反面、デメリットもあります。
プロダクトごとに特化されるプラクティスが他のプロダクトで流用しにくい点です。
The product focus of each team can lead to duplication of base infrastructure or divergence of practices between teams, which is inefficient and limits knowledge sharing and mobility.
– Google Cloud Blog: How SRE teams are organized, and how to get started
また、似たような形態として Embedded がありますが、横断的な施策が進めにくいとされています。 Product SRE でも同様のことが言えます。
It may result in lack of standardization between teams, and/or divergence in practice.
SREs may not have the chance to spend much time with peers to mentor them.
– Google Cloud Blog: How SRE teams are organized, and how to get started
特に横断的な施策が進めにくいという課題がよく言われるデメリットかと思います。
デメリットをどう補っているか
それらに対して私たちは
- 毎日 SRE メンバーで進捗確認
- 事例共有として全社オープンドキュメント化
- 毎週オフラインで SRE についての議論
などを行っています。
これらの取り組みの中で横断的な施策を円滑に動かすために2つのことを意識しています。
- SRE メンバー同士のコミュニケーションを活性化させること
- プロダクトの個別最適施策を進める際に横断でハマる形を意識すること
2つ目は特に重要です。Product SRE では各メンバーが担当プロダクトに深く入り込むため、視野がそのプロダクトの技術スタックやインフラ、開発フロー、プロジェクト管理手法に閉じやすくなります。
そこで、すべてのプロダクトの状況をある程度把握している統制役が必要になります。
統制役は、個別プロダクトの施策を設計する段階でレビューや助言を行い、「この設計なら他プロダクトでも適用しやすい」「ここはプロダクト固有の部分と共通化できる部分を分けた方がいい」といった方向づけをします。
個別最適を損なわず、施策の中に横断展開の余地を最初から織り込むのが統制役の役割です。
これにより、ある施策が完了した時点で横断展開のための再設計が不要になり、他プロダクトへの展開がスムーズに進みます。
私たちの場合はマネージャーがこの統制役を担っています。
コミュニケーションの活性化と、統制役による方向づけを続けていくことで、SRE メンバー間でも他プロダクトの状況が自然と把握できるようになり、横断的な観点で施策を考えられるようになってきます。
SRE 文化の浸透
そのような取り組みを続けてきた私たちですが、現状では上手くデメリットを回避しながら Product SRE を運用できていると感じています。
Product SRE として、プロダクトと一緒に歩んで来たことで SRE が勝手にやっていることではなく、文化として SLO がプロダクトに浸透しています。
実際にプロダクトチームのみで SLO を策定し、SLI を実装しているケースもあります。
それを見たときは SRE 文化が浸透するってこういうことなんだ…と感慨深かったです。
一方でうまく行っていないと感じるところもあります。
SLO を広めたときには意識できていた 文化を広める ことが段々とおろそかになってきています。
私も含め、SRE メンバーはエンジニアであるがゆえに、SRE をエンジニアリングとして捉えがちで、文化を広めることが置いてけぼりになっていると感じています。
ここに対する取り組みも行い始めたので、またどこかで記事にできたらと思います。
改めて SLO の導入を進めたときの気持ちを思い出しながら、SRE の提唱を進めていこうと思います。