はじめに
デジタルソリューション開発部 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
上記Problemに対応したTryを挙げてみます。
- SREとAPLチームの明確な役割分担を定義する
EmbeddedSREとAPLチーム間でそれぞれの役割を再確認、明確に区別し、共通認識を持つよう働きかける。 - SREチームへの作業依頼にかかる負荷を削減するようセルフサービス化検討
SREチームへの作業依頼をそもそもなくし、APLチームが独自で作業を進められるようセルフサービス化を検討。
コミュニケーションコスト削減を含めた開発効率向上のための取り組みを進める。 - Platform SREチーム内でEmbedded SREメンバーのサポーターを導入
共有会で伝えきれない、伝え漏れていた細かな変更についてEmbedded SREが気兼ねなく質問、サポートが受けられる体制を整えてみる。
まとめ
2024年度上期のEmbedded SREの活動を振り返りました。
JDEPは新規に立ち上がるサービスも増え、SREチームが直面する課題は多岐にわたります。
今後も、作業メトリクスの収集、セルフサーあビス化、体制のアップデートを通じて、課題解消とSREの活動の認識向上に努めていきます。
最後に
JCBでは我々と一緒に働きたいという人材を募集しています。 詳しい募集要項等については採用ページをご覧下さい。
本文および図表中では、「™」、「®」を明記しておりません。 記載されているロゴ、製品名は各社及び商標権者の登録商標あるいは商標です。