今年から新たに始まったカンファレンス「SRE Kaigi」に参加してきました。参加費1000円でお弁当付き、実質無料やん。スポンサーの皆さまありがとうございます。
いつも通り印象に残ったセッションをだらだらと挙げていきますね。
目次
直接見たセッション
2週に1度のビッグバンリリースをデイリーリリース化するまでの苦悩
これをお読みになっている皆さんもビッグバンリリースのご経験が何かしらあるかと存じますが、一度それが普通になってしまった現場で「じゃあ次からデプロイ頻度上げていきましょう！」とするのはなかなか大変なんですよね。やればできるんですよ。できるんですけど、染みついた文化を変えていくのが大変で、そこも含めて大変だったんだろうなと思いながら聞いてました。あとスクショで貼られていたリリースの手順書がリアルすぎて苦笑い。こういうの見せてくれるのいいですね。
一番良かったのが「竹を割ったような美しいサービス分割からProject bambooと名付けました」ってところ。名前は大事だ！！皆さんもなんかいい感じのプロジェクト名をつけましょう。
2,500万ユーザーを支えるSREチームの6年間のスクラムのカイゼン
SREでスクラムとは？あんまり相性よくないと言われてるやつだけど上手くいってるのかなと気になって見に行きました。実際発表を見た感想としては、その「あんまり相性がよくない」の部分が実例と合わさってうまく言語化されている内容でした。
まずこれを見てくださいよ。
SREのステークホルダー誰、たしかに？#srekaigi#srekaigi_b
— karia (@karia2nd) 2025年1月26日
スクラム用語に関しては 5分で分かるスクラム用語集 | Ryuzee.com などを見て頂ければと思うのですが、SREチームでは直接プロダクトを開発しているわけではない場合がほとんどで、スクラム用語をSREチームに当てはめようとするとまず無理矢理当てはめている感が出てしまうんだよね。
それに関連してこういう悩みもある。
SREタスクってユーザーストーリーしにくいよね～～～～わかる#srekaigi#srekaigi_b
— karia (@karia2nd) 2025年1月26日
例えば「nginxをバージョンアップする」というタスクには「nginxをバージョンアップする」以上のストーリーはないわけです。「Railsをバージョンアップする」とか「MySQLをバージョンアップする」とかなら開発者をユーザーに見立てたストーリーは多少書けるかもしれないけど、それってユーザーストーリーって言うの？という疑問符がつく。そこを無理してユーザーストーリーにする必要はないんじゃないかなあというのは自分の実感としてもありました。「なぜEOL対応をやるのか」の言語化はしておいて良いとは思うけどね。
発表の結論としては改良した形で今も続いているということなので、そこはすごいなと思います。結局そのチームに合わせた形で改良していくしかないよな。
Platform EngineeringがあればSREはいらない!? 新時代のSREに求められる役割とは
Platform EngineeringとSREの関係とか役割を論じる発表はこれ以外にもあってかなりホットなトピックだと思います。その中でもセッションの時間がちょうどよかったこちらを聞きに行きました（最大3セッションが同時進行するタイムテーブルだったので、見たいセッションの被りが多すぎるんだよね……）。
一番印象的だったのはここでしょうか。
「Platformチームは提供するサービス・ツールを実際に使わない」#srekaigi #srekaigi_a
— karia (@karia2nd) 2025年1月26日
これ、プラットフォームチームとアプリケーション開発チームが分かれていることによる悩みだと思っていて、たとえばAWSなんかでも「実際に開発者としてこのプロダクトを使っていれば絶対●●の機能が欲しくなるはずなのに！」という機能がないという事はあるんですよね。でもアプリケーション開発者がプラットフォームを作るヒマはない。だから仲介者が必要だ、という理論はまあわかります。
ただ、それをSREと呼ぶのか？は議論があるところかと思います。SREの定義ってなんだっけ、という前提を考えながら取り組んでいかないと、ただの道具組み立て屋さん（もしくは昔ながらのインフラ作業者）で終わってしまいそうだよね。そういう意味では、領域からはみ出してプラットフォームチームにフィードバックを行う動きとか、実際にメルカリハロを9ヶ月でローンチした実績というのは素晴らしい事だと思います。
あと、production-readiness-checklistは知らなかったので知ることができて良かったな。
このチェック自体も自動化が進んでいるらしく良いですね。
資料だけ見たセッション
朝起きれず見られなかったセッションがいっぱいあったし時間が重複したセッションも多かった、ので、資料読みはあとから進めていきたい所存。このセクションは後ほど追記していきます。
実践: Database Reliability Engineering ~ クラウド時代のデータベースエンジニアの役割 ~
「ツール・カタログ一覧」のスライドがよくまとまってていいなあと。ツール1個を取ってもなぜやるのかがはっきり言語化されていて、これぐらい業務が整理・標準化されていたいですね。
あと、データベースにフォーカスした発表というのもSRE Kaigi（やSRE NEXT）の中でも珍しかったのではないかと思います。DBの安定化がサーバーサイドの安定化の鍵を握っていることは珍しいことではなく、重要なトピックだと思いました。
全体通しての感想
去年参加したSRE NEXTと比べてどう変わるかな、というところが気になっていたのですが、やはり同じ「SRE」というテーマを持ちつつもカンファレンスごとの色は出たかなという印象がありました。SRE NEXTは歴史もあるしキーノートもあるし、発表時間にもメリハリがあったりして、全体としてかなりカッチリしているイメージ。それに対してSRE Kaigiは30分枠のセッションがとにかくぎっしり詰め込まれていて、初年度ということもあってかバラエティに富んでいる感じがしました。
今回参加者が350人いたということで、やはりSREというのが注目度の高いトピックなのだと感じます。ここからどう広がっていくか楽しみですね。
