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

パイプラインの監視プロセスは、通常、オンコールローテーションを実装することで最善に管理されます。これは、一度に一人のチームメンバーがパイプラインを積極的に監視している（"オンコール"）ことを意味し、パイプラインの問題（通常はヘルスチェックの失敗の形）に対応することが、彼女のオンコールローテーション期間中の最も重要な優先事項となります。

効果的なパイプライン監視チームを設定するために推奨されるステップは次のとおりです。

• 監視するさまざまなパイプラインのサポート時間を定義します。
  • パイプラインが正しく夜間または週末に更新されることが重要ですか？
• アラートメカニズムを定義します。これについては下記を参照してください。
• サポートローテーションスケジュールを定義します。
  • サポートローテーションは何日で、どの日にハンドオフすべきですか？
  • (Pagerdutyなどの外部ツールを使用している場合)オンコールの主要な人物がアラートを見逃した場合、第二のオンコールローテーションスケジュールが必要ですか？
• パイプラインの文書化を準備します。
  • 文書化が存在する場所を簡単に見つけることができるべきです。良い場所の例は、Foundryのパイプラインに近い場所に文書化を保持することで、例えば、パイプラインの主要な出力が存在するプロジェクトのトップレベルのdocumentation フォルダーです。
  • 文書化には以下を含めるべきです。
    • パイプラインの目的の概要、出力がどのように使用され、組織的な期待とSLA。
    • パイプラインの最新の Data Lineage グラフ。
    • 問題がある場合に、オンコールのチームメンバーが連絡を取る可能性があるすべての上流サポートチームを記載します。例えば、プラットフォームサポートチーム、Palantirのパイプラインサポートチーム、パイプラインのデータを提供している組織内の他のチーム。
    • エスカレーションパスのメモ（オンコールの人が自分自身で解決できない、ただちに注意が必要な緊急の問題がある場合、どのようにエスカレーションするか？）
    • パイプラインの定期的な問題についてのセクションを作成し、自分自身または次のオンコールの人が以前に発生した問題を簡単に特定し、同じ修正を適用することができます。一部のチームはすべての技術的な問題をログに記録することを選ぶかもしれませんが、過度に文書化すると情報を素早く見つけることが難しくなる可能性があります。
• オンコールローテーション間のハンドオフのためのSOPを定義します。
  • ハンドオーバーは定期的な時間にスケジュールされるべきですか？
  • 異なるチームメンバーのオンコールローテーションをまたぐ長期間の問題をどのように追跡しますか？
  • 長期間の問題を追跡し解決する責任は誰にありますか？問題を最初にトリアージしたオンコールのチームメンバーは、彼女がオンコールでないときに問題に取り組むのか、それとも問題は積極的にオンコールしている人に引き渡されるのか？
• 下流の消費者にダウンタイムとメンテナンスを通知するプロセスを定義します。これは、下流のパイプラインのメンテナが非問題でアラートされるリスクを最小限に抑えるのに役立ちます。

アラートメカニズム

アラートメカニズムは、パイプラインのヘルスチェックが失敗したときに反応的に対応することを可能にします。これにより、パイプラインの状態を確認するためにData Lineageグラフ、ダッシュボード、またはレポートを定期的にチェックする必要がなくなります。適切なアラートメカニズムの選択は、アラートの規模と、SLAがどれほど厳しいか（これは応答時間がどれほど重要かを決定します）によります。

自動化されたアラートの利用可能なオプションには以下のものがあります。

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

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