une mauvaise migration de système ressemble à une passe ratée dans la surface de réparation !

Le système est-il prêt ?

Article original en Anglais « Planning System Cutovers » par Dave Nielsen

Office Workers Clapping at Office PartyL’équipe a bossé dur et construit un système qui satisfait à toutes les exigences business. Elle l’a testé et a vérifié qu’il répond à tout le jeu de normes de qualité applicables et les membres de l’équipe l’ont livré dans les temps. Maintenant vous pouvez vous asseoir et vous féliciter de l’excellent travail que vous avez fait en manageant ce projet.

Eh bien, pas tout à fait … …votre travail n’est pas terminé tant que le nouveau système n’est pas en production et la responsabilité du support transférée aux opérations. Pour y parvenir, vous devez planifier la migration parfaite.

Avant la planification de la migration il y a quelques interrogations auxquelles on doit répondre, comme:
  • “Comment le système se comportera-t-il dans l’environnement de production ?”
  • “Comment le système se comportera-t-il dans l’environnement de production ?”
  • “Le nouveau système peut-il supporter tous les utilisateurs qui doivent l’utiliser ?”

Telles sont les questions auxquelles l’on devrait répondre avant d’être prêts pour une transition en production.

Abordons ces questions dans l’ordre.

“Comment le système se comportera-t-il dans l’environnement de production ?”

SMP Test maturiteLa réponse à la première question devrait être “il s’exécutera aussi bien qu’il le faisait dans l’environnement de test”. Vous pouvez répondre avec assurance à la question parce qu’un jeu complet de tests a été exécuté dans un environnement de test qui est en tout un double de l’environnement de production hormis la présence des utilisateurs. Cet environnement est parfois appelé l’environnement de pré-production.

Le serveur qui supporte le système devrait être un clone du serveur de production. Si le système s’exécute dans un environnement distribué, tant l’hôte que le client doivent être dupliqués sur un réseau qui est un double du réseau de production.

Fréquemment nos systèmes nouveaux ou mis à jour doivent fonctionner dans un environnement qui comporte un système d’exploitation standard et du logiciel “sur étagère” supplémentaire (Off The Shelf). Les systèmes d’exploitation et le logiciel “sur étagère” dans l’environnement de pré-production devraient être le duplicata exact de ce qu’ils seront dans l’environnement de production et toutes les versions logicielles devraient être les mêmes.

Assurez-vous que toutes les corrections qui seront appliquées au système de production sont aussi appliquées à l’environnement de pré-production.

Si votre nouveau système exige une mis à jour du système d’exploitation et/ou d’un logiciel auxiliaire assurez-vous que vous installerez les mêmes sur l’environnement de production que sur l’environnement de pré-production. Tester votre système nouveau ou mis à jour sur le même matériel et le logiciel que ceux sur lesquels il fonctionnera dans l’environnement de production est une partie critique des tests. Fréquemment le logiciel se comportera différemment selon la combinaison de matériel/OS sur laquelle il fonctionne. Le système peut fonctionner sur la nouvelle combinaison, mais se comporter différemment selon l’environnement; donc une série complète de tests devrait être utilisée pour tester dans l’environnement de pré-production.

“Comment le système se comportera-t-il dans l’environnement de production ?”

data hard diskLa plupart des systèmes exigent de nos jours que des informations soient stockées et récupérées. Cela peut être minimal, comme un jeu d’identifiants utilisateurs et de mots de passe pour la connexion d’utilisateurs, ou cela peut être l’exigence plus importante d’une grosse base de données relationnelle. Les données qui doivent être propagées depuis l’environnement de production précédent doivent être clairement identifiées et un plan de travail défini pour les capturer et les installer dans le nouveau système pendant la migration.

En attendant, les tests dans l’environnement de pré-production devraient être réalisés avec un jeu de données qui simule l’environnement de production aussi étroitement que possible. Les données devraient imiter la production dans les secteurs de la volumétrie et de la distribution. C’est d’habitude accompli dans les systèmes ayant une grosse base de données relationnelle en prenant une copie instantanée des données de production, la convertissant au nouveau format de données et la chargeant dans l’environnement de pré-production. Ce processus de conversion est critique à la migration.

Pendant la migration, le processus utiliser pour convertir et charger les données dans l’environnement de pré-productions sera répété pour transférer les données vers le nouvel environnement de production. Non seulement le processus doit être répétable, il doit être optimisé pour que le téléchargement, la conversion et le chargement se déroulent rapidement.

“Le nouveau système peut-il supporter tous les utilisateurs qui doivent l’utiliser ?”

fastVotre projet peut ou pas avoir délivré des améliorations de performance. S’il l’a fait, ces améliorations doivent être vérifiées dans l’environnement de pré-production. Si aucune amélioration de performance n’a été exigée, il devrait s’exécuter au moins aussi bien que la précédente version. Le test devrait inclure la mesure de la performance de fonctions fréquemment utilisées en temps de charge. Par exemple, si le nombre maximal d’utilisateurs que le système doit supporter est 1000, à quelle rapidité le 1000ème utilisateur est-il connecté ?

Des points de référence devraient être spécifiés dans les secteurs de la performance, de la charge et le test de stress devrait être exécuté dans l’environnement de pré-production et vérifier par rapport à ces points de référence.

C’est seulement quand tous les points de référence ont été atteints ou dépassés que vous êtes prêts pour la migration.

Les Utilisateurs sont-ils Prêts ?

Le système peut être prêt pour les utilisateurs mais est-ce que les utilisateurs sont prêts pour le système ? De nouveaux systèmes apportent les communications dans l'équipegénéralement de nouvelles fonctionnalités que la communauté métier doit utiliser pour satisfaire aux nouvelles demandes du marché, pour répondre à un besoin de réduire l’effort, pour améliorer les performances, etc.

Les utilisateurs doivent être préparés pour qu’ils puissent bénéficier du nouveau système aussitôt qu’il est activé. Toute nouvelle fonctionnalité demande généralement de former la communauté des utilisateurs, mais au-delà de cela, ils doivent savoir quand le nouveau système sera mis en œuvre. Passer au nouveau système sans notifier la communauté d’utilisateurs, même une communauté d’utilisateurs formés, aboutira à un déluge d’appels de support.

La migration exige souvent une fenêtre de temps pendant laquelle ni les nouveaux systèmes ni les vieux ne seront disponibles.

C’est particulièrement vrai des systèmes qui utilisent d’importants volumes de données. Les données doivent être gelées pour être récupérées du vieux système, converties et copiées vers le serveur du nouveau système. Les utilisateurs n’auront pas d’accès aux données pendant ce laps de temps et donc devraient être notifiés pour qu’ils puissent planifier en amont cette période d’inactivité. Migrer vers le nouveau système pendant les heures de travail normales sans notifier la communauté d’utilisateur déclenchera immanquablement un déluge d’appels de support et peut causer plus de dégâts si les délais ne sont pas respectés. Votre migration comprendra un bulletin avant la fermeture du vieux système mais votre communauté d’utilisateurs doit être informée bien en avance de ce bulletin dans votre processus de migration.

Le Plan de Migration

PM PlanLe travail qui peut être fait sans perturber l’environnement de production devrait être fait en avance de la migration. Des tâches comme des installations de matériel, des installations de base de données, des installations d’OS, des installations logicielles devraient toutes être faites en avance de la migration réelle. Le plan de migration doit identifier et prévoir toutes les activités qui doivent se produire au moment de la migration. Mettre en place de nouveaux systèmes qui remplacent des systèmes existants exigera typiquement que la migration se déroule pendant des heures creuses. Le temps nécessaire devrait être identifié dans votre plan. L’heure H marque le début de vos activités de migration. Le plan devrait inclure chaque activité à exécuter, son responsable principal et le temps alloué à cette tâche. L’identification d’un remplaçant au responsable principal vous donnera un niveau de sécurité supplémentaire .

La première tâche sera le bulletin notifiant la communauté d’utilisateurs que l’arrêt se produira à l’heure H. Vous pouvez vouloir publier plusieurs bulletins pour vous assurer que tous les utilisateurs reçoivent la notification (y compris les utilisateurs qui se connectent 30 minutes avant l’arrêt). La tâche suivante est la récupération de toutes les données de l’environnement de production. Le téléchargement, la conversion et le chargement de données devraient suivre la procédure définie pendant le test.

Il y a plusieurs façons d’approcher la migration.

Vous fournissez un nouvel environnement de production et mettez le vieux à la retraite, vous utilisez l’environnement de production existant et échangez l’environnement de production par celui de la pré-production.

L’approche que vous prenez déterminera vos étapes suivantes et sera influencée par combien d’argent l’organisation doit/peut dépenser sur le système et à quel point le système supporte une mission cruciale pour l’entreprise.

  • Fournir un nouvel environnement de production et mettre le vieux à la retraite ou échanger la pré-production et les environnements de production vous permettra d’exécuter des activités comme l’installation de matériel, les installations de base de données, les mises à jour logicielles, etc avant la migration.
  • La réutilisation de l’environnement de production existant exigera probablement que vous exécutiez ces activités pendant la migration.

Chaque activité devrait être vérifiée sur l’environnement de pré-production et mesurée pour qu’une durée raisonnable puisse être intégrée dans votre plan de migration. Puisque le but ici est de  limiter la durée d’indisponibilité, essayez de prévoir autant d’activités en parallèle que possible sans risquer l’échec. Une fois que l’environnement de production a été mis à jour vous pouvez charger les données converties.

L’étape suivante devrait être un test “de fumée” (smoke test) du nouveau système de production.

Le test devrait être assez minutieux pour assurer qu’aucune étape de migration n’a été manquée, mais rationalisé pour qu’il puisse être exécuté dans une durée relativement brève. Les connexions d’utilisateur sont toujours un bon candidat aux tests de fumée. N’importe quel travail qui est exécuté fréquemment par les utilisateurs en est un autre.

La dernière étape devra exécuter toute mise à jour de l’OS nécessaire pour rediriger les utilisateurs sur le nouveau système et notifier que le système est prêt.

Ce bulletin est aussi une occasion d’informer les utilisateurs de tous les changements du système, comme des numéros de version, de nouvelles fonctionnalités, etc. Rendez le nouveau numéro de version évident à trouver et dirigez des utilisateurs sur les documentations décrivant la mise à jour dans votre bulletin d’annonce. Arrangez-vous pour faire surveiller le nouveau système dès la migration. Puisque la plupart des migrations arrivent pendant les périodes d’utilisation non-maximale, la  surveillance devrait durer au moins jusqu’à ce que le système rencontre une situation d’utilisation maximale, par exemple le lundi matin.

NQI est Partenaire de DantotsuPM
NQI est Partenaire de DantotsuPM

Votre plan devrait toujours être testé sur l’environnement de pré-production pour vous assurer de sa complétude (c’est-à-dire toutes les activités nécessaires sont identifiées) et que les durées sont adéquates. Si l’équipe a des problèmes à réaliser une tâche à 10h00 un mardi où personne ne souffle sur leurs nuques, ils échoueront quand ils essaieront à minuit un samedi avec le le Vice Président des Opérations qui les observe.

Stratégie de Retour Arrière

L

Vous souvenez-vous j’ai mentionné qu’un test de fumée et un contrôle sont les parties essentielles du plan ? Que se passe-t-il si le test de fumée échoue ou le contrôle révèle un degré inacceptable de dégradation de système pendant l’utilisation nominale ? La réponse est: un retour arrière.

Le retour arrière rétablit le système et les données précédents sur l’environnement de production et ressemble fortement à une autre migration.

La stratégie de retour arrière dépendra de l’approche de migration utilisée. L’environnement de production doit-il être changé pour revenir en arrière ? ou est-ce que ce sera simplement une question d’installation de l’ancienne base de données dans l’environnement de pré-production et de rediriger les utilisateurs sur celui-ci ?

La stratégie de retour arrière devrait être testée avec le plan de migration pour s’assurer qu’elle fonctionne.

Cela peut sembler beaucoup de travail, d’autant plus que vous devrez probablement ramener l’environnement de pré-production à son état d’avant la migration, mais cela mérite l’effort particulièrement sur des systèmes de mission cruciale.

Et pour finir

Le plan de migration, y compris la stratégie de retour arrière, devrait être passé en revue avec des experts des migrations précédentes et le groupe de support.

supportLes experts de migrations précédentes sont une source d’informations de valeur sur ce qui marche bien ou pas dans votre organisation. Les leçons apprises sont une autre source d’informations mais les auteurs de ces leçons sont d’encore plus de valeur.

Le groupe de support portera le contrecoup principal de n’importe quelles bévues dans la planification ou l’exécution de la migration. Il devrait se sentir confortable que le plan n’a pas loupé d’étapes et que son exécution leur livrera un système supportable quand il le recevra après la migration.

Le plan de migration sera un livrable clef à la réunion de revue de jalon, ou la réunion de pré-jalon, tenue pour déterminer que vous êtes prêts pour la migration.

Le plan de migration ne semblera pas être un livrable important dans le rush pour compléter le projet dans les temps mais l’attention aux détails de ce plan en avance de la migration vaudra bien tous vos efforts.

Ne pas prêter l’attention nécessaire à ce livrable critique gâchera tout le dur labeur de l’équipe pour atteindre ce point culminant.

Peu importe comment l’équipe a bien réussi pendant le reste du projet, on se souviendra seulement du désastre au moment de la migration bien longtemps après que tout ce bon travail soit oublié. Une mauvaise migration ressemble à  une passe ratée dans la surface de réparation. L’attaquant peut avoir gagné 150m en courant, mais on se souviendra seulement qu’il a coûté la victoire à son équipe en ratant la dernière passe décisive.

Enregistrer

Enregistrer

Enregistrer

Merci de bien vouloir partager vos commentaires

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.