Upgrade to Pro — share decks privately, control downloads, hide ads and more …

1年 SRE をやって見えてきた SRE とプロダクト開発の関わり方

1年 SRE をやって見えてきた SRE とプロダクト開発の関わり方

ゆるSRE勉強会 #5 ~しくじりSRE - 俺みたいになるな!~(https://yuru-sre.connpass.com/event/312943/)の LT 資料

Daigo HIROOKA

April 17, 2024
Tweet

More Decks by Daigo HIROOKA

Other Decks in Technology

Transcript

  1. 自己紹介 • 廣岡大吾 ◦ dhirooka (@daigo_hirooka) / X(Twitter) • キャディ株式会社

    ◦ 2022/12 - 23/3: MLOps Engineer として 図面解析システムの開発・運用など担当 ▪ 一時期 Embedded SRE を兼任 ◦ 2023/4 - now: Enabling SRE として 図面活用 SaaS Drawer の信頼性向上に向けて色々 ▪ 最近 SRE チームが1周年になりました🎉
  2. 今回のテーマ:二つの SRE タイプを振り返ってみる • キャディ株式会社 ◦ 2022/12 - 23/3: MLOps

    Engineer として 図面解析システムの開発・運用など担当 ▪ 一時期 Embedded SRE を兼任 ◦ 2023/4 - now: Enabling SRE として 図面活用 SaaS Drawer の信頼性向上に向けて色々 二つの SRE タイプを踏まえて、どうすれば もっとうまく信頼性向上を推進できたか考えてみる
  3. Embedded SRE at AI team:背景 • AI team の MLOps

    エンジニアと、サブポジションとして Embedded SRE を兼任 • キャディにおける embedded SRE の役目と成り立ち ◦ スタートアップという環境下で、非機能要件設計やインフラ構築への配慮が薄くなりがち だったため、これらと強く結びついた役割として各チームで embedded SRE を任命 ◦ 社内の Platform Group が整備するポリシーやガイドラインの理解、チームへの展開も担当
  4. Embedded SRE at AI team:成果と心残り • 図面解析の性能目標などの非機能要件整備や、関連するモニタリング整備、 platform group との連携窓口としては機能していた

    • いわゆる「SRE」のプラクティス(非常時プレイブックの整備、計装の推進など)はまだまだ ◦ そもそも SRE の責任への知識が少なかった ◦ Embedded SRE として何をどこからやるべきか、の具体的な要件・優先順位が 明確でなかった ◦ そもそも AI team が提供する機能で、信頼性起因の課題が顕在化していなかった
  5. Enabling SRE at SaaS Product:背景 • 図面活用 SaaS Drawer の専任

    SRE チーム ◦ 他に検索チーム、非同期図面処理チームなどがマイクロサービス的に存在 • SRE チーム設立の背景 ◦ サービスローンチ後半年ほど経っており、インフラや信頼性にフォーカスするチームの 必要性が増していた ◦ SaaSのSREチームを立ち上げました - CADDi Tech Blog
  6. Enabling SRE at SaaS Product:取り組み • チーム設立初期 ◦ インフラアップデート、サービスアカウントの整理、コストダッシュボードの構築など ◦

    インフラや非機能要件周りで顕在化していた課題を拾いつつ、開発チームと Platform Group の連携窓口としても動いた ◦ ✅小粒でも見えやすい成果を作ることで、 Quick Win を得られた
  7. Enabling SRE at SaaS Product:取り組み • Enabling SRE としての信頼性プラクティスの推進 ◦

    SRE 本など読んだ上で、 SLI/SLO の構築やインシデント・オンコール対応整備など とっつきやすいところに順次着手 ◦ 頭数が少なかったので各チームエンジニアや PdM とのコミュニケーションを厚くした ▪ ✅信頼貯金+各チームの課題の解像度が上がって結果的に Good 👍
  8. Enabling SRE at SaaS Product:最近の洞察 • 1年間の SRE チームとしてサービス全体の信頼性向上に取り組んだおかげで、 チーム/コンポーネント単位の課題の解像度が上がってきた

    ◦ 新規立ち上げプロダクトへの信頼性構築の支援 ◦ SLI/SLO のボトルネックへの重点的な分析、改善支援 ◦ インシデント調査時のボトルネック領域への改善支援 • 💡個別の課題が見えてきたタイミングで embedded SRE を設けると、やることが明確
  9. • Enabling SRE ◦ SRE チームとして人を集約することで、優先度の高いタスクにフォーカスできる &ナレッジも集まる ◦ 関連チームや EM,

    PdM とのコミュニケーションを厚くすることで、プロダクトにおける 信頼性の必要性や有用性を広めることができる。チーム単位の課題も見えてくる 二つの SRE タイプを踏まえて
  10. • Embedded SRE ◦ 「SRE」としての役割を期待するなら、やるべき内容や目標の具体化が重要 ◦ 既に課題が顕在化している場合はそこから着手する ▪ パフォーマンスのボトルネック調査や改善が必要 ▪

    アラートやインシデント対応時のプレイブック不足 ◦ フラットな状態から始める場合は SLI/SLO の計画からやるのが良さそう ▪ PdM やエンジニアチームで CUJ ディスカッション、監視や計装の強化 ▪ チーム内でのダッシュボード確認の習慣づけ ◦ SRE チームから一時的に派遣するような関わり方もありそう 二つの SRE タイプを踏まえて
  11. • SRE ポジション/チームの構築は役割と目標をよく考えて進めよう • 参考 ◦ Books For Site Reliability

    Engineering ◦ Embedded SRE at Mercari ◦ Embedded SREとは何か - SREの組織類型についての覚書 - chroju.dev ◦ SaaSのSREチームを立ち上げました - CADDi Tech Blog まとめ