IncidentRelay チームによる比較。ドキュメントは に確認されました。 IncidentRelay スコープ: v2.3.1。これはドキュメントに基づいた評価であり、パフォーマンスのベンチマークや機能の同等性を保証するものではありません。
素早い決定 · 機能 · 移行制限 · パイロット チェックリスト
短い答え
オンコール インフラストラクチャを自分で実行する場合は、IncidentRelay を評価します。デプロイメント制御、検査可能なソース、およびアラート ルーティング構成の所有権が必要です。 PagerDuty ベンダーが運営するサービスとその確立されたワークフローが、そのインフラストラクチャを所有するよりも価値がある場合を評価します。
どちらの選択をしても、所有権の定義、スケジュールの管理、通知のテストといった作業が不要になるわけではありません。 IR を使用すると、ページング システム自体のホスティング、アップグレード、バックアップ、監視がその責任リストに追加されます。これらのコストを、単なるヘッドラインシートの価格ではなく、実際に使用する PagerDuty プランやアドオンと比較してください。
機能名だけでなくワークフローを比較する
| 決断 | IncidentRelay v2.3.1 | PagerDuty |
|---|---|---|
| 動作モデル | 自己ホスト型のオープンソース アプリケーション。あなたのチームがデプロイメントを運用します。 | ベンダー運営のインシデント管理プラットフォーム。 |
| スケジュールとエスカレーション | ローテーション レイヤ、オーバーライド、エスカレーション ポリシー。インポートの制限は、ソース スケジュールのタイプによって異なります。 | スケジュールとエスカレーション ポリシーによって、どのレスポンダが割り当てられ、通知されるかが決まります。 |
| イベントルーティング | グローバルおよびサービス オーケストレーション、正規化されたラベル、シミュレーション、リプレイ、シャドウ モード。 | イベント オーケストレーション;高度な機能はプランとアドオンによって異なります。 |
| お知らせ | チャット、メール、音声チャネルに加え、プロファイル レベルのブラウザ/PWA プッシュ。プロバイダーと連絡先を自分で設定します。 | プッシュ、電話、Slack、電子メール、SMS 配信パスを含むユーザー通知ルール。 |
| インシデントモデル | AlertGroups は技術的なページングを処理します。個別のインシデントが運用ワークフローを調整します。 | サービス イベントは、割り当て、承認、解決、タイムラインを伴うアラートとインシデントを作成します。 |
上記の PagerDuty ライフサイクルと配信の詳細は、インシデントの概要に続きます。いずれかのシステムを選択する前に、プランの資格、プロバイダーの適用範囲、依存する正確な統合を検証してください。
IRのインシデントモデルが示唆しないこと
IR 2.3 は、技術的なアラート グループを運用上のインシデントから分離します。 1 つのインシデントは、技術履歴をマージせずに複数のアラート グループをリンクできます。確認とエスカレーションは依然として AlertGroup の懸念事項です。このリリースでも、レスポンダーとステークホルダーは引き続き AlertGroup スコープです。既存の対応プロセスをマッピングする前に、インシデント管理の境界を読んでください。
IR は、PagerDuty API のドロップイン代替品ですか?
いいえ。IR は、/api/integrations/webhook でPagerDuty Events API v2互換のアラート ペイロードを受け入れます。送信者はエンドポイントの変更をサポートし、IR ルート トークンを routing_key として使用する必要があります。 trigger、acknowledge、および resolve を安定した dedup_key でテストします。
この互換性は、PagerDutyRESTAPI、モバイル アプリ、Terraform リソース、またはすべての統合の動作ではなく、アラートの取り込みを対象としています。在庫自動化は別途。 PagerDuty のエンドポイントをハードコーディングするツールには、別の統合またはアダプターが必要になる場合があります。
PagerDuty インポーターが実際に転送するもの
IR v2.3.1 移行ガイドには、両方の製品のパブリック API を使用したドライランファースト インポーターについて記載されています。 --apply を追加する前にレポートを確認してください。
- サポート対象: ユーザー、チーム、メンバーシップ、従来のスケジュールとレイヤー、毎日の/weekly制限、将来のオーバーライド、エスカレーション ポリシー、サービス、Webhook ルート、およびアクティブな/futureメンテナンス時間枠。
- インポートされません: インシデントまたはアラートの履歴、イベント オーケストレーションとルールセット、V3 シフトベースのスケジュール、電話番号、連絡方法、通知ルールまたはチャネル。
- 非可逆マッピング: 共有スケジュールとポリシーはチームごとに複製されます。マルチチーム サービスは、最初にマップされたチームを使用します。並列エスカレーション ターゲットは、最初のターゲットの後に遅延がゼロの連続ルールになります。意図したページング動作に対する各警告を確認してください。
- 重要なカットオーバー要件: 作成されたルートには通知チャネルがありません。インポートされたサービスは、チャネルまたは通知ポリシーが構成されてテストされるまで、誰にもページングする準備ができていません。
安全に再開するには、state.json を保持してください。 route-secrets.json と route-switch-map.csv を保護します。これらには取得資格情報が含まれています。オーケストレーション ルールを意図的に再構築します。機能名が似ていても、ルール言語を交換可能にすることはできません。
移行受け入れチェックリスト
- 予行演習を実行し、サポートされていないオブジェクトのインベントリを作成し、非運用環境の IR デプロイメントでインポートをリハーサルします。変更を適用する前に IR をバックアップします。
- 1 つの完全なオンコール サイクル、タイムゾーンの変更、オーバーライド、エスカレーション順序を比較します。 オンコール ヘルスを使用して、ギャップや欠落している配信構成を見つけます。
- 同じ重複排除キーを使用してトリガーを 2 回送信し、それを確認して解決します。応答コードだけでなく、グループ化、所有権、および結果の状態を確認します。
- 実際のチャット、電子メール、プッシュ、または音声配信をテストします。エスカレーションを実行するために 1 つのアラートを未確認のままにし、確認によりそれ以上のページングが停止されることを確認します。
- カットオーバー CSV を使用してリスクの低いサービスを 1 つ切り替え、オンコール サイクルを観察します。承認されるまで、PagerDuty 構成と文書化された送信者ロールバックを利用できるようにしておきます。パイロット中は重複した運用ページングを避けてください。
まだ移行すべきでない場合
必要なスケジュールを表現できない場合、応答者がテストされていないモバイルまたは音声ワークフローに依存している場合、履歴レコードをサービスとともに移動する必要がある場合、または新しい展開を誰も所有していない場合は、一時停止します。送信者を切り替える前に、これらのギャップを解決してください。成功したインポート レポートは、エンドツーエンドの配信テストではありません。
評価する準備はできていますか? テスト インスタンスをデプロイし、より広範なロールアウトを計画する前に、代表的なサービスを 1 つ検証します。
PagerDuty は PagerDuty, Inc. IncidentRelay の商標です。 PagerDuty と提携していません。