SRE (Site Reliability Engineering)からPE (Platform Engineering)へ

Platform Engineeringチームの加藤です。PEチームが昨年後半から提供を始めたプラットフォームに1つ目のプロダクトの乗り入れが完了し、PE活動の一つの節目を迎えたため、オプティムにおけるPlatform Engineering活動を紹介します。

PE活動は元SREチームのメンバーが中心となって始めた活動です。そのため

SREの振り返り
PEチーム発足の経緯
PEの活動

の順で話を進めていきます。

SREの振り返り

SREチームは、IoTプラットフォームOPTiM Cloud IoT OSのインフラ開発・運用のメンバーを中心に結成し、2020~2021年度の2年間、オプティムプロダクトの速い・安い・安心を横串で実現することをミッションに活動しました。

SREチームは特定のプロダクトを持たないチームで、

プロダクトを横断的にレビューし
一律に改善する方法を検討し
特定のプロダクトで試験実装・試験運用し
他のプロダクトに展開する

という動き方をしていましたが、次のような難しさがありました。

プロダクトを持たないため運用を含めた成功例を作って示せず、最初に適用されるプロダクトチームの負担を強いること
改善の適用をプロダクトチームにお願いした場合、彼らには他にさらに優先すべきことがあるため改善がなかなか進まないこと
改善の適用をSREチームが行った場合、他で手一杯なプロダクトチームへの引き渡しが難しいこと
成功例ができてもプロダクトごとに実装が異なるため、水平展開が難しいこと

こうしたアプローチの難しさやプロダクトを持たないことによって現場で抱えている課題の肌感が薄くなったことなどの理由があり、とても悩みましたがSREチームは解散することにしました。(SREチームのマネジャー視点での振り返り記事もぜひご覧ください。)

PEチームの発足の経緯

SREチームが解散した後は元々所属していたOPTiM Cloud IoT OSのインフラ開発・運用チームに戻りましたが、OPTiM Cloud IoT OSだけでなくAIサービスやDXサービスなどのインフラ開発・運用を一手に引き受けるチームとなっていました。インフラ開発・運用に関する知見を貯める目的で集約された体制でしたが、実情はインフラの実装の違いなどにより知見が集約できずサイロ化していました。そして、それによってチームの負荷が高まっており、今後も担当するサービスが増え続け、さらに負荷が高まることが予想されたこともあり、改善が急務となっていました。

負荷の原因の一つは、アプリ開発チームとインフラ開発・運用チームで権限を分けてアプリとインフラで境界線を設けていることによるものでした。これによって次のような問題がありました。

インセンティブの違いによる摩擦
- チームが分かれているため、目標や優先度が異なり、開発と運用の間に見えない壁が出来やすくなっていました。
スピードの低下
- アプリのことは当然インフラ開発・運用チームよりアプリ開発チームのほうが詳しいため、アプリ開発チーム側で対応した方が速いことでも権限がないためにインフラ開発・運用チームに依頼が必要となり、それだけで時間がかかっていました。そして、依頼した作業がうまくいかなければそのリカバリのためにコミュニケーションが必要となるため、さらに時間がかかります。

こうした従来のルールによって壁を作る門番(ゲートキーバー)から、速度を出しつつ信頼性を落とさない仕組み(ガードレール)への転換が求められました。そんな中書籍Team TopologiesやPlatform Engineeringの盛り上がりに後押しされ、これらの問題を解決するためにPEチームを発足しました。

PE活動

オプティムにおけるPEチームは次のような活動を推進します。

プロダクトチームがプロダクト固有の問題解決にフォーカスし、プロダクトの価値(美味い)が向上できるようにするために、プロダクト非固有の問題(速い・安い・安心)を解決するプラットフォームを提供します。
- オプティムプロダクトの品質を一律に底上げします。
プラットフォームのセルフサービス化を促進するポータルを提供します。
- プロダクト非固有の問題を解決するための方法を集約し共有します。
プラットフォームをテンプレート化します。
- インフラを分ける必要性があるプロジェクトでインフラ構築のスピード増加と他で得た知見を水平展開し運用を効率化します。
- テンプレートの構成要素も再利用可能な形でまとめ、それ単体での利用も可能にします。
  - Helm chartやTerraform module、コンテナイメージ、CI/CDの設定テンプレートなどがあります。
プロダクトの品質の可視化
- プラットフォームを利用しているプロダクトを計測し、プロダクトのフェーズに応じたサービス品質の達成度合いスコアリング、そして改善に繋げます。
  - SREのときもやっていましたが、実装の違いから手動計測であったり、個々のチームで評価をしていたがために評価基準がブレたりなどの課題があったのを、プラットフォームによってプロダクト間の差が少なくなるため計測や評価の自動化が可能になる見込みです。
  - Production readyの観点やFour key metrics, コストなどを対象にすることを検討しています。

得られた・期待できる効果

PE活動によって次のようなよかった点、今後効果が期待できる点があります。

Platform as a Serviceという形で責任分界点を引き直すことが可能になりました。
- 「You build it, you run it.」を原則として、プロダクトのことはプロダクトチーム、プラットフォームのことはプラットフォームチームに整理を進めています。
プロダクトをプラットフォームに集約していくことでそれぞれのインフラ開発・運用チームが一つにまとまる方向に進み、知見の集約・共有がしやすくなりました。
一つのプラットフォームにプロダクトが集約されること、テンプレート化によってプラットフォームの水平展開が可能になったことでインフラ開発や運用の負荷も軽減できるようになりました。

まとめ

PEチームは、従来のDevとOpsで線を引いてルールでガチガチに縛ってプロダクトの歩みを遅くする「門番(ゲートキーパー)」ではなく、速い・安い・安心をプラットフォームの形をした「ガードレール」で提供してプロダクトの美味い(価値)を高めるお手伝いをしていきます。

今年度はより多くのプロダクトがプラットフォームを使えるようにマルチテナンシーの強化、プロダクトの乗り入れのサポートに力をいれてやっていきます。OPTiMではこのような取り組みに共感し、協力いただけるメンバーを募集しています。ご応募お待ちしています！