はじめに

デジタルソリューション開発部 SRE チームの小柳津です。

以前の記事で、JCB Digital Enablement Platform (JDEP) SREチームで取り組んでいる、SREエンゲージメントモデルの1つ「Embedded SRE」についてご紹介しました。（記事はこちらから！）
2024年度も半分を過ぎたということで、今回はここまでのEmbedded SREの活動実績および、取り組みを振り返りたいと思います。

✏️ Embedded SREとは？

先日の記事でもEmbedded SREの取り組みについてご紹介しましたが、ここで簡単におさらいをします。
（JDEPへの導入背景やAPLチームへの関与方針については、前回の記事をご参照ください。）

Embedded SREは「組み込みSRE」という意味で、SREメンバーが JDEP上で稼働しているAPLチームに、Devメンバーとして参画するモデルです。
スクラムイベントなども含めてAPLチームの一員として活動し、基盤構築や監視運用に密接に関与することが可能となります。
詳しくは、Googleが提唱しているSRE Engagement Modelをご覧ください。

SREチームは Embedded SREとJDEPの横断的な対応をするPlatform SREに分かれ、それぞれの役割で活動しています。

🏆️ 2024年上期の活動実績

2024年上期のEmbedded SREの活動実績をご紹介します。
今期は4チームへのEmbedded支援を行いました。サービスA、サービスC（#支援フェーズ1）、サービスDについては策定したミッションを達成、Embedded無事終了となりました。
サービスB、サービスC（#支援フェーズ2）においても多岐にわたるミッションをこなしており、今後も引き続き支援を行う予定です。
※サービスDの参画人数に記載している「Platformチーム」とは、JDEPの環境構築、維持管理を担当するチームを指します。開発体制の詳細については本ブログ記事「JDEPの開発体制とその変遷」をご参照ください。

サービス	ミッション	参画人数	期間
サービスA	非機能試験実施支援 Production環境構築	2名	2024/4 - 2024/6
サービスB	非機能試験実施支援 UAT, ST支援インフラ作業計画/設計/構築支援運用設計監視設計障害訓練支援	3名	2024/1 - 2024/12 ※予定
サービスC #支援フェーズ1	アーキテクチャ検討 Dev/QA環境構築 CI構築 CUJ/SLI/SLO検討監視設計/実装運用検討/設計スキル移管	3名	2024/2 - 2024/9
サービスC #支援フェーズ2	アーキテクチャ検討非機能要件検討支援 JDEPナレッジ共有 PoC準備支援外部設計ドキュメントRv、内部設計支援 Dev環境構築	3名	2024/6 - 2024/12 ※予定
サービスD	アーキテクチャ検討 QA環境構築運用構築 CUJ/SLI/SLO検討支援	2名（SRE、Platform チームから1名ずつ）	2024/7 - 2024/9

先期までの課題に対する今期の取り組み：APLチームへのスキルトランスファー

先期までの課題として、APLチームへのスキルトランスファーの難しさがありました。
Production環境のリリース支援や非機能試験支援など、スポット的にEmbedded参画することが多く、APLチームのDevとEmbedded SREが別々にタスクを遂行する状況が生じがちでした。
この結果、作業内容や設計思想の共有が十分に行われず、SRE側に知識が閉じてしまうケースがありました。

今期は、APL DevとSREがペアワークでタスクを遂行することで、スキルや知識の共有を進める試みを行いました。
また、SREが単独で作業する場合は、作業の録画を残し、Embedded期間終了後にもAPLチームに知見が引き継がれるよう工夫しています。

ただし、APL Devの認知負荷の増加による開発効率の低下も懸念されるため、今後も改善策を検討していきます。

💡 振り返り

今期の振り返りでもKPT法を用います。
Embeddedメンバーの意見から、EmbeddedSREおよびSRE全体におけるKPTが挙がりました。

Keep

ペアワークの実施によるスキルトランスファー
APLチームへのスキルトランスファーが進展した。
SREとPlatformチームからのジョイン
活動実績にある通り、サービスDへはSREとPlatformチームからそれぞれ1名ずつが参画し、インフラ構築におけるスムーズなタスク遂行と、両チームのスキル交流が促進された。
インフラ検討/構築の理解深化
サービス要件に基づいたインフラ構築作業を行うことで、理解力が深まった。

Problem

APL DevとEmbedded SREの作業線引きの曖昧さ
開発スケジュールとの兼ね合いや人的リソースの問題で、本来APLメンバーに実施してほしいタスクでもSREに振られることが多い。
本来の責任範囲を超えた対応をしてしまっていることはEmbedded SREメンバーの負荷増大やモチベーション低下にも繋がる懸念がある。
APLチームからSREへの作業依頼時のハードルの高さ
作業所掌としてIAMの付与やネットワーク設定はAPLチームから依頼を受けSREが行うとしている。
APLチームがSREに作業依頼を行う際、SREとのコミュニケーションが発生するため依頼に負担を感じる場面があることを認識。
SREの活動内容やルールの把握不足
Platform SREチームにおいて日々更新されていくルール/実装変更の共有が不十分で、Embedded SREが最新情報に追いつけていないケースが発生。

Try

上記Probleｍに対応したTryを挙げてみます。

SREとAPLチームの明確な役割分担を定義する
EmbeddedSREとAPLチーム間でそれぞれの役割を再確認、明確に区別し、共通認識を持つよう働きかける。
SREチームへの作業依頼にかかる負荷を削減するようセルフサービス化検討
SREチームへの作業依頼をそもそもなくし、APLチームが独自で作業を進められるようセルフサービス化を検討。
コミュニケーションコスト削減を含めた開発効率向上のための取り組みを進める。
Platform SREチーム内でEmbedded SREメンバーのサポーターを導入
共有会で伝えきれない、伝え漏れていた細かな変更についてEmbedded SREが気兼ねなく質問、サポートが受けられる体制を整えてみる。