Comparaison par l'équipe IncidentRelay. Documentation examinée le ; Portée IncidentRelay : v2.3.1. Il s'agit d'une évaluation basée sur la documentation, et non d'une référence de performances ou d'une promesse de parité des fonctionnalités.
Décision rapide · Capacités · Limites de migration · Liste de contrôle pilote
Commencez par la date d'arrêt
Opsgenie a arrêté les nouvelles ventes le 4 juin 2025. Atlassian indique qu'il fermera ses portes le 5 avril 2027 et que les données clients non migrées seront supprimées. Ce n’est pas seulement la fin des nouvelles fonctionnalités. Les utilisateurs existants ont besoin d'une destination et d'un plan de conservation des données. Consultez l'annonce officielle de Opsgenie migration.
Évaluez Jira Service Management si votre équipe souhaite rester dans Atlassian Cloud et conserver les workflows de gestion des services connectés. Évaluez IncidentRelay si vous souhaitez délibérément exploiter un système de garde open source dans votre propre infrastructure et pouvez être propriétaire de sa disponibilité, de ses mises à niveau et de ses sauvegardes.
L'auto-hébergement n'est pas un raccourci pour le travail de migration. Cela change à qui appartient la destination. Comparez les efforts d'hébergement et d'ingénierie avec le plan de destination réel, les rôles des utilisateurs et les exigences de notification, et non avec un remplacement de licence supposé un pour un.
Ce que vous déplacez réellement
| Décision | IncidentRelay v2.3.1 | Chemin de migration Atlassian |
|---|---|---|
| Modèle opérationnel | Application open source auto-hébergée. Votre équipe opère le déploiement. | L'outil de migration cible Atlassian Cloud, et non Jira Service Management Data Center. |
| Calendriers et escalades | Reconstruire les rotations, les couches, les remplacements et les règles d'escalade ; validez-les avec Santé d'astreinte. | Atlassian permet une migration automatisée des configurations prises en charge ; examiner les calendriers et les politiques qui en résultent. |
| Routage des événements | Orchestration globale et de services, étiquettes normalisées, simulation, relecture et mode fantôme. | Examiner les modifications d'intégration et les fonctionnalités obsolètes ; déménager un locataire ne garantit pas un comportement identique. |
| Notifications | Canaux de chat, d'e-mail et vocaux, ainsi que push/navigateur au niveau du profil PWA. Configurez vous-même les fournisseurs et les contacts. | Vérifiez les modifications apportées à l'application mobile et la configuration des notifications avant de désactiver l'ancien service Opsgenie. |
| Modèle d'incident | Les AlertGroups gèrent la pagination technique ; Des incidents distincts coordonnent le flux de travail opérationnel. | La réponse aux incidents se déplace vers Jira Service Management. Vérifiez les modifications apportées aux fonctionnalités par rapport à votre processus actuel. |
Pour connaître le chemin Atlassian, lisez les planifications de migration et les conseils de Cloud/Data Center ainsi que la liste de contrôle pour les modifications de fonctionnalités. Cette page compare ce chemin avec IR ; il ne traite pas Opsgenie et Jira Service Management comme le même produit.
Le passage à l'IR est une reconstruction, pas une importation de locataire
IR v2.3.1 ne fournit pas d'importateur Opsgenie. Les outils de migration de versions couvrent PagerDuty et Grafana OnCall OSS. N'appliquez pas leurs garanties d'importation à une exportation Opsgenie.
- Personnes et plannings : recréez des équipes, des adhésions, des rotations, des restrictions de temps et des remplacements. Comparez le répondeur réellement affecté sur un cycle complet, y compris les week-ends et les changements d'heure d'été.
- Intégrations et déduplication : inventoriez chaque expéditeur, son authentification et son identité d'alerte. Utilisez une intégration IR compatible ou mappez les événements au contrat de webhook générique. Une clé ou une charge utile Opsgenie API n'est pas automatiquement valide dans IR.
- Règles et livraison : reconstruisez intentionnellement le routage et la remontée d'informations. Configurez de nouveaux secrets, coordonnées utilisateur et canaux de notification ; ne présumez pas qu’un horaire copié peut informer quiconque.
- Historique et automatisation : conservez séparément les enregistrements requis ainsi que les scripts d'inventaire, les API clients, les liens de ticket et les actions de réponse. La recréation de configuration n'importe pas l'historique des incidents et n'assure pas la compatibilité Opsgenie API.
IR 2.3 sépare les groupes d'alerte techniques des incidents opérationnels. Un incident peut relier plusieurs AlertGroups sans fusionner leur historique technique. L'accusé de réception et l'escalade restent des préoccupations d'AlertGroup ; les intervenants et les parties prenantes sont toujours limités à AlertGroup dans cette version. Lisez les limites de gestion des incidents avant de mapper votre processus de réponse existant.
Un pilote avec un point de rollback explicite
- Enregistrez votre date limite de Opsgenie, le propriétaire de la migration et les exportations historiques requises. Si vous planifiez également une migration Atlassian, tenez compte de sa fenêtre d'accès parallèle ; ne présumez pas que l’ancien locataire restera disponible jusqu’à l’arrêt final du produit.
- Construisez une équipe représentative dans un déploiement IR test. Comparez un cycle de rotation complet, une dérogation, des délais d'escalade et le comportement lorsque le premier intervenant n'acquitte pas.
- Rejouez les événements de tir, de duplication et de récupération nettoyés. Vérifiez l'équipe sélectionnée, la clé de regroupement, le service et le canal de notification. Décidez quel système possède l’accusé de réception pendant le pilote.
- Testez la livraison sur de vrais appareils de réponse, y compris en dehors des heures d'ouverture. Utilisez Santé d'astreinte, mais vérifiez également que les messages et les appels arrivent réellement.
- Changez un expéditeur à faible risque. Conservez sa configuration précédente disponible pendant que Opsgenie reste actif et évitez les notifications de production en double. Développez-vous seulement après avoir observé un cycle d'astreinte.
Ne faites pas dépendre la restauration d'un locataire supprimé
Atlassian dit que la désactivation de Opsgenie est irréversible ; il s'arrête également automatiquement 120 jours après une migration Atlassian s'il n'est pas désactivé plus tôt. Cette fenêtre n’est pas une promesse de repli indéfini. Terminez la validation et conservez les enregistrements requis avant l’arrêt. Découvrez ce qui se passe lorsque Opsgenie est désactivé.
Commencez par un déploiement test. Si un flux de travail requis ne peut pas être reproduit ou si personne ne peut gérer la destination, résolvez cet écart avant de changer d'expéditeur de production.
Opsgenie et Jira Service Management sont des produits Atlassian. IncidentRelay n'est pas affilié à Atlassian.