オフラインでは 2020 年以来 3 年ぶりの参加でした。
参加セッションは以下のとおりでした（個別のコメントは省略）。
- 【A】ギークがイオンに飛び込んだ結果がやばい〜 Reliability と経営〜
- 【C】LINE スタンプの SREing 事例集：大量のスパイクアクセスを捌くための SREing
- 【C】備えあれば患いなし：効率的なインシデント対応を目指す SRE の取り組み
- 【B】プラットフォーム SRE による脆弱性対策を意識したコンテナビルドフロー構築
- 【A】【コミュニティコラボ企画】パネルディスカッション 〜信頼性に関わる、ご近所さんが集まりました〜
- 【B】SIEM を用いて、セキュリティログの可視化と分析を実現し、PDCA サイクルを回してみた
- 【B】SRE を以てセキュリティエンジニアリングを制す ― class Dev"Sec"Ops の実装に向けて
- 【B】増え続ける公開アプリケーションへの悪意あるアクセス。多層防御を取り入れる SRE 活動。
- 【C】SRE の組織類型に応じたリーダーシップの考察
- 【A】Runbook に何を書き、どのようにアラートを振り分けるか？
- 【A】Yahoo! ショッピング商品管理システムにおける、問い合わせ駆動の信頼性向上の取り組み
- 【A】信頼性目標とシステムアーキテクチャー
今回強く感じたのは、2 つの意味での「世代交代」でした。
といっても、中心的な運営メンバーや登壇者の皆さんの顔ぶれが変わったという意味ではなくて、どちらかというと参加者の側の話なのですが。
まずは、ストレートに「年代」「年齢層」という意味での世代交代。
#srenext 懇親会、意外と見知った顔がいないなと思ったけどこれは多分いいこと(若者多い)、声を掛けてくれる人がいると自分のOSSのユーザーさんだったりしてこれも大変ありがたいこと。ありがとうございました！
— fujiwara (@fujiwara) 2023年9月29日
同じく（OSS 作ってないから声をかけられることはなかったですが）。
17時時点でもエンジニア歴25年が最長(最年長)だったらしいけどほんとかな、サバ読んでない?? #srenext https://t.co/qhgjJ9ymam
— fujiwara (@fujiwara) 2023年9月29日
すみませんでした。わたしが嘘をついておりました。
よく考えたら25年超えてた（しまった）。#srenext https://t.co/PBfZhUzSJN
— hmatsu47(まつ) (@hmatsu47) 2023年9月29日
「なんちゃって」含めて「SRE 歴 5 年」は嘘ではなかったのですが、SRE 以外を含め 27 年ほど経過しておりました。
もっとも、
わたし無意識にサバ読んで20年あたりに貼りました
— ばば としあき (@netmarkjp) 2023年9月29日
（実際は23年くらい）
馬場さんの例を見ても「20 年超えたらざっくり 5 年刻みで把握」説が。
いずれにせよ、藤原さんがおっしゃるように「見知った顔が少ない（＝常連客だけで固定化されていない）」「若者が多い」というのは良いことですね。
もう一つは「インフラエンジニア＝ SRE」世代から「SRE ネイティブ」な世代へ、という意味の世代交代です。
数年前までは主に採用を意識して「インフラチームから看板を架け替えただけの SRE チーム」が多かった気がするのですが、SRE NEXT では（いつの間にか？）そういう層が目立たなくなった感があります。
ﾍｰｼｬの場合、チーム結成の経緯の関係で「信頼性」の部分が「インフラ」になってしまっている部分がまだまだ大きいな。#srenext #srenext_c
— hmatsu47(まつ) (@hmatsu47) 2023年9月29日
↑これは、
- 【C】SRE の組織類型に応じたリーダーシップの考察
を聞いていたときのポストです。
（開発組織への実装を支援する対象が「信頼性」じゃなくて「インフラ」になってしまっている、という話）
全く共感されませんでしたが、共感されなかったのはそういうことだと思います。
（もちろんそれだけではなくて、会場で「他所の勉強会でよく見かけるインフラ寄りの人たちをあまり見かけなかった」という点もあわせて）
そんな「世代交代」ですが、まだ「インフラ」色が強い自社でも着々と進行中です。
2020 の参加記録（ブログ）を読み返してみました。
- SRE に限らず、少人数組織で「1 人が先に走ってワザを身に着ける」スタイルでやっていくと、2 人目以降との「圧倒的な差」が「溝」となってかえってチーム化が難しくなる問題。これをどう解決するのか、自分の中では答えが出ていない（「放任しても勝手に伸びる人」が入ってくるのを待つしかないのか…）。
- たとえ数年程度でも、ある程度「歴史」があって力量のあるメンバーがいると、その人たち頼みでトラブル対応がうまく回ってしまい、かえって仕組化が遅れる問題。↑で挙げた「2 人目がなかなか出て来ない」問題に通ずるものが。「結果だけ見ていてはいけない」典型例か。
このあたりは新しいメンバーの加入によって解決が進んできています。
もちろん、新しいメンバーが個人で抱え込まないように、注意しながら見守っていく必要はあります。
- セキュリティも幅広い知見とサービス各層への関与が必要な分野なので、やっぱり SRE が取り組むべき、となってくるのかな…（なんとなく予感はしていた）。
ここについては間違いなくそういう流れになってきています。
油断してるといつの間にかセキュリティがSREのお仕事になっているケースは割とありそう（うちもそう）。#srenext #srenext_b
— hmatsu47(まつ) (@hmatsu47) 2023年9月29日
そんなこともあって、今回 12 セッション中 5 セッション、セキュリティ関連を選択して話を聞きました。
このあたり、3 年前はわたしが個人で当たらないといけなくて苦労していたのですが、今は SRE チームのリーダーが先頭に立って進めてくれているので、ずいぶん楽になりました。
とはいえ、「セキュリティー＝ SRE の仕事」となるのは良くなくて、あくまでも
が対等な立場で協力しながらセキュリティーを高めていく必要があります。
セッション終了後、いずれも登壇された LINE の maru さん、ヤフーの吉冨さんと DB のマイグレーションについて立ち話をしていました。
詳細は書きませんが、マイグレーションの進め方についてお二人とも同じような見解をお持ちだったのが印象的でした（そしてそれについてはわたしも同意見）。
「判断と実行の責任を持つこと」の意味を考えさせられる話でした。
また、
懇親会の別の集団で全く同じ話をした。一応今回は、泥臭い作業（ヒアリングとか）の話も省かなかったけれど、やっぱりキラキラアピールは憧れますよね。
— maru621 (@maruloop) 2023年9月29日
ちなみに私は、本当にイケてない失敗系はゆるSRE会で話そうと考えてます。 https://t.co/7RY7RXMwzb
同じ「SRE」でも色々な切り口のイベントや勉強会があって良い（あったほうが良い）んだろうな、というのも、閉会後の X（Twitter）の TL を眺めながら感じた一日でした。
ありがとうございました。
