ゆるSRE勉強会 #5 ~しくじりSRE - 俺みたいになるな！~ @daigo_hirooka 1年 SRE をやって見えてきた SRE とプロダクト開発の関わり方

自己紹介 ● 廣岡大吾 ○ dhirooka (@daigo_hirooka) / X(Twitter) ● キャディ株式会社 ○ 2022/12 - 23/3: MLOps Engineer として 図面解析システムの開発・運用など担当 ■ 一時期 Embedded SRE を兼任 ○ 2023/4 - now: Enabling SRE として 図面活用 SaaS Drawer の信頼性向上に向けて色々 ■ 最近 SRE チームが1周年になりました🎉

あなたの SRE タイプは？ SRE NEXT 2023 のアンケートボード SRE NEXT 公式アカウントの投稿より引用 Embedded SRE Enabling SRE Platform Engineering

今回のテーマ：二つの SRE タイプを振り返ってみる ● キャディ株式会社 ○ 2022/12 - 23/3: MLOps Engineer として 図面解析システムの開発・運用など担当 ■ 一時期 Embedded SRE を兼任 ○ 2023/4 - now: Enabling SRE として 図面活用 SaaS Drawer の信頼性向上に向けて色々 二つの SRE タイプを踏まえて、どうすれば もっとうまく信頼性向上を推進できたか考えてみる

Embedded SRE at AI team：背景 ● AI team の MLOps エンジニアと、サブポジションとして Embedded SRE を兼任 ● キャディにおける embedded SRE の役目と成り立ち ○ スタートアップという環境下で、非機能要件設計やインフラ構築への配慮が薄くなりがち だったため、これらと強く結びついた役割として各チームで embedded SRE を任命 ○ 社内の Platform Group が整備するポリシーやガイドラインの理解、チームへの展開も担当

Embedded SRE at AI team：成果と心残り ● 図面解析の性能目標などの非機能要件整備や、関連するモニタリング整備、 platform group との連携窓口としては機能していた ● いわゆる「SRE」のプラクティス（非常時プレイブックの整備、計装の推進など）はまだまだ ○ そもそも SRE の責任への知識が少なかった ○ Embedded SRE として何をどこからやるべきか、の具体的な要件・優先順位が 明確でなかった ○ そもそも AI team が提供する機能で、信頼性起因の課題が顕在化していなかった

Enabling SRE at SaaS Product：背景 ● 図面活用 SaaS Drawer の専任 SRE チーム ○ 他に検索チーム、非同期図面処理チームなどがマイクロサービス的に存在 ● SRE チーム設立の背景 ○ サービスローンチ後半年ほど経っており、インフラや信頼性にフォーカスするチームの 必要性が増していた ○ SaaSのSREチームを立ち上げました - CADDi Tech Blog

Enabling SRE at SaaS Product：取り組み ● チーム設立初期 ○ インフラアップデート、サービスアカウントの整理、コストダッシュボードの構築など ○ インフラや非機能要件周りで顕在化していた課題を拾いつつ、開発チームと Platform Group の連携窓口としても動いた ○ ✅小粒でも見えやすい成果を作ることで、 Quick Win を得られた

Enabling SRE at SaaS Product：取り組み ● Enabling SRE としての信頼性プラクティスの推進 ○ SRE 本など読んだ上で、 SLI/SLO の構築やインシデント・オンコール対応整備など とっつきやすいところに順次着手 ○ 頭数が少なかったので各チームエンジニアや PdM とのコミュニケーションを厚くした ■ ✅信頼貯金＋各チームの課題の解像度が上がって結果的に Good 👍

Enabling SRE at SaaS Product：最近の洞察 ● 1年間の SRE チームとしてサービス全体の信頼性向上に取り組んだおかげで、 チーム/コンポーネント単位の課題の解像度が上がってきた ○ 新規立ち上げプロダクトへの信頼性構築の支援 ○ SLI/SLO のボトルネックへの重点的な分析、改善支援 ○ インシデント調査時のボトルネック領域への改善支援 ● 💡個別の課題が見えてきたタイミングで embedded SRE を設けると、やることが明確

● Enabling SRE ○ SRE チームとして人を集約することで、優先度の高いタスクにフォーカスできる &ナレッジも集まる ○ 関連チームや EM, PdM とのコミュニケーションを厚くすることで、プロダクトにおける 信頼性の必要性や有用性を広めることができる。チーム単位の課題も見えてくる 二つの SRE タイプを踏まえて

● Embedded SRE ○ 「SRE」としての役割を期待するなら、やるべき内容や目標の具体化が重要 ○ 既に課題が顕在化している場合はそこから着手する ■ パフォーマンスのボトルネック調査や改善が必要 ■ アラートやインシデント対応時のプレイブック不足 ○ フラットな状態から始める場合は SLI/SLO の計画からやるのが良さそう ■ PdM やエンジニアチームで CUJ ディスカッション、監視や計装の強化 ■ チーム内でのダッシュボード確認の習慣づけ ○ SRE チームから一時的に派遣するような関わり方もありそう 二つの SRE タイプを踏まえて

● SRE ポジション/チームの構築は役割と目標をよく考えて進めよう ● 参考 ○ Books For Site Reliability Engineering ○ Embedded SRE at Mercari ○ Embedded SREとは何か - SREの組織類型についての覚書 - chroju.dev ○ SaaSのSREチームを立ち上げました - CADDi Tech Blog まとめ