FR 3148504 A1 20241108 FR 2304418 A 20230503 L’invention concerne un procédé de génération de perturbations dans un réseau pour en vérifier sa robustesse, ledit réseau comprenant une pluralité d’infrastructures et de services le procédé comprenant - l’obtention (E1) d’une base de données comprenant des données de configuration pour la pluralité d’infrastructures et de services, - la détermination (E2) d’une valeur maximale d’indisponibilité de ladite infrastructure et des services, et si ladite valeur maximale d’indisponibilité est positive (E3) : - le déploiement (E4) d’un nouveau service, l - la transmission (E5) dans le réseau de données de perturbations de l’infrastructure réseau et des services déployés, les perturbations étant déterminées à partir d’au moins les données de configuration de la base de données et de la valeur maximale d’indisponibilité calculée, - la mise à jour (E6) de ladite valeur maximale d’indisponibilité suite aux perturbations. Figure pour l’abrégé : Fig. 1. dispositif et procédé de génération de perturbations dans un réseau. L’invention concerne le domaine de la transmission de perturbations dans des infrastructures réseau afin d’en tester sa robustesse Il existe aujourd’hui des solutions de déploiement de perturbations mais ces scénarios sont principalement applicables à des fournisseurs de services (CSP) ou des infrastructures qui sont déployées sur un seul environnement d’une même entité administrative. Cependant, avec le déploiement des applications à distance, situées dans le « cloud », et le déploiement d’instances sur des réseaux de périphérie, « edge cloud », il n’est pas possible de lancer des perturbations prenant en compte les contraintes à la fois des infrastructures réseau et des fournisseurs de service car notamment la connaissance de ces contraintes n’est pas partagée entre fournisseurs de services et gestionnaires d’infrastructure. Une solution permettant de tester une infrastructure réseau partagée entre un opérateur d’infrastructure et des fournisseurs de service en envoyant des perturbations est donc souhaitée. La présente invention concerne un procédé de génération de perturbations dans un réseau pour en vérifier sa robustesse, ledit réseau comprenant une pluralité d’infrastructures et de services déployés et hébergés dans ledit réseau, lesdits services étant fournis par au moins un fournisseur de services, le procédé comprenant - l’obtention d’au moins une base de données comprenant des données de configuration pour la pluralité d’infrastructures et de services, - la détermination d’une valeur maximale d’indisponibilité de ladite infrastructure et des services en fonction d’un niveau de service minimal toléré calculé à partir d’indicateurs de services de ladite infrastructure et desdits services , et si ladite valeur maximale d’indisponibilité est positive : - la transmission dans le réseau de données de perturbations de l’infrastructure réseau et des services déployés, les perturbations étant déterminées à partir d’au moins les données de configuration de la base de données et de la valeur maximale d’indisponibilité calculée, - la mise à jour de ladite valeur maximale d’indisponibilité suite aux perturbations. Selon certains modes de réalisation, le procédé comprend le déploiement d’un nouveau service, ledit nouveau service étant déterminé à partir d’au moins les données de configuration de la base de données et de la valeur maximale d’indisponibilité calculée. Selon certains modes de réalisation, le procédé comprend la délégation de droit d’exécution d’éléments de perturbation par l’un au moins des fournisseurs de service de l’un de ses sous-domaines. Selon certains modes de réalisation, la délégation de droit d’exécution d’éléments de perturbation comprend la transmission de clés privées relatives au service sur lequel les perturbations sont déployées préalablement à la transmission des perturbations. Selon certains modes de réalisation lequel lesdits indicateurs de service sont obtenus à partir de logiciels de surveillance de l’infrastructure et des services. Selon certains modes de réalisation, lesdites perturbations comprennent une ou plusieurs parmi les perturbations suivantes : - un déséquencement des paquets de données transmis aux services, - l’introduction de délais additionnels dans le service de requêtes vers des fournisseurs de service ; - la modification du contenu de requêtes entrantes ou de réponses, - l’insertion de nouvelles requêtes inconnues des services. Selon certains modes de réalisation, lesdites perturbations comprennent une ou plusieurs parmi les perturbations suivantes : - un déséquencement des paquets de données transmis aux services, - l’introduction de délais additionnels dans le service de requêtes vers des fournisseurs de service ; - la modification du contenu de requêtes entrantes ou de réponses, - l’insertion de nouvelles requêtes inconnues des services. Selon certains modes de réalisation, le procédé comprend au moins une requête d’obtention de métriques des infrastructures et des services afin de constituer les données de configuration de ladite base de données, lesdites métriques comprenant les performances, la charge d’un ou plusieurs processeurs de l’infrastructure, un taux de mémoire utilisée par les services ou l’infrastructure. Selon certains modes de réalisation, les données de configuration de la base de données comprennent un ensemble de perturbations auxquelles sont associés leur impact sur les infrastructures et sur les services, des indicateurs de niveau de service, (SLI) et des objectifs de niveau de service pour les infrastructures et pour les services. Les caractéristiques, présentées isolément dans la présente demande en lien avec certains modes de réalisation du procédé de la présente demande peuvent être combinées entre elles selon d’autres modes de réalisation du présent procédé. L’invention concerne également un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon l’invention, selon l’un quelconque de ses modes de réalisations, lorsque ledit programme est exécuté par un ordinateur. L’invention concerne également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon l’invention, selon l’un quelconque de ses modes de réalisations. L’invention concerne également un serveur de génération de perturbations dans un réseau pour en vérifier sa robustesse, comprenant un ou plusieurs processeurs configurés ensemble ou séparément pour instructions pour l’exécution des étapes du procédé selon l’invention, selon l’un quelconque de ses modes de réalisations. Ainsi l’invention concerne un serveur de génération de perturbations dans un réseau pour en vérifier sa robustesse, ledit réseau comprenant une pluralité d’infrastructures et de services déployés et hébergés dans ledit réseau, lesdits services étant fournis par au moins un fournisseur de services, le serveur comprend un ou plusieurs processeurs configurés ensemble ou séparément pour - obtenir au moins une base de données comprenant des données de configuration pour la pluralité d’infrastructures et de services - déterminer une valeur maximale d’indisponibilité de ladite infrastructure et des services en fonction d’un niveau de service minimal toléré calculé à partir d’indicateurs de services de ladite infrastructure et desdits services et si ladite valeur maximale d’indisponibilité est positive : - transmettre dans le réseau de données de perturbations de l’infrastructure réseau et des services déployés, les perturbations étant déterminées à partir d’au moins les données de configuration de la base de données et de la valeur maximale d’indisponibilité calculée, - mettre à jour ladite valeur maximale d’indisponibilité suite aux perturbations. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexes qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. La représente un exemple de système mettant en œuvre certains modes de réalisation de la présente invention. La représente un procédé selon un mode de réalisation de l’invention, La illustre des variations du budget d’erreur selon un mode de réalisation, La représente un mode de réalisation d’obtention de la base de données comprenant des données de configuration pour la pluralité d’infrastructures et de services, La représente un mode de réalisation de détermination des perturbations et de lancement des perturbations. Dans la suite on entend par nouveau service tout ajout d’applications ou de parties d’application de CSP (aka une application d’un CSP ou d’un nouveau CSP) ou de l’infra (aka un nouveau service dans les containers ) dans les serveurs de l’infrastructure. Dans la suite de la description les termes marge d’erreur ou encore budget d’erreur, indicateur de niveau de service, (SLI) et objectif de niveau de service (SLO) décrivent : SLI est une métrique. Par exemple cette métrique peut correspondre au temps de traitement d’une requête HTTPS par un centre de données définit comme l’instant de départ du dernier bit de la réponse moins l’instant d’arrivée du 1 er bit de la requête, SLO est la valeur à respecter sur une période de temps. Par exemple 99,99% des requêtes transmises en moins de 100ms sur 30 jours. SLI (acronyme anglais de « Service Level Indicator ») et SLO (acronyme anglais de « Service Level Objective ») sont deux concepts liés à la gestion des niveaux de service dans les systèmes informatiques. Un SLI est une mesure quantitative qui permet de définir les performances d'un système ou d'un service en fonction d'un critère spécifique. Par exemple, un SLI pourrait être le temps de réponse d'un serveur ou le nombre d'erreurs de connexion. Un SLO, quant à lui, est un objectif de niveau de service que l'on souhaite atteindre pour un SLI donné. Il s'agit donc d'un indicateur de performance que l'on veut maintenir ou dépasser. Par exemple, un SLO pourrait être que le temps de réponse d'un serveur ne doit pas dépasser 100 millisecondes. Les SLOs sont généralement basés sur des SLIs. C'est-à-dire que pour définir un SLO, on va se baser sur une ou plusieurs mesures quantitatives pour déterminer l'objectif à atteindre. Les SLIs permettent donc de mesurer la performance d'un système ou d'un service, tandis que les SLOs permettent de définir les objectifs à atteindre. Autrement dit, les SLIs mesurent la performance d'un système ou d'un service, tandis que les SLOs définissent les objectifs à atteindre en termes de niveaux de service. Les SLOs sont basés sur des SLIs et permettent de mesurer la performance par rapport à des critères préétablis. La marge d’erreur ou le budget d’erreur est la durée qui représente 100% moins SLO (exprimé en pourcentage). Par exemple, pour un SLO de 97%, la marge d’erreur est 3% c’est-à-dire que 3% des requêtes peuvent être traitées en plus de 100ms sur 30 jours. Avantageusement, le procédé permet de combiner des indicateurs de qualité ou de performance, SLOs, de l’infrastructure réseau et des SLOs de services applicatifs dans un service d’ « Ingénierie en qualité opérationnelle » IQO ou encore « Ingénierie de fiabilité de site », ou encore « Site Reliability Engineer » (SRE) en anglais. Les techniques IQO de l’infrastructure mesurent la résistance de l’infrastructure à des scénarii de tests de perturbations de niveau infrastructure. Les techniques IQO applicatif mesurent la résistance du service applicatif à des scénarii de tests de perturbations de niveau applicatif. Le fournisseur de services applicatif peut déléguer la gestion de ses scénarios de perturbation à l’opérateur d’infrastructure ou à un tiers pour gérer la sécurité de son service. Un tel service IQO de lancement de scénarii de perturbation peut être hébergé par un opérateur d’infrastructure ou par un tiers comme un éditeur de logiciel fournissant un service IQO commun à l’application et à l’infrastructure. Ainsi, l’opérateur d’infrastructure, ou ce tiers, peut mutualiser la télémétrie de plusieurs fournisseurs de services applicatifs pour entrainer des modèles basés sur de l’intelligence artificielle pour la génération et le paramétrage de scénarii de perturbation. Le procédé peut générer de nouveaux scénarios de perturbations (attaques, turbulences, erreurs injectées dans le service du fournisseur de services) que le fournisseur de services ne peut concevoir lui-même par manque de données lui permettant d’appréhender les contraintes de l’infrastructure ou concernant des services de tiers. Il peut également combiner des scénarios de perturbation de fournisseurs de service différents. Le procédé peut également éviter de lancer des perturbations des services qui pourraient dégrader les performances de l’infrastructure voire la faire tomber. Un mode de réalisation d’un système mettant en œuvre la présente invention est illustré en . Ce système peut comprendre plusieurs modules. Le mode de réalisation décrit en correspond à un environnement Kubernetes, aussi noté K8S. Il comprend notamment deux répartiteurs de charge, LB, (pour « load balancer » en anglais) qui répartissent les applications sur les différents serveurs ou groupes. Il comprend également un contrôleur ingress. Il comprend également deux groupes (pour « cluster » en anglais). Chaque groupe comprend des workers (w), ici 2 et chaque worker comprend deux services (S) dans l’exemple. Chaque groupe comprend un « master 8K ». Chacun des clusters peut par exemple être situé chez un opérateur d’infrastructure différent. Les « Master nodes » et « Worker nodes » sont des concepts issus de kubernetes. Un cluster est composé d’un ensemble de serveurs. Ils sont généralement co-localisés mais on peut trouver des architectures où ces deux fonctions peuvent être sur différents PoPs (en anglais « Point of Presence ») aussi appelés points d’accès, par exemple suivant la place et autres contraintes qui empêcheraient d’avoir plus de serveurs. Les « Worker node » supportent les applications et services. Les « Master node », sont en charge de la gestion. Ingress signifie ici Ingress Controlleur qui est une fonction permettant à un flux d’entrer sur le cluster et d’être aiguillé vers le bon noeud/service. Un cluster Kubernetes est donc composé d’au moins 1 master et de un ou plusieurs serveurs « Worker nodes » supportant les services / applications demandées. Ces applications sont instanciées dans ce qu’on appelle des Pods, qui s’apparentent à des containeurs. Les containeurs sont une segmentation de du système d’opération qui permet à l’opérateur de bien séparer les droits et les accès, ainsi que les ressources entre containeurs. Cette segmentation est faite pour des raisons de sécurité, mais aussi pour des raisons de facilité de gestion. Si un containeur est en défaut, cela ne met pas en défaut tout le système, mais seulement le containeur. Il est ainsi facile de le redémarrer sans impacter les autres containeurs. Le terme Pod est spécifique à Kubernetes car il embarque aussi des fonctions de gestion K8S comparativement au terme containeur qui est très générique en lui-même. Les nœuds maitres « Master nodes » sont moins nombreux que les nœuds de travail « Worker nodes » car ils n’ont pas à supporter d’applications, mais seulement des fonctions de gestion du cluster relatives à Kubernetes. Ils gèrent par exemple une base de données des applications tournant sur le cluster ainsi que des fonctions de contrôle, etc. Les clés privées peuvent être gérées à différents niveaux : - au niveau du load-balancer - au niveau de l’ingress controlleur, - au niveau du containeur (pod) - au niveau VIP, signifiant adresse virtuelle IP (protocole Internet), une IP virtuelle permet d’identifier un cluster de plusieurs serveurs. Celle-ci évite d’utiliser du SNI snooping. Le SNI snooping, qui signifie scruteur de l’indicateur du nom de service, est une fonction permettant de vérifier le champ SNI dans un paquet TLS (Transport Layer Security) utilisant notamment dans le cas de HTTPS (HTTP sur TLS). Le champ SNI contient le nom de domaine ciblé par la requête. Sans ce champ, le paquet étant chiffré, un équipement en coupure, comme un load balancer ou un proxy ne pourrait pas savoir quel est le site demandé par l’utilisateur. Ici le champ SNI permet donc au Load-Balancer d’aiguiller la requête vers le bon serveur disposant du service demandé et de présenter le bon certificat, lors de l’établissement de la connexion TLS. Un mode de réalisation d’un procédé selon l’invention est représenté en Le procédé comprend une première étape E1 d’obtention d’une base de données comprenant des données de configuration pour la pluralité d’infrastructures et de services. Elle peut par exemple comprendre des scénarios IQO. Cette base de données comprend un modèle de données comprenant l’architecture de l’infrastructure ainsi que la configuration des scénarios IQO associée. La configuration des scénarios IQO comprend la configuration des scénarios IQO appliqués par logiciel, pour chaque fournisseur de service applicatif hébergé, par exemple dans un cluster kubernetes commun, par localisation géographique. Selon certains modes de réalisation, l’obtention ou la création de la base de données des scénarios IQO peut être faite en interrogeant les différents éléments (configuration, état, …) composant l’infrastructure et en interrogeant les différents fournisseurs de service. Cette base de données peut comprendre les configurations détaillées, les templates de scenarios de chacun, les templates de scénarios commun (aka synchrone), les SLOs connus. La représente un mode de réalisation d’obtention des données de configuration de la base de données. Les données de configuration peuvent comprendre les configurations détaillées (ex. Worker node [identifiant, localisation, processeur, mémoire], certificats et localisation des clés privées et algorithme, taille de la clé, etc.), les trames de scenarios de chacun des acteurs (Chaque scénario est décrit dans turbulence par exemple. : Turbulence1 : délai, méthode, interface, protocole, etc.), les trames de scénarios commun (aka synchrone), les SLOs connus (ex : SLO minimal toléré pour un scenario donné, exemple RTT : Lors d’une étape E2, on détermine une valeur maximale d’indisponibilité combinée de l’infrastructure et des services en fonction d’un niveau de service (SLO) minimal toléré calculé à partir d’indicateurs de services de l’infrastructure et des services. Pour ce faire, on peut déterminer des objectifs de niveau de service, SLO. Ces objectifs de niveau de service sont obtenus à partir des indicateurs de niveau de service (SLI) des éléments compris dans l’infrastructure, c’est-à-dire des dispositifs assurant l’acheminement des données dans le réseau et de dispositifs de stockage dans des centres de données, ainsi que des indicateurs de niveau de service (SLI) des services ou applications. Un SLI mesure des aspects spécifiques des niveaux de service fournis. Parmi les indicateurs de niveau de service, on peut citer le temps de réponse aux requêtes, la disponibilité, le taux d’erreur et le débit. L’objectif de niveau de service SLO peut être défini comme étant : SLI (Service Level Indicator) et SLO (Service Level Objective) sont deux concepts liés à la gestion des niveaux de service dans les systèmes informatiques. Un SLI est une mesure quantitative qui permet de définir les performances d'un système ou d'un service en fonction d'un critère spécifique. Par exemple, un SLI pourrait être le temps de réponse d'un serveur ou le nombre d'erreurs de connexion. Un SLO, quant à lui, est un objectif de niveau de service que l'on souhaite atteindre pour un SLI donné. Il s'agit donc d'un indicateur de performance que l'on veut maintenir ou dépasser. Par exemple, un SLO pourrait être que le temps de réponse d'un serveur ne doit pas dépasser 100 millisecondes. Le lien entre les deux est que les SLOs sont généralement basés sur des SLIs. C'est-à-dire que pour définir un SLO, on va se baser sur une ou plusieurs mesures quantitatives pour déterminer l'objectif à atteindre. Les SLIs permettent donc de mesurer la performance d'un système ou d'un service, tandis que les SLOs permettent de définir les objectifs à atteindre. En résumé, les SLIs mesurent la performance d'un système ou d'un service, tandis que les SLOs définissent les objectifs à atteindre en termes de niveaux de service. Les SLOs sont basés sur des SLIs et permettent de mesurer la performance par rapport à des critères préétablis. Une façon courante d'exprimer la relation entre le SLO et le SLI est de dire que l'objectif de SLO doit être supérieur ou égal au niveau de performance mesuré par le SLI. On pourrait donc représenter cela par une formule comme suit par exemple: SLI ≤ SLO Cela signifie que le SLI doit être maintenu en dessous ou égal au SLO pour respecter les objectifs de niveau de service définis. Par exemple, si un SLI mesure le temps de réponse d'un système et que le SLO est défini à 100 millisecondes, la formule indiquerait que le temps de réponse ne doit pas dépasser 100 millisecondes pour respecter le niveau de service visé. Les métriques utilisées peuvent par exemple être extraites à l’aide des logiciels grafana et prometheus : Prometheus et Grafana sont deux outils populaires utilisés dans le domaine de la surveillance et de l’observabilité des systèmes informatiques. Prometheus est un système de surveillance de performance open source qui collecte des données de performance à partir de différentes sources et les stocke dans une base de données en mémoire. Il permet de surveiller l’état et les performances de différents systèmes en temps réel, en collectant des données de métriques telles que la charge de CPU, la mémoire utilisée et les taux d’erreur. Grafana est un outil de visualisation de données open source qui peut être utilisé avec de nombreuses sources de données différentes, y compris Prometheus. Il permet de créer des graphiques et des tableaux de bord pour visualiser et analyser les données de performance de différents systèmes de manière facile et intuitive. Ensemble, Prometheus et Grafana sont souvent utilisés pour surveiller et analyser les performances des systèmes informatiques, en particulier dans les environnements de production et de cloud. Ils sont utilisés dans l’industrie pour aider les équipes de développement et de gestion de systèmes à comprendre comment les systèmes fonctionnent et à détecter et résoudre les problèmes de performance. On peut déterminer ensuite déterminer une valeur maximale d’indisponibilité ou budget d’erreur, EB, pour l’ensemble des services et de l’infrastructure. Ce budget d’erreur est calculé à partir du SLO. Par exemple le budget erreur correspond à la formule 1 – SLO. Une illustration d’un budget d’erreur est représentée en . Le budget d’erreur représente une période d’indisponibilité déterminée comme acceptable pour une période considérée. Il peut s'agir du seuil maximal admissible d'erreurs et d'interruptions. Le budget d'erreur est à disposition des développeurs qui peuvent l'utiliser lors du lancement d'une nouvelle fonction. En se basant sur l'objectif de niveau de service et sur le budget d'erreur, il est possible de déterminer si le lancement d'un produit ou d'un service est possible avec le budget d'erreur alloué. La illustre une évolution du budget d’erreur selon un mode de réalisation. En ordonnée est représenté le budget d’erreur (en pourcentage) et en abscisse le temps, chaque pas de temps correspondant à un mois de l’année. Ce budget d’erreur peut correspondre au budget d’erreur dans une infrastructure, chez un fournisseur de service ou les deux combinés. Il illustre les phases pendant lesquelles le budget d’erreur est considéré comme ne permettant pas de lancer des perturbations et des phases pendant lesquelles le budget d’erreur permet de lancer des perturbations. Sur la , on peut noter que le budget d’erreur est inférieur à 99,99% entre approximativement mi-juin et début septembre. Ceci signifie donc que l’on peut par exemple déployer de nouvelles fonctions ou modifier la configuration du réseau et des services et challenger cette modification avec des perturbations réseau et services qui pourront être acceptables, car le SLO est respecté. Le budget d’erreur est une notion très liée à celle d’un ou plusieurs SLOs dans la gestion des niveaux de service. Il s'agit de la quantité d'erreurs ou de temps d'indisponibilité qui sont tolérés par rapport à un objectif de niveau de service (SLO) donné. En d'autres termes, le budget d’erreur est le pourcentage de temps durant lequel le système peut être en panne ou produire des résultats en dehors de la plage acceptable pour le SLO, tout en respectant toujours l'objectif global de niveau de service. La relation entre le budget d’erreur et le SLO est donc très étroite, le budget d’erreur est calculé en soustrayant le pourcentage du temps d'indisponibilité ou d'erreurs toléré (défini par le budget d’erreur) du pourcentage de temps alloué pour répondre au SLO. Par exemple, si le SLO est défini à un temps de réponse moyen de 100 millisecondes, le budget d’erreur pourrait être de 0,5%. Cela signifierait qu'il est autorisé d'avoir des temps de réponse supérieurs à 100 millisecondes pendant 0,5% du temps d'activité du système sans dépasser le niveau de service accepté. En résumé, le budget d’erreur et le SLO sont étroitement liés car le budget d’erreur définit la quantité d'erreurs tolérées par rapport à un SLO donné et permet ainsi de maintenir le niveau de service attendu en cas de problèmes. Lorsque les temps de réponses sont par exemple >100 ms correspondent à 0,499% de disponibilité du système, il convient de ne pas modifier la configuration en déployant de nouvelles fonctions et de travailler sur la fiabilité du réseau et des services et de ne pas déployer de nouvelles fonctions. Le budget d’erreur EB être défini comme étant : Un SLO est déterminé par système, et donc un budget d’erreur par système Exemple 1 : SLO Application Exemple 2 : SLO Infra cloud Exemple 3 : SLO réseau Dans certains modes de réalisation, un SLO n'est pas exprimé en pourcentage. Bien que les pourcentages soient couramment utilisés dans le cadre de la gestion des niveaux de service pour mesurer les objectifs de performance, les SLO peuvent être définis de différentes manières en fonction des besoins et des objectifs du système ou du service. Par exemple, un SLO peut être défini comme une mesure de temps, comme un temps de réponse maximum en millisecondes, ou une mesure de disponibilité, comme un pourcentage du temps total où le système doit être opérationnel. Le budget d’erreur est généralement calculé à partir du SLO en utilisant une formule qui soustrait le SLO de 100%, ce qui donne la quantité d'erreur ou d'indisponibilité acceptable. Par exemple, si le SLO est défini comme un temps de réponse maximum de 100 millisecondes, le budget d’erreur pourrait être calculé en utilisant la formule 100% - SLO, ce qui donnerait un budget d’erreur de 0,0% si l'objectif de temps de réponse doit toujours être respecté. Si le budget d’erreur est dépassé (seuil atteint, dans notre exemple, 0,5% d’erreur), étape E3, alors on passe à une étape E4 et s’il n’est pas dépassé (seuil non atteint) on passe à l’étape E5. Lors de l’étape E4, on déploie un nouveau service, le nouveau service étant déterminé à partir d’au moins les données de configuration de la base de données et de la valeur de budget d’erreur atteinte . Lors d’une étape E5, on injecte, dans le réseau, des données de perturbations de l’infrastructure réseau et des services déployés, les perturbations étant déterminées à partir d’au moins les données de configuration de la base de données et de la valeur maximale d’indisponibilité calculée. Lors d’une étape E6, on met à jour la valeur maximale d’indisponibilité suite aux perturbations injectées et on repasse à l’étape E2. Il est également possible selon certains modes de réalisation de déterminer des contremesures pour améliorer le SLO. Si le budget d’erreur est dépassé (seuil atteint) à l’étape E3, alors on passe à une étape E7. Lors de cette étape, on lance une analyse intelligente basée sur de l’intelligence artificielle, communément connue sous le terme AISV, acronyme anglais de « Artificial Intelligence Software Vendor ». Dans un exemple d’usage du procédé appliqué à la sécurité, on peut par exemple, vouloir d’appliquer une contremesure proposée par l’AISV et déduite de la valeur de l’EB calculé suite à l’injection d’une turbulence. Ainsi par exemple, la stratégie de stockage des clés privées est modifiée pour en améliorer la sécurité. Ainsi lors d’une étape E8, on peut appliquer une contremesure pour les services ou infrastructure dont le budget d’erreur a été dépassé. Puis lors d’une étape E10 on peut appliquer la stratégie déterminée pour l’ensemble considéré, les services ou infrastructure dont le budget d’erreur est dépassé Et on repasse à l’étape E2. Prenons maintenant un exemple d’application du procédé tel que décrit en référence à la . Selon cet exemple, le calcul des budgets d’erreur effectué lors de l’étape E2 indique que le budget d’erreur de l’infrastructure réseau est respecté ainsi que celui d’un service de localisation. Afin de pouvoir déployer les perturbations sur le service de localisation, le fournisseur du service de localisation délègue un de ses sous-domaines (une zone géographique, un sous réseau IP, un cluster ou groupe de clusters, une passerelle d’accès à un réseau mobile par exemple de type UPF (acronyme anglais de « User Plane Function ») à un opérateur de l’infrastructure réseau ou à un tiers en charge de mettre en œuvre le scénario de perturbations. Un service d’analytique fourni ou mis au point par le fournisseur Cloud et/ou par le fournisseur d’infrastructure réseau est capable d’adapter le scénario de turbulences aux contextes de l’infrastructure Cloud et de l’infrastructure réseau. Réciproquement un fournisseur de service pourrait demander à un fournisseur d’infrastructure réseau d’appliquer les scénarios de turbulences propres aux applications de ce fournisseur de service. Le fournisseur de service délègue dynamiquement un de ses sous domaines à l’opérateur pour l’exécution d’un scénario à partir d’un ou de Master gérant les pods hébergeant les applications du fournisseur de services. Le scénario contient les pods concernés : Le procédé peut donc comprendre la délégation par l’application du fournisseur de services de droit d’exécution d’éléments de perturbations isolés dans un de ses sous-domaines par l’un au moins des fournisseurs d’infrastructure cloud et/ou réseau. Un opérateur de réseau ou de cloud assurant le test d’une infrastructure et de services mis en oeuvre sur cette infrastructure, le fournisseur de services peut avantageusement déléguer le test d’un service par la mise en œuvre de scénarios de turbulences. Selon certains modes de réalisation, la délégation consiste à automatiser la mise en œuvre du procédé. L’établissement de la délégation consister à envoyer de la part du délégataire, ici, fournisseur du service, CSP1, une demande signée de sa part au délégué, ici, fournisseur de cloud et/ou réseau, OP1. Cette demande contient les paramètres définissant le périmètre précis des scénarios de turbulences où la délégation s’exerce. Ces paramètres consistent en par exemple : éléments de l’infrastructure réseau/Cloud concernés (ex., Pods, clusters), sous-domaines concernés (ex., NS1, NS2, etc.), scénarios de turbulences concernés, credentials, et durée de validité de la délégation. Les méthodes de délégation pouvant être mise en œuvre sont par exemple : - ACME/STAR qui utilise x509 spécifique fournit par un CA (externe), ou- Delegated credentials : une délégation plus rapide signée du délégataire. Le scénario est ensuite exécuté un des dispositifs de l’infrastructure et peut être contrôlée par l’opérateur de l’infrastructure, par le fournisseur du service ou par un tiers. Si c’est le fournisseur de service qui contrôle le déploiement des perturbations, alors le fournisseur de service demande les budgets d’erreur de l’infrastructure, fournit le tout au tiers et obtient un scenario mis à jour. Si c’est l’opérateur de l’infrastructure qui contrôle le déploiement des perturbations, alors l’opérateur de l’infrastructure demande les budgets d’erreur du fournisseur de service, fournit le tout au tiers et obtient un scenario mis à jour. Des exemples de perturbations pouvant être mis en œuvre dans le cadre de certains modes de réalisation de la présente invention sont donnés ci-après à titre d’exemple. Selon certains modes de réalisation, les perturbations comprennent une ou plusieurs parmi les perturbations suivantes : - un déséquencement des paquets de données entrants dans l’infrastructure ou dans un service, - un déséquencement des paquets de données sortant de l’infrastructure ou d’un service, - l’introduction de délais additionnels dans le flux de requêtes entrantes à destination des fournisseurs de service, - activation d’un déséquilibre dans le routage d’un load balancer afin de saturer brièvement un groupe de serveurs, - la modification du contenu de requêtes entrantes ou de réponses sortantes, - l’insertion de nouvelles requêtes inconnues des services et de l’infrastructure, -l’activation de procédures de protections incluses dans les services ou dans l’infrastructure, procédures qui ne se déclenchent pas en fonctionnement normal. Par exemple, un déséquencement des paquets de données entrants ou sortants dans l’infrastructure ou dans un service, peut par exemple consister en l’injection d’un message erroné vers un service de kubernetes comme « etcd » ou « grafanas ». La durée du déséquilibre engendré lors de l’injection de perturbations afin de brièvement un groupe de serveurs peut dépendre du budget d’erreur. Parmi les procédures de protections incluses dans les services ou dans l’infrastructure, on peut citer le log des tous les paquets vers un sous domaine d’un service ; le contrôle approfondi des certificats des requêtes http vers un sous domaine d’un service ou venant d’un sous réseau IP. Premier exemple de turbulence dans le contexte d’un serveur de données de type HTTPS Apache. L’opérateur d’infrastructure sait que le fournisseur de services comprend des containers Apache à partir des traces de déploiement des services (ArgoCD), ou bien en interrogeant l’infrastructure K8S (via une commande qui permet de contrôler ses nœuds kubernetes, soit faire la liste des services), ou encore en observant les requêtes http entrantes dans une entité de contrôle des flux de données entrants, connue en anglais sou le nom de « Ingress controller ». ArgoCD est un outil open source de déploiement continu et de livraison continue qui facilite la gestion des déploiements de logiciels dans des environnements de production. Il permet de déployer automatiquement les applications sur différents environnements tels que les clusters Kubernetes, les machines virtuelles et les serveurs bare-metal. Ce dernier mode suppose que l’infrastructure dispose des clés privées et donc agit comme reverse proxy (élément qui régit les connexions entrantes dans un centre de données) pour le service. Il peut effectuer un comptage applicatif s’il possède les clés chiffrant les flux concernés, où seulement s’il a reçu une délégation lui permettant de lire au moins une partie de la signalisation reçue par l’application hébergée. Deuxième exemple de turbulence dans le contexte d’un environnement MySQL L’opérateur d’infrastructure sait que le fournisseur de services a des containers MySQL à partir des traces de déploiement des services (ArgoCD), ou bien en interrogeant l’infrastructure K8S (via p.e., kubectl list services), ou encore en observant les requêtes http entrantes dans le contrôleur d’Ingress. Ce dernier mode suppose que l’infrastructure dispose des clés privées et donc agit comme reverse proxy pour le service : il termine la connexion TLS, effectue du comptage, voire des actions de SRE et route la requête vers l’application hébergée. Par exemple, un scénario de SRE permettant de tester la « capacité à router les requêtes d’un dispositif utilisateur à la bonne plateforme et vers le bon service » pourrait comprendre les turbulences suivantes : - Turbulence1 : introduire du dé-séquencement dans l’ordre d’arrivée des requêtes d’un dispositif utilisateur (et non dans les paquets) ; ex : dé-séquencement de 5 secondes dans le protocole HTTPS en entrée du reverse proxy - Turbulence2 : introduire de très longs délais dans les POST HTTP en entrée du reverse proxy vers les serveurs de base de données. Exemple : retarder un formulaire MySQL de 3 minutes et voir l’impact. Troisième exemple de turbulence dans le contexte d’un scénario pré-codé dans le code du fournisseur de service. Le scénario de perturbations inclut des fonctions de turbulences internes à l’application (comportement anormal programmé dont l’activation nécessite une authentification) activées à l’aide de clés de démarrage et d’arrêt générées dynamiquement par l’opérateur d’infra à partir des crédits du scénario. Une turbulence pré-codée est une fonction incluse dans le code du programme de l’application du fournisseur de services : par exemple le container de routage applicatif inclut une fonction de turbulence qui une fois activée génère des erreurs dans le routage pour challenger le comportement des composantes de l’application : les composants sont conçus pour résister à des erreurs de routages se produisant notamment durant le cycle de vie des containers (relance des requêtes des clients lors de l’arrêt, démarrage de fonction de routage…). La représente un mode de réalisation d’obtention de la base de données comprenant des données de configuration pour la pluralité d’infrastructures et de services, Lors d’une étape T1, les fournisseurs de services transmettent une demande de test de fiabilité d’un ou plusieurs services à l’attention du gestionnaire de l’infrastructure et plus particulièrement d’un module qui contrôle l’établissement et la gestion des scenarii, le moniteur d’infrastructure. L’étape T1 fait partie du démarrage de l’établissement de l’inventaire des fournisseurs de service. Lors d’une étape T2, le moniteur d’infrastructure transmet une demande de lancement de la procédure de perturbations à certains ou à la pluralité des fournisseurs de services présents. Lors d’une étape T3, ces fournisseurs de service transmettent une réponse au moniteur. Cette réponse peut être un accord, un rejet, une demande de différé ou le lancement des perturbations. Lors d’une étape T4, le moniteur d’infrastructure transmet également des messages de notifications relatifs aux perturbations en cours au maitre de l’infrastructure (K8S) . Il reçoit une réponse, étape T5. Cette réponse comprend les états des différents éléments testés. Les étapes T2 à T5 font partie de l’interrogation des différents composants, aussi bien fournisseurs de service que modules de l’infrastructure. Lors d’une étape T6, le gestionnaire de charge, LB, transmet des métriques au moniteur d’infrastructure. Parmi les métriques transmises, on peut citer des métriques réseau (nombre de paquets perdus), des métriques d’application (temps de traitement de la requête par l’application hébergée), métrique cloud (temps de traversée de gestionnaire de charge (LB). Lors d’une étape T7, le side-car proxy (c’est un proxy, élément de commande, situé sur l’infrastructure cloud (en général co-localisé à l’application, au client ou fournisseur de service)) transmet aussi ses métriques (par exemple les sessions en cours, le trafic réseau, etc). Grâce à cette fonction, l’application est déchargée d’un certain nombre de fonctions telles que l’envoi de métriques la concernant au moniteur d’infrastructure. Lors d’une étape T8, les fournisseurs de service transmettent également leurs métriques, sous forme de SLIs, au moniteur d’infrastructure. Le procédé spécifie 2 fonctions nouvelles : le Moniteur SRE capable de créer la base de données SRE en interrogeant les différents éléments de l’infrastructure et du service et l’injecteur SRE permettant de déclencher les perturbations. La représente un mode de réalisation de détermination des perturbations et de lancement des perturbations selon certains modes de réalisation du procédé selon l’invention. Lors d’une étape Z1, le side-car proxy transmet ses métriques au moniteur de l’infrastructure. Un side-car proxy est une application qu’on vient ajouter à une application existante dans un containeur. Lors d’une étape Z2, les fournisseurs de service transmettent leurs métriques au moniteur de l’infrastructure. Lors d’une étape Z3, le gestionnaire de charge, LB, transmet ses métriques au moniteur de l’infrastructure. Lors d’une étape Z4, le side-car proxy transmet ses métriques au moniteur du fournisseur de service. Lors d’une étape Z5, les fournisseurs de service transmettent leurs métriques au moniteur du fournisseur de service. Lors d’une étape Z6, le moniteur du fournisseur de services transmet le SLO calculé à un injecteur SRE du fournisseur de services. Lors d’une étape Z7, le moniteur de l’infrastructure transmet le SLO calculé à un injecteur SRE de l’infrastructure. Lors d’une étape Z8, une synchronisation est effectuée entre l’injecteur SRE de l’infrastructure et le moniteur SRE du fournisseur de services. Lors de cette étape le budget d’erreur est calculé, comme décrit précédemment en regard de la . Lors d’une étape Z9, une vérification et une génération de clés est effectuée entre le moniteur SRE du fournisseur de services et l’injecteur SRE de l’infrastructure. Lors d’une étape Z10, un signal d’activation est transmis de l’injecteur SRE de l’infrastructure vers l’injecteur SRE du fournisseur de services pour exécuter le ou les scénarios de perturbation. Lors d’une étape Z11, l’injecteur SRE de l’infrastructure transmet les perturbations au gestionnaire de charge ou active les turbulences au niveau du gestionnaire de charges, comme mentionné précédemment en regard de l’étape E5 de la . Lors d’une étape Z12, l’injecteur SRE de l’infrastructure transmet les perturbations au side-car proxy ou active les turbulences au niveau du side-car proxy comme mentionné précédemment en regard de l’étape E5 de la . Lors d’une étape Z13, l’injecteur SRE de l’infrastructure transmet les perturbations aux fournisseurs de services ou active les turbulences au niveau du fournisseur de services comme mentionné précédemment en regard de l’étape E5 de la . Nous allons maintenant décrire un exemple de mise en œuvre de l’invention. Des métriques sont utilisées pour définir la disponibilité d’un service sur une période courte t de durée T et respecte un encadrement pour valider la période. Plusieurs métriques peuvent être combinées pour invalider une période t. Le nombre de périodes valides sur P détermine le pourcentage de disponibilité. Par exemple, si 90% des périodes T sont valides sur la période P, le service est disponible à 90% du temps. Dans ec cas, le budget d’erreur sur P est de 10%. Cette marge d’erreur est disponible sans rompre la disponibilité. Elle est utilisée par chaque acteur pour tester la robustesse de son service. On utilise les métriques suivantes : La métrique de l’application est le temps de traitement de la requête entrante par l’application hébergée. La métrique de l’infrastructure cloud est le temps de traversée du gestionnaire de charge de l’infrastructure. La métrique du réseau est le nombre de paquets perdus. On considère les trois turbulences suivantes: InjSql23(x,y) : injection de X attaques dans Y requêtes SQL Form15(x,y) : Injection de X formulaires Web aléatoires dans des POST HTML dans Y sessions DeSeq10(x) : Déséquencement de X formulaires Web des POST HTML Les impacts de ces trois turbulences sur le budget d’erreur sont les suivants (les chiffres indiqués dans le tableau correspondent au budget d’erreur) : acteur Application infrastructure cloud réseau Scenario turbulences Impact estimé EBa (%) Impact estimé EBi (%) Impact estimé EBr (%) InjSql23(3,5) 8 7 3 InjSql23(8,9) 6 4 2 Form15(6,12) 4 1 1 Form15(3,6) 2 1 1 DeSeq10(5) 1 1 1 DeSeq10(10) 3 3 3 On suppose qu’à l’instant t1, les budgets d’erreur respectifs (EBa, EBi, EBr) sont (15, 6, 5). Selon les modes de réalisation de la présente invention, le procédé détermine les séquences de turbulences qui respectent le budget d’erreur de chacun (application, infrastructure cloud, réseau) avec pour contrainte le fait que la turbulence détériore de manière acceptable le budget d’erreur de chacun, c’est-à-dire que l’application de la turbulence ne rende pas le budget d’erreur négatif. Si on essaie de lancer InjSql23(3,5), on obtient (EBa, EBi, EBr) = (15, 6, 5) – (8, 7, 3)=(7, -2, 3). Le budget d’erreur de l’infrastructure cloud est négatif, donc on ne peut pas lancer cette perturbation. Si on essaie de lancer InjSql23(8,9), on obtient (EBa, EBi, EBr) = (15, 6, 5) – (6, 4, 2) = (9, 2, 3). La perturbation Form15(6, 12) peut être exécuté en même temps ou en série donnant (EBa, EBi, EBr) = (9, 2, 3) – (4, 1, 1)= (5, 1, 2). DeSeq10(5) peut aussi être exécuté en même temps ou en série que InjSql23(8,9) et Form15(6, 12) On obtient (EBa, EBi, EBr) = (5 ,1, 2) – (1, 1, 1) = (4, 0, 1) Form15(3, 6) = peut aussi être exécuté en même temps ou en série que InjSql23(8,9) : On obtient (EBa, EBi, EBr) = (9 ,2, 3) – (2, 1, 1) = (7, 1, 2) DeSeq10(10) ne peut pas être exécuté en même temps ou en série que InjSql23(8,9)car on obtiendrait (EBa, EBi, EBr) = (9 ,2, 3) – (3, 3, 3) = (6, -1, 0) : Un premier scénario de perturbation qui peut être lancé est donc : - InjSql23(8,9) - Form15(6, 12) - DeSeq10(5) Un second scénario qui peut être lancé est donc : - InjSql23(8,9) - Form15(3,6) Les impacts de chaque turbulence paramétrée sont estimés à l’avance, par exemple, par entrainement à partir des erreurs des logs applicatifs et des paramètres d’activités observés sur l’infrastructure et le réseau. Ces impacts peuvent faire partie des données de configuration présentes dans la base de données. Un exemple est donné dans le tableau suivant : Application Infrastructure cloud réseau Erreurs et attaques observées dans les logs Nombre de requêtes Nombre de sessions Impact estimé EBa (%) Ram (Go) Cpu (Gflops) Disque (Go) Impact estimé EBi (%) Delai (ms) Perte (integer) Jigue (ms) Impact estimé EBr (%) InjSql23 3 5 8 20 17 15 7 20 20 10 3 InjSql23 8 9 6 28 19 10 4 25 28 20 2 Form15 11 32 4 19 25 20 1 35 25 19 1 Form15 15 15 2 25 35 28 1 15 35 25 1 DeSeq10 10 10 1 10 15 10 1 10 15 20 1 DeSeq10 20 20 3 20 10 20 3 20 10 28 3 Procédé de génération de perturbations dans un réseau pour en vérifier sa robustesse, ledit réseau comprenant une pluralité d’infrastructures et de services déployés et hébergés dans ledit réseau, lesdits services étant fournis par au moins un fournisseur de services, le procédé comprenant - l’obtention (E1) d’au moins une base de données comprenant des données de configuration pour la pluralité d’infrastructures et de services, - la détermination (E2) d’une valeur maximale d’indisponibilité de ladite infrastructure et des services en fonction d’un niveau de service (SLO) minimal toléré calculé à partir d’indicateurs de services de ladite infrastructure et desdits services , et si ladite valeur maximale d’indisponibilité est positive (E3) : - la transmission (E5) dans le réseau de données de perturbations de l’infrastructure réseau et des services déployés, les perturbations étant déterminées à partir d’au moins les données de configuration de la base de données et de la valeur maximale d’indisponibilité calculée, - la mise à jour (E6) de ladite valeur maximale d’indisponibilité suite aux perturbations. Procédé selon la revendication 1 comprenant le déploiement (E4) d’un nouveau service, ledit nouveau service étant déterminé à partir d’au moins les données de configuration de la base de données et de la valeur maximale d’indisponibilité calculée. Procédé selon l’une des revendications 1 ou 2 comprenant la délégation de droit d’exécution d’éléments de perturbation par l’un au moins des fournisseurs de service de l’un de ses sous-domaines. Procédé selon l’une des revendications 1 à 3 dans lequel la délégation de droit d’exécution d’éléments de perturbation comprend la transmission de clés privées relatives au service sur lequel les perturbations sont déployées préalablement à la transmission des perturbations. Procédé selon l’une des revendications précédentes dans lequel lesdits indicateurs de service sont obtenus à partir de logiciels de surveillance de l’infrastructure et des services. Procédé selon l’une des revendications précédentes dans lequel lesdites perturbations comprennent une ou plusieurs parmi les perturbations suivantes : - un déséquencement des paquets de données transmis aux services, - l’introduction de délais additionnels dans le service de requêtes vers des fournisseurs de service ; - la modification du contenu de requêtes entrantes ou de réponses, - l’insertion de nouvelles requêtes inconnues des services. Procédé selon l’une des revendications précédentes comprenant au moins une requête d’obtention de métriques des infrastructures et des services afin de constituer les données de configuration de ladite base de données, lesdites métriques comprenant les performances, la charge d’un ou plusieurs processeurs de l’infrastructure, un taux de mémoire utilisée par les services ou l’infrastructure. Procédé selon l’une des revendications précédentes dans lequel les données de configuration de la base de données comprennent un ensemble de perturbations auxquelles sont associés leur impact sur les infrastructures et sur les services, des indicateurs de niveau de service, (SLI) et des objectifs de niveau de service (SLO) pour les infrastructures et pour les services Programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon l’une des revendications 1 à 8 lorsque ledit programme est exécuté par un ordinateur. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon l’une des revendications 1 à 8. Serveur de génération de perturbations dans un réseau pour en vérifier sa robustesse, ledit réseau comprenant une pluralité d’infrastructures et de services déployés et hébergés dans ledit réseau, lesdits services étant fournis par au moins un fournisseur de services, le serveur comprend un ou plusieurs processeurs configurés ensemble ou séparément pour - obtenir au moins une base de données comprenant des données de configuration pour la pluralité d’infrastructures et de services, - déterminer une valeur maximale d’indisponibilité de ladite infrastructure et des services en fonction d’un niveau de service (SLO) minimal toléré calculé à partir d’indicateurs de services de ladite infrastructure et desdits services et si ladite valeur maximale d’indisponibilité est positive : - transmettre dans le réseau de données de perturbations de l’infrastructure réseau et des services déployés, les perturbations étant déterminées à partir d’au moins les données de configuration de la base de données et de la valeur maximale d’indisponibilité calculée, - mettre à jour ladite valeur maximale d’indisponibilité suite aux perturbations.