Warning

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

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

パイプラインの監視プロセスは、通常、オンコールローテーションを実施することにより最善の管理が可能です。これは、一度に一人のチームメンバーがアクティブにパイプラインを監視(「オンコール」)し、パイプライン問題(通常は、健康状態チェックの失敗の形)に対応することが、彼女のオンコールローテーション期間中の最も重要な優先事項であることを意味します。

効果的なパイプライン監視チームを設定するための以下のステップが推奨されます:

  • モニターする各パイプラインのサポート時間を定義します。
    • パイプラインが正しく夜間や週末に更新されることは重要ですか?
  • アラートメカニズムを定義します。詳細は下記を参照してください。
  • サポートローテーションスケジュールを定義します。
    • サポートローテーションはどのくらいの期間で、どの日に引き継ぎが行われるべきですか?
    • (Pagerdutyのような外部ツールを使用している場合)主なオンコール担当者がアラートを見落とす場合に備えて、セカンダリーのオンコールローテーションスケジュールが必要ですか?
  • パイプラインのドキュメンテーションを準備します。
    • ドキュメンテーションがどこにあるのかを簡単に見つけられるようにする必要があります。良い場所の例としては、Foundryのパイプラインに近い場所にドキュメンテーションを保管することが挙げられます。例えば、パイプラインの主要な出力が存在するプロジェクトのトップレベルの documentation フォルダーなどです。
    • ドキュメンテーションには以下を含める必要があります:
      • ユーザーのパイプラインの目的、出力の使用方法、組織の期待とSLAの概要。
      • ユーザーのパイプラインのための最新の Data Lineage グラフ。
      • 問題が発生した場合にオンコールのチームメンバーが連絡を取る必要がある上流のサポートチームをすべて記録しておく。例としては、プラットフォームサポートチーム、Palantirのパイプラインサポートチーム、ユーザーのパイプラインのためのデータを提供している組織内の他のチームを含めることができます。
      • エスカレーションパス(オンコール担当者が自身で解決できない緊急の問題が発生した場合にどのようにエスカレーションを行うか)のメモを作成します。
      • ユーザーのパイプラインの定期的な問題に関するセクションを作成し、自身や次のオンコール担当者が以前に発生した問題を簡単に特定し、同じ修正を適用できるようにします。一部のチームでは、発生した全ての技術的な問題を記録することを選ぶかもしれませんが、過度のドキュメンテーションは情報を素早く見つけることを難しくする可能性があることを考慮してください。
  • オンコールローテーション間の引き継ぎのためのSOPを定義します
    • 引き継ぎは定期的な時間にスケジュールされますか?
    • 長期間にわたる問題をどのように追跡しますか?これらの問題は、異なるチームメンバーのオンコールローテーションにまたがっています。
    • 長期間にわたる問題を追跡し、解決するのは誰の責任になりますか?問題を最初にトリアージしたオンコールのチームメンバーは、オンコールでないときに問題に取り組むのですか?それとも、問題はアクティブにオンコールである人に引き継がれますか?
  • ダウンタイムとメンテナンスを下流の消費者に通知するプロセスを定義します。これにより、下流のパイプライン保守者が非問題に対して警告されるリスクを最小限に抑えることができます。

アラートメカニズム

アラートメカニズムを設定することで、パイプラインでの健康状態チェックの失敗に対してリアクティブに対応することができます。これにより、パイプラインの状態を確認するために、Data Lineageグラフ、ダッシュボード、レポートを定期的にチェックする必要がなくなります。適切なアラートメカニズムの選択は、アラートの規模とSLAの厳しさ(これが応答時間がどれだけ重要かを決定する)によります。

自動アラートの利用可能なオプションは以下の通りです:

  • パイプラインのすべての個別の健康状態チェックを購読します。この方法を使用すると、通知設定がオンになっている場合は、Foundryとメールで通知を受け取ることができます。ただし、この方法は手動で維持するのが難しい場合があります。
  • check group digestsを購読します: チェックグループには、パイプラインで監視したいすべての健康状態チェックを含める必要があります。
    • ノイズを減らすために、チェックグループのスケジュールで、パイプラインでチェックが失敗しているときだけ通知されるように設定できます。
  • 外部のアラートツールとの統合 例えば、Pagerdutyなど。
    • 一部のツールは、オンコールローテーションとスケジュール、セカンダリーオンコールローテーションを含む、管理を支援することも可能です。
    • 一部のツールは、アラート設定でさらに柔軟性とカスタマイズを提供できます。通知が応答されなかった場合のエスカレーションの方法をカスタマイズすることは、特に時間に基づく厳格なSLAを持つ非常に重要なパイプラインを持っている場合に特に有用です。
    • 一部のツールは、ユーザーが好む通信ツールとさらに統合できます。
    • 上記の機能を提供する業界標準のツールの例としてPagerdutyがあります。現在、Pagerdutyと統合するための推奨方法は、メール統合を通じて行うことです。

どのオプションを実装するにせよ、Foundryプラットフォームの他の通知の中でアラートを見逃さないように、フィルター処理するのが有用です。