Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’exécution est l’endroit où les plans se transforment en réalité. Cette étape implique de préparer tout le monde pour le changement, en effectuant le travail de développement dans des environnements hors production. Vous testez soigneusement et déployez en production de manière contrôlée. L’accent est mis sur les tests rigoureux et les pratiques de déploiement sécuritaires pour réduire les perturbations de l’entreprise, étant donné que les modifications peuvent être importantes.
Préparer les parties prenantes à la modernisation
Avant d’atteindre le bouton déployer, il est essentiel de préparer toutes les parties prenantes et tous les utilisateurs pour ce qui est à venir. Les surprises peuvent entraîner une confusion ou même des problèmes opérationnels. Les principales étapes de préparation incluent la communication, les gels des modifications (mentionnés précédemment) et les plans de support :
Annoncez la planification du déploiement pour toutes les parties prenantes. À l’avance, communiquez à toutes les parties concernées lorsque le déploiement de modernisation doit se produire et ce qu’il faut attendre. Incluez les dates clés telles que le blocage des modifications et la fenêtre de mise en ligne pour aider les parties prenantes à se préparer de manière appropriée. En définissant des attentes, les utilisateurs peuvent planifier les temps d’arrêt, et les équipes internes peuvent être prêtes.
Implémentez un gel des modifications sur les charges de travail sources et dépendantes. Comme prévu plus tôt dans la gouvernance, il est maintenant temps d’appliquer le gel. Assurez-vous qu’aucune modification du code, ajustements de configuration ou autres déploiements ne se produisent sur la charge de travail (et les charges de travail dépendantes) pendant une certaine période avant et pendant le déploiement. Cela maintient l’environnement stable. Assurez-vous que tous les membres de l’équipe et tous les tiers intégrés sont conscients. Définissez clairement la fenêtre de gel avec des heures de début et de fin spécifiques pour éviter toute confusion.
Communiquez les actions des utilisateurs finaux et les modifications post-déploiement. Les utilisateurs ont besoin d’une notification préalable des actions requises avant et après le déploiement pour empêcher l’interruption du flux de travail. Demandez aux utilisateurs de se déconnecter ou d’enregistrer leur travail avant le début de la transition. Partagez de nouvelles URL d’accès, des modifications d’authentification telles que les exigences de connexion à l’ID Microsoft Entra et les flux de travail mis à jour qui affectent les opérations quotidiennes. Fournissez de la documentation de support et des guides de démarrage rapide pour réduire la confusion le premier jour.
Coordonner le personnel de soutien pour le déploiement. Les équipes informatiques et de développement doivent être disponibles pour surveiller et répondre aux problèmes pendant les phases de déploiement critiques. Planifiez des heures de support prolongées et d’autres employés pour le premier jour ouvré après le déploiement lorsque les problèmes sont susceptibles d’apparaître. Informez les unités commerciales du plan de support post-déploiement et des procédures d’escalade pour garantir une résolution rapide des problèmes.
Définissez des procédures de secours pour les charges de travail critiques. Les charges de travail critiques nécessitent des solutions de contournement manuelles et des plans d’urgence pour maintenir les opérations métier pendant les fenêtres de déploiement. Documentez les procédures spécifiques, telles que le traitement manuel des commandes pendant les périodes en lecture seule des charges de travail. Partagez ces procédures à l’avance et confirmez la préparation avec les équipes concernées pour garantir une exécution transparente si nécessaire.
Développer des modernisations dans un environnement hors production
Tous les changements de développement et d’intégration des changements de modernisation doivent se produire en dehors de la production (dans les environnements de développement, de test, de préproduction). Principe directeur : construire et tester dans des environnements proches de la production, afin que le déploiement en production repose sur un périmètre déjà connu.
Suivez les principes Well-Architected Framework pendant l’implémentation. Lors du codage et de la configuration des nouveaux changements, appliquez en continu les bonnes pratiques issues du cadre Well-Architected Framework (WAF) d'Azure. Utilisez des recommandations Azure Advisor et des processus de révision architecturale pour valider les décisions de conception. Cette approche garantit que les composants modernisés répondent aux meilleures pratiques et aux normes opérationnelles Azure.
Créez des environnements hors production qui reflètent la production. Faire tourner les environnements de développement/test dans Azure qui sont aussi proches que possible de la configuration de production. Si la production utilise certains services Azure, utilisez les mêmes services dans le test, à une échelle plus réduite ou à un niveau de performance inférieur (SKU) pour réduire les coûts. Plus votre environnement de test est proche de la production, plus vous pouvez être sûr que les résultats des tests doivent passer au comportement de production.
Implémentez les modifications de manière incrémentielle avec le contrôle de code source et CI/CD. Traitez l’effort de modernisation comme tout autre projet logiciel. Utilisez Git ou un autre contrôle de code source pour toutes les modifications de code et l’infrastructure en tant que scripts de code. Il fournit l’historique et la possibilité d’annuler des modifications de code si nécessaire. Décomposez le travail en petits blocs (peut-être par fonctionnalité ou correctif) et utilisez des branches de fonctionnalités. Fusionnez les changements fréquemment après revue de code. Configurez des builds d’intégration continue pour exécuter vos suites de test sur chaque validation, afin de détecter les problèmes au début.
Valider les modifications de modernisation avec les tests
Les tests sont essentiels. Étant donné que la modernisation n’ajoute pas de nouvelles fonctionnalités, le focus est mis sur les tests de régression (rien de cassé) et les tests de performances/sécurité (il fonctionne mieux qu’auparavant, pas pire). Vous souhaitez vérifier chaque aspect de la charge de travail dans l’environnement de test avant de toucher à la production.
Exécutez des tests unitaires et d’intégration sur tous les composants modifiés. Les développeurs doivent créer ou mettre à jour des tests unitaires pour tout code refactorisé. Même si c'est un code hérité, l'écriture de tests unitaires pour les fonctions critiques peut aider à détecter si la refactorisation a modifié le comportement par inadvertance. Exécutez les tests unitaires dans votre pipeline CI en continu. En outre, exécutez des tests d’intégration pour vous assurer que les composants communiquent correctement les uns avec les autres. Après tout correctif de bogue, réexécutez les tests pertinents pour vous assurer que le bogue est effectivement résolu et rien d’autre n’est rompu (évitez les régressions).
Effectuez des tests fonctionnels de bout en bout. Dans un environnement intermédiaire ou de test, effectuez des tests de flux de travail complets comme si vous êtes un utilisateur final. Ce test peut être des tests manuels par des tests d’interface utilisateur automatisés ou d’assurance qualité. Connectez-vous à l’application, effectuez des tâches majeures. Vérifiez que les fonctionnalités inchangées restent inchangées. En gros, simuler une utilisation réelle pour détecter ce que les tests unitaires pourraient manquer.
Effectuez des tests d’acceptation utilisateur (UAT) avec les parties prenantes. Il est judicieux d’impliquer des utilisateurs finaux réels ou des parties prenantes de l’entreprise dans le test de la charge de travail modernisée avant de passer en ligne. Ils peuvent intercepter des nuances que les développeurs ignorent. Capturez des commentaires sur la facilité d’utilisation, les performances et les lacunes de fonctionnalités. Résolvez les problèmes de test d’acceptation des utilisateurs critiques (UAT) avant le déploiement et obtenez une approbation formelle auprès des parties prenantes pour confirmer la préparation de l’entreprise.
Validez les performances à l’aide de tests de charge dans des conditions réalistes. La modernisation devrait idéalement améliorer ou maintenir les performances. Utilisez des outils de test de charge (tels qu’Azure Load Testing) pour simuler des modèles d’utilisation réalistes. Comparez les résultats par rapport aux bases de référence des performances de l’environnement source pour identifier toute dégradation. Effectuez des tests de contrainte à 150% de charge attendue pour déterminer les limites de charge de travail et valider la résilience sous pression.
Exécutez des vérifications de validation et de conformité de sécurité. Exécutez des analyses de vulnérabilité sur de nouvelles images de code et de conteneur pour détecter les risques de sécurité. Effectuez une validation de conformité pour les charges de travail réglementées à l’aide d’outils spécifiques au secteur. Utilisez Microsoft Defender pour Cloud pour analyser les configurations incorrectes de l’infrastructure et valider les contrôles de sécurité répondent aux exigences.
Résolvez tous les problèmes critiques avant le déploiement de production. Corrigez les problèmes fonctionnels, de performances et de sécurité identifiés pendant les phases de test. Vérifiez que tous les tests réussissent et que les performances répondent aux contrats de niveau de service (SLA). Documentez les problèmes restants de faible priorité et créez des plans de correction pour la résolution après le déploiement.
Créer une infrastructure réutilisable
Une fois que votre solution modernisée réussit tous les tests dans l’environnement hors production, vous devez capturer la configuration et les configurations de l’infrastructure en tant que code, afin qu’elle puisse être facilement répliquée dans les environnements de production et futurs. L’infrastructure réutilisable signifie utiliser des modèles IaC (Infrastructure-as-code) et une automatisation pour la cohérence et la vitesse.
Créez des modèles IaC pour des configurations éprouvées. Prenez l’architecture finale de votre environnement de test (qui reflète ce que vous voulez en prod) et codifiez-la. Utilisez des modèles Bicep, Terraform ou Azure Resource Manager pour définir votre infrastructure. Paramétrez ces modèles afin qu’ils puissent être réutilisés pour différentes phases, comme le développement, le test, la production avec de petits ajustements tels que des noms ou des tailles. Cette configuration garantit que l’environnement de production que vous créez correspond à ce que vous avez testé. Il évite l’erreur humaine en cliquant manuellement sur le portail Azure pour créer des ressources. Cela signifie également que si vous avez besoin de recréer l’environnement, comme pour la récupération d’urgence ou le déploiement dans de nouvelles régions, vous disposez du déploiement de l’infrastructure prêt. Pour plus d’informations, consultez CAF Manage - Gérer les déploiements basés sur du code.
Stocker des modèles dans le contrôle de version. Vérifiez votre code d’infrastructure dans un référentiel Git (en même temps que le code de l’application ou dans un référentiel distinct). Utilisez GitHub ou Azure DevOps pour gérer les ressources IaC avec un contrôle de version approprié. Le contrôle de version permet des révisions de code, prend en charge la collaboration d’équipe et encourage la réutilisation des modèles dans les projets. Cette approche offre une traçabilité complète des modifications d’infrastructure et prend en charge les fonctionnalités de restauration lorsque des problèmes se produisent.
Automatisez l’installation et la configuration des dépendances. Créez des scripts ou des tâches de pipeline pour déployer ces modèles et gérez également toutes les tâches de configuration ou d’amorçage requises. Utilisez Azure Pipelines, GitHub Actionspour exécuter des travaux de déploiement qui prennent le modèle IaC et déploient sur un abonnement/groupe de ressources cible. Automatisez l’installation des dépendances d’application, la configuration des paramètres et la gestion des secrets. L’objectif est la configuration de l’environnement en un clic (ou une commande) : de rien à un environnement entièrement en cours d’exécution qui correspond à ce que vous avez testé.
Testez l’iaC et l’automatisation de bout en bout. Utilisez un abonnement Ou un groupe de ressources Azure distinct en tant que bac à sable et pratiquez le déploiement de votre environnement entier à partir de zéro à l’aide de vos modèles et scripts. Testez la capacité de vos modèles, pipelines et scripts IaC à créer une pile d’infrastructure complète à partir de zéro. Testez différents scénarios de déploiement, notamment le déploiement initial, les mises à jour de configuration et les procédures de restauration pour confirmer que l’automatisation fonctionne correctement.
Pour plus d’informations, consultez Concevoir une gestion de la chaîne d'approvisionnement pour le développement des charges de travail et Infrastructure en tant que code dans WAF.
Créer une documentation de déploiement
Même avec l’automatisation, avoir une bonne documentation autour des déploiements est cruciale pour l’audit, pour l’intégration de nouveaux membres d’équipe et pour une maintenance future. La documentation de déploiement doit couvrir les configurations, les procédures et les étapes de restauration sous forme lisible par l’homme.
Documenter les paramètres de configuration et les étapes. Enregistrez tous les paramètres spécifiques à l’environnement, les chaînes de connexion, les points de terminaison de service et les configurations de sécurité dans la documentation accessible. Incluez des instructions de déploiement pas à pas, des conditions préalables requises et des étapes de validation post-déploiement. Cette documentation permet des déploiements cohérents et prend en charge la résolution des problèmes lorsque des problèmes se produisent. Si un nouvel ingénieur devait déployer, il pourrait lire ce document et suivre ou comprendre les résultats du pipeline.
Mettre à jour les procédures d'annulation et de récupération. Une fois vos tests terminés, formalisez les étapes permettant de rétablir les modifications lorsque des problèmes de déploiement se produisent. Incluez les déclencheurs de restauration, les procédures de sauvegarde et de restauration des données et les étapes de validation de récupération. Testez régulièrement les procédures de restauration et de récupération pour s’assurer qu’elles fonctionnent correctement si nécessaire. Cette préparation réduit les temps d’arrêt.
Collectez toutes ces documentations dans un emplacement central. Utilisez SharePoint, GitHub ou un wiki pour stocker ces informations. Assurez-vous que l’équipe et le personnel du support technique savent où le trouver. Lors d'un incident très stressant, avoir des documents clairs à portée de main est une bouée de sauvetage.
Déployer la modernisation
Le déploiement de production est le point culminant de l’effort de modernisation. Selon votre stratégie choisie (sur place ou parallèle), les étapes diffèrent. Avant d’exécuter, vérifiez à deux reprises que toutes les étapes de préparation sont effectuées : les parties prenantes sont informées, gel en vigueur, sauvegardes effectuées, surveillance en attente.
Déployer la modernisation sur place
Planifiez une fenêtre de maintenance. Si les modifications nécessitent un temps d’arrêt ou l’exécution de scripts qui verrouillent des ressources, comme une migration de schéma de base de données, effectuez-le dans une fenêtre de maintenance prédéfinie. Vérifiez que tous les utilisateurs sont hors de la charge de travail à ce moment-là. L'utilisation d'une fenêtre dégagée vous donne également un objectif pour terminer le déploiement ou décider de revenir en arrière si vous manquez de temps.
Utilisez votre pipeline CI/CD pour le déploiement. Un déploiement de production doit utiliser le même pipeline automatisé que celui que vous avez utilisé pour les tests, mais pointé vers l’environnement de production. Cette configuration garantit la cohérence, de sorte que l’infrastructure et le code se déploient de la même façon. Avant de l’exécuter, effectuez des sauvegardes finales de toutes les données critiques (bases de données). Même si vous pouvez effectuer une restauration, avoir une sauvegarde est un filet de sécurité supplémentaire en cas d’incident. Exécutez le pipeline pour déployer le nouveau code et les changements d'infrastructure. Avoir les logs et le monitoring visibles en temps réel. Si une étape échoue, suspendez-vous et évaluez si vous pouvez avancer ou s'il vous faut revenir en arrière.
Implémentez un routage progressif du trafic (canary) si possible. De nombreux services Azure permettent d’échanger des emplacements ou de déplacer le trafic progressif, même dans un scénario sur place. Azure prend en charge les déploiements de type canary via des emplacements de déploiement Azure App Service, la répartition du trafic des Azure Container Apps et le service Azure Kubernetes avec Azure Pipelines. Si plusieurs machines virtuelles se trouvent derrière un équilibreur de charge, mettez à jour une instance à la fois (mise à niveau en rotation), pendant que les autres gèrent le trafic, puis faites-les alterner.
Augmentez progressivement jusqu'à la capacité maximale tout en surveillant. Une fois la nouvelle version active, surveillez-la étroitement. Vérifiez les journaux des applications, les métriques de performances, les taux d’erreur. Commencez par une petite partie des utilisateurs (ou commencez par la charge de travail en mode de validation si possible). Si tout semble bon après quelques minutes, augmentez à environ 25 % du trafic. Vérifiez à nouveau les métriques (aucun pic de 500 erreurs, temps de réponse normal). Augmentez à 50%, puis 100% sur la période prévue. Cela pourrait être plus d’une heure ou plus si vous voulez être prudent. Si un problème grave est observé à une étape quelconque, lancez la restauration avant qu’elle n’affecte tous les utilisateurs.
Maintenir la cohérence des données pendant le déploiement. Les déploiements sur place conservent les points de terminaison de données existants tout en modifiant potentiellement les schémas de données. Appliquez les modifications de schéma de base de données de manière rétrocompatible afin de prendre en charge les anciennes et nouvelles versions de l'application pendant les déploiements progressifs. Utilisez des scripts de migration de base de données qui ajoutent de nouvelles colonnes ou tables sans supprimer les structures existantes jusqu’à ce que le déploiement se termine correctement.
Déployer la modernisation dans un environnement parallèle
Créez l’environnement de production parallèle. À l’aide des modèles IaC, créez le nouvel environnement de production dans Azure qui reflète ce que vous avez testé. Cet environnement inclut tous les calculs, la mise en réseau, le stockage. Il doit être opérationnel, mais actuellement sans trafic utilisateur. Vérifiez que les éléments tels que les groupes de sécurité réseau, les pare-feu, l’identité (identités managées ou principaux de service) et la surveillance sont toutes configurées si nécessaire (répétez essentiellement la configuration de test dans l’abonnement prod).
Mettez en place la réplication de base de données. Configurez la fonctionnalité de réplication native de votre plateforme de base de données pour établir une réplication continue des données entre votre source et votre charge de travail cible Azure. Vérifiez que la synchronisation de données initiale se termine correctement et que la réplication est saine. Vous pouvez effectuer une copie en bloc initiale de la base de données à partir de la sauvegarde ou de l’instantané, puis activer la réplication pour les nouvelles transactions. Surveillez le décalage dans la réplication à l’aide des outils de supervision de votre plateforme de base de données. Une latence élevée augmente les risques et la durée du basculement. Ne passez pas à l’étape suivante tant que le décalage de réplication n’est pas égal à zéro.
Copiez des données et des fichiers non structurés. Copiez des données et des fichiers non structurés dans Azure avant le basculement final. Utilisez Outils pour la migration d’objets et de fichiers avec des fonctionnalités pour transférer des fichiers vers les services de stockage Azure appropriés. Cette préparation réduit la quantité de données qui doivent être copiées pendant la transition finale.
Terminer la synchronisation finale des données. Au moment du basculement, vous souhaitez zéro ou une perte de données minimale. Pour les bases de données, vérifiez qu'aucune transaction en attente ne reste sur les charges de travail source et que la réplication est à jour. Dans certains cas, vous devrez peut-être suspendre brièvement les écritures sur la base de données source pour vider les modifications finales (en particulier pour des éléments tels que la cohérence transactionnelle). Vous pouvez utiliser des techniques telles que l'expédition de journaux de transaction ou une courte interruption pour effectuer une dernière restauration de sauvegarde incrémentielle. Copiez les données non structurées modifiées à l’aide d’AzCopy ou d’un outil similaire.
Réduisez progressivement le trafic utilisateur vers le nouvel environnement. Mettez à jour les enregistrements DNS et les configurations d’équilibreur de charge pour diriger le trafic utilisateur vers l’environnement Azure. Surveillez l'intégrité et les performances des charges de travail. Commencez par 1% du trafic actif dirigé vers la charge de travail modernisée à l’aide du routage pondéré avec votre équilibreur de charge Azure. Surveillez les métriques en temps réel, notamment les temps de réponse, les taux d’erreur et l’intégrité de la connexion de base de données. Augmentez le trafic par incréments rapides (5 %, 15 %, 50 %) en quelques minutes plutôt qu'en quelques heures, avec des déclencheurs de retour en arrière automatisés si des seuils sont dépassés.
Effectuez le changement final vers 100%. Une fois que vous êtes confiant, routez tous les utilisateurs vers le nouvel environnement. Ce changement peut être un basculement DNS, ce qui peut prendre des secondes à quelques minutes si la valeur du time-to-live (TTL) était faible, ou une modification de la configuration de l'équilibreur de charge. À ce stade, les utilisateurs sont opérationnels sur le système modernisé.
Vérifiez et surveillez immédiatement après le basculement. Passez en revue vos vérifications post-basculement. Effectuez des tests fonctionnels de bout en bout de tous les processus métier critiques à l’aide de suites de tests automatisées. Validez l’exactitude des données à l’aide de la vérification par somme de contrôle et des comparaisons de fonctions de hachage entre les charges de travail source et cible. Les propriétaires de charge de travail doivent confirmer que toutes les fonctions principales fonctionnent correctement. Surveillez les performances de la charge de travail, les taux d’erreur et les modèles d’accès utilisateur pour les 24-48 premières heures après le basculement pour identifier les problèmes de dégradation ou de fonctionnalité des performances.
Maintenez l'ancien environnement actif (serveur de secours) pendant un certain temps. Ne déchirez rien encore. Il est judicieux de garder l’ancienne charge de travail en veille à chaud pendant au moins 24 à 72 heures, avec une synchronisation continue des données si possible (ou prête à être synchronisée rapidement). Si un problème critique imprévu survient en production, vous pouvez toujours décider d'effectuer un retour arrière en redirigeant le trafic. La perte de données devrait être minimale, car vous pourrez rattraper via les journaux ou d'autres moyens.
Valider la réussite de la modernisation
Maintenant que la nouvelle charge de travail est active, vous devez valider en production que tout fonctionne comme prévu et répond aux critères d’acceptation.
Confirmez la réussite de l’accès utilisateur et des performances de la charge de travail. La validation de l’accès utilisateur garantit que la modernisation est transparente et que les performances répondent aux attentes. Cette confirmation valide que les utilisateurs peuvent accéder à la charge de travail sans interruption. Surveillez les modèles d’accès utilisateur, les métriques de performances de charge de travail et les taux d’erreur pendant la période initiale après la migration.
Annoncez la réussite de la migration uniquement après une validation approfondie. La validation complète garantit que toutes les parties prenantes vérifient que la charge de travail est stable et fonctionnelle. Cette confirmation empêche les déclarations prématurées de succès susceptibles d’entraîner des problèmes ultérieurement. Obtenez la confirmation des propriétaires, des testeurs et des parties prenantes métier que la charge de travail répond à toutes les exigences et fonctionne correctement.
Prise en charge du volume de travail pendant la phase de stabilisation
Même après un lancement réussi, planifiez une période de stabilisation où vous accordez une attention supplémentaire à la charge de travail. Les charges de travail récemment modernisées peuvent présenter des problèmes inconnus qui apparaissent uniquement sous des modèles d’utilisation réels après un certain temps.
Établir une couverture améliorée du soutien pendant la période de stabilisation. Pendant les premiers jours ou semaines (en fonction de la complexité) après la mise en service, mettez en œuvre un protocole de support intensif. Assignez du personnel informatique expérimenté ou des partenaires de migration pour surveiller étroitement la charge de travail et fournir des SLA plus courts que les opérations habituelles.
Mettez à jour votre documentation opérationnelle et vos outils. Vérifiez que tous les runbooks, documents de support et configurations de surveillance sont mis à jour pour refléter la nouvelle réalité. Former l’équipe des opérations sur toutes les nouvelles procédures telles que les nouveaux processus de sauvegarde, les nouvelles procédures de redémarrage pour les microservices. Transférez la charge de travail modernisée aux équipes ops/support avec un transfert de connaissances complet. Assurez-vous que votre inventaire des ressources/CMDB enregistre les nouveaux serveurs, adresses IP, services et supprime ou marque les serveurs hérités.