Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Comprendre les exigences en matière de 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, en ce qui concerne 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 ?
+ La documentation actuelle, telle que la CMDB ou l'équivalent, contient-elle un mappage application-infrastructure ? Chaque actif d'infrastructure est-il associé à une application ? Chaque application est-elle mappée à l'infrastructure ?
+ La documentation contient-elle un catalogue de licences et de contrats de licence pour chaque produit ?
+ La documentation contient-elle 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 de performances, de surveillance, de référentiels, de bases de connaissances et d'outils de gestion pouvant ê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** | **Évaluation du 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 | Medium-low - 35 à 40 % des données exactes, 65 à 60 % des valeurs supposées ou des données datent de 120 à 150 jours. | Moyenne | 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. | Moyenne | Contient des données provenant de sources mixtes, plusieurs lacunes |
| Exportations vers VMware vCenter | Medium-high - 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 |
| Application name (Nom de l'application) | Nom sous lequel cette application est connue de votre organisation. Incluez le fournisseur commercial prêt à l'emploi (COTS) et le nom du produit, le cas échéant. | R | R (D) | Medium-high |
| Est-ce que COTS ? | Oui ou non. Qu'il s'agisse d'une application commerciale ou d'un développement interne | R | R (D) | Medium-high |
| Produit et version COTS | Nom et version du produit logiciel commercial | R | R (D) | Moyenne |
| Description | Fonction et contexte principaux de l'application | R | O | Moyenne |
| Criticité | Par exemple, une application stratégique ou génératrice de revenus, ou le soutien d'une fonction critique | R | O | Medium-high |
| Type | Par exemple, base de données, gestion de la relation client (CRM), application Web, multimédia, service informatique partagé | R | O | Moyenne |
| Environnement | Par exemple, production, pré-production, développement, test, bac à sable | R | R (D) | Medium-high |
| Conformité et réglementation | Cadres applicables à la charge de travail (par exemple, HIPAA, SOX, ISO, PCI-DSS SOC, FedRAMP) et aux exigences réglementaires | R | R (D) | Medium-high |
| Dépendances | Dépendances en amont et en aval vis-à-vis d'applications ou de services internes et externes. Non-technical les dépendances telles que les éléments opérationnels (par exemple, les cycles de maintenance) | O | O | Medium-low |
| Cartographie des infrastructures | Mappage vers les actifs and/or virtuels physiques qui constituent l'application | R | O | Moyenne |
| Licence | Type de licence logicielle standard (par exemple, Microsoft SQL Server Enterprise) | O | R | Medium-high |
| Cost | Coûts de licence logicielle, d'exploitation des logiciels et de maintenance | O | O | Moyenne |
### 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 | Medium-high |
| Nom DNS (nom de domaine complet, ou FQDN) | Nom du DNS | O | O | Moyenne |
| Adresse IP et masque réseau | Adresses IP and/or publiques internes | O | O | Medium-high |
| Type de ressource | Serveur physique ou virtuel, hyperviseur, conteneur, appareil, instance de base de données, etc. | R | R | Medium-high |
| Nom du produit | Fournisseur commercial et nom du produit (par exemple, VMware ESXi, IBM Power Systems, Exadata) | R | R | Moyenne |
| Système d’exploitation | Par exemple, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Medium-high |
| Configuration | Processeur alloué, nombre de cœurs, threads par cœur, mémoire totale, stockage, cartes réseau | R | R | Medium-high |
| Utilisation | Pic et moyenne du processeur, de la mémoire et du stockage. Débit des instances de base de données. | O | O | Medium-high |
| Licence | Type de licence de produit (par exemple, RHEL Standard) | O | R | Moyenne |
| Cartographie des applications | Applications ou composants d'application exécutés dans cette infrastructure | R | O | Moyenne |
| Cost | Coûts complets pour les serveurs bare metal, y compris le matériel, la maintenance, les opérations, le stockage (SAN, NAS, objet), les licences du système d'exploitation, le partage de l'espace rackspace et les frais généraux des centres de données | O | O | Medium-high |
### Réseaux
|
|
| **Nom d'attribut** | **Description** | **Inventaire et priorisation** | **Affaire de rentabilisation** | **Niveau de fidélité recommandé (minimum)** |
| --- |--- |--- |--- |--- |
| Taille du tuyau (Mb/s), redondance () Y/N | Spécifications actuelles des liaisons WAN (par exemple, 1000 Mb/s redondantes) | O | R | Moyenne |
| Sites connectés | Emplacements nommés connectés par ce lien | O | O | Moyenne |
| Utilisation des liens | Utilisation maximale et moyenne, transfert de données sortants () GB/month | O | R | Moyenne |
| Latence (ms) | Latence actuelle entre les sites connectés | O | O | Moyenne |
| Cost | Coût actuel par mois | N/A | O | Moyenne |
### Migration
|
|
| **Nom de l'attribut** | **Description** | **Inventaire et priorisation** | **Affaire de rentabilisation** | **Niveau de fidélité recommandé (minimum)** |
| --- |--- |--- |--- |--- |
| Coût de réhébergement | 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) | Medium-high |
| Coût de la replateforme | 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) | Medium-high |
| Coût de refactorisation | 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) | Medium-high |
| Coût de retraite | Nombre de serveurs, coût moyen de mise hors service | N/A | O | Medium-high |
| Zone d'atterrissage | Re-use existing (Y/N), liste des régions AWS nécessaires, coût | N/A | R (F) | Medium-high |
| 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) | Medium-high |
| Duration | Durée de la migration de la charge de travail visée (mois) | O | R (F) | Medium-high |
| Coût parallèle | Période et taux auxquels les coûts tels quels peuvent être supprimés pendant la migration | N/A | O | Medium-high |
| Coût parallèle | Période et rythme auxquels les produits et services AWS, ainsi que les autres coûts d'infrastructure, sont introduits pendant la migration | N/A | O | Medium-high |
## É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 données actualisées et 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. Toutefois, au fur et à mesure des progrès, les données haute fidélité vous aident à créer des plans de migration réussis et à 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
+ High-confidence planification des vagues de migration
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 dans AWS (tels que les groupes de sécurité, les types d'instances, le placement de 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).
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 de données actualisé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é
+ Quelles sont les données collectées par l'outil ?
+ 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 infrastructure est requise pour déployer l'outil, et quels en sont les différents composants ?
+ Plusieurs architectures ou modèles de déploiement sont-ils disponibles ?
+ L'outil permet-il d'installer des composants dans des zones de sécurité verrouillées ?
#### Performance
+ 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 doit-il installer un agent sur chaque système cible ?
+ Supporte-t-il la collecte de données sans agent ?
+ Les fonctionnalités avec agent et sans agent offrent-elles les mêmes fonctionnalités ?
+ En quoi consiste le processus de collecte ?
#### Caractéristiques
+ Quelles sont les fonctionnalités disponibles ?
+ Peut-il calculer le coût total de possession (TCO) et le taux de AWS Cloud fonctionnement estimé ?
+ 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.
#### Cost
+ Qu'est-ce que le modèle de licence ?
+ Quel est le coût de 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 \+ ?
**Astuce**
Pour rechercher et évaluer les outils de découverte, utilisez le site [Discovery, Planning, and Recommendation](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/).
### 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 ainsi que les environnements d'exécution, les packages et les frameworks 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).
+ **Découverte de bases** de données — Il doit être capable de découvrir des bases de données, des instances et des schémas, y compris les types et les versions de moteurs.
+ **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 des 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)
+ **Right-sizing recommandation** (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 aide à la création de plans de vague 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 responsables du déploiement de 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 ?
+ Quel est le processus de demande de 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) ?