SAP Hana - le monstre des correctifs

Si l'on regarde les cycles de patch des bases de données importantes pour le marché et, par conséquent, la concurrence Hana, on obtient une image intéressante sur une base mensuelle. Les fabricants d'autres bases de données font également des erreurs ("releases retirées"), de sorte que les cycles de release prévus ne peuvent pas être respectés comme prévu.

Pour SAP, on ne peut certes pas partir du principe que c'est planifié, mais le passé confirme le nombre de versions retirées. Aucune autre de ces bases de données n'a une cadence aussi élevée.

De manière optimiste, on peut dire que "le développement de Hana progresse rapidement". Cependant, la plupart des observateurs et des utilisateurs concluent que trop d'erreurs ont été commises par le passé et qu'elles ne sont pas dues à de nouvelles fonctionnalités.

Selon SAP, les révisions dites de maintenance ne font que corriger des erreurs et n'activent pas de nouvelles fonctionnalités. Si le nombre de ces versions de maintenance augmente, cela met en évidence le manque de qualité du logiciel.

Cela est particulièrement visible dans le cas de SPS12. Certains clients l'ont également confirmé et les représentants de SAP ont compris et accepté ce point critique. Depuis les dernières révisions (nettement à partir de 122.09), les erreurs ont énormément diminué.

Dans le graphique, qui a été réalisé à partir de plus de 400 des notes officielles de SAP, on voit clairement combien d'erreurs sont contenues dans une révision Hana et, de manière beaucoup plus dramatique, qu'aucune solution de contournement n'est disponible ou proposée pour environ 35% d'entre elles !

Selon l'importance du bug, il faut alors passer à la révision supérieure. De nombreux clients se plaignent justement de ce comportement, car ils passent d'un bug à l'autre. Cela implique un énorme travail d'administration et de test en interne.

L'aspect temporel est un énorme problème, surtout pour les grandes entreprises qui ne mettent généralement en production qu'une ou deux versions par an. Il faut toutefois faire la différence entre les maintenances planifiées (nouvelles fonctionnalités, améliorations des performances, fin du support ou dépendances avec la version SAP) et les maintenances non planifiées (problèmes de stabilité, résultats erronés, problèmes de cohérence, fonctionnalités défectueuses).

En moyenne, il faut entre trois et six semaines pour effectuer tous les tests de régression, de sauvegarde, de restauration et de clustering pour une nouvelle version de base de données, sans compter le temps de préparation et de coordination.

Mais lorsque la prochaine révision de Hana est publiée quatre à cinq semaines plus tard, il est impossible de sortir de cette spirale de tests. C'est là que SAP met à disposition, via "Capture and Replay" (à partir de SPS12), une nouvelle fonction nécessaire qui minimise et optimise l'effort de test.

On n'a plus besoin d'utilisateurs de test/clés explicites qui testent la nouvelle version de manière fonctionnelle et avec une faible charge seulement, mais on peut reproduire 1:1 la charge de travail du système de production sur un système de test.

30 minutes pour changer de version ?

Dans l'environnement Hana, SAP vante souvent un temps de maintenance de seulement 30 minutes pour un changement de version. Mais on oublie de dire qu'il s'agit d'une simple procédure technique.

Les travaux préparatoires nécessaires et suffisants, les tests, les contrôles de cohérence ou même la vérification des dépendances ne sont pas inclus, car ils prennent de loin le plus de temps.

Pour vérifier ce dernier point, SAP ne met malheureusement pas à la disposition des clients un ensemble d'outils digne de ce nom. Cela signifie que pour chaque changement de version, il faut vérifier plusieurs centaines de références pour savoir si la fonction est utilisée et si cela s'applique à la future version de la base de données utilisée.

Il n'existe pas, à l'heure actuelle, de système de recherche, de filtrage ou de catégorisation des notes Hana-SAP. Au final, cela complique la tâche de l'administrateur et prolonge ainsi le temps de test pour d'éventuelles solutions de contournement et des bugs qui pourraient tout de même être contenus dans la nouvelle version visée.

Les collaborateurs SAP présents n'ont pas pu répondre à la question de savoir si un tel outil serait livré à l'avenir par SAP. Ce point critique a également été pris en compte, mais n'a pas pu être entièrement clarifié à ce jour.

QPCM a développé une solution possible avec l'iHAL (intelligent Hana Assurance List), indépendamment de SAP, afin que la recherche, la vérification et la pondération des indices Hana, qui prennent plusieurs jours, ne représentent pas une charge de travail trop importante.

En saisissant la version source et la version cible, l'administrateur peut utiliser iHAL pour déterminer puis évaluer combien de bogues sont liés à telle ou telle fonctionnalité et, sur la base de la pondération, s'il est judicieux de mettre en place une solution de contournement ou s'il vaut mieux attendre une des prochaines révisions.

Cet outil de contrôle Hana sera disponible à l'avenir sur www.qpcm.de. (Si vous êtes intéressé ou si vous souhaitez une évaluation détaillée, contactez jens.gleichmann@qpcm.de par mail).

Tous les bugs ne conduisent pas à une mise à jour

Une grande partie des erreurs Hana publiées par SAP sont de nature grave et affectent la stabilité de la base de données Hana ainsi que la cohérence des données. Ainsi, chaque mise à jour devrait être mûrement réfléchie et vérifiée avant d'être techniquement appliquée.

Le graphique donne un aperçu de la répartition des catégories et du nombre de bugs Hana associés. Ce qui est important, c'est le message clé de la contribution d'impulsion de SAP : "Tous les bugs ne doivent pas obligatoirement conduire à une mise à jour" !

Il faut donc évaluer si la fonctionnalité concernée ainsi que son impact mettent en danger le fonctionnement, la stabilité et l'intégrité de l'ensemble du système. Ce n'est qu'en sachant cela que l'on peut répondre en toute conscience à la question "quel est le bon moment pour une mise à jour/une mise à niveau".

Or, à l'heure actuelle, c'est précisément cette transparence qui fait défaut aux clients et aux utilisateurs. Dans ces conditions, la question dont discutent presque tous les responsables informatiques et les administrateurs se pose inévitablement : Hana est-il déjà "Mission critical ready" ?

En raison de ces cycles de release très courts ainsi que des efforts importants qui y sont liés et de la quantité de bugs encore ouverts malgré tout par rapport à d'autres bases de données, la base de données Hana mérite aujourd'hui le surnom de "monstre des patchs", déjà connu de nombreux clients.

L'événement a été très constructif, tant pour les fabricants que pour les clients, et SAP s'est montré ouvert aux critiques. Le géant du logiciel de Walldorf a déjà réagi ces dernières semaines et a nettement stabilisé les révisions de Hana.

Cet événement a permis de poser les bases du groupe de travail DSAG "Hana en entreprise" qui a été demandé par de nombreux clients fin juin.