15 septembre 2022 Pourquoi les copies de système et l'anonymisation des données vont-elles de pair ?
Dans le cycle de vie SAP®, il est toujours nécessaire de mettre en place un système de projet ou de sandbox. Cela peut être nécessaire pour des tests de performance, de mise à jour, de validation. Mais aussi pour d'autres exigences comme un déménagement de système. Que ce soit sur un matériel plus récent, dans un autre centre serveur ou dans le cloud.
Les systèmes de staging non productifs existants, tels que les systèmes de qualité, de test, de formation et de développement des lignes régulières, ne sont pas toujours adaptés ou conçus pour être utilisés dans le cadre de changements importants, tels que des projets de grande envergure ou des mises à jour logicielles complexes. Dans ces cas, les organisations ont volontiers recours à des systèmes sandbox qui peuvent être modifiés à volonté et, en cas de doute, détruits logiquement, sans que cela n'ait de répercussions sur la ligne régulière.
L'utilité de ces systèmes de projet et de sandbox augmente avec leur disponibilité, même à court terme, et leur capacité à reproduire les propriétés logiques de la ligne régulière. En ce qui concerne ce dernier point, la mise à disposition de ces systèmes n'implique généralement pas la création de systèmes standard vides, mais de clones de systèmes, c'est-à-dire de répliques complètes des systèmes de la ligne régulière.
En fonction de l'architecture, de la complexité et de la taille de l'environnement SAP, cela peut être une tâche très importante, et cette procédure implique généralement un grand nombre d'activités manuelles qui peuvent durer des heures, voire des jours. S'il s'agit en outre d'environnements de plusieurs systèmes connectés, ces temps s'additionnent volontiers dans le cadre d'un clone paysager pour constituer une véritable charge de travail pour les unités organisationnelles exécutantes, pour laquelle il n'y a jamais de "bon" moment. Les clones de systèmes et de paysages bloquent des ressources importantes et coûteuses : les professionnels internes ou externes de SAP Basis.
Cela dépend beaucoup des exigences. S'il s'agit de mettre en place un système aussi standardisé que possible, le choix se portera probablement sur une nouvelle installation from-the-scratch.
Mais comme les systèmes SAP® sont adaptés au quotidien et s'écartent donc de plus en plus du standard, cette solution n'est pas toujours adaptée. Ces écarts ou "saletés" peuvent justement être pertinents pour d'autres exigences de test. Un test de performance sur un système "propre" fraîchement mis en place ne peut pas être comparé à un système utilisé avec toutes ses quantités de données et exactement la répartition ou la structure des données.
Il en va de même pour les tests de mise à jour ou de validation. Les paramètres adaptés lors de l'utilisation ou les programmes installés peuvent empêcher une simple mise à jour et c'est précisément l'objectif d'un tel test de mise à jour. Trouver un processus de mise à jour propre afin de mettre à jour le système existant avec un temps d'arrêt aussi court que possible.
Les dépenses liées à la mise en place des systèmes jouent également un rôle dans la réflexion.
L'automatisation permet d'alléger considérablement la charge de travail des personnes chargées de la mise en œuvre et, grâce à l'automatisme, la mise en place peut être facilement répétée.
Les installations peuvent généralement être automatisées à l'aide de fichiers de paramètres. Néanmoins, l'installation doit être effectuée et cela prend généralement plus de temps que de dupliquer, c'est-à-dire de cloner un système existant. A quoi faut-il faire attention ?
Dans le cadre du clonage ou par la suite, il faut toutefois tenir compte du fait que le système ne peut pas être simplement repris 1 à 1. Il s'agit de choses évidentes comme le nom de l'ordinateur. Mais il faut également tenir compte des informations du système. Il s'agit d'informations infrastructurelles telles que les imprimantes ou les connexions et interfaces avec d'autres systèmes ainsi que les tâches exécutées dans le système SAP.
Mais il y a encore d'autres points à prendre en compte. Les testeurs doivent-ils être autorisés à voir les "vraies données" ? Il faut donc tenir compte des exigences de sécurité, comme par exemple le RGPD. Il s'agit donc maintenant de modifier les données de manière à ce qu'aucune information pertinente ne puisse être lue, mais après la modification, la répartition ou la structure des données doit encore correspondre à l'original, sinon les résultats des tests ne seront pas fiables, par exemple pour les tests de performance.
Ici, il est surtout important que le système dupliqué corresponde le plus possible au système source et que le temps d'arrêt nécessaire à la mise en place du système dupliqué soit réduit au minimum.
Il s'avère que certaines questions doivent être clarifiées au préalable et que la voie à suivre pour une mise en œuvre optimale doit être définie sur la base des exigences.
Libelle IT Group peut vous aider en tant qu'expert avec 27 ans d'expérience. Il peut également vous fournir des outils pour réaliser cette mise en œuvre de manière optimale.