SAP Hana: el monstruo de los parches

Si se observan los ciclos de parches de las bases de datos relevantes en el mercado y, por consiguiente, de la competencia de Hana, surge mensualmente un panorama interesante. Los fabricantes de otras bases de datos también cometen errores ("lanzamientos retirados"), por lo que los ciclos de lanzamiento previstos no pueden cumplirse según lo previsto.

Con SAP, no se puede dar por hecho lo previsto, pero el pasado confirma el número de versiones retiradas. Ninguna otra base de datos tiene una frecuencia tan alta.

Siendo optimistas, se puede decir: "El desarrollo de Hana avanza rápidamente". Sin embargo, la mayoría de los observadores y usuarios concluyen que ha habido demasiados errores en el pasado que no pueden atribuirse a las nuevas funciones.

Según SAP, en las llamadas revisiones de mantenimiento sólo se corrigen errores y no se activan nuevas funciones. Si aumenta el número de estas versiones de mantenimiento, se hace visible la falta de calidad del software.

Esto es especialmente evidente con SPS12. Algunos clientes también lo han confirmado y los representantes de SAP han comprendido y aceptado este punto de crítica. Desde las últimas revisiones (claramente a partir de la 122.09) los errores han disminuido enormemente.

En el gráfico, creado a partir de más de 400 de las notas oficiales de SAP, se puede ver claramente cuántos errores contiene una revisión de Hana y, lo que es mucho más dramático, ¡que no existe ni se ofrece ninguna solución para alrededor del 35 por ciento de ellos!

En función de la ponderación del fallo, es necesario pasar a la revisión inmediatamente superior. Muchos clientes se quejan precisamente de este comportamiento, ya que pasan de un fallo al siguiente. Esto supone un enorme esfuerzo interno de administración y comprobación.

El aspecto temporal es un gran problema, especialmente para las grandes empresas que normalmente sólo ponen en producción una o dos versiones al año. En este caso, sin embargo, hay que diferenciar entre mantenimiento planificado (nuevas funciones, mejoras de rendimiento, fin de soporte o dependencias de la versión SAP) y no planificado (problemas de estabilidad, resultados incorrectos, problemas de coherencia, funcionalidades defectuosas).

Por término medio, se tarda entre tres y seis semanas en realizar todas las pruebas de regresión, copia de seguridad, recuperación y clúster de una nueva versión de la base de datos, sin ningún esfuerzo de preparación y coordinación.

Sin embargo, cuando la siguiente revisión de Hana se publica al cabo de sólo cuatro o cinco semanas, es imposible salir de esta espiral de pruebas. SAP ofrece ahora una nueva función necesaria a través de "Capture and Replay" (a partir de SPS12) que minimiza y optimiza el esfuerzo de prueba.

Ya no necesita usuarios de prueba/clave explícitos que prueben la nueva versión funcionalmente y con poca carga, sino que puede asignar la carga de trabajo del sistema productivo 1:1 en un sistema de prueba.

¿30 minutos para el cambio de versión?

En el entorno Hana, SAP anuncia a menudo un esfuerzo de mantenimiento de sólo 30 minutos para una actualización de versión. Sin embargo, omiten mencionar que solo se trata de un procedimiento puramente técnico.

Esto no incluye el trabajo preparatorio necesario y suficiente, las pruebas, las comprobaciones de coherencia o incluso la comprobación de las dependencias, ya que son, con diferencia, los que más tiempo llevan.

Lamentablemente, SAP no proporciona a los clientes un conjunto de herramientas razonable para comprobar esto último. Esto significa que para cada cambio de versión hay que comprobar varios cientos de referencias para ver si la función está en uso y si se aplica a la versión de la base de datos que se utilizará en el futuro.

En esta fase no hay búsqueda, filtro ni categorización de las notas SAP de Hana. En definitiva, dificulta el trabajo del administrador y, por tanto, prolonga el esfuerzo de comprobación de posibles soluciones y errores que aún puedan incluirse en la nueva versión prevista.

Los empleados de SAP presentes no pudieron responder si SAP ofrecería una herramienta de este tipo en el futuro. Este punto de crítica también fue abordado, pero no pudo aclararse plenamente hasta ahora.

QPCM ha desarrollado una posible solución con la iHAL (intelligent Hana Assurance List) independientemente de SAP, para que los días de búsqueda, comprobación y ponderación de notas de Hana no supongan tanto esfuerzo.

Al introducir la versión de origen y la de destino, el administrador puede utilizar iHAL para determinar y, a continuación, ponderar cuántos errores están asociados a cada característica y, en función de la ponderación, evaluar si tiene sentido utilizar una solución alternativa o sería mejor esperar a una de las próximas revisiones.

Esta herramienta de prueba de Hana estará disponible en el futuro en www.qpcm.de. (Si está interesado o desea una evaluación detallada, póngase en contacto con jens.gleichmann@qpcm.de).

No todos los errores conducen a una actualización

La mayoría de los errores de Hana publicados por SAP son de carácter grave y pueden afectar a la estabilidad de la base de datos de Hana, así como a la coherencia de los datos. Esto significa que cada actualización debe considerarse y comprobarse cuidadosamente antes de aplicarla técnicamente.

El gráfico ofrece una visión general de la distribución de las categorías y el número asociado de errores de Hana. La afirmación central de la contribución de impulso de SAP es importante: "¡No todos los errores deben conducir necesariamente a una actualización!

Por tanto, hay que sopesar si la función afectada y su impacto ponen en peligro el funcionamiento, la estabilidad y la integridad del sistema en su conjunto. Sólo con este conocimiento se puede responder con la conciencia tranquila a la pregunta "¿cuándo es el momento adecuado para actualizar?

Pero a día de hoy, es precisamente esta transparencia la que falta para clientes y usuarios. En estas circunstancias, surge inevitablemente la pregunta que se plantean casi todos los responsables y administradores de TI: ¿Está Hana ya "preparado para misiones críticas"?

Debido a estos ciclos de lanzamiento tan cortos, así como al gran esfuerzo asociado y a la cantidad de errores aún abiertos en comparación con otras bases de datos, la base de datos Hana merece el título de "el monstruo de los parches", que ya es conocido entre muchos clientes.

El evento fue muy constructivo tanto para los fabricantes como para los clientes y SAP abordó abiertamente las críticas. El gigante del software de Walldorf ya ha reaccionado en las últimas semanas y ha estabilizado considerablemente las revisiones de Hana.

Este evento sentó las bases para el grupo de trabajo del DSAG "Hana en Operaciones" a finales de junio, que fue solicitado por muchos clientes.