Schedule

8/3 13:35 - 14:15

Reliable Systems through Platform Engineering

Infrastructure breaks, but systems can persist! We really want systems that withstand unavoidable failures. Abstractly, we understand that. In this talk, Steve presents concepts like spanning failure domains and using generic mitigations through Platform Engineering, as well as introducing a lab environment where teams can experiment with these capabilities directly and a community where we can discuss it all, memes and all.

8/3 14:30 - 15:10

工学としてのSRE再訪

SREが普及するにつれて、システム管理のアプローチは技芸から工学（科学）へ移り変わっています。2010年発行の書籍ウェブオペレーションでは、「ウェブオペレーションは技芸であり、科学ではない。」と書かれています。システム管理の個別具体的な要素技術はコンピュータサイエンスに依るとしても、個別技術の集合体と人間が統合されたサービスを正常に稼働させ続けることは技芸の範疇にありました。そして、SRE普及以後は、ユーザー視点に基づくエンドツーエンドの信頼性を定義・計測し、計測結果に基づいて、開発・運用の意思決定を行う工学的アプローチがとられるようになりました。しかし、システム管理の分野を技芸から工学へと昇華させるための土台となる知識や過程、その精神は、現在のエンジニアコミュニティには共有されていないままに思えます。 そこで、本発表では、コンピュータサイエンス、ソフトウェア工学、信頼性工学、認知科学などの工学・科学分野がSREにどのように接続されているかを、歴史的な論文や書籍、SREcon、LISAなどのプレゼンテーションを基に、発表者の見解を交えながら、紐解いていきます。

8/3 14:30 - 15:10

組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜

インシデントの復旧対応はその緊急度の高さから必ず行われますが、組織的に対応するための仕組みづくりは後回しにされがちです。 また、いざ仕組みづくりをしようと思っても、ベストプラクティスを安易に導入するだけでは不十分であり、自社の対応フローやカルチャーを踏まえた上で効果的かどうかを慎重に見極める必要があるため一筋縄ではいきません。 結果として、復旧メインの対応フローからなかなか改善が進まず、対応者が特定のメンバーに偏る（属人化）という問題が生じ、それが常態化することも珍しくありません。 そこで、本セッションでは、インシデントマネジメントにおける自社の現在地を把握し、段階的に仕組みづくりをしたいと考えるエンジニアに向けて、組織的なインシデント対応を主眼としたインシデント対応成熟度モデル（IRMM: Incident Response Maturity Model）を紹介します。 また、このモデルを活用したインシデントマネジメントの評価方法や各レベルごとの改善のステップについてお話します。

8/3 14:30 - 15:10

Becoming SRE - SREって何から始めればいいの？ - ①

8/3 15:10 - 15:20

Becoming SRE - SREって何から始めればいいの？ - ②

8/3 15:30 - 15:50

DevSecOpsの内回りと外回りで考える持続可能なセキュリティ対策

発表の主旨 Snykを活用した持続可能なセキュリティ運用を発表します。 背景、課題の共有 DevSecOps、ShiftLeftとはの説明とそれが求められる背景について説明します。 そして、それらの実現を目指すべく実践した内容とそこで表出した課題を説明します。 課題に対してアプローチした内容 上述の課題に対してアプローチした内容をDevOpsの「内回り」と「外回り」に分けて説明します。 「内回り」では開発プロセス初期からセキュリティを組み込む「Shift Left」戦略に焦点を当て、開発者主導のセキュリティ対策で実現できたこと、できなかったことを紹介します。 「外回り」ではデプロイ後の運用環境におけるセキュリティ監視や対応方法など、運用段階でのセキュリティ対策で実現できたこと、できなかったことを紹介します。 組織にDevSecOpsを定着させるためのステップ 最後に、ここまでのまとめとしてDevSecOpsを実現するために必要な取り組みを紹介します。 開発者の負担を下げながらセキュリティ運用を導入することが大事なことや、組織全体に導入するために必要な準備についても触れます。

8/3 15:30 - 15:50

Managing OS Lifecycle: A Deterministic Approach

Deploying an operating system on a host in a datacenter environment is preferred over PXE and kickstart-based mechanisms at scale. However, with the variety of incoming hardware changing every year, it is hard to manage OS packages across the fleet. In this talk, we will share our humble attempt at standardization and making OS deployment across the fleet more deterministic and consistent.

8/3 15:30 - 15:50

巨大インフラ産業で戦うSRE

オープンロジは2013年の創業以来、「物流の未来を、動かす」というミッションを掲げ、従来はアナログでの作業が多かった業務をデジタル化し、効率化を進めてきました。 物流は社会にとって重要なインフラであり、社会インフラとなるサービスを提供するオープンロジにとおいて、システムの障害は大きな問題です。 もしシステムが停止すると物流自体も止まり影響範囲が大きいため、私たちにとってサービスの信頼性は非常に重要です。 当発表では、オープンロジがこれまでどのようにしてサービスの信頼性を高めてきたのか、そして将来的に目指している姿についてお話しします

8/3 16:05 - 16:25

スポンサーLT

『An Efficient Incident Response Training with AI』 属人的ではなく組織的なインシデント対応能力の向上は、MTTR を短縮することに加え、バス係数といったリスクの軽減、SREの負担軽減、Alert Fatigueのリスク低下などにも寄与します。 しかし、実際のインシデントの最中にはMTTRを最小限に抑えることが求められるため、リアルタイムのインシデントをトレーニングの機会として利用するのは困難です。 また、インシデントレスポンスのトレーニングはシナリオの生成やファシリテーションの難しさから、多くの企業で頻繁に行われているとは言いづらいと考えています。 この問題を解決するため、AIの技術を活用してインシデントレスポンスのトレーニングのファシリテーションと現実に即したインシデントシナリオの生成を試みます。 本発表では、実際に AI の技術を活用してインシデントレスポンスのトレーニングを行った様子について紹介します。 『「一人目」はいかがですか？ちょうどギフティって会社があるんですが……』 ギフティでは BtoB, BtoC, CtoC, GtoC の複数の事業領域と、それらに紐づく合計 50 名ほどのエンジニアが自律的にプロダクトを開発・運用しています。およそ 2 年ほど前、「開発生産性を高めるための、複数のチームを横断した基盤づくり」をミッションとするチームが組成されました。複数のチームに対してコミュニケーションを行うことが前提になるチームはこれが初めてで、自分はその「一人目」でした。SRE に限らず、これからそういったロールを経験することになる方への糧になるような話をします。 『グローバルなコーディング試験サービスの信頼性向上に向けた負荷試験とスケーリングの実施』

8/3 16:05 - 16:25

スポンサーLT

『chocoZAPの成長を支えるインフラの裏側』 皆さん、chocoZAPをご存知ですか？ 約1年で会員数が100万人を突破したライザップが運営するコンビニジム。本日は、その急成長を支えるインフラについて、具体的なサーバ構成やリクエスト数などを交えながら簡潔にご説明いたします。 『アンドパッドのマルチプロダクト戦略を支えるSRE』 アンドパッドは、建築・建設現場の効率化から経営改善まで一元管理できるクラウド型建設プロジェクト管理サービスです。機能やプロダクトは多岐にわたりますが、基本的には現場に関わる方々を巻き込んで、コミュニケーションを取ったり、情報共有したり、報告を上げたりということができるようなものになっております。 私たちは、マルチプロダクト戦略を通じて建築・建設現場の非効率をなくし、働く人を幸せにすることを目指しています。そして、このミッションを縁の下から支えているのがSREチームです。SREチームは、アンドパッドを安定稼働させるため、マイクロサービスアーキテクチャ、クラウドネイティブ、インフラセキュリティ、DevOps、o11yなど様々な技術を駆使し、日々成長するサービスの改善に取り組んでいます。 本講演では、社会にインパクトを与えるプロダクト開発、成長するサービス・開発組織でのSREの苦労や面白さをご紹介します。 『大規模SaaS「カイポケ」のフルリニューアルを裏で支えるSREの取り組み』 介護事業者向けの経営支援サービス「カイポケ」のフルリニューアルPJを裏で支えるSREの取り組みについて紹介します。現行のカイポケは約40の機能・サービスを提供しており、そのリニューアルはシステム面・ビジネス面で多くの課題が伴う不確実性の高いPJです。当初このPJはSRE（およびインフラ担当）の人員が開発者に比べて少数で限られた状況で開始しました。その中でSREがどのように課題に取り組んできたか、また今後取り組んでいくのかについて話します。

8/3 16:35 - 17:15

日本最大口座数を保有するSBI証券のAWSマイグレーションを支えたサービスとソリューション

SBI証券は、新サービスの導入に伴う取引量の増加に備え、オンライン取引システムをAWSへ移行しました。本システム移行には、AWSのサービスであるAWS Fault Injection Service(以下、AWS FIS)を活用することで、障害をシミュレートし、システムの予期せぬ停止に対する対処方法を検証することで高可用性と拡張性を実現し、AWS Distributed Load Testingを利用して大規模な負荷をシミュレートすることで、顧客サービスの安定稼働と需要増加への対応力を確保し、低遅延、高可用性、高パフォーマンスなミッションクリティカルなシステムの移行に成功しました。

8/4 09:35 - 10:15

宇宙科学研究所の探査機運用システムにおけるSREのプラクティスの導入と月着陸実証機SLIMでの利用

宇宙探査機および人工衛星の運用においては、その状態を正確に把握するために地上システムが不可欠です。JAXA宇宙科学研究所は50年以上にわたる衛星運用の歴史を持っていますが、地上システムおよびソフトウェアは古い設計のままであり、さまざまな改善が必要です。最近ではオープンソースソフトウェアの活用を含めた衛星・探査機の監視システムの現代化について検討を進めています。 2023年9月に打ち上げられた月着陸機SLIMの運用ではこのアプローチに基づいたシステムが部分的に利用されました。例えば、Grafanaなどのツールを導入してObservabilityの改善を試みています。月着陸に成功する2024年1月20日までの期間、我々はSREという言葉を知らないまま開発や利用を進めましたが、結果的にこの取り組みは「SREのプラクティスを探査機運用に導入した」と言うことができます。 本講演では、我々のシステム構成の詳細、実際のデータを使用した画面の紹介、そして導入に至る意思決定や開発・利用の過程について、SREの視点を交えて再整理しながら解説します。

8/4 10:30 - 10:50

オブザーバビリティのマクロからミクロまで〜あるいはなぜ技術書を翻訳するのか ①

SREの中でも最も重要なプラクティスであるオブザーバビリティですが、これはシステムや組織のどのレベルで持つべきものなのでしょうか。マクロなレベルで持つオブザーバビリティと、ミクロなレベルで持つオブザーバビリティは大局的には同じでも、細かな部分ではそのサイクルを含めて異なってきます。本セッションでは組織でオブザーバビリティを導入する際の大局的なサイクルと、開発チーム〜個人レベルでのミクロのサイクルの違いを紹介し、組織における各単位で必要となる戦略を詳らかにします。 また私がさまざまなSRE関連書籍を翻訳・監訳しているの理由を、この観点から紹介します。SREの実践の各段階にある方々に、各書籍の内容の紹介と、それらが先に紹介しているオブザーバビリティプロセスのどの段階を解説するものなのかの位置づけを解説し、先に紹介したプロセスをスムーズに実践するための足がかりにするためのポインターを提示します。

8/4 10:30 - 10:50

プロダクトのスケールによって顕在化しうるリスクをどう管理するか？

株式会社diniiでは、飲食店の注文や会計を行うプロダクト群を提供しています。システム障害によって注文や会計が失敗すると、飲食店が営業できなくなるほどのインパクトがあるため、日々安定性を向上するための取り組みを行っています。 今回の発表では、"System Risk Records" と呼んでいるドキュメントを活用し、プロダクトの成長に伴って顕在化しうるリスク情報をどのように管理・対応しているかという取り組みについて紹介します。 System Risk Records は、リスクのインパクトやリスクが顕在化しうるタイミングの把握することで適切な時期にアクションを行い、アクションの記録を学びとして残しておくために活用しており、ドキュメントのフォーマットや活用事例について紹介できればと思います。

8/4 10:30 - 10:50

大きな組織にSLOを導入し運用するということ、その難しさ ①

DMMのプラットフォーム開発本部という部署では現在SLI/SLO導入の推進活動を行っており、長いチームだと現在では1年以上の運用実績があります。 DMMという大きな組織にSLOを導入する際には多種多様なチームがいます。 その中でサポート活動やガイドラインの設定といった活動を行った上で、計装やSaaSの仕様など多くの壁にあたりました。 今回、どのようにSLO導入推進しているのかに加え、実際長期間SLOを運用をしないと見えてこない課題点・反省点を含めて発表させていただこうと思います。

8/4 11:00 - 11:20

オブザーバビリティのマクロからミクロまで〜あるいはなぜ技術書を翻訳するのか ②

SREの中でも最も重要なプラクティスであるオブザーバビリティですが、これはシステムや組織のどのレベルで持つべきものなのでしょうか。マクロなレベルで持つオブザーバビリティと、ミクロなレベルで持つオブザーバビリティは大局的には同じでも、細かな部分ではそのサイクルを含めて異なってきます。本セッションでは組織でオブザーバビリティを導入する際の大局的なサイクルと、開発チーム〜個人レベルでのミクロのサイクルの違いを紹介し、組織における各単位で必要となる戦略を詳らかにします。 また私がさまざまなSRE関連書籍を翻訳・監訳しているの理由を、この観点から紹介します。SREの実践の各段階にある方々に、各書籍の内容の紹介と、それらが先に紹介しているオブザーバビリティプロセスのどの段階を解説するものなのかの位置づけを解説し、先に紹介したプロセスをスムーズに実践するための足がかりにするためのポインターを提示します。"=

8/4 11:00 - 11:20

Central SREとEmbedded SREのハイブリッド体制で目指す最高のSRE組織

エムスリーは医療業界で多数のプロダクトを展開しており、それに合わせて開発組織にはおよそ20のチームが存在しています。その中でSRE組織は、横断チームとして全体に関わるSRE (Central SRE) と、各開発チームに所属してプロダクトを担当するSRE (Embedded SRE) の2種類からなるハイブリッドな体制をとっています。 数年前、まだ社内でオンプレミス環境が主流だった時代はEmbedded SREは存在せず、Central SREが多くの責務を担う集中型の組織でした。その後、全社的なクラウド移行の推進という大きなきっかけと、開発チームの裁量が大きいという組織の特徴に合わせて、SRE組織はハイブリッドな形へとシフトしていきました。SRE組織の体制については実事例やプラクティスを多くみかけますが唯一の正解はなく、自社に最適な形を目指して継続的に改善していく姿勢が重要だと考えています。 本発表では、弊社の組織変遷の経験から得られたSRE組織の体制の考え方と、現在のハイブリッドな体制の実践例についてお話しします。

8/4 11:00 - 11:20

大きな組織にSLOを導入し運用するということ、その難しさ ②

DMMのプラットフォーム開発本部という部署では現在SLI/SLO導入の推進活動を行っており、長いチームだと現在では1年以上の運用実績があります。 DMMという大きな組織にSLOを導入する際には多種多様なチームがいます。 その中でサポート活動やガイドラインの設定といった活動を行った上で、計装やSaaSの仕様など多くの壁にあたりました。 今回、どのようにSLO導入推進しているのかに加え、実際長期間SLOを運用をしないと見えてこない課題点・反省点を含めて発表させていただこうと思います。

8/4 11:30 - 11:50

内製化を見据えた効果的なSRE支援のアプローチ

株式会社スリーシェイクのSreake事業部では、お客様と連携し、SRE導入から内製化までをクラウドネイティブな視点から支援する総合的なサービスを提供しています。 本セッションでは、SRE支援を通じてお客様の状況や課題に合わせてSREプラクティスを導入させるための実践的なアプローチや、支援のゴールである内製化に必要な要素について詳しく解説します。また、SRE支援で起こりうる特有の課題や困難についても紹介し、どのように対処すれば良いかを解説します。 事業部内発足型のSREとは異なる視点から、SRE導入・内製化の成功に繋がる実践的な知見を共有します。

8/4 11:30 - 11:50

SRE文化の導入とプラットフォームの信頼性向上の取り組み

株式会社CAMは、「乃木坂46 Mobile」や「すとぷり」などのファンクラブサイトを自社プラットフォームで運用しています。 ファンクラブサイトでは、チケット先行販売時の突発的な負荷により、同一プラットフォームで運用している他のサービスが不安定になるという課題を抱えていました。また、数十人のエンジニアが同一プラットフォームで複数のサービス開発をしているため、SREチームだけでプラットフォームの信頼性を維持・向上させることが難しい状況でした。 そういった課題を解決するために、開発組織へSRE文化をインストールし、プラットフォームの信頼性を維持・向上させる為に行った取り組みについて紹介します。

8/4 11:30 - 11:50

SLO を満たせなくなったら

SLO を満たせなくなった場合にどういう対応をとるのがよいと思いますか。 このセッションでは、 - インシデントの分析により何が一番SLOに悪影響を与えるかをきちんと把握 - 効果的なポストモーテムによる失敗を克服できるチームづくり - リスク分析で予測される将来のトラブルの影響度の推測 という3つのテーマでおすすめの対応の紹介をします。

8/4 13:00 - 13:20

徹底的な自動化とトイルの撲滅で実現する効率的なSREの実践例

本発表では、数十のウェブサイトを限られた人数で構築・運用するための徹底した自動化とトイルの撲滅手法を紹介します。 1. IaCのモジュール化とテンプレート化: terraformのテンプレート化により、大量のインフラを効率的に構築・管理する手法を解説します。 2. モノレポによるCI/CDの効率化: terraformコードをモノレポで一元管理し、CI/CDリソースを最適化した方法を紹介します。 3. 脆弱性の継続的な予防・検知・対応: アップデートツールやクラウドサービスを駆使して、脆弱性検知と自動アップデートを実現した手法を説明します。 4. モニタリングとアラート、障害対応: 少人数運用に必要十分なモニタリングとアラート設計、障害例とその対応について紹介します。 5. 信頼性を担保する組織体制: 少人数での運用を支えるルールや体制、組織との連携について解説します。 これら発表を通じて、少人数での運用の効率化と信頼性向上をどのように実現したかを共有します。

8/4 13:00 - 13:20

SLOの理解を深めて、ユーザーエクスペリエンスを向上する方法

サービスレベル目標（SLO）は、ユーザーエクスペリエンスや信頼性を測定するための指標です。このセッションでは、適切なサービスレベル指標（SLI）を選択し、利害関係者との適切な合意を定義することによってより適切なSLOを定義する方法が学べます。また、エラーバジェットの重要な概念や、ユーザーエクスペリエンスの理解を深めるための具体的な質問例もご紹介します。

8/4 13:00 - 13:20

プロダクト全体で取り組むSREing：イシューから始める信頼性/生産性向上の実践

即戦力人材と企業をつなぐ転職サイト「ビズリーチ」は2009年のサービス開始以来成長を続け、今ではスカウト可能会員数は236万人以上のユーザーにご利用いただくサービスに成長をしました。 「キャリアインフラになる」という株式会社ビズリーチのビジョンを実現するプロダクトとなるべく、SREチームに留まらず、開発者・プロダクトマネジャー・カスタマーサクセスを巻き込み、職能横断でSREingを実践しています。 我々は「イシューからはじめる」アプローチを採用しており、事業成長に伴い直面した様々な問題に対し、解く価値のある課題を特定して、プロダクトを段階的に改善してきました。 本発表を通じ、事業成長を支えるSREingの実践方法と具体的成果を共有します。

8/4 13:30 - 13:50

本人確認サービスにおける信頼性の定義とアラート対応の継続的改善

TRUSTDOCKは、金融機関から一般事業会社まで、あらゆる事業における本人確認（eKYC/KYC）業務の課題を解決する企業です。 柔軟に組み込むが可能なAPI/SDK/ネイティブアプリを提供しており、様々な企業のユーザー登録等の導線に組み込まれています。 当社のサービスが使えなくることは、組み込み先のユーザー登録の導線が止まることに直結するため、当社システムの信頼性に対する期待値が高くなることが多々あります。 その期待に応えるために、基本的なアラートの運用、そしてSLIの設定など、継続的な改善を繰り返しています。 継続的な改善を繰り返す中で、信頼性を定義するには「本人確認」というドメインへの理解をしたうえで、各ステップで適切な信頼性の定義を行うことが重要であることに気づきました。 課題も含めて、我々の取り組みを紹介をします。

8/4 13:30 - 13:50

事業フェーズの変化を乗り越えるEnabling/Platform SREへの転換

創業から6年、ビットキーのSite Reliability Engineeringは、初期から信頼性を支えてきたメンバーの入れ替わり、プロダクトの普及、事業拡大により大きく変化しました。 その変化に伴い、信頼性の重要性も一層高まり、SREチームは開発チームに直接参加して伴走するEmbedded SREから、全社横断のEnabling/Platform SREへの転換を図っています。 本セッションでは、この転換を成功させるために実践しているアプローチを紹介します。 一例として、プロダクトチームとSREチームによる定期MTGを取り上げ、全員でのSLO確認、プロダクト横断の観点でシステム運用に関するトピックのフィードバック、インシデントのポストモーテム実施のプラクティス紹介します。 最後に、SLOの策定と運用にまつわる課題と将来の展望を紹介します。 この発表を通じて、事業フェーズや組織体制に応じたSREチームのあり方について、事例を通じた情報を提供します。

8/4 13:30 - 13:50

500万人が利用する「友達と遊べるたまり場アプリ パラレル」におけるデータベース基盤の継続的改善

『友達と遊べるたまり場アプリ パラレル』では、クラウドベンダーによる不定期メンテナンスや季節イベントによるアクセス急増によってデータベースが不安定になり、最終的にサービスダウンに発展することが過去何度かありました。その都度、ポストモーテムを行うことで、『パラレル』はデータベース基盤の耐障害性と安定性を高めてきました。 中でも、タイムアウト・サーキットブレーカー・コネクションプーリングプロキシという三つの機構はサービスの急成長と信頼性の維持に効果的でした。これらは汎用性が高い対策ではありますが、それぞれに独自の実装の複雑さも伴います。 このセッションでは、『パラレル』がこれまで経験してきた障害とその対応策、そしてポストモーテムを通じて、どのようにデータベース基盤の耐障害性と安定性を向上させてきたのかについて詳しくお話しします。具体的な実装については、MySQL、Semian、Toxiproxy、Vitessを例に挙げて解説する予定です。

8/4 14:10 - 14:30

SRE の考えをマネジメントに活かす

このセッションでは、SRE (Site Reliability Engineering) の経験を活かし、組織の信頼性とパフォーマンスを維持するためのマネジメントスキルについて解説します。SREとマネージャーの役割の違いや共通点を明確にし、具体的な業務内容を例にして応用方法を紹介します。アラート対応、人材育成、リスク管理、組織設計など、SREのスキルをマネジメントにどのように転用できるかを具体例を交えて説明します。人間はシステムとは異なるため、同じアプローチは通用しない場面もありますが、同じメンタルモデルを適用できるケースもあることを示し、実践的なヒントを提供します。

8/4 14:10 - 14:30

Enabling Client-side SLO

Luupでは、電動アシスト自転車、電動キックボードなどの電動マイクロモビリティのシェアリングサービス「LUUP」を提供しています。Luup SREチームでは、各開発チームがSREを実践しSLI/SLOを自律的に設計・実装・運用できるようにEnabling SREを進めています。「Enabling SREを進める」とはいえSREのプラクティスは多くあるため、まずはSREのコアとなる要素であるSLOをEnablingすることにしました。 これまでは、開発組織全体とIoT開発チームに対してEnabling SLOをおこなってきました（SRE NEXT 2023の登壇）。この活動をさらに拡大するため、クライアントサイド（iOS, Android）のSLOを計測し始めた話を共有します。 AndroidやiOSの開発チームを巻き込みながら、プロダクトマネージャーと共にクライアントサイドのSLOを運用し始めるまでの取り組みを、スタートアップ独特の企業の特性や課題を踏まえて共有します。

8/4 14:10 - 14:30

SREの技術トレンド2024 ①

8/4 14:40 - 15:00

スタートアップの急成長に寄り添うOn-Call体制構築とその変遷

サービスの信頼性を維持しユーザに機能提供を続ける上でOn-Callの運用は必要不可欠であり、業務でこれに参加し関わっている人も多いでしょう。一方で体制の構築から運用フロー整備までは比較的泥臭い側面も多く、組織やフェーズによって要件も異なるためノウハウが多く流通していないように感じます。 私が所属する株式会社10Xでは、サービスや組織の急拡大に合わせてゼロからOn-Call体制の構築を行ってきました。そこで弊社のSREチームがどのようなプロセスを経て体制の導入と安定化を実現したか、組織の変遷をなぞりつつ事例を紹介します。 本発表ではPagerDutyやDataDogによるモニタリングからTerraformによる自動化といった技術的トピックだけでなく、実際にOn-Callを行っていくにあたって組織内でどのような取り組みを行ったか、技術面以外でのチャレンジについても重点的にお話しします。

8/4 14:40 - 15:00

SkyWayが遭遇したWebRTC の可観測性に関する問題と開発者向け可視化サービス提供までの道のり

WebRTCは、ビデオ会議などで利用されている身近な技術です。 しかし、実際にはリアルタイム通信を実現するための処理は複雑で、様々な理由で不具合が発生します。 皆様もビデオ会議サービスで「音声が途切れる」「映像がカクつく」などの通話不具合を経験したことがあるのではないでしょうか。 WebRTCの通話不具合はコードのバグだけでなく、ブラウザバージョンやクライアントの端末種別、ネットワーク状況など様々な理由で発生します。 WebRTC特有の情報も合わせて参照し、不具合調査を行うためには工夫が必要です。 SkyWayではWebRTCアプリケーションの不具合調査を実現するために、WebRTC専用のObservabilityシステムを開発しました。そして、このObservabilityシステムを社内活用するだけでなく、ユーザーフレンドリーに可視化するSkyWay Analyticsという機能をβ公開しています。 本セッションでは、リアルタイム通信における可観測性の重要性と発生する問題、そして、SkyWayが開発者向けに可視化サービスを提供するに至った理由について紹介します。

8/4 14:40 - 15:00

SREの技術トレンド2024 ②

8/4 15:20 - 15:40

敵対的SRE: 300個のジョブをAIチーム全員で支える技術

エムスリーのAI・機械学習チームでは、10人ほどのチームメンバーが300個以上のジョブを運用しています。 それだけ多くのジョブを運用するには、SREの考え方を応用した効率的な監視が必要です。 本発表では、チーム全員が運用を効率化するために如何に全体を網羅したアラートを作っていくか・運用者負担を減らすために如何にアラートを絞るかをどう進めたかをお話します。 まるで生成器と識別器の２つが敵対的に学習し合い精度を高めるGANというアルゴリズムのように、アラート検出とアラート削減をし合いながらシステムの信頼性を向上させてきた知見の発表です

8/4 15:20 - 15:40

Enabling SRE by Guide Maps

この発表では、エンジニア組織全体で SRE を実践するためのガイドライン整備の取り組みについてご紹介します。 日本経済新聞社のエンジニア組織は 80 人を超える集団に成長しました。私たちは、日経電子版をはじめ、良質なビジネスコンテンツをお届けする NIKKEI COMPASS など、多岐にわたるサービスを次々に展開しています。 サービスと組織の成長に伴い、私たち日経 SRE チームはいくつかの課題に直面しました。 1. 開発チームに SRE プラクティスを普及させるにあたり、どこから着手すべきか明確でない 2. 各開発チームでどのくらい SRE プラクティスが浸透しているか、把握しづらい 3. SRE チームと各開発チームとの間で、信頼性に関してどのような部分に課題があるか不明瞭になりがち 4. 機能開発が高速に進み、可観測性やドキュメントなどの信頼性に関わる部分の改善が後回しになる これらの解決のために、弊社で試みている SRE 実践のためのトレイルマップの提供をはじめ、ポストモーテムやドキュメントライティングなどに関するガイドラインの整備について紹介します。

8/4 15:20 - 15:40

LT

『社内留学を通じて加速するプロダクトチームとのコラボレーション』: Erika Takada 組織全体でSREの影響力を拡大する重要なタイミングにおいては、プロダクトチームとの信頼関係強化や相互理解が不可欠です。 弊社では、プロダクトチームからSREチームへの社内留学制度を通じて、下記のような取り組みを実施しました。 ・SREの役割と重要性についての議論 ・プロダクトのシステム構成図の作成 ・監視設定およびアラート対応プロセスの標準化 ・SREツールの共同開発 ・複数のプロダクトチームとの定期的なプロダクションミーティングへの参加 このセッションでは、これらの相互学習のプロセスがどのようにして両チーム間の相互理解と信頼関係を強化したかを詳しく解説します。 『複業SRE、どこまでいける？』: sogaoh 縁も運もあってか、今自分はなんと4社で明示的にSREロールを担う/もしくは委託されています。 暗黙的もしくは自称を加えるとあと数社これに乗ってきます。 ただでさえ、そう簡単ではない複業でのSRE稼業を、どのように掴み・回し・前に進めているのか。 振り返りつつ、プラスの面・マイナスの面を整理して、現状をご紹介します。 2024年7月時点の、課題に感じていることと直近数年程の展望も、お話ししたいと思います。 『現実と理想のSRE組織とは』: 田口 雅教 私はサイバーエージェントで、複数プロダクトを担当するSRE組織の開発責任者をしています。スタイルとしては、EmbeddedSREとPlatformSREとCenter Of Practiceの3視点を用いてチームの魅力を上げていけるように日々奮闘しています。 SREが主体的になれること、主体的になれないことや、評価ポイントや、悔しいところなど発表できればと思います 『FourKeysを導入したが生産性向上には至らなかった理由』: 島 翔平 DORAチームのOSSをベースにFourKeysを導入してみましたが、開発生産性の可視化と改善は単純なものではありませんでした。 用意されたFourKeysの指標を導入するだけでは、我が組織が計測すべき適切な指標や、本質的な課題を見つけられませんでした。 本講演では、FourKeysを実際に導入する際に直面した課題や、得られた学びについてお話しいたします。

8/4 15:50 - 16:10

開発チームへのディープダイブで見えてきた 顧客 = 開発者 の本当の課題

本発表では、新機能開発チームの開発生産性向上を目指してイネーブルメントチームのメンバーとして体験した学びを紹介いたします。当初、開発者からのヒアリングを通じても、不確実性が高い新機能開発チームの全ての要求に応えることは難しく、重要な課題の特定も困難でした。そこで、開発チームの一員として実際の開発に参加し、直面する課題や高い認知負荷、実現困難な要求を自らの体験を通じて収集しました。これらの課題に対して、初めは個人的に解決策を模索し、次にそれを標準化することで、真に必要なプラットフォームのみを効率よく開発し、提供することが可能となりました。このプロセスを経ることで、ヒアリングだけでは得られなかった課題の解像度が明らかに向上し、実体験に基づく適切なソリューションを提供し、プラットフォームの開発を段階的に進めることができました。

8/4 15:50 - 16:10

SREが考えるハイブリッド開催の技術イベントのライブ配信における信頼性

最近、現地会場とオンライン会場を併用したハイブリッド形式で開催される技術イベントが増えています。それに伴い、視聴者数の観点からもライブ配信の重要性が高まっています。 配信が本業ではないSREが、小規模な技術イベントやコミュニティイベントの配信を複数手掛けてきた経験をもとに、『信頼性』や『品質』をどのように向上させてきたかを、試行錯誤の過程を交えて紹介します。