Reliability Engineering at Studist 株式会社スタディスト VP of Engineering Katsuhisa Kitano / @katsuhisa__

⾃⼰紹介 ● 北野 勝久 / Katsuhisa Kitano ● X(Twitter) ID: @katsuhisa__ ● 株式会社スタディスト 執⾏役員 VPoE / SRE Engineering Manager ● ⼀般社団法⼈ SRE NEXT 代表理事 ● SRE NEXT Founder

#chiyoda_tech 発表のゴール

発表のゴール ● スタディスト開発本部の信頼性を制御する活動の 2024年版スナップショットを残す ● 今のスタディストの Reliability Engineering を 記録することに重点をおくため、 持ち帰っていただきたい Tips があるわけではない ● 組織の規模やフェーズ、周辺チームとの関わりで、 SREingのあり⽅は違うよね、を再確認する

#chiyoda_tech スタディストの Reliability Engineering の歴史

SREという⾔葉を知らなかった頃からはじまった ● インフラ運⽤を ⼿動Opsでがんばる エンジニアが数名 ● SREを組織化し、 ソフトウェアでの 運⽤⾃動化を継続体制へ ○ SLI/SLO ○ Toil削減 ○ 信頼性を制御する 感覚を得る https://speakerdeck.com/ katsuhisa91/sre-taizen-studist-1

たいへんだった ● インフラ運⽤を ⼿動Opsでがんばる エンジニアチーム ● SREを組織化し、 ソフトウェアで運⽤を ⾃動化する継続 ○ SLI/SLO ○ Toil削減 ○ 信頼性を制御する 感覚を得る https://speakerdeck.com/ katsuhisa91/sre-taizen-studist-1 マシンイメージが 秘伝のタレ化！！！ なぜかRDSが 最強スペック アラート すごいくるけど なんでか分からん！

当時、集中していたこと ● 振り返ってみれば、 信頼性を制御できる状態づくりに集中していた ● SRE本に書いてあった導⼊できそうな価値観や プラクティスを導⼊することで、制御できる感覚へ近づけた ● 基本的な運⽤の⾃動化や効率化はこの頃に完了 ● 暗黙知を減らすことを⼀⽣懸命やっていた気もする

プロダクト開発における暗黙知の向き合い⽅については過去話した https://speakerdeck.com/katsuhisa91/strategies-for-tacit-knowledge-transfer-at-software-development

徐々に、さらなるスケーラビリティや開発者体験に集中できるように ● Platform Engineering 的アプローチを強化 ● Infra CI/CD 強化 ● コンテナ基盤づくり ● ブランチごと 検証環境の⾃動化 https://speakerdeck.com/ katsuhisa91/self-service-and -silos-and-organizational- structure

徐々に、さらなるスケーラビリティや開発者体験に集中できるように ● Platform Engineering 的アプローチを強化 ● Infra CI/CD 強化 ● コンテナ基盤づくり ● ブランチごと 検証環境の⾃動化 https://speakerdeck.com/ katsuhisa91/self-service-and -silos-and-organizational- structure SREだけでなく、 CRE組織ができた🎉 歴史的経緯で分散していた インフラ基盤を統一できた🚀 AWS / k8s 開発運用の 基盤が整った🚀

#chiyoda_tech スタディストの Reliability Engineering の現在地点

● 体制 ○ プロダクト別のエンジニアリングチーム + 横断的なSREチーム ○ 主⼒事業の Teachme Biz 配下には複数チームあり、 その中に前述のCREチームもある ● 特徴 ○ SREの⼈数 = ex-SREの⼈数 ■ SREで仕事をした後に、 いわゆる Stream-aligned team に異動している ○ チーム横断のエラーを⾒る会で プロダクト状況を継続確認する⽂化がある スタディストのReliability Engineeringの体制と特徴

CRE（＝顧客信頼性のための活動全般を担っているチーム）のおしごと例 顧客の利⽤環境を ⼀⽬で収集できる 問い合わせ対応効率の 向上ツール開発 https://studist.tech/ doctor-maron-e514d9dfeaaf

CRE（＝顧客信頼性のための活動全般を担っているチーム）のおしごと例 https://studist.tech/cloudfront-alternate-domain-80fed5d47666 cloudfront.net ドメインから代替ドメインに移⾏

潜在的に危険な DBマイグレーションを 事前に検知するツール （strong_migrations） の導⼊ https://studist.tech/ strong-migrations-1673192f72b6 CRE（＝顧客信頼性のための活動全般を担っているチーム）のおしごと例

CRE（＝顧客信頼性のための活動全般を担っているチーム）のおしごと例 https://studist.tech/font-issue-8ee610ee7be0 タイ語のフォントを違和感がないフォントに変更する

● 信頼性に関わることはぜんぶやる ○ 業務範囲的には Platform Engineering / CCoE / DX (Developer Experience) 領域がごちゃまぜ ○ 昨今よく聞く、認知負荷の低減に関しては 部分的に逆⾏している実感もある ● 信頼性にまつわるエンジニアリングをする + そのためのツールセットやインフラをつくる + ツールセットの開発体験を良い感じにする ○ SRE evangelist 的な活動も SREチームのおしごと‧関⼼事項

SREチームの領域例: スキル整理 ※社内議論のメモで、技術的な正しさは精査できていない

SREチームの領域例: チームの動き⽅の整理 ※社内議論のメモで、技術的な正しさは精査できていない

● ALL STAR SAAS CONFERENCE 2024 ● k8sのJob管理ライブラリ ● Rails World の動画 ● モジュラモノリス ● LGWAN環境での動作検証 ● データ分析基盤のための ツール導⼊ ● テーブルのannotate管理 参考: スタディストSREチームの先週（2024/11/25週）の話題 ● re:Inventに⼊らなかった 直近のAWSアップデート ● CI共通化や改善 ● Datadogの使い⽅ ● ベクトル検索 ● Design Doc を書くタイミング ● 忘年会 ● 部屋の加湿 ● ⽝が⼤事なものをくわえて持っ ていって焦った話 ⽔曜⽇に45分、⾦曜⽇に30分つかい、 お互いの取り組み内容や疑問点、技術的な最新情報を共有している

#chiyoda_tech スタディストの最近の Reliability Engineering で⼤事にしていること

いっしょに⼀つの作業をやる ● チームで集まって、何か⼀つの作業をやる時間が 定期的にある ● 具体的にやっていること ○ Renovate がつくった PR を棚卸しする会 ○ konmari day（負債解消⽇）で、 ⼀つの負債をみんなで協⼒して倒す ○ インフラコストをいっしょにみて、傾向を考察する時間

● ツールをつくっての⾃動化の積み上げで、 ⼀部の仕組みのメンテナンスが重荷になっている ● ツールを書いて⾃動化は引き続きやるが、 ツール⾃体のメンテコストにはあらがえない ● Design Doc を常に書くわけではない話といっしょで、 ⾃前ツール開発の損益分岐点を最近は慎重に議論している ● なるべく標準機能でまかなう ⾃動化はするが、ツールをつくりすぎない

● 昔はSREからの「⽀援」っぽいなと思っていたが、 直近の状況はどちらかといえば、ただのお互い様って感じ ● 今⽇紹介したように Reliability Engineering にまつわる テーマは開発組織のあちこちで実践されていて、 たまたまこっちのチームでやってることと、 あっちのチームでやってることがあるだけ ● ex-SRE がふらっと現SREのミーティングにあそびにくるが、 話しながら「頼り、頼られ」をやってる感覚もある チーム間で「頼り、頼られ」をやる

#chiyoda_tech おわりに: 今までを振り返って

これまでとこれから ● 今のスタディストSREの存在意義は、 信頼性にまつわる組織の基準線であること ○ 他のチームも信頼性制御にまつわる活動はやる ● Opsっぽい⼀部の業務が ex-SRE + SRE に残っているのでうまく組織内に広げる ● Reliability Engineering を実践するチームをどう拡⼤する？ （分割する？）は、実践した結果をいつか発表したい