Slide 1

Slide 1 text

Sansan株式会社 部署 名前 信頼性と向き合う 組織⽂化醸成に向けたあれこれ Sansan技術本部 UB Tech vol. 13 技術本部 Eight Engineering Unit 間瀬 哲也

Slide 2

Slide 2 text

間瀬 哲也 Sansan株式会社 技術本部 Eight Engineering Unit SRE グループ - Sansan株式会社の第1号インフラエンジニアとして⼊社。 当時はSansan (オンプレ時代)、Eight、社内インフラなどを まとめて担当。 - 現在はEightのSREグループのグループマネジャーとして、 SREメンバーがSREとしての⽂化を醸成していくのを温か く⾒守る傍らで、全社のプロダクトインフラの戦略⽴案を 担う。

Slide 3

Slide 3 text

© Sansan, Inc.

Slide 4

Slide 4 text

アジェンダ - EightのSRE - 信頼性と向き合うための取り組み - まとめ - 最後に

Slide 5

Slide 5 text

EightのSRE

Slide 6

Slide 6 text

- 2023年10⽉発⾜ - 旧インフラグループ5名 + 基盤開発メンバー 1名 - SREとして - システム視点ではなく、ユーザー視点でプロダクトの信頼性に向きあう - もちろん、インフラとしてやっていたことも EightのSRE

Slide 7

Slide 7 text

EightのSRE Eight Engineering Unit Eight Engineering Unit Eight開発 イベント開発 インフラ プロダクト開発 基盤開発 Eight 開発 SRE プロダクト開発 アライアンス 開発 イベント開発 アライアンス 開発

Slide 8

Slide 8 text

信頼性と向き合うための 取り組み

Slide 9

Slide 9 text

第1期 - きっかけ - ⼈数的に余裕ができてきた - といっても1.5名 → 2.5名 - システムの状態を定量化したい - ⾃分たちの成果を⾒せたい - Push配信などのシステム影響をわかりやすく⽰したい

Slide 10

Slide 10 text

第1期 - SLOを定義してみよう - インフラチームで集まって議論した - インフラ観点 + サービス/システム全体としての指標を定義した - ある指標から試す - ⼩さく初めてPDCAを回す - ⾃分たちもイメージをつける - ダッシュボード - 定例MTGでの報告・共有をする > 開発メンバー向け: 週次 > 事業部全体向け: ⽉次

Slide 11

Slide 11 text

- SLO: 99.9%⽬標 - ダウンタイム > ヘルスチェックに5分以上継続して失敗がないか - Error Rate > サーバでの5xxエラー率が5分間継続して1%以上となることがないか - Response Time > メインのサービスで95%ileで5分間継続して1sec超となることがないか - 外部サービスAPI > エラーレスポンスが返ることがないか 第1期

Slide 12

Slide 12 text

- PDCAを回す - 最初はかなり過敏なほどにチェックをした > 低下原因 サービスを知る > サービス影響 ユーザを知る > 開発メンバーとの共有 システムを知る - 閾値の⾒直し > サービス影響がないものは緩くする 第1期

Slide 13

Slide 13 text

- 課題 - インフラチームだけが頑張っている感 - 理解の不⾜? - 説明不⾜? - もどかしさ 第1期

Slide 14

Slide 14 text

- Engineering Unitとして信頼性を意識する - 主要機能APIに対してSLI/SLOを設定 > APM > 開発者が意識をしやすい値 > CUJっぽい > 信頼性への意識や⾃分事感 - データベース/クエリのパフォーマンスを意識 > Performance Insights > Observability - 後者は結構定着 第2期

Slide 15

Slide 15 text

- 課題 - 基本的にシステムの状態について⾒ている - ユーザがどのように影響を受けているのかがわかりづらい 第2期

Slide 16

Slide 16 text

- SREグループ発⾜ - CUJ (Critical User Journey) について考える - プロダクト開発・運⽤に関わる全員で考える > プロダクトマネージャ > プロダクト開発チーム > SRE 第3期

Slide 17

Slide 17 text

- 議論する - CUJとは何か > ユーザーが⽬的を完遂するために⾏う特定の動作 - なぜ必要なのか > システムの状態を知りたいわけではない > ユーザの体験が毀損されていないかを知りたい - プロダクトとして⼤切にしているもの - ユーザがなぜEightを使うのか - ユーザージャーニーを複数リストアップ - 優先度付け > 使えないことでどれだけ困るか 第3期

Slide 18

Slide 18 text

第3期 CUJとそれに内包されるユーザの操作

Slide 19

Slide 19 text

- CUJを考える中での副産物 - SRE (旧インフラ) がEightの機能を知ることができた - Now - ⽬下ユーザージャーニーに紐付く計測可能な指標を洗い出し中 - 計測できていない項⽬の計測⽅法についても検討 第3期

Slide 20

Slide 20 text

まとめ

Slide 21

Slide 21 text

まとめ 第1期から第2期 - はじめは単純なシステム全体の状態を定量化・周知 - 開発者含めて理解を深めていく - より⾝近な指標で体感してもらう - 改善のためのアクションにつなげてもらえる 認知 理解 共感 行動

Slide 22

Slide 22 text

まとめ 第3期 - CUJを考える過程に価値がある - 関係者間のコミュニケーション - 共通認識 - 共通の⽬標 - プロダクトをより深く知ることができる - CUJ⾃体 - 問題発⽣時のユーザ影響がわかりやすい - 今後のオンボーディングにも使える

Slide 23

Slide 23 text

最後に

Slide 24

Slide 24 text

最後に 今はまだCUJの第1弾ができあがった段階です。 そこからSLI/SLOを定義し、⽇々運⽤し、PDCAを回していくことでさらに 改善を進めていきます。 この先CUJベースのSLI/SLOを⽤いた運⽤については、また別の機会にご紹 介します。 ぜひ、楽しみにしていてください。

Slide 25

Slide 25 text

Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/

Slide 26

Slide 26 text

No content