El día después de la puesta en marcha de Hana
Para muchos, el paso a Hana y S/4 supone un cambio enorme, porque no sólo cambia la base de datos, sino también el sistema operativo subyacente. Hay que revisar a fondo el funcionamiento anterior y, por tanto, el manual de instrucciones.
Aquí empieza un tema que muchos suelen descuidar en sus proyectos, ya que muchos administradores carecen de relevancia práctica en el nuevo entorno y, por tanto, sólo descubren algunos escollos durante la implantación.
En la mayoría de los casos, aún no existen conceptos para los paquetes de trabajo aprovisionamiento del sistema en Linux, copias del sistema con Hana, supervisión, sistema de transporte de objetos Hana, autorizaciones, mantenimiento cíclico o para la verificación y validación de nuevas revisiones de Hana.
No hay que subestimar el esfuerzo que supone el mantenimiento en particular, ya que muchos componentes tienen interdependencias que no había que tener en cuenta de antemano.
Además de las conocidas restricciones relativas al almacenamiento, el servidor y el sistema operativo, también existen otras limitaciones. Como resultado, muchos equipos (servidor, sistema operativo, bases de datos, SAP Basis) tienen que coordinarse aún más estrechamente que antes.
Para producir el menor número posible de tiempos de inactividad, es aconsejable sincronizar los ciclos de mantenimiento de los componentes. Suse ya lo ha integrado con gran éxito en "Suse Linux Enterprise Server for SAP Applications" con el soporte ampliado del producto.
Aquí, por ejemplo, el fin de mantenimiento de Hana 2 SPS01 se vinculó a SLES for SAP 12 SP1. A continuación, SLES for SAP 12 SP2 y Hana 2 SPS02 se quedarán sin mantenimiento en abril de 2019.
Con este mantenimiento, siempre se plantea la cuestión de la verificación técnica y la validación funcional. La mayoría de los usuarios clave apenas tienen capacidad para realizar pruebas además de su trabajo de proyecto y sus operaciones normales. Aquí es donde entra en juego la función "Capture & Replay", que es gratuita, es decir, ya está incluida en la licencia de Hana.
Esto le permite ejecutar la carga de trabajo generada por las sentencias SQL 1:1 en otro sistema. Así, si su sistema ERP productivo tiene 2000 usuarios, puede volver a ejecutar todas las transacciones en un periodo de tiempo definido. Los únicos requisitos son una copia de seguridad del sistema productivo y un registro de dicho periodo.
Esta copia de seguridad se importa a otro sistema, por ejemplo el sistema de control de calidad (QAS). Aquí se pueden mapear varias iteraciones de cambios (parche Hana/Linux, cambios de parámetros) y comparar los resultados de cada ejecución, por ejemplo si las consultas fueron más rápidas o más lentas o si hubo incluso algún error.
Con este procedimiento, se puede relevar a los usuarios clave e incluso realizar una prueba de carga con datos productivos que incluya 2000 usuarios o más. El sistema no tiene que "desecharse" al final, sino que puede volver a incorporarse al paisaje como QAS con la reelaboración de la copia del sistema. Por lo tanto, tiene mucho sentido vincular estos trabajos de mantenimiento a la planificación existente de las copias del sistema.
¿Qué no puede hacer "Capture & Replay"? No es posible probar un cambio de kernel SAP o un cambio de versión.
Conclusión
Debido a la complejidad y las dependencias de los componentes del sistema Hana, la necesidad de automatizar parcialmente las pruebas es especialmente acuciante. Debido al aumento de los requisitos, la disminución del número de ventanas de mantenimiento y los ajustados ciclos de lanzamiento, la optimización del proceso de mantenimiento es más que deseable.
Si combina esto con el procedimiento de "Mantenimiento con tiempo de inactividad casi nulo" (Hana System Replication + DBSL Suspend) y un Rolling Kernel Switch (RKS), también podría llevar a cabo el mantenimiento durante la semana sin apenas afectar al usuario final.
