Comprensión de los requisitos de datos de la evaluación inicial - AWS Guía prescriptiva
Fuentes de datos y requisitos de datosEvaluar la necesidad de herramientas de descubrimiento

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Comprensión de los requisitos de datos de la evaluación inicial

La recopilación de datos puede llevar un tiempo considerable y convertirse fácilmente en un obstáculo cuando no hay claridad sobre qué datos se necesitan y cuándo se necesitan. La clave es entender el equilibrio entre los datos que son muy pocos y los que son demasiados para los resultados de esta etapa. Para centrarse en los datos y el nivel de fidelidad necesarios para esta fase inicial de la evaluación de la cartera, adopte un enfoque iterativo para la recopilación de datos.

Fuentes de datos y requisitos de datos

El primer paso es identificar las fuentes de datos. Comience por identificar a las partes interesadas clave de su organización que pueden cumplir con los requisitos de datos. Por lo general, son miembros de los equipos de administración de servicios, operaciones, planificación de la capacidad, supervisión y soporte, y los propietarios de las aplicaciones. Establezca sesiones de trabajo con los miembros de estos grupos. Comunique los requisitos de datos y obtenga una lista de las herramientas y la documentación existente que puedan proporcionar los datos.

Para guiar estas conversaciones, utilice el siguiente conjunto de preguntas:

  • ¿Cuán preciso y actualizado es el inventario actual de infraestructuras y aplicaciones? Por ejemplo, en el caso de la base de datos de gestión de la configuración (CMDB) de la empresa, ¿sabemos ya cuáles son las carencias?

  • ¿Disponemos de herramientas y procesos activos que mantengan actualizada la CMDB (o su equivalente)? Si es así, ¿con qué frecuencia se actualiza? ¿Cuál es la última fecha de actualización?

  • ¿El inventario actual, como la CMDB, contiene application-to-infrastructure mapas? ¿Cada activo de infraestructura está asociado a una aplicación? ¿Cada aplicación está mapeada a la infraestructura?

  • ¿El inventario contiene un catálogo de licencias y acuerdos de licencia para cada producto?

  • ¿El inventario contiene datos de dependencia? Tenga en cuenta la existencia de datos de comunicación, como de servidor a servidor, de aplicación a aplicación, de aplicación o de servidor a base de datos.

  • ¿Qué otras herramientas que pueden proporcionar información sobre aplicaciones e infraestructuras están disponibles en el entorno? Tenga en cuenta la existencia de herramientas de rendimiento, supervisión y administración que se pueden utilizar como fuente de datos.

  • ¿Cuáles son las diferentes ubicaciones, como los centros de datos, donde se alojan nuestras aplicaciones e infraestructura?

Una vez respondidas estas preguntas, enumere las fuentes de datos identificadas. Luego, asigne un nivel de fidelidad, o nivel de confianza, a cada una de ellas. Los datos validados recientemente (en un plazo de 30 días) a partir de fuentes programáticas activas, como las herramientas, tienen el mayor nivel de fidelidad. Los datos estáticos se consideran de menor fidelidad y menos fiables. Algunos ejemplos de datos estáticos son los documentos, los libros de trabajo, las CMDB actualizadas manualmente o cualquier otro conjunto de datos que no se mantenga mediante programación o cuya fecha de última actualización sea anterior a 60 días.

Los niveles de fidelidad de los datos de la siguiente tabla se proporcionan a modo de ejemplo. Le recomendamos que evalúe los requisitos de su organización en términos de tolerancia máxima a las suposiciones y al riesgo asociado para determinar cuál es el nivel de fidelidad adecuado. En la tabla, el conocimiento institucional se refiere a cualquier información sobre las aplicaciones y la infraestructura que no esté documentada.

Origen de datos

Nivel de fidelidad

Cobertura de cartera

Comentarios

Conocimiento institucional

Bajo: hasta un 25% de los datos precisos, el 75% de los valores asumidos o los datos tienen más de 150 días de antigüedad.

Baja

Escaso, centrado en aplicaciones críticas

Base de conocimientos

Medio-bajo: entre el 35 y el 40% de los datos precisos, entre el 65 y el 60% de los valores o datos supuestos tienen entre 120 y 150 días de antigüedad.

Medio

Niveles de detalle inconsistentes y mantenidos manualmente

CMDB

Medio: aproximadamente el 50% de los datos precisos, aproximadamente el 50% de los valores supuestos o los datos tienen entre 90 y 120 días de antigüedad.

Medio

Contiene datos de fuentes mixtas, con varios vacíos de datos

Exportaciones de VMware vCenter

Medio-alto: entre el 75 y el 80% de los datos precisos, entre el 25 y el 20% de los valores asumidos o los datos tienen entre 60 y 90 días de antigüedad.

Alta

Cubre el 90% del espacio virtualizado

Supervisión del rendimiento de las aplicaciones

Alto: datos en su mayoría precisos, aproximadamente un 5% de los valores asumidos o los datos tienen entre 0 y 60 días de antigüedad.

Baja

Limitado a los sistemas de producción críticos (cubre el 15% de la cartera de aplicaciones)

En las siguientes tablas se especifican los atributos de datos obligatorios y opcionales para cada clase de activos (aplicaciones, infraestructura, redes y migración), la actividad específica (inventario o modelo de negocio) y la fidelidad de los datos recomendada para esta fase de evaluación. En las tablas se utilizan las siguientes abreviaturas:

  • R, si es necesario

  • (D), para un modelo de negocio direccional, obligatorio para las comparaciones del coste total de propiedad (TCO) y los modelos de negocio direccionales

  • (F), si se trata de un modelo de negocio totalmente orientado, es necesario para comparar el TCO con los modelos de negocio direccionales que incluyan los costes de migración y modernización

  • O, de forma opcional

  • N/A, si no se aplica

Aplicaciones

Nombre de atributo

Descripción

Inventario y priorización

Caso de negocio

Nivel de fidelidad recomendado (mínimo)

Identificador único

Por ejemplo, el identificador de la aplicación. Suele estar disponible en las CMDB existentes u otros sistemas de control e inventarios internos. Considere la posibilidad de crear identificadores únicos siempre que no estén definidos en su organización.

R

R (D)

Alta

Nombre de la aplicación

Nombre por el que su organización conoce esta aplicación. Incluya el nombre del proveedor comercial off-the-shelf (COTS) y del producto cuando proceda.

R

R (D)

Medio-alto

¿Es COTS?

Sí o no. Si se trata de una aplicación comercial o de un desarrollo interno

R

R (D)

Medio-alto

Producto y versión de COTS

Nombre y versión del producto de software comercial

R

R (D)

Medio

Descripción

Función y contexto de la aplicación principal

R

O

Medio

Criticidad

Por ejemplo, una aplicación estratégica o generadora de ingresos, o que respalde una función crítica

R

O

Medio-alto

Tipo

Por ejemplo, base de datos, gestión de relaciones con los clientes (CRM), aplicación web, multimedia o servicio compartido de TI

R

O

Medio

Entorno

Por ejemplo, producción, preproducción, desarrollo, pruebas o entorno aislado

R

R (D)

Medio-alto

Cumplimiento y regulación

Marcos aplicables a la carga de trabajo (por ejemplo, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) y a los requisitos reglamentarios

R

R (D)

Medio-alto

Dependencias

Dependencias ascendentes y descendentes de aplicaciones o servicios internos y externos. Dependencias no técnicas, como los elementos operativos (por ejemplo, los ciclos de mantenimiento)

O

O

Medio-bajo

Mapeo de infraestructuras

Mapeo de los activos físicos y/o virtuales que componen la aplicación

O

O

Medio

Licencia

Tipo de licencia de software básico (p. ej., Microsoft SQL Server Enterprise)

O

R

Medio-alto

Costo

Costos de la licencia de software, las operaciones del software y el mantenimiento

N/A

O

Medio

Infraestructura

Nombre del atributo

Descripción

Inventario y priorización

Caso de negocio

Nivel de fidelidad recomendado (mínimo)

Identificador único

Por ejemplo, el ID del servidor. Suele estar disponible en las CMDB existentes u otros sistemas de control e inventarios internos. Considere la posibilidad de crear identificadores únicos siempre que no estén definidos en su organización.

R

R

Alta

Nombre de la red

Nombre del activo en la red (por ejemplo, nombre de host)

R

O

Medio-alto

Nombre DNS (nombre de dominio completo o FQDN)

Nombre de DNS

O

O

Medio

Dirección IP y máscara de red

Direcciones IP internas y/o públicas

R

O

Medio-alto

Asset type (Tipo de activo)

Servidor físico o virtual, hipervisor, contenedor, dispositivo, instancia de base de datos, etc.

R

R

Medio-alto

Nombre del producto

Nombre del producto y proveedor comercial (p. ej., VMware ESXi, IBM Power Systems, Exadata)

R

R

Medio

Sistema operativo

Por ejemplo, REHL 8, Windows Server 2019, AIX 6.1

R

R

Medio-alto

Configuración

CPU asignada, número de núcleos, subprocesos por núcleo, memoria total, almacenamiento, tarjetas de red

R

R

Medio-alto

Utilización

Pico y promedio de CPU, memoria y almacenamiento. Rendimiento de las instancias de base de datos.

R

O

Medio-alto

Licencia

Tipo de licencia de producto básico (por ejemplo, RHEL Standard)

R

R

Medio

¿Es una infraestructura compartida?

Sí o No para indicar los servicios de infraestructura que proporcionan servicios compartidos, como el proveedor de autenticación, los sistemas de monitoreo, los servicios de respaldo y servicios similares

R

R (D)

Medio

Mapeo de aplicaciones

Aplicaciones o componentes de aplicaciones que se ejecutan en esta infraestructura

O

O

Medio

Costo

Todos los costos de los servidores básicos incluyen el hardware, el mantenimiento, las operaciones, el almacenamiento (SAN, NAS, Object), la licencia del sistema operativo, la participación en Rackspace y los gastos generales del centro de datos

N/A

O

Medio-alto

Redes

Nombre del atributo

Descripción

Inventario y priorización

Caso de negocio

Nivel de fidelidad recomendado (mínimo)

Tamaño de la tubería (MB/s), redundancia (Y/N)

Especificaciones actuales del enlace WAN (por ejemplo, 1000 Mb/s de redundancia)

O

R

Medio

Utilización del enlace

Utilización máxima y media, transferencia de datos salientes (GB/mes)

O

R

Medio

Latencia (ms)

Latencia actual entre las ubicaciones conectadas.

O

O

Medio

Costo

Coste actual por mes

N/A

O

Medio

Migración

Nombre del atributo

Descripción

Inventario y priorización

Caso de negocio

Nivel de fidelidad recomendado (mínimo)

Volver a alojar

Esfuerzo de los clientes y socios por cada carga de trabajo (días-persona), tarifas de costo por día de clientes y socios, costo de las herramientas y cantidad de cargas de trabajo

N/A

R (F)

Medio-alto

Redefinir la plataforma

Esfuerzo de los clientes y socios por cada carga de trabajo (días-persona), tarifas de costos por día de clientes y socios y cantidad de cargas de trabajo

N/A

R (F)

Medio-alto

Refactorizar

Esfuerzo de los clientes y socios por cada carga de trabajo (días-persona), tasas de costo por día de clientes y socios y cantidad de cargas de trabajo

N/A

O

Medio-alto

Retirar

Número de servidores, coste medio de desmantelamiento

N/A

O

Medio-alto

Zona de aterrizaje

Reutilizar los existentes (sí/no), lista de AWS regiones necesarias, coste

N/A

R (F)

Medio-alto

La gente y el cambio

Número de personal que se capacitará en operaciones y desarrollo de la nube, costo de la capacitación por persona, costo del tiempo de capacitación por persona

N/A

R (F)

Medio-alto

Duración

Duración de la migración de la carga de trabajo incluida (meses)

O

R (F)

Medio-alto

Coste paralelo

Plazo y ritmo a los que se pueden eliminar los costos «tal cual» durante la migración

N/A

O

Medio-alto

Plazo y ritmo a AWS los que se introducen los productos y servicios, así como otros costes de infraestructura, durante la migración

N/A

O

Medio-alto

Evaluar la necesidad de herramientas de descubrimiento

¿Su organización necesita herramientas de descubrimiento? La evaluación de la cartera requiere up-to-date datos fiables sobre las aplicaciones y la infraestructura. En las etapas iniciales de la evaluación de la cartera se pueden utilizar suposiciones para subsanar las lagunas en los datos.

Sin embargo, a medida que se avanza, los datos de alta fidelidad permiten crear planes de migración satisfactorios y estimar correctamente la infraestructura de destino para reducir los costos y maximizar los beneficios. También reduce el riesgo al permitir implementaciones que tengan en cuenta las dependencias y evitar los problemas de migración. El uso principal de las herramientas de descubrimiento en los programas de migración a la nube es reducir el riesgo y aumentar los niveles de confianza en los datos mediante lo siguiente:

  • Recopilación de datos automatizada o programática, lo que da como resultado datos validados y de gran confianza

  • Aceleración de la velocidad a la que se obtienen los datos, lo que mejora la velocidad del proyecto y reduce los costos

  • Mayores niveles de integridad de los datos, incluidos los datos de comunicación y las dependencias que normalmente no están disponibles en las CMDB

  • Obtener información como la identificación automática de aplicaciones, el análisis del TCO, las tasas de ejecución proyectadas y las recomendaciones de optimización

  • Planificación fiable de las oleadas de migración

Cuando no se sabe con certeza si los sistemas existen en una ubicación determinada, la mayoría de las herramientas de detección pueden analizar las subredes de la red y detectar los sistemas que responden a los ping o a las solicitudes del Protocolo simple de administración de redes (SNMP). Tenga en cuenta que no todas las configuraciones de red o sistemas permitirán el tráfico de ping o SNMP. Analice estas opciones con sus equipos técnicos y de red.

Las etapas posteriores de la evaluación y migración de la cartera de aplicaciones dependen en gran medida de una información precisa sobre el mapeo de dependencias. El mapeo de dependencias permite comprender la infraestructura y la configuración que se necesitarán AWS (por ejemplo, los grupos de seguridad, los tipos de instancias, la ubicación de las cuentas y el enrutamiento de la red). También ayuda a agrupar las aplicaciones que deben moverse al mismo tiempo (por ejemplo, las aplicaciones que deben comunicarse a través de redes de baja latencia). Además, el mapeo de dependencias proporciona información para desarrollar el modelo de negocio.

A la hora de decidirse por una herramienta de descubrimiento, es importante tener en cuenta todas las etapas del proceso de evaluación y anticipar las necesidades de datos. Las brechas de datos tienen el potencial de convertirse en obstáculos, por lo que es clave anticiparlas analizando los requisitos de datos y las fuentes de datos en el futuro. La experiencia sobre el terreno indica que la mayoría de los proyectos de migración estancados tienen un conjunto de datos limitado en el que no se identifican claramente las aplicaciones incluidas en el ámbito de aplicación, la infraestructura asociada y sus dependencias. Esta falta de identificación puede provocar métricas, decisiones y retrasos incorrectos. La obtención up-to-date de datos es el primer paso para que los proyectos de migración tengan éxito.

¿Cómo seleccionar una herramienta de descubrimiento?

Varias herramientas de descubrimiento del mercado ofrecen diferentes funciones y capacidades. Tenga en cuenta sus requisitos. Y decida cuál es la opción más adecuada para su organización. Los factores más comunes a la hora de decidirse por una herramienta de detección para las migraciones son los siguientes:

Seguridad

  • ¿Cuál es el método de autenticación para acceder al repositorio de datos de la herramienta o a los motores de análisis?

  • ¿Quién puede acceder a los datos y cuáles son los controles de seguridad para acceder a la herramienta?

  • ¿Cómo recopila la herramienta los datos? ¿Necesita credenciales dedicadas?

  • ¿Qué credenciales y nivel de acceso necesita la herramienta para acceder a mis sistemas y obtener datos?

  • ¿Cómo se transfieren los datos entre los componentes de la herramienta?

  • ¿La herramienta admite el cifrado de datos en reposo y en tránsito?

  • ¿Los datos están centralizados en un solo componente dentro o fuera de mi entorno?

  • ¿Cuáles son los requisitos de red y firewall?

Asegúrese de que los equipos de seguridad participen en las primeras conversaciones sobre las herramientas de descubrimiento.

Soberanía de datos

  • ¿Dónde se almacenan y procesan los datos?

  • ¿Utiliza la herramienta un modelo de software como servicio (SaaS)?

  • ¿Tiene la posibilidad de conservar todos los datos dentro de los límites de mi entorno?

  • ¿Se pueden analizar los datos antes de que salgan de los límites de mi organización?

Tenga en cuenta las necesidades de su organización en términos de requisitos de residencia de datos.

Arquitectura

  • ¿Qué infraestructura se requiere y cuáles son los diferentes componentes?

  • ¿Hay más de una arquitectura disponible?

  • ¿La herramienta admite la instalación de componentes en zonas de seguridad cerradas?

Rendimiento

  • ¿Cuál es el impacto de la recopilación de datos en mis sistemas?

Compatibilidad y alcance

  • ¿La herramienta es compatible con todos o la mayoría de mis productos y versiones? Revisa la documentación de la herramienta para verificar las plataformas compatibles con la información actual sobre tu alcance.

  • ¿La mayoría de mis sistemas operativos son compatibles con la recopilación de datos? Si no conoce las versiones de su sistema operativo, intente limitar la lista de herramientas de detección a aquellas que cuenten con una gama más amplia de sistemas compatibles.

Métodos de recopilación

  • ¿La herramienta requiere instalar un agente en cada sistema de destino?

  • ¿Soporta despliegues sin agente?

  • ¿Ofrecen las mismas funciones con agente y sin agente?

  • ¿Cuál es el proceso de cobro?

Características

  • ¿Cuáles son las funciones disponibles?

  • ¿Puede calcular el coste total de propiedad (TCO) y la tasa estimada de ejecución de AWS la nube?

  • ¿Soporta la planificación de la migración?

  • ¿Mide el rendimiento?

  • ¿Puede recomendar la AWS infraestructura de destino?

  • ¿Realiza un mapeo de dependencias?

  • ¿Qué nivel de mapeo de dependencias proporciona?

  • ¿Proporciona acceso a la API? (por ejemplo, ¿se puede acceder a ella mediante programación para obtener datos?)

Considere las herramientas con funciones sólidas de mapeo de dependencias de aplicaciones e infraestructuras y aquellas que puedan deducir las aplicaciones a partir de los patrones de comunicación.

Costo

  • ¿Qué es el modelo de licencias?

  • ¿Cuánto cuesta la licencia?

  • ¿El precio de cada servidor es válido? ¿Se trata de precios escalonados?

  • ¿Existen opciones con funciones limitadas que se puedan licenciar bajo demanda?

Las herramientas de descubrimiento se suelen utilizar durante todo el ciclo de vida de los proyectos de migración. Si su presupuesto es limitado, considere la posibilidad de tener al menos 6 meses. Sin embargo, la ausencia de herramientas de detección suele implicar un mayor esfuerzo manual y costes internos.

Modelo Support

  • ¿Qué niveles de soporte se proporcionan de forma predeterminada?

  • ¿Hay algún plan de soporte disponible?

  • ¿Cuáles son los tiempos de respuesta a los incidentes?

Servicios profesionales

  • ¿Ofrece el proveedor servicios profesionales para analizar los resultados del descubrimiento?

  • ¿Pueden cubrir los elementos de esta guía?

  • ¿Hay descuentos o paquetes de herramientas y servicios?

Funciones recomendadas para la herramienta de descubrimiento

Para evitar aprovisionar y combinar datos de varias herramientas a lo largo del tiempo, una herramienta de descubrimiento debe incluir las siguientes características mínimas:

  • Software: la herramienta de descubrimiento debe poder identificar los procesos en ejecución y el software instalado.

  • Mapeo de dependencias: debe poder recopilar información de conexión de red y crear mapas de dependencias entrantes y salientes de los servidores y las aplicaciones en ejecución. Además, la herramienta de detección debería poder inferir aplicaciones de grupos de infraestructuras en función de los patrones de comunicación.

  • Detección de perfiles y configuraciones: debería poder informar del perfil de la infraestructura, como la familia de CPU (por ejemplo, x86 o PowerPC), la cantidad de núcleos de CPU, el tamaño de la memoria, la cantidad de discos y el tamaño y las interfaces de red.

  • Detección del almacenamiento en red: debe poder detectar y perfilar los recursos compartidos de la red desde el almacenamiento conectado a la red (NAS).

  • Rendimiento: debería poder informar sobre el uso máximo y promedio de la CPU, la memoria, el disco y la red.

  • Análisis de brechas: debe poder proporcionar información sobre la cantidad y la fidelidad de los datos.

  • Escaneo de red: debe poder escanear subredes de red y descubrir activos de infraestructura desconocidos.

  • Informes: debe poder proporcionar el estado de la recopilación y el análisis.

  • Acceso a la API: debe poder proporcionar medios programáticos para acceder a los datos recopilados.

Características adicionales a tener en cuenta

  • Análisis del TCO para proporcionar una comparación de costos entre el costo local actual y el costo proyectado AWS .

  • Recomendaciones de análisis y optimización de licencias para los sistemas Microsoft SQL Server y Oracle en escenarios de rehospedaje y replataforma.

  • Recomendación de estrategia de migración (¿Puede la herramienta de descubrimiento hacer recomendaciones de tipo R de migración predeterminadas en función de la tecnología actual?)

  • Exportación de inventario (a CSV o un formato similar)

  • Recomendación sobre el tamaño correcto (por ejemplo, ¿puede mapear una AWS infraestructura de destino recomendada?)

  • Visualización de dependencias (por ejemplo, ¿se puede visualizar el mapeo de dependencias en modo gráfico?)

  • Vista arquitectónica (por ejemplo, ¿se pueden producir diagramas arquitectónicos automáticamente?)

  • Priorización de las aplicaciones (¿puede asignar peso o relevancia a los atributos de las aplicaciones y la infraestructura para crear criterios de priorización para la migración?)

  • Planificación de oleadas (por ejemplo, grupos de aplicaciones recomendados y posibilidad de crear planes de oleadas de migración)

  • Estimación del costo de migración (estimación del esfuerzo de migración)

Consideraciones sobre la implementación

Una vez que haya seleccionado y adquirido una herramienta de descubrimiento, tenga en cuenta las siguientes preguntas para impulsar las conversaciones con los equipos responsables de implementar la herramienta en su organización:

  • ¿Los servidores o las aplicaciones son gestionados por un tercero? Esto podría determinar los equipos que deben participar y los procesos a seguir.

  • ¿Cuál es el proceso de alto nivel para obtener la aprobación para implementar herramientas de descubrimiento?

  • ¿Cuál es el principal proceso de autenticación para acceder a sistemas como servidores, contenedores, almacenamiento y bases de datos? ¿Las credenciales del servidor son locales o centralizadas? ¿Cuál es el proceso para obtener las credenciales? Se necesitarán credenciales para recopilar datos de sus sistemas (por ejemplo, contenedores, servidores virtuales o físicos, hipervisores y bases de datos). Obtener las credenciales de la herramienta de descubrimiento para conectarse a cada activo puede resultar difícil, especialmente cuando estos activos no están centralizados.

  • ¿Cuál es el esquema de las zonas de seguridad de la red? ¿Están disponibles los diagramas de red?

  • ¿Cuál es el proceso para solicitar las reglas de firewall en los centros de datos?

  • ¿Cuáles son los acuerdos de nivel de servicio (SLA) de soporte actuales en relación con las operaciones del centro de datos (instalación de herramientas de detección, solicitudes de firewall)?