Narration client

Effectué

Dans le module Bien Démarrer, nous avons partagé la narration relative à Tailwind Traders. L’équipe des opérations centralisées et l’équipe de la plateforme chez Tailwind Traders savent gérer les centres de données existants de l’entreprise. Le projet en cours visant à migrer deux centres de données vers Azure expose déjà quelques courbes d’apprentissage critiques que les compétences actuelles de l’entreprise ne permettent pas de traiter.

Contraintes importantes

À ce stade, l’entreprise a placé une priorité élevée sur la migration et le respect des contraintes de temps pour sortir du centre de données. En raison de cette priorité métier, les équipes métier et informatique ont dépriorisé les exigences de sécurité et de conformité à plus long terme tant qu’elles n’ont pas terminé le développement de leur plateforme cloud principale.

Étant donné que Tailwind est nouveau dans le cloud, peu de membres des équipes des opérations, de la plateforme ou de l’administration informatique ont de l’expérience dans le cloud. L’entreprise souhaite évoluer lentement vers des opérations, une sécurité et une gouvernance modernes, mais elle a toujours besoin d’une base cloud capable de s’adapter pour répondre à ces besoins à mesure qu’ils deviennent plus importants.

Jusqu’ici, Tailwind Traders a fonctionné exclusivement sous le prisme des opérations centrales. Par conséquent, les équipes de charge de travail ne peuvent pas interagir avec les environnements de production. L’entreprise n’a pas de moyen simple de mapper des ressources (machines virtuelles, données et applications) à des charges de travail définies, donc parfois les limites de chaque charge de travail peuvent ne pas être claires.

Alignement sur les zones d’atterrissage Azure

Les équipes des opérations et de la plateforme ont accepté l’alignement suivant :

• L’architecture conceptuelle des zones d’atterrissage Azure servira de projet à long terme pour l’état futur de l’environnement cloud. Toutes les équipes concernées utiliseront cette architecture comme base pour acquérir des compétences cloud et configurer leur environnement cloud.
• Les équipes utiliseront l’accélérateur de zones d’atterrissage Azure pour commencer la configuration de leur environnement.
• Si les équipes sont amenées à personnaliser leur environnement, ils utiliseront l’une des options d’implémentation personnalisées qui s’alignent sur ou étendent le déploiement initial basé sur l’accélérateur.

Écart par rapport aux instructions de zone d’atterrissage Azure standard

La liste suivante décrit comment les contraintes ont poussé Tailwind Traders à s’écarter des principes de conception des zones d’atterrissage Azure, ainsi que l’impact de chaque décision :

• Gouvernance pilotée par la stratégie : Tailwind Traders n’a jamais automatisé ses stratégies d’entreprise. En raison de la pression de migrer rapidement le centre de données, l’entreprise a choisi de réduire la quantité de gouvernance, y compris dans son déploiement initial d’une zone d’atterrissage.

  L’entreprise s’est également engagée à suivre le module Learn sur la méthodologie de gouvernance du Cloud Adoption Framework après avoir configuré l’environnement initial. Les limitations du personnel informatique dédié à la migration cloud sont un facteur important de cet écart. Cet écart est renforcé par la résistance des entreprises et des services informatiques à la gouvernance complète du cloud, ou « Azure Ops ».

• Démocratisation des abonnements : L’équipe des opérations centrales maintient la responsabilité des opérations de production pour toutes les charges de travail. Cette équipe permet rarement à une équipe de charge de travail d’avoir accès à un environnement de production, et ne respecte donc pas le principe de conception de la démocratisation des abonnements.

  Si une équipe de charge de travail doit s’écarter du principe, l’équipe des opérations centrales envisagera au cas par cas une zone d’atterrissage dédiée pour les charges de travail individuelles. Sinon, Tailwind Traders s’engage fermement à maintenir des opérations centrales et aura des instances limitées de charges de travail dans des environnements de production isolés (ou zones d’atterrissage d’applications).

• Modèle de service centré sur l’application : Les processus relatifs aux pannes peuvent prendre en compte les charges de travail, en particulier pour les ressources alimentant des charges de travail critiques. Cependant, en dehors des pannes, l’équipe des opérations centrales ne fait pas de distinction entre les charges de travail et les applications pour les processus de gestion des opérations. Les principaux processus de l’équipe fonctionnent, gèrent, changent et optimisent toutes les ressources de la même manière, quelles que soient les limites ou l’architecture des charges de travail. Étant donné les contraintes de temps de cette migration, il n’est pas possible pour Tailwind Traders de définir des limites d’application et d’établir un modèle de service centré sur l’application.

La plupart des points de la liste précédente seront expliqués dans les unités ultérieures de ce module Learn. Plusieurs d’entre eux sont reflétés dans des notes pour créer des opportunités d’apprendre.

Ces écarts n’enlèvent rien à l’alignement qu’elles ont accepté. Toutefois, ils affectent certaines options du déploiement de l’accélérateur de zone d’atterrissage Azure. Ces écarts affectent également la conception des zones d’atterrissage d’application individuelles, qui sont déployées une fois que vous commencez à migrer des ressources vers le cloud.

Ces écarts nécessitent également que les équipes Tailwind Traders suivent les modules Learn sur la gestion, la sécurité et la gouvernance dans le Cloud Adoption Framework après le déploiement de l’environnement initial.

Contraintes supplémentaires

Les contraintes supplémentaires suivantes risquent d’affecter les décisions de Tailwind.

Operations

L’équipe d’exploitation centralisée a créé de manière organique un ensemble de processus et de contrôles pour gérer le portefeuille global. Elle dépend de System Center Operations Manager et de Microsoft Configuration Manager pour la base de référence de ses opérations.

L’équipe a également intégré des outils haut de gamme pour la gestion des machines virtuelles, le suivi de la gestion des incidents et de la configuration, la supervision du réseau, les opérations de sécurité, les contrôles de gouvernance et d’autres outils. La plupart de ces outils disposent d’une intégration prédéfinie à Azure, ce qui a influencé la décision d’utiliser Azure comme principal fournisseur de services cloud de l’entreprise. L’exploitation de ces outils nécessite des ressources et un capital humains importants.

Outils d’exploitation

Les licences pour les outils de gestion des opérations (notamment les hyperviseurs) consomment plus de 20 pour cent du budget informatique de base. La nouvelle directrice informatique (CIO) a défié l’équipe de réévaluer ces outils et processus pour trouver des alternatives axées en priorité sur le cloud ou sur les opérations unifiées. La directrice informatique examinera la réduction des dépenses en outils comme un indicateur précoce de la réussite de cette migration.

Processus opérationnels

Le responsable informatique a demandé le recrutement de deux nouvelles personnes pour soutenir l’équipe d’exploitation centralisée. Elles contribueront à équilibrer la charge qui s’exerce sur l’équipe trop sollicitée. En particulier, elles prendront en charge les pratiques de continuité et de reprise d’activité (BCDR) et les processus de conformité des correctifs.

L’entreprise n’est pas prête pour passer totalement à des opérations natives cloud, en particulier pour les applications stratégiques. La directrice informatique pense que certains investissements dans les outils d’exploitation natifs cloud contribueraient à réduire la charge de l’équipe des opérations centrales en reportant certaines de ces responsabilités sur le fournisseur de services cloud.

La directrice examinera les changements opérationnels afin d’améliorer la satisfaction des employés et de réduire la charge de l’équipe des opérations centrales. Elle demandera aussi des mises à jour fréquentes sur la manière dont le plan d’adoption affecte les efforts de mise à jour corrective et de continuité et reprise d’activité (BCDR).

Contrat de niveau de service

Malgré tout le travail et les coûts associés aux opérations, l’équipe ne parvient parfois pas à respecter le contrat de niveau de service (SLA) de 90 % de temps de disponibilité pour les systèmes stratégiques dans le centre de données principal. Il s’agit d’un problème coûteux pour la directrice informatique et le PDG. Du matériel obsolète et un cycle d’actualisation en retard dans le centre de données ont entraîné des interruptions brèves mais fréquentes.

La société a accepté à contrecœur ce contrat SLA, mais la nouvelle directrice informatique n’est pas impressionnée. Indépendamment des économies réalisées, la directrice attend de l’équipe des opérations centrales qu’elle respecte un contrat SLA nettement plus élevé après la migration.

Innovation pour la vente au détail

La narration client proposée dans le module Bien Démarrer vous a présenté l’équipe d’innovation commerciale au sein de Tailwind Traders. Cette équipe était à l’origine une start-up dont Tailwind Traders a fait l’acquisition. Le PDG initial de la start-up est maintenant le directeur technique (CTO) de Tailwind. Le directeur technique dirige encore cette division comme une start-up, en donnant la priorité à l’expérimentation et à l’innovation.

Les processus de gestion des opérations actuels demandent que toutes les nouvelles innovations de cette équipe passent par un processus de mise en production. L’équipe d’exploitation centralisée au sein du service informatique passe en revue l’architecture pour déceler d’éventuels problèmes de sécurité, de gouvernance et de gestion des opérations. Quand cette équipe est satisfaite de la solution, elle la met en service dans un environnement de production géré de manière centralisée. Ce processus est censé se poursuivre dans le cloud.

Gestion des identités

Active Directory est le magasin d’identités et l’outil principal pour l’authentification et le contrôle d’accès dans les centres de données de Tailwind Traders. L’entreprise a utilisé des systèmes haut de gamme pour étendre la gestion des identités à une solution d’authentification multifacteur. Elle dispose également d’identités fédérées pour déployer sa solution Microsoft 365. Mais même avec celles-ci, Active Directory reste pour Tailwind Traders au centre de la gestion des identités.

Dans le cloud, la société a désormais des options supplémentaires, telles que Microsoft Entra ID ou Microsoft Entra Domain Services s’exécutant dans une infrastructure IaaS. L’équipe d’exploitation centralisée éprouve des difficultés à comparer les options et à choisir la meilleure solution d’identité pour ses plans d’adoption du cloud.

Topologie et connectivité du réseau

Tailwind Traders utilise des lignes MPLS (Multiprotocol Label Switching) pour connecter ses centres de données et ses magasins physiques. Tout le trafic Internet est canalisé via le centre de données principal. En raison de conflits IP (Internet Protocol) entre deux centres de données, le trafic est isolé et le routage dépend de tables de routage complexes. La connectivité externe au centre de données ou au bureau d’entreprise est assurée via un réseau privé virtuel. Cette connectivité est limitée et déconseillée.

Les centres de données principal et secondaire ont des schémas d’adresses IP cohérents dont la gestion et l’organisation sont claires. Le troisième centre de données comprend 50 blocs d’adresses IP différents avec un faible niveau de cohérence et sans organisation claire ou plan de segmentation. Les cycles d’innovation continus sont limités au troisième centre de données, mais ils peuvent présenter des problèmes lors de la définition de la topologie du réseau et du routage dans le cloud.

Organisation des ressources

La segmentation des ressources entre chaque centre de données traitait chaque collection de charges de travail comme un grand bloc de ressources. Chaque collection était ensuite divisée par profil de risque pour créer des segments isolés et contrôlés, afin de permettre un flux réseau limité entre les charges de travail. Les charges de travail qui nécessitent une connexion réseau entrante provenant de tout réseau non protégé sont isolées en un ou plusieurs segments de réseau de périmètre dans chaque centre de données.

Au-delà de cette organisation de base, la base de données de gestion de la configuration présente des incohérences. Il est donc difficile de savoir quelles ressources sont associées à quelles charges de travail. Les propriétaires de charges de travail et les chaînes de remontée d’incidents sont bien définis pour les charges de travail stratégiques, mais sont absents pour la plupart des autres charges de travail.

Pour les charges de travail moins stratégiques, il est courant que le propriétaire identifié soit un ancien employé de Tailwind Traders. Le mappage de configuration fait souvent référence à des machines virtuelles qui ont été arrêtées. De même, plus de 30 % des ressources prises en charge ne sont pas clairement mappées à une charge de travail unique. Pendant la migration, l’entreprise aura besoin de pratiques pour assurer l’analyse des dépendances et une organisation adéquate des ressources.