SRE Kaigi 2025に参加してきた

はじめに

2025年1月26日（日）にSRE Kaigi 2025という技術カンファレンスに参加してきました。その時に聞いたセッションのざっくり概要と備忘録のメモになります。

カンファレンス概要

SREのカンファレンスだとSRE NextやゆるSRE勉強会などがありますが、もっとSREについて話すカンファレンスがあったらいいということで今年初開催になりました。「More SRE」というテーマで、

• さらにSREに関わる技術者の活躍の場を増やすため
• さらにSREを理解し、興味を持っていただける技術者を増やすため

を目的に開催されました。閉会式での発表によると約350人の方が参加されたそうです。さらにはカンファレンス参加者が楽しめるように色々と用意されていました。おでん/たこ焼き/クレープなどの屋台や指圧体験が独特で面白い企画でした。

各セッションの印象に残ったことと感想

資料が公開されているセッションについては見出しをリンクにしています。途中引用記法を使っていますが、説明と自分の感想を分けるために使っているためで、スライドの文章と完全一致はしていません。ご了承ください。

Re 可用性を支えるモニタリング、パフォーマンス最適化、そしてセキュリティ

経験ある方のセッションを聞いて自分の業務の改善点を見つけようと思って本セッションを聴講しました。

定義やノウハウに対して私はこうしているというアンサーを込めてセッションタイトルにReがついているそうです。そのタイトルの通り、SREに必要な要素を網羅的に説明しつつ、P山さんのたくさんの経験をもとにこうするべきという説明でした。

足し算できるような運用をする

• 運用を育てる
• ベネフィットがあるなら出せ（100%のものではなく8割くらい動くものができたら出しちゃえ）

現代においてはクラウドの弾力性やスケーリングを踏まえると、セマンティック監視の重要度が高い

テレメトリデータがリンクしていることが重要

前職でオブザーバビリティをやっていたので激しく同意する説明でした。

時代はトレース、トレースもってこい！！

日々の調査のたびに不足している何かはある、それをそのままにせず計装する

まさにその通りで、頭の中でわかっているのにできていない自分にもどかしさを感じています。木こりのジレンマにならないように、今年はOpenTelemetryをきちんと勉強して社内に広めることを頑張ろうと改めて決意しました。

SREの取り組みを組織的なものにする 可用性の担保はSREだけでなく、開発者や管理者を責任を持つべき

確かに自分が支援として入っているプロダクトで開発者にうまく意識させることができていないなと感じました。チームの定例ミーティングでダッシュボードを見るといったのは確かにいいなと思ったので、次回の定例で提案してみようと思います。

ノイジーアラートになりがちなため、機械学習などで解決する

これはセキュリティの異常検知の文脈で説明されていた言葉です。私も心当たりのあるアラートがあり、正常か異常か判断がつかないので安全をとってアラートをあげて少しノイジーになっています。やらないとと思った時に勉強しないとだと思うので、機械学習を学習項目に追加しました。

障害対応には矜持がある

• 障害対応に対して責任を持ち、早急に根本対応を実施する必要がある

耳が痛いです...もちろん責任を持って対応をしますが、自分でわからないところを他人に任せたり、最後はPMに任せたりとしている時もあるなあと。障害対応は経験も重要で積極的に関わって自分の糧にしていかないといけないと他のセッションも通して痛感する1日でした。

最後にSREの醍醐味について、「やることが多いが、それが面白い」と説明されていました。「全部やればええやろ」に尽きるのかなと。SREの業務の中で、知らなかったことに積極的に関わりシステムのさまざまを理解し実践できるようになるのが面白いと感じています。やることや方針は間違っていなくて、思っていても実践できていないことを改めて気付かせるセッションでした。

一人から始めたSREチーム3年間の歩み -求められるスキルの変化とチームのあり方-

私の所属するSREチームの現在地を知り、将来どのようなことが必要になってくるのか考えるために本セッションを聴講しました。

• 1人目のSRE期
  • 体制はEmbedded SRE
  • 浅く広い知識が必要
  • SREを布教するフェーズ、後で読み直せるように資料を書きまくる
  • 現場が疲弊しているところのアラートから設計を見直す
  • 早めにミッションやバリューを作る
• チーム拡大期
  • 体制はEnableing SRE
  • 前期に加えて、チームビルディングなどのスキルが必要
  • 1人1プロダクト以上を持ち、大変
  • 1人に依存しているので休むと稼働がなくなるが、網羅率を上げることを重視
  • アプローチ方法や解決の方針はミッションによって変わるのでミッションが重要
  • プロダクトごとの課題でバラバラで、他の人に知見を還元できてなく、チームとしての最大化できていない
• チーム安定期
  • ロードマップがちゃんと進む
  • 体制はEnabling SRE
  • 高い専門性や長期視点での問題解決力が必要になる
  • 経験が浅い領域にチャレンジできるし、経験があるメンバーがサポートできる
  • オンボーディングフローを向上できた
  • 繰り返しを回避するためのツール群を開発（DBのアップグレードなど）
  • ポストモーテムのロールプレイ研修
  • プロダクトチームとの関係性が希薄になるという課題が発生し、関係を維持するため定例をする
    • 相互情報の交換
    • メトリクスレポート
    • プロダクトからはリリースや懸念情報

期待通り、各フェーズでどのようなことが必要になり、どのような課題が発生するのかを聞くことができました。 チーム拡大期のやっていることや課題にとても共感したので、私の職場は拡大期の後期くらいなのかと思いました。 ただ、この事例に比べてミッションが薄い気がするのでミッションについて改めてしっかりとしたものにしたいと感じました。

また、自分が最も輝く場所はどこかというのを考える視点をいただけました。この機会に考えてみると、浅く広くタイプなのと仕組みを作っていくのが好きなので拡大期が自分にはあっているのだろうなと。

もっとSREの裾野を広げるための初学者向け技術研修設計

今の職場では中途採用しかしていないため新人にSREを教える機会がなく、いざその立場になった時にどうすればいいのかという知見が欲しく聴講しました。

• SREに求められるスキルの幅広さ
• SREロールの固定化、特定の人がやってしまうのでプラクティスが広がりづらい
• SREスキルの学習機会が少ない
  • OJTでは学習が起こるタイミングが偶然に依存する
  • SREが成熟するに伴い、簡単な課題が発生する確率が下がる

SREスキル習得の課題はまさにその通りで、私自身も現場でやっていくうちに次第にSREの素養が身に付いたので、新人はどうやって学習するのだろうと思っていたところでした。

GMOペパボの新卒研修

• コンテナ研修（幅広くやってインデックスを貼ってもらう）
• オブザーバビリティ研修（コンテナ研修で作った基盤のテレメトリーを取得）
• パフォーマンスチューニング実践

前職でも研修設計をしたこともあり、やはり研修として企画するのはここらへんになりますよね。 パフォーマンスチューニングのところで、CTO協会主催の模擬ISUCONやprivate-isuはいい題材だなと思ったので参考にさせていただきます。

意識していたこと

• 座学は一瞬、ほとんどの時間は実践。必要な知識は文書化しておいておく、アウトプットすることを重視
• 背景を知って、手を動かしてHowを取得して、再度Whyを問う

設計に含めたい視点を考え、それを盛り込んでいて素晴らしいなと思いました。特に2つ目の再度Whyを問うというのが忘れがちです。

オンボーディング時

• ハンズオン
  • 検証環境で叩いてみる
• ポストモーテム
  • システムへの理解を深めるチャンス
• プレモーテム
  • 障害を想定して対応を考えてみる（過去のポストモーテムも参考に）

個人的に効果的だった教材

• SRE サイトリライアビリティエンジニアリングが”ザックリ”「すっきり」分かる本
• ワークショップ：「The art of SLOs」
• 自宅サーバー

この2つは私がいざオンボーディングで新人に教えることになった時のメモです。

期待通り、新人に教える観点を得られました。スピーカーの方はお若いのに、技術的にも教えることにも知見が深くとても参考になりました。 あとはペパボさんは研修が充実していて組織的に人材を育成する環境がきちんとできていることに感心するばかりでした。 今の職場ではこの知見を使う機会はまだありませんが、成長していくと人材成長を整えることは必須なので、その際にまた参考にさせていただきます。

どうやればインシデント対応能力を鍛えられるのか？

CloudNative Daysの実行委員会でもお世話になったことのある高石さんのセッション。SREをやっているとインシデント対応はつきもの。自分に足りないところを探すために聴講しました。

• インシデント対応は総合競技
• ハードスキル・ソフトスキル・経験・システム理解の掛け算
  • ハードスキル: 個人が持つ技術・知識・ノウハウ
  • ソフトスキル: コミュニケーション
  • 対応経験
  • システム理解
• 実際のトラブルだけで経験を積むのは難しいので擬似的に学習する
  • シャドーイング: 経験豊富なメンバを観察して学ぶ
  • 障害対応訓練: 開発やステージングで意図的に障害を発生させて対応の経験を積む
  • Hardening Project
  • ISUCON

必要なスキルについてわかりやすく分析されていました。やっぱり自分の課題は対応経験であることを痛感しました。 以前、障害が発生した時に開発者任せにしてしまいました...障害の経験できる機会は確かに減っているので、、開発者の人に任せず自分がリーダーで最後まで責任持って対応していればと悔やまれます。 擬似的な学習を参考にしつつ、もっと経験をつめるように気を引き締めました。

インフラおじさんがSREになる話

開発の方にSREをやってもらうのはどうしたいいのかのヒントを得たくて聴講しました。

• SREチームがインフラチームのようになったことを問題とした
  • 2年前、SREは存在はしていたが、横断的な組織だった
  • インフラとモニタリングの運用管理がメインになっていた
  • SREに任せることで開発部で解決できないことがどんどん増えてきた
  • インフラの管理状況やモニタリングがチームによって差があった
• 解決方法として、Embedded SREとして各チームをSREが支援する体制をとった
  • 長期的なSRE活動のロードマップの決定
  • 文化や役割について勉強会をして各チームで理解を深めてもらう
  • やることは、IaC化やモニタリングの整備などインフラが多い
  • アプリケーションチームから人員を選出
    • アプリの認知負荷の高さを考慮
    • アプリ担当の方が誤認識されていた経験を伝授しやすい
  • モニタリング体制の整備
    • アラートの整理
    • ダッシュボードの整備
    • メトリクス確認回
  • SREの実践をするという目的を持つことで自然とSREっぽいことをすることができるようになった
  • ひとまず開発のベースラインが揃った
• レバテック事業部独自のSREチーム発足
  • インフラの運用を開発へ
    • 相談が来たら一緒にやるという体制に、ペアプロやモブプロによるEnablingへ
  • インシデント対応の共通化
    • 障害報告ワークフローを実行し、手順通り進めるだけの仕組みを作る
    • インシデントレベルの基準の明確化
    • 各チームでポストモーテムをきちんと実施する
  • モニタリングからo11yへ
    • DatadogからNewRelicへ移行
  • 社内で勉強会を開いて障害対応訓練
• 現在の取り組み
  • RDSからTiDBへ移行
    • RDSだとクラスタが多く管理効率が悪い
    • DDLの反映などメンテナンスが必要となるケースが多い
    • ほぼ全てのRDSをTiDBへ
  • クエリチューニングに対する課題
    • 本番相当のテストデータ環境が存在しない
    • 本番相当のデータ量を保持したDBを複製するシステムを構築中
• 現状の課題
  • AWSの管理上の課題により開発チームだけで判断が難しい要素がある
  • シングルアカウントによる弊害
  • o11yを導入したがノイズアラートが多い
• 今後の取り組み
  • マルチアカウント化
  • ガイドラインの策定

組織的にも大きいのに2年間でここまで変えられる速さに驚きました。 私の現職でも同じような課題にぶち当たるのが目に見えているので、説明されていた取り組みをぜひ参考にさせていただきます。開発の人に実践させないとやばいな...

2,000万ユーザーを支えるSREチームの6年間のスクラムのカイゼン

前職でスクラムでSREを実践していて相性が悪いかもなあとモヤモヤしていました。そのモヤモヤを明確にしたいというのと、どう解決しているのか気になって聴講しました。

• みてねのSREチーム
  • 独立チームで支援するSRE
  • 個人ごとに1バックログを持つ、個人ごとにやっているのでスプリントバックログもないし、分割もやってない
• SREのスクラムの難しさ
  • Alert対応と問い合わせ対応や他チームとの連携でSprint計画時に建てた計画を何も全うできない
  • SREのタスクはユーザーストーリーにしにくい
    • 単純な問い合わせやEKSのアップグレードなどユーザストーリーの粒度がバラバラ
    • 個人個人が大きいタスクを持った時点で止まる
    • 問い合わせなどもなんとなく属人的になる、暗黙のアサイン
  • 中長期目標が描きづらい
    • 気がついたらアップグレードばかりしている
• みてねのSREでの対応
  • 差し込みが多い対策
    • 差し込み業務はあるものと割り切る
    • ベロシティを計測しない
    • スプリントゴールを設定しない
  • バックログがわんぱくになる対策
    • バックログで管理するものとその他を切り分ける
    • HOWがわかっている差し込み業務はTODOリストとしてGithub Issueで管理
    • 属人化する恐れのあるもののみバックログで管理
  • 中長期の目標が描きづらい対策
    • スプリントからの積み上げを常に意識する

目的通り、自分の中のモヤモヤを明確にしてくれるとても良いセッションでした。 課題の分析も納得でした。差し込みやストーリーの粒度の件については共感しかありませんでした。 対応策もスプレッドシートやGithub Issueとよくあるツールで対応しているので真似できそうです。

今回のセッションでは対象外にしていますが、Embedded SRE としてスクラムに入った時のSREのタスク管理はどうするのかなあとも聞いていて思いました。 リリースまでに求められるのはどうしても機能ばかりになって、SREとしてよく扱う非機能は後回しになったり、バックログが大きくなりそうです。 今回みたいにバックログで管理しない方がいいんですかね。SREの課題管理のセッションを別の事例で聞いていつか解決したいです。

SREとしてスタッフエンジニアを目指す

スタッフエンジニアをちゃんと理解したいのとキャリアの参考になると思い、聴講しました。

スタッフエンジニアとは

• 組織全体の技術成功をリードする技術職
• マネジメントではなく、技術的なリーダーシップを担う

恥ずかしながらスタッフエンジニアというワードを初めて知りました。なので紹介されていた「スタッフエンジニア　マネジメントを超えるリーダーシップ」を早速購入しました。読書日記に書きたいですね。

コードを書いたり手を動かす時間は減るが、影響力やより重要な問題に取り組める

スタッフエンジニアは技術的な方向性を示すのに対し、エンジニアリングマネージャーはチームの人材育成や評価などに取り組む

SREのリーダーをやっていれば、組織全体に関わるプロジェクトをリードすることになるので、自動的にスタッフエンジニアになるのでは？

SREを突き詰めた先はどうなるのか？と思っていたので、新しい道を教えてもらった気になりました。 一方で、まだスタッフエンジニアの職を用意している企業は少ないので、エンジニアリングマネージャーと兼務していく形になる企業が多いのかなと思いました。

• SREとしての技術的成長
  • まずはシステム全体を見渡して幅広い知識を身につけつつ得意領域を見つける
• 影響力の拡大
  • ちょっとずつチームからはみ出して影響力を
• リーダーシップの発揮
  • 先頭に立つと自分の成長も加速する
• マインドセット
  • システムの信頼性のオーナーとしての意識を持つ

ある程度できているのかなと思いつつ、マインドセットで説明されていた組織に浸透させるということがまだ自分はできていないと思いました。 多分自分が次のステップに進むためには、個人ではなく、組織の文化を作る活動が必要だと今までのセッションを聞いていて感じました。 引用はしませんでしたが、レビューでなぜを聞くというのも参考になりました。最近レビューする機会が増えてきたので、レビュアーとして成長するために意識するようにします。

自分のキャリア、悩ましいですね...でも選択肢を狭めないためにもこのセッションを聞けて、スタッフエンジニアのことを知った気になれてよかったです。 もう少し本を読んで自分なりに理解を深めて、自分のキャリアを改めて考え直そうかと思うセッションでした。 でも、エンジニアリングマネージャーとしてチームビルディングとかもやってみたいんだよな...

あなたの興味は信頼性？それとも生産性？ SREとしてのキャリアに悩むみなさまに伝えたい選択肢

CloudNative Days でもお世話になったjacopenさんのセッションです。 このセッションはまとめ方が難しかったので箇条書きメモになりました...

• なんちゃってSREはXでも結構話題になっていましたね笑
• 何かするから障害が起きる。障害のほとんどはデプロイ時に起きる
  • 引用されていた「エレガントパズル」も積本です...読まないと
• 左から右がPlatform Engineering, 右から左がSRE, なるほどなあ
• AIなどある技術が流行った時、SREに求められることを考えることは重要
  • cline, devin, boltなどのAIエージェントを触る

最後の流行りの時にSREに求められることを考えることは重要というのは自分にない観点だったので、ハッとしました。 どうしてもミーハーになりたくないのか、流行りにすぐ乗ろうとしないんですよね... 技術者としては触ってどんな感じのものかだけでも体感しておかないといけないし、フットワーク軽く対応しないといけないですよね。 紹介されていたAIエージェントを触ることを目標に追加しました。

聞けなかったけど気になるセッション

以上、長文になってしまいましたが、私が聞いたセッションのメモでした。ただ、セッション重なっていて聞きたかったけど聞けなかったセッションが何個もありました。

ありがたい話、こちらで公開されているスライドをまとめてくれています。ここに書くとさらに長文になるので、別の記事で書こうと思います。

• 信頼性を支えるテレメトリーパイプラインの構築
• 実践: Database Reliability Engineering ~ クラウド時代のデータベースエンジニアの役割 ~
• インフラコストとセキュリティ課題解決のためのリアーキテクチャリング
• Platform EngineeringがあればSREはいらない!? 新時代のSREに求められる役割とは
• Improving Incident Response using Incident Key Metrics

全体の所感

共感したり、この対応参考になる！と思ったことが山盛りの会議でとても勉強になる1日でした。数年前は、SREの会議を聞いてもふーんで終わることが多かったので、自分が色々と経験したということなんですかね。

また、今年初開催にも関わらず、運営でごたついている様子もなく、宣伝やCMもしっかり準備され、さらには屋台でおでん/たこ焼き/クレープを無料で配っていたりといろいろな企画を用意していました。準備してくださったスタッフの皆様ありがとうございました。私もいつかスタッフ側に回って、コミュニティを広げつつ、SREの発展に貢献できたらと思います。

長文にも関わらず、最後まで読んでいただきありがとうございました。