こんにちは！プロダクトの安定稼働を支えるインフラやアプリの番人として、日夜奮闘しているエンジニアの皆さん、お疲れ様です。
深夜3時に「PagerDutyが鳴り響く」、あるいは「Slackのアラートチャンネルが真っ赤に染まる」……。あの寝ぼけ眼でPCを開き、VPNに接続し、K8sのログを追って、最終的に `kubectl rollout restart deployment` を叩くだけの作業。
「これ、俺がやる必要あるか？」と天井を見上げた経験、ありませんか？
今回は、そんな「人間が夜中にやらなくてもいい単純作業」を完全自動化し、あなたの睡眠時間を守るための強力な武器「Datadog Workflow Automation」について、基礎から実践まで徹底的に解説します。
これをマスターすれば、アラート検知から復旧までのリードタイム（MTTR）が劇的に短縮され、毎日のオンコール対応が驚くほど楽になりますよ。一緒に見ていきましょう！
—
1. Datadog Workflow Automationとは何か？（ツールの本質）
まず、Datadog Workflow Automationの役割を定義しておきましょう。
従来のDatadogは、「異常を検知して通知する（知る）」ことにかけては世界最高峰でした。しかし、検知した後の「対応する（直す）」アクションは、人間の手（あるいは個別のWebhooksや複雑なスクリプト）に委ねられていました。
Workflow Automationは、この「検知（Monitor）」と「修復（Action）」のギャップを埋める、ノーコード・ローコードのオーケストレーション基盤です。
- 何ができるのか？
- Datadogのアラート発火をトリガーにする。
- Slackで担当者に「自動修復を実行しますか？」とボタン付きで尋ねる（承認フロー）。
- AWS LambdaやKubernetes APIを叩いて、ポッドの再起動やリソースのスケールを行う。
- 修復結果をSlackやJiraに自動通知する。
これらを視覚的なフローチャートを描くように構築できるのが、この機能の真髄です。
—
2. 基礎セットアップ：まずはエージェントと権限の準備から
Workflow Automationを動かすためには、Datadogからあなたのインフラストラクチャー（AWSやKubernetes）へ安全にアクセスする権限（コネクション）が必要です。
今回は、最も需要の高い「Kubernetesポッドの再起動」を自動化するシナリオを想定して、基礎セットアップを進めましょう。
Step 1: Datadog AgentとCluster Agentの確認
Kubernetes環境でアクションを実行するためには、Datadog Cluster Agentがデプロイされており、かつセキュアな通信が確立されている必要があります。Helmチャートでインストールする際、以下の設定が有効になっていることを確認してください。
values.yaml の抜粋例
clusterAgent:
enabled: true
# Action Runner機能を有効化
actions:
enabled: true
Step 2: Datadog上で「Connection」を確立する
Workflow Automationから外部クラウドやK8sクラスターを操作するためには、認証情報をDatadog上に安全に保持させる必要があります。
1. Datadogの画面から Workflows > Connections に移動。
2. 対象のインフラストラクチャー（例: AWSやKubernetes）を選択。
3. 必要なIAMロールやサービスアカウントの権限をバインドします。
これで、Datadogからインフラを安全に触るための「手足」が準備できました。
—
3. HelloWorld的ワークフロー：高負荷ポッドの自動再起動を作ってみる
それでは、記念すべき最初のワークフローを作ってみましょう。
今回の「HelloWorld」は、「特定のKubernetesポッドでメモリ使用率がスパイクした際、安全に再起動（Rollout Restart）するワークフロー」です。
1. トリガーの設定（Trigger）
まずは、何がきっかけでこのワークフローが動き出すかを定義します。
- トリガーの種類: `Datadog Monitor`
- 対象モニター: 「Kubernetes Pod Memory High（メモリ使用率 85%超）」のモニターを選択。
これで、アラートが「Alert」状態になった瞬間、このワークフローが自動起動します。
2. アクションステップの追加（Action）
次に、アラートを検知したあとに実行するアクションを追加します。Workflowのビルダー画面で「＋」ボタンを押し、Kubernetesインテグレーションを選択します。
- アクション: `Restart Kubernetes Deployment` （または Rollout Restart）
- パラメータ設定:
- Cluster Name: アラートが発生したクラスター名（変数が使えます：`{{ Trigger.event.tags.cluster }}` など）
- Namespace: `{{ Trigger.event.tags.namespace }}`
- Deployment Name: `{{ Trigger.event.tags.deployment }}`
> 💡 先輩エンジニアのワンポイントアドバイス
> いきなり完全自動（Full Automation）にするのは少し勇気がいりますよね。本番環境で試す際は、アクションの直前に「Slack Approval（承認ステップ）」を挟むのが定石です。
> 「ポッドを再起動しますか？ [はい競技 / いいえ]」というボタンをSlackに飛ばし、あなたが「はい」を押した時だけ次のステップに進むように設計できます。まずはここから始めるのが精神衛生上も非常におすすめです。
3. 仕上げの通知ステップ（Notification）
修復アクションが成功した（あるいは失敗した）ら、チームに結果を報告させましょう。
- アクション: `Send a Slack Message`
- メッセージ内容:
🚨 障害自動修復を実行しました
- モニター: {{ Trigger.monitor.name }}
- 対象クラスター: {{ Trigger.event.tags.cluster }}
- 実行結果: ポッドのロールアウト再起動が正常に完了しました。様子を観測します。
これで、ワークフローの構築は完了です！右上の「Publish」を押して有効化しましょう。
—
4. 現場で使える！深夜のオンコールを激減させる具体的なユースケース
HelloWorldが動いたら、次は現場で即効性のある具体的なユースケースに挑戦してみましょう。これらを実装することで、あなたのチームのオペレーションコストは劇的に下がります。
ユースケース A: コネクションプールの枯渇に対する「段階的リカバリ」
データベースへのコネクションリーク等で、APIサーバーが「502 Bad Gateway」を返し始めたときの手順です。
1. トリガー: HTTPチェックモニターが「502エラー検知」
2. アクション1: 障害の一次切り分けとして、直近のエラーログをDatadog Logsから自動抽出。
3. アクション2: そのログのサマリーを、専用のSlackインシデントチャンネルに自動投稿。
4. アクション3: 対象のAPIサーバー群をローリングアップデートで順次再起動し、コネクションを強制解放。
5. アクション4: ヘルスチェックが「正常（200 OK）」に戻ったことを確認して、インシデントを自動クローズ（Resolve）。
人間は「あ、治ってるな」とSlackの通知を目で追うだけです。
ユースケース B: 外部APIのタイムアウトに対する「自動スケールアウト」
サードパーティの決済APIなどの遅延により、自社のバックグラウンドワーカー（Worker）がつまり始めたときの手順です。
1. トリガー: キューの滞留数（Queue Length）が閾値を超過。
2. アクション: KubernetesのHorizontal Pod Autoscaler (HPA) の上限を一時的に引き上げる、あるいは対象のDeploymentのレプリカ数（replicas）を強制的に倍増させる。
3. 効果: 人間が起きてPCを開く前に、システムが自発的にキャパシティを拡張してスループットを維持します。
—
5. まとめ：オブザーバビリティの次のフェーズへ
今回は、Datadog Workflow Automationの基本概念から、Kubernetesポッドの自動再起動を行うワークフローの構築、そして現場で使える実践的なユースケースまでを解説しました。
オブザーバビリティ（可観測性）の本来の目的は、単に「きれいなダッシュボードを作ること」でも「素早くエラーに気づくこと」でもありません。「気づいたあとのアクションを最適化し、システムと人間のストレスを最小化すること」です。
面倒な定型作業や、深夜の単純な再起動対応はすべてWorkflow Automationに任せてしまいましょう。そして、あなたにしかできない、より創造的でアーキテクチャの本質的な改善に時間を使っていきましょう。
明日からの運用ライフが、もっと快適なものになることを応援しています！