$30 off During Our Annual Pro Sale. View Details »

サービスと開発者に最も近いProduct SREsとして 取り組んでいるコト / Work as Product SREs closest to services and developers

VTRyo
August 23, 2022

サービスと開発者に最も近いProduct SREsとして 取り組んでいるコト / Work as Product SREs closest to services and developers

2022/8/23 多様化し続けるSREのLT会
https://moneyforward.connpass.com/event/250555/

VTRyo

August 23, 2022
Tweet

More Decks by VTRyo

Other Decks in Technology

Transcript

  1. サービスと開発者に最も近い Product SREsとして 取り組んでいるコト マネーフォワード HRソリューション本部 SREグループ VTRyo

  2. Table of contents 2 • 自己紹介 • Product SREsとしてのお仕事 ◦

    SREプラクティスのインストール活動 ▪ SLO/SLIを設定 or 再定義する ◦ チームによって異なるシステム課題の解決
  3. VTRyo(リョウ) - マネーフォワード HR領域のProduct SRE - 現場の仕事から採用、広報、メンバー評価など立ち上げに必 要なこと全部やります - 最近は自身のオブザーバビリティを高めています

    - ブクログとwithingsのPrometheus Exporter を書いてGrafanaで見る図 3
  4. VTRyo(リョウ) - SRE NEXT 2022 ONLINEでもProduct SRE関連で登壇 4

  5. Product SREsとしてのお仕事 ※今回は採用やSREチーム自体の話はしません

  6. 6

  7. 7

  8. SREを前へ ソフトウェアエンジニア自身が SREプラクティスを知り、 信頼性を高められる世界観へ 8

  9. ソフトウェアエンジニア自身が SREプラクティスを実行できるまでの大道筋 9 1 3 2 SREと共にSREプラクティ スが実施できる SREによる支援なしでSRE プラクティスが実施できる

    SREによる支援があればSRE プラクティスが実施できる 0 SREプラクティスが実施さ れていない 0 SREsがチームに 配置される準備が整う ? 「俺がSREだ」 「そしてお前もSREだ」
  10. 信頼性階層を 積み上げる プロダクトチームがどの階層 にいるのか見極め SREプラクティスを実施するの かも見ていた 10 引用: Google -

    Site Reliability Engineering
  11. 11

  12. SLOの実装 12

  13. “ SRE の中核的な責任は、単に「何もかも」自動化することや、ペー ジャーを持っておくことで はありません。SRE の日々のタスクやプロ ジェクトは、SLO によって駆動されます。 すなわち、 短期的には

    SLO を守ること、そしてそれらが中長期的に 維持し続けられるようにするということなのです。 SLO がなければ、SRE の必要性もないとさえ言えるでしょう。 引用: O'Reilly Japan - サイトリライアビリティワークブック 13
  14. クラウド勤怠・クラウド給与 暫定SLOを実装していたので、 今年はよりコア機能に迫った改 定を実施。 SLIの洗い出しからプロダクト チームとともに伴走。 チームによってはPMやデザイ ナーも同席した 各プロダクトに合わせたSLOを実装する クラウド人事管理

    今年からSREプラクティスを開 始。 SLOがなかったため新規で実 装。まずはプロダクトチームに理 解してもらうため、シンプルなも のを意識。 14
  15. 15 プロダクトチームと の連携 SLIとは何か。 プロダクトにとってどう良いの か。 何回かに分けてオンボードし SLIの洗い出しを実施

  16. 16 SLIブレスト with プロダクトチーム

  17. 17 Datadogによる SLOの実装 Miroでグルーピングした測定 すべき機能ごとにSLOを設定

  18. 18 SRE内レビューの 様子 PJ管理はGitHubで完結。 プロダクトチームへ展開する 場合は情報共有ツールへ

  19. ここで疑問 ✋ SREとプロダクトチーム、 タスクを主導する境界線はどこなのか SLOひとつとってもSREが主導するチームと、 プロダクトチームと伴走するチームとで分岐した 19

  20. 「開発者よりもSREの方が効率的に達成でき る場合のみ、関与する」 • Google SRE’sのミッションを参考 How Google SRE and Developers

    Collaborate - IT Revolution • 最終的にプロダクトチームがSREプラクティスを実施 できる世界線にしたい • 今すでにできていることを Product SREがあえて巻き取ることはない • この判断は対象の成熟度によって異なる 20
  21. “ Google SRE’s mission is to: - Ensure that Google’s

    products and infrastructure meet their availability targets. - Subject to (1), maximize long-term feature velocity. - Use software rather than human toil to accomplish (1) and (2). - Engage only when (1) through (3) are accomplished more efficiently by SRE than developers. How Google SRE and Developers Collaborate - IT Revolution 21
  22. チームによって 異なるシステム課題の解決 22

  23. SLOを守るために必要なシステム課題解決 - 各チームでフェーズが異なり、求められるスキル セットも異なる - プロダクトチームと話し合い、直近問題となっている 部分や将来の懸念を収集してそれぞれロードマップ 化 - 都度発生する予定外の課題解決も実施

    (Help wanted) 23
  24. 主なハードスキルセット 24

  25. もっと聞きたい人は カジュアル面談で😉 SNSでも可 • @3s_hv 25

  26. まとめ

  27. Product SREsとして取り組んでいるコト - プロダクトチームがSREプラクティスを取り入れ、自 身で運用できるようになるための支援 - SREsが担当したほうが効率的な場合は主導 - 徐々にプロダクトチームへ委譲する -

    プロダクトの信頼性を脅かす課題を先手を打って解 決へ持っていく 27
  28. SRE Foward by VTRyo