Narrativa del cliente

Completado

En el módulo Introducción, se ha compartido la narrativa de Tailwind Traders. El equipo de operaciones centrales y el equipo de plataforma de Tailwind Traders tiene experiencia en la administración de los centros de datos existentes de la empresa. El proyecto en curso para realizar la migración de dos de sus centros de datos a Azure ya muestra algunas curvas de aprendizaje críticas que la empresa no puede resolver con sus conjuntos de aptitudes actuales.

Restricciones importantes

En este momento, la empresa considera como puntos prioritarios la migración y cumplir las restricciones de tiempo para la salida del centro de datos. Debido a esa prioridad de la empresa, los equipos empresariales y de TI han reducido la prioridad de los requisitos de seguridad y cumplimiento a más largo plazo hasta que puedan completar el desarrollo de su plataforma principal en la nube.

Como Tailwind Traders es nuevo en la nube, pocos miembros de los equipos de operaciones, plataforma o administración de TI tienen experiencia con la nube. La empresa quiere pasar gradualmente a contar con operaciones, seguridad y gobernanza modernas, pero necesita una base en la nube que pueda escalarse para satisfacer esas necesidades a medida que se vayan haciendo más importantes.

Históricamente, Tailwind Traders ha operado exclusivamente desde la perspectiva de las operaciones centrales. Como resultado, los equipos de carga de trabajo no pueden interactuar con entornos de producción. La empresa no cuenta con una forma fácil de asignar recursos (máquinas virtuales, datos y aplicaciones) a cargas de trabajo definidas, por lo que los límites de cada carga de trabajo pueden no estar claros en ocasiones.

Alineación con zonas de aterrizaje de Azure

Los equipos de operaciones y plataforma han acordado la alineación siguiente:

  • La arquitectura conceptual de las zonas de aterrizaje de Azure servirá como visión a largo plazo para el estado futuro del entorno de nube. Todos los equipos afectados usarán esa arquitectura como base para crear habilidades en la nube y configurar el entorno de nube.
  • Los equipos usarán el acelerador de zona de aterrizaje de Azure para comenzar con la configuración del entorno.
  • Si los equipos necesitan personalizar su entorno en el futuro, usarán una de las opciones de implementación personalizadas que se alinean con la implementación inicial basada en el acelerador o que la amplían.

Desviación de la guía de zona de aterrizaje de Azure estándar

En la lista siguiente se describe cómo las restricciones han provocado que Tailwind Traders se desvíe de los principios de diseño de las zonas de aterrizaje de Azure, junto con el impacto de cada decisión:

  • Gobernanza basada en directivas: Tailwind Traders no ha automatizado sus directivas corporativas históricamente. Debido a la presión de migrar rápidamente el centro de datos, la empresa optó por minimizar la cantidad de gobernanza, incluida la implementación inicial de una zona de aterrizaje.

    La empresa también se ha comprometido a completar el módulo de Learn sobre la metodología de gobernanza de Cloud Adoption Framework después de configurar el entorno inicial. Las limitaciones del personal de TI dedicado a la migración a la nube son un impulso determinante para esta desviación. La desviación se ve aún más reforzada debido a la resistencia empresarial y de TI frente a la gobernanza de la nube completa o "Azure Ops".

  • Democratización de las suscripciones: el equipo de operaciones centrales mantendrá la responsabilidad de las operaciones de producción para todas las cargas de trabajo. Este equipo rara vez se permitirá que un equipo de cargas de trabajo tenga acceso a un entorno de producción, por lo que no sigue el principio de diseño de la democratización de las suscripciones.

    Si un equipo de cargas de trabajo requiere una desviación, el equipo de operaciones centrales considerará una zona de aterrizaje dedicada para las cargas de trabajo individuales en función de cada caso. De lo contrario, Tailwind Traders se compromete firmemente a mantener las operaciones centrales y tendrá instancias limitadas de cargas de trabajo en entornos de producción aislados (o zonas de aterrizaje de aplicaciones).

  • Modelo de servicio centrado en aplicaciones: los procesos relacionados con las interrupciones podrían considerar las cargas de trabajo, especialmente para los recursos que admiten cargas de trabajo críticas. Pero, aparte de las interrupciones, el equipo de operaciones centrales no diferencia entre cargas de trabajo y las aplicaciones para los procesos de administración de operaciones. Los procesos principales del equipo operan, administran, realizan cambios y optimizan todos los recursos de la misma manera, independientemente de los límites o la arquitectura de la carga de trabajo. Dadas las restricciones de tiempo de esta migración, no es factible que Tailwind Traders defina límites de aplicación ni que establezca un modelo de servicio centrado en aplicaciones.

Muchos de los términos de la lista anterior se explicarán en unidades posteriores de este módulo de Learn. Algunos de ellos se reflejan en las notas para crear oportunidades de enseñanza.

Estas desviaciones no nos apartan del acuerdo de alineación. Aun así, afectarán a algunas opciones al implementar el acelerador de zona de aterrizaje de Azure. Las desviaciones también afectarán al diseño de zonas de aterrizaje de aplicaciones individuales, que se implementan después de que se empiece a migrar recursos a la nube.

Estas desviaciones también requerirán que los equipos de Tailwind Traders completen módulos de Learn sobre la administración, la seguridad y la gobernanza en Cloud Adoption Framework después de implementar el entorno inicial.

Restricciones adicionales

Las siguientes restricciones adicionales podrían afectar a las decisiones de Tailwind Traders.

Operations

El equipo de operaciones central ha creado un conjunto orgánico de procesos y controles para administrar la cartera global. El equipo depende de System Center Operations Manager y Configuration Manager de Microsoft para su línea de base de operaciones.

También han integrado las mejores herramientas para las tareas de administración de máquinas virtuales, seguimiento de la administración de incidentes y configuración, supervisión de redes, operaciones de seguridad, controles de gobernanza y otras herramientas. La mayoría de estas herramientas se integran con Azure, lo que ha influido en la decisión de usar Azure como proveedor de nube principal de la empresa. El funcionamiento de estas herramientas requiere abundante mano de obra y capital.

Herramientas de operaciones

Las licencias de las herramientas de administración de operaciones (incluidos los hipervisores) consumen más del 20 % del presupuesto de costos de TI. El nuevo director de informática (CIO) ha presentado un reto al equipo que consiste en volver a evaluar esas herramientas y procesos para buscar alternativas unificadas o enfocadas a la nube. Observará la reducción de los gastos en herramientas como un indicador inicial del éxito de esta migración.

Procesos de las operaciones

El administrador de TI ha solicitado dos nuevas contrataciones para respaldar al equipo de operaciones central. Ayudarán a equilibrar la sobrecarga del equipo. En concreto, admitirán los procedimientos de continuidad empresarial y recuperación ante desastres (BCDR) y los procesos de cumplimiento de las revisiones.

La empresa no está lista para realizar un cambio a gran escala a operaciones nativas de nube, especialmente en el caso de las aplicaciones críticas. El CIO considera que la inversión en herramientas de operaciones nativas de nube ayudaría a reducir la carga del equipo de operaciones centrales, ya que desplazaría parte de esas responsabilidades al proveedor de nube.

El CIO supervisará los cambios operativos para mejorar la satisfacción de los empleados y la reducción de la carga en todo el equipo de operaciones centrales. También solicitará actualizaciones frecuentes sobre cómo afecta el plan de adopción a los esfuerzos de BCDR y de revisión.

Contrato de nivel de servicio

A pesar del trabajo duro y los costos asociados a las operaciones, el equipo no cumple periódicamente el contrato de nivel de servicio (SLA) de tiempo de actividad del 90 % para los sistemas críticos en el centro de datos principal. Es una preocupación costosa para el CIO y el director ejecutivo (CEO). El hardware obsoleto y un ciclo de actualización vencido en el centro de datos han generado interrupciones frecuentes pero breves.

Aunque la empresa haya aceptado de mala gana este contrato de nivel de servicio, el nuevo CIO no está impresionado. Independientemente del ahorro financiero, espera que el equipo de operaciones centrales ofrezca un SLA mucho más alto después de la migración.

Innovación comercial

En la narrativa del cliente del módulo Introducción, se ha presentado al equipo de innovación comercial de Tailwind Traders. Originalmente, ese equipo era una startup adquirida por Tailwind Traders. Su CEO original es ahora el director de tecnología (CTO) de Tailwind. El CTO sigue al frente de esa división como si fuera una startup, priorizando la experimentación y la innovación.

Para los procesos actuales de administración de operaciones es necesario que todas las innovaciones del equipo pasen por un proceso de versiones. El equipo de operaciones central de TI revisa la arquitectura en lo que respecta a problemas de seguridad, gobernanza y administración de operaciones. Una vez que el equipo se sienta cómodo con la solución, la publica en un entorno de producción administrado centralmente. Se espera que este proceso continúe en la nube.

Administración de identidades

Active Directory es el almacén de identidades y la herramienta principal para la autenticación y el control de acceso entre los centros de datos de Tailwind Traders. La empresa ha usado los mejores sistemas para ampliar la identidad a una solución de autenticación multifactor. También tiene identidades federadas para implementar su solución de Microsoft 365. Pero incluso así, Active Directory es la forma de administrar las identidades para Tailwind Traders.

En la nube, ahora la empresa tiene más opciones, como Microsoft Entra ID o Microsoft Entra Domain Services que se ejecutan en una infraestructura como servicio (IaaS). El equipo de operaciones central se esfuerza por comparar las opciones y elegir la mejor solución de identidad para sus planes de adopción de la nube.

Topología de red y conectividad

Tailwind Traders usa líneas de conmutación de etiquetas multiprotocolo (MPLS) para conectar sus centros de datos y almacenes físicos. Todo el tráfico de Internet se canaliza a través del centro de datos principal. Debido a conflictos del protocolo de Internet (IP) entre dos de los centros de datos, el tráfico se aísla y el enrutamiento depende de complejas tablas de enrutamiento. La conectividad externa al centro de datos o a la oficina corporativa se proporciona mediante una red privada virtual. Esa conectividad es limitada y poco aconsejable.

Los centros de datos principal y secundario tienen esquemas de direcciones IP coherentes que se mantienen y se organizan de forma clara. El tercer centro de datos incluye 50 bloques IP diferentes con poca coherencia y sin ninguna organización clara ni plan de segmentación. Los ciclos de innovación continua se limitan al tercer centro de datos, pero es posible que aparezcan problemas al definir la topología de red y el enrutamiento en la nube.

Organización de recursos

La segmentación de recursos entre cada centro de datos trata cada colección de cargas de trabajo como un gran bloque de recursos. Después, cada colección se divide por perfil de riesgo para crear segmentos aislados y controlados que permitan un flujo de red limitado entre las cargas de trabajo. Las cargas de trabajo que necesitan una conexión de red de entrada desde cualquier red sin protección se aíslan en uno o varios segmentos de red perimetral de cada centro de datos.

Más allá de esa organización básica, existen incoherencias en la base de datos de administración de configuración, por lo que es difícil saber qué recursos están asociados a cada carga de trabajo. Los propietarios de cargas de trabajo y las cadenas de escalado de incidentes están bien definidos para cargas de trabajo críticas, pero faltan para la mayoría de las cargas de trabajo restantes.

En el caso de las cargas de trabajo menos críticas, es habitual que el propietario identificado sea un antiguo empleado de Tailwind Traders. A menudo, la asignación de configuración hace referencia a máquinas virtuales que se han finalizado. Del mismo modo, más del 30 % de los recursos admitidos no se asignan claramente a una sola carga de trabajo. Durante la migración, la empresa necesitará procedimientos para asegurar el análisis de las dependencias y la organización adecuada de los recursos.