AWS Systems Manager Incident Manager n'est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour plus d'informations, consultez [AWS Systems Manager Incident Manager la section Modification de la disponibilité](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-availability-change.html).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# AWS Systems Manager Incident Manager changement de disponibilité
Après mûre réflexion, AWS a pris la décision de ne plus accepter de nouveaux clients dans AWS Systems Manager Incident Manager à compter du 7 novembre 2025 et n'ajoutera plus de nouvelles fonctionnalités ou capacités à Incident Manager à l'avenir. AWS continuera à investir dans la sécurité et la disponibilité d'Incident Manager, et les clients existants d'Incident Manager pourront continuer à utiliser le service normalement dans les comptes où Incident Manager est déjà activé.
Comme Incident Manager n'ajoutera plus de nouvelles fonctionnalités ou capacités, il est important que vous compreniez les alternatives qui s'offrent à vous en matière de gestion des incidents. Pour plus d'informations sur les alternatives, consultez[Guides de migration](migration-guides.md).
Lors de la migration d'Incident Manager vers une autre solution, nous vous recommandons d'exporter les données de l'incident pour une analyse plus approfondie ou à des fins d'archivage. Pour de plus amples informations, veuillez consulter [Exportation des données d'Incident Manager](export-data.md).
Une fois votre migration terminée, nous vous recommandons également de nettoyer les ressources restantes du gestionnaire d'incidents afin d'éviter tout frais récurrent. Pour de plus amples informations, veuillez consulter [Nettoyage des ressources du gestionnaire d'incidents](migration-cleanup.md).
Pour obtenir une assistance supplémentaire, vous pouvez contacter votre responsable de compte technique ou [créer un dossier d'assistance dans le centre de support](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) du AWS Management Console.
# Guides de migration
Comme il n'y AWS Systems Manager Incident Manager aura plus de nouvelles fonctionnalités ou capacités, il est important que vous compreniez les alternatives qui s'offrent à vous en matière de gestion des incidents. Cette section fournit des guides de migration pour vous aider à passer d'Incident Manager à des solutions alternatives.
Pour gérer les problèmes opérationnels de votre AWS infrastructure, nous vous recommandons d'utiliser [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html). Pour les capacités de pagination et de réponse automatisées, nous recommandons les solutions proposées par les partenaires de notre [AWS réseau de partenaires](https://partners.amazonaws.com/). AWS Les architectes de solutions et les responsables de comptes techniques seront en mesure de vous guider vers l'option la plus appropriée en fonction de vos besoins spécifiques.
Vous pouvez également consulter les guides de migration suivants pour l'intégration aux solutions partenaires :
+ [Migration vers AWS Systems Manager OpsCenter](migration-opscenter.md)
+ [Migration vers Jira Service Management](migration-jira.md)
+ [Migration vers ServiceNow](migration-servicenow.md)
+ [Migration vers PagerDuty](migration-pagerduty.md)
# Migration vers AWS Systems Manager OpsCenter
Ce guide vous aide à comprendre les principales différences entre Incident Manager et OpsCenter à déterminer s'il OpsCenter répond à vos besoins opérationnels et propose des moyens de migrer OpsCenter vers AWS Systems Manager Incident Manager.
[AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html), une fonctionnalité de AWS Systems Manager, fournit un emplacement central où les ingénieurs des opérations et les professionnels de l'informatique peuvent consulter, étudier et résoudre les éléments de travail opérationnels (OpsItems) liés aux AWS ressources. OpsCenter est conçu pour réduire le délai moyen de résolution (MTTR) des problèmes ayant un impact sur AWS les ressources. OpsCenter agrège et normalise OpsItems l'ensemble des services tout en fournissant des données d'investigation contextuelles sur chacun des services OpsItem, ainsi que sur les ressources connexes OpsItems et connexes. OpsCenter s'intègre à Systems Manager Automation, ce qui vous permet d'utiliser les runbooks Automation pour étudier et résoudre les problèmes. Vous pouvez consulter des rapports de synthèse générés automatiquement OpsItems par statut et par source. Vous pouvez également utiliser [OpsCenterla fonctionnalité multi-comptes](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-setting-up-cross-account.html) pour gérer de manière centralisée OpsItems tous les comptes.
**Note**
Des frais sont associés à son OpsCenter utilisation. Reportez-vous à la [page de AWS Systems Manager tarification](https://aws.amazon.com/systems-manager/pricing/) pour plus de détails.
Semblable à Incident Manager, OpsCenter il est intégré à Amazon CloudWatch et Amazon EventBridge. Cela signifie que vous pouvez configurer ces services pour créer automatiquement un OpsItem in OpsCenter lorsqu'une CloudWatch alarme entre dans l'`ALARM`état ou lorsqu'il EventBridge traite un événement provenant d'un site Service AWS publiant des événements. La configuration des CloudWatch alarmes et EventBridge des événements pour qu'ils OpsItems soient créés automatiquement vous permet de diagnostiquer et de résoudre rapidement les problèmes liés aux AWS ressources à partir d'une console unique.
## Comprendre les différences
AWS Systems Manager Incident Manager fournit des fonctionnalités de réponse aux incidents, notamment des plans de réponse automatisés, l'engagement et l'escalade des intervenants, la gestion de la rotation sur appel, l'automatisation des runbooks, l'intégration des opérations de discussion (Slack, Microsoft Teams, Amazon Chime) et l'analyse post-incident. Ces fonctionnalités aident les entreprises à coordonner et à résoudre les incidents critiques et urgents affectant les applications AWS hébergées.
En revanche, il AWS Systems Manager OpsCenter se concentre sur la gestion des éléments de travail opérationnels (OpsItems) pour les problèmes day-to-day opérationnels tels que les alertes de sécurité, la dégradation des performances, les défaillances des ressources, les notifications de santé et les changements d'état. OpsCenter s'intègre aux AWS ressources via Amazon CloudWatch et Amazon EventBridge, permettant une OpsItem création et une correction automatisées à l'aide des runbooks Systems Manager Automation. OpsCenter prend en charge la gestion multicompte OpsItems au sein d'une région, permettant aux équipes opérationnelles de visualiser, d'étudier et de résoudre les problèmes liés à plusieurs AWS comptes. Toutefois, n' OpsCenter inclut pas les fonctionnalités de pagination ou de rotation sur appel.
Les principales différences entre ces deux AWS services résident dans leur objectif et leur portée. Le gestionnaire d'incidents est conçu pour répondre aux incidents critiques et urgents, tout en OpsCenter étant orienté vers la gestion de tâches opérationnelles et d'éléments de travail plus larges.
Le tableau suivant compare les principales fonctionnalités entre Incident Manager et OpsCenter. Utilisez cette comparaison pour déterminer si elle OpsCenter répond à vos besoins opérationnels.
| Fonctionnalité/capacité | AWS Systems Manager Incident Manager | AWS Systems Manager OpsCenter |
| --- | --- | --- |
| Objectif principal | Réponse et coordination aux incidents critiques et urgents | Day-to-day gestion opérationnelle des éléments de travail |
| Cas d'utilisation | Incidents ayant un impact sur les applications ; violations de sécurité ; pannes de service ; défaillances critiques du système | Alertes de sécurité ; Dégradation des performances ; Défaillances de ressources ; Notifications de santé ; Changements d'état |
| Pagination automatisée | Oui - Pagination intégrée et engagement du répondeur | Non - Nécessite une intégration tierce (PagerDuty, ServiceNow, Jira) |
| Gestion de la rotation sur appel | Oui - Horaires d'astreinte et rotation natifs | Non - Non pris en charge |
| Politiques d'escalade | Oui - Chaînes d'escalade automatisées | Non - Escalade manuelle requise |
| Intégration des Chat-Ops | Oui - Slack, Microsoft Teams, Amazon Chime | Limité - Intégration manuelle requise |
| Automatisation des runbooks | Oui - Exécution automatisée via des plans de réponse | Oui - Exécution manuelle des runbooks Systems Manager Automation |
| Gestion inter-comptes | Oui - Partage d'incidents entre comptes | Oui - OpsItem Gestion de comptes multiples au sein d'une région |
## Options de migration
Si vous avez déjà intégré des CloudWatch alarmes et des EventBridge règles à Incident Manager, vous devez les mettre à jour pour les intégrer OpsCenter. Vous pouvez effectuer la migration en utilisant l'une des approches suivantes :
Migration automatisée à l'aide de runbooks
Utilisez [les runbooks Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) pour migrer automatiquement vos CloudWatch alarmes et EventBridge règles d'Incident Manager vers OpsCenter. Cette approche inclut la sauvegarde, les flux de travail d'approbation configurables et la journalisation détaillée. Vous pouvez choisir d'exiger une approbation manuelle avant la migration ou de sauter l'étape d'approbation pour les migrations automatisées à grande échelle. Pour step-by-step obtenir des instructions, voir[Utilisation des runbooks de migration pour OpsCenter](migration-opscenter-runbooks.md).
Intégration manuelle
Configurez manuellement vos CloudWatch alarmes et vos EventBridge règles à intégrer OpsCenter. Pour obtenir des instructions, reportez-vous [aux sections Configuration des CloudWatch alarmes pour créer OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) et [Configuration EventBridge pour créer OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-automatically-create-OpsItems-2.html) dans le Guide de l'utilisateur de Systems Manager.
## Ressources connexes
+ [AWS Systems Manager OpsCenter Guide de l'utilisateur](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
+ [Exportation des données d'Incident Manager](export-data.md)
+ [Nettoyage des ressources du gestionnaire d'incidents](migration-cleanup.md)
# Utilisation des runbooks de migration pour OpsCenter
Ce guide fournit des step-by-step instructions pour migrer vos CloudWatch alarmes Amazon et vos EventBridge règles Amazon depuis AWS Systems Manager Incident Manager vers l' AWS Systems Manager OpsCenter utilisation de runbooks de migration automatisés.
Pour un aperçu des OpsCenter fonctionnalités et pour comprendre les différences entre Incident Manager et OpsCenter, voir[Migration vers AWS Systems Manager OpsCenter](migration-opscenter.md).
## Présentation de la migration
Le processus de migration utilise [les runbooks Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) pour intégrer vos CloudWatch alarmes et EventBridge règles existantes. OpsCenter Le processus comprend les étapes suivantes :
+ **Déployer l'infrastructure** : déployez la CloudFormation pile pour créer les ressources requises pour les runbooks de migration.
+ **Migrer les CloudWatch alarmes et EventBridge les règles** : exécutez les runbooks d'automatisation vers lesquels migrer vos ressources. OpsCenter
+ **Nettoyer les ressources** : supprimez éventuellement le jeu de réplication et les autres ressources du gestionnaire d'incidents.
**Note**
Les runbooks prennent en charge la migration pour une seule paire compte-région. Si vous disposez de ressources réparties sur plusieurs comptes ou régions, vous devez exécuter la migration séparément pour chaque combinaison compte-région.
## Étape 1 : Déployer le CloudFormation modèle
Déployez le CloudFormation modèle pour créer le rôle IAM, le compartiment Amazon S3 et la rubrique Amazon SNS requis par les runbooks de migration.
### Autorisations IAM requises
Pour déployer ce CloudFormation modèle, vous avez besoin d'autorisations IAM pour les opérations de CloudFormation stack (`cloudformation:CreateStack`,`cloudformation:DescribeStacks`), la gestion des rôles IAM (`iam:CreateRole`,,`iam:PutRolePolicy`,`iam:PassRole`)`iam:AttachRolePolicy`, la création et la configuration de compartiments Amazon S3 (`s3:CreateBucket`,`s3:PutBucket*`) et les opérations sur les rubriques Amazon SNS `sns:CreateTopic` (`sns:Subscribe`,,). `sns:SetTopicAttributes`
Pour plus de détails sur CloudFormation les autorisations, consultez la [référence CloudFormation aux autorisations](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html) dans le guide de CloudFormation l'utilisateur.
### Pour déployer le CloudFormation modèle à l'aide de la console
1. Téléchargez et extrayez le fichier [AWS- IncidentManager - MigrationResources .zip](./samples/AWS-IncidentManager-MigrationResources.zip) qui contient le `AWS-IncidentManager-MigrationResources.yaml` modèle.
1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation)
1. Sélectionnez **Créer la pile**.
1. Dans la section **Spécifier un modèle**, sélectionnez **Charger un modèle de fichier**.
1. Choisissez **Choisir un fichier**, puis sélectionnez le `AWS-IncidentManager-MigrationResources.yaml` fichier.
1. Choisissez **Suivant**.
1. Sur la page **Spécifier les détails de la pile**, entrez ce qui suit :
+ **Nom de la pile** : entrez un nom (par exemple,`im-migration-infrastructure`)
+ **ApprovalEmail**- Entrez l'adresse e-mail pour recevoir les notifications d'approbation (uniquement utilisée lorsque le paramètre RequireManualApproval runbook est défini sur true).
+ **IsPrimaryMigrationRegion**- Choisissez `true` s'il s'agit de la première région de votre compte dans laquelle vous déployez la pile, sinon choisissez `false`
1. Choisissez **Next** (Suivant).
1. Sur la page **Configurer les options de pile**, choisissez **Suivant**.
1. Sur la page de **révision**, faites défiler la page vers le bas et sélectionnez **Je reconnais que cela CloudFormation pourrait créer des ressources IAM avec des noms personnalisés**.
1. Sélectionnez **Soumettre**.
CloudFormation affiche le `CREATE_IN_PROGRESS` statut. Le statut passe au `CREATE_COMPLETE` moment où la pile est prête.
**Note**
Si vous avez des CloudWatch alarmes ou des EventBridge règles dans plusieurs régions, déployez cette CloudFormation pile dans chaque région où vous souhaitez effectuer la migration.
Pour les déploiements multi-comptes au sein d' AWS Organizations, utilisez-en deux : CloudFormation StackSets
** StackSetPrincipal** : défini IsPrimaryMigrationRegion sur true pour une région par compte
**Secondaire StackSet** : défini IsPrimaryMigrationRegion sur false pour toutes les autres régions
Pour obtenir des instructions, reportez-vous à la section [Travailler avec CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) dans le guide de CloudFormation l'utilisateur.
### Pour déployer le CloudFormation modèle à l'aide du AWS CLI
Pour la première région de votre compte, utilisez la commande suivante :
```
aws cloudformation create-stack \
--stack-name im-migration-infrastructure \
--template-body file://AWS-IncidentManager-MigrationResources.yaml \
--parameters ParameterKey=ApprovalEmail,ParameterValue=your-email@example.com \
ParameterKey=IsPrimaryMigrationRegion,ParameterValue=true \
--capabilities CAPABILITY_NAMED_IAM \
--region us-east-1
```
Pour les régions supplémentaires associées au même compte, définissez les paramètres `IsPrimaryMigrationRegion` `false` suivants :
```
aws cloudformation create-stack \
--stack-name im-migration-infrastructure \
--template-body file://AWS-IncidentManager-MigrationResources.yaml \
--parameters ParameterKey=ApprovalEmail,ParameterValue=your-email@example.com \
ParameterKey=IsPrimaryMigrationRegion,ParameterValue=false \
--capabilities CAPABILITY_NAMED_IAM \
--region us-west-2
```
Pour vérifier l'état de la pile :
```
aws cloudformation describe-stacks \
--stack-name im-migration-infrastructure \
--query 'Stacks[0].StackStatus' \
--output text
```
Attendez le retour de la commande `CREATE_COMPLETE` avant de passer à l'étape suivante.
## Étape 2 : migrer les CloudWatch alarmes et EventBridge les règles
Utilisez les runbooks Systems Manager Automation pour migrer vos CloudWatch alarmes et EventBridge règles d'Incident Manager vers OpsCenter.
### Runbooks de migration
+ [AWS- MigrateIncidentManagerCloudWatchAlarms](https://console.aws.amazon.com/systems-manager/documents/AWS-MigrateIncidentManagerCloudWatchAlarms)
+ [AWS- MigrateIncidentManagerEventBridgeRules](https://console.aws.amazon.com/systems-manager/documents/AWS-MigrateIncidentManagerEventBridgeRules)
Pour plus d'informations sur le fonctionnement de ces runbooks, y compris les descriptions détaillées des étapes, les paramètres d'entrée et les sorties, consultez la documentation des runbooks.
### Comment fonctionnent les runbooks
Les deux runbooks de migration suivent le même flux de travail :
+ **Découverte et traitement par lots** : découvre toutes les CloudWatch alarmes ou EventBridge règles configurées avec les actions du plan de réponse d'Incident Manager et les organise en lots configurables.
+ **Approbation manuelle (facultative)** : nécessite par défaut une approbation explicite avant de procéder à la migration, avec un délai d'expiration de 24 heures. Une notification Amazon SNS est envoyée à l'adresse e-mail spécifiée lors CloudFormation du déploiement. Toutes les configurations sont sauvegardées sur Amazon S3, et la liste complète des ressources à migrer est stockée pour examen manuel. Cette étape peut être ignorée en réglant la valeur RequireManualApproval sur false.
+ **Sauvegarde et migration** : si l'approbation manuelle est définie sur true, attend l'approbation, puis sauvegarde chaque configuration sur Amazon S3 et effectue la migration. Si ce paramètre est défini sur false, passe directement à la sauvegarde et à la migration.
### Paramètres d’entrée
Les deux runbooks nécessitent les paramètres suivants :
AutomationAssumeRole (Obligatoire)
L'ARN du `IM-Migration-Automation-Role` créé par la CloudFormation pile.
ApproverArn (Obligatoire)
L'ARN du rôle ou de l'utilisateur IAM qui peut examiner et approuver la migration.
S3 BucketName (obligatoire)
Nom du compartiment Amazon S3 créé par la CloudFormation pile.
SNSTopicArn (obligatoire)
L'ARN de la rubrique Amazon SNS créée par la CloudFormation pile.
MaxNumberOfAlarmsToMigrate ou MaxNumberOfRulesToMigrate (Facultatif)
Le nombre maximum de ressources à migrer en une seule exécution. Valeurs valides : 1, 5, 10, 50, 100, 500, 5000, 10000, 25000, 50000. Par défaut : 10 000
BatchSize (Facultatif)
Le nombre de ressources à traiter dans chaque lot. Valeurs valides : 25, 50, 100, 200, 250, 300, 350, 400, 450, 500. Par défaut : 100. Le runbook prend en charge un maximum de 100 BatchSize ressources par exécution.
RequireManualApproval (Facultatif)
Valeur booléenne permettant de contrôler si une approbation manuelle est requise avant la migration. Lorsque ce paramètre est défini sur true (par défaut), vous recevez un e-mail de notification Amazon SNS indiquant l'emplacement de la liste des ressources sur Amazon S3 et un lien vers la console d'exécution de l'automatisation pour approuver, refuser ou annuler. Lorsqu'il est défini sur false, le runbook se lance automatiquement après la découverte et la sauvegarde. Valeurs valides : vrai, faux. Valeur par défaut : vraie.
### Pour effectuer une migration à l'aide de la console
1. Ouvrez la console Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager.](https://console.aws.amazon.com/systems-manager)
1. Dans le panneau de navigation de gauche, sélectionnez **Automation** (Automatisation).
1. Recherchez le nom du runbook (`AWS-MigrateIncidentManagerCloudWatchAlarms`ou`AWS-MigrateIncidentManagerEventBridgeRules`).
1. Choisissez **Execute automation (Exécuter l’automatisation)**.
1. Entrez les valeurs des paramètres à partir des sorties de votre CloudFormation pile.
1. (Facultatif) Définissez **RequireManualApproval**cette option `false` si vous souhaitez ignorer l'étape d'approbation manuelle.
1. Sélectionnez **Execute (Exécuter)**.
1. S'il `RequireManualApproval` est défini sur true (par défaut), vous recevez une notification par e-mail lorsque l'exécution attend une révision manuelle. L'e-mail contient un lien d'approbation vers la page de la console d'exécution automatique. Consultez la liste des ressources dans le compartiment Amazon S3, puis approuvez, refusez ou annulez dans les 24 heures suivant le lien de l'e-mail ou la page de console. La migration n'a lieu qu'après approbation. Si ce paramètre est défini sur false, la migration se poursuit automatiquement après la sauvegarde.
1. Attendez que le statut d'exécution passe à **Success**.
### Pour effectuer une migration à l'aide du AWS CLI
**Pour les CloudWatch alarmes :**
```
aws ssm start-automation-execution \
--document-name "AWS-MigrateIncidentManagerCloudWatchAlarms" \
--parameters '{
"AutomationAssumeRole": ["arn:aws:iam::123456789012:role/IM-Migration-Automation-Role"],
"ApproverArn": ["arn:aws:iam::123456789012:role/Admin"],
"S3BucketName": ["im-migration-logs-123456789012-us-east-1"],
"SNSTopicArn": ["arn:aws:sns:us-east-1:123456789012:Automation-IM-Migration-Approvals"],
"RequireManualApproval": ["false"]
}' \
--region us-east-1
```
**Pour EventBridge les règles :**
```
aws ssm start-automation-execution \
--document-name "AWS-MigrateIncidentManagerEventBridgeRules" \
--parameters '{
"AutomationAssumeRole": ["arn:aws:iam::123456789012:role/IM-Migration-Automation-Role"],
"ApproverArn": ["arn:aws:iam::123456789012:role/Admin"],
"S3BucketName": ["im-migration-logs-123456789012-us-east-1"],
"SNSTopicArn": ["arn:aws:sns:us-east-1:123456789012:Automation-IM-Migration-Approvals"],
"RequireManualApproval": ["false"]
}' \
--region us-east-1
```
Pour consulter la liste des ressources dans Amazon S3 :
```
# For CloudWatch alarms
aws s3 cp s3://im-migration-logs-123456789012-us-east-1/review/CloudWatch/review_CW_alarms_to_migrate_123456789012_us-east-1.json ./
# For EventBridge rules
aws s3 cp s3://im-migration-logs-123456789012-us-east-1/review/EventBridge/review_EB_rules_to_migrate_123456789012_us-east-1.json ./
```
Si RequireManualApproval ce paramètre est défini sur true, consultez la liste des ressources et approuvez la migration en cliquant sur le lien d'approbation figurant dans la notification par e-mail ou sur la page de la console d'exécution automatique. Si ce paramètre est défini sur false, la migration se poursuit automatiquement après la sauvegarde.
## Étape 3 : vérifier votre migration
Une fois la migration terminée, vérifiez que vos ressources fonctionnent correctement :
+ **Déclenchez une alarme ou un événement de test** : activez l'une de vos CloudWatch alarmes ou EventBridge règles migrées pour générer une notification de test.
+ **Confirmer OpsItem la création** - Vérifiez qu'un OpsItem est automatiquement créé OpsCenter lorsque l'alarme ou l'événement se déclenche.
+ **Validez le mappage de gravité** : vérifiez que le niveau de gravité de votre configuration initiale d'Incident Manager est correctement préservé dans le OpsItem. (Applicable uniquement aux CloudWatch alarmes).
## Étape 4 : Nettoyer les ressources du gestionnaire d'incidents
Après avoir migré avec succès vos CloudWatch alarmes et vos EventBridge règles, vous pouvez éventuellement nettoyer les ressources d'Incident Manager pour vous déconnecter complètement du service.
Pour obtenir des instructions détaillées sur la suppression du kit de réplication, des plans de réponse, des contacts, des runbooks et d'autres ressources du gestionnaire d'incidents, consultez[Nettoyage des ressources du gestionnaire d'incidents](migration-cleanup.md).
### Supprimer CloudFormation des piles (facultatif)
Vous pouvez supprimer les CloudFormation piles pour supprimer le rôle IAM, la rubrique Amazon SNS et le compartiment Amazon S3 créés pour la migration.
**Important**
Le compartiment Amazon S3 contenant les sauvegardes de toutes les ressources migrées doit être vidé avant la suppression de la pile. CloudFormation Impossible de supprimer les compartiments Amazon S3 contenant des objets.
**Pour supprimer la CloudFormation pile**
```
aws cloudformation delete-stack --stack-name
```
## Surveillance et résolution des problèmes
**CloudWatch Journaux** : les activités de migration sont enregistrées dans CloudWatch Logs :
+ CloudWatch alarmes : `/aws/ssm/incidentmanager/cwmigration`
+ EventBridge règles : `/aws/ssm/incidentmanager/ebmigration`
**Structure de sauvegarde Amazon S3** : toutes les configurations sont sauvegardées sur Amazon S3 avant la migration :
```
migration-logs-{AccountId}-{Region}/
├── backups/
│ ├── CloudWatch/
│ │ └── {AccountId}/
│ │ └── {Region}/
│ │ └── {AlarmName}_backup.json
│ └── EventBridge/
│ └── {AccountId}/
│ └── {Region}/
│ └── {RuleName}_backup.json
└── review/
├── CloudWatch/
│ └── review_CW_alarms_to_migrate_{AccountId}_{Region}.json
└── EventBridge/
└── review_EB_rules_to_migrate_{AccountId}_{Region}.json
```
**Problèmes courants :**
+ **Notification Amazon SNS non reçue** (lorsque RequireManualApproval =true) - Vérifiez l'abonnement à la rubrique Amazon SNS :
```
aws sns list-subscriptions-by-topic --topic-arn
```
+ **Échec partiel de la migration** : consultez CloudWatch les journaux pour obtenir des messages d'erreur détaillés et réessayez l'automatisation avec une taille de lot réduite.
**Procédure de rétrogradation :**
Si vous devez annuler la migration :
+ Récupérez des sauvegardes depuis Amazon S3 :
```
aws s3 sync s3://im-migration-logs-123456789012-us-east-1/backups/ ./backups/
```
+ Restaurez les ressources :
```
# For CloudWatch alarms
aws cloudwatch put-metric-alarm --cli-input-json file://backups/CloudWatch/123456789012/us-east-1/MyAlarm_backup.json
# For EventBridge rules
aws events put-targets --rule MyRule --targets file://backups/EventBridge/123456789012/us-east-1/MyRule_backup.json
```
## Questions fréquentes (FAQ)
Q : Que se passe-t-il si l'automatisation expire pendant l'approbation ?
R : L'automatisation expire au bout de 24 heures si aucune approbation n'est reçue. Vous pouvez redémarrer l'automatisation avec les mêmes paramètres.
Q : Puis-je migrer des ressources d'une région à l'autre ?
R : Non. Chaque région doit être migrée séparément à l'aide d'exécutions automatisées spécifiques à chaque région.
Q : Combien de temps dure la migration ?
R : Le temps de migration dépend du nombre de ressources :
+ \$1100 alarmes/règles : 5 à 10 minutes
+ \$11000 alarmes/règles : 30 à 60 minutes
+ \$110000 alarmes/règles : 2-4 heures
Q : La sévérité est-elle préservée après la migration vers OpsCenter ?
A : Oui. La gravité configurée dans les niveaux d'impact du plan de réponse d'Incident Manager est préservée et automatiquement mappée aux niveaux de OpsCenter gravité appropriés lors de la migration des CloudWatch alarmes. Cela ne s'applique pas aux EventBridge règles.
Q : L'exécution des runbooks d'automatisation me sera-t-elle facturée ?
R : Non. Les runbooks d'automatisation de la migration n'entraînent pas de frais d'exécution. Toutefois, OpsCenter l'utilisation après la migration entraînera des frais. Pour plus de détails, consultez la documentation [tarifaire de Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
## Ressources connexes
+ [Migration vers AWS Systems Manager OpsCenter](migration-opscenter.md)
+ [AWS Systems Manager OpsCenter Guide de l'utilisateur](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
+ [Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Exportation des données d'Incident Manager](export-data.md)
+ [Nettoyage des ressources du gestionnaire d'incidents](migration-cleanup.md)
# Migration vers Jira Service Management
[Jira Service Management (JSM)](https://www.atlassian.com/software/jira/service-management/features/itsm#incident-management) est une solution de gestion des services informatiques (ITSM) qui aide les équipes à recevoir, suivre, gérer et résoudre les demandes des employés et des clients via plusieurs canaux, notamment le courrier électronique, le chat, les centres d'assistance et les widgets. Basé sur la plateforme Jira, Jira Service Management permet aux équipes de toute une organisation (du développement à l'informatique en passant par les ressources humaines) de recevoir des demandes, de répondre aux alertes et aux incidents, de déployer des modifications, de suivre les actifs, de faire ressortir les connaissances et d'automatiser les flux de travail. Jira Service Management inclut des fonctionnalités de gestion des incidents telles que la planification des appels, les alertes, la gestion des incidents majeurs, la gestion du changement et des fonctionnalités post mortem (PIR) irréprochables conçues pour les DevOps flux de travail, en tirant parti des CI/CD pipelines existants et en automatisant les tâches manuelles.
Jira Service Management s'intègre à Amazon CloudWatch et Amazon EventBridge, ce qui vous permet de créer automatiquement des alertes Jira Service Management lorsque les CloudWatch alarmes entrent dans l'`ALARM`état ou lorsque EventBridge des événements sont traités à partir d'un site Service AWS qui publie des événements. La configuration d' CloudWatch alarmes et d' EventBridge événements pour créer automatiquement des alertes Jira Service Management vous permet de diagnostiquer et de résoudre rapidement les problèmes liés aux AWS ressources depuis une plate-forme unique. Jira Service Management agit en tant que répartiteur, notifiant les bonnes personnes par le biais de multiples canaux (e-mail, SMS, appels téléphoniques, push mobile) en fonction des horaires d'appel et des politiques d'escalade.
Si vous avez déjà intégré des CloudWatch alarmes et EventBridge des règles AWS Systems Manager Incident Manager, nous vous recommandons de mettre à jour ces intégrations pour utiliser Jira Service Management à la place. La documentation officielle d'Atlassian fournit des instructions détaillées sur l'[intégration CloudWatch et l'intégration de Jira Service Management](https://support.atlassian.com/jira-service-management-cloud/docs/integrate-with-amazon-cloudwatch/) [dans Jira](https://support.atlassian.com/jira-service-management-cloud/docs/integrate-with-amazon-eventbridge/) Service Management. EventBridge
Outre la création automatique d'alertes, Jira Service Management propose une gamme de fonctionnalités permettant de rationaliser la gestion des incidents, telles que la planification des appels, les politiques d'escalade et les règles d'automatisation. Les clients peuvent consulter la documentation Atlassian suivante pour plus de détails sur la configuration de ces fonctionnalités :
+ [Découvrez les alertes et les appels](https://support.atlassian.com/jira-service-management-cloud/docs/discover-alerting-and-on-call/)
+ [Créez des horaires d'appel](https://support.atlassian.com/jira-service-management-cloud/docs/create-an-on-call-schedule/)
+ [Création de politiques d'escalade](https://support.atlassian.com/jira-service-management-cloud/docs/create-edit-delete-an-escalation-policy/)
+ [Configurez des équipes et des personnes](https://support.atlassian.com/platform-experiences/docs/start-an-atlassian-team/)
+ [Configurer les méthodes de contact](https://support.atlassian.com/jira-service-management-cloud/docs/add-contact-methods/)
+ [Configuration des règles de notification](https://support.atlassian.com/jira-service-management-cloud/docs/add-notification-rules/)
+ [Configurer les SMS et les notifications vocales](https://support.atlassian.com/jira-service-management-cloud/docs/set-up-sms-and-voice-notifications/)
+ [Configurer des règles d'automatisation](https://www.atlassian.com/software/jira/service-management/product-guide/tips-and-tricks/automation#overview)
+ [Configuration et gestion des parties prenantes en cas d'incident](https://support.atlassian.com/jira-service-management-cloud/docs/how-can-i-add-and-manage-internal-stakeholders/)
Pour obtenir une assistance supplémentaire, vous pouvez contacter votre responsable de compte technique ou [un représentant commercial Atlassian](https://www.atlassian.com/enterprise/contact) pour plus d'informations.
# Migration vers ServiceNow
ServiceNow La [gestion des incidents](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/product/incident-management/concept/c_IncidentManagement.html) est un module ITSM de base conçu pour rétablir les opérations de service normales après des interruptions imprévues tout en minimisant l'impact commercial. À l'instar d' ServiceNow Incident Manager, la gestion des incidents fournit un système structuré et automatisé permettant de visualiser, d'étudier et de résoudre les incidents informatiques, avec des fonctionnalités telles que la priorisation automatique et des processus d'escalade intégrés.
Le module ServiceNow Service Operations with Incident Management and Event Management s'intègre à Amazon CloudWatch, vous permettant de créer automatiquement des ServiceNow événements/alertes et des incidents lorsque les CloudWatch alarmes entrent dans l'`ALARM`état. La configuration d' CloudWatch alarmes pour créer automatiquement des ServiceNow incidents grâce à Webhook to AIOps Event Management vous permet de diagnostiquer et de résoudre rapidement les problèmes liés aux AWS ressources à partir d'une plate-forme unique.
Si vous avez intégré des CloudWatch alarmes existantes AWS Systems Manager Incident Manager, nous vous recommandons de mettre à jour ces intégrations pour utiliser plutôt la plateforme de [gestion des ServiceNow incidents](https://www.servicenow.com/products/incident-management.html) et de [renseignement sur les AIOps événements](https://www.servicenow.com/products/event-management.html). La ServiceNow documentation officielle fournit des instructions détaillées pour [l'intégration ServiceNow à Amazon CloudWatch](https://www.servicenow.com/docs/bundle/zurich-integrate-applications/page/administer/integrationhub-store-spokes/concept/amazon-cloudwatch.html).
Outre la création automatique d'incidents, la gestion des ServiceNow incidents propose une gamme de fonctionnalités pour améliorer la gestion des incidents, telles que la gestion des communications relatives aux incidents, la planification des appels, les politiques d'escalade, etc. Les clients peuvent consulter la ServiceNow documentation suivante pour plus de détails sur la configuration de ces fonctionnalités :
+ [Documentation sur la gestion des incidents](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/product/incident-management/concept/c_IncidentManagement.html)
+ [Gestion de la fiabilité des services](https://www.servicenow.com/docs/bundle/zurich-it-operations-management/page/product/service-reliability/reference/sr-landing-page.html)
+ [Gestion des communications en cas d'incident et contacts](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/product/incident-alert-management/concept/c_IncidentAlertContact.html)
+ [Horaires d'appel](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/administer/on-call-scheduling/concept/c_OnCallScheduling.html)
+ [Processus d'escalade](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/administer/on-call-scheduling/concept/designing-escalation-process-oncall.html)
Pour obtenir une assistance supplémentaire, vous pouvez contacter votre responsable de compte technique ou un [représentant ServiceNow commercial](https://www.servicenow.com/be/contact-us/sales.html) pour plus d'informations.
# Migration vers PagerDuty
[PagerDuty](https://support.pagerduty.com/main/docs/introduction)est une plateforme de gestion des incidents qui aide les entreprises à détecter les incidents, à y répondre et même à les prévenir. Comme Incident Manager, il PagerDuty fournit un emplacement central où les équipes opérationnelles s'occupent des tâches critiques liées aux AWS ressources, réduisant ainsi l'impact sur les clients.
PagerDuty s'intègre à Amazon CloudWatch et Amazon EventBridge, ce qui vous permet de créer automatiquement des PagerDuty incidents lorsque des CloudWatch alarmes entrent dans l'`ALARM`état ou lorsque EventBridge des événements de traitement proviennent d'un Service AWS site qui publie des événements. En configurant les CloudWatch alarmes et les EventBridge événements pour créer automatiquement des PagerDuty incidents, vous pouvez rapidement diagnostiquer et résoudre les problèmes de AWS ressources à partir d'une plate-forme unique.
Si vous avez intégré des CloudWatch alarmes et des EventBridge règles existantes AWS Systems Manager Incident Manager, nous vous recommandons de mettre à jour ces intégrations pour les utiliser à la PagerDuty place. La PagerDuty documentation officielle fournit des instructions détaillées pour [l'intégration PagerDuty CloudWatch](https://support.pagerduty.com/main/docs/amazon-cloudwatch-integration-guide) et [l'intégration PagerDuty avec EventBridge](https://support.pagerduty.com/main/docs/amazon-eventbridge-integration-guide).
Outre la création automatique d'incidents, il PagerDuty propose une gamme de fonctionnalités pour améliorer la gestion des incidents, telles que la planification des appels, les politiques d'escalade et plus de 700 intégrations de out-of-box plateformes. Vous pouvez également personnaliser les règles de notification, configurer des surfaces de discussion et tirer parti de l'IA et de l'automatisation au sein de la PagerDuty plateforme pour accélérer la résolution des incidents.
+ [Gérer les utilisateurs](https://support.pagerduty.com/main/docs/manage-users)
+ [Création d'équipes](https://support.pagerduty.com/main/docs/teams)
+ [Configurer les méthodes de contact](https://support.pagerduty.com/main/docs/contact-information)
+ [Configuration des règles de notification](https://support.pagerduty.com/main/docs/notification-rules)
+ [Configurer une rotation sur appel](https://support.pagerduty.com/main/docs/schedule-basics)
+ [Création de politiques d'escalade](https://support.pagerduty.com/main/docs/escalation-policies)
+ [Configurer l'intégration à Slack](https://support.pagerduty.com/main/docs/slack-integration-guide)
+ [Configurer des actions d'automatisation](https://support.pagerduty.com/main/docs/automation-actions)
Pour obtenir une assistance supplémentaire, vous pouvez contacter votre responsable de compte technique ou [AWS-IM-help@pagerduty.com](mailto:AWS-IM-help@pagerduty.com) pour plus d'informations.
# Exportation des données d'Incident Manager
Cette rubrique explique comment utiliser un script Python pour exporter des enregistrements d'incidents et des analyses post-incident depuis AWS Systems Manager Incident Manager. Le script exporte les données vers des fichiers JSON structurés pour une analyse plus approfondie ou à des fins d'archivage.
## Ce que vous pouvez exporter
Le script exporte les données suivantes :
+ Dossiers complets des incidents, y compris :
+ Chronologie des événements
+ Éléments connexes
+ Fiançailles
+ Exécutions automatisées
+ Constatations de sécurité
+ Étiquettes
+ Documents d'analyse post-incident publiés par Systems Manager
## Prérequis
Avant de commencer, assurez-vous d'avoir :
+ Python 3.7 ou version ultérieure installé
+ AWS CLI configuré avec les informations d'identification appropriées
+ Les packages Python suivants ont été installés :
```
pip install boto3 python-dateutil
```
## Autorisations IAM requises
Pour utiliser ce script, assurez-vous de disposer des autorisations suivantes :
Autorisations relatives aux incidents de Systems Manager
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm-incidents:ListIncidentRecords",
"ssm-incidents:GetIncidentRecord",
"ssm-incidents:ListTimelineEvents",
"ssm-incidents:GetTimelineEvent",
"ssm-incidents:ListRelatedItems",
"ssm-incidents:ListEngagements",
"ssm-incidents:GetEngagement",
"ssm-incidents:BatchGetIncidentFindings",
"ssm-incidents:ListTagsForResource"
],
"Resource": "*"
}
]
}
```
Autorisations de Systems Manager
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:GetDocument",
"ssm:GetAutomationExecution"
],
"Resource": "*"
}
]
}
```
## Structure d'exportation
Le script crée la structure de répertoire suivante pour les données exportées :
```
incident_manager_export_YYYYMMDD_HHMMSS/
├── incident_records/
│ ├── 20250309_102129_IAD_Service_A_Lambda_High_Latency.json
│ ├── 20250314_114820_SecurityFinding_SecurityHubFindings.json
│ └── ...
└── post_incident_analyses/
├── 20250310_143022_Root_Cause_Analysis_Service_A.json
├── 20250315_091545_Security_Incident_Review.json
└── ...
```
## Exécution du script d'exportation
### Utilisation de base
Le script d'exportation de données Incident Manager est fourni`[here](samples/export-incident-manager-data.zip)`. Téléchargez le script et suivez les instructions ci-dessous pour l'exécuter.
Pour exécuter le script avec les paramètres par défaut, procédez comme suit :
```
python3 export-incident-manager-data.py
```
### Options disponibles
Vous pouvez personnaliser l'exportation à l'aide des options de ligne de commande suivantes :
| Option | Description | Par défaut |
| --- | --- | --- |
| --region | AWS Région | us-east-1 |
| --profile | AWS nom du profil | Profil par défaut |
| --verbose, -v | Activer la journalisation détaillée | FALSE |
| --limit | Nombre maximum d'incidents à exporter | Aucune limite |
| --timeline-events-limit | Nombre maximal d'événements chronologiques par incident | 100 |
| --timeline-details-limit | Nombre maximal de détails chronologiques des événements par incident | 100 |
| --related-items-limit | Nombre maximum d'éléments connexes par incident | 50 |
| --engagements-limit | Nombre maximum d'engagements par incident | 20 |
| --analysis-docs-limit | Nombre maximum de documents d'analyse à exporter | 50 |
### Exemples
Exporter depuis une région spécifique à l'aide d'un profil personnalisé :
```
python3 export-incident-manager-data.py --region us-east-1 --profile my-aws-profile
```
Exportation avec journalisation détaillée et limites de test :
```
python3 export-incident-manager-data.py --verbose --limit 5 --timeline-events-limit 10
```
Exportation avec des limites prudentes pour les grands ensembles de données :
```
python3 export-incident-manager-data.py --timeline-events-limit 50 --timeline-details-limit 25
```
## Structure du fichier de sortie
### Structure JSON de l'enregistrement d'incident
Chaque fichier d'enregistrement d'incident contient la structure suivante :
```
{
"incident_record": {
// Complete incident record from get-incident-record
},
"incident_summary": {
// Incident summary from list-incident-records
},
"incident_source_details": {
"from_incident_record": {},
"from_incident_summary": {},
"enhanced_details": {
"created_by": "arn:aws:sts::...",
"source": "aws.ssm-incidents.custom",
"source_analysis": {
"source_type": "manual",
"creation_method": "human_via_console",
"automation_involved": false,
"human_created": true
}
}
},
"timeline_events": {
"detailed_events": [
{
"summary": {}, // From list-timeline-events
"details": {} // From get-timeline-event
}
],
"summary_only_events": [],
"metadata": {
"total_events_found": 45,
"events_with_details": 25,
"limits_applied": {}
}
},
"related_items": {
"items": [],
"metadata": {}
},
"engagements": {
"engagements": [],
"metadata": {}
},
"automation_executions": [],
"findings": [],
"tags": [],
"post_incident_analysis": {
"analysis_reference": {},
"metadata": {}
},
"export_metadata": {
"exported_at": "2025-09-18T...",
"region": "us-east-*",
"incident_arn": "arn:aws:ssm-incidents::..."
}
}
```
### Structure JSON d'analyse post-incident
Chaque fichier de document d'analyse contient :
```
{
"document_metadata": {
// Document metadata from list-documents
},
"document_details": {
"Name": "037fc5dd-cd86-49bb-9c3d-15720e78798e",
"Content": "...", // Full JSON content
"DocumentType": "ProblemAnalysis",
"CreatedDate": 1234567890,
"ReviewStatus": "APPROVED",
"AttachmentsContent": [],
// ... other fields from get-document
},
"export_metadata": {
"exported_at": "2025-09-18T...",
"region": "us-east-*",
"document_name": "..."
}
}
```
# Nettoyage des ressources du gestionnaire d'incidents
Si vous ne les utilisez plus AWS Systems Manager Incident Manager, nous vous recommandons de nettoyer les ressources restantes du gestionnaire d'incidents. Cela vous permettra de vous désinscrire complètement du service et d'éviter tout frais récurrent. Consultez la [page de AWS Systems Manager tarification](https://aws.amazon.com/systems-manager/pricing/) pour plus de détails.
## Suppression du jeu de réplication
Le kit de réplication est un composant clé d'Incident Manager qui facilite la réplication des données relatives aux incidents dans plusieurs AWS régions. Si vous n'avez plus besoin d'Incident Manager, vous devez supprimer le jeu de réplication.
Pour supprimer le jeu de réplication :
1. Ouvrez la AWS Systems Manager console
1. Dans le volet de navigation, choisissez Incident Manager
1. Sous « Ensembles de réplication », recherchez le jeu de réplication que vous souhaitez supprimer
1. Cliquez sur le nom du jeu de réplication pour ouvrir la page de détails
1. Sur la page de détails du jeu de réplication, cliquez sur le bouton « Supprimer »
1. Dans la boîte de dialogue de confirmation, passez en revue les informations et cliquez sur « Supprimer le jeu de réplication » pour procéder à la suppression
**Note**
La suppression du jeu de réplication supprimera définitivement toutes les données d'incident stockées dans Incident Manager. Assurez-vous de ne plus avoir besoin d'accéder aux informations historiques sur les incidents avant de procéder à la suppression.
## Supprimer des ressources liées au gestionnaire d'incidents
Outre le kit de réplication, vous pouvez disposer d'autres ressources liées à Incident Manager, telles que des plans de réponse, des contacts et des runbooks. Si vous n'avez plus besoin de ces ressources, vous pouvez envisager de les supprimer pour les déconnecter complètement d'Incident Manager.
Pour supprimer des ressources liées à Incident Manager :
1. Ouvrez la AWS Systems Manager console
1. Dans le volet de navigation, choisissez Incident Manager
1. Accédez à la section appropriée (par exemple, « Plans de réponse », « Contacts », « Runbooks ») et localisez les ressources que vous souhaitez supprimer
1. Sélectionnez les ressources et cliquez sur le bouton « Supprimer » pour les supprimer