Slide 1

Slide 1 text

SRE NEXT 2022 ONLINE 2022/5/14(Sat.) 一人から始めるプロダクトSRE Money Forward Business Company HRソリューション本部 プロダクト開発部 VTRyo

Slide 2

Slide 2 text

感想、ご意見は励みになります! 1 イベントハッシュタグ #srenext Roomタグ #srenextA

Slide 3

Slide 3 text

Who am I VTRyo(りょう) SRE @ Money Forward, Inc クラウド勤怠/クラウド給与 SRE担当 2 @3s_hv https://vtryo.me #srenextA

Slide 4

Slide 4 text

宣伝… VTRyo(りょう) 作家としても活動しています 3 @3s_hv https://vtryo.me #srenextA

Slide 5

Slide 5 text

今日話すこと 4 SREのいないプロダクトチームで 一人でSRE活動を始める ときに迷わないためのヒント #srenextA

Slide 6

Slide 6 text

持ち帰れること 5 1. これからSREを始める人がその現場に合 わせた柔軟な意思決定を自信持ってでき る 2. 目の前の課題解決、SRE立ち位置の定め 方、メンバーの巻き込み方を知り一人から でもSREを始められる #srenextA

Slide 7

Slide 7 text

このセッションの前提となる情報 6 #srenextA

Slide 8

Slide 8 text

このセッションの前提となる情報 7 #srenextA 本日はここの部分。Product SREをどのように始めたか

Slide 9

Slide 9 text

こんなときどうする 8 「プロダクトチームでSREを始めてよ!(意訳)」 #srenextA

Slide 10

Slide 10 text

こんなときどうする 9 どこから始めれば良いのか? #srenextA 🤔

Slide 11

Slide 11 text

プロダクトSREを始めてほしいと言われたら 1 #srenextA Google SRE本! SLO!SLI! ポストモーテム! トイル! 他社事例! Core SRE! Embedded SRE! Enabling SRE!

Slide 12

Slide 12 text

プロダクトSREを始めてほしいと言われたら 1 #srenextA Google SRE本! SLO!SLI! ポストモーテム! トイル! 他社事例! 大混乱 事例にあるプラクティスをすべてやりたい… しかし、SREはあなたしかいない

Slide 13

Slide 13 text

問題は、今の所のSREはあなた一人しかいないということだ 1 - SRE本に記載された多くのプラクティスのすべてを すぐに導入するのは非現実的 - SREの役割を果たせるのは現状あなたしかいない さらに通常、本に記載されている環境とは前提も異なる #srenextA

Slide 14

Slide 14 text

このセッションのポイント 1 - SRE組織の立ち上げ時に実施した具体的な事例 - どのように意思決定してそれを実施したのか #srenextA

Slide 15

Slide 15 text

クラウド勤怠の例 1 #srenextA

Slide 16

Slide 16 text

Money Forwardクラウド勤怠 1 #srenextA

Slide 17

Slide 17 text

Money Forwardクラウド勤怠 1 #srenextA

Slide 18

Slide 18 text

クラウド勤怠の例 1 【前提】 - このチーム最初のSREとして参画 - スモールチームのため、開発者をSREにコンバートする余裕はない - SREを意識的に経験している人はこのチームにはいない #srenextA

Slide 19

Slide 19 text

クラウド勤怠の例 1 【前提】 - このチーム最初のSREとして参画 - スモールチームのため、開発者をSREにコンバートする余裕はない - クラウド勤怠のインフラ面はインフラチームに依頼 #srenextA わかっていることをベースに まずは現状を把握しに行きましょう

Slide 20

Slide 20 text

SRE原則を胸に。現場の状況を確認しよう 1 - まずは現状把握を実施 - 転職や異動などでドメイン知識 やチーム状況がわからない場 合は重要 #srenextA

Slide 21

Slide 21 text

チームの課題、状況を観察しよう 2 - 担当するプロダクトチーム、部署において何が課題であるか #srenextA 担当するプロダクトチーム、 部署において何が課題か

Slide 22

Slide 22 text

チームの課題、状況を観察しよう 2 #srenextA

Slide 23

Slide 23 text

チームの課題、状況を観察しよう 2 #srenextA 整理を実施しながら、 現場の課題とも向き合い始める

Slide 24

Slide 24 text

チームの課題、状況を観察しよう 2 - SREを必要としているチーム は、多くの場合で運用ペインが 発生 - フェーズや成熟度によって 異なる。見極める - 理想とのギャップ #srenextA Service Reliability Hierarchy https://sre.google/sre-book/part-III-practices/

Slide 25

Slide 25 text

マネーフォワードクラウド勤怠の場合 2 【(真っ先に課題と感じる)クラウド勤怠で起きていたこと】 - システムに何かが起きているが、何かはわからない - 無差別アラート発火問題 #srenextA

Slide 26

Slide 26 text

マネーフォワードクラウド勤怠の場合 2 【無差別アラート発火問題】 - 毎日エラー通知がSlackに届いている - 見ているけど対応はしない - 「通知はされていますがユーザ影響のないものです」といった いわゆる「オオカミ少年」「割れ窓」状態 - 開発者はただただ集中力を削がれている #srenextA

Slide 27

Slide 27 text

マネーフォワードクラウド勤怠の場合 2 【無差別アラート発火問題】 - 毎日エラー通知がSlackに届いている - 見ているけど対応はしない - 「通知はされていますがユーザ影響のないものです」といった いわゆる「オオカミ少年」「割れ窓」状態 - 開発者はただただ集中力を削がれている #srenextA 開発者生産性が目に見えて低下している…

Slide 28

Slide 28 text

マネーフォワードクラウド勤怠の場合 2 - この無差別アラート発火の問題点 - 通知要件が無設計 - サービスに何が起きているのか(Event)見えてない #srenextA

Slide 29

Slide 29 text

マネーフォワードクラウド勤怠の場合 2 - この無差別通知事件の問題点 - 通知要件が無設計 - サービスに何が起きているのか(Event)見えてない - 人によって情報差があるためにその場で人間が判断してやるかやらな いかを決めている #srenextA ここでSRE原則の出番です

Slide 30

Slide 30 text

マネーフォワードクラウド勤怠の場合 2 意思決定ポイント 1. SREには信頼性と開発速度のバランスを取る責務もある 2. メンバーヒアリングで、通知に関するペインが集中していると判明 3. 適切なモニタリングはService Reliability Hierarchyの一番最初の部分 #srenextA

Slide 31

Slide 31 text

マネーフォワードクラウド勤怠の場合 3 意思決定ポイント 1. SREには信頼性と開発速度のバランスを取る責務もある 2. メンバーヒアリングで通知に関するペインが集中 3. 適切なモニタリングはService Reliability Hierarchyの一番最初の部分 #srenextA まずはモニタリングをエンジニアリングする

Slide 32

Slide 32 text

マネーフォワードクラウド勤怠の場合 3 - 通知要件を見直す - alert, ticket, log ( https://sre.google/in-conversation/ Let's discuss monitoring, a core SRE responsibility. Can you talk about the philosophy behind SRE and monitoring?) - 「エラー率が高い、サービスに影響があるときにだけメンション通知が来 る」など人間の介入が必要な場合を振り分ける - ユーザ影響がないエラーならticketやふりかえり時に見ればよいとする - トラッキングすることに価値はあるが、そのすべてが優先度高であるわけではない #srenextA https://moneyforward.com/engineers_blog/2021/11/29/visualize/

Slide 33

Slide 33 text

マネーフォワードクラウド勤怠の場合 3 - 通知要件を見直す - alert, ticket, log - 「エラー率が高い、サービスに影響があるときにだけメンション通知が来 る」など人間の介入が必要な場合を振り分ける - ユーザ影響がないエラーならticketやふりかえり時に見ればよいとする - トラッキングすることに価値はあるが、そのすべてが優先度高であるわけではない #srenextA alertとなる 「サービス影響がある」とは?

Slide 34

Slide 34 text

マネーフォワードクラウド勤怠の場合 3 - SLO/SLIの出番です - 開発チームにヒアリングし、重要な機能や勘所をSLIとして記録 - 暫定のSLOとして設定することで、それを脅かす異常をalertする - このSLOの設定はチーム全体にも納得感が生まれる - 推測するな、計測せよ by Rob Pike - 「エラーたくさん来ていたと思ったけど全体の0.02%じゃん」 #srenextA

Slide 35

Slide 35 text

マネーフォワードクラウド勤怠の場合 3 - SLO/SLIの出番です - 開発チームにヒアリングし、重要な機能や勘所をSLIとして記録 - 暫定のSLOとして設定することで、それを脅かす異常をalertする - このSLOの設定はチーム全体にも納得感が生まれる - 推測するな、計測せよ by Rob Pike - 「エラーたくさん来ていたと思ったけど全体の0.02%じゃん」 #srenextA “Done is better than perfect” SLO/SLIは定期的に見直せばよい

Slide 36

Slide 36 text

マネーフォワードクラウド勤怠の場合 3 - #srenextA

Slide 37

Slide 37 text

マネーフォワードクラウド勤怠の場合 3 - #srenextA ダッシュボードでシステムを俯瞰 + ダッシュボードの使い方を布教

Slide 38

Slide 38 text

マネーフォワードクラウド勤怠の場合 3 - 通知要件を見直す - alert, ticket, log - 「エラー率が高い、サービスに影響があるときにだけメンション通知が来 る」など人間の介入が必要な場合を振り分ける - ユーザ影響がないエラーならticketやふりかえり時に見ればよいとする - トラッキングすることに価値はあるが、そのすべてが優先度高であるわけではない #srenextA 一人から始めるときは まずはプロダクトチームに安心してもらおう

Slide 39

Slide 39 text

開発者のペインが一つ取り除かれた後 3 - 通知要件を見直す - alert, ticket, log - 「エラー率が高い、サービスに影響があるときにだけメンション通知が来 る」など人間の介入が必要な場合を振り分ける - ユーザ影響がないエラーならticketやふりかえり時に見ればよいとする - トラッキングすることに価値はあるが、そのすべてが優先度高であるわけではない #srenextA 開発者のペインが一つ取り除かれた後

Slide 40

Slide 40 text

開発者のペインが一つ取り除かれた後 3 【その後取り組んだこと】 - 一般的に、SREはプロダクトチームに何をするのか伝える - このチームでのSREのあり方を考える - 現時点でSREが一人しかいない問題と向き合う - どんな体制で関わるのかを考える #srenextA

Slide 41

Slide 41 text

開発者のペインが一つ取り除かれた後 4 【その後取り組んだこと】 - 一般的に、SREはプロダクトチームに何をするのか伝える - このチームでのSREのあり方を考える - 現時点でSREが一人しかいない問題と向き合う - どんな体制で関わるのかを考える #srenextA SREとは何をする人か知ってもらう

Slide 42

Slide 42 text

SREについてプロダクトチームに理解してもらう 4 チームにSREという考え方をインストールする - まずはSREとは何かを共有する(一般的な範囲) - このチームのSREとして何をするのか共有する(責務範囲) - 後述するミッション設定により範囲は変化する - あなたが何をする人か知ってもらい、チームと信頼関係を築く あなた自身のReliabilityも高めてください #srenextA

Slide 43

Slide 43 text

SREについてプロダクトチームに理解してもらう 4 #srenextA

Slide 44

Slide 44 text

SREについてプロダクトチームに理解してもらう 4 #srenextA 誤解がありそうなポイントを質問項目にする (互いの期待値がずれると大変)

Slide 45

Slide 45 text

SREについてプロダクトチームに理解してもらう 4 #srenextA その箇所を重点的に資料にして共有会(LT)をした

Slide 46

Slide 46 text

SREについてプロダクトチームに理解してもらう 4 #srenextA

Slide 47

Slide 47 text

SREについて知ってもらった後 4 【その後取り組んだこと】 - 一般的に、SREはプロダクトチームに何をするのか伝える ✅ - このチームでのSREのあり方を考える - 現時点でSREが一人しかいない問題と向き合う - どんな体制で関わるのかを考える #srenextA

Slide 48

Slide 48 text

ミッションの設定 4 Product SREのミッションを決めると… - SREがチームにどんな関わり方をするのかイメージしやすくなる - 具体的にどのようなアプローチを取るか方向性が決まりやすい #srenextA SREのあり方を考える  = ミッションを考える

Slide 49

Slide 49 text

ミッションの設定 4 Product SREのミッションを決めると… - SREがチームにどんな関わり方をするのかイメージしやすくなる - 具体的にどのようなアプローチを取るか方向性が決まりやすい #srenextA

Slide 50

Slide 50 text

HRソリューション本部SREのミッション 4 「ソフトウェアエンジニアがプロダクトの信頼性と開発速度を  最大化する活動ができる状態をつくる」 #srenextA 「ソフトウェアエンジニアがプロダクトの信頼性と 開発速度を最大化する活動ができる状態をつくる」

Slide 51

Slide 51 text

HRソリューション本部SREのミッション 5 ミッションの理由 - スモールチーム開発という特性から、プロダクト開発者が自律的にSRE活動 できることが理想と判断 - アポロ誘導コンピュータを設計したマーガレットハミルトンを例に 「SREという単語を知らなくてもSRE活動ができるチーム」は強い #srenextA

Slide 52

Slide 52 text

ミッションが決まった後 5 【その後取り組んだこと】 - 一般的に、SREはプロダクトチームに何をするのか伝える ✅ - このチームでのSREのあり方を考える ✅ - 現時点でSREが一人しかいない問題と向き合う - どんな体制で関わるのかを考える #srenextA

Slide 53

Slide 53 text

SREの体制について考える 5 ミッションから、どのようなSRE体制が最善か考える - Core SRE? - Embedded SRE? - Enabling SRE? (現場の課題によって、組織や会社ごとに定義は若干異なるようです) #srenextA

Slide 54

Slide 54 text

Core SRE 5 横断的、中央集権的な役割を果たすSRE 組織全体を見るSRE向上委員会的立ち位置 SRE Center Of Practiceとも ( https://medium.com/slalom-build/the-many-shapes-of-site-reliability-engineering-468359866517) #srenextA

Slide 55

Slide 55 text

Embedded SRE 5 プロダクトチームに組み込まれるSRE Core SREの実践部隊的立ち位置 #srenextA

Slide 56

Slide 56 text

Enabling SRE 5 プロダクトチーム自身でSRE活動を可能にさせるためのSRE Embedded SREと似ているが、自律性を支援する側面が強くする立ち位置。 #srenextA

Slide 57

Slide 57 text

一人しかいない問題も合わせて考える 5 - SREに種類があることを踏まえて、自チームに最も適した体制を採用 - 今現時点で最善の一手 - 今後SREが増えれば変更はあるし、してもよいとする - 今は一人しかいなという課題も同時に解決する体制 #srenextA

Slide 58

Slide 58 text

一人しかいない問題も合わせて考える 5 どちらかに絞った - Embedded SRE - Enabling SRE #srenextA

Slide 59

Slide 59 text

一人しかいない問題も合わせて考える 5 - Embedded SRE - Enabling SRE #srenextA SREへコンバートできない事情もあり 開発者に自律的にSRE活動してもらうのが一番良い

Slide 60

Slide 60 text

一人しかいない問題も合わせて考える 5 - Embedded SRE - Enabling SRE #srenextA Enabling SREを採用 (今後変更される可能性あり)

Slide 61

Slide 61 text

立ち上げ初期の取り組み 6 【その後取り組んだこと】 - 一般的に、SREはプロダクトチームに何をするのか伝える ✅ - このチームでのSREのあり方を考える ✅ - 現時点でSREが一人しかいない問題と向き合う ✅ - どんな体制で関わるのかを考える ✅ #srenextA

Slide 62

Slide 62 text

Enabling SREをやっていく 6 - Embedded SRE - Enabling SRE #srenextA Enabling SREとしての活動事例を一部紹介

Slide 63

Slide 63 text

Enabling SRE 6 - 日々の仕事に隠れたSRE精神を自覚していただく - システムダッシュボードのふりかえり会 - 信頼性や運用効率性に関わるタスク解消時間をつくる #srenextA

Slide 64

Slide 64 text

日々の仕事に隠れた SRE精神を自覚していただく 6 #srenextA

Slide 65

Slide 65 text

日々の仕事に隠れた SRE精神を自覚していただく 6 #srenextA SRE活動が無意識でも実施されていたら 良いフィードバックで伝える

Slide 66

Slide 66 text

システムダッシュボードのふりかえり会 6 #srenextA これらに加えて、ticketとしていたエラーについても精査しています ダッシュボードとエラーチケットを同時にふりかえることで、メンバーはシステ ムに対する勘所が鍛えられると信じています

Slide 67

Slide 67 text

システムダッシュボードのふりかえり会 6 #srenextA これらに加えて、ticketとしていたエラーについても精査しています ダッシュボードとエラーチケットを同時にふりかえることで、メンバーはシステ ムに対する勘所が鍛えられると信じています 一朝一夕ではできないため 投資と思って活動していきましょう

Slide 68

Slide 68 text

信頼性や運用効率性に関わるタスクの優先度付 6 #srenextA 信頼性や運用効率性に関わるタスク解消時間 - 機能開発は最速に実施しつつも、ライブラリアップデートやよりよいログ基盤 構築など、後回しにされがちなタスクを実施する時間を明示的に取るようチー ム全体に働きかけます - リーダー、PM、開発者といった関係者の合意を取ることが重要 - 「締切はないがやるべきこと」は優先度スコアを計算して決める

Slide 69

Slide 69 text

信頼性や運用効率性に関わるタスクの優先度付 6 #srenextA 参考: SREがプロダクトの価値を最大化するためにチームとして取り組んできたこと       https://tech.dely.jp/entry/2021/10/01/173000

Slide 70

Slide 70 text

信頼性や運用効率性に関わるタスク作業ログはみんなが見えるところに 6 #srenextA

Slide 71

Slide 71 text

信頼性や運用効率性に関わるタスク作業ログはみんなが見えるところに 7 #srenextA SREを一人から始めるときは、 どんどん周りに託していこう

Slide 72

Slide 72 text

おかげさまで現在のクラウド勤怠 7 クラウド勤怠の状況 - 疲弊しないモニタリング - SRE活動をするために機能開発とは別枠で時間を確保できる - ふりかえりや障害時に困らないためのログ形式の検討 - SLIを意識した機能パフォーマンス検証の実施 #srenextA

Slide 73

Slide 73 text

おかげさまで現在のクラウド勤怠 7 クラウド勤怠の状況 - 疲弊しないモニタリング - SRE活動をするために機能開発とは別枠で時間を確保できる - ふりかえりや障害時に困らないためのログ形式の検討 - SLIを意識した機能パフォーマンス検の実施 #srenextA Enabling SREとしてはじめの一歩を 踏めたのではないだろうか

Slide 74

Slide 74 text

まとめ 7 一人から始めるプロダクトSRE - プロダクト固有の課題に向き合えることを活かし、まずは状況観察 - Service Reliability Hierarchyを参考に理想と現実とのギャップを埋める - メンバーに自分を信頼してもらえるように働きかける - 「一人しかいない」「SREにコンバートできない」といった現実を加味した体制 を考える - 決めた方針に合わせてSRE活動をちいさく始める #srenextA

Slide 75

Slide 75 text

お約束の 7 マネーフォワードクラウドHR領域では、Enabling SREを募集しています 「背中でも腕でもメンバーを引っ張りたいソフトウェアエンジニア(SRE)」 な方、ぜひお待ちしてます! #srenextA

Slide 76

Slide 76 text

ご清聴ありがとうございました