プロポーザル

■ 発表カテゴリ
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）
近年、日本でもスタッフエンジニアという名称が広まってきました。スタッフエンジニアは管理職ではなく、技術面でのリーダーシップを発揮するキャリアパスです。しかし、SREの分野でスタッフエンジニアとなって活躍するには、どのような能力や役割が求められるのでしょうか。
本セッションでは、前職のメルカリでプリンシパルエンジニアおよびエンジニアリングマネージャーを経験した視点から、SREにおけるテクニカルリーダーシップと、キャリアパスについて解説します。技術力と組織への影響力を両立させるための動き方や、SREならではの課題と機会についても触れます。
管理職以外のキャリアパスを模索するSREの方々、そしてSRE組織でのリーダーシップに関心のある方々にとって、有意義なセッションになるとうれしいです。

■ 発表の詳細（1000字程度）

本セッションでは、SREのキャリアパスを考えている人に向けて、スピーカーの実体験に基づいた具体的な事例や実践的なアドバイスを伝えたいと思っています。どのような人がスタッフエンジニアのような役割を担っていたのか、他社の事例なども含めて共有します。
また、エンジニアリングマネージャーの経験を持つスピーカーならではの視点で、管理職とスタッフエンジニアの役割や実際の働き方の違いや、それぞれのキャリアパスの特徴についても言及します。これにより、参加者が自身のキャリアを考える上での新たな視点を提供します。

以下のような構成を考えています。

1. はじめに
   スタッフエンジニアについて、一般的な定義や役割を説明し、エンジニアリングマネージャーなどのキャリアとの比較を行います。
   また、SREという組織におけるリーダーシップの特殊性について説明します。

2. SREスタッフエンジニアの役割
   スタッフエンジニアとしての役割や動き方を、実際の事例などを含めて紹介します。

   • 技術的な課題解決
   • システムの設計とレビュー
   • チーム横断的なプロジェクトのリード
   • 組織におけるSRE文化の醸成

3. 必要なスキルと能力
   求められるマインドや技術的な知識・経験について説明します。以下のようなトピックについて話す予定です。

   • 責任感と信頼感
   • システムアーキテクチャと依存関係の理解
   • クラウド・セキュリティ・コスト
   • 社内外のコミュニケーション
   • 意思決定
   • 長期的な視点
   • インシデント対応

4. キャリアパスの構築
   実際にどのようにしたらSREとしてキャリアを築くことができるか、考えを共有します。

   • スキルアップの方法
   • 組織内での認知度を高める方法

各トピックでは、理論的な説明だけでなく実際の業務シーンを想定したシナリオや、スピーカーが直面した具体的な課題とその解決策を紹介します。

■ 対象聴衆とその人たちが得られるもの

SREとしてのキャリアをより良くしたいと考えている人が、新たな視点を持つことができることを期待しています

■ なぜこのトピックについて話したいのか（モチベーション）
より多くのSREの人がエンジニアリングを続けて、現場で活躍して欲しいから

■ 発表カテゴリ
・Practices: SREの実践例と得られた教訓

■ 発表概要（400字程度）
「トイル」
手作業で、繰り返されて、戦術的で自動化でき、長期的価値を持たず、システムのスケールに対して作業量も比例するという散々な作業のことです。

"トイル"という用語は、一見かっこよく聞こえますが、実際には誰もやりたがらない退屈で反復的な作業を指します。
トイルは蓄積されることで、システムの効率を低下させ、ある時点で大きな問題となって襲いかかってくることが多いです。

これに対して、以下の3つを中心にどう立ち向かったかを紹介します。
・複数あるトイルに対してのトリアージ
・具体例を交えた改善例
・改善から得られた組織への影響

また、全社的に「やったほうが良いと思っているが、自部署の仕事ではない」と思うようなことを解決するために新設されたソリューションチームの例を交えつつお話しします。

■ 発表の詳細（1000字程度）

• 誰もやりたくない仕事、トイル
  • なぜ誰もやりたくないのか
  • トイル撲滅に取り組んだ方がよいワケ
• 具体的改善例
  • SSHオペレーションからCI/CDを用いた自動化への移行
  • 情報確認のpull型からpush型への移行について
  • クリックOpsからGitOpsへの移行について
• スズキ流トイルとの向かい合い方
  • トイルに対しての思考方法
• 今後トイルを生み出さないようにするためには

■ 対象聴衆とその人たちが得られるもの

• 改善に取り組んでいる人
• 改善に取り組みたい人

■ なぜこのトピックについて話したいのか（モチベーション）
SREとしての経験を通じて、日常のオペレーション業務において、「トイル」が生産性とエンジニアのモチベーションにどれほど大きな影響を与えるかを何度も目の当たりにしてきました。
私たちはしばしば、目立つ成果物やプロジェクトに目を向けがちですが、その一方でトイルのような地味で見えにくい仕事がいかに重要かを強調したいです。
トイルの撲滅に取り組むことで、全体の生産性を向上させるとともに、エンジニアの幸福感も大幅に高めることができると思っています。同じ悩みを抱える多くのエンジニアに対し、有用な知識と具体的な改善方法を提供します。

■ 発表カテゴリ
・Tech: SREを支える具体的な技術や手法

■ 発表概要（400字程度）

Terraformを使ったことはありますか？Terraform Providerを実装したことは？そのときにライブラリは何を使いましたか？
約2年前、Terraform Plugin Frameworkという、旧来のTerraform Plugin SDKv2から大きく進化したSDKがGAを迎えました。
一方、Terraform Plugin SDKv2は未だメンテナンス自体はされており、引き続き使用することはできます。
本発表では、Terraform Plugin SDKv2と比べてTerraform Plugin Frameworkのどういった点が嬉しいのか、既に存在するPlugin SDKv2ベースのProviderはどのようにしてPlugin Frameworkに移行すれば良いのか、あるいは移行の際に気を付けるべきことを共有します。

■ 発表の詳細（1000字程度）

• Terraformの構造
  • Terraform Pluginとはなにか
• Terraform Pluginを実装する方法
  • Terraform Plugin SDKv2
  • Terraform Plugin Framework
• Terraform Plugin SDKv2とTerraform Plugin Frameworkの比較
  • 何が違うのか
  • 何が嬉しいのか
• Terraform Plugin SDKv2からTerraform Plugin Frameworkへの移行
  • どのように移行すれば良いのか
  • 移行する際の注意点

■ 対象聴衆とその人たちが得られるもの

• Terraform Pluginを実装することに興味のある人
  • どのようにTerraform Pluginを実装することができるか
• Terraform Plugin SDKv2を使ってTerraform Pluginを実装している人
  • Terraform Plugin SDKv2からTerraform Plugin Frameworkへの移行方法

■ なぜこのトピックについて話したいのか（モチベーション）

快適・安全に開発を進められるように基盤を整えたり、ミドルウェアや使用しているライブラリを適切に更新していくこともSREの典型的な仕事の一つであると思っています。
多くの企業ではTerraform Pluginを開発する必要は無く、オープンソースのProviderを使用することで十分であるとは思いますが、Terraform Pluginの実装方法について学ぶことで、自前で実装をできるだけではなく、オープンソースのProviderに問題があったり、新機能を追加したい場合にコントリビューションしやすくなります。
SREが使用する技術の多くはオープンソースコミュニティにより支えられており、コントリビューターを増やすことも重要であると考えています。

■ 発表カテゴリ

・Practices: SREの実践例と得られた教訓

■ 発表概要（400字程度）

「SREのはじめの一歩はどんな感じなんだろう？」

本セッションでは、SRE未経験のインフラエンジニアが中心となり、SaaSサービスの立ち上げ期にSREを実践しているようすを紹介します。
PdM、デザイナー、開発エンジニア、カスタマーサクセスが集う十数名のチームメンバーと共に、どのようにSREの考え方を導入・実践し、サービスの信頼性向上に取り組んだのかをお話しします。

・SREについて考えるようになった背景・契機
・ミッションを中心にSREに取り組む
　・CDNの本格導入
　・Google App EngineからGoogle Kubernetes Engineへの移行
　・ステータスページの導入
・取り組みを通して学んだこと
・これから取り組むこと

SRE経験はゼロからのスタートでしたが、サービスが成長していく中で、SREの実践に奮闘して得た経験と学びを、赤裸々に語ります。

■ 発表の詳細（1000字程度）

◎SREについて考えるようになった背景・契機

2024年7月にヘッドレスCMS「NILTO」の開発チームにインフラエンジニアとしてジョインした私は、Google Cloud上で構築された、今まさに成長中のサービスを目の当たりにしました。
2023年12月の正式リリース以降、NILTOの機能開発はさらに加速中。

そんな中私は、Google Cloud認定Professional Cloud DevOps Engineerの取得を契機に、SREへの関心を深めました。
試験範囲にあったSREの手法を、私たちのサービスにも適用できるのではと考えたのです。

SREという言葉はまだチーム内にありませんでしたが、プラクティスを適用できる余地は多く、SREの0→1フェーズを経験することは、私だけでなくチーム全体にとって有益だと考え、実践に取り組みはじめました。

◎ミッションを中心にSREに取り組む

SREと一言で言っても、そのプラクティスは多様です。
まずはインフラエンジニアとしてのお仕事・ミッションを中心に、少しずつ取り入れていくことにしました。

・CDNの本格導入

CDNサービス選定と並行し、ドキュメント作成に着手しました。
サービス選定がほぼ完了した段階で、IaCによるリソース作成を試行。
CDNとアプリケーションの間に必要な機能の設計・開発と並行して、ドキュメントを充実させていきました。

・Google App EngineからGoogle Kubernetes Engineへの移行

まずはGKE周辺の構成図を書くことからはじめて、IaCによるリソース作成、移行の検証に取り組みました。
また、モニタリング項目が大きく変わるため、改めて整理を行いました。

・ステータスページの導入

SLOに関わるシステム稼働情報、メンテナンス情報、インシデント対応状況などをリアルタイムにユーザーに伝えるため、ステータスページ導入を検討しました。
サービス選定と試用を通じて、運用イメージを具体化し、ユーザーへの透明性向上と信頼獲得を目指しました。

◎取り組みを通して学んだことと、これから取り組むこと

これらの取り組みは、現在も進行中です。
発表では、取り組みの結果や経験から得られた学びと今後の展望について、発表時の最新情報も交えてお伝えします。

SRE未経験のインフラエンジニアを起点として、チームで実践してきた道のりを共有することで、同様の課題を抱える方々への一助となることを願っています。

■ 対象聴衆とその人たちが得られるもの

・新サービスの企画中で、SREってどんな風に始まるの？と考えている人
・サービス立ち上げ期、もしくは実際にサービス運用中で、これからSREを始めていきたい開発／インフラ／運用エンジニア

私たちも、開発／インフラ／運用エンジニアとしてのバックグラウンドを基に、SREの学習と実践を繰り返している真っ只中です。
本セッションを通じて、SREを始めるにあたっての足がかりとなる情報を得ていただき、そして一緒にブラッシュアップしていければ良いなと考えています。

■ なぜこのトピックについて話したいのか（モチベーション）

サービス正式リリース直後の立ち上げ期にSREの考えを導入して実践するということは、立場や状況によってはなかなか経験が少ないと思います。
その経験から得た知見をオープンな場所で発表することで、将来SREに関わるエンジニアの実務への活用や、SREコミュニティの広がりに貢献していきたいと考えています。

■ 発表カテゴリ
Tech: SREを支える具体的な技術や手法

■ 発表概要（400字程度）
本セッションでは「SLOベースのアラート」の導入ステップを料理のレシピになぞらえてご紹介します。具体的には、完成形のイメージ、必要な材料やツール、工程を分かりやすく説明します。

SLOベースのアラートは、アプリケーションの信頼性を保つための強力な監視手法です。特に「複数ウィンドウ、複数バーンレートのアラート」という手法が『サイトリライアビリティワークブック』で推奨されています。

しかし、導入事例をあまり見かけない現状です。その背景には、導入のハードルが高そうだという誤解があるのかもしれません。

レシピ形式でお伝えする本セッションを通じて、一見ややこしそうなSLOベースのアラートでも「意外と簡単に導入できそうだな」と感じていただければ幸いです。そして、実際に試すことで、この手法の強力さを実感してほしいと願っています。

■ 発表の詳細（1000字程度）
以下の流れでの発表を考えています。

1. 完成形のイメージ

まず、料理のレシピと同様に、完成形のイメージを示します。本セッションでの完成形のイメージは「複数ウィンドウ、複数バーンレートのアラート」を用いてWebサービスの可用性を監視している状態です。この手法の概要や、なぜこの完成形を目指すのかも説明します。

2. 必要な材料

次に、必要な材料を示します。具体的には、可用性を監視したいWebサービスのアクセスログです。本セッションでは、このアクセスログを使って工程を説明します。ただし、フロントエンドのイベントログを監視したい場合など、異なる材料を使いたい場合でも応用が利くよう配慮します。

3. 必要なツール

さらに、必要なツールも示します。具体的には、メトリクス保存器、メトリクス集計器、アラーム発報器、複合アラーム発報器の4つです。各ツールの役割と必要な機能を説明します。

4. 工程

最後に、完成までの工程を説明します。具体的には、下記の4つです。

• 工程1：可用性のSLOを策定します。
• 工程2：メトリクスを保存器に保存します。
• 工程3：メトリクスを集計器で定期的に集計し、その結果を別の保存器に保存します。
• 工程4：集計結果に応じてアラームを発報するよう発報器を設定します。

各工程の詳細はセッションでのお楽しみとさせてください。

5. アレンジレシピ：ダッシュボード添え

もし時間に余裕があれば、可用性の推移を可視化するダッシュボードの作り方を「アレンジレシピ」として紹介します。

■ 対象聴衆とその人たちが得られるもの

• SLOベースのアラートに興味はあるが、導入経験のない方：この手法のメリットや、導入に必要なステップが理解できます。
• SLOベースのアラートを導入済みの方：他の導入例を知り、現行の運用をチェックするための視点が得られます。

■ なぜこのトピックについて話したいのか（モチベーション）
SLOベースのアラートを勤務先で導入し、とても満足しているため、その知見を未経験の方々にも共有したいというのが最大のモチベーションです。「このレシピならおいしい料理が簡単に作れるから、ぜひ試して」という感覚に近いと思います。せっかく強力な手法があるのに、導入事例をあまり見かけないのはもったいないな、と日頃から感じていました。

■ 発表カテゴリ
募集要項（ https://www.notion.so/srekaigi/SRE-Kaigi-2025-CfP-0939fcd968a74bddaebdbf638a957ab9 ） にある6つの発表カテゴリからお選びください

・Practices: SREの実践例と得られた教訓

■ 発表概要（400字程度）

SLI/SLOはSREの単語としてよく聞きますが、モバイルアプリ開発にはあまり馴染みのないものです。
私の所属するプロダクトのモバイルアプリは障害の発生率が高く、それを早期に検知し、解消できる仕組みが必要でした。
そこで私はこのSLI/SLOの仕組みをモバイルアプリに合う形に適用し、ユーザー体験の低下を検知する仕組みを作成しました。
この仕組みによって以下のことが即時検知可能です。

• 失敗率(一定以上のユーザーが機能を利用時にエラーなどの出現で機能の利用に失敗したケース)
• キャンセル率(一定以上のユーザーが機能を利用時に何かを理由にキャンセルしたケース)
• 中断率(一定以上のユーザーが機能を利用時に何かを理由にアプリをキルしたケース)

現在ではこの監視対象として40以上の機能に埋め込みが完了しています。

このセッションでは以下のことについて話していければと考えています。

• SLI/SLOとは
• 一般的なSLI/SLOとユーザー体験を検知するSLI/SLOの違い
• ユーザーが途中で機能の利用をやめたり、途中でクラッシュしたケースを計測するためには
• ユーザー体験のアラート基盤の作成時にどのようにノイズアラートと戦うか
• 計測基盤を埋め込むときになるべくメインコードに影響を与えないためには
• ビジネスのメンバーを巻き込んでユーザー体験の低下を検知、阻止するためには

■ 発表の詳細（1000字程度）

• SLI/SLOとは

SLI/SLOの基本的な説明を行います

• 一般的なSLI/SLOとユーザー体験を検知するSLI/SLOの違い

このセッションでは、「クライアントでSLI/SLOを計測する = 機能単位で機能を利用し始めるところか完了するまでの一連のフロー計測する」こととします。
具体例をもとに説明します。

• ユーザーが途中で機能の利用をやめたり、途中でクラッシュしたケースを計測するためには

API単位での計測と異なり、ユーザーが計測中に離脱することも考慮して計測しないといけません。その課題をどのように乗り越えるかの説明をします。

• ユーザー体験のアラート基盤の作成時にどのようにノイズアラートと戦うか

計測データはもろにユーザー行動の影響を受けます。その中でどのようにアラートを構築したかについてお話します。

• 計測基盤を埋め込むときになるべくメインコードに影響を与えないためには

計測処理をクライアントのプロダクションコードに記述する形で計測しています。その時、計測処理がユーザーの体験を損ねてしまうわけにはいきません。
ここでの工夫についてお話しします。

• ビジネスのメンバーを巻き込んでユーザー体験の低下を検知、阻止するためには

SLI/SLOは信頼性を可視化することができます。しかし、これをビジネスメンバーに理解してもらうことは簡単ではありません。
私の所属するチームでは障害対応時に利用するダッシュボードを作成しました。
これにより私の所属するプロダクトのメンバーのほとんどはSLI/SLOを認知しています。どのようにビジネスメンバーに定着したかの過程を紹介します。

■ 対象聴衆とその人たちが得られるもの

• クライアント領域におけるSREの導入事例とその違い
• SLI/SLOをビジネスメンバーに定着してもらう動き

■ なぜこのトピックについて話したいのか（モチベーション）

SLI/SLOの概念はサービスの信頼性を表すものであり、バックエンドのみならず、プロダクト全体で計測することで真価が発揮されると考えています。
実際にプロダクトに導入してみて、APIが叩かれる前段階でユーザー体験が低下している事例も多く存在しました。クライアント領域から見たSREについて話させていただければと思います。

■ 発表カテゴリ
・Tech: SREを支える具体的な技術や手法

■ 発表概要（400字程度）
ある程度の規模のプロダクション環境では、複数のマイクロサービスが様々な基盤の上で、絶え間なく変化を続けながら動作することになります。そんな環境から各種テレメトリーデータを集めて可視化し、複雑な状況の把握を助けるのが「オブザーバビリティ」と呼ばれている分野です。

オブザーバビリティのためのテレメトリーデータを収集する各種ツール群や標準を提供しているのがOpenTelemetryです。様々な箇所にエージェントを設定し、データパイプラインを構築し、バックエンドに送り、可視化する。OpenTelemetryは「簡単に始められる」というコンセプトはありつつも、実際には、常にうまく動くとは限りません。

本セッションでは、OpenTelemetryの計装でよくあるトラブルの例とその解決方法を、OpenTelemetryのアーキテクチャーとともに紹介していきます。そして、テレメトリーデータの活用を始めるためのステップについて議論していきます。

■ 発表の詳細（1000字程度）

1. OpenTelemetryとオブザーバビリティの概要

本セッションの目的と内容を紹介し、OpenTelemetryがオブザーバビリティの領域で果たす役割を簡単に説明します。マイクロサービスアーキテクチャにおいて、どのようにして複雑なシステム全体の健全性を可視化するのか、そのために必要なテレメトリーデータの収集と分析の重要性を伝えます。

2. OpenTelemetryの基本アーキテクチャ

OpenTelemetryの構成要素（API、SDK、Collector、エクスポート機能など）について簡単に解説します。各コンポーネントがどのように連携して動作し、テレメトリーデータを収集・処理・送信するかを紹介し、全体の流れを把握します。

3. よくあるトラブルとその原因

OpenTelemetryをプロダクション環境で導入した際に直面することの多いトラブルをいくつか紹介します。例えば、以下のような問題が取り上げられます。

• メトリクスやトレースが意図した通りに収集されない
• 特定のサービスでエージェントが正常に動作しない
• データパイプラインが断続的に失敗する

これらの問題の原因を探るための手順を解説します

4. トラブルシューティングの方法と解決策

よくあるトラブルに対する具体的な解決方法を説明します。例えば、エージェントの設定ミス、ネットワーク関連の問題、バックエンドへのデータ送信が不安定なケースなどについて、どのように診断し、修正するかを解説します。また、適切なログの確認方法や、トラブル解決を容易にするデバッグツールの使用についても触れます。

5. テレメトリーデータの活用を始めるためのステップ

OpenTelemetryを効果的に導入し、オブザーバビリティを高めるためのステップについて議論します。初期の設定から本格的なデータ可視化・分析まで、どのような段階を踏んで進めていくべきかを具体的にアドバイスします。例えば、小規模なテスト環境での計装から本番環境への展開、データの収集・保存・分析のための適切なツールの選定などです。

■ 対象聴衆とその人たちが得られるもの

• SRE、開発者
• トラブルシュートやパフォーマンス問題に悩む人
• 開発/運用プロセスの改善を考えている人
• OpenTelemetryを使い始めようと思っている人
• OpenTelemetryを試したことがあるけどうまく動かなくて「？」ってなった経験がある人
• オブザーバビリティの向上が必要だと思っている人

■ なぜこのトピックについて話したいのか（モチベーション）
私の経験が皆さまのお役に立てればと思い・・・

■ 発表カテゴリ
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）
昨今、DDoS攻撃や不正アクセスなど、Webサービスが攻撃にさらされる機会は増加の一途を辿っています。
セキュリティ運用の温度感は高くなっており、SREチームが兼務している企業も少なくないのではないでしょうか。

一般的なセキュリティ対策として、問題特定や予兆検知に用いるセキュリティログ管理が重要です。
セキュリティ領域でのログやイベント管理をSIEMと呼びます。

ココナラではセキュリティチームだけでなく、SREチームもセキュリティ運用に取り組んでいます。
以前は何も動けていませんでしたが、今では日々のメトリクスモニタリングに運用を組み込み、信頼性向上に寄与しています。

セキュリティ運用整備をSREチームがやることで信頼性向上に繋げた事例や、SIEM運用のつまづき・メリット / デメリットを紹介します。
この発表でチームの垣根を超えた信頼性向上の取り組みやSIEMのノウハウを得られると幸いです。

■ 発表の詳細（1000字程度）
以下の章立てでお話をします。

1. ココナラで抱えていたセキュリティの課題
2. セキュリティログ分析へのアプローチ
3. セキュリティの課題をどのように解決していったか？
4. SIEMの導入効果
5. 今後の取り組み

ココナラはもともとSREチームがスキマ時間でセキュリティ対応を行っており、後手後手に回っていたり、体系立てた対応ができませんでした。
そこを改善すべく、SIEM（Amazon OpenSearch Serviceを利用した分析基盤）を導入し、試行錯誤の結果、セキュリティログの可視化と分析を行える状態を作りました。

また、「セキュリティログ分析はセキュリティの仕事」になりがちですが、SREも入ることによって運用改善・効率化の結果、信頼性向上（攻撃予兆 〜 傾向分析を行い、WAFのルールやアプリケーションを改善することでSuccess Rateを99.95% → 99.998%へ向上）を実現できました。
SREやセキュリティエンジニアの協業・キャリア形成の取り組みにも触れて話をします。

DevOpsDays Tokyo 2024ではOpsの話をしたので、今回はセキュリティログ分析を起点としたSREのプラクティスやSRE・セキュリティエンジニアのキャリア形成にもつながる話をします。
■SREのプラクティス
・日々のメトリクスモニタリングへ装着し、攻撃の予兆検知 〜 遮断対応の高速化
・ログ分析による予防のアクション創出〜実践

■SRE・セキュリティエンジニアのキャリア形成
・SREから見ると
　　DevSecOpsの実践
　　セキュリティ運用のトイル削減、既存設定の見直しなどIaC以外の効率化・自動化
・セキュリティエンジニアから見ると
　　セキュリティ × SREのプラクティスによるプロアクティブな運用改善実践
　　組織としてサービスに貢献できることの楽しさによるIaCへの取り組みや監視改善

https://speakerdeck.com/coconala_engineer/siemwoyong-ite-sekiyuriteirogufen-xi-noke-shi-hua-tofen-xi-woshi-xian-si-pdcasaikuruwohui-sitemita-3c3b6400-1e46-45d1-adcc-f619843328d7

■ 対象聴衆とその人たちが得られるもの
・信頼性向上に向けたSRE × セキュリティ観点のアプローチ、キャリアパスの広がり
・特にAWS環境におけるセキュリティログ分析・モニタリングの取り組みと実践
・SIEMでできること、SIEM on Amazon Open SearchServiceのより良い使い方

■ なぜこのトピックについて話したいのか（モチベーション）
セキュリティの専門組織を持っていない会社、持っていてもプロダクトのセキュリティログ分析に工数が割けない会社が多いと思います。

SREは1つのロールなので、職種横断で取り組むべきプラクティスですし、セキュリティという切り口でSREの裾野を広げることがこのイベントの趣旨にあっていると考えたからです。

SREに対しては、
・SRE × セキュリティのプラクティスで技術もキャリアも幅が広がる
を伝えていき、セキュリティエンジニアに対しても
・実は業務の一部がSREを実践している
・セキュリティ起点でプロダクトの価値向上に大いに貢献できる
というのを伝えることで、キャリアパスの広がりや業務のシナジーを生み出していきます。

■ 発表カテゴリ
募集要項（https://www.notion.so/srekaigi/SRE-Kaigi-2025-CfP-0939fcd968a74bddaebdbf638a957ab9） にある6つの発表カテゴリからお選びください

・Tech: SREを支える具体的な技術や手法

■ 発表概要（400字程度）
日本ではまだ馴染みの薄い DBRE。
おそらく DBRE ってそもそも必要なのか？やろうとしてもどうやって始めたらいいの？具体的に何をやっているの？という方が数多くいると思います。
このセッションでは私たちはなぜ DBRE という道を選んだのか、DBRE は何をしているのか？について実践的な内容を含めて共有させていただくことで皆様の疑問にお答えします。

具体的には下記を提供することで参加者の皆様に下記を通じて DBRE の実践を感じ取っていただきます。

• DBRE は自分たちに本当に必要なのか
• DBRE の目標、ゴール設定はどのように定義しているのか
• プロジェクトの進め方はどのようにしているのか
• 実際のアウトプットのデモ

ここまで聞くと、DBRE ではないけれど、実は自分たちも同じような仕組みを構築している、自分たちも同じようなプラットフォームが欲しい、という共感を持っていただけるかもしれません。
そんなあなたはもう DBRE です。
ぜひ日本の DBRE も一緒に盛り上げて行きましょう。

■ 発表の詳細（1000字程度）
前提として現段階の私たちは Platform を提供することで、「プロダクトのエンジニアと伴奏しながら彼らの自律性を高めること」を目的に活動しています。
なぜそのような動きをしているのか、その効果は？について具体例を用いて紹介させていただきます。

• DBRE とは
  • Database に対する専門知識と判断を用いてサービスの信頼性を担保するのが役割
  • クラウドが普及してきた現代ではゲートキーパーとしての役割ではなく、現場のエンジニアが事業成長に注力できる環境をどのように提供したらよいか
• DBRE は自分たちに本当に必要なのか
  • DBRE が向いている組織とそうでない組織にはどのような違いがあるのか
• DBRE の目標、ゴール設定はどのように定義しているのか
  • DBRE のミッション, ビジョン
  • 3年戦略
• プロジェクトはどのように進めているのか
  • DBRE を支える技術
    • エンジニアリング
    • monorepo 管理
    • スクラム
• 実際のアウトプットの例
  • データベースパスワードの安全なローテーション
  • 生成 AI を活用したスキーマレビュー
    • プロジェクト開始前に作成したインセプションデッキとデモを用いて共有します

■ 対象聴衆とその人たちが得られるもの
特にデータベースの運用や信頼性に関心を持つSREエンジニア、システム設計者、エンジニアリーダーを対象としています。
参加者は、データベースを軸とした Reliability Engineering について実践的なアプローチを学び、実際の導入事例から得られた教訓を自身の組織に応用するための具体的な手法とアイデアを得ることができます。

■ なぜこのトピックについて話したいのか（モチベーション）
私たちは、DBRE を実践するために様々な挑戦をしてきました。DBREという分野において、単なる技術的な解決策だけでなく、チームの文化や組織としての取り組みも重要です。
これまでの経験を共有することで、同じような課題に直面している他のエンジニアやチームの助けになりたいと考えています。
また、データベースを軸とした Reliability Engineering という視点を広め、SREコミュニティにも知見の共有と改善に貢献したいという思いから、このトピックを選択しました。

■ 発表カテゴリ
募集要項（https://www.notion.so/srekaigi/SRE-Kaigi-2025-CfP-0939fcd968a74bddaebdbf638a957ab9） にある6つの発表カテゴリからお選びください

・Tech: SREを支える具体的な技術や手法

■ 発表概要（400字程度）
Kubernetesを基盤とした現代のシステム運用において、SREの実践は重要な役割を果たしています。本セッションでは、オープンソースツールを活用してKubernetes上に信頼性の高いインフラストラクチャを構築し、組織全体のソフトウェアデリバリーを加速させる方法を探ります。Helm、Tekton、Argo CD、Crossplane、Knativeなどの主要ツールの統合方法や、運用効率を高めるアプリケーションの設計、マルチクラウド戦略の実装、プログレッシブデリバリーの実現方法について具体的に解説します。これらの技術と手法を通じて、開発チームと運用チームの連携を強化し、システムの信頼性を向上させながら、ソフトウェアデリバリーの効率を大幅に改善する方法を学びます。さらに、SREの効果を測定するためのメトリクスと、継続的な改善サイクルの確立方法についても触れ、長期的な運用戦略を提示します。
■ 発表の詳細（1000字程度）
本セッションでは、Kubernetes環境におけるSRE実践の高度化について解説します。現代のシステム運用でKubernetesが中心的役割を果たす中、SRE原則の効果的な適用がますます重要になっています。我々は、オープンソースツールを活用して信頼性の高いインフラを構築し、組織全体のソフトウェアデリバリーを加速させる方法を探ります。

主要なオープンソースツール（Helm、Tekton、Argo CD、Crossplane、Knative）の特徴と、SRE実践への統合方法を紹介します。これらのツールの選定基準や、組織のニーズに合わせたカスタマイズ方法にも触れ、最適なソリューション構築を支援します。

SRE視点からの効率的な運用API設計原則を解説し、開発・運用チームの協働促進方法を具体例と共に紹介します。自動化と標準化によるヒューマンエラー削減事例も共有し、信頼性向上への道筋を示します。

マルチクラウド環境でのSRE戦略として、Crossplaneを用いたクラウドリソース管理の統一や、クラウド間でのSLO一貫管理技術を紹介します。障害シナリオにおけるマルチクラウドの利点活用についても実践的アプローチを共有します。

プログレッシブデリバリーによる信頼性向上として、Knative ServingとArgo Rolloutsを用いたカナリアリリース、段階的トラフィック制御、リアルタイムモニタリング統合、自動ロールバックメカニズムの構築方法を解説します。

開発・運用チームの生産性と信頼性の同時向上のため、共通基盤による開発者体験向上とSRE原則浸透、自動化による認知負荷軽減、エラーバジェットの概念導入とその活用について説明します。

SRE実践の効果測定と継続的改善のフレームワークとして、DORAメトリクスの活用、カスタムSLI/SLOの設定・追跡、データ駆動型改善サイクルの確立方法を紹介します。

最後に、大規模システムでのSRE導入事例、課題と克服方法、得られた教訓を共有します。長期的な信頼性向上と運用効率化の両立戦略についても議論し、参加者が自身の環境でSRE実践を高度化するための具体的なアイデアと方法論を提供します。

■ 対象聴衆とその人たちが得られるもの

• SRE実践者や運用エンジニア
• Kubernetesを用いたシステム運用に携わる開発者やアーキテクト
• 信頼性向上とDevOps文化の導入を推進する技術リーダー
• クラウドネイティブ環境での運用最適化を目指すチーム

得られるもの：
1.Kubernetes環境でのSRE実践を高度化するための具体的な手法と工夫
2.オープンソースツールを活用した信頼性向上と運用効率化の実践的アプローチ
3.マルチクラウド環境での一貫したSRE戦略の立案と実装方法
4.プログレッシブデリバリーによるリスク軽減と信頼性向上の実現手法
5.SRE実践の効果を定量的に測定し、継続的に改善するためのフレームワーク
6.実際の導入事例から学ぶ、SRE実践の課題克服とベストプラクティス

■ なぜこのトピックについて話したいのか（モチベーション）
Kubernetesの普及に伴い、多くの組織が複雑性の増大と信頼性維持の難しさに直面しています。SREの原則と実践は、これらの課題を解決し、システムの信頼性と運用効率を飛躍的に向上させる可能性を秘めています。
私自身、複数の大規模プロジェクトでKubernetesベースのシステム運用とSRE導入に携わり、その過程で得た知見と成功事例を共有したいと考えています。特に、オープンソースツールの効果的な組み合わせによる柔軟なソリューションの構築方法や、開発・運用チームの協働を促進するAPIの設計について、具体的な実装例を交えて解説することで、聴衆の皆様に実践的な価値を提供できると確信しています。
このセッションを通じて、参加者の皆様がKubernetes環境でのSRE実践に関する新たな視点と具体的なアプローチを得られ、より信頼性の高いシステムと組織の実現に向けた一歩を踏み出せることを願っています。

■ 発表カテゴリ
Tech: SREを支える具体的な技術や手法

■ 発表概要（400字程度）
SREは、システムの安定運用だけでなく、幅広い技術的な課題に対応する責任を持ちます。このセッションでは、モニタリング、パフォーマンス改善、そしてセキュリティの観点から、SREがどのようにシステムの信頼性を確保すべきかを体系的に解説します。システムの健全性を把握するためのモニタリング手法、パフォーマンス最適化に必要な実践的なアプローチ、さらにセキュリティ対策を通じて可用性を守るための戦略を取り上げます。特定のツールに依存せず、柔軟な運用方法と幅広い適用可能性を意識した内容を提供します。SREとして直面する日常の課題を深く掘り下げ、より包括的な視点での実践的なアドバイスを得ることができます。

■ 発表の詳細（1000字程度）
このセッションでは、SREが担うべき広範な技術領域について、具体的な方法論と実践事例を交えて紹介します。

まず、モニタリングの重要性を中心に、システムの健全性を常に把握するための効果的なモニタリング手法について議論します。どのようなツールを使うかに依存せず、システムの状態を適切に監視し、早期に問題を発見するための最適なアプローチを考察します。さらに、アプリケーションの動作状況を可視化し、パフォーマンスボトルネックを特定するためのテクニックも紹介します。オブザーバビリティの観点から、システム全体の信頼性を高める方法に焦点を当てます。

次に、パフォーマンス最適化の分野について、実際の経験を基にした具体的な事例を紹介します。Linuxカーネルのパラメーター調整によるシステムの最適化や、アプリケーションコードにおけるN+1問題の解消など、システムの性能を向上させるための実践的な手法を掘り下げます。また、過剰なトラフィックを効率的に制御し、システムの安定性を維持するための対策についても説明します。

最後に、セキュリティの側面について議論します。可用性を確保するためには、システムが常にセキュアであることが前提条件です。SREとして、どのようなセキュリティ対策が求められるのか、特に攻撃や不正アクセスに対する防御がシステム全体の信頼性にどのように寄与するかを解説します。これらの課題を通して、SREが技術的な観点だけでなく、運用とセキュリティの両方を統合的に管理する必要性を再認識します。

■ 対象聴衆とその人たちが得られるもの
このセッションは、中堅のSREエンジニアや、SREを目指すエンジニアを対象としています。彼らは、SREが対応すべき幅広い技術領域についての体系的な知識を得るとともに、現場で実際に使える具体的なモニタリング手法やパフォーマンス最適化の技術、さらにセキュリティ対策の重要性を学ぶことができます。特定のツールに依存しない柔軟な方法論を知ることで、各自の職場に適したSREのベストプラクティスを取り入れることができるようになるでしょう。

■ なぜこのトピックについて話したいのか（モチベーション）
SREとしての役割が多岐にわたる一方で、その守備範囲が明確でない場合が多いと感じています。日常の運用業務だけでなく、パフォーマンスの最適化やセキュリティ対策にも深く関わるべきだと考えています。私自身が直面してきた実務上の課題やその解決方法を共有することで、多くのエンジニアがより幅広い視点を持ち、SREとしての職責を再定義できるようになることを目指しています。このトピックを通じて、SREがシステム信頼性の中核を担う役割を再認識し、より効果的な運用を支援したいと考えています。