Datadog のトライアルを成功に導く技術 / Techniques for a successful Datadog trial

Transcript

1. Datadog のトライアルを 成功に導く技術 ヌーラボにおけるオブザーバビリティ改善の道のり Japan Datadog User Group Meetup#9@福岡 Yuki Yoshiiwa
2. 📛 吉岩祐貴 (@mananyuki) 💻 Platform Engineer @ Nulab Inc. 📚 趣味・関心 • SRE / Platform Engineering • Kubernetes • いぬ🐕 / さかな🐟 • アイドル
3. 3 ヌーラボについて • 創業21周年 • NULL + LAB = NULAB ◦ 無の状態から有を創り出す「研究所」のような会社 • 福岡を拠点に世界へ広がるヌーラボオフィス ◦ リモートワーク / コアレスフレックス / 多様な労働スタイルに理解のある職場 ◦ General Meeting (社員総会) で集結することも
5. 5 本⽇のテーマ 本セッションで特に伝えたいこと: • Datadog チャンピオン (推進者) となることの重要性 • 透明性が高く、客観的な評価に基づく意思決定プロセスの勘所 📝 アジェンダ: 1. Datadog 選定の背景: ヌーラボの課題とツール選定プロセス 2. トライアルを成功に導いた「3つの戦略的準備」 3. まとめ
6. Datadog 選定の背景: ヌーラボの課題とツール選定プロセス
7. Datadog 導⼊前の課題
8. 8 監視ツール乱⽴による「⾒えない壁」 🧩 監視ツールの断片化 • 主要ツール: Prometheus、Grafana、CloudWatch、Mackerel などが併存 • 結果: システム全体の健全性を一元的に把握できず、情報がサイロ化 • 影響: インフラとアプリケーション間のデータ相関分析が困難 😥 SREs / 開発者の負担増 • 運用負荷: 複数ツールの管理 (アップデート、設定など) で SREs の負荷増 • 認知負荷: 新規メンバーの学習コスト増。複数ツールの UI / クエリ習得 • 潜在的コスト: オブザーバビリティ基盤の自社構築・維持には SREs 3-5名相 当の工数が必要と試算
9. 9 MTTR 悪化とその他の問題 ⏱ インシデント解決の遅延 (MTTR 悪化) • 初動の遅れ: 新規オンコール担当者などが、どのツールを見るべきか迷う • 調査の非効率: オブザーバビリティが不十分で、複数ツール間でリクエスト ID を突き合わせ調査 🤔 その他、見過ごせない課題 • 属人化の進行: 特定個人に依存した専門知識のブラックボックス化 • 限定的な可視性: システムパフォーマンスの可視性が不十分で、プロアク ティブな問題特定やリソース最適化が困難 • DevOps の阻害: 開発と運用の効果的な連携を妨げ、共通理解の醸成が困難
10. ツール選定プロセスと ADR の活⽤
11. 11 Architecture Decision Records (ADR) とは？ 📜 Architecture Decision Records (ADR) とは • 重要なアーキテクチャ上の決定を記録するための軽量なドキュメント • 「何を」「なぜ」「どのように」決定したのかを簡潔に記述 👍 ヌーラボがADRに期待するメリット • 関係者の合意形成の促進 • 後日の決定理由の明確化・参照の容易性 • 知識の共有とオンボーディングの効率化 • 意思決定プロセスの透明性向上
12. 12 なぜ意思決定プロセスに課題があったのか？ 🤔 過去の反省点: • 2022年に全社的に Architecture Decision Records (ADR) を導入するも、 SRE チーム内での活用が不十分 • 結果: 意思決定の経緯が不明瞭になるケースが発生 💡 今回の選定での改善: • オブザーバビリティツール選定では ADR を積極活用し、決定プロセスを記録 ・共有
13. 13 評価プロセス①: トライアル対象ツールの選定 ⚖ 客観的評価軸に基づく網羅的な比較検討 • 機能、コスト、操作性、将来性、学習リソース、コミュニティなどを多角的 に評価 • 例: Observability (Metrics, Logs, APM, Frontend), Learning resources, Cost control, Popularity, Business Continuity 🎯 候補ツールの絞り込みと ADR による記録 • 比較の結果、Datadog を含む複数の主要候補ツールをトライアル対象として 決定 • この意思決定を ADR として記録し、透明性と再現性を確保
14. 14 評価プロセス②: 多⾓的なフィードバック収集 🧪 実践的なシナリオに基づく詳細トライアル • 選定された候補ツールを導入 • 実際の業務課題（例: 特定の障害調査、ダッシュボード作成）を解決できる か検証 📊 定量的・定性的評価の収集と分析 • Datadog (社内評価: 4.46/5) / 候補B (社内評価: 3.88/5) のように評価スコ アを収集 • SREs、開発者など現場エンジニアによる定性評価 (操作感、学習コスト、課 題解決能力、サポート体制など) を重視
15. 15 評価プロセス③: 導⼊ツールの最終決定と組織的合意 ⚖ 総合的な評価と最終決定 • トライアル結果、アンケート、コスト、将来性、Datadog の主な強み (直感 的な UI、Go 言語プロファイラ、包括的機能、社内評価の高さなど)、候補 B の主な強み (手厚いサポート体制など) を総合的に比較検討。 • 最終決定会議での議論を経て、Datadog を選定。 ADRによる最終決定の記録 • この最終決定を ADR として記録し、全社に公開
16. 16 判断理由①: 優れた操作性と開発⽀援機能 🌟 直感的な UI と柔軟なダッシュボード • 学習コスト低減と迅速な情報把握・分析を支援 💡 Go 言語を含む継続的プロファイリング機能 • ボトルネック特定と開発サイクル改善に寄与
17. 17 判断理由②: 包括的な機能セットと将来性 🛠 統合監視プラットフォーム • Metrics、Logs、APM などを単一基盤で提供しツール分断を解消 📈 R&Dへの継続的投資と事業計画との整合性 • 技術的進化への期待とヌーラボ戦略との適合性
18. 18 判断理由③: トライアルによる有効性の実証と組織的合意 🤝 社内トライアルでの高い評価 • 平均4.46/5点という高評価を獲得 📊 課題解決への貢献 • 「ボトルネック特定」「調査効率向上」など業務改善効果を実感 🗣 全社的な意思決定 • 最終決定会議での広範な支持と合意
19. トライアルを成功に導いた 「3つの戦略的準備」
20. 20 なぜ「準備」がトライアルの成否を分けるのか？ 😥 過去の反省: • 透明性の低い意思決定プロセスは、現場に「押し付け感」を生み、ツールの 定着を阻害 💡 今回の学び: • 技術検証だけでは不十分。ツール選定・導入を成功させるには、組織的な 「仕込み」が不可欠 本セクションでは、ヌーラボが Datadog トライアルを成功に導いた、具体的な 「3つの戦略的準備」を紹介します。
21. 準備①: 「なぜやるのか？」 ⽬的と評価軸の徹底的な明確化
22. 22 現状課題の共通認識を醸成 🗣 全社アナウンスによる目的共有 • トライアル開始前に、監視体制の現状課題（運用負荷、認知負荷、MTTR 悪 化など）と、ツール統合によって「何を目指すのか」を共有 📢 現実的な期待値の設定 • 「ツール移行で全てが解決するわけではないが、本質的な活動に取り組める 状況を作る」
23. 23 トライアルのゴールと評価基準を定義 🎯 明確な評価軸の設定 • 「何を触っていいかわからない」状態を回避 ◦ オブザーバビリティの民主化 ◦ MTTR の短縮 ◦ 効果的な DevOps 文化の醸成 ◦ 開発生産性の向上 📝 フィードバック収集の仕組み • 設定した評価軸に基づき、具体的なアンケート項目を作成し、トライアル参 加者からフィードバックを収集
24. 準備②: 「誰とやるのか？」 推進体制と情報透明性の確保
25. 25 Datadog チャンピオンの役割 🏆 主体的な情報提供と推進 • 自身が推進者となり、トライアルに必要な情報（ツールの概要、効果的な使 い方、外部セッション資料など）を積極的に提供 📚 事前の徹底的なドキュメント読解 • 事前に Datadog ドキュメントを徹底的に読み込み、理解を深めることで、ト ライアル中の問い合わせに迅速かつ的確に対応できる体制を構築
26. 26 関係者の早期巻き込みと ADR 活⽤ 👥 多様な視点での評価 • SRE チームだけでなく、開発チームのメンバーにも初期段階からトライアル へ参加を呼びかけ、多角的なフィードバックを収集 🔗 透明性の高い意思決定プロセス • ADR を活用し、トライアル対象の絞り込みから最終決定までのプロセスと理 由を記録・公開し、組織全体の納得感を醸成
27. 準備③: 「どう試すか？」 効果的なトライアル体験の設計と⽀援
28. 28 スモールスタートと学習⽀援 🚀 スモールスタートと対象範囲の明確化 • 限定的な範囲（代表的なサービスや機能、開発環境など）からトライアルを 開始 • 検証したい内容、対象範囲を明確化し、評価のブレを防止 󰞹 操作理解を促すハンズオンとベンダーセッション • 主要機能や評価ポイントを理解するためのハンズオンを実施 (「ここを触れ ば OK」というガイド) • Datadog ベンダーによる紹介セッションを企画し、初期理解を促進
29. 29 迅速な Q&A と情報共有 💬 専用 Q&A チャンネルの設置 • Slack チャンネルを設置し、チャンピオンが積極的に回答 🗣 情報共有会による知識の底上げ • 進捗、課題、Tips などを共有する情報共有会で、参加者全体の知識レベルを 向上
30. トライアルから得られた主要な学び
31. 31 学び①: ツール選定は技術と組織の両輪で 🤝 高機能ツールも組織適合が不可欠 • 導入プロセスや組織文化に適合しなければ真価を発揮できない 🗣 広範囲利用ツールは納得感が鍵 • 特に広範囲で利用されるツールの場合、多様な関係者の納得感ある意思決定 プロセスが不可欠
32. 32 学び②: 成功の鍵となった「3つの戦略的準備」 🔑 1. 目的設定の明確化 • 「何のために導入するのか」を明確にしたことで、評価軸がブレず、トライ アルの方向性が定まった。 🔑 2. 関係者の早期巻き込み • 透明性の高いプロセスで関係部署と連携した結果、導入後のスムーズな協力 体制、さらには新たな Datadog チャンピオンの誕生に繋がった。 🔑 3. 段階的な導入と検証 • スモールスタートで得た小さな成功体験が、全社展開への自信と組織全体の 納得感を醸成した。
33. まとめ
34. 34 成功への提⾔: Whyを問い、仲間と⼩さく始める 🔥 情熱を力に、まず「Why」を問う • なぜ Datadog なのか？　導入目的を明確にし、組織の共通言語に • 推進者自身が熱意を持ち、目的と期待効果を粘り強く伝える 󰔡 仲間を増やし、透明性を武器にする • 関係各部門を早期から巻き込み、共にトライアルを推進 • ADR などを活用し、選定プロセスや評価基準をオープンに 🌱 小さく始め、学びを力に変える • 限定的な範囲からスタートし、具体的な評価軸で効果を検証 • 学びを活かし、適用範囲やルールを段階的に拡大・改善
35. 35 今後の展望と謝辞 🔭 ヌーラボにおける今後のオブザーバビリティ向上施策: • IDP (Internal Developer Platform) との連携強化 • SLO 運用の本格化 • FinOps へのオブザーバビリティデータ活用 • → 目指す姿: データドリブンな開発文化の醸成 ご清聴ありがとうございました。