2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

新卒2年目SREが行く SRE NEXT 2025 参加レポート(Day1)

Last updated at Posted at 2025-09-03

はじめに

初めまして、新卒2年目SREの🦊です。
時が経つのは早いもので、内定者アルバイト期間を含めると、会社に在籍して丸2年になりました。

2025年7月11日〜12日に開催されたSRE NEXT 2025に参加しましたので、本記事ではDay1の参加レポートをお届けします。気づけば、9月になってしまいました...。

実は2023年のSRE NEXTにも参加していましたが、今回は会場の雰囲気やスポンサーブースの規模が格段に大きくなっており、イベントの圧倒的な成長を感じました。すごい。

会場の様子

セッション聴講とブース巡りに集中していたため、会場の写真を撮り忘れてしまいました。

image.png

お弁当

会場では美味しいお弁当が配布されました。

image.png

企業ブース

企業ブースでは、ノベルティの配布や企業エンジニアの方々との気軽な交流ができます。写真には写っていませんが、多くのブースを回った結果、かなりの量のノベルティをいただきました。

特に印象的だったのは、各企業で興味深いサービスを運営している方々に直接話を聞けたり、AI機能のデモを体験できたりしたことです。サービスのアーキテクチャや今後の動向、市場ニーズについても質問でき、普段とは異なる視点でのディスカッションを楽しめました。

image.png

負荷試験に関する課題相談

今回の私の裏テーマとして、各企業の負荷試験に対する取り組みについて質問させていただきました。

弊社では、マイクロサービスの新規機能リリース時に負荷障害試験を実施していますが、その作業工数が大きく課題を感じていました。そこで、他社ではリリース前にどのような試験を実施し、どのような判断をしているのかを伺いました。

多くの企業では、サービス負荷の問題が少ない場合やtoBサービスのようにトラフィックが予測しやすい場合は、リリース速度を優先して試験を最小限に抑える工夫をしているとのことでした。

弊社はtoCサービスを提供しており、セールや曜日・時間帯によってトラフィックは変動しますが、ある程度の予測は可能です。これらを踏まえて、チーム・部内での実施要否のガイドラインを再整備する良いきっかけになりました。

弊社の負荷試験については、以下の記事が参考になります。

セッションレポート

今回のメインイベントであるセッションでは、現在の業務に関連しそうな内容を中心に聴講しました。本記事では、いくつかの聴講したセッションから抜粋してレポートを書かせていただきます。

image.png

SRE へのサポートケースをAIに管理させる方法

発表者: Ubie株式会社 guniさん

Ubieでは、SREへの月100件以上の問い合わせによる稼働圧迫と、本質的課題への注力不足が課題となっていました。これを解決するため、GKE上で動作するAIを活用した社内サポートシステムを開発したとのことです。

このシステムの主な機能は以下の通りです:

  • AIによる問い合わせの一次回答
  • チケットの優先度判定
  • SREへの自動アサイン

SREが作成した社内ドキュメントを学習させることで、Ubie独自のインフラ知識に基づいた回答を提供できるようになりました。これにより、プロダクトチームの自己解決が促進され、SREはより複雑で時間のかかるタスクに集中できるようになったとのことです。また、手動でのチケット管理のオーバーヘッドも削減され、インフラ関連の問い合わせ経路も統一されました。

興味深い点として、結果的に問い合わせの件数と解決にかかる時間は増加したそうです。しかし、これは本質的な課題に取り組めるようになったための増加とのことでした。

弊社でも、CSチームやインフラに関する問い合わせが日々発生しており、少なくない工数が必要になっています。全社的なAI活用の波が広がる中、チームとしてのAI活用による効率化はまだ十分に取り組めていない現状があるため、このセッションを機に積極的に活用していきたいと思いました。

アーカイブ動画:

複雑なシステムにおけるUser Journey SLOの導入

発表者: 株式会社メルカリ 土屋さん

メルカリでは、数百のマイクロサービスで構成される複雑なシステムにおいて、障害発生時の顧客への影響範囲特定が困難という課題を抱えていました。この課題に対し、顧客目線でのサービス信頼性指標としてCritical User Journey (CUJ) SLOを導入したとのことです。

CUJは、ユーザーのコア機能に不可欠な「クリティカルなAPI」を特定し、シンプルなSLIとして定義することで実現されました。その特定には、プロキシを用いた自動化された障害テストが活用され、Terraformによるコード管理でSLOやダッシュボードの自動生成・更新が可能とのことです。

これにより、障害発生時に影響しているCUJを迅速に特定し、SREや開発チームが効率的に対応できるようになりました。

弊社でも大規模なマイクロサービス基盤を有しており、影響範囲の特定や重要な機能が障害になった際のユーザー影響の特定が困難という同様の課題があります。また、マイクロサービス単位でのSLOは定義されているものの、十分に活用しきれていないという課題感もありました。

ユーザージャーニーを用いたSLOであれば即座にユーザー影響を特定できるという内容は非常に参考になり、参加後にチーム内でも話題に上げて議論することができました。

アーカイブ動画:

終わりに

SRE NEXT 2025はDay1のみのオフライン参加でしたが、終始有意義な時間でした。AWSやKubernetesに関する勉強会とは異なり、「SREとは何か?」「SREとして組織やビジネスにどのような良い影響を与えることができるのか?」といった本質的な部分について改めてインプットし、整理することができるイベントでした。

今回得た知見を活かして、チームでの取り組みをより良いものにしていきたいと思います。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?