一人から始めるプロダクトSRE / How to start SRE in a product team, all by yourself

SRE NEXT 2022 ONLINE 5.14

「このチームの最初のとして、SRE組織を作ってくれないか」
と言われたとき、あなたならどこからアプローチしますか？
　本に記載された多くのSREプラクティスのすべてをすぐに導入するのは容易くありません。なぜならの役割を果たせるのは現状あなたしかおらず、さらに通常、SRE本に記載されている環境とは前提も異なるからです。
　では、どこから始めればいいのでしょうか。
　本セッションでは、実際にSRE組織の立ち上げ時に実施した内容を紹介しつつ、どのようにアプローチし意思決定したかをお話します。

Transcript

1. SRE NEXT 2022 ONLINE 2022/5/14(Sat.) 一人から始めるプロダクトSRE Money Forward Business Company HRソリューション本部 プロダクト開発部 VTRyo
2. 感想、ご意見は励みになります！ 1 イベントハッシュタグ #srenext Roomタグ #srenextA
3. Who am I VTRyo（りょう） SRE @ Money Forward, Inc クラウド勤怠/クラウド給与 SRE担当 2 @3s_hv https://vtryo.me #srenextA
4. 宣伝… VTRyo（りょう） 作家としても活動しています 3 @3s_hv https://vtryo.me #srenextA
5. 今日話すこと 4 SREのいないプロダクトチームで 一人でSRE活動を始める ときに迷わないためのヒント #srenextA
6. 持ち帰れること 5 1. これからSREを始める人がその現場に合 わせた柔軟な意思決定を自信持ってでき る 2. 目の前の課題解決、SRE立ち位置の定め 方、メンバーの巻き込み方を知り一人から でもSREを始められる #srenextA
7. このセッションの前提となる情報 6 #srenextA
8. このセッションの前提となる情報 7 #srenextA 本日はここの部分。Product SREをどのように始めたか
9. こんなときどうする 8 「プロダクトチームでSREを始めてよ！（意訳）」 #srenextA
10. こんなときどうする 9 どこから始めれば良いのか？ #srenextA 🤔
11. プロダクトSREを始めてほしいと言われたら 1 #srenextA Google SRE本！ SLO！SLI！ ポストモーテム！ トイル！ 他社事例！ Core SRE！ Embedded SRE！ Enabling SRE！
12. プロダクトSREを始めてほしいと言われたら 1 #srenextA Google SRE本！ SLO！SLI！ ポストモーテム！ トイル！ 他社事例！ 大混乱 事例にあるプラクティスをすべてやりたい… しかし、SREはあなたしかいない
13. 問題は、今の所のSREはあなた一人しかいないということだ 1 - SRE本に記載された多くのプラクティスのすべてを すぐに導入するのは非現実的 - SREの役割を果たせるのは現状あなたしかいない さらに通常、本に記載されている環境とは前提も異なる #srenextA
14. このセッションのポイント 1 - SRE組織の立ち上げ時に実施した具体的な事例 - どのように意思決定してそれを実施したのか #srenextA
15. クラウド勤怠の例 1 #srenextA
16. Money Forwardクラウド勤怠 1 #srenextA
17. Money Forwardクラウド勤怠 1 #srenextA
18. クラウド勤怠の例 1 【前提】 - このチーム最初のSREとして参画 - スモールチームのため、開発者をSREにコンバートする余裕はない - SREを意識的に経験している人はこのチームにはいない #srenextA
19. クラウド勤怠の例 1 【前提】 - このチーム最初のSREとして参画 - スモールチームのため、開発者をSREにコンバートする余裕はない - クラウド勤怠のインフラ面はインフラチームに依頼 #srenextA わかっていることをベースに まずは現状を把握しに行きましょう
20. SRE原則を胸に。現場の状況を確認しよう 1 - まずは現状把握を実施 - 転職や異動などでドメイン知識 やチーム状況がわからない場 合は重要 #srenextA
21. チームの課題、状況を観察しよう 2 - 担当するプロダクトチーム、部署において何が課題であるか #srenextA 担当するプロダクトチーム、 部署において何が課題か
22. チームの課題、状況を観察しよう 2 #srenextA
23. チームの課題、状況を観察しよう 2 #srenextA 整理を実施しながら、 現場の課題とも向き合い始める
24. チームの課題、状況を観察しよう 2 - SREを必要としているチーム は、多くの場合で運用ペインが 発生 - フェーズや成熟度によって 異なる。見極める - 理想とのギャップ #srenextA Service Reliability Hierarchy https://sre.google/sre-book/part-III-practices/
25. マネーフォワードクラウド勤怠の場合 2 【（真っ先に課題と感じる）クラウド勤怠で起きていたこと】 - システムに何かが起きているが、何かはわからない - 無差別アラート発火問題 #srenextA
26. マネーフォワードクラウド勤怠の場合 2 【無差別アラート発火問題】 - 毎日エラー通知がSlackに届いている - 見ているけど対応はしない - 「通知はされていますがユーザ影響のないものです」といった いわゆる「オオカミ少年」「割れ窓」状態 - 開発者はただただ集中力を削がれている #srenextA
27. マネーフォワードクラウド勤怠の場合 2 【無差別アラート発火問題】 - 毎日エラー通知がSlackに届いている - 見ているけど対応はしない - 「通知はされていますがユーザ影響のないものです」といった いわゆる「オオカミ少年」「割れ窓」状態 - 開発者はただただ集中力を削がれている #srenextA 開発者生産性が目に見えて低下している…
28. マネーフォワードクラウド勤怠の場合 2 - この無差別アラート発火の問題点 - 通知要件が無設計 - サービスに何が起きているのか（Event）見えてない #srenextA
29. マネーフォワードクラウド勤怠の場合 2 - この無差別通知事件の問題点 - 通知要件が無設計 - サービスに何が起きているのか（Event）見えてない - 人によって情報差があるためにその場で人間が判断してやるかやらな いかを決めている #srenextA ここでSRE原則の出番です
30. マネーフォワードクラウド勤怠の場合 2 意思決定ポイント 1. SREには信頼性と開発速度のバランスを取る責務もある 2. メンバーヒアリングで、通知に関するペインが集中していると判明 3. 適切なモニタリングはService Reliability Hierarchyの一番最初の部分 #srenextA
31. マネーフォワードクラウド勤怠の場合 3 意思決定ポイント 1. SREには信頼性と開発速度のバランスを取る責務もある 2. メンバーヒアリングで通知に関するペインが集中 3. 適切なモニタリングはService Reliability Hierarchyの一番最初の部分 #srenextA まずはモニタリングをエンジニアリングする
32. マネーフォワードクラウド勤怠の場合 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/
33. マネーフォワードクラウド勤怠の場合 3 - 通知要件を見直す - alert, ticket, log - 「エラー率が高い、サービスに影響があるときにだけメンション通知が来 る」など人間の介入が必要な場合を振り分ける - ユーザ影響がないエラーならticketやふりかえり時に見ればよいとする - トラッキングすることに価値はあるが、そのすべてが優先度高であるわけではない #srenextA alertとなる 「サービス影響がある」とは？
34. マネーフォワードクラウド勤怠の場合 3 - SLO/SLIの出番です - 開発チームにヒアリングし、重要な機能や勘所をSLIとして記録 - 暫定のSLOとして設定することで、それを脅かす異常をalertする - このSLOの設定はチーム全体にも納得感が生まれる - 推測するな、計測せよ by Rob Pike - 「エラーたくさん来ていたと思ったけど全体の0.02%じゃん」 #srenextA
35. マネーフォワードクラウド勤怠の場合 3 - SLO/SLIの出番です - 開発チームにヒアリングし、重要な機能や勘所をSLIとして記録 - 暫定のSLOとして設定することで、それを脅かす異常をalertする - このSLOの設定はチーム全体にも納得感が生まれる - 推測するな、計測せよ by Rob Pike - 「エラーたくさん来ていたと思ったけど全体の0.02%じゃん」 #srenextA “Done is better than perfect” SLO/SLIは定期的に見直せばよい
36. マネーフォワードクラウド勤怠の場合 3 - #srenextA
37. マネーフォワードクラウド勤怠の場合 3 - #srenextA ダッシュボードでシステムを俯瞰 + ダッシュボードの使い方を布教
38. マネーフォワードクラウド勤怠の場合 3 - 通知要件を見直す - alert, ticket, log - 「エラー率が高い、サービスに影響があるときにだけメンション通知が来 る」など人間の介入が必要な場合を振り分ける - ユーザ影響がないエラーならticketやふりかえり時に見ればよいとする - トラッキングすることに価値はあるが、そのすべてが優先度高であるわけではない #srenextA 一人から始めるときは まずはプロダクトチームに安心してもらおう
39. 開発者のペインが一つ取り除かれた後 3 - 通知要件を見直す - alert, ticket, log - 「エラー率が高い、サービスに影響があるときにだけメンション通知が来 る」など人間の介入が必要な場合を振り分ける - ユーザ影響がないエラーならticketやふりかえり時に見ればよいとする - トラッキングすることに価値はあるが、そのすべてが優先度高であるわけではない #srenextA 開発者のペインが一つ取り除かれた後
40. 開発者のペインが一つ取り除かれた後 3 【その後取り組んだこと】 - 一般的に、SREはプロダクトチームに何をするのか伝える - このチームでのSREのあり方を考える - 現時点でSREが一人しかいない問題と向き合う - どんな体制で関わるのかを考える #srenextA
41. 開発者のペインが一つ取り除かれた後 4 【その後取り組んだこと】 - 一般的に、SREはプロダクトチームに何をするのか伝える - このチームでのSREのあり方を考える - 現時点でSREが一人しかいない問題と向き合う - どんな体制で関わるのかを考える #srenextA SREとは何をする人か知ってもらう
42. SREについてプロダクトチームに理解してもらう 4 チームにSREという考え方をインストールする - まずはSREとは何かを共有する（一般的な範囲） - このチームのSREとして何をするのか共有する（責務範囲） - 後述するミッション設定により範囲は変化する - あなたが何をする人か知ってもらい、チームと信頼関係を築く あなた自身のReliabilityも高めてください #srenextA
43. SREについてプロダクトチームに理解してもらう 4 #srenextA
44. SREについてプロダクトチームに理解してもらう 4 #srenextA 誤解がありそうなポイントを質問項目にする （互いの期待値がずれると大変）
45. SREについてプロダクトチームに理解してもらう 4 #srenextA その箇所を重点的に資料にして共有会（LT）をした
46. SREについてプロダクトチームに理解してもらう 4 #srenextA
47. SREについて知ってもらった後 4 【その後取り組んだこと】 - 一般的に、SREはプロダクトチームに何をするのか伝える ✅ - このチームでのSREのあり方を考える - 現時点でSREが一人しかいない問題と向き合う - どんな体制で関わるのかを考える #srenextA
48. ミッションの設定 4 Product SREのミッションを決めると… - SREがチームにどんな関わり方をするのかイメージしやすくなる - 具体的にどのようなアプローチを取るか方向性が決まりやすい #srenextA SREのあり方を考える 　= ミッションを考える
49. ミッションの設定 4 Product SREのミッションを決めると… - SREがチームにどんな関わり方をするのかイメージしやすくなる - 具体的にどのようなアプローチを取るか方向性が決まりやすい #srenextA
50. HRソリューション本部SREのミッション 4 「ソフトウェアエンジニアがプロダクトの信頼性と開発速度を 　最大化する活動ができる状態をつくる」 #srenextA 「ソフトウェアエンジニアがプロダクトの信頼性と 開発速度を最大化する活動ができる状態をつくる」
51. HRソリューション本部SREのミッション 5 ミッションの理由 - スモールチーム開発という特性から、プロダクト開発者が自律的にSRE活動 できることが理想と判断 - アポロ誘導コンピュータを設計したマーガレットハミルトンを例に 「SREという単語を知らなくてもSRE活動ができるチーム」は強い #srenextA
52. ミッションが決まった後 5 【その後取り組んだこと】 - 一般的に、SREはプロダクトチームに何をするのか伝える ✅ - このチームでのSREのあり方を考える ✅ - 現時点でSREが一人しかいない問題と向き合う - どんな体制で関わるのかを考える #srenextA
53. SREの体制について考える 5 ミッションから、どのようなSRE体制が最善か考える - Core SRE？ - Embedded SRE？ - Enabling SRE？ （現場の課題によって、組織や会社ごとに定義は若干異なるようです） #srenextA
54. Core SRE 5 横断的、中央集権的な役割を果たすSRE 組織全体を見るSRE向上委員会的立ち位置 SRE Center Of Practiceとも ( https://medium.com/slalom-build/the-many-shapes-of-site-reliability-engineering-468359866517) #srenextA
55. Embedded SRE 5 プロダクトチームに組み込まれるSRE Core SREの実践部隊的立ち位置 #srenextA
56. Enabling SRE 5 プロダクトチーム自身でSRE活動を可能にさせるためのSRE Embedded SREと似ているが、自律性を支援する側面が強くする立ち位置。 #srenextA
57. 一人しかいない問題も合わせて考える 5 - SREに種類があることを踏まえて、自チームに最も適した体制を採用 - 今現時点で最善の一手 - 今後SREが増えれば変更はあるし、してもよいとする - 今は一人しかいなという課題も同時に解決する体制 #srenextA
58. 一人しかいない問題も合わせて考える 5 どちらかに絞った - Embedded SRE - Enabling SRE #srenextA
59. 一人しかいない問題も合わせて考える 5 - Embedded SRE - Enabling SRE #srenextA SREへコンバートできない事情もあり 開発者に自律的にSRE活動してもらうのが一番良い
60. 一人しかいない問題も合わせて考える 5 - Embedded SRE - Enabling SRE #srenextA Enabling SREを採用 （今後変更される可能性あり）
61. 立ち上げ初期の取り組み 6 【その後取り組んだこと】 - 一般的に、SREはプロダクトチームに何をするのか伝える ✅ - このチームでのSREのあり方を考える ✅ - 現時点でSREが一人しかいない問題と向き合う ✅ - どんな体制で関わるのかを考える ✅ #srenextA
62. Enabling SREをやっていく 6 - Embedded SRE - Enabling SRE #srenextA Enabling SREとしての活動事例を一部紹介
63. Enabling SRE 6 - 日々の仕事に隠れたSRE精神を自覚していただく - システムダッシュボードのふりかえり会 - 信頼性や運用効率性に関わるタスク解消時間をつくる #srenextA
64. 日々の仕事に隠れた SRE精神を自覚していただく 6 #srenextA
65. 日々の仕事に隠れた SRE精神を自覚していただく 6 #srenextA SRE活動が無意識でも実施されていたら 良いフィードバックで伝える
66. システムダッシュボードのふりかえり会 6 #srenextA これらに加えて、ticketとしていたエラーについても精査しています ダッシュボードとエラーチケットを同時にふりかえることで、メンバーはシステ ムに対する勘所が鍛えられると信じています
67. システムダッシュボードのふりかえり会 6 #srenextA これらに加えて、ticketとしていたエラーについても精査しています ダッシュボードとエラーチケットを同時にふりかえることで、メンバーはシステ ムに対する勘所が鍛えられると信じています 一朝一夕ではできないため 投資と思って活動していきましょう
68. 信頼性や運用効率性に関わるタスクの優先度付 6 #srenextA 信頼性や運用効率性に関わるタスク解消時間 - 機能開発は最速に実施しつつも、ライブラリアップデートやよりよいログ基盤 構築など、後回しにされがちなタスクを実施する時間を明示的に取るようチー ム全体に働きかけます - リーダー、PM、開発者といった関係者の合意を取ることが重要 - 「締切はないがやるべきこと」は優先度スコアを計算して決める
69. 信頼性や運用効率性に関わるタスクの優先度付 6 #srenextA 参考: SREがプロダクトの価値を最大化するためにチームとして取り組んできたこと 　　　　　 https://tech.dely.jp/entry/2021/10/01/173000
70. 信頼性や運用効率性に関わるタスク作業ログはみんなが見えるところに 6 #srenextA
71. 信頼性や運用効率性に関わるタスク作業ログはみんなが見えるところに 7 #srenextA SREを一人から始めるときは、 どんどん周りに託していこう
72. おかげさまで現在のクラウド勤怠 7 クラウド勤怠の状況 - 疲弊しないモニタリング - SRE活動をするために機能開発とは別枠で時間を確保できる - ふりかえりや障害時に困らないためのログ形式の検討 - SLIを意識した機能パフォーマンス検証の実施 #srenextA
73. おかげさまで現在のクラウド勤怠 7 クラウド勤怠の状況 - 疲弊しないモニタリング - SRE活動をするために機能開発とは別枠で時間を確保できる - ふりかえりや障害時に困らないためのログ形式の検討 - SLIを意識した機能パフォーマンス検の実施 #srenextA Enabling SREとしてはじめの一歩を 踏めたのではないだろうか
74. まとめ 7 一人から始めるプロダクトSRE - プロダクト固有の課題に向き合えることを活かし、まずは状況観察 - Service Reliability Hierarchyを参考に理想と現実とのギャップを埋める - メンバーに自分を信頼してもらえるように働きかける - 「一人しかいない」「SREにコンバートできない」といった現実を加味した体制 を考える - 決めた方針に合わせてSRE活動をちいさく始める #srenextA
75. お約束の 7 マネーフォワードクラウドHR領域では、Enabling SREを募集しています 「背中でも腕でもメンバーを引っ張りたいソフトウェアエンジニア（SRE）」 な方、ぜひお待ちしてます！ #srenextA
76. ご清聴ありがとうございました