こんにちは。SRE の @chaspy です。
タイトルの通り、以下のイベントで登壇します。
本記事では、当日の発表をより多くの人に見てもらえるよう、connpass に掲載されている発表概要について補足します。
登壇情報
Title: SRE を実現するための組織マネジメント
『スタディサプリ』はサービス全体で会員数が194万人(2020年度）となり、信頼性への要求も組織規模も拡大しています。これまでは SRE チームが SLO の実装や文化構築をリードしてきましたが、それ自身を各開発チーム内で実現していくフェーズに移行しつつあります。本発表ではリクルートグループのミッションマネジメントを活用し、開発チームの SRE Capability 習得を支援する事例を紹介します。
こちらを補足していきます。
登壇の背景
登壇者は『スタディサプリ』（小学・中学・高校講座）及び海外で展開する『Quipper』を開発・運用していた『Quipper』という会社で SRE チームとして従事、現在は事業移管により株式会社リクルートで Engineering Manager をしています。
信頼性への要求も組織規模も拡大しています という点では、特に COVID-19 の流行によるオンライン学習の拡大が大きな背景にあります。BtoC だけではなく、学校にも使われることで信頼性への要求は大きくなってきています。当時コロナ禍によるアクセス急増を組織としてどう乗り切ったかは以下の記事を参照ください。
SRE チームが SLO の実装や文化構築をリード という点については、2020年1月の以下の発表にある通り、ボトムアップで SLI/SLO という概念をインストールしてきました。
現在の「信頼性」を取り巻く開発組織の状況
現在、「スタディサプリ」（小学・中学・高校講座）を開発する「小中高プロダクト開発部」は 14 チーム（SRE、Native 開発、Technical Product Manager Group を含む）、80名と、2年前から比べると倍増しています。その拡大に対して、SRE チームは前述した SLI/SLO のカルチャーの醸成だけでなく、可能な限り開発チームだけでできることを増やすため、Production Readiness Checklist の運用や、Cloud Infrastructure を self-service で行えるよう Terraform monorepo platform を進化させてきました。
Service の Monitoring、 Incident response も各サービスチームがオーナーシップを持って実施できており、SRE チームがいないとできないことはかなり減ってきたように思えます。
事業としては利用ユーザを獲得しながらも、パフォーマンスなどユーザー体験を損ねないためのパフォーマンスの維持・改善だけでなく、中学講座ベーシックコースをフルリニューアルしたり、保護者向けの新機能をリリースしたりと、開発速度を落とさず、運用をバランス良くやっていく必要があります。
そんな状況の中、現在信頼性に関する問題は SRE チームが横断的に解決するというよりも、開発ドメインに特化した問題にシフトしつつあります。具体的には以下のトピックが挙げられます。
負荷試験
- Shared Database である MongoDB という文脈では SRE が貢献できる点も多いが、基本的に負荷試験は実際に想定されるユースケースに合わせた実施が必要であるため、ドメイン知識が必要不可欠である。
- また、想定ユーザーがどれぐらいでそのような期待があるかという点で Business Developer との会話が必要であり、それは SRE ではなく開発チームで Lead できるのが望ましい。
ドメイン特化の Pod Auto Scaling
- サービス特性により発生するスパイクを、単なる CPU 利用率ではなくドメインデータから取得した値でスケーリングさせたり、Cascading Failure を回避するために依存されるサービスのスケールも同時に考慮したりと、単純なシステム運用の知識だけではない、ドメイン知識が必要なスケーリング戦略が求められる場面が増えている。
Frontend Performance の測定 および SLI/SLO の改善
- Backend Service に対する HTTP Success Rate および Latency の測定、および SLO 策定はできているが、よりユーザー体験に近い場所での計測をしない限り、リリースストップを行えるだけの説得材料にならないという課題がある
- コアとなるユーザージャーニーに対して、フロントエンドを含めて計測し、SLO を決定し、Business Developer 含めて プロダクトチーム全員で見ていける指標に育てていくためには開発者の知識が必要
QA 自動化
- 開発チームがより速く変更を本番環境に投入するためには、QA を自動化する必要がある。
- Product QA チームと連携しながら、開発チーム内でどこをテストすべきかの戦略を立て、実行できる体制を持てたほうが良い
開発チーム内から「SRE」Capability を作る打ち手
このような状況の中、SRE チームとしてはこれらの課題を解決するような技術的な支援、及び Platform の開発に注力しつつ、この問題を推進するには開発チーム自身にこれらの課題解決を推進できる Capability を身につけることが必要だと考えました。
一部の意欲のある、希望があるメンバーに一定割合「ミッション」を持ってもらい、推進してもらうことに挑戦してみています。本発表ではこの方法と効果についてお届けします。
リクルートのミッションマネジメント
リクルートグループでは各個人の「WCM: Will / Can / Must」を言語化・担当マネージャとすり合わせた上で、各期で挑戦する「ミッション」を決めて働いています。
このミッションの担当マネージャ（レポートライン）は必ずしも直属のチームマネージャである必要はありません。これにより各開発チームの一部メンバーには SRE に関係するミッションを持ってもらい、信頼性に関するチームの Capability 向上など様々なミッションに挑戦してもらっています。
対象聴衆
拡大する組織に対して SRE Capability を開発チームに身につける方法に興味がある方
Audience Takeaways
- SRE チームと開発チームの関わり方
- SRE チームと開発チームの担当メンバーにどのようなミッションを設定するのか
- 設定したミッションをどのように可視化し、コラボレーションを推進するのか
おわりに
当日は質問の時間もありますし、事前質問は slido で募集しています。聞いてみたいことがあれば発表に反映させるかもしれないので、遠慮なくお寄せください。
slido: https://app.sli.do/event/bupdyiP7iSJAHtrnhZytvh
SRE チームでは世界の果てまで学びを届けたい仲間を募集しています。最近はセキュリティに特化した Product Security Engineer のポジションもオープンしました。
その他の登壇
リクルートグループからは以下もう1件発表を行いますのでこちらもご覧ください。
歴史あるサービスに向き合うSRE（仮） リクルートのなかには、紙媒体からWebに移行し、成長を続けているサービスが複数し、それらのサービスは歴史があり新しいものと古いものが混在します。 その中で信頼性を担保するためのSREの取り組みを紹介します。
slido: https://app.sli.do/event/oREQxfaeqb9PAb8NbrfNTt
