信頼性と向き合う組織⽂化醸成に向けたあれこれ

■イベント
【ユーザベース × Sansan】組織全体で向き合うSaaSプロダクトの信頼性向上への取り組み - UB Tech Vol.13
https://uzabase-tech.connpass.com/event/300220/

■登壇概要
タイトル：信頼性と向き合う組織⽂化醸成に向けたあれこれ
登壇者：技術本部 Eight Engineering Unit 間瀬 哲也

■Sansan 技術本部 採用情報
https://media.sansan-engineering.com/

Transcript

1. Sansan株式会社 部署 名前 信頼性と向き合う 組織⽂化醸成に向けたあれこれ Sansan技術本部 UB Tech vol. 13 技術本部 Eight Engineering Unit 間瀬 哲也
2. 間瀬 哲也 Sansan株式会社 技術本部 Eight Engineering Unit SRE グループ - Sansan株式会社の第1号インフラエンジニアとして⼊社。 当時はSansan (オンプレ時代)、Eight、社内インフラなどを まとめて担当。 - 現在はEightのSREグループのグループマネジャーとして、 SREメンバーがSREとしての⽂化を醸成していくのを温か く⾒守る傍らで、全社のプロダクトインフラの戦略⽴案を 担う。
3. © Sansan, Inc.
4. アジェンダ - EightのSRE - 信頼性と向き合うための取り組み - まとめ - 最後に
5. EightのSRE
6. - 2023年10⽉発⾜ - 旧インフラグループ5名 + 基盤開発メンバー 1名 - SREとして - システム視点ではなく、ユーザー視点でプロダクトの信頼性に向きあう - もちろん、インフラとしてやっていたことも EightのSRE
7. EightのSRE Eight Engineering Unit Eight Engineering Unit Eight開発 イベント開発 インフラ プロダクト開発 基盤開発 Eight 開発 SRE プロダクト開発 アライアンス 開発 イベント開発 アライアンス 開発
8. 信頼性と向き合うための 取り組み
9. 第1期 - きっかけ - ⼈数的に余裕ができてきた - といっても1.5名 → 2.5名 - システムの状態を定量化したい - ⾃分たちの成果を⾒せたい - Push配信などのシステム影響をわかりやすく⽰したい
10. 第1期 - SLOを定義してみよう - インフラチームで集まって議論した - インフラ観点 + サービス/システム全体としての指標を定義した - ある指標から試す - ⼩さく初めてPDCAを回す - ⾃分たちもイメージをつける - ダッシュボード - 定例MTGでの報告・共有をする > 開発メンバー向け: 週次 > 事業部全体向け: ⽉次
11. - SLO: 99.9%⽬標 - ダウンタイム > ヘルスチェックに5分以上継続して失敗がないか - Error Rate > サーバでの5xxエラー率が5分間継続して1%以上となることがないか - Response Time > メインのサービスで95%ileで5分間継続して1sec超となることがないか - 外部サービスAPI > エラーレスポンスが返ることがないか 第1期
12. - PDCAを回す - 最初はかなり過敏なほどにチェックをした > 低下原因 サービスを知る > サービス影響 ユーザを知る > 開発メンバーとの共有 システムを知る - 閾値の⾒直し > サービス影響がないものは緩くする 第1期
13. - 課題 - インフラチームだけが頑張っている感 - 理解の不⾜? - 説明不⾜? - もどかしさ 第1期
14. - Engineering Unitとして信頼性を意識する - 主要機能APIに対してSLI/SLOを設定 > APM > 開発者が意識をしやすい値 > CUJっぽい > 信頼性への意識や⾃分事感 - データベース/クエリのパフォーマンスを意識 > Performance Insights > Observability - 後者は結構定着 第2期
15. - 課題 - 基本的にシステムの状態について⾒ている - ユーザがどのように影響を受けているのかがわかりづらい 第2期
16. - SREグループ発⾜ - CUJ (Critical User Journey) について考える - プロダクト開発・運⽤に関わる全員で考える > プロダクトマネージャ > プロダクト開発チーム > SRE 第3期
17. - 議論する - CUJとは何か > ユーザーが⽬的を完遂するために⾏う特定の動作 - なぜ必要なのか > システムの状態を知りたいわけではない > ユーザの体験が毀損されていないかを知りたい - プロダクトとして⼤切にしているもの - ユーザがなぜEightを使うのか - ユーザージャーニーを複数リストアップ - 優先度付け > 使えないことでどれだけ困るか 第3期
18. 第3期 CUJとそれに内包されるユーザの操作
19. - CUJを考える中での副産物 - SRE (旧インフラ) がEightの機能を知ることができた - Now - ⽬下ユーザージャーニーに紐付く計測可能な指標を洗い出し中 - 計測できていない項⽬の計測⽅法についても検討 第3期
20. まとめ
21. まとめ 第1期から第2期 - はじめは単純なシステム全体の状態を定量化・周知 - 開発者含めて理解を深めていく - より⾝近な指標で体感してもらう - 改善のためのアクションにつなげてもらえる 認知 理解 共感 行動
22. まとめ 第3期 - CUJを考える過程に価値がある - 関係者間のコミュニケーション - 共通認識 - 共通の⽬標 - プロダクトをより深く知ることができる - CUJ⾃体 - 問題発⽣時のユーザ影響がわかりやすい - 今後のオンボーディングにも使える
23. 最後に
24. 最後に 今はまだCUJの第1弾ができあがった段階です。 そこからSLI/SLOを定義し、⽇々運⽤し、PDCAを回していくことでさらに 改善を進めていきます。 この先CUJベースのSLI/SLOを⽤いた運⽤については、また別の機会にご紹 介します。 ぜひ、楽しみにしていてください。
25. Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/