[Schedule \| SRE NEXT 2025](https://sre-next.dev/2025/schedule/#) ## Day 1 ### Fast by Friday: Making performance analysis fast and easy by Gregg > It is not ok that we speed weeks, even months, trying to solve why software or hardware is slow. In the meantime, companies waste money on datacenter or cloud compute costs, users are unhappy with latency, and product evaluations can run out of time, leading to poor choices. It should not take more than a week to identify the root cause or causes for a system's poor performance, such that any issue reported on a Monday should be solved by Friday, or sooner. This talk explores a vision called "fast by Friday," a new approach to performance engineering made practical by [[eBPF]] superpowers, and explores engineering work we all need to do to make it possible. This involves default tools, compiler, and runtime options to support immediate analysis, and new production diagnosis tools to exonerate components, focusing the target of analysis. This work can also be adopted by SREs, who must solve issues in much shorter time frames, for a similar vision: "Fast by five minutes!" > ソフトウェアやハードウェアの速度低下の原因を解決するために、数週間、あるいは数ヶ月も時間を費やすことは許されません。その間、企業はデータセンターやクラウドのコンピューティングコストを無駄に消費し、ユーザーは遅延に不満を抱き、製品評価の期限が過ぎてしまい、不適切な選択につながるおそれがあります。システムのパフォーマンス低下の根本原因を特定するのに 1 週間以上かかるべきではありません。つまり、月曜日に報告された問題は、金曜日までに、あるいはそれより早く解決すべきです。この講演では、eBPF の超能力によって実用化された、パフォーマンスエンジニアリングの新しいアプローチである「fast by Friday」というビジョンを探求し、それを実現するために私たち全員が取り組むべきエンジニアリング作業について考察します。これには、即時分析をサポートするデフォルトツール、コンパイラ、ランタイムオプション、およびコンポーネントを特定し分析の焦点を絞るための新しい生産環境診断ツールが含まれます。この取り組みは、より短い時間枠で問題を解決する必要があるSREにも適用可能で、同様のビジョン「Fast by five minutes!」を実現するための基盤となります。 NICs+eBPF 1. Quantify, static tuning, load 2. ebpf tools 3. profiling 4. layency logs, ciritical path 5. Efficiency, algorithms 6. case studyt. retrospective performance engineering team がUSでは存在する。 perormance mantras! why did you change job from netflix into intel? Do you believe the possiblityies of AI Agent based performance engineering? Ai tourble shuuters ### SRE へのサポートケースをAIに管理させる方法 by guni - https://sre-next.dev/2025/schedule/#slot050 ### パネル スタートアップでのSRE実践 - tjun newmo モノレポ - LLM rulesの影響 - 橋本さん Devin 複数横断リポジトリできる CUJに期待 人間が見渡せない範囲で - mirakui 外部依存が多い 電話番号 Twilio, LLM - karszawa グループのクラウドへの依存 - SLO 99.95% 21分/月 - 店舗内のiPadとか、注文データの一貫性を維持 - tjunさん - タクシー決済 電波悪いと決済できない - 現金にフィードバック - 橋本さん - AIをだれが管理するか - .cursor/ .cline / Claude.md がリポジトリぐちゃぐちゃ - ガードレール整備は、守り方が未整備 - LLM observability - mirakui - AI 電話 別モデルにフォールバックする - LLM o11y - 期待した応答をかえすてくれるか ちゃんとしてる度合い - 会場 1-2割ぐらい LLMをプロダクトに組み込んでいる - karszawa - メニュー名 の翻訳 説明性を重視 2色丼 => two color じゃなくて - ### Rethinking Incident Response: Context-Aware AI in Practice by rrreeeyyy https://sre-next.dev/2025/schedule/# - 会場 2/5ぐらい - なぜWaroomをつくったか？ - インシデントレスポンス の近況データ - ポストモーテム改善 孤立がち - ICSの課題 大きい企業の課題 - AI - 自動運転レベルとのマッピング ### パネル ロールモデルなき道をゆく、女性SREキャリア談義 (14:50 - 15:30) https://sre-next.dev/2025/schedule/#slot046 - 大学の教授から アジアで女性エンジニア少ない - AIができないことの武器。巻き込み力、説明力。意思決定、判断力。 - SREって技術を突き詰めないほうがいい？ ### システムから事業へ 〜SREが描く“その先”のキャリア〜 by tomo - https://sre-next.dev/2025/schedule/#slot045 - ## Day 2 ### すみずみまで暖かく照らすあなたの太陽でありたい by 戸田さん https://sre-next.dev/2025/schedule/#slot049 - Service Reliabity Engagement - プライベートクラウドつくっている => ただのオンプレでは？ - オンサイトプライベートクラウド vs 事前調達型オンプレミス - 小売なのにびっくりするぐらいのコア数 ### ABEMA の本番環境負荷試験への挑戦 https://sre-next.dev/2025/schedule/#slot064 - マルチテナント化 - DBまで複製は厳しい - Uber / Mercari - Operator - ヘッダーベースルーティング - Istio - LLM使っても良さそう - k6sシナリオを自動生成している メトリクスの時系列データをもとに - アクセスログではない？ - 自動緊急停止トリガー - k6s - GETの負荷試験のみ - ダミーフラグ -> あとでクリーンアップ - 環境構築時間 数10分へ - 85%の予算削減 - スパイクテストとスケールテスト - Chaos Engineeringも考慮 - [[Chaos Mesh]]をこれまで開発環境やってきた。 - Tenantアプリを利用して、DarkCanary ### SRE with AI：実践から学ぶ、運用課題解決と未来への展望 - https://sre-next.dev/2025/schedule/#slot089 ### Kubernetes で管理する大規模 Edge クラスタ: 200台のEVチャージャーの安定稼働を支える技術 by kurarrr 米倉さん PowerX - 事業内容 - 電力事業 - ためる -> 使う -> 運ぶ - コンテナ型の蓄電システム - EV充電器を探せるアプリなど - 全国に119ステーション - 設置作業中がかなり多い - スタック - マイクロサービス - gRPC GKE - Kotlin / Terraform, Config Connector - prom / otel インフラアーキテクチャ - エッジノードで、予約QRのスキャン - Low-layer API -> IoT Gateway -> cloud のk8s - 充電処理を開始 - デバイスの混在 - ふるいエッジデバイス (armv7, mem 500MB) - 新デバイス (intel, mem 2GB) - k8sファミリー - k0s: メモリフットプリント, シングルバイナリ, - k3sとminikubeと比較 - k0s clusterはクラウドとエッジでまたがってクラスタを組む。 - ネットワークオーバーヘッド問題の顕在化 - kubeletという層をが増えている ### 顧客の画像データをテラバイト単位で配信する画像サーバを WebP にした際に起こった課題とその対応策 ～継続的な取り組みを添えて～ https://sre-next.dev/2025/schedule/#slot059 ### SREのためのeBPF活用ステップアップガイド by egmc https://sre-next.dev/2025/schedule/#slot072 ### システム障害対応のツマミになる話 by [t4kimura](https://twitter.com/t4kimura) https://sre-next.dev/2025/schedule/#slot047