SREへの社内留学を通してEnabling SREを推進した話

こんにちは、金融開発チームでアプリケーションエンジニアをしている ogugu です。
普段はサーバーサイド・フロントエンド問わず実装しています。
直近では、半分趣味でGoのlinterを自作したり、フロントエンドにStorybookのインタラクションテストを導入したり、幅広くやっています。

さて、今回は、SREチームに社内留学して Enabling SRE を推進した話をします。

なぜ留学したか

自分はこれまで「技術をリードしていく立場として幅広い知識と経験を持った人材になりたい」というキャリア志向を抱いていました。
そのために、自分自身がウィークポイントに感じていたインフラやセキュリティの理解を深めたいと感じていました。

また、同時に、freeeの開発組織に対して「悪い意味で開発者とSREの責任境界がはっきりしていて、開発者がインフラの構築・運用やアラート対応に疎くなっているのでは」といった課題も感じていました。
実際、SRE側も以下のように同様の課題を感じていることがわかりました。

新規サービスが立ち上がる度にインフラ構築依頼が来て、SREがボトルネックになっている
アラート対応の負荷がSREへ偏ってしまっている
権限を委譲していくために、アプリケーション開発者の課題や気持ちを知りたい

そうした相談をマネージャーと重ねるうちに、「一ヶ月間、SRE チームに留学してみないか」と提案を受けました。
freeeでは、在籍チームは変えずに期間を決めて別のチームの業務を体験できる「留学制度」があるのです。

自分は当時、異動戦国という制度（1年に1回自分の希望するチームに異動の立候補できる）も利用していて、直近で金融開発チームへ異動する予定もありました。
そんな中にも関わらず、マネージャー陣の後押しもあって、せっかくの機会ということでSREへの留学に挑戦させてもらいました。
こういったfreeeの「自分の成長と向き合う文化」「それを全力で手助けする人事制度と組織風土」には感謝してもしきれない思いです。

とはいえ、組織に何か恩恵はもたらしたいと思っていて、「自分が留学することで、プロダクト開発者とSREの分離を崩すきっかけを作れるといいのでは」と考えていました。
その結果、構築から運用まで、自分のプロダクトに0から100まで責任を持てる開発者が増えれば、freeeの開発組織はより良くなるだろうという考えです。

Enabling SRE チーム

そして、自分が留学先に選んだのは「Enabling SRE」というチームでした。

そもそもSREとは、文字通り「サービスの安定稼働を実現すること・信頼性を維持すること」がミッションです。 freeeにおけるSRE組織は、以下の3つのチームに別れています。

Platform SRE: サービスを載せる基盤の横断的仕組み化によって信頼性を担保するチーム
Enabling SRE: 開発チームに対してSREの知見や文化を浸透させて立ち上がりを支援し、信頼性を担保するチーム
DBRE: データストア層に関わる信頼性を担保するチーム

そして、Enabling SREは、開発チームの立ち上がりを支援することで、開発者自身がSREのプラクティスを実践することを可能にする (=Enabling) という役割です。
まさに、自分の動機を考えると留学するにはもってこいのチームでした。

反面、当時のEnabling SREチームは、プロダクト開発者の支援どころか肩代わりをしてしまうことも多く、苦労していた時期もあったと聞きます。
そんな Enabling SRE の1つのゴールは、サポートの結果、プロダクト開発チームの中に Product SRE とも呼べる人が誕生することと言えそうです。

※ freeeのSRE組織の歩みについてもっと知りたい方は、以下の記事も合わせてお読みください。
2022: freee SRE Journey - これまでの振り返りとこれから - freee Developers Hub

留学で何をしたか

留学で得た知見や成果として、次の3つを紹介していきます。

SREオンボーディングプログラムの実践と改善
新規サービスのインフラ構築
freee人事労務におけるSLOアラート導入の提案

SREオンボーディングプログラムの実践と改善

配属直後は、オンボーディングプログラムを実践させてもらいました。
freeeでは大規模なEKSクラスタの運用が進んできた一方で、以下のように多くの技術をキャッチアップする必要があります。

AWSの基本的なネットワーク・コンピューティング・ストレージ技術の理解
kubernetesや仮想化技術に関する理解
terraformによるインフラリソースのコード化
Helm および helmfile によるkubernetesマニフェストのパッケージ化
ArgoCD によるkubernetesのGitOps デプロイメント
datadogによる監視モニタリング

そこで、そういった技術スタックを最短経路でキャッチアップするため、有志によってオンボーディング資料が作られてきました。

その充実したコンテンツのおかげで、最初の1〜2週間でfreeeのインフラ技術を体系的・網羅的にキャッチアップできたことは、その後に大きく繋がりました。
一方、当時はまだ荒削りなコンテンツもあったため、実施と同時に気になったコンテンツの改善を行っていきました。

このように、実施者がオンボーディングコンテンツの改善に回るフィードバックサイクルは自分以外にも行っていて、今も継続されています。
こうしたドキュメント文化は、プロダクト開発者としても見習うべき部分があると感じました。

新規サービスのインフラ構築

当時、freee販売を始めとしたいくつかの新規プロダクト・基盤マイクロサービスのリリースが控えていました。
そこで、freee販売のプロダクト開発チームをEnabling SREメンバーがサポートする協業体制で、インフラ構築を行う運びとなりました。

さて、freeeではEKSクラスタをシングルテナントで運用しており、インフラ構築を行おうとするとクラスタの払い出しから必要になります。
そういう意味では、プロダクト開発者にとって敷居が高い作業となりますが、こうした協業体制による権限移譲を始められたのには理由がありました。

それは、標準構成のクラスタを作成するための手順が整備されたことです。
ほとんど機械的な作業で、EKSクラスタの作成→IAMロールとポリシーの作成→ALBとそのエイリアスレコードの作成→ArgoCDデプロイ設定の流れを完結できるように、しっかりドキュメンテーションされていました。
手順書のプロダクトコードを置換してあげれば、ほとんどコピーペーストでPRを作成できるといった世界観です。

勿論、手順通りうまくいかない部分もあったので、その場合はトラブルシューティングを行い、ドキュメンテーションのフィードバックサイクルも同時に行っていきました。
余談ですが、Platform SREチームでは、こうして型化された作業をさらに抽象化・自動化した仕組み（詳細は伏せます）を考えているようです。

また、kubernetesのマニフェストに関しては、Helm によって Chart という形でパッケージ化されていて、さらに helmfile によってそれを宣言的に利用できるようになっています。
例えば、標準的なwebサーバーのためのDeployment・HPA・Configmapなどの組み合わせは、ある1つのChartを利用することで完結できます。

これらの地道なドキュメンテーション・標準化・充実したオンボーディングのおかげで、自分は統合環境〜ステージング環境〜本番環境のインフラ構築を2週間で完了できました。
そして、何よりEnabling SREチームのプロダクト開発者に対する継続的なサポート・コミュニケーションも大きかったと思います。
こうした足回りの整備もあって、並走していたfreee販売の開発チームも無事に構築作業を自走でき、Enablingが進んでいることがはっきりと実感できました。

そして、この取り組みの中で「SREの中で当たり前なこの構成はどうしてこうなっているの？」といった疑問はどんどんぶつけていくように意識していました。
つくった仕組みや知見を最終的に活用するのはプロダクト開発者であって、そのプロダクト開発者視点の疑問はドキュメントで払拭されるようになっているべきと考えたからです。

freee人事労務におけるSLOアラート導入の検討

ここまでは新規サービスの構築の話でしたが、既存サービスの運用におけるEnablingも重要です。

そこで、留学に送り出してくれたチームに何か恩を返したいという思いもあって、freee人事労務におけるSLOアラート導入の検討を行いました。
実際、この時期、freee人事労務ではユーザー増加に伴うパフォーマンスイシューなどアラート対応に見舞われており、以下のような課題を感じていました。

そのアラートが真にユーザー体験に影響を及ぼしているのかがわからない（ノイジーアラート）
そのアラートが具体的にどの機能に影響しているのかがわからない
アラートに反応するメンバーが属人化していた（SREと一部のプロダクト開発者）

SLOアラートでは、ユーザーの満足度やプロダクトの信頼性を表すSLO（サービスレベル指標）を定義し、それに基づいて真にユーザー影響のある事象のみをアラートしていきます。
これは、1点目の課題に通じていて、従来はCPU・メモリなどのいわゆるメトリクスアラートが多く、アラートがユーザー体験と直接結びついていませんでした。

また、SLOは重要なユーザーの利用シナリオ (CUJ : Critical User Journey) ごとに定義することで、「ユーザーがどのようにサービスを利用するか」が考慮されます。
これは、2点目の課題に通じていて、例えばレイテンシやエラーレートの集計も全エンドポイント総計で行っていたため、そのアラートが具体的にどの機能への影響を表すのかがわかりませんでした。

表1. 実際に作成したfreee人事労務におけるSLOのドラフト設計（一部抜粋）
ドメイン	CUJ	数値指標 (SLI)	数値指標の目標値 (SLO)	集計元
給与	給与の計算が行える	(n秒以内に成功したジョブ)/(総ジョブ数)	99.9%	給与計算の非同期ジョブ
給与	給与の管理が行える	(n秒以内に成功したリクエスト)/(総リクエスト数)	99.9%	給与・賞与明細の参照・更新API
勤怠	勤怠の管理が行える	(n秒以内に成功したリクエスト)/(総リクエスト数)	99.5%	勤怠一覧、勤怠集計、休暇管理の参照API
勤怠	勤怠の登録が行える	(n秒以内に成功したリクエスト)/(総リクエスト数)	99.9%	Web/Mobileの勤怠登録API、打刻機からの打刻API、勤怠画面の参照API

一方、EnablingチームではこれまでしばらくSLOアラートを検討していましたが、なかなか導入には至りませんでした。
実際、SLO設計にはプロダクト理解が必要不可欠で、SRE単独では成し得ません。
そこで、留学メンバーの自分がfreee人事労務におけるSLOのドラフト設計 (表1) を作り、検討→提案の橋渡しを行いました。

結果として、人事労務チームの「やりましょう」という心強い一声で Enabling が始まりました。
Enablingチームでは、今までプロダクト開発チームへの一定の忖度があったようで、その心理的な壁を壊すきっかけになれたように思います。

また、現在では、それぞれのチームが担当する業務ドメインに別れてSLOを設計し、試験的なアラート導入が始まっています。
その事前準備として、PMとコミュニケーションしながらCUJの見極めやSLOの策定を行ったり、SLO策定にあたってノイズとなっている既存エラーの整理を行っているようです。
ここはいずれ人事労務チームから共有があるかもしれませんので、ご期待ください。

さらに異動を経て

冒頭に述べた通り、SREへの留学を終えた後は、異動戦国を利用して金融開発チームへ異動しました。
そこでは主にfreeeカードUnlimitedの開発を担当しています。

freeeカードUnlimitedは、社内でも珍しいプロダクト内でのマイクロサービス構成になっていて、扱うkuberntes・AWSリソースの数や種類も多いです。
そのため、プロダクト開発者がインフラを触る機会が多く、やはり開発チームが自律的に構築・運用を行える必要があります。
そこで、留学の経験を活かして、金融開発チーム内のProduct SREのような貢献をできるように心がけています。

直近では、1つしか存在しなかった統合開発環境を複数に増やせるように、terraformやhelmfileのリファクタリングを行い、環境の増築を行いました。
また、インフラの構築や設定で困っているメンバーがいたら積極的にサポートし、スキルトランスファーやドキュメンテーションをして、今後開発チームが自律的に解決できるよう働きかけています。

※ freeeカードUnlimitedの開発に関しては、連載記事がありますのでそちらも併せてどうぞ。
【連載第1回】freeeカード Unlimited の開発の道のり - freee Developers Hub

さいごに

留学を通して、Enabling SREと留学制度はとにかく相性がいい と感じました。
当初は「ただただ組織に個人の成長機会を与えてもらうだけで、迷惑をかけるのではないか」という懸念もありましたが、実際は、以下に挙げるように プロダクト開発者・SREの双方にメリットをもたらしうる と感じます。