CI/CDを「オブザーバビリティの源泉」へ昇華させる：Datadog連携の深淵
多くのエンジニアにとって、CI/CDパイプラインは単なる「自動化された作業場」に過ぎない。しかし、真のアーキテクトにとって、そこはシステムの状態を決定づける「最初のイベントソース」である。
GitHub Actionsの実行結果をただダッシュボードに並べるだけの「お絵描き」で満足してはならない。本稿では、CI/CDをDatadogのオブザーバビリティ・グラフに完全に統合し、デプロイとインフラの因果関係をミリ秒単位で可視化するための「極限のハック」を伝授する。
—
1. 統計の闇を切り裂く：Datadog CI Visibilityの真価
標準的なDatadog Actionsを使えば、実行時間や成功率は取れる。だが、それだけでは「なぜ遅いのか」「なぜ失敗したのか」の文脈（コンテキスト）が欠落する。
我々が目指すべきは、「ビルド時間とアプリケーションのP99レイテンシの相関」を一枚のボードで射抜くことだ。
推奨構成：`datadog-ci` CLIの深層活用
公式のGitHub Actionをそのまま使うのではなく、`datadog-ci` CLIをパイプラインのライフサイクルに埋め込み、ペイロードをカスタマイズして送信する。
.github/workflows/deploy.yml
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Setup Datadog CI
run: npm install -g @datadog/datadog-ci
- name: Instrumented Build
run: |
# 実行時間をカスタムメトリクスとしてパイプライン自体に埋め込む
# –dd-api-keyはシークレット管理
datadog-ci synthetics run-tests \
–public-id “xxx-xxx-xxx” \
–tags “env:production,team:core” \
–json-report result.json
極意: `datadog-ci` を叩く際、必ず `CI_JOB_URL` や `COMMIT_SHA` だけでなく、「ビルド時のランナーの負荷状態（CPU/Memory）」もメタデータとして付与せよ。ボトルネックがコードなのか、CI環境のスペック不足なのかを一瞬で切り分けるためだ。
—
2. デプロイイベントの「完全同期」：Event Correlationの極致
障害発生時、「直前に何を変えたか」という情報（デプロイマーカー）がない監視など、羅針盤を持たずに荒海へ出るようなものだ。DatadogのEvents APIを叩き、GitHub Actionsの終了直後に正確なイベントを打つ。
独自自動化スクリプト：`send-deploy-event.sh`
GitHubの環境変数を利用して、Datadogに詳細なデプロイコンテキストを送信する。
!/bin/bash
Datadogにデプロイイベントを送信するスクリプト
障害切り分けにおいて、この「マーカー」が全ての命運を握る
curl -X POST “https://api.datadoghq.com/api/v1/events” \
-H “DD-API-KEY: ${DD_API_KEY}” \
-H “Content-Type: application/json” \
-d @- <
—
3. インフラとCIの因果関係：パフォーマンスのボトルネックハック
CI/CDパイプラインを「ブラックボックス」にするな。Datadogの「CI Visibility」機能を使い、ビルド内の各ステップをトレースするのだ。
- ハック1: メモリ消費の可視化
Dockerビルドがメモリリークしている場合、CIのランナーそのものを監視するエージェントをデプロイせよ。GitHub Actions RunnerのホストメトリクスをDatadogで監視すれば、ビルドプロセスがOSのOOM Killerに殺される予兆を検知できる。
- ハック2: キャッシュヒット率のメトリクス化
ビルド時間の9割はパッケージのインストールにある。キャッシュヒット率を独自メトリクスとして`dogstatsd`経由で送信せよ。
# Node.jsであれば、node_modulesのサイズ変化を監視する
echo “ci.build.cache_hit_rate:${HIT_RATE}|g” | nc -u -w0 127.0.0.1 8125
—
4. アーキテクトの結論：監視の「自動化」から「自律化」へ
単にツールを繋ぐだけで満足してはならない。最終的には、「デプロイ直後のエラーレート上昇を検知し、CI/CDパイプラインにロールバックのシグナルを自動で送る」というループを完成させるべきだ。
1. Observability: Datadogでデプロイ後の異常（4xx/5xxスパイク）を検知。
2. Analysis: Watchdog機能で関連する変更箇所を特定。
3. Action: GitHub ActionsのAPIを叩き、強制的に前バージョンへのデプロイを再実行する。
これこそが、SREが目指すべき「オペレーションの自動化」の終着点である。
CI/CDはシステムの一部だ。その実行結果を、インフラの健全性と同じ熱量で監視せよ。それが、システムを支配し、障害を無力化する唯一の道である。健闘を祈る。