IncidentRelay チームによる比較。ドキュメントは に確認されました。 IncidentRelay スコープ: v2.3.1。これはドキュメントに基づいた評価であり、パフォーマンスのベンチマークや機能の同等性を保証するものではありません。
素早い決定 · 機能 · 移行制限 · パイロット チェックリスト
シャットダウン日から開始
Opsgenie は、2025 年 6 月 4 日に新規販売を停止しました。アトラシアンは、移行されていない顧客データは削除され、2027 年 4 月 5 日に閉鎖されると述べています。これは単に新機能の終わりではありません。既存のユーザーには宛先とデータ保持プランが必要です。 公式の Opsgenie 移行に関するお知らせをご覧ください。
Jira Service Management チームが Atlassian Cloud に留まり、接続されたサービス管理ワークフローを維持したいかどうかを評価します。 オープンソースのオンコール システムを自社のインフラストラクチャで意図的に運用し、その可用性、アップグレード、バックアップを所有できる場合は、IncidentRelay を評価します。
セルフホスティングは移行作業の近道ではありません。目的地の所有者が変わります。ホスティングとエンジニアリングの労力を、想定される 1 対 1 のライセンス交換ではなく、実際の宛先プラン、ユーザーの役割、通知要件と比較します。
実際に何を動かしているのか
| 決断 | IncidentRelay v2.3.1 | アトラシアンの移行パス |
|---|---|---|
| 動作モデル | 自己ホスト型のオープンソース アプリケーション。あなたのチームがデプロイメントを運用します。 | 移行ツールは、Jira Service Management データセンターではなく、Atlassian Cloud をターゲットとしています。 |
| スケジュールとエスカレーション | 回転、レイヤー、オーバーライド、エスカレーション ルールを再構築します。 オンコール ヘルスで検証します。 | アトラシアンは、サポートされている構成の自動移行を提供します。結果として得られるスケジュールとポリシーを確認します。 |
| イベントルーティング | グローバルおよびサービス オーケストレーション、正規化されたラベル、シミュレーション、リプレイ、シャドウ モード。 | 統合の変更と廃止された機能を確認します。テナントを移動しても、同じ動作が保証されるわけではありません。 |
| お知らせ | チャット、メール、音声チャネルに加え、プロファイル レベルのブラウザ/PWA プッシュ。プロバイダーと連絡先を自分で設定します。 | 古い Opsgenie サービスを無効にする前に、モバイルアプリの変更と通知の設定を確認してください。 |
| インシデントモデル | AlertGroups は技術的なページングを処理します。個別のインシデントが運用ワークフローを調整します。 | インシデント対応は Jira Service Management に移行します。現在のプロセスに対して機能の変更を確認します。 |
アトラシアンのパスについては、移行スケジュールと Cloud Center/Data のガイダンスと機能変更チェックリストをお読みください。このページでは、そのパスを IR と比較します。 Opsgenie と Jira Service Management は同じ製品として扱われません。
IR への移行はテナントのインポートではなく再構築です
IR v2.3.1 には Opsgenie 用のインポートツールは含まれていません。このリリースの移行ツールが対応しているのは PagerDuty と Grafana OnCall OSS です。これらのツールのインポート保証が、Opsgenie のエクスポートにも適用されるとは限りません。
- メンバーとスケジュール: チーム、メンバーシップ、ローテーション、時間制限、上書きを再作成します。週末や夏時間の変更を含むサイクル全体にわたって、実際に割り当てられたレスポンダを比較します。
- 統合と重複排除: 各送信者、その認証、アラート ID をインベントリします。 サポートされている IR 統合を使用するか、イベントを汎用 Webhook コントラクトにマップします。 Opsgenie API キーまたはペイロードは、IR では自動的には有効になりません。
- ポリシーと配信: ルーティングとエスカレーションを意図的に再構築します。新しいシークレット、ユーザーの連絡先詳細、通知チャネルを構成します。コピーしたスケジュールが誰にでも通知できるとは考えないでください。
- 履歴と自動化: 必要なレコードを個別に保存し、スクリプト、API クライアント、チケット リンク、応答アクションをインベントリします。構成の再作成では、インシデント履歴はインポートされず、Opsgenie API の互換性も提供されません。
IR 2.3 は、技術的なアラート グループを運用上のインシデントから分離します。 1 つのインシデントは、技術履歴をマージせずに複数のアラート グループをリンクできます。確認とエスカレーションは依然として AlertGroup の懸念事項です。このリリースでも、レスポンダーとステークホルダーは引き続き AlertGroup スコープです。既存の対応プロセスをマッピングする前に、インシデント管理の境界を読んでください。
明示的なロールバック ポイントを持つパイロット
- Opsgenie の期限、移行所有者、必要な履歴エクスポートを記録します。 Atlassian の移行もスケジュールする場合は、並行アクセス ウィンドウを考慮してください。製品が最終的にシャットダウンされるまで、古いテナントが使用可能なままであると想定しないでください。
- テスト IR 導入で代表チームを 1 つ構築します。全ローテーション サイクル、オーバーライド、エスカレーションの遅延、ファーストレスポンダが応答しない場合の動作を比較します。
- サニタイズされた起動、複製、回復イベントを再生します。選択したチーム、グループ化キー、サービス、および通知チャネルを確認します。パイロット中にどのシステムが確認応答を所有するかを決定します。
- 時間外の状況を含め、実際のレスポンダー デバイスで配信をテストします。 オンコール ヘルスを使用しますが、メッセージと通話が実際に到着することも確認します。
- リスクの低い送信者を 1 人切り替えます。 Opsgenie がアクティブな間は以前の構成を利用可能な状態に保ち、運用通知の重複を避けます。オンコール サイクルを観察した後にのみ拡張してください。
削除されたテナントにロールバックを依存させないでください
アトラシアンは、Opsgenie をオフにすることは元に戻せないと述べています。また、事前にオフにしなかった場合は、アトラシアンへの移行から 120 日後に自動的にシャットダウンされます。この期間は、無期限のフォールバックを約束するものではありません。検証を終了し、シャットダウンする前に必要なレコードを保存します。 Opsgenie をオフにするとどうなるかをご覧ください。
テスト導入から始めます。必要なワークフローを再現できない場合、または宛先を誰も操作できない場合は、運用送信者を変更する前にそのギャップを解決してください。
Opsgenie と Jira Service Management はアトラシアン製品です。 IncidentRelay はアトラシアンと提携していません。