皆さんこんにちは！GC Growth devというチームで新規事業開発やeギフト販売SaaSプロダクトの開発に携わっているエンジニアのinoueです。 ギフティは2024/08/03~04にかけて開催されたSRE NEXT 2024にGOLDスポンサーとして参加しました。 私も参加者として一緒にカンファレンスを楽しんできましたので、その模様をお伝えしたいと思います！なお、スポンサーの背景はもう一つの参加記事で書いていますのでぜひこちらもご覧ください。

SRE NEXT 2024とは

公式より引用：SRE NEXT 2024

信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンスです。 同じくコミュニティベースのSRE勉強会である「SRE Lounge」のメンバーが中心となり運営・開催されます。 SRE NEXT 2024のテーマは「Beyond NEXT」です。SRE NEXT 2023で掲げた価値観 Diversity、Interactivity、Empathyを大切にしつつ、SREの担う幅広い技術領域のトピックや組織、人材育成に対してディスカッションやコミュニケーションを通じて、新たな知見や発見を得られる場にします。

SREにまつわるカンファレンスで２日間にわたって開催されました。今回のテーマは「Beyond NEXT」でした。 オフライン・オンラインのハイブリッド開催ということで、会場だけでも多くの人で賑わっていましたが、オンラインでもたくさんの方が参加されていたようです。

セッション

キーノートやLTなどたくさんの発表がありました。どれも参考になるものばかりでしたが、特に印象に残ったセッションについて、学んだこと・感じたことを紹介します。

Becoming SRE - SREって何から始めればいいの？

こちらはオフライン限定のパネルディスカッションでした。実は私自身、SRE観点の考え方・スキルをこれから学んでいきたいというひよっ子状態だったので、様々な学びがありました。

そもそも私の中の「SRE」というロールに対するイメージとしては、クラウドインフラの設計・リソース構築・監視・デプロイ基盤実装等が求められるものと思っていました。そのため、プロダクトに機能を実装するアプリケーション開発者とは少し距離がある役割を責務として持つという固定観念を持っていました。しかし、最終的に目指したい信頼性等はプロダクトの性質に合わせる必要があるためプロダクトの理解がとても重要という話がパネルディスカッションの中であり、考え方が変わりました。思ってた以上にプロダクトマネジメント視点の思考や行動が求められる領域なのだと理解できました。 また、SRE業務がプロダクト開発チームと分離されている組織が前提の場合、SREチームとしてやるべきと考えることと、現場開発チームでSREチームにやってほしいと考えていることを十分にすり合わせないと最終的に目指したい指標にズレが発生してしまうことも珍しくないようでした。一般的なSRE観点ですべきことを作業的に実装しデプロイしても、結果的に現場開発チーム側の理解が得られなければ意味がないため、あえて意思決定や実行スピードを落とすことで理解を得ながらやるほうが良いという考え方も紹介されました。最終的にどのような理想状態を描くのかを、プロダクト性質を十分に考慮したうえで設定できなければいけない難しさを改めて感じ、プロダクト全般に関するかなり広い視点を持って意思決定する重要性を学びました。

また、SRE職の方はどのくらい居ますか？という聴講者に対する問いに対しては、半分に満たない程度の人が挙手していました。テーマ的にもこれからSREを始めたいという方が多く参加されていたみたいです。

発表者の皆さんありがとうございました！

プロダクトのスケールによって顕在化しうるリスクをどう管理するか？

diniiさんのサービスを導入されている飲食店の売上がとても重要だからこそ、diniiさんのサービスが機能不全に陥ることを可能な限りなくすため、信頼性の投資が不可欠！という重要なメッセージが印象的でした。

信頼性向上の取り組みとして、インシデントの予防・緩和・振り返りを実施されているようです。私もなんとなくモニタリングや振り返りなどは意識しつつも、今のやり方が不十分だったなと気づきがありました。チーム全体で振り返りする会を月に1回行っていますが、監視アラートの通知で傾向変化に気づく場合も多かったです。また特定のメンバーが監視周りも定期的に目を通していたから結果的に障害を予防できていた状態であったと思います。担当プロダクト内ではもっと短期的な振り返りを仕組みとして作るべきだという学びを得たので、具体的なやり方はこれから模索しようと思います。

また、属人化についての話もありました。私のチームでメンバー皆インフラレイヤーの実装や監視等の改善には手を入れつつも、継続的なSRE観点での対応については、直近では意図的に私が可能な限り対応する方針としていました。これは私がSRE観点を学びたいという思いと現場開発リソースのバランスを考えての意思決定です。まだSRE観点の基盤・改善文化が整ってるとは言えない体制ですが、長期的にはできあがった基盤をチームにどのように伝播するのか、文化としてどのように醸成していくかは課題に思っていました。発表内容の方法を取り入れてみようと思います。

発表ありがとうございました！

Central SREとEmbedded SREのハイブリッド体制で目指す最高のSRE組織

エムスリーさんの数年に渡るSRE組織体系の変遷から得た学びを発表いただきました。オンプレミス時代からクラウド主流時代への重要な転換期を経ての内容でした。

エムスリーさんでは、Central SRE担当（全社横断チーム所属）とEmbedded SRE担当（各開発チーム所属）に役割が分かれた形でSRE観点の施策を実施されているようでした。ハイブリッド体制と呼んでいましたね。Embedded SREがいることで開発現場からの主体性が保たれるメリットがあり、全社横断的なサポートをCentral SREが担う形で構成されているのはとてもバランスが良さそうに思いました。

一方で各チームに細かい知見がばらついてしまったり、特定箇所の改善が周囲に影響を与えてしまうケースもあったりと、なかなか情報把握が難しそうな点がデメリットでありそうでした。完全にチームを横断チーム or 各チーム配属とどちらかに固定するよりもメリットは多そうに感じましたが、なかなか良いバランスを保つのは難しいのですね…。Embedded SREを主体にしつつの方針になりそうとの話もありましたが、私のチームでも先ほど述べたように属人化されてる点の解消方法としてどのような体制が相応しいのかは考えていこうと思います。

発表ありがとうございました！

ブース

ブースコーナーでは様々な企業さんが出展されていましたが、我々も出展していました。ブースにお立ち寄りいただいた皆様ありがとうございました！

我々のブースでは「私の組織・プロダクト ここをなんとかしたい！」という皆さんの課題感を記載いただくボードを用意しました。トイル削減・高速化といった実装観点の意見であったり、SREチームがほしい・リソースがほしいという組織的な観点が含んだ意見を記載いただけました。共感できることもたくさんあり、会話もさせていただきありがとうございました。ギフティのサービスを知っていただけている方が想像よりも多く嬉しかったのが印象的です。eギフト認知の高まりを感じました。

懇親会

Day1の夜は懇親会がありました。会場がTK NIGHTCLUBというクラブでした。が、正直私はビビってました。パリピ感すごそうでついていけるか…!?と…。 気合い入れて挑みましたが、結果楽しい会でした（笑）

多少密集する雰囲気はありましたが、会場自体はそれなりに広かったです。デカデカと映るけろぺんは圧巻でした。小さめのスタンディングテーブルで集う感じがこれまた密集感があり、疑似クラブ体験をした気分です（?）。

終わりに

SRE関連のカンファレンスへの参加は私も初めてでしたし、ギフティとしても初の出展でした。私個人としては、プロダクトマネジメント観点も必要であるという視点がとても大きな学びでした。また発表の中やブース・懇親会等でも話題に上がっていましたが、実際はプロダクト関係者との距離がありすぎると理解が得られないものが増えてしまうというのも重要な観点だと理解できました。多くの発表を通してとても勉強になりました！！

SREに対して熱い方がこんなにも集まれるカンファレンスの企画・運営をいただいた皆様、本当にありがとうございました！関わった全ての方々に感謝いたします。