Erreurs courantes à éviter lors de la migration

Pour les entreprises, la possibilité de migrer des milliers d'applications est inévitable pour rester compétitives. Comprendre comment réussir une migration fait peur alors plongeons dans les pièges à éviter.

COVID-19 a créé à la fois une pénurie de talents techniques combinée à une augmentation de la demande de délais techniques accélérés. De nombreuses entreprises commencent à faire face à un effet « Red Queen », où les entreprises doivent redéfinir comment et où elles se font concurrence sur le marché pour s'assurer qu'elles restent pertinentes. Aujourd'hui, les entreprises qui restent complaisantes sont récompensées par un désavantage mordant et un cycle de rattrapage perpétuel. Les migrations des technologies en place vers des solutions plus réactives et plus rentables constituent une partie importante de la métamorphose de toute entreprise ; cependant, il peut être semé d'embûches pour les non préparés.

Selon une étude du Boston Consulting Group en 2020, qui comprenait 825 cadres supérieurs dans 70 entreprises impliquant 895 transformations numériques, seulement 30 % des transformations ont atteint leurs objectifs de transformation.

Ce ne sont pas des chiffres pour inspirer confiance. Heureusement, des entreprises comme Stark & Wayne ont travaillé pour permettre plusieurs migrations d'entreprise afin que d'autres puissent les éviter. Stark & Wayne est un expert de la migration d'infrastructures à l'échelle de l'entreprise. Les projets antérieurs ont inclus des déploiements Cloud Foundry Foundation qui gèrent 45 000 instances d'application.

Documenter une référence de performance

C'est un mandat ! Chaque entreprise exige de meilleures performances, mais beaucoup manquent de mesures de performances de base ou de moyens de mesurer ce que signifient de meilleures performances. Les performances sont-elles liées à l'expérience de l'utilisateur final ? Les performances sont-elles basées sur l'augmentation et la réduction des charges de travail pour réduire la consommation ? Les performances sont-elles mesurées en temps réduit de déploiement ou de mise à niveau ? Une fois que vous avez établi comment vous allez mesurer les performances, vous pouvez les lier à vos applications, vos clients et votre entreprise.

Cela vous permettra d'évaluer si les applications sont sous-performantes pendant et après la migration. Il aide également à gérer les perceptions lors d'un changement important et aide à quantifier le succès. Vous devrez comparer vos plates-formes pré- et post-migration avec des charges de travail similaires. Ce que vous mesurez dépend des besoins de l'entreprise, mais certaines mesures génériques sont :

• Temps de fonctionnement des composants
• Temps de réponse des applications
• Temps d'exécution globaux de l'application
• Tester les applications pour valider la connectivité des composants et l'accessibilité des services
• Métriques API (chargement de la page, utilisation de la mémoire, processeur, performances du serveur)
• Charge de sortie du journal
• Charge de signalement des incidents au fil du temps
• Automatisation (et traiter l'automatisation comme un citoyen de première classe car elle améliorera les performances globales)
• Modifications des coûts opérationnels dues à la migration et à l'automatisation des tâches
• Testez avec des types d'application qui modélisent votre environnement.

De bons tableaux de bord : vous ne pouvez pas migrer ce que vous ne trouvez pas

La plupart des organisations savent ce qu'elles prennent en charge actuellement, mais doivent identifier ce qu'elles souhaitent prendre en charge après la migration. Il est facile de connaître le nombre d'instances d'application, car votre fournisseur vous facture probablement en fonction de cette métrique. Néanmoins, vous devrez également connaître le nombre d'applications, les équipes qui prennent en charge les applications, les interdépendances entre les applications et les types de services consommés par chaque application. L'identification de ces variables vous aidera à déterminer comment vous pouvez à la fois migrer et prendre en charge le nouvel environnement.

Lors de la cartographie des propriétaires de chaque application, il est essentiel d'identifier ceux qui ont des scripts de test automatisés pour valider le fonctionnement de l'application. Idéalement, chaque application dispose de scripts de test automatisés, mais à tout le moins, vous devez disposer d'un mappage des propriétaires d'applications. En outre, vous devrez rechercher les applications inutilisées et non maintenues. La dernière chose que vous voulez faire est de migrer une application non fonctionnelle (nous avons vu cela se produire) lorsque l'application doit être supprimée ou corrigée avant la migration. Un nombre surprenant de fois, vous constaterez qu'il n'existe pas de mappage principal des propriétaires d'applications, ce qui soulève des problèmes pendant et après la migration.

Ainsi, l'accent est mis sur "l'inventaire, l'inventaire, l'inventaire", car de nombreuses entreprises n'ont pas d'emplacement central qui répertorie qui possède chaque application, ce que chaque application a ou fait, et quel est l'impact commercial de l'application. La capacité d'interroger et de trouver rapidement des informations pertinentes est vitale pour les opérations, l'efficacité et la prise de décision commerciale.

Où commencer? Tout d'abord, répondez aux questions plus larges :

• Dans quelles régions courez-vous et pourquoi ?
• Quelles applications sont exécutées dans chaque région ?
• Quels services chaque application utilise-t-elle dans chaque région ?
• Quelle version de Linux est utilisée ?
• Quelles applications communiquent avec d'autres applications dans une région ?
• Quelles applications sont orientées client ou internes ?

La collecte de ces points de données de départ ne répondra pas à toutes les inconnues, mais ils commenceront à fournir les informations dont vous avez besoin.

Auditez ce que vous pouvez : et acceptez les inconnaissables

Peu importe à quel point vous auditez ou documentez chaque détail, il y aura des variables inconnues qui auront un impact sur les temps d'arrêt, les clients, les collègues, les dépenses et les délais. Ces inconnues ne peuvent être trouvées que lorsque l'équipe technique met la main à la pâte avec le processus de migration. Voici comment vous pouvez les soutenir :

• Ajouter une chronologie pour les inconnues
• Avoir plus de ressources disponibles pour aider lorsqu'un élément inconnu crée un problème
• Soyez flexible avec les politiques de l'entreprise, les réunions internes et le déploiement de nouvelles fonctionnalités
• Avoir des plans de sauvegarde en place tels que des restaurations si les tests échouent
• Concentrez-vous d'abord sur les petites victoires pour prendre de l'élan tout en planifiant les grandes. N'oubliez pas que des gains rapides tangibles peuvent aider le moral tant qu'ils n'entraînent pas de frais généraux opérationnels supplémentaires.

La méthode préférée consiste à entreprendre un audit complet et à documenter les structures et les relations organisationnelles et à les utiliser comme référence tout au long du travail. Une fois le projet lancé, cette documentation deviendra votre carte et vous aidera à éviter de déprioriser ou de mettre des éléments en attente. Vous constaterez peut-être qu'une escalade vers la haute direction peut être nécessaire pour hiérarchiser les actions que vous devez faire passer. Néanmoins, la préférence devrait être de comprendre comment les équipes individuelles fonctionnent et d'établir une bonne communication avec elles plutôt que de passer par-dessus leurs têtes.

Sécurité : Invitez l'équipe SecOps à déjeuner

Nous ne voulons pas dire cela dans le genre Tony Soprano « Emmenez-les faire un tour » ; nous voulons vraiment dire inviter l'équipe de sécurité à déjeuner pour établir une relation face à face. L'équipe de sécurité est essentielle au processus de migration pour restreindre, assouplir ou fournir des solutions de contournement pour les bloqueurs qui surviennent. Vous avez également besoin de leur examen rapide de tout nouveau logiciel requis pour réussir votre migration. Une équipe de sécurité négligée sera un bloqueur. Regardons les choses en face avec une autre terrible analogie de film, la sécurité ne veut jamais être le chevalier noir de Monty Python criant : "Aucun ne passera !" mais ils veulent vraiment jouer le rôle vital de garder tout en sécurité. En fin de compte, la sécurité veut permettre à tout le monde au sein de l'organisation tant qu'il existe des directives appropriées. Si vous les impliquez tôt, vous éviterez les maux de tête lorsque la sécurité est mise en place à la dernière minute.

Résistez au fluage de la portée : c'est une très bonne idée… pour l'année prochaine

La dérive de la portée doit être gérée avec soin. Toutes les organisations veulent résoudre leurs problèmes simultanément, mais vous devez vous concentrer sur la résolution d'un problème très spécifique. Prenant l'exemple du passage de Pivotal Cloud à l'open source Cloud Foundry, les principaux points forts de Cloud Foundry sont les nombreuses fonctionnalités qui peuvent être ajoutées et le potentiel de personnalisation. Par exemple, l'amélioration de la posture de reprise après sinistre et des sauvegardes peut être tentante, mais la création d'une portée supplémentaire crée des problèmes supplémentaires.

La dérive de la portée crée également un problème où quelque chose peut se casser, et vous ne pouvez pas être sûr si la rupture a été causée par l'objectif global de votre projet ou la portée supplémentaire.

Mise en miroir : faire correspondre le monde que vous voulez laisser derrière vous

Une fois que vous avez établi les paramètres de votre projet et les résultats souhaités, vous devez vous assurer que vous avez mis en miroir tous les environnements qui seront migrés. Cela inclut votre environnement d'exploitation ou «terrain de jeu», où vous prouverez tout avant, en passant à la non-production et enfin à la production.

Lors de la création de l'environnement de terrain de jeu, vous voudrez vous assurer que la technologie en place, dans notre exemple Pivotal, est identique à votre environnement de non-production. Cela vous permettra d'être plus sûr que vous rencontrerez moins de problèmes.

Questions de gestion : faites-vous des amis haut placés

Vous aurez besoin du soutien de la direction, alors ne brossez pas un tableau entièrement rose. Les migrations ont un long chemin devant elles. Déplacer la plate-forme est une chose, mais vous devez également gérer tous les services. La direction doit connaître votre approche de la migration et votre plan pour atténuer les risques commerciaux. La direction sera nerveuse car les migrations pourraient affecter le résultat net, vous devez donc discuter de toutes vos mesures pour éviter cela.

Bien échouer : en faire un succès

L'échec est bon, l'échec est grand et l'échec doit être attendu tant que vous mettez en œuvre les leçons apprises la prochaine fois. Vous ne pouvez pas tout expliquer, et les échecs perçus se produisent lorsque les inconnues deviennent un blocage. Faire savoir à la direction qu'il y aura des échecs évitera, espérons-le, les connotations négatives et améliorera le moral général. En fait, vous devez célébrer les apprentissages de l'échec parce que vous faites des progrès. Pour vendre que l'échec est acceptable, vous avez besoin d'un plan de repli clair. Faites en sorte que cela fasse partie de la planification de votre journée de migration avec des points de décision go/no go pour revenir en arrière.

Les frais de licence et les risques sont les principaux moteurs de la migration vers Open Source Cloud Foundry ou Kubernetes. Pour les grandes organisations exécutant des milliers d'applications, les enjeux sont critiques. Avec la demande croissante d'évolutivité et la pénurie de développeurs, les migrations semblent risquées. La principale préoccupation est d'éviter l'impact sur les équipes d'application et d'éviter les temps d'arrêt. La bonne nouvelle est que Stark & Wayne a effectué de nombreuses migrations réussies à l'échelle de l'entreprise qui ont respecté un impact minimal sur les développeurs et des temps d'arrêt limités aux fenêtres de contrôle des modifications.

En tenant compte de ces erreurs courantes que nous avons rencontrées, votre prochain projet est moins susceptible de faire partie de ces 70 % que Boston Consulting Group suggère de ne pas obtenir ce qu'ils attendent.

Également publié ici .