¿O se puede? Por supuesto, la migración de sistemas SAP es un proceso complejo y meticuloso, para el cual es fundamental la colaboración efectiva de todos los participantes. Y si la migración se realiza en un corto período, la tarea se complica aún más. No todos se atreven a hacerlo. Puede haber varias razones. Por ejemplo, el proceso en sí es prolongado y organizativamente complicado. Además, existe el riesgo de paradas no planificadas de los sistemas. O los clientes no están seguros de que, tras pasar por esta operación, obtendrán beneficios proporcionales a los esfuerzos invertidos. Sin embargo, hay excepciones.
A continuación, hablaremos sobre las dificultades que enfrentan los clientes durante el proceso de migración y mantenimiento de sistemas SAP, discutiremos por qué los estereotipos no siempre se ajustan a la realidad y compartiremos un caso de cómo logramos migrar los sistemas de un cliente a una nueva infraestructura en poco más de tres meses.
Hosting de sistemas SAP
Hace solo cinco años, era difícil imaginar que los clientes comenzaran a utilizar de manera masiva recursos de hosting para aplicaciones SAP. En la mayoría de los casos, se implementaban on-premise. Sin embargo, con el desarrollo de modelos de outsourcing y del mercado de servicios en la nube, la mentalidad de los clientes ha comenzado a cambiar. ¿Cuáles son los argumentos que influyen en la elección de la nube para SAP?
- Para los principiantes que apenas están planeando la implementación de SAP, la infraestructura en la nube representa prácticamente una elección estándar: escalabilidad de recursos según las necesidades actuales del sistema y la falta de deseo de desviar recursos hacia el desarrollo de competencias no centrales.
- En empresas con un amplio paisaje sistémico, mediante el hosting de sistemas SAP, los CIO alcanzan un nivel cualitativamente diferente en la gestión de riesgos, ya que el socio es responsable del SLA.
- El tercer argumento más común es el alto costo de construir una infraestructura para realizar escenarios de alta disponibilidad y DR.
- Factor 2027: el anunciado fin del soporte de sistemas obsoletos por parte del vendedor en 2027. Esto implica la migración de la base de datos a HANA, lo que conlleva gastos en modernización y adquisición de nuevas capacidades computacionales.
El mercado de hosting SAP en Rusia se puede considerar actualmente bastante maduro. Esto ofrece amplias oportunidades para los clientes que desean cambiar sus plataformas de hosting. Sin embargo, tales proyectos pueden justificar las preocupaciones de las empresas debido a la complejidad del proceso de migración. Esto lleva a los clientes a tener mayores expectativas de los proveedores de servicios, que deben poseer no solo competencias excepcionales en hosting y soporte de sistemas SAP, sino también una experiencia exitosa en el campo de la migración.
¿Cuáles son las dificultades al cambiar de hosting SAP?
Existen diferentes tipos de hosting. La discrepancia entre el nivel de servicio prometido, un montón de "pero" y estrellas con advertencias en letra pequeña, la limitación de recursos y capacidades proveedor de alojamiento, la falta de flexibilidad en la comunicación con el cliente, la burocracia, las limitaciones técnicas, la baja competencia de los especialistas de soporte técnico, así como muchos otros matices, son solo una pequeña parte de los escollos con los que pueden enfrentarse los clientes en el proceso de explotación de sus sistemas empresariales en infraestructuras externalizadas. A menudo, para el cliente, todo esto permanece en la sombra, en la complejidad de un contrato de varias páginas, y emerge solo durante el uso de los servicios.
En algún momento, al cliente le queda claro que el nivel de servicio que recibe está muy por debajo de sus expectativas. Esto actúa como un catalizador para buscar soluciones a la situación y, si no tiene éxito, cuando los problemas se acumulan hasta el límite y se vuelve realmente doloroso, comienzan acciones activas para explorar alternativas en dirección al cambio de proveedor.
¿Por qué esperar hasta el último momento? La razón es simple: el proceso de traslado de sistemas no siempre es transparente y comprensible para los clientes. A los clientes les resulta difícil evaluar los riesgos reales asociados con el proceso de migración. Se puede decir que la migración para los clientes es como una especie de caja negra: no queda claro el costo, el tiempo de inactividad de los sistemas, los riesgos y cómo mitigarlos, y en general es oscuro y aterrador. Aquí es así, si no funciona, habrá consecuencias para los altos directivos y los ejecutores.
SAP es un sistema de nivel empresarial, complejo y, por decirlo de alguna manera, no barato. La implementación, personalización y mantenimiento de estos sistemas requieren presupuestos significativos, y su disponibilidad y correcto funcionamiento son vitales para la operación de la empresa. Ahora imagina las consecuencias de detener una gran producción. Estas son pérdidas financieras que pueden contarse en cifras con muchos ceros, así como riesgos reputacionales y otros, igualmente importantes.
Analizaremos las complejidades que pueden surgir en cada etapa del caso de migración de sistemas SAP de uno de nuestros clientes.
Preparación y diseño
La migración es una fórmula con muchos componentes diferentes. Uno de los más importantes es la etapa de diseño y preparación de la infraestructura objetivo (nueva).
Necesitamos sumergirnos en la implementación existente de los sistemas y su arquitectura. En la infraestructura objetivo, en algunos casos replicamos las soluciones existentes, en otros las complementamos y mejoramos, y en algunos casos rediseñamos, planificamos y elegimos soluciones para garantizar la disponibilidad y resiliencia, además de consolidar al máximo todos los recursos.
Durante el proceso de diseño, se llevaron a cabo muchos ejercicios diferentes que, al final, permitieron prepararnos lo mejor posible para la migración y tener en cuenta todos los matices y posibles obstáculos (de los que hablaremos más adelante).
Lo que obtuvimos como resultado fue una infraestructura de nube privada diseñada a medida, basada en nuestro centro de datos:
- servidores físicos dedicados para SAP HANA;
- plataforma de virtualización VMware para servidores de aplicaciones y servicios de infraestructura;
- canales de comunicación duplicados entre centros de datos para L2; VPN;
- dos sistemas de almacenamiento principales para separar la producción y 'todo lo demás';
- Copia de seguridad en base a Veritas Netbackup con un servidor separado, una estante de discos y una biblioteca de cintas.
Así es como realizamos todo esto desde el punto de vista técnico.
SAP
- Para un uso efectivo de los almacenes de HANA productivos, utilizamos discos compartidos sin replicación del sistema de base de datos por parte de SAP. Todo esto se configuró en un clúster Activo-Standby de SUSE HAE basado en Pacemaker. Sí, el tiempo de recuperación es un poco más largo que con la replicación, pero así logramos una reducción del espacio en el sistema de almacenamiento a la mitad y, como resultado, se ahorra presupuesto para el cliente.
- Se rechazaron los entornos de preproducción de los clústeres HANA, pero técnicamente se replicó la configuración de producción.
- Los entornos de prueba y de desarrollo se distribuyeron en varios servidores sin clústeres en la configuración de MCOS.
- Se virtualizaron todos los servidores de aplicaciones y se alojaron en VMware.
Redes
- Se separaron físicamente los contornos de las redes de gestión y las redes productivas con pilas de conmutadores, dirigiendo las productivas hacia el centro de datos del cliente.
- Se preveía un número suficiente de interfaces de red para no mezclar grandes flujos de tráfico.
- Para la transmisión de datos desde el almacenamiento, se establecieron fábricas SAN FC clásicas.
Sistema de almacenamiento
- La carga productiva y de preproducción de SAP se dejó en un arreglo all-flash.
- Los entornos de prueba de los desarrolladores y los servicios de infraestructura se colocaron en un arreglo híbrido separado.
SRK
- Se hizo sobre la base de Veritas Netbackup.
- Se añadieron algunos scripts integrados para hacer copias de seguridad de las configuraciones de MCOS.
- Las copias operativas se colocaron en un estante de discos para recuperar rápidamente, y para el almacenamiento a largo plazo usamos cintas.
Monitoreo
- Todo el hardware, el sistema operativo y SAP se introdujeron en Zabbix.
- Se recopilaron numerosos paneles útiles en Grafana.
- Al generarse una alerta, Zabbix puede abrir un ticket en el sistema de gestión de incidentes, que en nuestro caso está implementado en Jira. También se duplica la información en un canal de Telegram.
Telegram
Estado general de HANA
Estado del servidor de aplicaciones SAP:
Servicios de infraestructura
- Para mantener los espacios de nombres internos, se levantó un clúster de servidores DNS que se sincroniza con los servidores del cliente.
- Se hizo un servidor de archivos separado para el intercambio de datos.
- Para almacenar diferentes configuraciones, añadimos Gitlab.
- Para información sensible, utilizamos HashiCorp Vault.
Proceso de migración
En general, el proceso de migración consiste en las siguientes etapas:
- preparación de toda la documentación del proyecto necesaria;
- negociaciones con el proveedor actual – resolución de cuestiones organizativas;
- compra, entrega e instalación del nuevo equipo para el proyecto;
- migración de prueba y ajuste del proceso;
- traslado de sistemas, migración en vivo.
A finales de octubre de 2019 firmamos el contrato, luego diseñamos la arquitectura y, tras su aprobación por parte del cliente, ordenamos el equipo necesario.
Lo que hay que tener en cuenta en primer lugar son los plazos de entrega del equipo. En promedio, la entrega del hardware certificado para SAP NAHA, que cumple con los requisitos del proveedor de software para plataformas de hardware, tarda entre 10 y 12 semanas. Y considerando la estacionalidad (la implementación del proyecto caía justo en Año Nuevo), este plazo podría extenderse un mes más. Por lo tanto, fue necesario acelerar al máximo el proceso: trabajamos con el distribuidor-proveedor, acordamos un envío acelerado por avión (en lugar de rutas terrestres y marítimas).
Noviembre y diciembre se dedicaron a preparar la migración y a recibir parte del equipo. Realizamos la preparación en un entorno de prueba en nuestra nube pública, donde perfeccionamos todos los pasos básicos y detectamos posibles dificultades y problemas:
- preparamos un plan detallado de interacción de los miembros de los equipos de proyecto con cronogramas por minuto;
- construimos un entorno de prueba para las bases de datos y los servidores de aplicaciones de manera similar a la infraestructura objetivo;
- configuramos los canales de comunicación necesarios y los servicios de infraestructura para verificar el funcionamiento de las integraciones;
- ensayamos los escenarios de cutover;
- la nube también nos ayudó a crear plantillas preconfiguradas de máquinas virtuales, que luego simplemente importamos y desplegamos en el paisaje objetivo.
Poco antes de las fiestas de Año Nuevo, llegó a nosotros el primer lote de equipos. Esto permitió desplegar parte de los sistemas en hardware real. Como no llegó todo, conectamos equipos de repuesto, cuya entrega logramos acordar con el vendedor y los distribuidores. Recibimos los restos de la infraestructura objetivo ya en la etapa final.
Para cumplir con los plazos, nuestros ingenieros tuvieron que sacrificar las vacaciones de Año Nuevo y comenzar a trabajar en la preparación de la infraestructura objetivo el 2 de enero, en pleno apogeo de las celebraciones. Sí, a veces esto sucede, cuando hay prisa y no hay otras opciones. En juego estaba la operatividad de los sistemas de los que depende la viabilidad de la empresa.
El orden general de la migración fue el siguiente: en primer lugar, los sistemas menos críticos (paisaje de desarrollo, paisaje de prueba), luego, los sistemas productivos. La etapa final de la migración se llevó a cabo a fines de enero y principios de febrero.
El proceso de migración fue detallado minuto a minuto. Se trata de un plan de corte con una lista de todas las tareas, tiempos de ejecución y responsables. Todos los pasos ya habían sido ensayados en la migración de prueba, por lo que en la migración en vivo solo fue necesario seguir el plan y coordinar el proceso.
La migración se realizó por sistemas en varias etapas. En cada etapa, se trabajaron dos sistemas.
El resultado de un sprint de tres meses fue un sistema completamente funcional en el centro de datos de KROK. En general, se obtuvo un resultado positivo gracias al trabajo conjunto, donde la contribución y dedicación de todos los participantes del proceso fueron máximas.
El papel del cliente en el proyecto
Comunicarme con el proveedor que nuestro cliente dejaba no fue sencillo. Y es comprensible, eran los últimos en la lista de interesados en el éxito del proyecto. El cliente asumió las tareas de escalamiento y resolución de todas las cuestiones de comunicación y lo hizo con un 100500% de éxito. Por esto, le agradecemos especialmente. Sin su participación activa en el proceso, el resultado del proyecto podría haber sido muy diferente.
Debido a la formalidad de los procesos del antiguo proveedor, especialistas, que en el sentido más literal estaban lejos de los problemas de su cliente en ese momento, se encargaban del soporte de la infraestructura. Por ejemplo, el proceso de exportación de la misma base de datos podía tardar entre una hora y cinco. En ese momento parecía que había alguna magia, un secreto que nunca se nos reveló. Probablemente, los ingenieros de soporte técnico se entregaban a la meditación, olvidando que en algún lugar de la lejana Rusia había plazos, ingenieros sin ensaladas navideñas, y un cliente que lloraba y sufría.
Resultados del proyecto
El acto final de la migración fue la transferencia de sistemas al soporte.
Ahora ofrecemos un servicio de ventanilla única para consultas del cliente y cerramos toda la carga de tareas de mantenimiento de componentes de infraestructura y SAP basis junto con nuestro socio — itelligence. El cliente ha estado en la nube privada durante seis meses. Aquí está la estadística de los casos de servicio durante este tiempo:
- 90 incidentes (20% resueltos sin involucrar al cliente)
- Resueltos dentro del SLA – 100%
- Paradas no planificadas de sistemas – 0
Si tiene tareas similares a las que enfrentó nuestro cliente y desea saber más sobre cómo resolverlas, escríbanos a: ahaidukov@croc.ru
Fuente: habr.com
