Share
Embed
Slide 1
Slide 1 text
EightのSREが向き合うプロダクトと組織
Sansan株式会社
技術本部 Eight Engineering Unit
間瀬 哲也
Findy Job LT
【SRE特集】プロダクト成⻑を⽀えるSRE 役割の変遷と今後の挑戦とは？
Slide 2
Slide 2 text
2
© Sansan, Inc.
所属
- Sansan株式会社
技術本部 Eight Engineering Unit
Platform グループ / Product Dev グループ
兼 技術本部 VPoE室 インフラ戦略グループ
略歴
- 2010年9⽉ Sansan株式会社⼊社
- オンプレ時代のSansan
- 社内のIP電話設定
- インフラをAWSへリプレイス
- Eightの⽴ち上げ など
⾃⼰紹介
Slide 3
Slide 3 text
3
© Sansan, Inc.
営業DXサービス 名刺アプリ
インボイス管理サービス 契約データベース
Slide 4
Slide 4 text
4
© Sansan, Inc.
© Sansan, Inc.
Slide 5
Slide 5 text
5
© Sansan, Inc.
Slide 6
Slide 6 text
6
© Sansan, Inc.
Slide 7
Slide 7 text
Eight の開発組織
Slide 8
Slide 8 text
8
© Sansan, Inc.
開発体制
Eight事業部
Eight
Eingineering
Unit
Quality Assurance
グループ
Eight Event
プロダクトマネジメント プロダクトマネジメント
Web/API Web/API
iOS
Android
⽣産性改善
SRE
QA QA
ビジネスサイド ビジネスサイド
Slide 9
Slide 9 text
Eight SRE の歴史
Slide 10
Slide 10 text
10
© Sansan, Inc.
ざっくり歴史
第1期
インフラチームとして
SLOを策定
第2期
主要機能の
SLOを策定
第3期
SREチーム誕⽣
CUJ+SLOを策定
第4期
SREチームとして
パフォーマンス改善
Slide 11
Slide 11 text
11
© Sansan, Inc.
第1期 インフラチームとしてSLOを策定
- モチベーション
- システムの状態 ≒ ⾃分たちの成果を定量化したい
- ユーザ体験の毀損を明らかにしたい
> メール配信
> Push通知配信
- 観点
- インフラの可⽤性
- サービス/システム全体としての指標
Slide 12
Slide 12 text
12
© Sansan, Inc.
第1期 インフラチームとしてSLOを策定
- 活動
- 定例で開発チームやEight事業部にも共有
- ひたすらPDCAを回す
> 原因調査
> サービス影響調査
> 開発メンバーへの共有
> 閾値の⾒直し
- 課題
- インフラチームだけでやっている
- 理解(のための説明)不⾜
- システム全体での影響度
Slide 13
Slide 13 text
13
© Sansan, Inc.
- モチベーション
- インフラチームだけでなくEight Engineering Unitとして意識をする
> 開発者も⾃分事感が持てること
- 観点
- API単位
> APMを活⽤
- DBパフォーマンス
> Amazon Aurora の Performance Insights を活⽤
> SLOではなく、Observabilityの向上
第2期 主要機能のSLOを仮策定
Slide 14
Slide 14 text
14
© Sansan, Inc.
- 活動
- 定例で開発チームとインフラで共有
- Performance Insightsを⾒るようにする
> ドキュメンテーション
> 問題発⽣時の参考スクリーンショットでの利⽤
- 課題
- システムとしての影響だけを⾒ている
- 開発としての優先度に影響を及ぼせない
第2期 主要機能のSLOを仮策定
Slide 15
Slide 15 text
15
© Sansan, Inc.
- モチベーション
- CUJの策定
> SREチーム + プロダクト開発チーム + プロダクトマネージャ
> ユーザの体験毀損を定量化
- 観点
- システムではなく、ユーザへの影響
- プロダクトとしての重要度
- ウィンドウベースSLOではなく、イベントベースSLO
第3期 SREチーム誕⽣
Slide 16
Slide 16 text
16
© Sansan, Inc.
- 活動
- CUJの策定
- イベントベースなSLOの設定
- ダッシュボード
- アラート
- 課題
- ⾮同期処理のパフォーマンスが計測できていない
- モバイルアプリについての問題が計測できていない
- 開発としての優先度に影響を及ぼせていない (再)
第3期 SREチーム誕⽣
Slide 17
Slide 17 text
17
© Sansan, Inc.
- モチベーション
- SREになる
- インフラ業、データ基盤業に追われすぎている
- SREとしてパフォーマンスを改善を実践
- 観点
- SLOの低下に限らない
- ユーザ体験の毀損を減らす
- (裏) アプリケーション実装に関わることへのハードルを取り除く
第4期 SREチームとしてパフォーマンス改善
Now!!
Slide 18
Slide 18 text
18
© Sansan, Inc.
- 活動
- 他部⾨への改善アプローチ
- 名刺のデータ化
- 不要処理の除去
- ⾮効率処理の改善
- 課題
- 実装⼒やドメイン知識の不⾜
- 劇的な改善項⽬があまりない
第4期 SREチームとしてパフォーマンス改善
Now!!
Slide 19
Slide 19 text
Eight SRE のこれから
Slide 20
Slide 20 text
我々はまだ黎明期
Slide 21
Slide 21 text
21
© Sansan, Inc.
- 信頼性向上
- 抽象的な⽬標
- チーム内の認識をそろえる
⇒ Maturity Modelの定義と実践
- ⽣産的な時間の確保
- トイル / 運⽤⼯数の削減
- Eightアプリケーションを知る
- 多くのメンバーが元々インフラメイン
- 逆Embed (短期留学) も検討中
- インフラ領域の委譲
- System Adminとしての権限を必要としない範囲
EightのSREは何を⽬指すのか
Slide 22
Slide 22 text
22
© Sansan, Inc.
- 成熟度モデル
- 組織の成⻑プロセスをダイン快適に評価・改善する枠組み
- Eight SREのMaturity Model例
- パフォーマンス改善
- エラー率削減
- インシデント対応・ポストモーテム
- セキュリティベースラインの確保
> これらを4段階で評価するためにモデルを定義中
Maturity Modelとは？
Slide 23
Slide 23 text
⼀歩ずつ着実にSREとしての
成⻑を⽬指します
Slide 24
Slide 24 text
Eight SREの構成要素
Slide 25
Slide 25 text
25
© Sansan, Inc.
SREのプラクティスを
最⼤限実践する
インフラエンジニアとしての
強みを持つ
システム管理者としての
責任を果たす
Eight事業・プロダクトの
成⻑に100%コミットする
SRE Eight Engineer
Infra Engineer
System Administrator
EightのSRE
Slide 26
Slide 26 text
26
© Sansan, Inc.
We are hiring!
⼀緒にEightの価値を⾼められる⽅を募集しています！
Slide 27
Slide 27 text
No content