「深夜3時のアラート」を過去にする：Datadog Workflow Automationによる自動修復の実践論
エンジニアの皆さん、こんにちは。
「またか」という通知音と共に叩き起こされ、眠い目をこすりながらKubernetesのポッドを再起動し、ログを漁る……そんな作業は、もう「技術的負債」以外の何物でもありません。オブザーバビリティの真の目的は、単に「システムが壊れたこと」を通知することではなく、「システムが自動的に健全な状態を維持する」ことにあります。
本稿では、Datadog Workflow Automation（WFA）を使い、泥臭い障害対応から脱却し、本来やるべき「価値ある開発」に集中するための設計思想と実装の極意を伝授します。
—
1. Workflow Automationの設計思想： 「監視」から「制御」へ
WFAは、単なるスクリプト実行エンジンではありません。「コンテキスト（メトリクスやログ）に基づいた判断」と「実行（Action）」を統合するオーケストレーターです。
多くのチームが陥る罠は、アラートが飛ぶたびにSlackで人間が承認ボタンを押すフローです。これを極限まで省力化するには、「信頼できる状態（Known Good State）への復帰」を定型化し、コード（Workflow）として管理することが鍵となります。
現場で震えるほど役立つ「WFA構築の鉄則」
- 冪等性を担保せよ: 自動修復は必ず「何度実行しても副作用がない」設計にすること。
- 「診断」と「修復」を分離せよ: いきなり再起動するのではなく、先に「ダンプ取得」「スレッドダンプ調査」などの診断ステップをWorkflow内に組み込む。
- 人間をループから外すな（最初は）: 最初から全自動にするのではなく、Slackボタンでの承認フローを挟み、「何が起きてどう直ったか」の監査ログを残すことから始める。
—
2. 実践：K8sポッドの自動再起動Workflow
最も即効性が高い「メモリリークやデッドロックによる一時的な不調」を解消するWorkflowの構成例を紹介します。
Workflow YAML構成例（ベストプラクティス）
ダンプ取得から再起動までのワークフロー例
name: “K8s_Pod_Autorecovery”
steps:
- id: get_pod_logs
type: “kubernetes.get_logs”
inputs:
pod_name: “{{ trigger.pod_name }}”
namespace: “production”
- id: restart_pod
type: “kubernetes.restart_pod”
inputs:
pod_name: “{{ trigger.pod_name }}”
namespace: “production”
# ここが重要：失敗時に即座に通知を飛ばすための条件分岐
on_failure:
action: “slack.notify”
inputs:
message: “自動復旧に失敗しました。人間出動してください。”
プロの極意: `on_failure` を適切に設定しないWorkflowは、ただの「死んだふりをするシステム」です。必ず失敗時の通知フローを設計してください。
—
3. Datadogを極めるための「隠れた技術」
ここからは、日々のオペレーションを加速させるためのプロのTIPSです。
A. 開発スピードを劇的に上げるキーボードショートカット
- `Shift + ?`: 全ショートカット一覧を表示。これを暗記していないエンジニアは、Datadogを使いこなせていません。
- `g + d`: Dashboardsへ即移動。
- `g + a`: Alertsへ即移動。
- `Cmd/Ctrl + K`: 最強のコマンドパレット。リソース名、ダッシュボード、設定項目までこれ一つで検索可能です。マウス操作は極力減らしましょう。
B. 絶対に入れるべき「神」プラグイン・拡張
- Datadog Browser Extension: Chrome拡張を入れてください。現在のページから直接「どのダッシュボードがこのリソースを見ているか」や「関連ログ」へのショートカットが生まれます。
- Datadog CLI (dd): CI/CDパイプラインに組み込むなら必須。設定ファイルのバリデーション（`dd check`）をローカルで行うだけで、デプロイ後の設定ミスが9割減ります。
C. チーム開発で役立つ設定共有ルール
- Dashboardは「JSON as Code」で管理せよ: 手動でポチポチ作ったダッシュボードは、誰かが触れば壊れます。`terraform-provider-datadog` を使い、GitHubリポジトリで管理し、PRレビューを通す運用に強制的に切り替えてください。
—
4. 最後に：エンジニアの時間を守るために
「深夜の障害対応」を自動化することは、単なる効率化ではありません。それは、あなたのチームの疲弊を防ぎ、創造的な議論をするための時間を取り戻すことです。
Workflow Automationは、最初は「怖そう」に見えるかもしれません。しかし、一度「アラートが飛んだ瞬間に、システムが自己修復し、完了報告がSlackに来る」という体験をすると、もう元の手動対応には戻れません。
まずは、最も頻繁に発生する「再起動すれば直る」という単純なアラートから、自動化の第一歩を踏み出してください。技術は、人を苦しめるためにあるのではなく、人を解放するためにあります。
さあ、今夜はアラートに邪魔されず、ゆっくりと眠りましょう。皆さんのシステムが、自律的に健やかであることを願っています。