Control-M + PagerDuty

あなたの PagerDuty ワークフローは、インシデントアクションが呼び出される前から始まります — そして、何か上流が壊れると失敗する可能性があります。AWS Batch ワークロードは、その依存プロセスが完了する前に失敗します。SAP のクローズジョブは、午前 2 時の完了ウィンドウを逃します。Control-M は、ワークロード実行、依存関係の完了、PagerDuty インシデントアクション、および下流の回復を調整します。

あなたのようなパイプラインで見る統合の詳細を見る

一般的なワークフローの問題

これがあなたの週のように聞こえますか？

これらはエッジケースではありません。それは、複数のツールを使ってPagerDutyインシデントワークフローを実行しているチームにとっての通常の運用条件です。Control-Mがそれぞれをどのように処理するかは次の通りです。

エスカレーションの見逃し

あなたの午前2時のバッチが失敗しました。誰もPagerDutyインシデントを開きませんでした。

Control-Mはワークフローの失敗を検出し、適切なサービス、緊急度、タイトル、インシデントの詳細を持つインシデントを作成するためにPagerDutyジョブを実行します — オペレーターを待つことなくプロダクションの失敗をインシデントレスポンスに直接接続します。

インシデントコンテキスト

ページが発火しました。今、応答者は何が失敗したのかを再構築する必要があります。

Control-Mは、インシデントが作成されるときに応答チームに行動可能なコンテキストを提供するために、タイトル、サービスID、緊急度、インシデントキー、インシデント本文を含むワークフロー特有の詳細でPagerDutyインシデントを埋めることができます。

クロスツール可視性

PagerDutyはインシデントを把握しています。オペレーションは依然としてワークフローステートが必要です。

Control-MはPagerDutyジョブのステータス、結果、および出力を、その周囲のジョブと共に1つのスケジューリング環境内で監視するため、オペレーターはエンドツーエンドのプロダクションワークフローの文脈でインシデントアクションを確認できます。

SLAリスク

ワークフローは遅れていますが、エスカレーションは期限後に始まります。

Control-MはSLAジョブをPagerDutyジョブに添付し、インシデント対応をより広いワークフローと調整することができ、オペレーションチームが重要なサービス提供を追跡するために使用する同じオーケストレーション環境でのレスポンス管理を支援します。

インシデントライフサイクル

回復が始まりました。PagerDutyインシデントは依然として調整されたアクションを必要としています。

Control-M PagerDutyジョブは、インシデントの詳細を作成、更新、スヌーズ、取得することができ、インシデント管理ステップが自動化された生産ワークフローの明示的な部分となり、失敗後の切り離された手動アクションではなくなります。

統合の詳細