タイムテーブル
9/29 10:05 - 10:45
みなさん、イオンという企業をご存知ですか？ イオンはその前身となる企業を含めれば、創業300年で年間売上９兆円にも及ぶ 超巨大な老舗企業です。 そんな大企業に、どこにでもいる普通の SRE が、昨年 CTO としてたった一人で飛び込みました。当企業の威信をかけたEC新事業をローンチするためです。 本講演では、そんなサービスローンチの舞台裏についてお話致します。
イオンネクスト株式会社 CTO
イオンネクストCTO。元Googleエンジニア、元Retty CTO、元PowerX社外CTO、「脱炭素にワクワクを」樽石デジタル技術研究所代表。
New Relic株式会社
9/29 11:00 - 11:20
SREにとってサービス信頼性維持のための Alert 対応やObservability の実践、組織への普及は欠かせない活動になっているかと思います。今回紹介するGenerative AI を使った New Relic Grok を利用することで、すべてのエンジニアに可観測性を開放する New Relic の次世代の活用方法をご紹介します。
New Relic株式会社 ソリューションコンサルタント
New Relic Solutions Consultant、立ち上げ期のスタートアップや BtoB SaaS 数社でSWEを経験した後に現職。SaaS 全般やテレコミュニケーション系のお客様をメインに担当。暇さえあればゴルフのことが頭に浮かんでしまっておりスコア70台と目指せ350yが当面の目標。
9/29 11:00 - 11:20
ウォンテッドリーでは、明確な『SREチーム』というものはありません。伝統的にインフラチームが SLI/SLO やポストモーテムを企画運用していますが、その運用に各技術領域・各プロダクトのエンジニアが参加し、信頼性に関する問題に対して自律的に動き協業した結果としてシステムの信頼性を維持・向上を実現しています。全員が SRE です。 そしてこの体制で SRE を実践するために、ウォンテッドリーでは開発者のためのプラットフォーム（共通基盤）を作っています。 本セッションではウォンテッドリーの SRE の取り組みを振り返るとともに、そのためのプラットフォーム開発の思想と実践、特に実践では技術やツールをどうやってプラットフォームに導入していくか、開発してきて得られた技術マネジメントの知見を紹介します。
ウォンテッドリー株式会社 インフラエンジニア
株式会社NTTデータ、株式会社リクルートを経て2021年9月よりウォンテッドリー株式会社 / Infrastructure Squad に所属。インフラやデータ基盤領域でソフトウェアエンジニアをやっている者です。Kubernetes Cluster のバージョンアップが得意。
9/29 11:00 - 11:20
LINEスタンプのシステムでは、しばしばキャンペーンや時節のイベントでアクセス数が非常に増えることがあります。特に「あけおめLINE」と呼ばれる年明けの挨拶では、平日ピーク時間帯と比較して13倍ものアクセスが来ます。 このようなシステムの信頼性を維持向上しながら、新機能を安全にかつ迅速にリリースするためには様々なSREingに関連したプラクティスを実践する必要があります。 本セッションでは実際に私たちのチームの一員として、新年対応プロジェクトの3ヶ月を追体験していただきます。
LINE株式会社 SRE
2020年12月にLINE株式会社に入社。LINEアプリのスタンプ、着せかえ、絵文字、ホームタブ、ウォレットタブのSREを担当。
9/29 11:30 - 11:50
ChatGPTでのGPT4モデル公開を皮切りに、ちまたではGenerative AI(生成AI)についての情報が溢れています。 SREとして信頼性に責任を持つ立場からどのようにGenerative AIを付き合っていけばよいのかを考えていくなかで、大きく2つの役割を任せられるのではないかと考えました。 1つ目は情報摂取効率の向上、2つ目はtoil削減の実装の代替です。 検証例をベースに2つの役割の詳細、現状実装に関わる技術要素についてお話しします。
株式会社スリーシェイク
金融メガベンチャー、スタートアップ経験を経て2021/12 株式会社スリーシェイク入社 SRE導入支援をメイン業務として活動中、名前がレアなので検索するとすべてばれる
株式会社リンクアンドモチベーション
9/29 11:30 - 11:50
リンクアンドモチベーションでは現在「モチベーションクラウド」「コミュニケーションクラウド」「ストレッチクラウド」など、複数プロダクトを開発しており、それに加えて独自の組織基盤、契約基盤などがあります。 これらマルチプロダクトの運用にあたり、以下のような課題がありました。 ・既存プロダクト運用と新規プロダクト立ち上げの両立が大変 ・各プロダクトへのSREsの最適なアサインがわからない ・プロダクトごとに技術や運用がバラバラ 本セッションではこれらの課題にどのように取り組んできたかについてご紹介できればと思います
株式会社リンクアンドモチベーション SRE
2021年7月株式会社リンクアンドモチベーションにSREとして入社。新規プロダクトであるストレッチクラウドの立ち上げに携わった後、現在はプロダクトや開発組織拡大のためのインフラ改善を主に担当。
株式会社リンクアンドモチベーション SRE
2019年新卒入社。2020年からSREとして活動。モチベーションクラウドのECS移設から開発メトリクス向上Pjtで4keysの一つであるデプロイ頻度をMiddleからHighへ、生産性の高い組織へと牽引。現在はモチベーションクラウドシリーズ全体の生産性向上に取り組んでいます。
9/29 11:30 - 11:50
SREのインシデント対応の取り組みとして、ポストモーテムは広く知られていますが、皆さまは他にどのような対策を行っていますか？ 本セッションでは、有事の際にスムーズな情報共有とトラブルシューティングを実践するための事前準備として、効率的なインシデント対策の取り組みを紹介します。 具体的には以下の内容を取り上げます： - インシデントの重要度を示す「Severity Levels」の定義 - スムーズな情報共有を可能にする「エスカレーションフロー」の整備 - 避難のない振り返りと効果的な再発防止策の検討「ポストモーテム」の実施 - 定期的 な「Fire Drill（消防訓練）」実践の重要性 本セッションをきっかけに、皆さまがインシデント対策により自信を持ち、素早い対応ができるようになれば幸いです。
株式会社ベガコーポレーション SRE
2017年ベガコーポレーションに入社。翌年にSREグループを設立し、リーダーとして自社プロダクトの信 頼性向上に従事。2023年からコーポレートIT部門まで管轄を広げ全社の信頼性向上とモダナイゼーションに取り組んでいる。
9/29 12:00 - 12:20
SREとその関連分野では、情報科学の他の分野と同様に、日々多数の論文が企業や大学から公開されています。論文に書かれている内容が、目前のSREの業務にすぐに直結することは稀ですが、論文には必ず新しいことが書かれているため、知的な刺激を受けることができます。さらに、その論文のアイディアがまだ社会実装されていなければ、エンジニアがそのアイディアを実装することがコミュニティへの貢献機会にもなり得ます。しかし、エンジニアコミュニティで共有されるブログ記事などとは異なり、機械学習など一部の分野を除いて、論文を発見するための導線が少なく、エンジニア向けの論文の読み方も共有されている例はほとんどありません。 そこで、本発表では、最先端のアイディアを発見・実装したいと考えるエンジニアに向けて、発表者の5年間のSRE研究と5年間のSRE業務の経験を踏まえて、SRE分野の論文の探し方・読み方を紹介します。探し方については、論文の種類やSRE分野に関連する国際会議、検索ツールの使い方などを、読み方については、単一の論文の下読み・精読方法と複数の論文を横断するシントピカルな読み方をそれぞれ概説します。
さくらインターネット株式会社 Researcher
国内でも数少ないSREの研究者。さくらインターネット研究所上級研究員、Topotalテクノロジーアドバイザー。専門領域はObservabilityとAIOps。
Sysdig Japan合同会社
9/29 12:00 - 12:20
株式会社スクウェア・エニックスのとあるシステムでフロンエンドのアプリケーション・サーバーがコンテナ化されるにあたり、コンテナビルド時の脆弱性検知/対策ができるビルドフローの構築を進めていました。この仕組みの概観についてお話したいと思います。 インフラ寄りの視点であることとsysdigのcli-scannerという特定製品の脆弱性検知の仕組みの説明になりますが、コンテナ/Kubernetes環境での脆弱性対策のフロー構築の参考になるように説明できればと思います。
株式会社スクウェア・エニックス 情報システム部 オンラインサービス・インフラストラクチャー クラウドエンジニア(SRE)
ネットワーク、サーバー インフラ エンジニアを経て 2020 年より現職。Google Cloud / Kubernetes（GKE）を用いたゲーム系バックエンド システムの設計、構築、運用に携わっています。
9/29 12:00 - 12:20
システムの本番環境において、どんな問題でも迅速に誰もが原因を特定（デバック）できればオブザーバビリティは高い状況と言えます。一方、デバックを勘に頼っていたり、長く在籍するエンジニアが最高のデバッガーである状況はオブザーバビリティが高い状況とは言えません。 急成長してきたSansan株式会社のインボイス管理サービス「Bill One」の1年前を振り返ると、誰でも容易にデバッグできるとは言えない状況でした。Primary Signals（Metrics、Logs、Traces）の中でもTracesを活用しきれていないのが課題だと考え、Tracesの活用を主軸としたオブザーバビリティ向上の施策を実施しました。 本発表では、Bill Oneでのオブザーバビリティ向上の道のりを事例として、オブザーバビリティの基本的な考え方や重要性、そしてオブザーバビリティを向上していくための具体的な施策について説明します。
Sansan株式会社 技術本部 Bill One Engineering Unit SREチーム
SREチームでテクニカルリードを担当。ミッション定義や信頼性向上の文化作り、負荷試験による性能改善、IaCの活用などを推進。Cloud Runとラーメンが好き。
9/29 13:10 - 14:00
特別企画として、CloudNative, Platform Engineering, DevOpsといった各分野の技術コミュニティからゲストスピーカーをお招きしたパネルディスカッションを行います。各技術コミュニティとSREとの関連性や技術コミュニティの運営から見出す組織文化醸成のノウハウなど様々な切り口で語ります！お楽しみに！ （※ 本セッションは会場限定セッションのため配信予定はありません）
株式会社サイバーエージェント Software Engineer、KaaS Product Owner、CyberAgent Developer Experts
2016年入社後、OpenStackベースのプライベートクラウドやコンテナ基盤の構築にゼロから携わる。著書に『Kubernetes完全ガイド』『みんなのDocker/Kubernetes』『Kubernetesの知識地図』。OSS活動をはじめ、「CloudNative Days Tokyo」の共同議長、「Kubernetes Meetup Tokyo」の主催などコミュニティ活動にも従事。
HashiCorp Japan Senior Solutions Engineer
HashiCorp Japanにてプロダクトのプリセールスフェーズに関わる。一般社団法人クラウドネイティブイノベーターズ協会代表理事。クラウドネイティブ技術の黎明期からプラットフォームの開発・運用に携わっており、その経験を元にPlatform Engineering Meetupの発起人となる
株式会社ITプレナーズジャパン・アジアパシフィック 代表取締役社長
メーカー系IT企業を経て、2011年にITプレナーズへ入社。セールスに従事後、BizDev責任者としてアジャイル・DevOps領域の研修サービス立ち上げに携わる。2018年4月より代表取締役社長に就任。一般社団法人DevOpsDays Tokyo 実行委員、IPA ITSS+ アジャイルWG委員。
弁護士ドットコム株式会社
9/29 14:15 - 14:35
契約マネジメントプラットフォーム「クラウドサイン」では、SREだけでなく開発者も 直接インフラに関与し、信頼性を高める取り組みを行っています。 信頼性を高める施策の1つとして、開発者が主体となりリリースフラグ管理サービスとして Amazon CloudWatch Evidently を導入しました。 本セッションではこの導入事例をもとに、開発者がインフラ設計や運用に積極的に参加することの価値、その過程で遭遇した課題、そしてその解決策についてお話しします。 このセッションを通じて、エンジニア全員が開発と運用に参加するという我々の取り組みを共有し、皆さんのプロダクト改善に役立てば幸いです。
弁護士ドットコム株式会社 クラウドサイン事業本部Reliability Engineering部 SREチーム
2022年10月から弁護士ドットコムに入社しクラウドサインのSREを担当しています。 インフラの監視・構築・運用だけでなくトイル削減のための開発業務など幅広く行い、開発者の生産性向上と信頼性を高める活動をしています。 趣味は散財で、そのエネルギーを活力にして業務に取り組んでいます。
9/29 14:15 - 14:35
昨今、DDoS攻撃や不正アクセスなど、攻撃にさらされる機会は少なくありません。 Site Reliability Engineering の組織の中でセキュリティに関しても見ている企業も多いのではないでしょうか。 ただし、「セキュリティのログを分析して打ち手を講じる」というフェーズまで取り組まれている企業は多くないかもしれません。 セキュリティ観点でのログ分析は「インシデント発生時のリアクティブな調査・分析」から「日々の傾向分析〜アクション創出といったプロアクティブな対応」を可能とします。 プロアクティブな対応ができれば、サイトの信頼性をより高めることが可能です。 ココナラで「どのようにSIEM on Amazon OpenSearch Serviceを導入し、ログ分析・モニタリングを実現したか？」や「ログ分析・モニタリングの結果をどのようにPDCAサイクルに繋げたか？」を登り方や事例を交えてご紹介します。 これからセキュリティログ分析に取り組む方だけで なく、現在取り組まれている方にも参考になる情報を提供します。
株式会社ココナラ Head of Information
株式会社ココナラのエンジニアマネージャー。担当領域はプロダクトインフラ・SREと社内情報システム / セキュリティ。2023年から技術広報 / エンジニアブランディングにも取り組んでいる。
9/29 14:15 - 14:35
Chatwork株式会社の藤井です。 本発表では、プロダクトオーナーの視座から信頼性をどのように計測可能なものとして捉え、組織全体の体制づくりに結びつけるかについて話します。 そもそも私たちが扱っている問題領域と解決領域についてご説明させていただきます。 さらに、「クリティカルユーザージャーニー（CUJ）」が何で、CUJを起こさないための「サービスレベルインジケータ（SLI）」の仮説設定と検討の苦悩について掘り下げます。また、これらの指標を適切に計測するために必要なオブザーバビリティを獲得するための取り組みについても解説します。 特に注目すべきは、オブザーバビリティを達成するために活用してきたOpenTelemetryの仕様理解と実装の難しさと、どのように対応したかについての経験談です。さらに、分散トレーシングに期待すること、そして今後の課題についても触れます。 この発表を通じて、信頼性とオブザーバビリティの理解を深め、プロダクトオーナーとしての視座から見た組織体制づくりの一助となることを目指します。しかし、これはまだ道半ばの旅であり、一緒に新たな可能性を探求していきましょう。
Chatwork株式会社 プロダクトオーナー
Chatwork株式会社でリライトプロジェクトをリードしています。リライトした世界にユーザー満足度を維持・向上できる信頼性を獲得するべく日々奔走しています。
9/29 14:45 - 15:05
信頼性という言葉を紐解くと、"[システムが]求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こすことなく実行する確率"であるとPractical Reliability Engineeringに記載されており、GoogleのSite Reliability Engineeringでも引用されております。 この中で語られている一つの要素、"求められる機能"についてSREとして取り組むことが信頼性の向上に繋がると考えています。 本セッションで は、私がFanstaという新規プロジェクトに携わる中でQAチームと協力し、機能性を担保するための取り組みに対してSREとしてどのように関わり、信頼性向上に取り組んだか？についてお話させていただきます。 お伝えする具体的なこと ・機能性から考える信頼性 ・QAに対してSREが出来ること ・実際に取り組んだこと ・まとめ
株式会社MIXI
2019年に株式会社ミクシィ（現:株式会社MIXI）に入社。 サーバーサイドを中心に開発を行い、XFLAG STOREアプリ開発・TIPSTAR開発などを経て、Fansta開発チームの遊撃部隊として活動。
株式会社Flatt Security
9/29 14:45 - 15:05
システムやソフトウェアの信頼性（Reliability）とセキュリティは多くの共通項を持つ概念です。本セッションでは、信頼性に主な関心を置いた技術体系であるSREを、セキュリティリスクの健全な管理のための技術体系として活用する方法を考察します。具体的にはSLO/SLI/エラーバジェット的発想に基づくセキュリティリスク管理や、セキュリティに関するソフトウェアエンジニアリング技法について、具体的な事例も交えながら論じます。 セキュリティ領域は技芸（Art）的解決が必要な課題領域も未だ多く、Engineering的体系は進化の途上にあります。SREというプラクティスを土台としてセキュリティ課題の解決を検討することは、SREに慣れ親しんだ（あるいは興味を持った）技術者の集まる本カンファレンスにおいては、セキュリティ領域への最も良い入り口になるのではないでしょうか。本セッションが、`class DevOps` の実装から一歩進んだ `class DevSecOps` を、あなたの組織で実装する際の一助となれば幸いです。
株式会社Flatt Security 取締役CTO
2019 年にFlatt Securityに入社し、2021年6月よりCTOに就任。(一社)セキュリティ・キャンプ協議会の一員として、教育活動やCTFの開催・運営にも参画。著書に『Webブラウザセキュリティ―Webアプリケーションの安全性を支える仕組みを整理する』(2021年、ラムダノート社)等。
9/29 14:45 - 15:05
Site Reliability Engineering の考え方に基づいた運用を行う上で、SLO は重要な道具の一つです。チームに導入するにあたっては、プロダクトオーナーも考え方を理解して合意する必要があります。 一方でただでさえ考えることが多く忙しいプロダクトオーナーにとって、新たな概念の理解と導入は負担になり、なかなか優先度を上げられず進められないのではないかと思います。ある日「このラインを割ったら開発を止めます」と言われても困りますし、「信頼性を上げられます」と言われても、そんなに困ってない、となることも多いのではないでしょうか。 本セッションでは、プロダクトオーナーとしてのSLOへ向き合ってどう考えてきたかについて、などを私自身が Mackerel のプロダクトオーナーをしていた経験に基づいてお話しします。SLO策定段階から、実際に運用して嬉しかった場面や負担に感じた場面など、よくあるパターンと具体的な事例を紹介していきます。
株 式会社はてな Mackerel プロデューサー
2011年、株式会社はてなにインフラエンジニアとして入社。基盤運用部署のマネージャーやチーフエンジニアなどを経て、現在はMackerelの事業責任者。
9/29 15:15 - 15:35
SLOはSREや開発者だけが守るものではありません。また、SREがプロダクトチームにお願いして守ってもらうものでもありません。プロダクトチームがオーナーシップをもってSLOを運用していくためには何が必要なのでしょうか。この発表では、職種の垣根を超えてSLOプロジェクトを発足し、技術的な課題と文化的な課題の両方に直面しつつ、SLOを組織文化として浸透させるためにやってきた弊社の数ヶ月間の取り組みをご紹介します。
株式会社グロービス SRE
2019年に株式会社グロービスに入社。元々アプリケーションエンジニアとして活動していた経験を活かし、SREとしてKubernetesを用いたインフラ移行PJやSLI/SLOの導入に取り組んでいます。
9/29 15:15 - 15:35
あるWebセキュリティ情報メディアのレポートによると全世界で平均して1ホストあたり17回/秒のサイバー攻撃を検知しているそうです。 これは2022年のデータですが、おそらく2023年には増加していると予想します。 インターネットでアプリケーションを公開することはサイバー攻撃を受ける危険性と隣り合わせです。 自社の公開アプリケーションを守るためのSRE活動は何でしょうか？ 実際に経験した事実を基にしたフィクションという体でサイバー攻撃への対策を紹介します。
株式会社MIXI 開発本部 CTO室 SREグループ SRE
2023年7月より株式会社MIXIへ入社。以前はクラウドアーキテクチャを設計するソリューションアーキテクトとして活躍していました。株式会社MIXI入社後は社内横断的に各プロダクトの価値を高めるSRE活動をしています。
9/29 15:15 - 15:35
Luupでは、電動アシスト自転車、電動キックボードなどの電動マイクロモビリティのシェアリングサービス「LUUP」を提供しています。 LUUPのSLI/SLOの設計・実装・運用に関して、これまでSREチームが他チーム協力のもと行ってきました。しかし、SLI/SLOはSREチームのみが管理すれば良いような指標ではなく、信頼性指標として開発組織全体、またビジネス領域にも顧客満足度として活用していくものです。そのため、Luup SREチームでは、各開発チームがSREを実践しSLI/SLOを自律的に設計・実装・運用できるようにEnabling SREを進めています。「Enabling SREを進める」とはいえSREのプラクティスは多くあるため、まずはSREのコアとなる要素であるSLOをEnablingすることにしました。Backend開発とIoT開発の２チームとPdMに対してEnabling SLOを行うために実践したプラクティスをスタートアップやIoT領域ならではの会社の特性や課題を踏まえて紹介します。
株式会社Luup SRE
ソフトウェアベンダーで開発、運用、SRE、企画を経験。2023年2月に株式会社Luupに入社。IoT領域のSREとして主にSLI・SLOまわりを推進。 SRE NEXT 2023 Chair。
9/29 15:50 - 16:10
What does every Bloomberg application have in common? Every application and thousands of machines write to a central telemetry system that we call GUTS (short for "Grand Unified Telemetry System"). Learn about how 8,000+ Bloomberg Engineers leverage the wealth of information and insights provided by GUTS, and how it's changed engineers' day-to-day workflows. ブルームバーグでは、数千のマシンとすべてのアプリケーションが「GUTS」に情報を送り込んでいる。8000人以上のブルームバーグエンジニアたちが、どのようにGUTSが提供する情報を利用し、GUTSがどのようにエンジニアたちの日々のワークフローを変えたかを紹介する。
ブルームバーグエルピー
2021年にインターンとしてブルームバーグに入社し、2022年よりTicker Plant SRE APACに務め、リアルタイム金融市場データシステムの健全性と回復を担当。大学時代では人工知能の研究や競技プログラミングをしていた。
ブルームバーグエルピー
ブルームバーグのソフトウェア・エンジニアとして5年以上勤務。主にC++を使用し、証券取引所など世界中のソースから毎日数千億のイベントを処理する金融市場データフィードハンドラーをメンテナンス。
9/29 15:50 - 16:10
WARNアラートはすぐさま重大なエラーにつながるわけではありませんが、何かしらの潜在的な問題に繋がってる可能性があります。 これらのWARNアラートを放置しておくと、重大な障害につながるかもしれません。 ところが、こういったアラートの詳細調査は、定形で手作業かつ、サービスの成長に伴い数が増える繰り返しなもので、自動化が可能。つまりトイルです。 定例の場でWARNアラートの確認しても『あとで調査します。』となって結局調査されないまま放置されることもあります。 そこで、WARNアラートが発生した場合、アラート駆動でログを自動収集する仕組みを入れました。その恩恵について、事例を発表します
面白法人カヤック その他事業部SREチーム データエンジニア
2016年より面白法人カヤックに入社。SREチーム所属のデータエンジニア。趣味はネットゲーム と寝ること、食べ比べ飲み比べです。ニッチなOSSを書くことも好きです。
9/29 15:50 - 16:10
TopotalではSRE組織に対して技術支援を行っています。そこで観察しているとSREがリーダーシップを発揮し様々な役割の人と協業することが求められていると感じています。そして、SREの組織類型（Embedded SREやEnabling SRE、Consultingなど）により求められるリーダーシップが異なっているようにも見えています。 では、SREの組織類型に応じてリーダーシップを発揮するにはどのような行動が必要なのでしょうか。SREの組織類型とリーダーシップの理論を組み合わせ、SREに求められるリーダーシップについて考察します。
Topotal, Inc. COO
ソフトウェアプロダクトのセールス、マーケティング、セールスマネージャー、事業責任者を経て、2016 年から MSP 事業会社の取締役として従事。Topotal では、事業全体の責任者として経営に参画。SREについて学びを深めるために、もう一度読むSREのPodcastの配信しています。 https://podcasters.spotify.com/pod/show/read-sre-again
9/29 16:20 - 16:40
SREのプラクティスにおいてアラートに対応するRunbookを備えることは推奨されています。しかしながら記載する内容についてはしばしば議論の対象となり、短期的な対応手順にフォーカスするのか、ハイレベルな情報にフォーカスするのか、メンテナンスのコストとのバランスをどのように取るか、むしろRunbookに時間を費やすべきではないのではないか、といったことまで様々な意見があります。 グリーではいわゆる障害対応の手順書は古くから運用されていましたが、それらは基本的に一次対応にフォーカスしており、根本的な原因調査のヒントがない、アラートの背景を伝えられていない、検索性が悪いなどの課題がありました。 本セッションでは一つの解として、これらの課題を解決するために新たにアラートに対応するRunbookの仕組みを整備し、新規に運用を開始した事例についてお話します。 また、合わせてアラートをより有効に機能させるための振り分けルール、通知チャンネル選択のガイドラインといったトピックについて扱います。
グリー株式会社 リードエンジニア
2014年よりグリー株式会社、インフラストラクチャ部所属。 全社向けの監視基盤を提供するチームのリード的なお仕事をしています。
9/29 16:20 - 16:40
SLOの低下（エラーバジェットの消費）が次のアクションに結びついていない。そんな状況に心当たりはありませんか？ なぜ、エラーバジェットの運用が後回しにされがちなのか、ご存知でしょうか？ SLOにより信頼性を定量化出来ます。しかしこれだけだと、次の行動には移せません。行動に移すには、エラーバジェットを使い果たした際に行うべきことを、エラーバジェットポリシーとして定めるのが1つの手です。 このポリシーを定めて運用するには、関係者との合意形成が必要ですが、ハードルの高さから後回しにされがちです。 ではハードルを乗り越えてでもエラーバジェットの運用が必要なのはなぜなのでしょうか。運用のために具体的に何をすればいいのでしょうか。 本セッションでは、エラーバジェットポリシーを定め、エラーバジェットを運用をするまでに実施した内容を紹介します。また、運用で得た学び、反省点をお話します。 キーワード ・SLOに納得感を持ってもらおう ・エラーバジェットに対するネガティブイメージを払拭しよう ・一人ではポリシーは定まらない。関係者を巻き込もう ・ロードマップの決定/変更権限を持つ人の理解を得よう
株式会社マネーフォワード SRE
SIer企業でシステム運用効率化、性能試験を経験後、2022年から株式会社マネーフォワードへ入社し、SREを担当。SREが居なくても信頼性を高める活動が自然と出来ている。そんな組織を目指しています。
9/29 16:20 - 16:40
イオンスマートテクノロジーは、イオンのデジタルシフト戦略を担う会社であり、 iAEONアプリによるお客様のお買い物体験向上と店舗DXを進めています。 プロダクトの特性から、従来当グループにあったベンダ依存の状態から内製化を進めている最中です。 しかし弊社もグループ内では出島のような立ち位置なものの、 設立当初は所謂JTCと揶揄されかねないエンタープライズ企業の側面が多々あり、そのような中で1年ほど前からSREチームを立ち上げSREの実践を進めております。 立ち上げ当時はDevOpsへの理解も浅く、他チームとの認識齟齬も多々ある状態でしたが、そのような状態から「何を考え、どんな壁にあたり、どのようにコミュニケーションをとりながら」SREの実践を進めてきたか現在地と展望を交えながらお話しさせていただきます。
イオンスマートテクノロジー株式会社
イオンスマートテクノロジー株式会社 CTO室SREチーム所属。2022年に入社し、SREチームの立ち上げ業務に挑戦中。本業は猫の下僕。
9/29 16:50 - 17:10
Yahoo!ショッピングはモール型のECサイトであり、ストア様が商品情報を管理・編集する「ストアエディタ」というサービスを提供しています。ローンチから20年近くが経過しており、バグによるお問合せを多数いただいている状況でした。また、運用が過負荷状態でサービス改善に手を回しにくい状態でした。こうした状況を打開すべく、Yahoo!ショッピングのSREチームが「Embedded SRE」という形で参画し、運用負荷軽減に取り組みました。そこで直面したのは、人材入れ替えやマイクロサービス移行過渡期でサービス仕様の全体像を把握している人がいないという問題でした。したがってCUJ/SLO/SLIの策定といった、信頼性改善の基本的なアプローチが難しい状況でした。そこでSREチームでは、問い合わせチケットに着目し、開発チームと協力して、問題特定と修正を実施しました。このアプローチによって、バグを減らしながら、サービスの現在の問題点や仕様を把握し、信頼性改善の基本的なアプローチを取るための下準備が可能になりました。本発表では、この問い合わせ駆動の信頼性向上の取り組みについてご紹介いたします。
ヤフー株式会社 SRE
2020年よりYahoo!ショッピングの商品管理領域を担当。特に、レガシーシステムの運用と刷新に従事。SREの実践を通じて、ユーザー志向のエンジニアリングを浸透させることを目指している。
9/29 16:50 - 17:10
SRE の実現には、SRE という Role を持つ人だけでは成し遂げられません。プロダクト開発を行う組織の場合、プロダクト開発者と緊密な連携が必須です。その場合、SRE Team がいかにプロダクト開発者の直面する課題をどれだけ深く理解し、その要求を適切に定義できるかが鍵となります。 開発チームの要求を理解するためには以下の3種類のアプローチが有効です。 1直接のフィードバックを受け入れる 2.継続的にコラボレーションする 3. 実際の現場を体験し、開発者の立場を理解する そしてこれらを実現するためにはマネジメント上の工夫だけではなく、オープンで避難のないコミュニケーションや、定期的なふりかえり、そして適切なフィードバックを行うといった組織文化が必要不可欠です。 本セッションではこれらのアプローチの具体的な実践例と、それを支える組織文化に関する実例を詳しく紹介します。SRE チームと開発チームの両方のマネージャを経験を持つ私の独自の視点を通じて、プロダクト開発組織全体で SRE を効果的に実践するヒントを持ち帰っていただければと思います。
株式会社リクルート Engineering Manager
2018年6月にQuipperに入社。増えていく Product Team に Producton Readiness Check や SLI/SLO を導入をリード。2021年10月より同 SRE Team の Engineering Manager に任用、同時に事業移管よりリクルートへ転籍。2022年10月より中学生向けサービスの Web 開発チームの EM の兼任。趣味はクラフトビール屋めぐり
9/29 16:50 - 17:10
『家族アルバム みてね』（以下、『みてね』）のインフラは、2021年始めにAWS OpsWorksからAmazon EKSのマネージドK8s基盤へと移行しました。 K8sの採用は大きな恩恵がある一方で「運用コストが高くなる」と一般的に言われています。その理由としてあげられやすい4ヶ月に一回のマイナーリリースへの追従については、K8sクラスタの運用経験のある方であれば少なからず苦労した思い出があるのではないでしょうか。 当然のことながら『みてね』でも約3年間の運用のなかで幾度ものマイナーバージョンアップグレードが行われ、少なくない工数が消費されてきました。そしてそのなかで発見された課題に対しても取り組んできました。 本セッションでは、1,800万人のユーザーの皆さまに影響を出すことなく実施している『みてね』におけるAmazon EKSのマネージドK8s基盤のアップグレード戦略とその継続的な改善についてお話しできればと思います。
株式会社MIXI Vantageスタジオ みてねプロダクト開発部 基盤開発グループ SREチーム
2022年4月株式会社ミクシィ（現MIXI）に入社。『家族アルバム みてね』のSREチームにてサービス安定性、ユーザー体験の向上に取り組む。
9/29 17:20 - 18:00
信頼性目標はシステムの様々なアーキテクチャーや運用に影響を与えます。本セッションでは、まず信頼性目標とはなにかの解説を行い、いくつかの信頼性目標とそれぞれにおける必要なアーキテクチャやオペレーションを紹介します。最後に実際の事例を紹介し、まとめとします。
グーグル合同会社 シニアデベロッパーリレーションズエンジニア
グーグル合同会社シニアデベロッパーリレーションズエンジニア。クラウド製品の普及と技術支援、製品開発を担当し、オブザーバビリティ、SREの領域を担当。「オブザーバビリティ・エンジニアリング」「SLO サービスレベル目標」翻訳、「SREの探求」監訳。
