スタディサプリ/Quipper オンラインミートアップ #3（SRE）

Aug

25
スタディサプリ/Quipper オンラインミートアップ #3（SRE）
今回はSREの方を対象に、スタディサプリ事業の開発体制・魅力についてお話しします！

Organizing : Quipper Limited

Hashtag ：#sapurimeetup

Registration info	Registration not needed, or register on another site.

Description

イベントお申し込み方法

▼以下リンクよりお申し込みください

https://krs.bz/q-studysapuri/m?f=7

※申し込んでいただいた方には、メールにてイベントURLをお送りします

イベント概要

Quipper Limited/スタディサプリ事業では、事業拡大に伴い、エンジニアの方を積極採用中です！今回のイベント対象はSREの方です！弊社VP of Engineeringおよび実際に開発に携わっているSREより、スタディサプリの開発体制・魅力についてご紹介します。詳細は後述の「発表紹介」をご覧ください。

イベント対象

以下の方を主な対象としています（当てはまらなくてもお申込みいただけます）

Quipper/スタディサプリのSREにご興味のある方
教育業界のテクノロジーにご興味があるエンジニアの方
転職活動中、もしくは今後始めようと思われている方

開催方法

オンライン開催（Zoomウェビナー実施）となります

タイムテーブル

時間	内容	発表者
19:00	オープニング
19:10	「スタディサプリの事業と職場環境についてご紹介」	Ryuma Tsutaki / VP of Engineering
19:45	「How to measure "Site Reliability Engineering"」	Takeshi Kondo / SRE
20:15	終了予定

※随時、質問を受け付けます

発表紹介

スタディサプリの事業と職場環境についてご紹介

発表者

Ryuma Tsutaki / VP of Engineering

大学卒業後、中小SIerを経て、グリーに入社。グリーではエンジニアや釣りスタの事業責任者を務める。2016年にリクルートマーケティングパートナーズに入社、2017年よりスタディサプリEnglishの開発にマネージャーとして関与、2020年4月よりスタディサプリ全体の開発責任者としてVPoEを務める。

発表概要

スタディサプリの現在とこれから、プロダクト開発チームのカルチャーや働き方、どのような人材を求めているかなどについてお話しします。

How to measure "Site Reliability Engineering"

発表者

Takeshi Kondo (@chaspy) / SRE

新卒で富士通株式会社に入社。パブリッククラウド(IaaS)の開発をしたのち、2018年6月にQuipperに転職。開発者が幸せになれる世界を作っていきたい。最近はホットクックを買って自炊ライフを楽しんでいる。

https://chaspy.me

発表概要

Site Reliability Engineering (以下 SRE)、ちゃんとやっていますか？Quipper では SRE の Core Concept である Service Level Objectives を1年半前に導入しました。現状を振り返ってみると、それがうまく信頼性の計測につながっているケースもあれば、うまくユーザ価値を指標になっていないケースもありました。そこで、Service Level だけでなく、SRE の関心である Developer Productivity と Production Reliability、そしてそれらを支える Platform Development の4つの領域に対して提供する価値をどのように計測するかを考え、Platform の開発を「プロダクト的」に行うことで、指標を用いた分析・改善を試みました。本発表ではこの軌跡と学びを紹介します。意思決定を「なんとなく」行なってしまっている、以前の僕たちのような方にヒントを持ち帰ってもらえたら幸いです。

アウトライン

自己紹介
SRE Team の紹介
- 2 Products
- 100+ Developers
- 7 SREs
- SRE Team の Vision / Mission / Values
  - Vision: 最高の学習プロダクトを作り続けられる開発組織の実現
  - Mission: 自己完結チームがプロダクトを素早く安全に届け続けるためのプラットフォームと文化を作る
  - Values:
    - Fail smart: 失敗を非難せず、学習の糧とする。また、影響範囲をコントロールし、最小のリスクから最大のリターンを得られるよう、プロセスに失敗を織り込む。
    - Learning: 未知の課題を発見・解決するために、あらゆる物事を学習の機会と捉え、必要な変化をし続ける。
    - Borderless: 組織の垣根なくコミュニケーションし、協力しあうことでより大きな成果を目指す。
    - Metrics-driven: あらゆる課題・物事を指標化し、問題を点ではなく線で捉え、柔軟かつ自動的な解決を目指す。
- SRE Team の業務領域
  - Developer Productivity
    - Monorepo CI/CD
    - Preview Environment
    - Infrastructure Management
    - Microservice setup script
  - Production Reliability
    - Incident Response
    - Auto Scaling(HPA/CA)
    - Worker Node Management
    - Monitoring
  - Platform Development
    - Application Platform (Kubernetes Cluster)
    - Application monorepo CI/CD Platform (CircleCI / GitHub Actions)
    - Infrastructure monorepo CI/CD Platform (Terraform)
- Security(今回は対象外)
- Cost Management(今回は対象外)
Site Relibtiliy Engineering とはなにか
- SRE Book より簡単に説明
  - 定義
  - Core Contepts としての SLI/SLO
- SLI/SLO 運用の課題
  - Error Budget Policy の制定およびアクションが定着していない
  - SLI/SLO が役に立つ指標になっていないケースがある
  - Business Development を含め、組織全体で活用できる指標になっていない
どのように Site Reliability Engineering を計測するのか
- SRE Team が提供する価値をどう計測すれば良いか
- 事業にとって”Developer Productivity”はどう関係するのか
- 仮説検証を繰り返すための”Developer Productivity”
- それを示す指標: (本番環境への)デプロイ頻度
- なぜデプロイ頻度が指標として適切か？
  - 前提としてプロダクト開発ではリリースしてみないとKPIを改善するかどうかわからない（目的不確実性）がある
  - 仮説検証をできるだけ多く繰り返すためにはデプロイ頻度を高める必要がある
- デプロイ頻度だけを追えばいいのか？ No
  - さまざまな指標がシステム的に複雑に影響しあう
  - デプロイ頻度を main KPI と置きつつ、他の指標も観察する必要がある
  - 指標間には様々な関係性がある
- どこからどうやってはじめたらいいか？ -> プロダクト的に考える
  - ユーザを観察し
  - 価値を提供し
  - その価値を示す指標を観察し
  - 仮説検証を繰り返す
- なぜ”プロダクト的”に考えると良いのか
- 指標を検討するためにやってきたこと
  - 顧客・提供価値の言語化
  - 開発チームの Value Stream Mapping
  - 目指す姿をツリーで書き出し
- 今やっている取り組み
  - 指標の Monitoring 強化
  - Autify による E2E テスト自動化
  - Release 体験改善
- まとめ
  - Platform を"プロダクト的"に考えよう
  - 指標はデプロイ数からはじめよう
  - 事業活動との関係を意識しよう
- 今後
  - Business Team と一緒に Platform KPI を追いかけていく
  - ユーザの観察と指標改善のためのアクションを打って、仮説検証を繰り返していく
  - Platform Development 以外の領域にも同じ考え方を適用する
    - Security: 脅威と頻度等から数値化できないか？
    - Cost Management: User 規模と売り上げ・利益率から目標値を定めて適切なアクションを打っていくべき
- FAQ
  - SLI/SLOとエラーバジェットの運用について、SREだけでなくプロダクト開発組織全体を巻き込んだ運用を行うためにはどうすればいいでしょうか (どうしてもSRE本位になりがちで悩んでいます)
  - 開発チームとSREチームの境界線 (SLI/SLOに対して各チームがどこから/どこまで主体性を持って取り組んでいるか。インフラの選定やアップデートなども同様)
  - 変更失敗率はどうやって計測しているか
  - MTTR はどうやって計測しているか