現在のオンコール プロバイダーからの移行

This product is not supported for your selected Datadog site. ().

現在のオンコール プロバイダーから Datadog On-Call へ移行すると、監視とインシデント レスポンスを一元化し、アラートの複雑さを低減し、監視とインシデント レスポンスを統合できます。このガイドは、移行を計画・テストし、成功裏に完了させるための段階的なアプローチを提供します。

多くの組織は、機能の検証と運用上の適合性の評価のために、少数のチームで Datadog On-Call のパイロットから開始します。その基盤を踏まえ、本ガイドは評価段階から本番での全面採用へ移行するための主要ステップを順に説明します。

このガイドで学べること:

  • 現在のオンコール セットアップの棚卸しと評価を行う方法
  • チーム構成とエスカレーション パスに基づいて Datadog On-Call を構成する方法
  • アラート ルーティングとエスカレーション ワークフローを検証する方法
  • 既存のレガシー プロバイダーから安全に切り替える方法
  • 新しいオンコール プロセスを監視・運用・拡張する方法

また、本ガイドには、移行の信頼性を高めリスクを抑えるための検証チェックリスト、ロールバック ストラテジー、セーフガードも含まれます。

本ガイドの対象者

本ガイドは、オンコール移行に関与するエンジニアおよびステークホルダーを対象としています。サイト リライアビリティ エンジニア (SRE)、DevOps エンジニア、チーム リード、その他、インシデント レスポンスのワークフローを構成または管理する責任を持つ方を含みます。

現在のセットアップの棚卸しとマッピング

まず、現在オンコール チームをページングしているすべてのツールのインベントリを作成します。これには次が含まれます:

  • 監視プラットフォーム (Datadog、CloudWatch、Prometheus など)
  • チケット システム (Jira や Zendesk など)
  • カスタム アラーティング ツールやワークフロー ツール

各ツールについて、現在の連携方法を記録します。ネイティブ連携、ウェブフック、メール取り込み、カスタム スクリプトなどです。

現行のオンコール セットアップを評価する中で、その構成要素 (スケジュール、エスカレーション パス、オーバーライド、レスポンダー グループなど) が Datadog On-Call の構成モデルにどのように対応づけられるかを明らかにし始めてください。また、複雑または古いエスカレーション ロジックを簡素化し、チーム横断でポリシーを標準化する良い機会でもあります。明確な運用上の必要性がない限り、未使用またはレガシー構成は移行しないでください。

円滑な構成フェーズを支えるため、次の情報も必ず把握します:

  • チームのアクセス コントロールと権限
  • フォールバック レスポンダーの割り当てと通知設定
  • オーバーライド ウィンドウとハンドオフの取り決め

Datadog における統一されたアラーティング モデルは運用のオーバーヘッドを削減し、可視性を高めるのに役立ちますが、その効果は、入力が最初から明確に定義され、慎重にマッピングされている場合に限られます。

移行戦略を設計する

移行を成功させるには、ステークホルダーの足並みを揃え、リスクを低減し、オープンなコミュニケーションを維持する、明確で段階的な計画が不可欠です。移行を次のような扱いやすいステージに分割します:

  1. Discovery: 現行のワークフロー、連携、アラート ルール、チーム要件を文書化します。
  2. Configuration: 既存のセットアップと望む改善点に基づいて Datadog On-Call をセットアップします。
  3. Validation and testing: アラートが正しくルーティングされ、エスカレーション ロジックが期待どおりに動作することを確認します。
  4. Cutover: 通常はデュアル ルーティング ウィンドウを用いて、アラート対応の責務を Datadog On-Call へ移行します。
  5. Cleanup: レガシー システムを廃止し、安定性を検証し、ドキュメントとランブックを更新します。

各フェーズに明確なオーナーを割り当て、タイムラインを早期に周知します。タスクの調整、更新の共有、ブロッカーの即時可視化には、Slack や Microsoft Teams といった共有チャンネルを活用します。

Datadog On-Call を構成する

Datadog On-Call の構成を始める前に、Teams の概念を確認してください。Teams は On-Call 体制の基盤であり、次の定義に用いられます:

  • Schedules
  • Escalation policies
  • Notification rules
  • Incident ownership

チーム モデルを確認し既存アセットをマッピングしたら、望む体制を反映するよう Datadog On-Call を構成する準備が整います。

PagerDuty から移行する場合、Datadog は 専用の移行ツール を提供しており、Schedules と Escalation policies を選択的にインポートするのに役立ちます。未使用の構成を移行してしまうことを避け、手作業を減らすため、セットアップ時に活用してください。

セットアップ中は次の点も忘れずに行います:

  • チームのアクセス コントロールと権限の見直し
  • フォールバック レスポンダーと通知設定の定義
  • オーバーライド ウィンドウとオンコールのハンドオフの取り決めの設定

丁寧な構成はスムーズなカットオーバーを保証し、初日からチームが効果的に対応できるようにします。

移行を検証し、監視する

レガシー システムを廃止する前に、すべてのチームおよびあらゆるアラート シナリオにおいて、Datadog On-Call が適切にルーティング、エスカレーション、通知していることを確認するための包括的なテストを実施します。

検証チェックリスト

  • クリティカルな Monitors からアラートをルーティング: 最高重大度の Monitors を特定し、テスト アラートをトリガーして、適切な Datadog On-Call チームにルーティングされることを確認します。迅速な配信とメタデータの正確性をチェックします。
  • エスカレーション チェーンを検証: 未 Acknowledge のアラートをシミュレートして、エスカレーションが意図した順序に従うことを確認します。時間ベースとフォールバックの両方のエスカレーションを含めます。想定されたすべてのレスポンダーで受信を検証します。
  • 通知 チャンネルを確認: メール、SMS、プッシュ 通知、音声など、設定済みのすべての方法でチーム メンバーがアラートを受信できることを確認します。受信者に配信の有無と内容の明確さを確認してもらいます。
  • オーバーライド と ハンドオフをテスト: チーム メンバーに一時的なオーバーライドを設定し、その期間中にアラートが正しくルーティングされることを検証します。シフト間のハンドオフでも繰り返し、エッジ ケースを洗い出します。
  • Slack または Teams の可視性を検証: テスト アラートをトリガーし、正しい Slack または Teams のインシデント チャンネルに、正確な tags、オーナーシップ、Acknowledge または Resolve へのリンク付きで表示されることを確認します。
  • シンセティック インシデントをシミュレート: 手動でシンセティックなアラートをトリガーするか、ダミー モニターを使用して、Acknowledge、エスカレーション、解決までのインシデント ワークフロー全体をテストします。
  • スケジュール カバレッジを監査: 休日や週末を含め、チームの Schedules に未カバーの時間がないかクロスチェックします。
  • レガシー プロバイダーと比較: デュアル ルーティングを使用している場合、両方のシステムがアラートを受信し、類似のエスカレーション動作を取ることを検証します。カットオーバー前に差分を記録し、解消します。

デュアル ルーティングの実践

多くの組織は検証中にデュアル ルーティングを実施し、アラートをレガシー プロバイダーと Datadog On-Call の両方に並行送信します。これにより、チームは次のことが可能になります:

  • アラート ルーティングとエスカレーション動作をリアルタイムで比較する
  • システム間のギャップが存在しないことを確認する
  • 切り替え期間のリスクを低減する

Datadog の Monitor Bulk Editor を使用して、既存の送信先に加えて Datadog On-Call のハンドルを追加します。パフォーマンスとカバレッジを検証したら、レガシーのアラート ルートを削除し、カットオーバーを確定できます。

移行をモニタリング

Datadog Dashboards を使用して、移行のパフォーマンスをリアルタイムに観測します。次の指標に注目します:

  • プロバイダー別のアラート ボリューム
  • Acknowledge およびエスカレーションの遅延
  • チームのオーナーシップが欠けているインシデント

これらのシグナルは、準備状況の検証、誤構成の検出、フル カットオーバー前の早期課題の顕在化に役立ちます。

カットオーバーしてレガシー システムを廃止

検証が完了し、すべてのチームが Datadog On-Call を積極的に使用していることを確認したら、レガシー プロバイダーの段階的な廃止を開始します。多くのチームは次のように段階的に進めます:

  • 低重大度または発生頻度の低いアラート パスから先に廃止する
  • 廃止予定の Schedules、Escalation policies、routing keys を削除する
  • レガシー 構成をアーカイブするか、参照用にドキュメントとしてエクスポートする

すべての Monitors が Datadog On-Call のみに送信するよう設定され、レガシー連携がもはや使用されていないことをダブルチェックします。デュアル ルーティング期間に不整合やギャップが判明した場合は、カットオーバーを確定する前に対処します。

これを完了することで、クリーンな移行が保証され、インシデント レスポンス中の混乱やアラートの取りこぼしのリスクが排除されます。

オンコール 運用を維持・拡張

Datadog On-Call への中核的な移行が完了したら、長期運用と継続的改善にフォーカスを移します。以下のプラクティスを用いて、オンコール プロセスの健全性を保ち、チームの備えを維持し、ニーズの成長に合わせてセットアップを進化させましょう。

  • 継続的なオーナーシップを確立: チーム内で Datadog On-Call の明確なオーナーシップを割り当てます。Schedules の維持、新規 responders のオンボーディング、時間の経過に伴う機能変更への適応を含みます。
  • ポスト モーテムを取り入れる: 移行中または移行後に発生したインシデントを振り返り、見落とされたエスカレーションやアラート上の問題を特定します。得られた学びをテスト計画やランブックのドキュメントに反映します。
  • オンコールの健全性をトラッキング: On-Call Analytics を使用して、レスポンダーごとのアラート ボリューム、MTTA/MTTR の傾向、通知 疲労、再発するエスカレーションを監視します。
  • 最新情報を把握: Incident Response product updates を購読して、新機能、改善点、非推奨事項をフォローします。
  • プロダクト知識を深める: Datadog のドキュメント Incident Management、Schedules、Integrations を参照し、プラットフォームの活用範囲を広げます。
  • コミュニティに参加: Datadog Slack Community で同業者や Datadog エンジニアと交流し、ベスト プラクティスの共有、アドバイスの取得、フィードバックの提供を行います。
  • レトロスペクティブをスケジュール: 移行後 30～60 日以内にレトロスペクティブを実施し、得られた教訓を記録して、ドキュメント、社内ガイド、テスト プランを更新します。

参考資料

お役に立つドキュメント、リンクや記事:

On-Callドキュメント more more Incident Managementドキュメント more more