注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

推奨されるサポートプロセス

パイプラインの監視プロセスは、通常、オンコールの輪番制を導入して管理するのが最適です。これは、1度に1人のチームメンバーがパイプラインを積極的に監視し(「オンコール」)、その担当期間中はパイプラインの問題への対応(通常はヘルスチェックや監視ルールの失敗への対応)を最優先にするということです。

効果的なパイプライン監視チームを立ち上げるには、次の手順を推奨します。

  • 監視するパイプラインごとにサポート時間を定義します。
    • パイプラインが夜間に正しく更新されることは不可欠ですか?週末はどうですか?
  • アラートの仕組みを定義します。詳細は後述します。
  • サポートの輪番スケジュールを定義します。
    • サポートの担当期間はどのくらいで、何曜日に引き継ぎを行うべきですか?
    • (PagerDuty などの外部ツールを使用している場合)主要なオンコール担当者がアラートを見逃した場合に備えて、予備のオンコール輪番スケジュールは必要ですか?
  • パイプラインのドキュメントを準備します。
    • ドキュメントの保存場所は簡単に見つけられるようにする必要があります。適切な場所の例として、パイプラインの主要な出力が保存されているプロジェクトの最上位の documentation フォルダーなど、Foundry 内でパイプラインの近くにドキュメントを保持する方法があります。
    • ドキュメントには次の内容を含める必要があります。
      • パイプラインの目的、出力の使用方法、および組織が期待する要件と SLA の概要。
      • パイプラインの最新の Data Lineage グラフ。
      • 問題が発生した場合にオンコールのチームメンバーが連絡する必要がある上流のサポートチームをすべて記載します。例として、プラットフォームのサポートチーム、Palantir のパイプラインサポートチーム、パイプラインにデータを提供している組織内のほかのチームを含めます。
      • エスカレーション経路を記載します(即時の対応が必要な緊急の問題をオンコール担当者が自力で解決できない場合、どのようにエスカレーションしますか?)。
      • パイプラインで繰り返し発生する問題に関するセクション。これにより、ご自身や次のオンコール担当者が過去に発生した問題を簡単に特定し、同じ修正を適用できます。発生した技術的な問題をすべて記録するチームもありますが、過度にドキュメント化すると情報をすばやく見つけるのが難しくなることを考慮してください。
  • オンコール担当の交代時に行う引き継ぎの標準作業手順(SOP)を定義します。
    • 引き継ぎは定期的な時間に予定しますか?
    • 異なるチームメンバーのオンコール担当期間にまたがって継続する問題をどのように追跡しますか?
    • 長期にわたる問題の追跡と解決は誰が担当しますか?最初に問題のトリアージを行ったオンコールのチームメンバーが、担当期間外でも引き続き対応しますか?それとも、現在のオンコール担当者に問題を引き継ぎますか?
  • ダウンタイムとメンテナンスを下流の利用者に伝えるプロセスを定義します。これにより、下流のパイプライン管理者に問題ではない事象のアラートが通知されるリスクを最小限に抑えられます。

アラートの仕組み

アラートの仕組みがあれば、パイプラインでヘルスチェックに失敗したときに対応できます。これにより、パイプラインのステータスを確認するために Data Lineage グラフ、ダッシュボード、レポートを定期的に確認する必要性が低くなります。適切なアラートの仕組みの選択は、アラートの規模と SLA の厳しさによって異なります(SLA の厳しさによって、レスポンス時間がどれほど重要かが決まるためです)。

自動アラートには、次の選択肢があります。

  • パイプライン内の個々のヘルスチェックをすべてフォローする。この通知設定を有効にしている場合、Foundry とメールで通知を受け取れます。ただし、この方法は手動での維持管理が難しい場合があります。
  • 監視ビューをフォローすることで、ヘルスチェックと監視ルールのグループを監視します。
    • 通知頻度は、監視ビューのフォロー設定でカスタマイズできます。
  • 監視ビューを外部のアラートツールと統合する。
    • 予備のオンコール輪番を含め、オンコールの輪番やスケジュールも管理できるツールがあります。
    • アラート設定の柔軟性やカスタマイズの幅をさらに広げられるツールもあります。時間に関する厳格な SLA が設定された非常に重要なパイプラインでは、通知に対応がない場合のエスカレーション方法をカスタマイズすることが特に有用です。
    • 外部ツールとの利用可能な統合について、詳しくはこちら。

どの選択肢を導入する場合でも、ほかの Foundry プラットフォームの通知に紛れてアラートを見逃さないよう、フィルターを設定すると有用です。