はじめに
こんにちは、GENEROSITYのgenimuraです。
8/3, 8/4に行われました、SRE NEXT 2024に参加してきたので参加レポートをします。
あまり、撮影出来ておらず、Xで #srenext, #srenext_a, #srenext_b, #srenext_c のハッシュタグを検索すると詳しく様子が見れると思います！
今回まとめたのは、下記のとおりになります！
- 登壇資料まとめ(随時更新予定)
- スポンサーブースレポート
- アンケート結果(撮影したものだけ掲載)
-
オフライン限定開催パネルディスカッション(両日分)レポート
1. 「Becoming SRE」SREって何から始めればいいの？
2. SREの技術トレンド2024 - 感想まとめ
SRE NEXT 2024って？
信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンスです。 同じくコミュニティベースのSRE勉強会である「SRE Lounge」のメンバーが中心となり運営・開催されます。 SRE NEXT 2024のテーマは「Beyond NEXT」です。SRE NEXT 2023で掲げた価値観 Diversity、Interactivity、Empathyを大切にしつつ、SREの担う幅広い技術領域のトピックや組織、人材育成に対してディスカッションやコミュニケーションを通じて、新たな知見や発見を得られる場にします。
SRE Loungeというコミュニティを中心とした年に1回のイベントです！
SRE NEXT 2024 HP
今年で4回目になるイベントで、オフライン(Ameba Towers)/オンライン同時開催で行われました。
登壇資料まとめ(随時更新予定)
工学としてのSRE再訪
概要
SREが普及するにつれて、システム管理のアプローチは技芸から工学（科学）へ移り変わっています。2010年発行の書籍ウェブオペレーションでは、「ウェブオペレーションは技芸であり、科学ではない。」と書かれています。システム管理の個別具体的な要素技術はコンピュータサイエンスに依るとしても、個別技術の集合体と人間が統合されたサービスを正常に稼働させ続けることは技芸の範疇にありました。そして、SRE普及以後は、ユーザー視点に基づくエンドツーエンドの信頼性を定義・計測し、計測結果に基づいて、開発・運用の意思決定を行う工学的アプローチがとられるようになりました。しかし、システム管理の分野を技芸から工学へと昇華させるための土台となる知識や過程、その精神は、現在のエンジニアコミュニティには共有されていないままに思えます。
組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜
概要
インシデントの復旧対応はその緊急度の高さから必ず行われますが、組織的に対応するための仕組みづくりは後回しにされがちです。
また、いざ仕組みづくりをしようと思っても、ベストプラクティスを安易に導入するだけでは不十分であり、自社の対応フローやカルチャーを踏まえた上で効果的かどうかを慎重に見極める必要があるため一筋縄ではいきません。
結果として、復旧メインの対応フローからなかなか改善が進まず、対応者が特定のメンバーに偏る（属人化）という問題が生じ、それが常態化することも珍しくありません。
そこで、本セッションでは、インシデントマネジメントにおける自社の現在地を把握し、段階的に仕組みづくりをしたいと考えるエンジニアに向けて、組織的なインシデント対応を主眼としたインシデント対応成熟度モデル（IRMM: Incident Response Maturity Model）を紹介します。
また、このモデルを活用したインシデントマネジメントの評価方法や各レベルごとの改善のステップについてお話します。
DevSecOpsの内回りと外回りで考える持続可能なセキュリティ対策
概要
発表の主旨
Snykを活用した持続可能なセキュリティ運用を発表します。
背景、課題の共有
DevSecOps、ShiftLeftとはの説明とそれが求められる背景について説明します。
そして、それらの実現を目指すべく実践した内容とそこで表出した課題を説明します。
課題に対してアプローチした内容
上述の課題に対してアプローチした内容をDevOpsの「内回り」と「外回り」に分けて説明します。
「内回り」では開発プロセス初期からセキュリティを組み込む「Shift Left」戦略に焦点を当て、開発者主導のセキュリティ対策で実現できたこと、できなかったことを紹介します。
「外回り」ではデプロイ後の運用環境におけるセキュリティ監視や対応方法など、運用段階でのセキュリティ対策で実現できたこと、できなかったことを紹介します。
組織にDevSecOpsを定着させるためのステップ
最後に、ここまでのまとめとしてDevSecOpsを実現するために必要な取り組みを紹介します。
開発者の負担を下げながらセキュリティ運用を導入することが大事なことや、組織全体に導入するために必要な準備についても触れます。
巨大インフラ産業で戦うSRE
概要
オープンロジは2013年の創業以来、「物流の未来を、動かす」というミッションを掲げ、従来はアナログでの作業が多かった業務をデジタル化し、効率化を進めてきました。
物流は社会にとって重要なインフラであり、社会インフラとなるサービスを提供するオープンロジにとおいて、システムの障害は大きな問題です。
もしシステムが停止すると物流自体も止まり影響範囲が大きいため、私たちにとってサービスの信頼性は非常に重要です。
当発表では、オープンロジがこれまでどのようにしてサービスの信頼性を高めてきたのか、そして将来的に目指している姿についてお話しします
An Efficient Incident Response Training with AI
概要
属人的ではなく組織的なインシデント対応能力の向上は、MTTR を短縮することに加え、バス係数といったリスクの軽減、SREの負担軽減、Alert Fatigueのリスク低下などにも寄与します。
しかし、実際のインシデントの最中にはMTTRを最小限に抑えることが求められるため、リアルタイムのインシデントをトレーニングの機会として利用するのは困難です。
また、インシデントレスポンスのトレーニングはシナリオの生成やファシリテーションの難しさから、多くの企業で頻繁に行われているとは言いづらいと考えています。
この問題を解決するため、AIの技術を活用してインシデントレスポンスのトレーニングのファシリテーションと現実に即したインシデントシナリオの生成を試みます。
本発表では、実際に AI の技術を活用してインシデントレスポンスのトレーニングを行った様子について紹介します。
アンドパッドのマルチプロダクト戦略を支えるSRE
概要
アンドパッドは、建築・建設現場の効率化から経営改善まで一元管理できるクラウド型建設プロジェクト管理サービスです。機能やプロダクトは多岐にわたりますが、基本的には現場に関わる方々を巻き込んで、コミュニケーションを取ったり、情報共有したり、報告を上げたりということができるようなものになっております。
私たちは、マルチプロダクト戦略を通じて建築・建設現場の非効率をなくし、働く人を幸せにすることを目指しています。そして、このミッションを縁の下から支えているのがSREチームです。SREチームは、アンドパッドを安定稼働させるため、マイクロサービスアーキテクチャ、クラウドネイティブ、インフラセキュリティ、DevOps、o11yなど様々な技術を駆使し、日々成長するサービスの改善に取り組んでいます。
本講演では、社会にインパクトを与えるプロダクト開発、成長するサービス・開発組織でのSREの苦労や面白さをご紹介します。
オブザーバビリティのマクロからミクロまで〜あるいはなぜ技術書を翻訳するのか
概要
SREの中でも最も重要なプラクティスであるオブザーバビリティですが、これはシステムや組織のどのレベルで持つべきものなのでしょうか。マクロなレベルで持つオブザーバビリティと、ミクロなレベルで持つオブザーバビリティは大局的には同じでも、細かな部分ではそのサイクルを含めて異なってきます。本セッションでは組織でオブザーバビリティを導入する際の大局的なサイクルと、開発チーム〜個人レベルでのミクロのサイクルの違いを紹介し、組織における各単位で必要となる戦略を詳らかにします。
また私がさまざまなSRE関連書籍を翻訳・監訳しているの理由を、この観点から紹介します。SREの実践の各段階にある方々に、各書籍の内容の紹介と、それらが先に紹介しているオブザーバビリティプロセスのどの段階を解説するものなのかの位置づけを解説し、先に紹介したプロセスをスムーズに実践するための足がかりにするためのポインターを提示します。
プロダクトのスケールによって顕在化しうるリスクをどう管理するか？
概要
株式会社diniiでは、飲食店の注文や会計を行うプロダクト群を提供しています。システム障害によって注文や会計が失敗すると、飲食店が営業できなくなるほどのインパクトがあるため、日々安定性を向上するための取り組みを行っています。
今回の発表では、"System Risk Records" と呼んでいるドキュメントを活用し、プロダクトの成長に伴って顕在化しうるリスク情報をどのように管理・対応しているかという取り組みについて紹介します。
System Risk Records は、リスクのインパクトやリスクが顕在化しうるタイミングの把握することで適切な時期にアクションを行い、アクションの記録を学びとして残しておくために活用しており、ドキュメントのフォーマットや活用事例について紹介できればと思います。
大きな組織にSLOを導入し運用するということ、その難しさ
概要
DMMのプラットフォーム開発本部という部署では現在SLI/SLO導入の推進活動を行っており、長いチームだと現在では1年以上の運用実績があります。
DMMという大きな組織にSLOを導入する際には多種多様なチームがいます。
その中でサポート活動やガイドラインの設定といった活動を行った上で、計装やSaaSの仕様など多くの壁にあたりました。
今回、どのようにSLO導入推進しているのかに加え、実際長期間SLOを運用をしないと見えてこない課題点・反省点を含めて発表させていただこうと思います。
Central SREとEmbedded SREのハイブリッド体制で目指す最高のSRE組織
概要
エムスリーは医療業界で多数のプロダクトを展開しており、それに合わせて開発組織にはおよそ20のチームが存在しています。その中でSRE組織は、横断チームとして全体に関わるSRE (Central SRE) と、各開発チームに所属してプロダクトを担当するSRE (Embedded SRE) の2種類からなるハイブリッドな体制をとっています。
数年前、まだ社内でオンプレミス環境が主流だった時代はEmbedded SREは存在せず、Central SREが多くの責務を担う集中型の組織でした。その後、全社的なクラウド移行の推進という大きなきっかけと、開発チームの裁量が大きいという組織の特徴に合わせて、SRE組織はハイブリッドな形へとシフトしていきました。SRE組織の体制については実事例やプラクティスを多くみかけますが唯一の正解はなく、自社に最適な形を目指して継続的に改善していく姿勢が重要だと考えています。
本発表では、弊社の組織変遷の経験から得られたSRE組織の体制の考え方と、現在のハイブリッドな体制の実践例についてお話しします。
内製化を見据えた効果的なSRE支援のアプローチ
概要
株式会社スリーシェイクのSreake事業部では、お客様と連携し、SRE導入から内製化までをクラウドネイティブな視点から支援する総合的なサービスを提供しています。
本セッションでは、SRE支援を通じてお客様の状況や課題に合わせてSREプラクティスを導入させるための実践的なアプローチや、支援のゴールである内製化に必要な要素について詳しく解説します。また、SRE支援で起こりうる特有の課題や困難についても紹介し、どのように対処すれば良いかを解説します。
事業部内発足型のSREとは異なる視点から、SRE導入・内製化の成功に繋がる実践的な知見を共有します。
SRE文化の導入とプラットフォームの信頼性向上の取り組み
概要
株式会社CAMは、「乃木坂46 Mobile」や「すとぷり」などのファンクラブサイトを自社プラットフォームで運用しています。
ファンクラブサイトでは、チケット先行販売時の突発的な負荷により、同一プラットフォームで運用している他のサービスが不安定になるという課題を抱えていました。また、数十人のエンジニアが同一プラットフォームで複数のサービス開発をしているため、SREチームだけでプラットフォームの信頼性を維持・向上させることが難しい状況でした。
そういった課題を解決するために、開発組織へSRE文化をインストールし、プラットフォームの信頼性を維持・向上させる為に行った取り組みについて紹介します。
徹底的な自動化とトイルの撲滅で実現する効率的なSREの実践例
概要
本発表では、数十のウェブサイトを限られた人数で構築・運用するための徹底した自動化とトイルの撲滅手法を紹介します。
- IaCのモジュール化とテンプレート化: terraformのテンプレート化により、大量のインフラを効率的に構築・管理する手法を解説します。
- モノレポによるCI/CDの効率化: terraformコードをモノレポで一元管理し、CI/CDリソースを最適化した方法を紹介します。
- 脆弱性の継続的な予防・検知・対応: アップデートツールやクラウドサービスを駆使して、脆弱性検知と自動アップデートを実現した手法を説明します。
- モニタリングとアラート、障害対応: 少人数運用に必要十分なモニタリングとアラート設計、障害例とその対応について紹介します。
- 信頼性を担保する組織体制: 少人数での運用を支えるルールや体制、組織との連携について解説します。
これら発表を通じて、少人数での運用の効率化と信頼性向上をどのように実現したかを共有します。
引用元
プロダクト全体で取り組むSREing：イシューから始める信頼性/生産性向上の実践
概要
即戦力人材と企業をつなぐ転職サイト「ビズリーチ」は2009年のサービス開始以来成長を続け、今ではスカウト可能会員数は236万人以上のユーザーにご利用いただくサービスに成長をしました。
「キャリアインフラになる」という株式会社ビズリーチのビジョンを実現するプロダクトとなるべく、SREチームに留まらず、開発者・プロダクトマネジャー・カスタマーサクセスを巻き込み、職能横断でSREingを実践しています。
我々は「イシューからはじめる」アプローチを採用しており、事業成長に伴い直面した様々な問題に対し、解く価値のある課題を特定して、プロダクトを段階的に改善してきました。
本発表を通じ、事業成長を支えるSREingの実践方法と具体的成果を共有します。
事業フェーズの変化を乗り越えるEnabling/Platform SREへの転換
概要
創業から6年、ビットキーのSite Reliability Engineeringは、初期から信頼性を支えてきたメンバーの入れ替わり、プロダクトの普及、事業拡大により大きく変化しました。
その変化に伴い、信頼性の重要性も一層高まり、SREチームは開発チームに直接参加して伴走するEmbedded SREから、全社横断のEnabling/Platform SREへの転換を図っています。
本セッションでは、この転換を成功させるために実践しているアプローチを紹介します。
一例として、プロダクトチームとSREチームによる定期MTGを取り上げ、全員でのSLO確認、プロダクト横断の観点でシステム運用に関するトピックのフィードバック、インシデントのポストモーテム実施のプラクティス紹介します。
最後に、SLOの策定と運用にまつわる課題と将来の展望を紹介します。
この発表を通じて、事業フェーズや組織体制に応じたSREチームのあり方について、事例を通じた情報を提供します。
500万人が利用する「友達と遊べるたまり場アプリ パラレル」におけるデータベース基盤の継続的改善
概要
『友達と遊べるたまり場アプリ パラレル』では、クラウドベンダーによる不定期メンテナンスや季節イベントによるアクセス急増によってデータベースが不安定になり、最終的にサービスダウンに発展することが過去何度かありました。その都度、ポストモーテムを行うことで、『パラレル』はデータベース基盤の耐障害性と安定性を高めてきました。
中でも、タイムアウト・サーキットブレーカー・コネクションプーリングプロキシという三つの機構はサービスの急成長と信頼性の維持に効果的でした。これらは汎用性が高い対策ではありますが、それぞれに独自の実装の複雑さも伴います。
このセッションでは、『パラレル』がこれまで経験してきた障害とその対応策、そしてポストモーテムを通じて、どのようにデータベース基盤の耐障害性と安定性を向上させてきたのかについて詳しくお話しします。具体的な実装については、MySQL、Semian、Toxiproxy、Vitessを例に挙げて解説する予定です。
SRE の考えをマネジメントに活かす
概要
このセッションでは、SRE (Site Reliability Engineering) の経験を活かし、組織の信頼性とパフォーマンスを維持するためのマネジメントスキルについて解説します。SREとマネージャーの役割の違いや共通点を明確にし、具体的な業務内容を例にして応用方法を紹介します。アラート対応、人材育成、リスク管理、組織設計など、SREのスキルをマネジメントにどのように転用できるかを具体例を交えて説明します。人間はシステムとは異なるため、同じアプローチは通用しない場面もありますが、同じメンタルモデルを適用できるケースもあることを示し、実践的なヒントを提供します。
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を運用し始めるまでの取り組みを、スタートアップ独特の企業の特性や課題を踏まえて共有します。
スタートアップの急成長に寄り添うOn-Call体制構築とその変遷
概要
サービスの信頼性を維持しユーザに機能提供を続ける上でOn-Callの運用は必要不可欠であり、業務でこれに参加し関わっている人も多いでしょう。一方で体制の構築から運用フロー整備までは比較的泥臭い側面も多く、組織やフェーズによって要件も異なるためノウハウが多く流通していないように感じます。
私が所属する株式会社10Xでは、サービスや組織の急拡大に合わせてゼロからOn-Call体制の構築を行ってきました。そこで弊社のSREチームがどのようなプロセスを経て体制の導入と安定化を実現したか、組織の変遷をなぞりつつ事例を紹介します。
本発表ではPagerDutyやDataDogによるモニタリングからTerraformによる自動化といった技術的トピックだけでなく、実際にOn-Callを行っていくにあたって組織内でどのような取り組みを行ったか、技術面以外でのチャレンジについても重点的にお話しします。
SkyWayが遭遇したWebRTC の可観測性に関する問題と開発者向け可視化サービス提供までの道のり
概要
WebRTCは、ビデオ会議などで利用されている身近な技術です。
しかし、実際にはリアルタイム通信を実現するための処理は複雑で、様々な理由で不具合が発生します。
皆様もビデオ会議サービスで「音声が途切れる」「映像がカクつく」などの通話不具合を経験したことがあるのではないでしょうか。
WebRTCの通話不具合はコードのバグだけでなく、ブラウザバージョンやクライアントの端末種別、ネットワーク状況など様々な理由で発生します。
WebRTC特有の情報も合わせて参照し、不具合調査を行うためには工夫が必要です。
SkyWayではWebRTCアプリケーションの不具合調査を実現するために、WebRTC専用のObservabilityシステムを開発しました。そして、このObservabilityシステムを社内活用するだけでなく、ユーザーフレンドリーに可視化するSkyWay Analyticsという機能をβ公開しています。
本セッションでは、リアルタイム通信における可観測性の重要性と発生する問題、そして、SkyWayが開発者向けに可視化サービスを提供するに至った理由について紹介します。
敵対的SRE: 300個のジョブをAIチーム全員で支える技術
概要
エムスリーのAI・機械学習チームでは、10人ほどのチームメンバーが300個以上のジョブを運用しています。
それだけ多くのジョブを運用するには、SREの考え方を応用した効率的な監視が必要です。
本発表では、チーム全員が運用を効率化するために如何に全体を網羅したアラートを作っていくか・運用者負担を減らすために如何にアラートを絞るかをどう進めたかをお話します。
まるで生成器と識別器の２つが敵対的に学習し合い精度を高めるGANというアルゴリズムのように、アラート検出とアラート削減をし合いながらシステムの信頼性を向上させてきた知見の発表です
Enabling SRE by Guide Maps
概要
この発表では、エンジニア組織全体で SRE を実践するためのガイドライン整備の取り組みについてご紹介します。
日本経済新聞社のエンジニア組織は 80 人を超える集団に成長しました。私たちは、日経電子版をはじめ、良質なビジネスコンテンツをお届けする NIKKEI COMPASS など、多岐にわたるサービスを次々に展開しています。
サービスと組織の成長に伴い、私たち日経 SRE チームはいくつかの課題に直面しました。
- 開発チームに SRE プラクティスを普及させるにあたり、どこから着手すべきか明確でない
- 各開発チームでどのくらい SRE プラクティスが浸透しているか、把握しづらい
- SRE チームと各開発チームとの間で、信頼性に関してどのような部分に課題があるか不明瞭になりがち
- 機能開発が高速に進み、可観測性やドキュメントなどの信頼性に関わる部分の改善が後回しになる
これらの解決のために、弊社で試みている SRE 実践のためのトレイルマップの提供をはじめ、ポストモーテムやドキュメントライティングなどに関するガイドラインの整備について紹介します。
社内留学を通じて加速するプロダクトチームとのコラボレーション
概要
組織全体でSREの影響力を拡大する重要なタイミングにおいては、プロダクトチームとの信頼関係強化や相互理解が不可欠です。
弊社では、プロダクトチームからSREチームへの社内留学制度を通じて、下記のような取り組みを実施しました。
・SREの役割と重要性についての議論
・プロダクトのシステム構成図の作成
・監視設定およびアラート対応プロセスの標準化
・SREツールの共同開発
・複数のプロダクトチームとの定期的なプロダクションミーティングへの参加
このセッションでは、これらの相互学習のプロセスがどのようにして両チーム間の相互理解と信頼関係を強化したかを詳しく解説します。
複業SRE、どこまでいける？
概要
縁も運もあってか、今自分はなんと4社で明示的にSREロールを担う/もしくは委託されています。
暗黙的もしくは自称を加えるとあと数社これに乗ってきます。
ただでさえ、そう簡単ではない複業でのSRE稼業を、どのように掴み・回し・前に進めているのか。
振り返りつつ、プラスの面・マイナスの面を整理して、現状をご紹介します。
2024年7月時点の、課題に感じていることと直近数年程の展望も、お話ししたいと思います。
現実と理想のSRE組織とは
現実と理想のSRE組織とは
私はサイバーエージェントで、複数プロダクトを担当するSRE組織の開発責任者をしています。スタイルとしては、EmbeddedSREとPlatformSREとCenter Of Practiceの3視点を用いてチームの魅力を上げていけるように日々奮闘しています。
SREが主体的になれること、主体的になれないことや、評価ポイントや、悔しいところなど発表できればと思います
FourKeysを導入したが生産性向上には至らなかった理由
概要
DORAチームのOSSをベースにFourKeysを導入してみましたが、開発生産性の可視化と改善は単純なものではありませんでした。
用意されたFourKeysの指標を導入するだけでは、我が組織が計測すべき適切な指標や、本質的な課題を見つけられませんでした。
本講演では、FourKeysを実際に導入する際に直面した課題や、得られた学びについてお話しいたします。
開発チームへのディープダイブで見えてきた 顧客 = 開発者 の本当の課題
概要
本発表では、新機能開発チームの開発生産性向上を目指してイネーブルメントチームのメンバーとして体験した学びを紹介いたします。当初、開発者からのヒアリングを通じても、不確実性が高い新機能開発チームの全ての要求に応えることは難しく、重要な課題の特定も困難でした。そこで、開発チームの一員として実際の開発に参加し、直面する課題や高い認知負荷、実現困難な要求を自らの体験を通じて収集しました。これらの課題に対して、初めは個人的に解決策を模索し、次にそれを標準化することで、真に必要なプラットフォームのみを効率よく開発し、提供することが可能となりました。このプロセスを経ることで、ヒアリングだけでは得られなかった課題の解像度が明らかに向上し、実体験に基づく適切なソリューションを提供し、プラットフォームの開発を段階的に進めることができました。
SREが考えるハイブリッド開催の技術イベントのライブ配信における信頼性
概要
最近、現地会場とオンライン会場を併用したハイブリッド形式で開催される技術イベントが増えています。それに伴い、視聴者数の観点からもライブ配信の重要性が高まっています。
配信が本業ではないSREが、小規模な技術イベントやコミュニティイベントの配信を複数手掛けてきた経験をもとに、『信頼性』や『品質』をどのように向上させてきたかを、試行錯誤の過程を交えて紹介します。
スポンサーブースレポート
合計で14社のスポンサーブースがありました。(スポンサーは抽選で選ばれたみたいです、どこかにアーカイブが残っていたはず。)
順番にレポートしていきます。
-
サイバーエージェント
会場スポンサーとして参加です。
FFのゲームを支えるインフラの構成図を見せていただきました！
ノベルティには、SRE Technology MapというサイバーエージェントさんのSREたちが取り組んできたまとめを限定100冊配布していました。
他にもアベマくんの貯金箱(職人が一つ一つ作っているらしい)やお弁当箱などの配布がありました。 -
スリーシェイク
ダイアモンドスポンサーとして参加です。
抽選をやっていました。自分は両日ともハズレで飴をいただきましたが、当たりにはAnkerのモバイルバッテリーがありました。 -
ミクシィ
ダイアモンドスポンサーとして参加です。
アンケートを実施しておりました。(が結果を撮り忘れてしまいました)「SREチームとして導入したもののなかで、一番効果が出たと感じたことは？」「あなたが助けてほしい領域は？」というアンケートを実施していました！
回答すると、SREの領域(Automation, Incident, Monitoring等)のバッチをもらえました。
Incidentがアラートのマークでうっとなりました。もらいました。
あと、オラゴンが可愛かったです。 -
snyk
ダイアモンドスポンサーとして参加です。
フォームアンケートを回答すると豪華なノベルティを配布しておりました！
YETIのマグカップや、マスコットの犬のPatchのスクリーンクリーナー兼スマホ立てぬいぐるみ、マルチケーブルとかを配布しておりました。(トートバッグもすごいしっかりしていました)
ウェビナーにも申し込むことで、さらにノベルティを配布しておりました！スゴイ -
オープンロジ
プラチナスポンサーとして参加です。
「過去イチ大変だった障害を教えてください！」というテーマでアンケートを実施していました。
見てるだけで胃が痛くなるような気持ちになりました🥺
回答すると、お箸とかラムネジュースをいただけました！
あと、「私は S〇〇 Reliability Engineer です！」という大喜利もやっていて、無茶振りされました😂
Sushi とか Sakeは皆さん書いてますねっとネタも潰されていったので、涙目になりながら(冗談です)とりあえず「Super」って書いてきました。 -
Datadog
プラチナスポンサーとして参加です。
クリアファイルを配布していました！
デモ会をメインに実施しておりました。
私は触ったことがあったので体験しませんでしたが、常にデモをされていた印象がありました！ -
VISIONAL
プラチナスポンサーとして参加です。ビズリーチの会社ですね。
「いま注力しているサービスの信頼性の階層を教えてください」というテーマでアンケートを実施していました。
回答するとTシャツがもらえました。回答に対して今抱えている課題とかを軽くお話出来て良かったです！ -
ANDPAD
ゴールドスポンサーとして参加です。
アンケートと、抽選くじをやっていて、アンケートに回答すると建設業界なので軍手がもらえました。(エンジニア向けに指先が空いているものを作ったそうです。)
抽選くじは、エコバッグやドライバーセット等がもらえるようでした。 -
トポタル
ゴールドスポンサーとして参加です。
Waroomというインシデント対応サービスを提供していて、そちらのデモを実施していました。
SREが少ない組織にはピッタリのインシデント対応サービスだと思いました。
自分はいただいていないですが、ドリップバッグを配っていました。 -
BloomBerg
ゴールドスポンサーとして参加です。
Bloomberg Terminalというサービスのダッシュボードが見れる体験会を実施していました。
最新の金融ニュースや、株価をリアルタイムでウォッチするためのサービスのようです。
めちゃめちゃカッコいいダッシュボードで、キーボードも特製で作られていてデザインがいいなと思いました。
ノートやトートバッグ等を配布していました。 -
ギフティ
ゴールドスポンサーとして参加です。
ギフティにはたくさんのサービスがあって、そのエコシステムについてのお話をお聞きしました。
また、アンケートで「私の組織・プロダクト ここをなんとかしたい！」というテーマをやっていました。
アンケートに回答すると、めちゃくちゃ美味しいらしいドリップバッグをいただけました。 -
SMS
ゴールドスポンサーとして参加です。
アンケートを実施していました。
1日目は「あなたの好きな構成管理ツールは？」、2日目は「あなたの好きなCI/CDツールは？」というテーマでやっておりました。
また、フォームアンケートに回答すると、サプリメントケースも配布しておりました。
さらに、絵文字バッジや、SNSのアイコンをバッジにしてくれるという面白い企画をやっていました！(作ってもらいました) -
HireRoo
ゴールドスポンサーとして参加です。
エンジニアの採用時にスキルチェックを支援するサービスを提供していてそちらのデモ画面の提供と、
SRE用に用意されたテスト問題を出しており回答すると、Baseのクッキーやゴディバのクッキーをいただけました！ -
RIZAP
ゴールドスポンサーとして参加です。
アンケートを実施していて、「障害発生時の初動で最初に確認することは？」と「週に何日出社していますか？」というテーマのアンケートを実施しておりました。
また、フォームアンケートに回答すると、LEDリングライト、ライティングタブレット(黒板みたいな)、スマホスタンド、万歩計をもらえました！スゴイ -
本部
スポンサーブースを回るとスタンプをもらえてスタンプラリーが完了すると、SRE NEXTのマスコットキャラクターけろぺんの手ぬぐいがもらえました。抽選くじも実施していて、けろぺんグッズや、SRE NEXTグッズ(タンブラー)を配っていました！
あと、SREギーククイズを実施していて、結果(SLO)によって景品が変わる企画もやってました。
僕は勘と記憶をたどりながら、信頼性カレーをもらえました🎉(難しすぎて2日目はSLOが下がっていたみたいですね😁)
アンケート結果(撮影したものだけ掲載)
RIZAP アンケート
- 障害発生時の初期対応で最初に確認することはなんですか？
- 週に何日出社していますか？
SRE NEXT アンケート
- あなたのSREタイプは？
- SLO導入レベル
- SRE Practice どれが好き？
- あなたのSRE・エンジニア歴は？
- 使用している監視ツール
- SRE本読んでいる？
- SREチームの担っている役割
VISIONAL アンケート
- いま注力しているサービスの信頼性の階層を教えてください
オープンロジ アンケート
- 過去イチ大変だった障害を教えてください！
SMS アンケーㇳ
- あなたの好きな構成管理ツールは？
撮影出来ておらず、1日目の構成管理ツールはTerraformが圧倒的に多くて次点AWS CDKでした。 - あなたの好きなCI/CDツールは？
ギフティアンケート
- 私の組織・プロダクト ここをなんとかしたい！
オフライン限定開催パネルディスカッション(両日分)レポート
2つのオフライン限定のパネルディスカッションのレポートです。
- 「Becoming SRE」SREって何から始めればいいの？
- SREの技術トレンド2024
聞きながらメモしていたのと、不足分は記憶を引っ張りだして記載している部分もあるため、語弊があるかもしれませんがご了承ください。(改善要望があればご連絡ください)
1. 「Becoming SRE」SREって何から始めればいいの？
登壇者
-
LINEヤフー Service Embedded SRE team leader maru
- SWE、DBAなどを経て、2020年12月にLINE株式会社に入社。
- 主にLINEスタンプやLYP PremiumでEmbedded-SREとして活動。
- 2023年10月よりLINEヤフー株式会社。SREのように歩き、SREのように鳴くときに
-
スリーシェイク 代表取締役社長 吉田 拓真 (taqqma_ikachan)
- オンプレインフラエンジニア、クラウドエンジニア、SREを経て2015年にスリーシェイクを創業。
- SREを主軸にクラウドネイティブ化/エンジニアリング内製化支援を行う。
-
LayerX バクラク事業部 PlatformEngineering部 DevOps グループ マネージャー 星 北斗 (kani_bkanny)
- 大規模WebサービスのSRE、セキュリティエンジニア、CTO/CISOを経て2024年1月より現職。
- SREに加え複数領域に責任を持ち、お客様に信頼して使っていただけるサービスづくりを行う。
-
株式会社サイバーエージェント事業責任者 兼 SRE柘植 翔太 (shotaTsuge)
- 2014年新卒入社。
- 横断SRE組織の事業責任者/SREとして、SRE推進やリスク改善、サービス立ち上げなどに取り組む。
- SRE領域のDeveloper Expertとしてグループ全体の技術力発展や人材育成にも注力。
- データで見るサイバーエージェントグループのSREと横断的なSRE推進の取り組み
SREのフェーズライフサイクル
SREのフェーズにはライフサイクルがあるが、本パネルディスカッションでは、立ち上げ・成長フェーズにフォーカスする
- 創成期 立ち上げフェーズ
- 成長期 成長フェーズ
- 安定・フェーズ
- 衰退・再成長フェーズ
Q1. SRE組織の立ち上げフェーズにまずやることは？
maruさん
- 一番最初にやったこと&良かったこと
- LINEスタンプという10年動いてた(当時)サービス運用で、その組織で名前がついていないSREのプラクティスに名前を付けていったこと、SREとしての種火を保護&認知の受け入れを意識した
- もっとこうしてよかったなってこと
- ライブラリのdependencyのアップデート→ いつも誰か同じ人がやっているという属人性解消のために、Renovate導入をして猛反発をくらったこと
- 問題があるところに火を付けたらやってくれると思った→ 単純に仕事が増えた(すでに忙しかったDevがさらにつらくなってしまった)
- ライブラリのdependencyのアップデート→ いつも誰か同じ人がやっているという属人性解消のために、Renovate導入をして猛反発をくらったこと
- 事業理解がないと、信頼性を下げてしまう課題に対してのアプローチがしにくい
余談
- 障害対応をちょうど先日やった
ポストモーテムをしたが、事業部長?にSREはDeepContributorなのかFacilitatorなのかを問われた。- どっちの帽子もかぶるときがある
- 中立にいないといけないし、サービスも深くしっておかないといけない
- 関わっている開発組織のフェーズによるが、成熟していくと、DeeopContributorとしての側面が強くなっていくかも
ツゲさん
- SREの課題を可視化をすることにやっぱり反発はある
- 組織にとっては、自分たちが出来ていないということが明るみになって反発されやすいことがある
- サービスとか事業に対してどこまで理解があるのかが大事
- SREに興味を持ってもらうときはEmbeddedというよりもFacilitatorとしての側面が強めのほうがいいかも
- その後、ビジネスフローとか、ボトルネックを見つける事ができるようになっていく
- 事業理解をしてコアな部分から始める
星さん
- なぜ解決するのかを用意し、セットしてあげる
- モチベーションを上げてあげる
- ビジネスインパクトと対応コストを話してDeveloperと同じ目線で話す
- ToCのサービスからToBのサービスに携わるようになったとき一番最初にやったこと
- サービスが提供しているコアの部分を実際にサービスを使いながら探していくこと
- 最終的なアウトプットがビジネス的な価値を生み出している理解をしてもらう
- 最終的にやりたいことの目線を揃えることが大事
- サービスが提供しているコアの部分を実際にサービスを使いながら探していくこと
吉田さん
- SREが一番正しいとか、一番偉いっていう風に思われるとあんまりうまくいかない
- みんなと同じ目線・立場で良いサービス作っていきたいというゴールを忘れない
- 開発エンジニアと信頼性を築く
- コアのDeveloperを巻き込む
- まずサービスとか競合のサービスを触ってみて理解を深める
Q2. SREの採用・育成ってどうしてる？
吉田さん
- 年間で30人ぐらいSREを採用してる状況
- 技術的な魅力やスキルの話ではなくて、サービスを良くしていくというところに対して 縁の下の力持ち→テンションを高めていかないと難しい
- インフラエンジニアという名前を使う人がどんどん減ってきてSREって名乗ってる人が多い
星さん
- 1から採用をしていく余裕はない状況
- 採用するうえで、1番は事業を作っていくことに対して夢中になれるか
- ハート・素養 > インフラ・ソフトウェアスキル
- 一言でSREって言っても全然意味合いが違う
- NWの構築経験やアプリケーション開発の経験が必要
- インフラエンジニア→SREになったとしても、インフラのスキルとかトラブルシュートするスキルはずっと活きている
maruさん
- SREの新卒は取っていない
- ハートとか素養もそうだけど、好奇心お化けみたいな人たちはマッチはするが、コーディングスキルの重要性が高い
- LeetCodeとか競技プログラミングとは違った、サービス・Availability・コストとかを考えながら開発が出来る人を採用している
- 不足しているところにSREが入るような形なのでコーディングはする、Webアプリケーション・モバイルアプリ開発の経験が必須
- 1時間のライブコーディング + 1時間のホワイトボードディスカッションの試験
インフラエンジニアという名前を使う人がどんどん減ってきてSREって名乗ってる人が多い
- 昔はインフラエンジニアの領域は、開発以外のこと全てだった
- 自分たちの仕事を振り返って名前をつけていったときに半分ぐらいがSREの仕事だった
- ただ最近はSREも分業が明確になってきている(Chaos, Embedded, Enabling etc...)
Q. Webやモバイル開発の高レイヤーからの採用しかしていない？
- NWはNWでSREがいる、自分の所属は、バックエンド→ アプリケーション周りのSRE
- プラットフォームエンジニアとSREで分業出来ている
- 〇〇 as a Serviceをしていって、社内のマネージドのランナーがあったり、Developerはそこにあるプラットフォームを使っている感覚と同じ
ツゲさん
- 技術領域単位でSREを切ったりはしていなく、プロダクト単位、子会社単位、事業部全体、基盤単位でそれぞれSREチーム(Embedded)がいる
- 基本的に専属はなくて、プロジェクト単位でSREのメンバーをアサインする
- こういう改善をしたいという提案をしていって対応していく
- ただ、ある程度長くなったりすることもあるので、コロコロ変わるとやりにくいくなる
- 少なからず過去にやったようなメンバーをアサインしたりする
- ただ、ある程度長くなったりすることもあるので、コロコロ変わるとやりにくいくなる
Q3. SREとしての意思決定・実行スピードを落とさないようにしていることは？
星さん
- 自分でやらないといけないことが増えてくる
- 最初から最終的なアウトプットをイメージするようにチームに働きかける
- 何かを判断するときは、それによってサービスがどうなるのか、エンドユーザーにどういうことがおこるのかを考える
maruさん
- 意思決定・実行スピードを落としていった方がいいという意見
- 過去にSREを増やしすぎて、何か新しい取り組みをする際にがSRE内だけでApproveまで完結してしまった
- 結果 Devとの関係性が、「私たちとあなたたち」という分業になってしまった
- SREは全体に対して1割という取り決めをして、アサインする人を減らした
ツゲさん
- そもそもソフトウェアエンジニアが判断が出来るようにしていけばいい
- SREはLabelの一つでしかない
個人的な感想
- 今自分たちがやっていることに名前を付けて上がるっていうのが刺さった。SREとしての業務なんだっていうのを認識するのが第一歩なんだなぁと思った。
- それぞれの会社でSREのDevとのアプローチの仕方も担っていることも違うが、どういう関わり方をしても目的は常にサービスをより良く(信頼性)することなんだと感じた。目的が同じだから役割や関わり方が違っても同じSREとしてコンテクストの土台があるのだと思った。
2. SREの技術トレンド2024
スマホでメモを取っていたので、1のレポートよりも読みにくい + 発言者が追いにくくなっています。ご了承ください。
登壇者
-
一般社団法人 SRE NEXT 代表理事 / 株式会社スタディスト VPoE 北野 勝久
- SRE NEXTの創設者であり、一般社団法人 SRE NEXTの代表理事。
- 株式会社スタディストのSRE兼執行役員VPoE。
-
株式会社Topotal CTO rrreeeyyy
- 株式会社TopotalのCTO。
-
さくらインターネット株式会社 上級研究員 yuuk1
- さくらインターネット研究所のSRE研究者。
- 最近の研究テーマはAI for SRE。
- LLM for SREの世界探索
-
Mercari, Inc. Director of Platform Engineering deeeet
- Mercariのプラットフォームエンジニアリングディレクター。
- 最近はクロスボーダー(JPとEN間)のエンジニアリングにも関わってる
- DevOps、SRE、インフラを担当。
- Platform Engineering at Mercari
テーマ
SRE 技術トレンド2024はみなさんの日常の業務そのものなんじゃない？
ということで、みなさんの普段している仕事を話す
deeetさん
- クロスボーダーの事業に注力してる
- メルカリJP←→EN間で商品が買えるように
- Platform EngineerとSREは明確に分けている
- SREはPlatform EngineerチームとProductチームの間にいる
- SREの中でもCentral SREとEmbedded SREがいる
- 80%の自動化と、残りの20%のよりドメインやビジネスに特化した複雑な課題に取り組むのがSRE
- Domain SpecificなSREが必要
Mercari Hello立ち上げ時のSRE
- 基本一般的な企業にとってPlatform Engineerはオーバースペックになりがち
- 基本的には事業内のSREから規模が多くなってったときにPlatform Engineerのポジションを作っていく
1からSREを立ち上げるなら、どのスコープからやる？必要なパラメータは何？
- なんでマイクロサービス始めたか
- とにかく人が増えてきて、それのスケールに耐えられるようにPlatformを作り始めた
マイクロサービス化に対して再現性がある？
- 今なら、まだモノリスを活かす方法はあったと思う→当時はマイクロサービスが流行ってた
- メルペイで当時のマイクロサービス化に戻った時にどういうアプローチを取るかという振り返りを技術書典で出した
Platform EngineerもSREも達成したい目標は同じ
- サービスを良くするという点では同じで、アプローチが違うだけ
- SREは、サービス信頼性の観点
- Platform EngineerはUXを良くするとか、DevOpsをツール化していくところ
- 外からプラットフォームの提供と、中から→Enabling SRE, Embedded SRE
yuukiさん&レイさん
- LLM for SREの世界探索という記事書いた
- 普段はLLMとSREの研究論文をもれなく読んでいる
- レイさんとyuukiさんは普段からLLMを活用するための技術相談をしている
- まずLLMで出来ないか？と考えるきっかけとなった
WaroomでどういうようにLLMを使ってるか
- 要約→ポストモーテム
- インシデントのラベリング
- インシデントレスポンスのトレーニングにも活用(現在β版)
→ オンサポートのコストを減らすことがLLMでは得意
- 自動振り分けとかラベリング
- SummarizeやCategorizeは得意
- ダイジェスト化(障害に無関係な情報を削減)の課題の最適解はまだないがD-BotやPanda(障害のスナップショットを取るツール)とかは使えそう
LLMを使った何かをするときに考えること
- ワークフローありきで考える→ワークフローの中でどの部分にLLMが活用出来るかを考える
- チャットGUIから考えない
SRE as a Serviceを多種多様な企業に提供してきての共通項は？
- 結局、新しい仕組みを入れても、組織に働きかけないと機能しない
- 組織を変わらないといけなく、それに対してアシストするツールが必要だと感じている
- 例えばSLI/SLOを定める時に、GitHubのソースコードやIaCのコードを読み込んで、エンドポイントまで分かるようにして、SLI/SLOをサジェスト出来るようにするとか
- アシストするフローに対してLLMを使えると感じている
deeeetさん
メルカリではどういう働きかけをするか
- 具体的なProductの問題はSREからPlatform Engineerの経路で全体に適用
- 大きな課題はPlatform EngineerからSREの経路で(ツールのマイグレーションとか)
カンファレンスから見るSREトレンド
-
SRE CONみるといいかも
- インシデントレスポンス
- オブザーバビリティ
- コストマネジメント
- グローバルで新たなプラクティスを模索中
- SRE関連サービスプラクティスをDeveloperがそれを使う時代がくる
個人的な感想
- 他のセッションも聞いた上で、やはりEmbedded SREからがスタートなのは確かそうに感じた。
- Platform化していくハードルは高そうだけども、小さい基盤(IaCのモジュール化やCI/CDの組み込みのオートメーションとか)から作っていくのはすぐにでも出来そう？だと思った。
感想まとめ
最後に感想をまとめて終わりにします。
Code of Conduct(CoC)をすごく感じられた
スポンサーブースを回っていても、スタッフの方とすれ違っても、目が合ったら「こんにちは〜」「お疲れ様です〜」って声をかけられて、参加される全員に対してのリスペクトと自分も含めて良いものを作ろうとする気持ちがあると感じました。
ソロでの参戦で若干不安でしたが、2日間いろいろな方とお話が出来てとても良い体験ができました。
Code of Conduct一部引用
SRE NEXT 行動規範は、SRE NEXT 参加者および SRE NEXT を通じて提供されるコンテンツに適用されます。「SRE NEXT 参加者」には、チケットを購入しご来場した参加者だけでなく、運営スタッフ、スピーカー、スポンサー、その他サポートいただく関係者の皆様を含み、また「SRE NEXT を通じて提供されるコンテンツ」には発表されるトーク内容をはじめ、公式に提供されるコミュニケーションツール（Slack、Xなど）やスタッフが公開するブログ記事などを含みます。
これはイベントに関わるすべての人にとって安心・安全なイベント体験を提供するためのものです。
ハラスメントをしない
SRE NEXT はあらゆるハラスメント行為を認めません。性別、性的指向、身体障害、外見、体型、人種や宗教、以上に限らず、ハラスメントと思われる振る舞いをしてはいけません。
すべての参加者を尊重する
参加者、スピーカー、運営、スポンサー、様々なひとの善意でイベントは成り立っています。それらすべての人々に敬意を払い、攻撃・侮蔑を行う行為、発言をしてはいけません。
参加者の安全を脅かさない
危険物の持ち込み、および会場設備の破壊行為をしてはいけません。
懇親会スゴイ！
懇親会は、Night Clubというクラブ会場で、500人もの人が集まったそうです！
画像はごく一部でとにかくめちゃめちゃ人がいました！
登壇された方や、ブースにいた方とお話ができたり、セッションの感想戦をしたりと面白い話が出来て良かったです！
CloudBaseが懇親会のスポンサーとして参加されていて、Cloudbaseのラベルが貼られたクラフトビールの提供もしていました！
あと、おにぎりが美味しかったです！🍙
Ask the Speakerが良すぎた
今の会社の境遇を聞いた上で質問が出来て、有識者の方々にアプローチの方法や解決方法などの助言をしていただいて大変参考になりました。
また、Speakerの方が逆質問したりしていて議論の場としても有益なコミュニケーションだったと感じました！
個人的な刺さったキーワード・フレーズ
2日間で印象に残った、何度も触れられた、刺さったキーワード・フレーズをいくつか紹介します。
長くなってきたので、詳細は割愛します🥺
気になった方は調べてみてください！
- 信頼性は会話
- SREの分業化(Embedded, Central, Enabling etc...)
- チームトポロジー
- 人間が一番の脆弱性
- 一人目SRE
来年もいこう
すでに2025の開催が決まってます、来年もいきます！
次回までに自分もコミュニティに貢献出来たらいいなぁ、と思ってます。
#srenext
— SRE NEXT (@srenext) August 4, 2024
SRE NEXT 2025 開催決定！ pic.twitter.com/KjVifKbUhK
最後まで読んでいただき、ありがとうございました。
ぜひいいねいただければと思います！