Four KeysによるDataOps改善の第一歩

【Timee × NewsPicks共同開催】【オンライン開催】Four Keysで改善する開発生産性〜データ・モバイル・フロントエンド〜 - UB Tech Vol.12(https://uzabase-tech.connpass.com/event/294494/) 登壇資料です

Transcript

1. 2023/10/06　石井 正浩 Four KeysによるDataOps改善の第一歩 @marufeuille 【Timee × NewsPicks共同開催】【オンライン開催】 Four Keysで改善する開発生産性〜データ・モバイル・フロントエンド〜 - UB Tech Vol.12
2. DataOps改善の第一歩としての fourkeys導入から運用のお話
3. 石井 正浩 / @marufeuille 2022/8入社 データ基盤の開発・運用やってます 2月に第2子生まれました 🎂 コーヒー☕とコーラ🍹が好きです
4. 目次 • タイミーのデータ基盤と現在の活用状況 • タイミーの考えるDataOps • fourkeys計測の実装例 • 数ヶ月運用してみた考察と感想
5. 1 タイミーのデータ基盤と現 在の活用状況
8. 現在のデータ基盤概要 ・・・ 収集 活用 営業 施策 KPI 可視化 KPI 可視化 KPI 可視化 マーケ施 策 KPI 可視化 レコメン デーショ ン
9. 利用状況 参考数値 2022/8 … 社員数約350 2023/10/1 … 社員数約800 Looker上のダッシュボード数 BQ上のクエリの実行時間
10. 2 タイミーの考えるDataOps
11. そもそもDataOpsとは？ https://www.gartner.com/en/information-technology/glossary/dataops
12. そもそもDataOpsとは？ https://www.gartner.com/en/information-technology/glossary/dataops 一気通貫でデータを使った施策を高速で回せることの追求 (と解釈)
13. タイミーのDataOps ・・・ 収集 活用 営業 施策 KPI 可視化 KPI 可視化 KPI 可視化 マーケ施 策 KPI 可視化 レコメン デーショ ン 究極的にはこの全体を DataOpsの生産性として捉えたい
14. 例: 新しいデータを使って施策を回したい場合 ・・・ 収集 活用 営業 施策 KPI 可視化 KPI 可視化 KPI 可視化 マーケ施 策 KPI 可視化 レコメン デーショ ン 新しい データ 新しい 施策
15. 補足: データ基盤(ELT)の概念図 データ ソース Extract Transform Load データの抽出 データの 取り込み 変換処理 DataLake 生データ 置き場 Staging 形式の統一や 個人情報の処 理等 DataWare House Dimensional Modeling後の データ DataMart ※ Transform内の層の設計は弊社の場合です Lookerや各種 ダッシュボード 等それぞれに 特化したデー タ 新しい 施策
16. 施策実行時のチームと守備範囲 データ ソース Extract / Load DataLake Staging DataWareHouse DataMart DataEngineer (DRE) Analytics User ※ MLいれるとややこしくなりそうなので割愛します (実際に存在します) また、厳密ではないのでやることによって若干変わります 各システム保 持チーム Transform 新しい 施策
17. 施策実行時のチームと守備範囲 データ ソース Extract / Load DataLake Staging DataWareHouse DataMart DataEngineer (DRE) Analytics User ※ MLいれるとややこしくなりそうなので割愛します (実際に存在します) また、厳密ではないのでやることによって若干変わります 各システム保 持チーム Transform 体感的に課題が多そうな、まずは DREと一部 Analyticsの領域を計測していく
18. 3 fourkeys計測の実装例
19. データ基盤開発のプロセスイメージ ストーリーの 作成 外部依頼・ ニーズ リファイン メント 開発チーム アサイン PR デプロイ レビュー 価値の創出 開発が終わるまで 繰り返す fourkeysのリードタイムの範囲 チームのストーリーをこなすリードタイム
20. 情報の出どころ スループット 安定性 pr, commitなどの履歴情報 pr, commitなどの履歴情報 障害情報(ポストモーテム) スプリントのタスク、ストーリー
21. 利用したベースの実装紹介 ※ 上記画像は以下より引用 https://github.com/dora-team/fourkeys 収集用のDeploy(GoogleCloud)や可視化の Dashboard(Grafana)が付属したパッケージ 基本的にgithub eventをいい感じにしてくれるので、そこだけ でも使う価値ある(無料だし) ベースとして、DORAチームの実装を利用しています
22. 実際の構成 events_raw DORAの実装そのまま ポスト モーテム プロダクトバック ログ スプリントバック ログ 加工
23. ダッシュボード まずはDORA相当となるように実装
24. 4 数ヶ月運用してみた 考察と感想
25. 可視化してみたけれど...
26. 可視化してみたけれど... ふーん？って感じしませんか？
27. 可視化してみたけれど... https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance より引用 デプロイ頻度は1日2回以上だからまあいいかな リードタイム2.47日だと悪いから改善しないとなぁ・・・ とかいってもしゃーない感
28. 個別に問題を追い込む必要がある https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance より引用 ① あるリポジトリだけリードタイムが異様に遅い (5,6日)から改善しないと！ 確認すると、兼任者のみで構成されたチームが主に作業していたリポジトリであり、ヒアリング の結果、他の業務の手が空いたときのみの対応になっていることがわかった → 組織としての問題は把握できたが、即効性のある対応は難しそう ② そもそもどうやればリードタイム短くできるんだっけ？ 変更行数が短くても必ずすぐにマージされるとは 限らないが、長くて早くマージされるものは なかった → 基本的に抑える形で PR作っていこうという 　 コンセンサスを得られた 一定以上行数が多くてリードタイム 1日以内は存在して いなかった※
29. ダッシュボードの改善 ある程度の期間眺めていると見方が少しわかってくる 弊チームの場合 - リポジトリをまたいだ活動が多いので、デプロイ頻度は全体で見たほうが良さそう - リードタイムは個別
30. 一歩進めた可視化 ストーリーレベルのリードタイム 究極系に近づけるべく、まずはチームのストーリーレベルのリードタイムの可視化を開始
31. fourkeysを利用した施策 https://tech.timee.co.jp/entry/2023/09/07/202714
32. データ基盤における安定性のいま 当初想定 - 障害情報と紐づけて、問題の起こしたデプロイを特定し数値化すればなにか見えるはず 結果 - うまく紐づくようなものがほぼなかった
33. データ基盤における安定性の今後 データ ソース Extract Trans form Load ここまでが正しいこと を前提条件として 結果 テーブル 最終的なデータ品質 が悪化しないことを 担保 このあたりの変更によって
34. 最後に導入してみたまとめ ① fourkeys導入だけしてもそんなに意味はなさそう ② 必要な情報は得られつつあるので今後もやっていく ③ 生産性を向上させるための議論が深まるようになった
35. まだまだ道半ばなのでお力を貸してください！！！ https://hrmos.co/pages/timee/jobs/1682251404118319115 積極的に採用中です!!!