SRE30分クッキング「SLOベースのアラート」
岩本 隆史 ■ 発表カテゴリ
Tech: SREを支える具体的な技術や手法
■ 発表概要（400字程度）
本セッションでは「SLOベースのアラート」の導入ステップを料理のレシピになぞらえてご紹介します。具体的には、完成形のイメージ、必要な材料やツール、工程を分かりやすく説明します。
SLOベースのアラートは、アプリケーションの信頼性を保つための強力な監視手法です。特に「複数ウィンドウ、複数バーンレートのアラート」という手法が『サイトリライアビリティワークブック』で推奨されています。
しかし、導入事例をあまり見かけない現状です。その背景には、導入のハードルが高そうだという誤解があるのかもしれません。
レシピ形式でお伝えする本セッションを通じて、一見ややこしそうなSLOベースのアラートでも「意外と簡単に導入できそうだな」と感じていただければ幸いです。そして、実際に試すことで、この手法の強力さを実感してほしいと願っています。
■ 発表の詳細（1000字程度）
以下の流れでの発表を考えています。
- 完成形のイメージ
まず、料理のレシピと同様に、完成形のイメージを示します。本セッションでの完成形のイメージは「複数ウィンドウ、複数バーンレートのアラート」を用いてWebサービスの可用性を監視している状態です。この手法の概要や、なぜこの完成形を目指すのかも説明します。
- 必要な材料
次に、必要な材料を示します。具体的には、可用性を監視したいWebサービスのアクセスログです。本セッションでは、このアクセスログを使って工程を説明します。ただし、フロントエンドのイベントログを監視したい場合など、異なる材料を使いたい場合でも応用が利くよう配慮します。
- 必要なツール
さらに、必要なツールも示します。具体的には、メトリクス保存器、メトリクス集計器、アラーム発報器、複合アラーム発報器の4つです。各ツールの役割と必要な機能を説明します。
- 工程
最後に、完成までの工程を説明します。具体的には、下記の4つです。
- 工程1：可用性のSLOを策定します。
- 工程2：メトリクスを保存器に保存します。
- 工程3：メトリクスを集計器で定期的に集計し、その結果を別の保存器に保存します。
- 工程4：集計結果に応じてアラームを発報するよう発報器を設定します。
各工程の詳細はセッションでのお楽しみとさせてください。
- アレンジレシピ：ダッシュボード添え
もし時間に余裕があれば、可用性の推移を可視化するダッシュボードの作り方を「アレンジレシピ」として紹介します。
■ 対象聴衆とその人たちが得られるもの
- SLOベースのアラートに興味はあるが、導入経験のない方：この手法のメリットや、導入に必要なステップが理解できます。
- SLOベースのアラートを導入済みの方：他の導入例を知り、現行の運用をチェックするための視点が得られます。
■ なぜこのトピックについて話したいのか（モチベーション）
SLOベースのアラートを勤務先で導入し、とても満足しているため、その知見を未経験の方々にも共有したいというのが最大のモチベーションです。「このレシピならおいしい料理が簡単に作れるから、ぜひ試して」という感覚に近いと思います。せっかく強力な手法があるのに、導入事例をあまり見かけないのはもったいないな、と日頃から感じていました。
SLI/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について話させていただければと思います。
OpenTelemetry計装における、最初のトラブルシューティング
Kazunori Otani ■ 発表カテゴリ
・Tech: SREを支える具体的な技術や手法
■ 発表概要（400字程度）
ある程度の規模のプロダクション環境では、複数のマイクロサービスが様々な基盤の上で、絶え間なく変化を続けながら動作することになります。そんな環境から各種テレメトリーデータを集めて可視化し、複雑な状況の把握を助けるのが「オブザーバビリティ」と呼ばれている分野です。
オブザーバビリティのためのテレメトリーデータを収集する各種ツール群や標準を提供しているのがOpenTelemetryです。様々な箇所にエージェントを設定し、データパイプラインを構築し、バックエンドに送り、可視化する。OpenTelemetryは「簡単に始められる」というコンセプトはありつつも、実際には、常にうまく動くとは限りません。
本セッションでは、OpenTelemetryの計装でよくあるトラブルの例とその解決方法を、OpenTelemetryのアーキテクチャーとともに紹介していきます。そして、テレメトリーデータの活用を始めるためのステップについて議論していきます。
■ 発表の詳細（1000字程度）
- OpenTelemetryとオブザーバビリティの概要
本セッションの目的と内容を紹介し、OpenTelemetryがオブザーバビリティの領域で果たす役割を簡単に説明します。マイクロサービスアーキテクチャにおいて、どのようにして複雑なシステム全体の健全性を可視化するのか、そのために必要なテレメトリーデータの収集と分析の重要性を伝えます。
- OpenTelemetryの基本アーキテクチャ
OpenTelemetryの構成要素（API、SDK、Collector、エクスポート機能など）について簡単に解説します。各コンポーネントがどのように連携して動作し、テレメトリーデータを収集・処理・送信するかを紹介し、全体の流れを把握します。
- よくあるトラブルとその原因
OpenTelemetryをプロダクション環境で導入した際に直面することの多いトラブルをいくつか紹介します。例えば、以下のような問題が取り上げられます。
- メトリクスやトレースが意図した通りに収集されない
- 特定のサービスでエージェントが正常に動作しない
- データパイプラインが断続的に失敗する
これらの問題の原因を探るための手順を解説します
- トラブルシューティングの方法と解決策
よくあるトラブルに対する具体的な解決方法を説明します。例えば、エージェントの設定ミス、ネットワーク関連の問題、バックエンドへのデータ送信が不安定なケースなどについて、どのように診断し、修正するかを解説します。また、適切なログの確認方法や、トラブル解決を容易にするデバッグツールの使用についても触れます。
- テレメトリーデータの活用を始めるためのステップ
OpenTelemetryを効果的に導入し、オブザーバビリティを高めるためのステップについて議論します。初期の設定から本格的なデータ可視化・分析まで、どのような段階を踏んで進めていくべきかを具体的にアドバイスします。例えば、小規模なテスト環境での計装から本番環境への展開、データの収集・保存・分析のための適切なツールの選定などです。
■ 対象聴衆とその人たちが得られるもの
- SRE、開発者
- トラブルシュートやパフォーマンス問題に悩む人
- 開発/運用プロセスの改善を考えている人
- OpenTelemetryを使い始めようと思っている人
- OpenTelemetryを試したことがあるけどうまく動かなくて「？」ってなった経験がある人
- オブザーバビリティの向上が必要だと思っている人
■ なぜこのトピックについて話したいのか（モチベーション）
私の経験が皆さまのお役に立てればと思い・・・
SIEMによるセキュリティログの可視化と分析を通じた信頼性向上プロセスと実践
川崎 雄太 ■ 発表カテゴリ
・Case Studies: 実際の導入事例や失敗談
■ 発表概要（400字程度）
昨今、DDoS攻撃や不正アクセスなど、Webサービスが攻撃にさらされる機会は増加の一途を辿っています。
セキュリティ運用の温度感は高くなっており、SREチームが兼務している企業も少なくないのではないでしょうか。
一般的なセキュリティ対策として、問題特定や予兆検知に用いるセキュリティログ管理が重要です。
セキュリティ領域でのログやイベント管理をSIEMと呼びます。
ココナラではセキュリティチームだけでなく、SREチームもセキュリティ運用に取り組んでいます。
以前は何も動けていませんでしたが、今では日々のメトリクスモニタリングに運用を組み込み、信頼性向上に寄与しています。
セキュリティ運用整備をSREチームがやることで信頼性向上に繋げた事例や、SIEM運用のつまづき・メリット / デメリットを紹介します。
この発表でチームの垣根を超えた信頼性向上の取り組みやSIEMのノウハウを得られると幸いです。
■ 発表の詳細（1000字程度）
以下の章立てでお話をします。
- ココナラで抱えていたセキュリティの課題
- セキュリティログ分析へのアプローチ
- セキュリティの課題をどのように解決していったか？
- SIEMの導入効果
- 今後の取り組み
ココナラはもともと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への取り組みや監視改善
■ 対象聴衆とその人たちが得られるもの
・信頼性向上に向けたSRE × セキュリティ観点のアプローチ、キャリアパスの広がり
・特にAWS環境におけるセキュリティログ分析・モニタリングの取り組みと実践
・SIEMでできること、SIEM on Amazon Open SearchServiceのより良い使い方
■ なぜこのトピックについて話したいのか（モチベーション）
セキュリティの専門組織を持っていない会社、持っていてもプロダクトのセキュリティログ分析に工数が割けない会社が多いと思います。
SREは1つのロールなので、職種横断で取り組むべきプラクティスですし、セキュリティという切り口でSREの裾野を広げることがこのイベントの趣旨にあっていると考えたからです。
SREに対しては、
・SRE × セキュリティのプラクティスで技術もキャリアも幅が広がる
を伝えていき、セキュリティエンジニアに対しても
・実は業務の一部がSREを実践している
・セキュリティ起点でプロダクトの価値向上に大いに貢献できる
というのを伝えることで、キャリアパスの広がりや業務のシナジーを生み出していきます。
実践: Database Reliability Engineering ~ クラウド時代のデータベースエンジニアの役割 ~
粟田 啓介 ■ 発表カテゴリ
募集要項（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 管理
- スクラム
- DBRE を支える技術
- 実際のアウトプットの例
- データベースパスワードの安全なローテーション
- 生成 AI を活用したスキーマレビュー
- プロジェクト開始前に作成したインセプションデッキとデモを用いて共有します
■ 対象聴衆とその人たちが得られるもの
特にデータベースの運用や信頼性に関心を持つSREエンジニア、システム設計者、エンジニアリーダーを対象としています。
参加者は、データベースを軸とした Reliability Engineering について実践的なアプローチを学び、実際の導入事例から得られた教訓を自身の組織に応用するための具体的な手法とアイデアを得ることができます。
■ なぜこのトピックについて話したいのか（モチベーション）
私たちは、DBRE を実践するために様々な挑戦をしてきました。DBREという分野において、単なる技術的な解決策だけでなく、チームの文化や組織としての取り組みも重要です。
これまでの経験を共有することで、同じような課題に直面している他のエンジニアやチームの助けになりたいと考えています。
また、データベースを軸とした Reliability Engineering という視点を広め、SREコミュニティにも知見の共有と改善に貢献したいという思いから、このトピックを選択しました。
Site Reliability Engineering on Kubernetes
nwiizo ■ 発表カテゴリ
募集要項（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実践に関する新たな視点と具体的なアプローチを得られ、より信頼性の高いシステムと組織の実現に向けた一歩を踏み出せることを願っています。
Re:Define 可用性を支えるモニタリング、パフォーマンス最適化、そしてセキュリティ
P山 ■ 発表カテゴリ
Tech: SREを支える具体的な技術や手法
■ 発表概要（400字程度）
SREは、システムの安定運用だけでなく、幅広い技術的な課題に対応する責任を持ちます。このセッションでは、モニタリング、パフォーマンス改善、そしてセキュリティの観点から、SREがどのようにシステムの信頼性を確保すべきかを体系的に解説します。システムの健全性を把握するためのモニタリング手法、パフォーマンス最適化に必要な実践的なアプローチ、さらにセキュリティ対策を通じて可用性を守るための戦略を取り上げます。特定のツールに依存せず、柔軟な運用方法と幅広い適用可能性を意識した内容を提供します。SREとして直面する日常の課題を深く掘り下げ、より包括的な視点での実践的なアドバイスを得ることができます。
■ 発表の詳細（1000字程度）
このセッションでは、SREが担うべき広範な技術領域について、具体的な方法論と実践事例を交えて紹介します。
まず、モニタリングの重要性を中心に、システムの健全性を常に把握するための効果的なモニタリング手法について議論します。どのようなツールを使うかに依存せず、システムの状態を適切に監視し、早期に問題を発見するための最適なアプローチを考察します。さらに、アプリケーションの動作状況を可視化し、パフォーマンスボトルネックを特定するためのテクニックも紹介します。オブザーバビリティの観点から、システム全体の信頼性を高める方法に焦点を当てます。
次に、パフォーマンス最適化の分野について、実際の経験を基にした具体的な事例を紹介します。Linuxカーネルのパラメーター調整によるシステムの最適化や、アプリケーションコードにおけるN+1問題の解消など、システムの性能を向上させるための実践的な手法を掘り下げます。また、過剰なトラフィックを効率的に制御し、システムの安定性を維持するための対策についても説明します。
最後に、セキュリティの側面について議論します。可用性を確保するためには、システムが常にセキュアであることが前提条件です。SREとして、どのようなセキュリティ対策が求められるのか、特に攻撃や不正アクセスに対する防御がシステム全体の信頼性にどのように寄与するかを解説します。これらの課題を通して、SREが技術的な観点だけでなく、運用とセキュリティの両方を統合的に管理する必要性を再認識します。
■ 対象聴衆とその人たちが得られるもの
このセッションは、中堅のSREエンジニアや、SREを目指すエンジニアを対象としています。彼らは、SREが対応すべき幅広い技術領域についての体系的な知識を得るとともに、現場で実際に使える具体的なモニタリング手法やパフォーマンス最適化の技術、さらにセキュリティ対策の重要性を学ぶことができます。特定のツールに依存しない柔軟な方法論を知ることで、各自の職場に適したSREのベストプラクティスを取り入れることができるようになるでしょう。
■ なぜこのトピックについて話したいのか（モチベーション）
SREとしての役割が多岐にわたる一方で、その守備範囲が明確でない場合が多いと感じています。日常の運用業務だけでなく、パフォーマンスの最適化やセキュリティ対策にも深く関わるべきだと考えています。私自身が直面してきた実務上の課題やその解決方法を共有することで、多くのエンジニアがより幅広い視点を持ち、SREとしての職責を再定義できるようになることを目指しています。このトピックを通じて、SREがシステム信頼性の中核を担う役割を再認識し、より効果的な運用を支援したいと考えています。