ツールを超えた「共通言語」へ 開発とSREがDatadogを囲んで信頼を育てる 継続的かつ地道な実践 

自己紹介 山下 雅人 クラウド経費・クラウド債務支払 SRE チーム バックエンドエンジニアとSREの 経験を活かして活動中 Kaigi on Rails Organizer 

今日お伝えしたいこと 「完璧なダッシュボード」より、まず「全員で見る場」を作ろう ツールは会話のきっかけ。グラフの向こうを言語化して共有する 

オンプレミスからAWSへの移行 マネーフォワードの各プロダクトは オンプレミス環境で稼働していた 会社の方針により各プロダクトが AWS環境へ順次移行となった https://xtech.nikkei.com/atcl/nxt/column/18/000 01/11142/ 

Datadogダッシュボードの再編 オンプレ時代からダッシュボードが運用されていたが、 構成はオンプレミス前提となっていた AWS移行後はEKS・RDS・S3など見るべき対象が変わるので そのままでは何が起きているか掴めない クラウド経費・クラウド債務支払それぞれに対して再編に着手 

Datadogのメトリクス可視化が手動から自動に 「見ようとしたもの」から「見えるもの」へ オンプレ時代：設定した箇所しか見えない（手動で仕込む） AWS時代：連携するだけで詳細まで可視化（自動で取れる） 手動から自動に変わったメリット 高品質・高解像度の情報が、連携するだけで自動的にアップ される 個別に仕込んでいた詳細が即座に可視化されるようになった 

各メトリクスをDatadogで可視化 各マネージドサービスのメトリクスをDatadogで一元管理 

簡単に追加できる点は良かったが... SREだけでは全容の把握が困難になってきた 

徐々に長くなるダッシュボード サービスの成長と共に見るべき メトリクスが増加 インシデント対応で必要な メトリクスの追加も増える 結果として、ダッシュボードへの 「継ぎ足し」が続く SREだけで全容の把握は困難 ⬇︎ Still continues... 

そこで効果を発揮した取り組みが 「インフラヘルスチェック会」 

インフラヘルスチェック会とは オンプレミス時代からの習慣 週1回、開発チームとSREでミーティングを実施 目的 インフラの現状の認識合わせとオーナーシップ醸成 開発者がサーバーを「自分たちのもの」として意識する 

インフラヘルスチェック会がもたらしたもの Datadogの各メトリクスと 開発側コンテキストの 照らし合わせ 開発とSRE双方で 過去や未来の変更情報共有 再編による「情報量」× 既存の「会話」→「情報の交差点」 

「情報の交差点」から生まれるもの SREの視点（メトリクス）と開発の視点（コード/仕様）が 頻繁に行き交う グラフと原因を結びつける翻訳が繰り返される 継続的な場の開催と会話により、グラフを見るだけで全員が 同じ理解になる Datadogが開発とSREの「共通言語」として機能するようになる 

ヘルスチェック会で培った「共通言語」は 週1回の会議を超えて広がり、 有事や改善の場でも効果を発揮する 

活用事例1：インシデント対応（有事） 障害発生時の動き 開発者やSREが同じ画面を見て 障害の鎮火に向けて行動 迷わない初動 「どこを見ればいいか」が明確 「いつものグラフね」という 共通認識で説明のコストがゼロ 

活用事例2：開発のパフォーマンス評価（改善） リリース前の見積もりとリリース後のモニタリング 新機能リリース前に、開発とSREでメモリ増加量や 負荷傾向を把握 リリース後のモニタリングでのフィードバック 開発コードの改善における意思決定 複数処理を「まとめるか・分けるか」の判断に、Datadogの メトリクスを活用 「過去のリソース使用傾向」と「改善後の変化」を比較し 根拠を持って意思決定した 

Datadogを活用した改善はまだまだ継続中 ダッシュボード 分離やシンプル化も進めつつ、 今の優先順位は開発側との 認識合わせ 使い方の共有 Slack上で各メンバーが 「こんな使い方・見方がある」 といった共有を実施 

結論：Datadogという共通言語 同じ画面を見て、同じ認識を持つ 「今何が起きているか」 「次に何をすべきか」を 開発とSREの共通言語で揃える 今日持ち帰ってほしいこと i. 「完璧なダッシュボード」より、まずは「全員で見る場」を 作ろう ii. ツールは「会話のきっかけ」 。グラフの向こうにある意図や 状況を言語化して共有する 

ありがとうございました