Software Delivery Observability ~ CI・CD , DORA metrics も Datadog で可視化しよう ~ / datadog-ci-cd-observability

Transcript

1. Software Delivery Observability CI/CD , DORA metrics も Datadog で可視化しよう 2025/05/16 SRE Tech Talk - Annosuke Yokoo (@866mfs）
2. 2 自己紹介 Annosuke Yokoo（横尾杏之介） Datadog - Sales Engineer X : @866mfs Awards : Google Cloud Partner Top Engineer 2025 Fellow Community : Jagu'e'r オブザーバビリティ分科会 Oraganizer Interest : Sauna 🧖 / 🚢 / Observability 🔭 X で Datadog の最新情報を（気まぐれで）呟く Bot やってます Scan Me 👇
3. ❏ 内容 ◦ CI/CD オブザーバビリティ ◦ DORA Metrics を CI/CD の改善に生かそう ❏ ゴール ◦ CI/CD にもオブザーバビリティの考えを適用する ◦ Datadog にも CI/CD を中心とした Software Delivery におけるオブザー バビリティを高めるプロダクトがある 3 今日話すこと
4. 4 “オブザーバビリティ”は運用フェーズだけではない tag-observability /whitepaper.md https://github.com/cncf/tag-observability/blob/main/whitepaper.md
5. 5 “オブザーバビリティ”は運用フェーズだけではない tag-observability /whitepaper.md https://github.com/cncf/tag-observability/blob/main/whitepaper.md Observability（可観測性）は、システム開発ライフサイクルのあらゆる フェーズで活用することができます。 新機能のテスト中、プロダクション環境のレジリエンスの監視、顧客がどのように製品 を利用しているかのインサイト取得、あるいは製品ロードマップに関するデータ主導の 意思決定を行う際にも利用可能です。 いずれかの目的が明確になれば、次に考えるべきは 「出力」、つまり私たちが 「シグ ナル」 と呼んでいるものになります。
6. 6 Development QA Staging Production Shifting left より開発初期段階の環境における テストとパイプラインにも可視性 （可観測性）をもたらす これまでは Prod だけで オブザーバビリティを考える オブザーバビリティのシフトレフト
7. 7 Development QA Staging Production Shifting left より開発初期段階の環境における テストとパイプラインにも可視性 をもたらす これまでは Prod だけで オブザーバビリティを考える オブザーバビリティのシフトレフト “運用”だけでなく”開発”におけるオブザーバビリ ティのシフトレフトを考えることで、より生産的か つ安全にソフトウェアをデリバリーできる
8. 8 継続的な改善には、CI/CD オブザーバビリティが重要 https://speakerdeck.com/sansantech/20250514
9. • プロアクティブなエラー検知 ◦ テレメトリーシグナルを活用することで、CI/CD パイプライン内のパフォーマンス劣化 や不安定な挙動をデプロイ前に検知・対処可能 • 高速なフィードバックループ ◦ パイプライン全体のトレース性と実行状況の分析により、ビルド時間のボトルネック特定 やテストの信頼性評価が可能 • ソフトウェアデリバリーの信頼性可視化 ◦ ビルド・テスト段階での健全性の把握による、リリース判断の精度向上 • トレーサビリティとインシデントの根本原因分析 ◦ コミット単位でのジョブ失敗やパフォーマンス変化の可視化により、根本原因を迅速に把 握. インシデント対応の高速化とチームの説明責任の明確化 9 CI/CD オブザーバビリティのもたらす効果
10. ここから Datadog の話になります 10
11. Datadog の CI, CD Visibility 知っている方？󰢧 11
12. Secure Analyze Cloud Service Management Cloud Service Management • Incident Management • Case Management • Service Catalog • Resource Catalog • Workflow Automation • App Builder Monitor & Operate Optimize Software Delivery • RUM • RUM Heatmap/ Clickmap/ Scrollmap • Mobile App Testing • Session Replay • Cloud Security Mgmt • Application Security Mgmt • Cloud SIEM • Software Composition Analysis • Sensitive Data Scanner • Infra Monitoring • Network Monitoring • APM • Synthetics • Log Mgmt • Universal Service Monitoring • Observability Pipelines • LLM Observability • Continuous Profiler • Database Monitoring • Data Streams Monitoring • Cloud Cost Mgmt • Data Jobs Monitoring • CI Visibility • Intelligent Test Runner • Continuous Testing • Test Visibility Business Run Business Dev Monitor Operate Optimize Code Ship Test Understand Users Support Users Understand Business Run Secure 12 Datadog のオブザーバビリティ全体像
13. 13 Datadog CI/CD Observability 全体像
14. 14 Datadog CI/CD Observability 全体像
15. 15 ジョブの失敗やリグレッ ションテストなどの難しい デバッグ 複雑なパイプラインによ るリリース速度/頻度の 低下 時間と共に増加する CI/CD コスト CI/CD の実行待ちによる 生産性の無い時間 CI/CD オブザーバビリティが全く無いと...
16. 16 CI における課題 変更差分が大きくなり、複数の Job が走る Pipeline を考える • Build 実行時間が長くなり、キャッシュでも対応できなくなってくる • 各 Step の所要時間を把握しづらい（ or 出来ない） ◦ クリティカルパスの把握が難しい • 複雑な Pipeline は Job 失敗時の根本原因がわかりづらくなる → 生産性の低下 → CI の待ち時間が絶妙に何も生み出せない時間となる...（経験上） ◦ コーヒーブレイク / 雑談 / 休憩
17. 17 CI ツールにもモニタリング View はあるけど... • 特にこだわりなく（選択肢が無いから）使っている人 も多いのでは...?
18. 18 Continuous Integration (CI) Visibility • 内容 GA Continuous Integration Visibility https://docs.datadoghq.com/continuous_integration/
19. 19 Continuous Integration (CI) Visibility 各 Step の Trace を Flame Graph で表示 • Job は並列実行されることが多いため、依存関係が明確 化 クリティカルパス（Critical Path）の特定 • 依存関係により順番に実行されるステップ • 最も長くかかる経路 Exclusive Time（排他時間） • パイプラインの完了をそのステップだけがブロックして いる時間 CI の実行時間を短縮するにはクリティカルパス上の Job の実行 時間を短縮する必要がある → ビルドキャッシュ使用 → ビルドアーティファクト / テストの再使用 → Job の並列化 / 順序変更 GA https://docs.datadoghq.com/continuous_integration/guides/identify_highest_impact_jobs_with_critical_path/ クリティカル パスを特定 Log との相関 Exclusive Time
20. 20 CD における課題 デプロイ時に気にすべき指標は、たくさんあるが... デプロイ（CD）に関するメトリクスは意外と追いづらい😓 • なぜデプロイが失敗したのか？ • サービスのデプロイに平均してどれくらい時間がかかっているのか？ • すべての環境で現在デプロイされているサービスバージョンは何か？ • この Deployment でデプロイされている変更は何か？ • 先週、チームでどれくらいのロールバックが発生したか？ • なぜデプロイの完了にそんなに時間がかかるのか？ • 通常のデプロイ実行時間と外れ値は何か？ • CD パイプラインをどうすれば高速化できるか？
21. 21 Continuous Delivery (CD) Visibility Private Beta Continuous Delivery Visibility https://docs.datadoghq.com/continuous_delivery/
22. 22 Continuous Delivery (CD) Visibility Private Beta Continuous Delivery Visibility https://docs.datadoghq.com/continuous_delivery/ Demo - 実際に見てみましょう🏃
23. 23 CI/CD オブザーバビリティのその先 • CI, CD Visibility により、これまで見えにくかった部分を（簡単に）改善できる ◦ 単発の改善ではなく、フィードバックループを築き、継続的改善につなげること • CI/CD の継続的改善により、開発生産性を向上させることができる ↔ 開発生産性向上のために CI/CD の継続的改善がある • とはいえ、開発生産性 と一言で表すのは抽象度が高い • 改善と効果測定（計測）はセットでないといけない → なので、DORA Metrics もセットで考えましょう
24. 24 そもそも DORA って ？ • Google にある１部門　(2018年に買収) ◦ DevOps Research and Assessment • DevOps の業界動向を調査する組織 • DevOps 界隈のベンチマークレポート「State of DevOps Report(SODR)」が有名 ◦ DevOpsパフォーマンスモデルの提供 ◦ 開発生産性向上に関する多くの事例やレポート ◦ 開発生産性を計測するための4つの指標（Metrics）を提唱
25. 25 そもそも DORA って？ • Google にある１部門　(2018年に買収) ◦ DevOps Research and Assessment • DevOps の業界動向を調査する組織 • DevOps 界隈のベンチマークレポート「State of DevOps Report(SODR)」が有名 ◦ DevOpsパフォーマンスモデルの提供 ◦ 開発生産性向上に関する多くの事例やレポート ◦ 開発生産性を計測するための4つの指標（Metrics）を提唱 Four Keys 🔑 Four Keys だけでは少し古くなってきている... 開発生産性を計測する上では、+ 信頼性（SLA, SLI, SLO） も重要な指標
26. 26 ç Lead time for changes Deployment Frequency Time to restore service Change failure rate （Datadog では) Four Keys = DORA Metrics デプロイ頻度 変更リードタイム 変更失敗率 MTTR
27. 27 What Are DORA Metrics? https://www.datadoghq.com/knowledge-center/dora-metrics/
28. 28 DORA Metrics Preview DORA Metrics https://docs.datadoghq.com/dora_metrics/
29. 29 DORA Metrics Preview https://docs.datadoghq.com/dora_metrics/data_collected/#change-lead-time-metrics
30. • すでに周知の事実だが、DORA Metrics は”ハック”が出来てしまう ◦ 特に”デプロイ頻度”は細かくコミットを刻んでリリースすれば良いだけ • DORA Metrics の取得は手段であって、目的ではない ◦ DORA Metrics を取得して得られた、改善のきっかけ（洞察）にこそ価値がある • 改善のきっかけは、(CI/CD) オブザーバビリティを通して可視化できる ◦ デプロイ頻度が少ない → Rollback の影響が測れていないため変更が大きくなる ◦ 変更リードタイムが長い → CI/CD のクリティカルパスを特定できていない ◦ 変更失敗率が高い → CI のトレースが出来ていないので、根本原因が不明 ◦ MRRT が長い → そもそもオブザーバビリティ全体が足りていない可能性 30 DORA Metrics を CI/CD オブザーバビリティに活用する
31. ❏ 話した内容 ◦ CI/CD オブザーバビリティも（当たり前のように）考えようというお話し ◦ DORA Metrics は手段であり目的ではない ❏ ゴール ◦ CI/CD にもオブザーバビリティの考えを適用する → 継続的な改善には開発フェーズにもオブザーバビリティを使う （オブザーバビリティのシフトレフト） ◦ Datadog にも CI/CD を中心とした Software Delivery におけるオブザーバビリ ティを高めるプロダクトがある → CI, CD Visibility, DORA Metrics 31 まとめ
32. 32 宣伝 - Datadog Live Tokyo 👆Scan Now👆
33. Thank you!