SRE Kaigi 2025 に行ってきました。
イベントの概要
SRE Kaigi 2025は、「More SRE !」をテーマに開催される、SREを中心として知見の共有と参加者との交流を楽しむ技術カンファレンスです。
SREは世界的に注目され続けている領域であり、現場によって抱える課題や取り組みはそれぞれ異なります。
そうした多様な事例から得られた知見を共有する場は、まだまだ不足している現状です。「さらにSREに関わる技術者の活躍の場を増やすため」
「さらにSREを理解し、興味を持っていただける技術者を増やすため」この2つの“More”を目指し、参加者の皆様とコミュニティをより盛り上げていけたらと思います。
引用：
イベント参加の背景
・SREについて『SREをはじめよう』を読んだばかりの初学者。
・プロダクト開発における重要な役割とは理解しており、もっと解像度上げて理解したい。
・そもそもイベント自体が面白そう！！
事前情報
少し前のツナギメエフエムも楽しかったです。
持ち帰るところの多かったセッションメモ
気になるセッションが多すぎて朝１から行ってきました。
- SRE, 開発, QAが協業して挑んだリリースプロセス改革
speakerdeck.comプロダクトをグロースさせていくためには、高頻度で安定したリリースが重要。
そのために以下を実現。
・ゼロダウンタイムでのリリースを実現。（条件の明瞭化）
・DBマイグレーションリハーサル（必要な時間を計測して判断可能な状態に）
・Feature環境の導入（PRトリガーで作成、自動削除）
・開発DBの複製の自動化（PR単位の専用DB）
・テストでの本番データ利用（PR起因でマスキング、NWFirewallによる通信遮断）
・パラレルテスト（スクリプトテスト＋探索的テストの並走）の導入
・リリーストグルの運用改善（トグル状態の見える化・不要なトグルの通知）
結果、毎日複数回リリースできる状態に。変更障害率40%=>10%に低減 - 一人から始めたSREチーム3年間の歩み -求められるスキルの変化とチームのあり方-
マネーフォワードのSRE
SREチーム３つとPlatformチームがある。
３年前に１人目としてJOIN。最初はプロダクトチーム内でSRE１人。
布教から開始。SRヒエラルキー等をもとに共通の認知を獲得。
MVの作成。
チーム拡大期。チームビルディング。評価など行う。
因子からチームに。１人１プロダクト以上。
ミッション大事。アプローチ方法や解決の方針はミッションによって変わる。
Embedded体制からEnabling体制に。
チーム安定期。ロードマップが計画通りに。
より高い専門性を持つリーダーが各チームをけん引する形に。
オンボーディングフローの向上。
CLI等ツール群開発。将来問題となる課題に対するアプローチ。
プロダクトチームとの関係が希薄になる課題。SREチームは作業を受ける形に。
プロダクションミーティングの定期開催で解消のアプローチ。
言葉でのやり取りだけでは文化として残らない。仕組化必要。
３年で変わったこと。
ミッション、ロードマップは変えない。
体制・スキルセット変わる。やり方は柔軟に変える。
各フェーズでの活躍が得意な人同士で有機的な相乗効果が埋める状態を作る。 - もっとSREの裾野を広げるための初学者向け技術研修設計
ソフトウェアが広げる：監視ツール など
人が広げる：文化、思想、ソフトウェア など ←こっちのはなし。
SREスキル習得の課題。
・SREに求められることが多すぎてハードル高い。
・依存化が高く、組織化されない。
・学習機会が少ない。OJTは偶然に依存する。
これらを解消するために研修を利用する。
GMOペパポの研修の狙い。
・組織社会化。
・技術・文化の組織への浸透。
具体的な内容
・コンテナ研修
・オブザーバビリティ研修（社内ツールに揃える）
・パフォーマンスチューニング実績（日本CTO協会主催）
重視している部分。
・座学と実践のバランス
座学は一瞬、ほとんどの時間は実践。
当タイミングまでに基礎知識は習得済み。ぺパポは実践重視。
・HOWとWHY
まずは技術のモチベ導入、技術の腹落ちのためのWHY。
効果的だった教材。
・SRE サイトリライアビリティエンジニアリングが”ザックリ”「すっきり」分かる本: Googleが実践している新DevOps方法論
・The Art of SLOs
・自宅サーバー - どうやればインシデント対応能力を鍛えられるのか？
・インシデント対応能力とは？
ユーザーのサービス利用に影響のあるもの。
・対応能力とは？
ユーザーのサービス利用への影響を最小限に抑え、信頼性を維持する能力。
・ハードスキル
基礎要素。時間をかけて習得する。
個人が持つ知識、技術、技能、ノウハウなど。
使える道具が多い方が良いが、恒久的に使える道具はない。
関わるシステム次第で必要な技術は変わる。
可搬性が高い道具はある。
DB、言語・FW、Linuxオペレーション、ターミナルオペレーションなど。
・ソフトスキル
対人寄りのスキル。可搬性は高く、寿命は長い。
チーム内外とのコミュニケーション。
役割の明瞭化。声かけ・ファシリテーション。情報の一元管理。
リーダーシップ・判断・決断。
一部ソフトウェアでも代替は可能。
・経験
過去のインシデント対応経験の量。
周辺技術の進化によりそもそもトラブルが発生しづらくなっている。
結果、発生するトラブルは難易度が高いものになっている。
疑似経験でも学習はできる。シャドーイング、障害対応訓練、イベント（Hardening Project、ISUCON）。
・システム理解
アーキテクチャ、システム構成、コード、設計、DB、ドメイン、過去の経緯など。
外側からのアプローチ、内側からのアプローチがある。どちらも大事。
個人・組織の両輪で進める必要がある。 - Improving Incident Response using Incident Key Metrics
・MTTR（平均復旧時間）の問題点
TTRを短縮してもMTTRが短縮されない。
インシデントデータ。大半はかなり早く収束。
一部は悲惨なインシデント（ブラックスワンイベント）になる。
結果、後者に引きずられ、改善の指標としては役立たない。
何が問題だったか。
目的と指標がかみ合っていないことが問題。
改善箇所を明らかにし、変動性を抑える。
問の具体化とメトリクスの細分化をする。
・実績的なTTXメトリクス
網羅的であること、粒度が細かいこと、収集が現実的であること
定義のながれ
ベストプラクティスを学ぶ⇒おおまかにステータスを定義
⇒ベストプラクティスをもとに網羅性を高める⇒マイルストーンを定義
⇒マイルストーンを基にTTXを定義する⇒メトリクスを自動収集する
・発展的なメトリクス
インシデント対応にはサービス復旧以外に人への配慮など重要なことがある。 - 2,000万ユーザーを支えるSREチームの6年間のスクラムのカイゼン
みてねは９年の歴史。SREは６年の歴史。
みてねのSREはEmbeddedではなく独立チーム。
・スクラムうまくいかなかった件
１週間スプリントで各種スクラムイベントを実施。
個人ごとに１バックログ。
スプリントゴール未設定。レトロスペクティブはKPT。
差し込みタスクが多く計画通りの作業できない。
他チームとの連携で中断が発生する。
バックログがわんぱくになる。課題とタスクが混在。中長期が描きづらい。
大きいポイントでは人が止まり、属人化が発生する。
・みてねSREの対応
差し込みが多い⇒コントロール難しくある程度受け入れる必要あり。
結果、プラン通りに終わらせられない。ベロシティ安定しない。スプリントゴール満たせない。
けど、価値提供には影響しない。なので受け入れる。
ベロシティ⇒計測しない。
マーケットプレッシャー少なく、安定は他より求められない。
バックログ⇒HOWの分かり切ったものは別途TODOリストを用意。
課題ベースで書きたいが実業務と合わない。
中長期描きづらい⇒スプリントからの積み上げを意識。
スクラムとの親和性。
・現在のスクラム
リファインメント⇒都度バックログに入れるものとTODOリストに入れるものを判断。
プランニング⇒１か月単位に変更。
レビュー⇒価値ベースでの共有に。
レトロスペクティブ⇒１週間単位だけでなく、俯瞰したスクラムに対するふりかえりも実施。 - Platform EngineeringがあればSREはいらない!? 新時代のSREに求められる役割とは
Platform Engineeringとは？
開発者のエクスペリエンスと生産性を向上。
メルカリでは2018年頃から導入。
SREにとってもPlatformにより仕事のやり方・道具が変わった。
本番環境の民主化が発生。開発チームがPlatformの助けを得てサービス運用開始。
Platform Engineeringの課題に対してSREがアプローチ。
新サービス（ハロ）の爆速立ち上げにPlatform Engineeringが貢献。
インフラ系、ドキュメント類。
Platform自体に対する知識・経験が必要で課題があった。
・ツール・サービスが多岐に渡るため認知負荷が大きい。
・サービスチームとPlatformの距離感。
結果、サービスチームの生産性が上がらない。
Platformとサービスチームの橋渡しのためSREが貢献。
Platform EngineeringにSREはどうかかわっていくのが良いか。
Platformの補助役ではなく、非機能を中心にプロダクトの健全性をカバーしていく。
Platformのカバーする領域が拡張していっても、大きくは変わらない。
共にReliabilityを実装できるPlatformを実現していく。 - あなたの興味は信頼性？それとも生産性？ SREとしてのキャリアに悩むみなさまに伝えたい選択肢
SREが登場してから22年。
システムの複雑化・安定性に対する希求にともない、SREに対する必要性が高まったきた。
ビジネス上での実態と求められる姿と乖離がある。
信頼性を上げる最もいいことは？なにもしない。
デプロイによって障害は生まれる。
リリース速度を上げるとインシデントは増える。
結果、SREが必要になる。
本来のSREは本番からの視点が始まる。ただ、実際はそれに限定されない。
DevOpsとの伴奏が求められることもあるが、Platform Engineeringが生まれた。
真のDevOpsは開発者がアプリをエンドツーエンドでデプロイし、実行する。
結果、認知負荷が増大する。その負荷を除いていくのがPlatform Engineering。
DevOpsとの伴奏は、Platform Engineeringは実行する。
SREの独自に求められる部分。
・信頼性・可用性への強いコミット。
・分析・監視・運用設計の能力。
・障害対応から得た実績的知識。
・データドリブンな意思決定。
AIの影響は不可避。とりあえず触ってみる。
出展ブース
mixiさんとLOVEGRAGHさんでみてねのお話を聞けたのが嬉しかったです。
娘が産まれてからだんとつで利用しているアプリの一つ。
感想とまとめ
SREではなく、SREとの協業経験のない自分にとっても、SREの意義とその役割について解像度あげて理解できる濃厚な１日となりました。
役割に求められるタスクがある反面、役割に依存しない考え方や動き方はあるはずだと思っていて、自分の業務にも取り込める内容も多くありました。
自分のプロダクト開発における役割といえば、プロジェクトマネージャー、POアシスタント、バックエンドエンジニア、QAがメインになりますが、プロダクト開発に求められる要素の理解にも繋がります。
そのうえで、SREでこそ実現できる領域があるし、そうした熱量を感じる楽しいカンファレンスでした。
次回は来年２月の開催予定とのこと。楽しみ。
おまけ
せっかく中野に来たし普段行けないラーメン屋行こうとセッションの合間を縫って入った油そば屋。美味でした。
