Comprendre les exigences relatives aux données d'évaluation initiale

La collecte de données peut prendre beaucoup de temps et devenir un obstacle lorsque l'on ne sait pas exactement quelles données sont nécessaires et quand elles sont nécessaires. L'essentiel est de comprendre l'équilibre entre ce qui est trop peu de données et ce qui constitue trop de données pour les résultats de cette étape. Pour vous concentrer sur les données et le niveau de fidélité requis pour cette première étape de l'évaluation du portefeuille, adoptez une approche itérative de collecte de données.

Sources de données et exigences en matière de données

La première étape consiste à identifier vos sources de données. Commencez par identifier les principales parties prenantes de votre organisation qui peuvent répondre aux exigences en matière de données. Il s'agit généralement de membres des équipes de gestion des services, des opérations, de planification des capacités, de surveillance et de support, ainsi que des propriétaires des applications. Organisez des sessions de travail avec les membres de ces groupes. Communiquez les exigences en matière de données et obtenez une liste des outils et de la documentation existante qui peuvent fournir les données.

Pour guider ces conversations, utilisez les questions suivantes :

• Dans quelle mesure l'inventaire actuel de l'infrastructure et des applications est-il précis et à jour ? Par exemple, pour la base de données de gestion des configurations d'entreprise (CMDB), savons-nous déjà où se situent les lacunes ?

• Disposons-nous d'outils et de processus actifs qui maintiennent la CMDB (ou équivalent) à jour ? Dans l'affirmative, à quelle fréquence est-il mis à jour ? Quelle est la date de dernière actualisation ?

• L'inventaire actuel, tel que la CMDB, contient-il un mappage ? application-to-infrastructure Chaque actif d'infrastructure est-il associé à une application ? Chaque application est-elle mappée à l'infrastructure ?

• L'inventaire contient-il un catalogue de licences et de contrats de licence pour chaque produit ?

• L'inventaire contient-il des données de dépendance ? Notez l'existence de données de communication telles que serveur à serveur, application à application, application ou serveur à base de données.

• Quels autres outils pouvant fournir des informations sur les applications et les infrastructures sont disponibles dans l'environnement ? Notez l'existence d'outils de performance, de surveillance et de gestion qui peuvent être utilisés comme source de données.

• Quels sont les différents sites, tels que les centres de données, hébergeant nos applications et notre infrastructure ?

Une fois que vous aurez répondu à ces questions, dressez la liste des sources de données que vous avez identifiées. Attribuez ensuite un niveau de fidélité, ou un niveau de confiance, à chacun d'entre eux. Les données validées récemment (dans les 30 jours) à partir de sources programmatiques actives, telles que des outils, présentent le plus haut niveau de fidélité. Les données statiques sont considérées comme étant moins fidèles et moins fiables. Les exemples de données statiques sont les documents, les classeurs, les CMDB mises à jour manuellement ou tout autre ensemble de données géré de manière non programmatique, ou dont la date de dernière actualisation remonte à plus de 60 jours.

Les niveaux de fidélité des données présentés dans le tableau suivant sont fournis à titre d'exemple. Nous vous recommandons d'évaluer les exigences de votre organisation en termes de tolérance maximale aux hypothèses et aux risques associés afin de déterminer quel est le niveau de fidélité approprié. Dans le tableau, les connaissances institutionnelles font référence à toute information sur les applications et l'infrastructure qui n'est pas documentée.

Sources de données	Niveau de fidélité	Couverture du portefeuille	Commentaires
Connaissances institutionnelles	Faible : jusqu'à 25 % des données exactes, 75 % des valeurs supposées ou des données datent de plus de 150 jours.	Faible	Rare, axé sur les applications critiques
Base de connaissances	Moyenne-faible : 35 à 40 % des données exactes, 65 à 60 % des valeurs supposées ou des données datent de 120 à 150 jours.	Medium	Maintenu manuellement, niveaux de détail incohérents
CMDB	Moyen : environ 50 % des données exactes, environ 50 % des valeurs supposées ou des données datent de 90 à 120 jours.	Medium	Contient des données provenant de sources mixtes, plusieurs lacunes
Exportations vers VMware vCenter	Moyen—élevé : 75 à 80 % des données exactes, 25 à 20 % des valeurs supposées ou des données datent de 60 à 90 jours.	Élevée	Couvre 90 % du parc virtualisé
Surveillance des performances des applications	Élevé - Données généralement précises, environ 5 % des valeurs supposées ou des données datent de 0 à 60 jours.	Faible	Limité aux systèmes de production critiques (couvre 15 % du portefeuille d'applications)

Les tableaux suivants précisent les attributs de données obligatoires et facultatifs pour chaque classe d'actifs (applications, infrastructure, réseaux et migration), l'activité spécifique (inventaire ou analyse de rentabilisation) et la fidélité des données recommandée pour cette étape de l'évaluation. Les tableaux utilisent les abréviations suivantes :

• R, pour obligatoire

• (D), pour l'analyse de rentabilisation directionnelle, requise pour les comparaisons du coût total de possession (TCO) et les analyses de rentabilisation directionnelles

• (F), pour une analyse de rentabilisation directionnelle complète, requise pour la comparaison du coût total de possession et des analyses de rentabilisation directionnelles incluant les coûts de migration et de modernisation

• O, en option

• N/A, car non applicable

Applications

Nom d'attribut	Description	Inventaire et priorisation	Affaire de rentabilisation	Niveau de fidélité recommandé (minimum)
Identifiant unique	Par exemple, l'ID de l'application. Généralement disponible sur les CMDB existantes ou sur d'autres inventaires et systèmes de contrôle internes. Envisagez de créer des identifiants uniques chaque fois que ceux-ci ne sont pas définis dans votre organisation.	R	R (D)	Élevée
Nom de l'application	Nom sous lequel cette application est connue de votre organisation. Incluez le fournisseur commercial off-the-shelf (COTS) et le nom du produit, le cas échéant.	R	R (D)	Moyenne-élevée*
Est-ce que COTS ?	Oui ou non Qu'il s'agisse d'une application commerciale ou d'un développement interne	R	R (D)	Moyenne-élevée*
Produit et version COTS	Nom et version du produit logiciel commercial	R	R (D)	Medium
Description	Fonction et contexte principaux de l'application	R	O	Medium
Criticité	Par exemple, une application stratégique ou génératrice de revenus, ou le soutien d'une fonction critique	R	O	Moyenne-élevée*
Type	Par exemple, base de données, gestion de la relation client (CRM), application Web, multimédia, service informatique partagé	R	O	Medium
Environnement	Par exemple, production, pré-production, développement, test, bac à sable	R	R (D)	Moyenne-élevée*
Conformité et réglementation	Cadres applicables à la charge de travail (par exemple, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) et aux exigences réglementaires	R	R (D)	Moyenne-élevée*
Dépendances	Dépendances en amont et en aval vis-à-vis d'applications ou de services internes et externes. Dépendances non techniques telles que les éléments opérationnels (par exemple, les cycles de maintenance)	O	O	Moyenne-basse*
Cartographie des infrastructures	Mappage vers les actifs physiques et/ou virtuels qui constituent l'application	O	O	Medium
Licence	Type de licence logicielle standard (par exemple, Microsoft SQL Server Enterprise)	O	R	Moyenne-élevée*
Coût	Coûts de licence logicielle, d'exploitation des logiciels et de maintenance	N/A	O	Medium

Infrastructures

Nom de l'attribut	Description	Inventaire et priorisation	Affaire de rentabilisation	Niveau de fidélité recommandé (minimum)
Identifiant unique	Par exemple, l'ID du serveur. Généralement disponible sur les CMDB existantes ou sur d'autres systèmes d'inventaire et de contrôle internes. Envisagez de créer des identifiants uniques chaque fois que ceux-ci ne sont pas définis dans votre organisation.	R	R	Élevée
Nom du réseau	Nom de l'actif sur le réseau (par exemple, nom d'hôte)	R	O	Moyenne-élevée*
Nom DNS (nom de domaine complet, ou FQDN)	Nom du DNS	O	O	Medium
Adresse IP et masque réseau	Adresses IP internes et/ou publiques	R	O	Moyenne-élevée*
Asset type	Serveur physique ou virtuel, hyperviseur, conteneur, appareil, instance de base de données, etc.	R	R	Moyenne-élevée*
Nom du produit	Fournisseur commercial et nom du produit (par exemple, VMware ESXi, IBM Power Systems, Exadata)	R	R	Medium
Système d’exploitation	Par exemple, REHL 8, Windows Server 2019, AIX 6.1	R	R	Moyenne-élevée*
Configuration	Processeur alloué, nombre de cœurs, threads par cœur, mémoire totale, stockage, cartes réseau	R	R	Moyenne-élevée*
Utilisation	Pic et moyenne du processeur, de la mémoire et du stockage. Débit des instances de base de données.	R	O	Moyenne-élevée*
Licence	Type de licence de produit (par exemple, RHEL Standard)	R	R	Medium
S'agit-il d'une infrastructure partagée ?	Oui ou Non pour désigner les services d'infrastructure qui fournissent des services partagés tels que le fournisseur d'authentification, les systèmes de surveillance, les services de sauvegarde et les services similaires	R	R (D)	Medium
Cartographie des applications	Applications ou composants d'application exécutés dans cette infrastructure	O	O	Medium
Coût	Coûts complets pour les serveurs bare metal, y compris le matériel, la maintenance, les opérations, le stockage (SAN, NAS, Object), les licences du système d'exploitation, la part de l'espace rack et les frais généraux des centres de données	N/A	O	Moyenne-élevée*

Réseaux

Nom de l'attribut	Description	Inventaire et priorisation	Affaire de rentabilisation	Niveau de fidélité recommandé (minimum)
Taille du tuyau (Mo/s), redondance (Y/N)	Spécifications actuelles des liaisons WAN (par exemple, redondance de 1 000 Mo/s)	O	R	Medium
Utilisation des liens	Utilisation maximale et moyenne, transfert de données sortants (Go/mois)	O	R	Medium
Latence (ms)	Latence actuelle entre les sites connectés.	O	O	Medium
Coût	Coût actuel par mois	N/A	O	Medium

Migration

Nom de l'attribut	Description	Inventaire et priorisation	Affaire de rentabilisation	Niveau de fidélité recommandé (minimum)
Réhéberger	Effort du client et du partenaire pour chaque charge de travail (jours-personnes), taux de coûts par jour pour les clients et les partenaires, coût des outils, nombre de charges de travail	N/A	R (F)	Moyenne-élevée*
Recréation de plateforme	Effort du client et du partenaire pour chaque charge de travail (jours-personnes), taux de coûts par jour pour les clients et les partenaires, nombre de charges de travail	N/A	R (F)	Moyenne-élevée*
Refactoriser	Effort du client et du partenaire pour chaque charge de travail (jours-personnes), taux de coûts par jour pour les clients et les partenaires, nombre de charges de travail	N/A	O	Moyenne-élevée*
Mise hors service	Nombre de serveurs, coût moyen de mise hors service	N/A	O	Moyenne-élevée*
Zone d'atterrissage	Réutilisation de l'existant (Y/N), liste des AWS régions nécessaires, coût	N/A	R (F)	Moyenne-élevée*
Les gens et le changement	Nombre d'employés à former aux opérations et au développement du cloud, coût de la formation par personne, coût du temps de formation par personne	N/A	R (F)	Moyenne-élevée*
Durée	Durée de la migration de la charge de travail visée (mois)	O	R (F)	Moyenne-élevée*
Coût parallèle	Période et taux auxquels les coûts tels quels peuvent être supprimés pendant la migration	N/A	O	Moyenne-élevée*
	Période et rythme auxquels les AWS produits et services, ainsi que les autres coûts d'infrastructure, sont introduits pendant la migration	N/A	O	Moyenne-élevée*

Évaluation du besoin d'outils de découverte

Votre organisation a-t-elle besoin d'outils de découverte ? L'évaluation du portefeuille nécessite des up-to-date données fiables sur les applications et l'infrastructure. Les étapes initiales de l'évaluation du portefeuille peuvent utiliser des hypothèses pour combler les lacunes dans les données.

Cependant, au fur et à mesure des progrès, les données haute fidélité permettent de créer des plans de migration réussis et d'estimer correctement l'infrastructure cible afin de réduire les coûts et de maximiser les avantages. Il réduit également les risques en permettant des implémentations qui tiennent compte des dépendances et en évitant les pièges liés à la migration. Le principal cas d'utilisation des outils de découverte dans les programmes de migration vers le cloud est de réduire les risques et d'accroître le niveau de confiance dans les données par les moyens suivants :

• Collecte de données automatisée ou programmatique, aboutissant à des données validées et hautement fiables

• Accélération du taux d'obtention des données, amélioration de la vitesse des projets et réduction des coûts

• Niveaux accrus d'exhaustivité des données, y compris les données de communication et les dépendances qui ne sont généralement pas disponibles dans les CMDB

• Obtenir des informations telles que l'identification automatique des applications, l'analyse du coût total de possession, les taux d'exécution prévus et les recommandations d'optimisation

• Planification des vagues de migration en toute confiance

En cas d'incertitude quant à l'existence de systèmes à un emplacement donné, la plupart des outils de découverte peuvent scanner les sous-réseaux du réseau et découvrir les systèmes qui répondent au ping ou aux requêtes SNMP (Simple Network Management Protocol). Notez que toutes les configurations de réseau ou de système n'autorisent pas le trafic ping ou SNMP. Discutez de ces options avec votre réseau et vos équipes techniques.

Les étapes ultérieures de l'évaluation et de la migration du portefeuille d'applications reposent en grande partie sur des informations précises de mappage des dépendances. Le mappage des dépendances permet de comprendre l'infrastructure et la configuration qui seront requises AWS (par exemple, les groupes de sécurité, les types d'instances, le placement des comptes et le routage réseau). Cela permet également de regrouper les applications qui doivent se déplacer en même temps (telles que les applications qui doivent communiquer sur des réseaux à faible latence). En outre, la cartographie des dépendances fournit des informations permettant de faire évoluer l'analyse de rentabilisation.

Lorsque vous choisissez un outil de découverte, il est important de prendre en compte toutes les étapes du processus d'évaluation et d'anticiper les exigences en matière de données. Les lacunes dans les données peuvent devenir des bloqueurs. Il est donc essentiel de les anticiper en analysant les futures exigences en matière de données et les sources de données. L'expérience sur le terrain montre que la plupart des projets de migration bloqués disposent d'un ensemble de données limité dans lequel les applications concernées, l'infrastructure associée et leurs dépendances ne sont pas clairement identifiées. Ce manque d'identification peut entraîner des mesures, des décisions et des retards incorrects. L'obtention up-to-date de données est la première étape d'un projet de migration réussi.

Comment sélectionner un outil de découverte ?

Plusieurs outils de découverte disponibles sur le marché offrent des fonctionnalités et des capacités différentes. Tenez compte de vos besoins. Et choisissez l'option la plus appropriée pour votre organisation. Les facteurs les plus courants lors du choix d'un outil de découverte pour les migrations sont les suivants :

Sécurité

• Quelle est la méthode d'authentification pour accéder au référentiel de données de l'outil ou aux moteurs d'analyse ?

• Qui peut accéder aux données et quels sont les contrôles de sécurité pour accéder à l'outil ?

• Comment l'outil collecte-t-il les données ? A-t-il besoin d'informations d'identification dédiées ?

• Quels sont les identifiants et le niveau d'accès dont l'outil a besoin pour accéder à mes systèmes et obtenir des données ?

• Comment les données sont-elles transférées entre les composants de l'outil ?

• L'outil prend-il en charge le chiffrement des données au repos et en transit ?

• Les données sont-elles centralisées dans un seul composant à l'intérieur ou à l'extérieur de mon environnement ?

• Quelles sont les exigences en matière de réseau et de pare-feu ?

Assurez-vous que les équipes de sécurité participent aux premières discussions sur les outils de découverte.

La souveraineté des données

• Où sont stockées et traitées les données ?

• L'outil utilise-t-il un modèle de logiciel en tant que service (SaaS) ?

• Est-il possible de conserver toutes les données dans les limites de mon environnement ?

• Les données peuvent-elles être filtrées avant qu'elles ne quittent les limites de mon organisation ?

Tenez compte des besoins de votre organisation en termes d'exigences en matière de résidence des données.

Architecture

• Quelle est l'infrastructure requise et quels en sont les différents composants ?

• Plusieurs architectures sont-elles disponibles ?

• L'outil permet-il d'installer des composants dans des zones de sécurité verrouillées ?

Performances

• Quel est l'impact de la collecte de données sur mes systèmes ?

Compatibilité et champ d'application

• L'outil est-il compatible avec la totalité ou la plupart de mes produits et versions ? Consultez la documentation de l'outil pour vérifier les plateformes prises en charge par rapport aux informations actuelles concernant votre champ d'application.

• La plupart de mes systèmes d'exploitation sont-ils pris en charge pour la collecte de données ? Si vous ne connaissez pas les versions de votre système d'exploitation, essayez de limiter la liste des outils de découverte à ceux qui proposent le plus grand nombre de systèmes pris en charge.

Méthodes de collecte

• L'outil nécessite-t-il l'installation d'un agent sur chaque système cible ?

• Supporte-t-il les déploiements sans agent ?

• Les fonctionnalités avec agent et sans agent offrent-elles les mêmes fonctionnalités ?

• En quoi consiste le processus de collecte ?

Fonctions

• Quelles sont les fonctionnalités disponibles ?

• Peut-il calculer le coût total de possession (TCO) et le taux de fonctionnement estimé du AWS cloud ?

• Soutient-il la planification de la migration ?

• Mesure-t-il les performances ?

• Peut-il recommander une AWS infrastructure cible ?

• Effectue-t-il un mappage des dépendances ?

• Quel niveau de mappage des dépendances fournit-il ?

• Fournit-il un accès à l'API ? (par exemple, peut-on y accéder par programmation pour obtenir des données ?)

Pensez aux outils dotés de puissantes fonctions de mappage des dépendances des applications et des infrastructures et à ceux qui peuvent déduire des applications à partir de modèles de communication.

Coût

• Qu'est-ce que le modèle de licence ?

• Combien coûte la licence ?

• Le prix est-il valable pour chaque serveur ? S'agit-il d'une tarification échelonnée ?

• Existe-t-il des options avec des fonctionnalités limitées qui peuvent être licenciées à la demande ?

Les outils de découverte sont généralement utilisés tout au long du cycle de vie des projets de migration. Si votre budget est limité, considérez au moins 6 mois. Cependant, l'absence d'outils de découverte entraîne généralement une augmentation des efforts manuels et des coûts internes.

Modèle de support

• Quels sont les niveaux de support fournis par défaut ?

• Un plan de support est-il disponible ?

• Quels sont les délais de réponse aux incidents ?

Services professionnels

• Le fournisseur propose-t-il des services professionnels pour analyser les résultats de découverte ?

• Peuvent-ils couvrir les éléments de ce guide ?

• Existe-t-il des remises ou des offres groupées pour les services Tooling + ?

Fonctionnalités recommandées pour l'outil de découverte

Pour éviter de provisionner et de combiner des données provenant de plusieurs outils au fil du temps, un outil de découverte doit couvrir les fonctionnalités minimales suivantes :

• Logiciel — L'outil de découverte doit être capable d'identifier les processus en cours d'exécution et les logiciels installés.

• Cartographie des dépendances — Il doit être capable de collecter des informations de connexion réseau et de créer des cartes de dépendance entrantes et sortantes des serveurs et des applications en cours d'exécution. En outre, l'outil de découverte doit être capable de déduire des applications provenant de groupes d'infrastructures en fonction des modèles de communication.

• Découverte du profil et de la configuration — Il doit être en mesure de signaler le profil d'infrastructure tel que la famille de processeurs (par exemple, x86, PowerPC), le nombre de cœurs de processeur, la taille de la mémoire, le nombre de disques et leur taille, ainsi que les interfaces réseau.

• Découverte du stockage réseau — Il doit être capable de détecter et de profiler les partages réseau à partir du stockage rattaché au réseau (NAS).

• Performances — Il doit être en mesure de signaler l'utilisation maximale et moyenne du processeur, de la mémoire, du disque et du réseau.

• Analyse des lacunes — Elle doit être en mesure de fournir des informations sur la quantité et la fidélité des données.

• Analyse du réseau — Il doit être capable de scanner les sous-réseaux du réseau et de découvrir les actifs d'infrastructure inconnus.

• Rapports — Il doit être en mesure de fournir l'état de la collecte et de l'analyse.

• Accès à l'API — Il devrait être en mesure de fournir des moyens programmatiques pour accéder aux données collectées.

Fonctionnalités supplémentaires à prendre en compte

• Analyse du coût total de possession pour fournir une comparaison des coûts entre le coût actuel sur site et le coût prévu AWS .

• Analyse des licences et recommandations d'optimisation pour les systèmes Microsoft SQL Server et Oracle dans les scénarios de réhébergement et de replateforme.

• Recommandation de stratégie de migration (l'outil de découverte peut-il émettre des recommandations de type R de migration par défaut en fonction de la technologie actuelle ?)

• Exportation d'inventaire (au format CSV ou similaire)

• Recommandation de dimensionnement correct (par exemple, peut-elle cartographier une AWS infrastructure cible recommandée ?)

• Visualisation des dépendances (par exemple, le mappage des dépendances peut-il être visualisé en mode graphique ?)

• Vue architecturale (par exemple, les diagrammes architecturaux peuvent-ils être produits automatiquement ?)

• Priorisation des applications (peut-elle attribuer du poids ou de la pertinence aux attributs de l'application et de l'infrastructure afin de créer des critères de priorisation pour la migration ?)

• Planification des vagues (par exemple, groupes d'applications recommandés et possibilité de créer des plans de vagues de migration)

• Estimation des coûts de migration (estimation de l'effort de migration)

Considérations relatives au déploiement

Après avoir sélectionné et acheté un outil de découverte, posez-vous les questions suivantes pour engager des conversations avec les équipes chargées de déployer l'outil dans votre organisation :

• Les serveurs ou les applications sont-ils gérés par un tiers ? Cela pourrait dicter les équipes à impliquer et les processus à suivre.

• Quel est le processus de haut niveau pour obtenir l'autorisation de déployer des outils de découverte ?

• Quel est le principal processus d'authentification pour accéder à des systèmes tels que les serveurs, les conteneurs, le stockage et les bases de données ? Les informations d'identification du serveur sont-elles locales ou centralisées ? Quelle est la procédure à suivre pour obtenir des informations d'identification ? Des informations d'identification seront nécessaires pour collecter des données à partir de vos systèmes (par exemple, des conteneurs, des serveurs virtuels ou physiques, des hyperviseurs et des bases de données). Il peut être difficile d'obtenir des informations d'identification permettant à l'outil de découverte de se connecter à chaque ressource, en particulier lorsque ces ressources ne sont pas centralisées.

• Quelles sont les grandes lignes des zones de sécurité du réseau ? Les diagrammes de réseau sont-ils disponibles ?

• Quelle est la procédure à suivre pour demander des règles de pare-feu dans les centres de données ?

• Quels sont les accords de niveau de service (SLA) de support actuels relatifs aux opérations des centres de données (installation d'outils de découverte, demandes de pare-feu) ?