はじめに

本記事は、2024 年 2 月 21 日に開催された「RECRUIT TECH CONFERENCE 2024 - 技術で挑み、技術でつなぐ。」に参加した際のレポートです。

参加した経緯

SRE NEXT 2023 に参加して半年経ったので、改めて他社さんの SRE について知見を持とうと思ったから、また Platform Engineering についてのセッションがあったので気になったから

ピックアップ：自己完結な開発組織を支えるプラットフォーム作り

SRE チームの目標

自己完結チームが、プロダクトを素早く安全に稼げるためのプラットフォームと文化を作る

自己完結チーム？
自分たちに必要な問題解決をできるかぎり、自分たちで行うことができるチーム
(具体的には、自分たちで開発するのは、もちろんのことインフラ環境の構築や本番リリース後のトラブル解決等をすべて一貫して開発チームで行っていくチームのこと)

なぜ自己完結チームなのか
ユーザーへ、より素早く価値を提供できるから

自己完結チームに求められる要素

自分たちでサービスが観測可能である
サービスがどのように動いており、今どのような状態であるかを開発チームで把握し、説明できること
( オブザーバビリティが高いということ )

自分たちでサービスが制御可能である
開発チームが必要なタイミングでリリースができること
要求される仕様変更やトラフィックの増加等の内外原因の変化に対して、自分たちで対応が可能であること

SRE チームの取り組み

プラットフォームを作る

開発者はサービスをできるかぎり、自分たちでコントロールできる状態にする
SRE はリリースの可否を判断する存在ではない

手作業は極力避ける PRを作成、CI が通れば OK という状態にする

Terraform Repository で管理
tfaction による GitOps の実現
PR を作成するれば plan 結果が表示され、マージすれば apply
安全ではない、望ましくない設定は CI が通らないように

開発環境と本番環境の差分を小さくする

開発用DB 日時で本番からマスキングして同期
オブジェクトストレージはマスキングして開発環境へコピー
→ これらによりパフォーマンス問題に早く気付ける

可観測性

SLO の合意、運用
アラートをアクション可能なものに制限

文化を作る

開発者にとって身近な存在に
積極的に不満などを聞きに行く
プラットフォームのフィードバックを得る

感想

このセッションを聞いて、個人的に考えていた開発者のためのプラットフォームとは一体なんなのかについて、答えを得ることができた。近年、DevOps の推進によって運用やインフラ関連のタスクを開発者が行うことが多くなっている。それこそ、このセッションでも言われていた開発、インフラにおいて一貫することで自己完結していくチームが多くなるのは明確な事実で実際に起っている。しかし、これらによって開発者に多大な負荷がかかっていることも同時に起こっているのも一つの事実である
この負荷を解消するために PlatformEngineering はあるのではないかと本セッションを聞いて感想を抱いた。ただ、本セッションにおいても話題にあったかと思われるプラットフォームは開発者が必要としているものでなければ、使われず失敗に終わることがよくある
もしプラットフォームを作る機会があるなら、すぐ作るのではなく、なぜ必要なのか、何が必要なのかを正確に考える時間が必要だと思った