FR3108743A1 - Procede de prevention d’incident sur une chaine applicative et dispositif informatique de prevention d’incident - Google Patents
Procede de prevention d’incident sur une chaine applicative et dispositif informatique de prevention d’incident Download PDFInfo
- Publication number
- FR3108743A1 FR3108743A1 FR2003230A FR2003230A FR3108743A1 FR 3108743 A1 FR3108743 A1 FR 3108743A1 FR 2003230 A FR2003230 A FR 2003230A FR 2003230 A FR2003230 A FR 2003230A FR 3108743 A1 FR3108743 A1 FR 3108743A1
- Authority
- FR
- France
- Prior art keywords
- incident
- data
- application
- accident
- application chain
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 134
- 230000002265 prevention Effects 0.000 title claims abstract description 58
- 230000008569 process Effects 0.000 title description 28
- 230000003449 preventive effect Effects 0.000 claims abstract description 109
- 238000005259 measurement Methods 0.000 claims abstract description 12
- 230000006399 behavior Effects 0.000 claims description 78
- 230000015654 memory Effects 0.000 claims description 44
- 238000004458 analytical method Methods 0.000 claims description 34
- 230000009471 action Effects 0.000 claims description 31
- 238000013515 script Methods 0.000 claims description 26
- 238000004364 calculation method Methods 0.000 claims description 20
- 230000006870 function Effects 0.000 claims description 17
- 238000004590 computer program Methods 0.000 claims description 9
- 238000012795 verification Methods 0.000 claims description 6
- 230000000977 initiatory effect Effects 0.000 claims description 5
- 239000000523 sample Substances 0.000 description 29
- 238000012545 processing Methods 0.000 description 21
- 238000012544 monitoring process Methods 0.000 description 19
- 230000007257 malfunction Effects 0.000 description 14
- 230000004044 response Effects 0.000 description 13
- 238000003860 storage Methods 0.000 description 13
- 239000011449 brick Substances 0.000 description 12
- 230000000875 corresponding effect Effects 0.000 description 12
- 238000004891 communication Methods 0.000 description 10
- 238000012423 maintenance Methods 0.000 description 10
- 238000012986 modification Methods 0.000 description 9
- 230000004048 modification Effects 0.000 description 9
- 230000003542 behavioural effect Effects 0.000 description 6
- 230000002596 correlated effect Effects 0.000 description 5
- 238000013480 data collection Methods 0.000 description 5
- 238000001514 detection method Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 230000014509 gene expression Effects 0.000 description 5
- 230000001133 acceleration Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 3
- 230000001364 causal effect Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000033001 locomotion Effects 0.000 description 3
- 239000000779 smoke Substances 0.000 description 3
- 238000007619 statistical method Methods 0.000 description 3
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 3
- 239000006185 dispersion Substances 0.000 description 2
- 238000012806 monitoring device Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000007781 pre-processing Methods 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 238000012952 Resampling Methods 0.000 description 1
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 238000004378 air conditioning Methods 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 239000012141 concentrate Substances 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 230000008030 elimination Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000001747 exhibiting effect Effects 0.000 description 1
- 230000003631 expected effect Effects 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000010606 normalization Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000000513 principal component analysis Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000000528 statistical test Methods 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- 230000003442 weekly effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0712—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a virtual computing platform, e.g. logically partitioned systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3089—Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents
- G06F11/3093—Configuration details thereof, e.g. installation, enabling, spatial arrangement of the probes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3433—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment for load management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3447—Performance evaluation by modeling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3452—Performance evaluation by statistical analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/865—Monitoring of software
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Computer Hardware Design (AREA)
- Bioinformatics & Computational Biology (AREA)
- Evolutionary Biology (AREA)
- Bioinformatics & Cheminformatics (AREA)
- Life Sciences & Earth Sciences (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Probability & Statistics with Applications (AREA)
- Time Recorders, Dirve Recorders, Access Control (AREA)
- User Interface Of Digital Computer (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Debugging And Monitoring (AREA)
Abstract
L’invention porte sur un dispositif de prévention d’incident sur une chaine applicative et un procédé de prévention d’incident sur une chaine applicative comportant en particulier une étape de réception 400 de données de comportement d’une chaine applicative, une étape d’identification 500 d’au moins un état accidentogène en fonction des données de comportement d’une chaine applicative reçues et de données de profils d’incident préalablement mémorisés, une étape de sélection 600 d’au moins une action préventive en fonction de l’au moins un état accidentogène identifié et de données de résolution d’incident préalablement mémorisés, une étape d’application automatique 700 de l’au moins une action préventive correspondant à l’état accidentogène identifié, et une étape de vérification 800 de la prévention d’incident, comportant une mesure de l’efficacité de l’action préventive appliquée en fonction de données de comportement d’une chaine applicative et des données de profils de résolution préalablement mémorisés. Figure à publier avec l’abrégé : FIGURE 1
Description
L’invention s’intéresse au domaine de la surveillance d’infrastructures informatiques, et plus particulièrement au domaine de la prévention d’incident sur une chaine applicative. L’invention concerne un procédé de prévention d’incident sur une chaine applicative, ledit procédé étant mis en œuvre par un dispositif informatique. L’invention concerne en outre un dispositif informatique pour la prévention d’incident sur une chaine applicative.
Les infrastructures informatiques sont composées d'un nombre de plus en plus grand de composants interconnectés que cela soit des composants matériels ou des composants logiciels. Dans ces infrastructures informatiques, la multiplicité de ces composants entraine un risque élevé de défaillance du système. En outre, ces infrastructures informatiques sont souvent hétérogènes et changeantes entrainant une diversité des composants matériels et des composants logiciels d’une part et une évolution de leurs caractéristiques dans le temps d’autre part.
Dans les infrastructures informatiques complexes et distribuées récentes, il est souhaitable de fournir des fonctions autonomes dans le système informatique lui-même pour éliminer la nécessité d’une surveillance permanente du système par un administrateur humain. Cela a conduit au développement de procédés ou de dispositifs de surveillance d’infrastructure informatique permettant d’identifier des anomalies dans les comportements des différents composants matériel ou logiciels de l’infrastructure informatique.
Ainsi, avec ces procédés ou dispositifs de surveillance, un incident technique (e.g. une erreur, un ralentissement, un échec, etc.) qui se produit dans une infrastructure informatique, est susceptible d'être détecté sous la forme d’anomalies par exemple dans une ou plusieurs mesures d’indicateurs de performance. Ces mesures peuvent par exemple correspondre à des mesures de performance (par exemple, le temps moyen de réponse du serveur, l'histogramme de distribution horaire du serveur, la page taille du fichier, le nombre de pages lentes, le nombre de transactions, etc.), les paramètres du réseau (par exemple, le débit du réseau, la latence du réseau, etc.), et des mesures système (par exemple, l'utilisation du CPU, utilisation de la mémoire, etc.). Des techniques de surveillance d’indicateurs de performance sont bien connues pour la surveillance d’infrastructures informatiques avec par exemple l’utilisation de sondes telles que des moniteurs de ressources capables de surveiller un système informatique et de fournir des valeurs de performances réseau, applicatif et / ou système.
Néanmoins, dans les infrastructures informatiques complexes et distribuées récentes les valeurs observables d’indicateurs de performance varient fortement au fil du temps, et les techniques dans lesquelles les valeurs observées sont directement utilisées sont difficiles à appliquer parce que les valeurs de seuil de détection ne sont pas efficaces.
En outre, lorsqu’un incident ou un dysfonctionnement est détecté il est souvent trop tard et l’infrastructure informatique ainsi que ses chaines applicatives s’en trouvent grandement affectés sans parler des utilisateurs. En effet, les dispositifs ou procédés de surveillance existant se contentent généralement de rapporter des anomalies. Or, avec d’une part la complexité et d’autre part la taille croissante des infrastructures informatiques, les services de maintenance sont submergés par des alertes d’anomalie ou de défaillance.
De plus, au-delà de la génération d’alertes qui pourront être caractérisées par une valeur de risque de défaillance ou un niveau de criticité, l’équipe de maintenance bénéficie uniquement d’une information sur le risque de défaillance. Un temps non négligeable est alors nécessaire d’une part pour trouver une mesure corrective par l’équipe de maintenance, la mesure corrective devant être adaptée à l’incident et d’autre part pour le déploiement de cette action corrective. Le cas échéant, les actions correctives sont efficaces après l’incident.
Ainsi, il existe un besoin pour de nouvelles solutions permettant une prévention performante d’un incident sur une infrastructure informatique et plus particulièrement sur une chaine applicative permettant à la fois de prévenir d’un incident mais également de permettre à l’équipe de maintenance un gain de temps lors de la mise en place des actions préventives ou correctives.
[Problème technique]
L’invention a donc pour but de remédier aux inconvénients de l’art antérieur. En particulier, l’invention a pour but de proposer un procédé de prévention d’incident sur une chaine applicative, ledit procédé étant rapide et simple à mettre en œuvre. Le procédé permet d’une part de prévenir d’un incident et d’autre part d’apporter une ou plusieurs mesures préventives avant la survenue dudit incident ou d’un dysfonctionnement de la chaine applicative et par conséquent de l’infrastructure informatique.
L’invention a en outre pour but de proposer un dispositif informatique pour la prévention d’incident sur une chaine applicative, ledit dispositif informatique permet de prévenir d’un incident tout en apportant une mesure préventive avant la survenue d’un incident.
[Brève description de l’invention]
A cet effet, l’invention porte sur un procédé de prévention d’incident sur une chaine applicative, ledit procédé étant exécuté par un dispositif informatique comprenant une mémoire de données configurée pour mémoriser des données de profils d’incident, des données de résolution d’incident et des données de profils de résolution, lesdites données de résolution d’incident comportant des instructions exécutables permettant d’initier des actions préventives, ledit procédé comprenant :
- une étape de réception, par un module d’analyse, de données de comportement d’une chaine applicative,
- une étape d’identification, par le module d’analyse, d’au moins un état accidentogène en fonction des données de comportement d’une chaine applicative reçues et des données de profils d’incident préalablement mémorisés,
- une étape de sélection, par un module d’application, d’au moins une action préventive en fonction de l’au moins un état accidentogène identifié et des données de résolution d’incident préalablement mémorisés, de préférence ladite action préventive étant associée à une valeur de temps de déploiement,
- une étape d’application automatique, par le module d’application, de l’au moins une action préventive correspondant à l’état accidentogène identifié et de préférence dont la valeur de temps de déploiement est inférieure à une valeur de durée avant incident sur la chaine applicative, et
- une étape de vérification de la prévention d’incident, par un module d’alerte, comportant une mesure de l’efficacité de l’action préventive appliquée en fonction de données de comportement d’une chaine applicative et des données de profils de résolution préalablement mémorisés.
Le procédé selon l’invention permet de prévoir un incident sur une chaine applicative et d’apporter une ou plusieurs mesures préventives. Les prévisions selon le procédé sont optimisées et améliorées dans le sens ou celles-ci sont précises, justes, fiables et adaptées à un état accidentogène, autrement dit bien avant la survenue de l’incident correspondant à l’état accidentogène identifié.
En outre, le procédé selon l’invention permet d’apporter une ou plusieurs mesures préventives adaptées à l’incident ou au dysfonctionnement prédit en permettant une corrélation automatique entre des données de comportement, des données de profils d’incident, des données de profils de résolution et des données de résolution d’incident.
De façon particulièrement avantageuse, le procédé selon l’invention permet en outre de surveiller la stabilité et le comportement de la chaine applicative après application de l’action préventive afin d’assurer l’absence d’incident sur ladite chaine applicative après l’application d’une mesure préventive et assurer une suppression des conditions détectées associées à l’état accidentogène. Ainsi, le procédé permet de valider ou non que la mesure préventive ait bien eu l’effet escompté. En outre ceci permet de garantir le bon fonctionnement de la chaine applicative eta fortiorià long terme. En effet, les mesures préventives peuvent être initiées relativement tôt avec une identification d’un état accidentogène se faisant donc généralement principalement sur les premières périodes des profils. Ainsi, il est avantageux de coupler cela à une surveillance du comportement après application du correctif pour valider son effet.
Le procédé permet en outre un gain de temps et une meilleure gestion de la prévention des incidents en permettant par exemple la sélection par le dispositif informatique d’une ou plusieurs mesures préventives adaptées et en assurant son déploiement avant la survenue de l’incident. En outre, la détection par profil de résolution permet de détecter plus facilement les situation post accidentelles en limitant la surveillance et l’analyse à quelle sondes spécifiques.
Le procédé permet donc et de préférence de façon automatique l’application d’une ou plusieurs mesures préventives adaptées et spécifiques à un incident ce qui se traduit par une réduction des incidents sur la chaine applicative et donc un meilleur fonctionnement.
Selon d’autres caractéristiques optionnelles du procédé,
ce dernier peut inclure facultativement une ou plusieurs des caractéristiques suivantes, seules ou en combinaison :
- il comporte une étape de génération automatique, lors d’une phase d’apprentissage, d’un ou de plusieurs scripts codant pour une action préventive. Ainsi, le procédé selon l’invention permet d’automatiquement générer les solutions à implémenter à l’avenir et d’apprendre des solutions préventives mise en œuvre par les équipes lors de la phase d’apprentissage.
- Il comprend une étape de comparaison, par le module d’analyse, des données de comportement d’une chaine applicative reçues avec les données de profils d’incidents préalablement mémorisées. Ainsi, le procédé selon l’invention pourra continuer à évaluer le comportement de la chaine applicative dans ces composantes logicielles et matérielles et le comparer précisément avec un comportement attendu, fonction de l’action préventive implémentée.
- Il comprend une étape de calcul, par le module d’analyse, d’une valeur de durée avant incident, de préférence à partir des données de comportement d’une chaine applicative et des données de profils d’incident préalablement mémorisés. La connaissance d’une durée avant incident peut être d’une importance primordiale comme information à destination des équipes de maintenance ou pour choisir une action préventive adaptée au degré d’urgence de la situation.
- Il comprend une étape de comparaison, par le module d’application, de la valeur de durée avant incident à des valeurs de temps de déploiement des actions préventives, de préférence l’au moins une action préventive sélectionnée présentant un temps de déploiement inférieur à la valeur de durée avant incident. Ainsi, le procédé sera en mesure d’appliquer une solution pouvant intervenir avant la survenue d’un incident. Le procédé de prévention d’incident présentera alors une efficacité renforcée.
- Il comprend une étape d’identification, par le module d’application, de plusieurs actions préventives et une étape de calcul, par le module d’analyse, d’une valeur d’indice de performance de la prédiction pour chacun des états accidentogènes identifiés. Cela permet de sélectionner au moins une action préventive en fonction de la valeur d’indice de performance de la prédiction et éventuellement des valeurs de temps de déploiement. En effet, plusieurs états accidentogènes peuvent être prédits mais certains pourront présenter une valeur d’indice de performance de la prédiction plus élevé reflétant une probabilité plus élevée de survenue.
- Il comprend une étape de comparaison, par le module d’alerte, de données de comportement collectées postérieurement à l’application de l’au moins une action préventive avec des données de profils de résolution préalablement mémorisées. Ainsi, le procédé selon l’invention pourra continuer à évaluer le comportement de la chaine applicative dans ses composantes logicielles et matérielles et le comparer précisément avec un comportement attendu, fonction de l’action préventive implémentée.
- Il comporte une étape de calcul, par le module d’alerte, d’une valeur d’indice d’efficacité de l’au moins une action préventive appliquée. En particulier, la valeur d’indice d’efficacité peut être calculé à partir de la comparaison entre les données de comportement collectées postérieurement à l’application de l’au moins une action préventive et les données de profils de résolution préalablement mémorisées.
D'autres mises en œuvre de cet aspect comprennent des systèmes informatiques, des appareils et des programmes informatiques correspondants enregistrés sur un ou plusieurs dispositifs de stockage informatiques, chacun étant configuré pour effectuer les actions d’un procédé selon l’invention. En particulier, un système d’un ou de plusieurs ordinateurs peut être configuré pour effectuer des opérations ou des actions particulières, notamment un procédé selon l’invention, grâce à l’installation d’un logiciel, micrologiciel, matériel ou d’une combinaison de logiciels, micrologiciels ou matériel installé sur le système. En outre, un ou plusieurs programmes informatiques peuvent être configurés pour effectuer des opérations ou des actions particulières grâce à des instructions qui, lorsqu'elles sont exécutées par un appareil de traitement de données, obligent l'appareil à effectuer les actions.
L’invention porte en outre surun programme informatiquepour la prévention d’incident sur une chaine applicative, comportant des instructions de code de programme pour la mise en œuvre d’un procédé selon l’invention, lorsque ledit programme informatique est exécuté sur un dispositif informatique.
L’invention porte en outresurdispositif informatiquepour la prévention d’incident sur une chaine applicative, ledit dispositif informatique comprenant :
- Une mémoire de données configurée pour mémoriser des données de profils d’incident, des données de résolution d’incident et des données de profils de résolution, lesdites données de résolution d’incident comportant des instructions exécutables permettant d’initier des actions préventives,
- Un module d’analyse configuré pour :
- recevoir des données de comportement d’une chaine applicative ;
- identifier au moins un état accidentogène en fonction des données de comportement d’une chaine applicative reçues et des données de profils d’incidents préalablement mémorisées,
- Un module d’application configuré pour :
- sélectionner au moins une action préventive en fonction de l’au moins un état accidentogène identifié et des données de résolution d’incident préalablement mémorisées, de préférence ladite action préventive étant associée à une valeur de temps de déploiement ;
- appliquer automatiquement l’au moins une action préventive correspondant à l’état accidentogène identifié et de préférence dont la valeur de temps de déploiement est inférieure à une durée avant incident sur la chaine applicative,
- Un module d’alerte configuré pour vérifier la prévention d’incident comportant une mesure de l’efficacité de l’action préventive appliquée en fonction de données de comportement d’une chaine applicative et des données de profils de résolution préalablement mémorisées.
L’invention porte en outre surun système de préventiond’incident comprenant une chaine applicative et un dispositif informatique selon l’invention.
D’autres avantages et caractéristiques de l’invention apparaitront à la lecture de la description suivante donnée à titre d’exemple illustratif et non limitatif, en référence aux Figures annexées :
Les figures 2A à 2C, représentent les différentes étapes d’un mode de réalisation du procédé selon l’invention avec notamment :
Les figures 3A et 3B, représentent les modes de réalisation d’un système selon l’invention avec notamment :
Des aspects de la présente invention sont décrits en référence à des organigrammes et / ou à des schémas fonctionnels de procédés, d'appareils (systèmes) et de produits de programme d'ordinateur selon des modes de réalisation de l'invention.
Sur les figures, les organigrammes et les schémas fonctionnels illustrent l'architecture, la fonctionnalité et le fonctionnement d'implémentations possibles de systèmes, de procédés et de produits de programme d'ordinateur selon divers modes de réalisation de la présente invention. A cet égard, chaque bloc dans les organigrammes ou blocs-diagrammes peut représenter un système, un dispositif, un module ou un code, qui comprend une ou plusieurs instructions exécutables pour mettre en œuvre la ou les fonctions logiques spécifiées. Dans certaines implémentations, les fonctions associées aux blocs peuvent apparaître dans un ordre différent que celui indiqué sur les figures. Par exemple, deux blocs montrés successivement peuvent, en fait, être exécutés sensiblement simultanément, ou les blocs peuvent parfois être exécutés dans l'ordre inverse, en fonction de la fonctionnalité impliquée. Chaque bloc des schémas de principe et / ou de l'organigramme, et des combinaisons de blocs dans les schémas de principe et / ou l'organigramme, peuvent être mis en œuvre par des systèmes matériels spéciaux qui exécutent les fonctions ou actes spécifiés ou effectuer des combinaisons de matériel spécial et d'instructions informatiques.
En outre, lorsque l’on prête une action à un dispositif ou un module selon l’invention celle-ci est en fait effectuée par un microprocesseur du dispositif ou module commandé par des codes instructions enregistrés dans une mémoire du dispositif ou du module. Si l’on prête une action à une application, celle-ci est en fait effectuée par un microprocesseur du dispositif ou du module dans une mémoire duquel les codes instructions correspondant à l’application sont enregistrés.
[Description de l’invention]
Dans la suite de la description on entend par «prévention» l’action de prévenir, c’est-à-dire empêcher, la survenue d’un effet ou d’un état. Cela passe en particulier dans le cadre de l’invention par la mise en œuvre d’une action permettant d’empêcher la survenue d’au moins un incident ou dysfonctionnement d’une chaine applicative.
Par «script» au sens de l’invention on entend tout ou partie d’un programme chargé de faire exécuter une action et de préférence une action préventive.
Les termes «incident» ou «dysfonctionnement» au sens de l’invention, correspondent à un ralentissement ou un arrêt de fonctionnement d’une partie au moins de l’infrastructure informatique et de ses applications (une chaine applicative ou ses briques applicatives). Un incident technique peut être causé par une erreur réseau, un échec de processus ou encore une défaillance d’une partie du système. Un dysfonctionnement selon l’invention peut correspondre à la survenue d’un incident matériel ou d’une congestion sur la structure informatique hébergeant une chaine applicative.
L’expression «chaine applicative» au sens de l’invention correspond à un ensemble d’applications, reliées entre elles par un flot d’information et visant à proposer, au travers de plusieurs processus, une ou plusieurs fonctionnalités pouvant faire l’objet d’un accord de niveau de service (SLA). L’expression « brique applicative » au sens de l’invention correspond à une composante d’une application. La combinaison de briques applicatives est souvent nécessaire pour le fonctionnement d’applications, notamment d’applications métier, comme par exemple une application Web, une plateforme de partage de contenu ou une plateforme de calcul. Les briques applicatives de l’infrastructure informatique incluent, par exemple, un serveur ftp, un serveur de messagerie électronique, un serveur d’application Java et/ou une ou plusieurs bases de données.
Par «infrastructure informatique», on entend au sens de l’invention un ensemble de structures informatiques (i.e. dispositifs informatiques) apte à faire fonctionner une application ou une chaine applicative. L’infrastructure informatique peut être un ou plusieurs serveurs, ordinateurs, ou encore contrôleurs industriels. Ainsi, l’infrastructure informatique peut correspondre à un ensemble d’éléments comportant un processeur, une interface de communication et de la mémoire
Par «sonde» ou «sonde informatique», on entend au sens de l’invention un dispositif, logiciel ou processus associé à un équipement qui permet d’effectuer, de gérer et/ou de faire remonter vers un équipement informatique des mesures, des valeurs destinées à informer entre autres de l’état de fonctionnement de la chaine applicative et par exemple des ressources ou niveau de ressource. Cela peut correspondre au sens large à des valeurs sur l’utilisation de ressources, des valeurs de paramètres d’exécution d’applications ou encore des valeurs de l’état de fonctionnement des ressources. Une sonde selon l’invention englobe donc également les logiciels ou processus capable de générer des journaux applicatifs ou des historiques des événements (« log file » en terminologie anglosaxonne). En outre, les sondes peuvent aussi correspondre à des capteurs physiques tels que des capteurs de température, d’humidité, de fuites d’eau, de consommation électrique, de mouvement, d’air conditionné, et de fumée.
Dans la suite de la description, on entend par «Ressource» ou « Ressource matérielle », des paramètres, des capacités ou des fonctions de dispositifs informatiques permettant le fonctionnement d’une brique applicative, d’une application ou d’une chaine applicative. Un même dispositif informatique est associé généralement à plusieurs ressources. De même, une même ressource est généralement partagée entre plusieurs chaines applicatives. Par exemple, le terme « ressource » peut inclure : des disques réseaux caractérisé par exemple par leurs entrées/sorties, la lecture/écriture sur des disques, le taux d’utilisation de la mémoire, un réseau caractérisé par sa bande passante, un processeur caractérisé par exemple par son utilisation (en pourcent) ou le taux d’occupation de ses caches, une mémoire vive caractérisée par la quantité allouée, ou de façon plus globale le temps de latence d’un processus ou les pertes de paquets. Il n’est pas nécessaire de suivre toutes les ressources d’une infrastructure informatique pour mettre en œuvre le procédé selon l’invention et il est possible de former un groupe de ressources critiques dont l’utilisation est particulièrement importante. On entend par «utilisation des ressources», la consommation d’une ressource par exemple par une application métier.
On entend par «traiter», «calculer», «déterminer», «afficher», «extraire» «comparer» ou plus largement «opération exécutable», au sens de l’invention, une action effectuée par un dispositif ou un processeur sauf si le contexte indique autrement. À cet égard, les opérations se rapportent à des actions et / ou des processus d’un système de traitement de données, par exemple un système informatique ou un dispositif informatique électronique, tel qu’un ordinateur, qui manipule et transforme les données représentées en tant que quantités physiques (électroniques) dans les mémoires du système informatique ou d'autres dispositifs de stockage, de transmission ou d'affichage de l'information. Ces opérations peuvent se baser sur des applications ou des logiciels.
Les termes ou expressions «application», «logiciel», «code de programme», et «code exécutable» signifient toute expression, code ou notation, d'un ensemble d'instructions destinées à provoquer un traitement de données pour effectuer une fonction particulière directement ou indirectement (e.g. après une opération de conversion vers un autre code). Les exemples de code de programme peuvent inclure, sans s'y limiter, un sous-programme, une fonction, une application exécutable, un code source, un code objet, une bibliothèque et/ou tout autre séquence d'instructions conçues pour l'exécution sur un système informatique.
On entend par «processeur», au sens de l’invention, au moins un circuit matériel configuré pour exécuter des opérations selon des instructions contenues dans un code. Le circuit matériel peut être un circuit intégré. Des exemples d'un processeur comprennent, sans s'y limiter, une unité de traitement central, un processeur graphique, un circuit intégré spécifique à l'application (ASIC) et un circuit logique programmable.
On entend par «couplé», au sens de l’invention, connecté, directement ou indirectement avec un ou plusieurs éléments intermédiaires. Deux éléments peuvent être couplés mécaniquement, électriquement ou liés par un canal de communication.
L’expression «interface homme-machine» au sens de l’invention correspond à tout élément permettant à un être humain de communiquer avec un ordinateur en particulier et sans que cette liste soit exhaustive, un clavier et des moyens permettant en réponse aux ordres entrés au clavier d’effectuer des affichages et éventuellement de sélectionner à l’aide de la souris ou d’un pavé tactile des éléments affichés sur l’écran. Un autre exemple de réalisation est un écran tactile permettant de sélectionner directement sur l’écran les éléments touchés par le doigt ou un objet et éventuellement avec la possibilité d’afficher un clavier virtuel.
On entend par «module» au sens de l’invention, un dispositif, un élément physique ou virtuel pouvant faire partie d’un système et pouvant posséder ses propres mécanismes interne (pilotes et périphériques etc…), capacités et fonctionnalités. Un module au sens de l’invention peut correspondre à une extension, une carte, un code, un pilote, un programme, un logiciel, un disque, un fichier, une extension, un équipement informatique, un composant ou périphérique, etc…
Le terme «corrélation» au sens de l’invention correspond à une relation statistique, causale ou non, entre deux variables ou les valeurs de deux variables. Au sens le plus large, toute association statistique est une corrélation mais ce terme désigne par exemple la proximité entre deux variables et l’établissement d’une relation d’ordre. Le terme « causale » ou « causalité » au sens de l’invention correspond à une relation statistique causale entre deux variables ou les valeurs de deux variables. En particulier, une des variables est une cause qui est entièrement ou partiellement responsable de la valeur de l’autre variable au travers d’un effet. La valeur de première variable peut par exemple être considérée comme une cause d’une valeur (actuelle ou future) de la seconde variable. Que cela soit pour la corrélation ou la causalité, une ou plusieurs variables peuvent avoir une relation statistique avec une ou plusieurs autres variables. En outre, une corrélation ou causalité indirect(e) au sens de l’invention correspond à l’existence d’une chaine de lien de corrélation ou de causalité entre une première variable et une autre variable. Par exemple, une première variable est corrélée à une seconde variable qui est elle-même corrélée à une troisième variable qui est enfin corrélée avec une autre variable.
Par «état accidentogène» on entend un état de la chaine applicative pouvant refléter une anomalie et précédent un incident ou un dysfonctionnement de la chaine applicative. Les anomalies étant en particulier des observations dont les caractéristiques diffèrent significativement des données de comportement de la chaine applicative. Par significativement, on entend au sens de l’invention une différence de plus de 5%, de préférence de plus de 10%, de façon plus préférée de plus de 15% et de façon encore plus préférée de plus de 20%. Alternativement, la significativité peut être déterminée par des tests statistiques connus de l’homme de l’art.
Par «durée» au sens de l’invention, on entend une période de temps pouvant comprendre une pluralité d’intervalles temporels. Une période peut correspondre à un ou plusieurs jours, une ou plusieurs semaines, un ou plusieurs mois, une ou plusieurs années, mais aussi à des périodes plus courtes telles qu’une ou plusieurs heures.
Par «intervalle temporel» au sens de l’invention on entend un espace-temps, limité dans le temps entre deux instants. Un intervalle de temps peut correspondre à un ou plusieurs jours, une ou plusieurs semaines, un ou plusieurs mois, une ou plusieurs années, mais aussi à des périodes plus courtes telles qu’une ou plusieurs heures. De préférence un intervalle temporel comprend un indicateur de début et de fin accompagné d’une durée ou bien un intervalle temporel comprend un indicateur de début ou de fin, l’indicateur étant accompagné d’une durée.
Le terme «motif» au sens de l’invention correspond à une pluralité de valeurs par exemple sous la forme d’un groupe de données correspondant à un instant précis pour différents paramètres ou sous la forme d’une séquence de valeurs pour un ou plusieurs paramètres pouvant correspondre à un intervalle temporel. A titre d’exemple non limitatif, il peut s’agir de profil et d’évolution d’un profil au cours du temps.
Dans la suite de la description, les mêmes références sont utilisées pour désigner les mêmes éléments.
Les techniques de gestion des infrastructures informatiques ou des chaines applicatives s’exécutant sur de telles infrastructures informatiques sont généralement basées sur des seuils ou des modèles de détection d’incidents permettant d’informer les personnes en charge de ces infrastructures de la survenue d’un incident ou de la survenue probable d’un incident. Les personnes sont ensuite en charge de procéder aux actions préventives ou correctives permettant de prévenir ou de résoudre l’incident.
Cela entraine souvent une perte de temps et une sur sollicitation des équipes de maintenance. Pour répondre à cela, les inventeurs ont développé une solution permettant d’automatiquement prédire la survenue d’un incident, mettre en place des actions préventives puis évaluer la performance de ces actions. Ainsi, les équipes de maintenance d’une infrastructure informatique peuvent se concentrer essentiellement sur des incidents exceptionnels et les incidents ayant déjà été résolus ou dont les méthodes de préventions sont déjà connues peuvent être traitées automatiquement et en autonomie par la présente invention.
Ainsi, selon un premier aspect, l’invention porte surun procédé 1 de préventiond’incident sur une chaine applicative tel qu’illustré sur lafigure 1. Le procédé peut être exécuté par un dispositif informatique.
Comme cela a été mentionné, leschaines applicativessont généralement composées de briques applicatives en interaction pour rendre un ou plusieurs services comme par exemple à proposer des applications telles qu’une application Web, une plateforme de partage de contenu ou une plateforme de calcul. Les chaines applicative sont également composées de l’ensemble des infrastructures utilisés par ses briques applicatives (serveur, stockage, réseaux…). En particulier, un procédé 1 de prévention selon l’invention peuvent s’appliquer à la prévention d’un incident sur une brique applicative telle que, par exemple, un serveur ftp, un serveur de messagerie électronique, un serveur d’application Java et/ou une ou plusieurs bases de données.
L’invention sera décrite dans le cadre d’uneinfrastructure informatiqueet plus particulièrement une infrastructure informatique en production dont les ressources sont utilisées par deschaines 2 applicativesconstituées de briques applicatives 2a, 2b, 2c, 2d. Toutefois l’invention ne se limite pas à ce cadre et peut trouver d’autres applications dans d’autres cadres ou même domaines.
Comme cela est illustré à lafigure 1, un procédé 1 de prévention selon l’invention comporte en particulier une étape de réception 300 de données de comportement d’une chaine applicative, une étape d’identification 500 d’au moins un état accidentogène, une étape de sélection 600 d’au moins une action préventive, une étape d’application automatique 700 de l’au moins une action préventive correspondant à l’état accidentogène identifié, et une étape de vérification 800 de la prévention d’incident.
En outre, le procédé de prévention selon l’invention peut aussi comporter une étape de configuration 100, une étape de collecte 200 de données de comportement, une étape de traitement 400 des données de comportement.
Ainsi, de façon avantageuse mais non limitante, le procédé peut comprendreune étape de configuration 100. Cette étape de configuration 100, mentionnée à la figure 1, est en particulier décrite à lafigure 2A.
De préférence, l’étape de configuration 100 comporte la mémorisation de données de profils d’incident 130, la mémorisation de données de résolution d’incident 140 et/ou la mémorisation de données de profils de résolution 150. Cette étape peut être réalisée par un dispositif informatique comprenant une mémoire de données configurée pour mémoriser les données de profils d’incident, les données de résolution d’incident et/ou les données de profils de résolution.
De préférence, les données de profils d’incidents, les données de résolution d’incident et/ou les données de résolution d’incident sont issues d’une étape préalable de collecte de données de comportement 110. Le procédé peut également comprendre une étape de traitement ou de pré-traitement des données de comportement 120. Ces données de comportement collectées et traitées ou prétraitées peuvent alors permettre la mémorisation de données de profils d’incident 130, la mémorisation de données de résolution d’incident 140 et/ou la mémorisation de données de profils de résolution 150.
Les données de profils d’incidentpouvant être utilisés dans le cadre de la présente invention sont par exemple basés sur des paramètres de fonctionnement de chaine applicative tels que des utilisations des ressources, des historiques des événements, des erreurs logicielles, des erreurs matérielles, des temps de réponse, du trafic des applications, de la charge de service, du trafic réseau, des modifications de fichiers, du nombre d’utilisateurs d’un service, du nombre de session, du nombre de processus actifs, des valeurs de températures, des valeurs d’hygrométrie, et la consommation électrique, la consommation en ressources telles que CPU, mémoire, I/O. En particulier, les données de profils d’incident peuvent se baser sur des valeurs de débit du réseau, d’une latence du réseau, d’un taux d'utilisation de CPU, d’un taux d’utilisation de mémoire, d’un temps de réponse du serveur, d’un nombre de pages lentes et/ou d’un nombre de transactions. Ainsi il peut s’agir de données logicielles ou matérielles.
Il est possible dans une première étape de configuration d’importer des profils accidentogène rencontrer sur d’autres chaines applicatives et/ou des seuils limites (ressources, paramètres applicatif et/ou système...).
Les données de profils d’incident pourront également comporter des valeurs de durée avant incident ou des données permettant de calculer une valeur de durée avant incident.
Les paramètres de fonctionnement de chaine applicative pourront faire référence à des valeurs brutes, mais également à des valeurs issues de traitements mathématiques préalables, obtenus par exemple dans le cadre d’une étape de traitement 120. Par exemple, les paramètres de fonctionnement de chaine applicative pourront correspondre à des vitesses de modification, des accélérations, des extrêmes, des moyennes, des médianes…
Un procédé selon l’invention peut par exemple utiliser des valeurs de seuils prédéterminés ou des motifs prédéterminés, en particulier pour identifier un état accidentogène, sélectionner une action préventive et/ou vérifier l’efficacité de l’action préventive engagée. Les données de profils d’incident peuvent être des seuils prédéterminés et par exemple être renseignées avant la mise en œuvre de la surveillance par un opérateur via une interface graphique. Néanmoins, les données de profils d’incident utilisées lors de l’identification d’un état accidentogène sont de préférence déterminées lors de l’étape de configuration, ladite étape de configuration étant préférablement spécifique à l’infrastructure informatique ou aux chaines applicatives étudiées.
Ainsi, les données de profils d’incident pourront correspondre à un ou plusieurs seuils relatifs à des paramètres de fonctionnement de chaine applicative. Dans ce cas, le procédé selon l’invention pourra comporter au préalable à l’étape d’identification d’au moins un état accidentogène, une étape dedétermination de seuil 131et de mémorisation desdits seuils. Les seuils pourront par exemple correspondre à des valeurs minimales et/ou maximales de pourcentage d’utilisation de ressources (ex : taux d’occupation des processeurs CPUs, de la mémoire RAM), des temps de réponse, des temps de traitement ou à des valeurs de variation autorisée en fonction du temps. Les seuils peuvent être inscrits dans un fichier de configuration (par exemple pour chaque brique d’une chaine applicative et/ou pour chaque ressource). Ces seuils peuvent être utilisés pour déterminer si la chaine applicative ne dévie pas d’un comportement attendu et en particulier des données de comportement générées et mémorisées ou ne satisfait pas des performances voulues.
Avantageusement, les données de profils d’incident pourront également correspondre à des motifs de comportement d’un ou de plusieurs paramètres de fonctionnement de chaine applicative. Dans ce cas, le procédé selon l’invention pourra comporter au préalable à l’étape d’identification d’au moins un état accidentogène, une étape dedétermination de motifs 132et de mémorisation desdits motifs.
Dans le cadre de la détermination d’un motif, un procédé 1 de prévention selon l’invention peut comporter le calcul d’une série temporelle non accidentogène. Le calcul d’une série temporelle non accidentogène comporte généralement une composante normale, une composante de tendance ou variation globale (« trend » en terminologie anglo-saxonne) et un résidu. Dans le cadre de la prévention d’incident, la composante normale concerne la façon dont les choses changent au cours d'une période donnée, par exemple une année, mois, semaine, jour ; la composante de tendance prend en compte la tendance de la façon dont les choses changent ; et c’est la valeur de résidu qui permettra de déterminer avec le plus de précision s’il y a ou non une anomalie et donc un risque de la survenue d’un incident ou d’un dysfonctionnement traduit par un état accidentogène.
En particulier, les valeurs des données générées peuvent être des séries temporelles et sont donc associées à une temporalité (hebdomadaire, quotidien, horaire, mensuel, etc.). Dans ce contexte il existe de nombreuses méthodes permettant d’isoler des valeurs anormales de ces séries temporelles.
Ainsi, avantageusement, un procédé selon l’invention peut mettre en œuvre une méthode d’apprentissage permettant la génération d’une série temporelle non accidentogène et les nouvelles données collectées par les sondes seront comparées (par exemple après traitement) à la série temporelle non accidentogène de façon à identifier des états accidentogène à partir de données déviant significativement de la série temporelle non accidentogène.
Les données de résolution d’incident, peuvent avantageusement comporter des instructions exécutables permettant d’initier automatiquement des actions préventives. Les actions préventives se basent sur des données de résolution d’incident permettant d’apporter une solution spécifique à chaque donnée de profils d’incident.
Avantageusement, les données de résolution d’incidents peuvent comporter des valeurs de temps de déploiement. Ces valeurs de temps de déploiement sont généralement prédéterminées en particulier au moment de l’étape de configuration 100 du procédé selon l’invention.
En particulier, les données de résolution d’incident permettent d’agir sur une ou plusieurs chaines applicatives et/ou sur une infrastructure informatique de façon à éviter la survenue d’un incident. Ces données de résolution d’incident présentent également des langages ou codes variés et adaptés à tous types d’actions correctives pouvant être mises en œuvre. Ainsi, l’application d’une action préventive correspond à la mise en œuvre de données de résolution d’incident prédéterminée.
Par exemple, les données de résolution d’incidents peuvent correspondre à des données de type script dont le format pourra varier selon les systèmes d’exploitation considérés, par exemple il peut s’agir des scripts Shell SSH, Power Shell, GPO (ou Group Policies Object en terminologie anglosaxonne). Dans ces conditions, les seules limites de fonctionnalités des scripts sont ce que permet le système d’exploitation sur lequel ils vont s’exécuter et leur langages.
Typiquement, les scripts peuvent être dédiés à un incident spécifique par exemple : configuration de briques applicatives, déploiement ou interruption d’une ou de plusieurs nouvelles instances sur un cluster, configuration CPU d’une machine, configuration mémoire d’une machine, et configuration du nombre de ports pouvant être ouverts simultanément.
Ainsi, la mise en œuvre d’un script permet de réaliser une modification adaptée pouvant correspondre à une modification du niveau de ressource. Ceci permet avantageusement d’éviter à un utilisateur d’intervenir et par exemple de commettre une erreur d’environnement ; de valeur à mettre en place ou encore de commande. Ceci permet également d’accélérer la prévention de la survenue d’un incident sur la chaine applicative. Le script pourra comporter toutes les commandes nécessaires aux modifications et pourra notamment être configuré pour redémarrer la chaine applicative si nécessaire.
Le procédé selon l’invention peut comprendre en particulierune étape d’acquisition 141 d’un scriptpermettant d’agir sur une ou plusieurs chaines applicatives et/ou sur une infrastructure informatique de façon à éviter la survenue d’un incident.
L’acquisition d’un script 141 pourra par exemple correspondre à l’enregistrement d’un script apporté par l’intermédiaire d’une IHM et associé manuellement à des données de résolution d’incidents et plus particulièrement à des données de profils d’incident.
Ainsi, un profil d’incident pourra être associé à une ou plusieurs résolution d’incident. En effet, pour un même incident à venir, plusieurs solutions seront en mesure de prévenir la survenue de l’incident et présenteront différentes caractéristiques.
Le procédé selon l’invention peut comprendre en particulierune étape de génération automatique 142 d’un scriptpermettant d’agir sur une ou plusieurs chaines applicatives et/ou sur une infrastructure informatique de façon à éviter la survenue d’un incident. La génération automatique 142 d’un script pourra être réalisée lors d’une phase d’apprentissage lors de laquelle des solutions manuelles apportées par les équipes de maintenance à des survenue d’incident ou des risques de survenue d’incident pourront faire l’objet de la génération d’un script capable de reproduire les actions réalisées par les équipes de maintenance. De tels scripts automatiquement générés sont particulièrement pertinents lorsque les actions réalisées par les équipes qu’ils reproduisent ont été suffisantes pour prévenir ou corriger un incident. En particulier, de tels scripts peuvent coder des redémarrages de logiciel, de chaine applicative ou de matériel ou encore des modifications de paramètre de fonctionnement de logiciel de chaine applicative ou de matériel.
Les données de profil de résolutionpeuvent, comme les données de profil d’incident, être basées sur des paramètres de fonctionnement de chaine applicative ou d’infrastructure informatique. Ainsi, il peut s’agir de données logicielles ou matérielles.
Comme précédemment, les paramètres de fonctionnement de chaine applicative pourront faire référence à des valeurs brutes, mais également à des valeurs issues de traitements mathématiques préalables, obtenus par exemple dans le cadre d’une étape de traitement. Par exemple, les paramètres de fonctionnement de chaine applicative pourront correspondre à des vitesses de modification, des accélérations, des extrêmes, des moyennes, des médianes…
Les données de profil de résolution correspondent avantageusement à des valeurs de paramètres de fonctionnement de chaine applicative ou d’infrastructure informatique attendues après la mise en place d’une action préventive. Ainsi, alors que les paramètres de fonctionnement peuvent avoir subi une dégradation conduisant à la détection d’un état accidentogène, suite à la mise en œuvre de l’action préventive, ces paramètres de fonctionnement devraient évoluer et présenter des valeurs améliorées.
Les données de profil de résolution pourront correspondre à un ou plusieurs seuils relatifs à des paramètres de fonctionnement de chaine applicative. Dans ce cas, le procédé selon l’invention pourra comporter préalablement à l’étape d’identification d’au moins un état accidentogène, une étape dedétermination de seuil 151et de mémorisation desdits seuils. Cette étape de détermination de seuil 151 se fera de préférence suite à la mise en place d’une action préventive.
Avantageusement, les données de profils de résolution pourront également correspondre à des motifs de comportement d’un ou de plusieurs paramètres de fonctionnement de chaine applicative. Dans ce cas, le procédé selon l’invention pourra comporter préalablement à l’étape d’identification d’au moins un état accidentogène, une étape dedétermination de motifs 152et de mémorisation desdits motifs.
Ces seuils ou motifs correspondent à un fonctionnement corrigé de l’infrastructure informatique ou de la chaine applicative tel que cela est attendu après la mise en application de l’action préventive.
En outre, le procédé peut comprendre une étape de configuration des sondes. Cette étape peut permettre de définir quelles données doivent être collectées. Ainsi, un fichier de surveillance comportant des règles de collecte de métriques peut être préétabli. Ces règles de collecte de métriques peuvent spécifier des données qui doivent être enregistrées lors de l’exécution de la ou des chaines applicatives par exemple. En, outre ces règles de collecte peuvent comporter la définition des différents seuils correspondant par exemple à des valeurs minimales et/ou maximales de pourcentage d’utilisation de ressources (ex : taux d’occupation des processeurs CPUs, de la mémoire RAM), des temps de réponse, des temps de traitement ou à des valeurs de variation autorisée en fonction du temps. Les seuils peuvent être inscrits dans un fichier de configuration (par exemple pour chaque dispositif de la chaine applicative et/ou pour chaque ressource). Ceci permet de ne pas saturer la mémoire et de ne mémoriser ou traiter que des valeurs considérée commea prioripertinentes.
En particulier, la configuration des sondes peut comprendre une étape de sélection des données de comportement à collecter. Cette étape peut être réalisée par une interface homme-machine configurée pour configurer les sondes 41.
Pour sa mise en œuvre, de façon avantageuse mais non limitante, le procédé peut comprendreune étape de collecte de données de comportement 200. Cette étape de collecte est présentée à lafigure 2B.Alternativement, le procédé peut se baser sur des données collectées préalablement par exemple par un autre système informatique.
Les données de comportement d’une chaine applicative peuvent correspondre à toute donnée liée au fonctionnement d’une chaine applicative et pouvant influencer son fonctionnement. Il peut s’agir de données matérielles ou logicielles. Ainsi, les données de comportement peuvent correspondre à l’utilisation des ressources, la disponibilité des ressources, les historiques des événements, les temps de réponse, des temps de traitement mais également le statut des ports, le nombre de files de message JDBC ou JMS, le taux d’occupation du système de fichiers, le taux de fonctionnement du ramasse miettes ou récupérateur de mémoires, le trafic des applications, la charge de service, le trafic réseau, le nombre d’utilisateurs d’un service, le nombre de session, le nombre de processus, des valeurs de températures, des valeurs d’hygrométrie, de fuite d’eau, de mouvement, de fumée et de consommation électrique mais aussi de données de CPU, mémoire, swap, réseau, des informations sur les utilisateurs, les groupes, les supports de stockages, sur l’utilisation du kernel, ou les processus les plus consommateurs. Avantageusement, les données peuvent être génériques ou spécifiques à une chaine applicative.
Les données de comportement pourront refléter une saisonnalité s’appliquant à chaque chaine applicative. Avantageusement, les profils d’incident (e.g. seuils ou motifs) seront déterminés de façon à prendre en compte cette saisonnalité.
De préférence, l’étape de collecte de données de comportement 200 est mise en œuvre au cours du temps par des sondes. La ou les sondes 41 permettent par exemple de collecter des données sur l’utilisation des ressources, la disponibilité des ressources, les historiques des événements, les erreurs matérielles, les erreurs logicielles, les temps de réponse, le trafic des applications, la charge de service, le trafic réseau des modifications de fichiers, le nombre d’utilisateurs d’un service, le nombre de session, le nombre de processus, des valeurs de températures, des valeurs d’hygrométrie, de fuite d’eau, de mouvement, de fumée et la consommation électrique.
Ces mesures peuvent par exemple être réalisées à partir de sonde. Il existe de nombreux types de sondes, et l’homme du métier sera en capacité de déterminer quel type de sonde pourra faire remonter vers un équipement informatique des mesures ou des valeurs. Ainsi, à titre d’exemple il peut s’agir de toute instruction exécutable capable de fournir des valeurs telle qu’une sonde de type « Dynatrace », « AppDynamics », « Nigel’s Monitor » (Nmon) ou « Performance Monitor » (Perfmon). Par ailleurs les langages de programmation supportés peuvent être multiples et variés. Les sondes « Dynatrace » ou « Appdynamics » permettent par exemple l'accès à des données pertinentes sur l'état d'une application. Les sondes Nmon permettent par exemple d’afficher les données de CPU, mémoire, swap, réseau, des informations sur les utilisateurs, les groupes, les supports de stockages, sur l’utilisation du kernel, ou les processus les plus consommateurs. Les sondes de type Perfmon permettent de mesurer les performances d’une infrastructure informatique et plus particulièrement d’une chaine applicative. Les informations collectées peuvent par exemple correspondre à des pourcentages d’utilisation de ressources, des temps de réponse, des temps de traitement mais également le statut des ports, le nombre de files de message JDBC ou JMS, le taux d’occupation du système de fichiers, le taux de fonctionnement du ramasse miettes ou récupérateur de mémoires (pour « garbage collector » en anglais) pour les applications J2EE (pour « Java Enterprise Edition » en anglais).
Ces sondes peuvent être associées à chaque donnée (e.g. temps de réponse, ressource ou fonctionnalités) pour remonter les informations représentant par exemple le fonctionnement de l’infrastructure informatique. La ou les sondes peuvent suivre en continu ou à des intervalles configurables les données de façon à obtenir des informations par type de donnée en fonction du temps. Le suivi en continu correspond par exemple à des mesures réalisées à une fréquence inférieure ou égale à une heure, de préférence inférieure ou égale à trente minutes, de façon plus préférée inférieure ou égale à cinq minutes, par exemple inférieure ou égale à dix secondes. A noter que toutes les données ne seront pas nécessairement mesurées à une fréquence identique. Ces données et informations peuvent être stockées dans une mémoire.
Dans certains modes de réalisation, un dispositif informatique selon l’invention comporte une interface homme-machine permettant de définir les sondes sur chaque machine qui remontent les données provenant de l’utilisation de la chaine applicative.
Alternativement, cette étape peut être mise en œuvre automatiquement à partir des données de profil d’incident. En effet, dans le cadre du procédé selon l’invention, la collecte de données de comportement par les sondes peut être automatiquement limitée aux paramètres de fonctionnement présents dans les données de profils d’incident.
Ceci permet un gain de temps car les données à traiter et/ou à analyser sont moins nombreuses. Par exemple, il peut s’agir de donnée CPU, mémoire, I/O ou encore de temps de latence d’un processus, des pertes de paquets, des débits, des valeurs d’utilisation de ressources et des temps de réponse par requête, des temps de réponse par type d’acte métier, des temps d’exécution de certains traitements (tel que des traitements par batch) et des niveaux d’utilisation maximum des différentes ressources des différents serveurs.
Le procédé selon l’invention comprendune étape de réception 300 des données de comportement collectées.Cette étape est de préférence réalisée par le module d’analyse 11. L’étape de réception 300 des données de comportement collectées peut être réalisée par l’intermédiaire d’une interface de communication présente entre les sondes 41 et le module d’analyse 11.
De façon préférée, les données de comportement sont réceptionnées en continue, c’est-à-dire selon une fréquence inférieure ou égale à une heure, de préférence inférieure ou égale à trente minutes, de façon plus préférée inférieure ou égale à cinq minutes, par exemple inférieure ou égale à dix secondes.
Comme cela a été mentionné, les données de comportement collectées peuvent avoir subi un prétraitement avant réception, par exemple au niveau des sondes, permettant de limiter le flux de données transférées.
Néanmoins, le procédé 1 de prévention selon l’invention peut comprendreune étape de traitement 400 des données de comportement collectées.Cette étape de traitement 400 pourra être mise en œuvre par le module d’analyse 11.
L’étape de traitement 400 des données générées ou collectées peut comprendre la transformation des données en données pouvant être analysées par un module d’analyse. Cette étape peut au moins en partie être basée sur les principes généraux des mathématiques statistiques et plus particulièrement de l’apprentissage, qu’il soit supervisé ou non supervisé. En outre, de façon préférée, cette étape peut inclure des étapes de réduction de la dimensionnalité, une normalisation des données, un rééchantillonnage, une agrégation de données, et/ou un recodage des variables. Ceci permet de faciliter les étapes ultérieures de la prévention d’un incident sur une chaine applicative.
Avantageusement, les données de comportement sont traitées en temps réel, c’est-à-dire dans un délai inférieur ou égal à dix minutes, de façon plus préférée inférieur ou égal à cinq minutes, de façon encore plus préférée inférieur ou égal à une minute après l’étape de collecte de données de comportement. Ainsi, cela permet l’application d’une action préventive dans un délai inférieur ou égal à dix minutes, de façon plus préférée inférieur ou égal à cinq minutes, de façon encore plus préférée inférieur ou égal à une minute après l’étape de collecte de données de comportement.
Le procédé selon l’invention comprend avantageusement uneétape d’identification 500 d’au moins un état accidentogène. De préférence, l’étape d’indentification est réalisée par le module d’analyse 11. Cette étape est illustrée à la figure 1 et en particulier à lafigure 2B.
L’étape d’identification 500 d’au moins un état accidentogène peut être précédée par la réception par le module d’analyse des données de profils d’incident, des données de résolution d’incident et des données de profils de résolution. Ces données sont par exemple chargées en mémoire à partir d’une mémoire de données 13 à laquelle le module d’analyse aura accès directement (mémoire locale) ou via une interface de communication (mémoire distante tel qu’un serveur). De façon avantageuse, l’étape d’identification d’au moins un état accidentogène peut être précédée par la réception par le module d’analyse des motifs issus des données de profils d’incidents. Ceci permet de détecter plus facilement un état accidentogène tout en limitant la surveillance et les traitements ou analyse.
L’étape d’identification peut comprendre l’identification d’une déviation, d’une dispersion, le dépassement d’un seuil (inférieurement ou supérieurement), l’égalisation par rapport à un seuil ou encore une correspondance. Ainsi, l’identification peut en partie reposer sur une comparaison de valeurs mesurées à des valeurs de références. En particulier, l’étape d’identification 500 d’au moins un état accidentogène peut être réalisée en fonction des données de comportement réceptionnées (valeurs mesurées) et des données de profils d’incident préalablement mémorisés (valeurs de référence).
L’identification d’un état accidentogène permet de prédire un incident ou un dysfonctionnement avant sa survenue sur une ou plusieurs chaines applicatives. De préférence, cette identification peut reposer sur des valeurs prédéterminées générées à partir du fonctionnement normal passé (e.g. 1 à 3 mois) et/ou lors d'un incident ou d’un dysfonctionnement.
Alternativement, l’étape d’identification d’un état accidentogène peut être identifier manuellement. Ainsi un utilisateur peut identifier par lui-même une déviation, une dispersion, le dépassement d’un seuil (inférieurement ou supérieurement), l’égalisation par rapport à un seuil ou encore une correspondance.
Selon une autre alternative, l’étape d’identification peut être réalisée de façon semi-automatique. Ainsi, il peut s’agir d’une identification d’un état accidentogène réalisée par le module d’analyse et par un utilisateur.
De préférence, l’étape d’identification comprend lacomparaison 510 des données de comportement avec les données de profils d’incidents préalablement mémorisées. De manière plus préférée, il s’agit de la comparaison des données de comportement traitées avec les données de profils d’incidents. De manière encore plus préférées, il s’agit de la comparaison des données de comportement traitées avec des seuils de profils d’incidents.
Les comparaisons peuvent être réalisées sur des données synchronisées temporellement ou en prenant en compte un décalage temporel (par exemple en utilisant des méthodes de calcul de corrélations croisées). Alternativement, il peut également s’agir de méthodes statistiques comme celle de Pearson ou celle de Spearman. En particulier, il peut s’agir de corrélation. L’identification d’une corrélation peut être réalisée entre les données de comportement et des données de profils d’incident préalablement mémorisés. Lorsqu’une corrélation est identifiée entre ces données, cela permet l’identification d’un état accidentogène.
La comparaison peut comporter l’établissement de corrélations entre des données transformées telles que des données de comportement traitées et des valeurs de références telles que les données de profils d’incident. En particulier, la variation (i.e. valeur de dérivée) d’une ou plusieurs données peut être corrélée avec un état accidentogène. Par exemple, la volatilité de la donnée de comportement utilisation CPU peut être corrélée à des données de profil d’incident utilisation CPU pour identifier un état accidentogène.
Alternativement, il peut s’agir de calculer une distance des données de comportement collectées à la normalité. Alternativement encore, l’identification peut comporter la mise en œuvre d’une méthode statistique permettant de générer des valeurs de distance à la normalité pour chacune des données de comportement.
En particulier, il est possible de mettre en œuvre des méthodes univariées ou éventuellement des méthodes multivariées de type Analyse en Composantes Principales. En outre, pour chacune des données de comportement, l’étape d’identification peut comporter une segmentation des données passées et un calcul de l’appartenance de la valeur des données de comportement à un des groupes constitués, en particulier des données de profil incident. Ainsi, il est possible de déterminer un état accidentogène.
Cette étape, couplée aux étapes précédentes permet une surveillance en continue de la chaine applicative. Avantageusement, elle permet une prédiction d’un incident grâce à l’identification d’un état accidentogène. Ceci permet d’identifier un état accidentogène préalablement à la survenue d’un incident. En particulier, elle permet d’identifier un état accidentogène en fonction d’incident ou dysfonctionnement antérieurs pouvant être similaires.
En outre, l’étape d’identification 500 d’au moins un état accidentogène peut comporter une étape de calcul 520 d’une valeur de durée avant incident. Cette étape de calcul 520 d’une valeur de durée avant incident peut être réalisée sur la base des données de comportement mais également sur des données préalablement mémorisées telles que des données de profil d’incident. En effet, les données de profil d’incident peuvent comporter des valeurs de durées avant incident. Par exemple, si un seuil de 80 % de consommation CPU est dépassé avec une accélération supérieure à un seuil prédéterminé alors un incident pourra survenir dans une durée de 50 minutes.
En outre, l’étape d’identification 500 d’au moins un état accidentogène peut comporter une étape de calcul 530 d’une valeur d’indice de performance de la prédiction. Cette étape de calcul 530 d’une valeur d’indice de performance de la prédiction peut être réalisée pour chacun des états accidentogènes identifié. Ce calcul pourra en particulier être réalisé sur la base des données de comportement mais également sur des données préalablement mémorisées telles que des données de profil d’incident. En effet, le procédé peut s’appuyer par exemple sur la similarité entre les données de profil d’incident et les données de comportement de façon à calculer une valeur d’indice de performance de la prédiction. Par exemple, si la comparaison entre les données de comportement et les données de profil d’incident permet d’identifier deux profils d’incident similaires, alors la présente invention pourra fournir une valeur d’indice de performance de la prédiction pour chacun des états accidentogènes identifié de façon à évaluer la probabilité de défaillance associé à chacun des états accidentogènes identifié. Dans ce contexte, un profil d’incident présentant une similarité de 99 % avec les données de comportement collectées correspondra à un état accidentogène présentant une valeur d’indice de performance de la prédiction supérieure à celui d’un profil d’incident présentant une similarité de 82 % avec les données de comportement collectées. Ainsi, il est possible d’identifier plusieurs états accidentogènes probables chacun associé à un profil d’incident donné et chacun pouvant être associé à une valeur d’indice de performance de prédiction différent. Par ailleurs, une valeur d’indice de performance de la prédiction peut être particulièrement avantageuse lorsque les calculs sont réalisés à partir de profils. En effet, afin de prédire un incident, les calculs sont de préférence réalisés sur des données traitées en temps réel ce qui peut être une source d’erreur. Grâce à la valeur d’indice de performance, il est possible d’améliorer la précision, la fiabilité et la justesse du procédé de prévention.
En outre, l’étape d’identification 500 d’au moins un état accidentogène peut comporter une étape d’envoi d’une alerte 540. Ainsi, les services de maintenance pourront être informés de la détection d’au moins un état accidentogène et éventuellement des données de profils d’incident associées à ce ou ces états accidentogènes. L’alerte pourra prendre la forme d’un message de type courriel ou d’un message applicatif destiné à être affiché sur un tableau de bord.
De façon avantageuse, si un état accidentogène est identifié, le procédé selon l’invention peut comprendre une étape d’identification de la cause à l’origine de l’état accidentogène. Il s’agit donc de l’analyse de la cause d’origine ou « Root Cause » en terminologie anglosaxonne permettant d’identifier une ou plusieurs ressources responsables de l’état accidentogène. Pour cela, le procédé peut comprendre une analyse des incidents et dysfonctionnements antérieurs. En effet, les profils incidents sont de préférence mémorisés ce qui permet au module d’analyse de retrouver automatiquement l’origine dudit incident ou dudit dysfonctionnement. De façon avantageuse, le procédé selon l’invention peut comprendre une mémorisation de chaque cause d’origine de chaque incident ou dysfonctionnement antérieur. En outre, la mémorisation de chaque cause d’origine peut également comprendre la mémorisation des mesures correctrices associées à chaque cause d’origine. Ceci est particulièrement avantageux puisque les données de résolution d’incident sont préalablement mémorisées dans la mémoire de données. Ceci permet un gain de temps pour la suite du procédé de prévention. En outre, cette étape permet de déterminer des données de résolution d’incident spécifique et adaptée. Ceci permet d’améliorer la précision, la justesse et donc l’efficacité du procédé selon l’invention.
De façon avantageuse, le procédé selon l’invention peut comprendre une étape de mise à jour de la mémoire de données. Cette étape de mise en jour comprend notamment l’implémentation des données de profils d’incident et de cause d’origine. De façon avantageuse, l’étape de mise à jour peut être paramétrable selon une fréquence prédéterminée. Ceci permet d’éviter de surcharger la mémoire de données avec des mises à jour incessantes et les différentes données générées par les sondes.
Le procédé selon l’invention peut comprendreune étape de sélection 600, d’au moins une action préventiveen fonction de l’au moins un état accidentogène identifié et des données de résolution d’incident préalablement mémorisés. De préférence, l’étape de sélection est réalisée par un module d’application 14.
De façon avantageuse, les données de résolution d’incident peuvent être modifiables et modifiées sans nécessiter un redémarrage.
En outre, l’étape de sélection peut comprendre l’élection de n’importe quelle action préventive (données de résolution d’incident), qu’elle soit matérielle ou logicielle.
De façon avantageuse, le procédé peut comprendre une étape de modification automatique de la mémoire de données 13 avec des données de résolution d’incident correspondant à l’incident détecté.
Alternativement, le procédé peut comprendre une étape de modification manuelle de la mémoire de données 13 avec des données de résolution d’incident correspondant à l’incident détecté.
Ainsi, la sélection d’au moins une action préventive peut correspondre à des données de type scripts tel que divulgué précédemment, une mise à disposition de ressource(s), une reconfiguration, un re-paramétrage, ou une action manuelle.
Alternativement, l’étape de sélection peut comprendre la sélection en fonction d’une ou plusieurs données de résolution d’incident préalablement mémorisés de plusieurs actions préventives. Ainsi lorsqu’un état accidentogène identifié prévoit un incident ou un dysfonctionnement majeur, plusieurs actions peuvent également être mise en place de façon automatique ou manuelle ou les deux.
Si une intervention manuelle doit être mise en place, le procédé selon l’invention comprend la génération d’une alerte, de préférence par un module d’alerte 12, comportant l’action préventive qui doit être mise en œuvre par un opérateur. En effet, certaines actions préventives ne peuvent être exécutées par l’intermédiaire d’un script (e.g. changement disque dur) et une telle alerte permet à un opérateur de disposer de toutes les informations nécessaires à la modification manuelle de l’infrastructure informatique ou de la chaine applicative considérée.
Alternativement, un état accidentogène peut être identifié sans qu’au moins une action préventive lui soit associée, par exemple l’état accidentogène n’a encore jamais été identifié et aucune action préventive associée n’existe ou parce qu’aucune action préventive ne correspond à l’état accidentogène identifié. Ainsi, une alerte peut être émise et une intervention manuelle peut également être mise en place. De préférence, la ou les actions préventives mises en œuvre manuellement dans ce cas pourront être mémorisées. De cette façon, le procédé de prévention se trouve implémenté et donc amélioré.
Le procédé selon l’invention peut comprendreune étape d’identification 610 d’une ou de plusieurs actions préventives. De préférence cette étape est réalisée par le module d’application 14.
En effet, un état accidentogène pourra correspondre à plusieurs actions préventives possibles et donc différentes données de résolution d’incidents, chacune présentant des caractéristiques différentes et des avantages dans certaines conditions.
Comme mentionné, les données de résolution d’incidents peuvent comporter avantageusement des valeurs de temps de déploiement. En effet, certaines actions préventives pourront être déployées en quelques dizaines de secondes, ou en quelques minutes alors que d’autres nécessiteront des dizaines de minutes ou des heures. Le procédé selon l’invention peut comprendreune étape de comparaison 620 d’une valeur de durée avant incident aux valeurs de temps de déploiement des actions préventives.
Cette étape de comparaison permet de savoir si l’action préventive sera déployée avant la survenue de l’incident ou non. Ainsi, le procédé selon l’invention permettra de sélectionner une action préventive pouvant être déployée avant l’incident technique.
En outre, si la valeur de temps de déploiement de toutes les actions préventives est supérieure au temps avant survenue de l’incident, une alerte peut être mise en place afin d’alerter l’utilisateur. Celui-ci pourra alors réaliser une action préventive manuelle pour assurer le bon fonctionnement de la chaine applicative.
De plus, le procédé selon l’invention peut comporter à ce stadeune étape d’envoi d’une alerte 630par exemple à destination d’un opérateur, l’alerte spécifiant l’action préventive sélectionnée et une valeur de temps de déploiement.
Le procédé selon l’invention peut comprendreune étape d’application automatique 700, de l’au moins une action préventivecorrespondant à l’état accidentogène identifié et de préférence dont la valeur de temps de déploiement est inférieure à une valeur de durée avant incident sur la chaine applicative. De préférence, cette étape est réalisée par le module d’application 14. Le module d'application 14 peut correspondre à tout dispositif informatique capable de se connecter aux machines (physiques ou virtuelles) supportant les chaines applicatives de façon semi-automatisée ou automatisée. Le module d’application 14 sera avantageusement configuré pour pouvoir exécuter des scripts sur les différents serveurs de la chaine de liaison, pour pouvoir notamment mettre en place la surveillance et déployer des correctifs. Il pourra être supporté par la même infrastructure informatique que les chaines applicatives sous surveillance ou sur une infrastructure informatique indépendante.
Cette étape permet d’apporter une solution adaptée, efficace et plus rapide à la survenue d’un incident par rapport à l’état accidentogène identifié.
Comme illustré à lafigure 2C, le procédé selon l’invention peut comporter uneétape de chargement 710 d’un script.Ce chargement peut par exemple être réalisé dans une mémoire de données du dispositif informatique mettant en œuvre le procédé de prévention d’incident selon l’invention. Alternativement, le script peut être transmis par le dispositif informatique mettant en œuvre le procédé de prévention d’incident selon l’invention à une infrastructure informatique supportant l’exécution de la chaine applicative présentant un état accidentogène.
En outre, le procédé selon l’invention peut comporter uneétape d’exécution 720 du script préalablement chargé.Le script peut par exemple être exécuté par le dispositif informatique mettant en œuvre le procédé de prévention d’incident selon l’invention. Alternativement, le script peut être exécuté par l’infrastructure informatique supportant l’exécution de la chaine applicative présentant un état accidentogène.
Avantageusement, le procédé selon l’invention peut comporter une étape de mesure d’une nouvelle valeur de temps de déploiement de l’action préventive sélectionnée. Cette étape de mesure peut par exemple comporter un suivi de l’exécution du script ou alors des données de comportement ou des paramètres de fonctionnement de la chaine applicative. Par exemple, considérant le moment d’initiation de l’action préventive et le moment de la fin d’exécution du script, il est possible pour le procédé selon l’invention de comprendre une étape de mesure d’une nouvelle valeur de temps de déploiement. Cette nouvelle valeur pourra être mémorisée au niveau des données de résolution d’incident.
Comme cela a été présenté, le procédé peut faire appel, par exemple lors de l’étape 620 de comparaison, à une valeur de temps de déploiement prédéterminée. Néanmoins de façon préférée, une fois une action préventive sélectionnée, le procédé comporte une mesure d’une nouvelle valeur de temps de déploiement et avantageusement une mise à jour 730 de la valeur de temps de déploiement prédéterminée à partir de cette nouvelle valeur de temps de déploiement. De façon plus préférée, la mise à jour de la valeur de temps de déploiement prédéterminée comporte la prise en compte des données de comportement ayant conduit à l’identification d’un état accidentogène. Cela permet d’augmenter la précision du procédé et son efficacité. En effet, en fonction des états accidentogènes, certaines valeurs de temps de déploiement peuvent être faussées et il est important de pouvoir se baser lors de l’étape 620 de comparaison, sur une valeur de temps de déploiement prédéterminée la plus juste possible.
Comme illustré aux figures 1 et 2B, le procédé selon l’invention peut avantageusement comprendreune étape de vérification 800 de la prévention d’incident. De préférence, cette étape est réalisée par un module d’alerte 12.
L’étape de vérification comprend une mesure de l’efficacité de l’action préventive appliquée en fonction de données de comportement d’une chaine applicative collectées postérieurement à l’application de l’au moins une action préventive et des données de profils de résolution préalablement mémorisés.
Cette étape permet d’assurer que l’incident ne surviendra pas et que le procédé de prévention a été efficace.
Cette étape peut par exemple comprendre une surveillance des données de comportement et leur comparaison au cours du temps avec des données de profil de résolution.
La surveillance peut être continue, ponctuelle ou selon une fréquence prédéfinie. En effet, selon le type l’incident (qui est évité) il peut s’avérer nécessaire que la surveillance soit plus ou moins longue.
L’étape de vérification permet en outre de vérifier la stabilité des paramètres de fonctionnement de la chaine applicative.
En particulier, le procédé selon l’invention peut comporter uneétape de collecte 810 de données de comportement postérieuresà l’application de l’action préventive. Ces données comme précédemment concernent des paramètres de fonctionnement de la chaine applicative ou de l’infrastructure informatique. Ces données pourront être collectées par des sondes 41 et pourront ou non faire l’objet d’un traitement.
Le procédé selon l’invention peut aussi comporter uneétape de comparaison 820 des données de profil de résolution avec les données de comportement postérieures collectées.La comparaison peut notamment concerner la comparaison des données de comportement postérieures collectées à des seuils ou à des motifs. Cela permet de déterminer si l’action préventive appliquée entraine bien un comportement attendu par la chaine applicative ou l’infrastructure informatique.
Les comparaisons peuvent être réalisées sur des données synchronisées temporellement ou en prenant en compte un décalage temporel (par exemple en utilisant des méthodes de calcul de corrélations croisées). Alternativement, il peut également s’agir de méthodes statistiques comme celle de Pearson ou celle de Spearman. En particulier, il peut s’agir de corrélation. L’identification d’une corrélation entre les données de comportement et des données de profils de résolution préalablement mémorisés. Lorsqu’une corrélation est identifiée entre ces données, cela permet l’identification d’une résolution correcte et donc d’une prévention de l’incident.
En outre, le procédé selon l’invention peut comporterune étape de calcul 830 d’une valeur d’indice d’efficacité de l’au moins une action préventive appliquée.Cette étape de calcul 830 d’une valeur d’indice d’efficacité de la prévention peut être réalisée pour chacune des actions préventives appliquées. Ce calcul pourra en particulier être réalisé sur la base des données de comportement mais également sur des données préalablement mémorisées telles que des données de profil d’incident. En effet, le procédé peut s’appuyer par exemple sur la similarité entre les données de profil de résolution et les données de comportement postérieures de façon à calculer une valeur d’indice d’efficacité. Par exemple, si la comparaison entre les données de comportement postérieures et un profil de résolution associé à l’action préventive appliquée permet d’identifier une forte similarité, alors la présente invention pourra fournir une valeur d’indice d’efficacité élevé. Par exemple « élevé » peut correspondre sur une valeur relative, une valeur en pourcentage, une valeur numérique, ou tout autre valeur prédéfinie. Par exemple il peut s’agir d’une valeur sur une échelle de 1 à 10, 10 étant la meilleure valeur d’indice d’efficacité, une valeur supérieure ou égale à 6. Au contraire, dans le cas où les données de comportement postérieures présentent une forte dissemblance avec le profil de résolution attendu, alors la présente invention pourra fournir une valeur d’indice d’efficacité élevé.
Dans ce contexte, le procédé selon l’invention pourra comporter une étape d’envoi 840 d’une alerte par exemple à un opérateur. L’alerte pourra par exemple comporter un bilan de l’action préventive.
Enfin, le procédé selon l’invention peut comprendre une étape de génération 900 d’un tableau de bord. Une telle étape de génération permet d’informer les utilisateurs sur le fonctionnement de la chaine applicative et permet également d’identifier quelles sont les éventuelles actions manuelles qu’un utilisateur devra mettre en place en complément des actions préventives appliquées automatiquement.
Ainsi, un tableau de bord au sens de l’invention peut comprendre des informations telles que les taux de succès ou d’échec d’une action préventive, les temps de déploiements, le nombre d’incidents résolus, le nombre d’état accidentogène identifiés, le nombre d’incident évité etc… Ces tableaux de bord permettent donc d’informer les utilisateurs mais également d’informer les utilisateurs sur la pertinence du procédé de prévention d’un incident sur une chaine applicative au sens de l’invention.
L’invention porte en outre surun programme d’ordinateurpour la prévention d’incident sur une chaine applicative, comportant des instructions pour la mise en œuvre du procédé selon l’invention. Ce programme comprend des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé selon l’invention. Un tel programme peut être enregistré, stocké sur tout support pouvant par la suite être mis en œuvre par un ordinateur. De préférence, un ordinateur peut également correspondre à tout moyen de lecture de programme tel que tablette, téléphone ou télévision.
L’invention porte en outresur undispositif informatique10 pour la prévention d’incident sur une chaine applicative.
En particulier, le dispositif informatique est configuré pour prévenir la survenue d’incident sur une chaine applicative supportée par une infrastructure informatique.
Ainsi, le dispositif informatique pourra prendre la forme d’une entité indépendante de l’infrastructure informatique supportant la chaine applicative ou bien être intégré au sein de cette infrastructure informatique et en partager les ressources tel qu’illustré sur les figures 3A et 3B.
De façon préférée, le dispositif informatique 10 pour la prévention d’incident selon l’invention ne partagera pas les mêmes ressources que la chaine applicative.
Comme illustré à lafigure 3A ou 3B, ledispositif informatiquecomprend une mémoire de données 13, un module d’analyse 11, un module d’application 14, un module d’alerte 12. En outre, le dispositif informatique peut comporter au moins une interface (non représentée).
En outre, Il faut comprendre que bien que non représenté, d'autres composants matériels et / ou logiciels pourraient être utilisé en conjonction avec un dispositif informatique 10.
De façon préférée, le dispositif informatique 10 pour la prévention d’incident sur une chaine applicative est configuré pour mettre en œuvre tout ou partie du procédé de prévention d’incident selon l’invention.
Lamémoire de données 13peut être apte à, de préférence configurée pour, mémoriser des données de profils d’incident, des données de résolution d’incident et des données de profils de résolution, lesdites données de résolution d’incident comportant des instructions exécutables permettant d’initier des actions préventives.
Alternativement, le dispositif informatique peut comporter plusieurs mémoires de donnée aptes à, de préférence configurées pour mémoriser des données de profils d’incident, des données de résolution d’incident et des données de profils de résolution. En outre, une mémoire de données peut être apte à, de préférence configurée pour, mémoriser toutes autres données ou valeurs telles que des seuils, des motifs, des scripts.
Une mémoire de données peut comprendre un référentiel de données sous forme de liste ou de table.Chaque liste ou table peut être associées à un type de données, à une brique applicative, à un incident ou encore à un état accidentogène.
Une mémoire de données peut avantageusement comporter une section non effaçable, physiquement isolée ou simplement agencée pour qu’un accès en écriture ou en effacement soit proscrit. Une mémoire de données peut en outre être agencée pour enregistrer les données mesurées par des sondes.
Pour cela, la mémoire de donnée peut être locale, distante et/ou partagée. Il peut s’agir de n’importe quel support lisible connu dans l’art, par exemple une mémoire volatile, telle qu'une mémoire vive statique (SRAM) et une mémoire vive dynamique (DRAM), et / ou une mémoire non volatile, telle que mémoire morte, mémoires flash, disques durs, disques optiques et bandes magnétiques, d’une mémoire programmable, effaçable, flash ou toutes autres mémoires permettant le stockage selon une durée prédéterminée ou non. En outre, il peut également s’agir de tout support de stockage de type disque dur, CD-ROM, disque amovible ou tout autre support de stockage connu.
De façon avantageuse, la mémoire peut être mise à jour afin d’améliorer et perfectionner les données mémorisées selon une ou plusieurs fréquences paramétrables.
Le dispositif informatique 10 selon un mode de réalisation de l’invention peut comprendreune ou plusieurs interfaces.De préférence, il peut comporter une interface de communication.
Une interface de communication peut en particulier être configuré pour recevoir des données et envoyer des données. De préférence, la communication peut être opérée par l’intermédiaire d’un protocole sans fils tel que wifi, 3G, 4G, et/ou Bluetooth. Ces échanges de données peuvent prendre la forme d’envoi et de réception de fichiers, possiblement cryptés et associés à une clé spécifique de receveur. La communication peut se faire via les ondes radios et un émetteur/récepteur à deux voies.
L’interface de communication permet d’une part la transmission d’une pluralité de données et de métadonnées mais peut d’autre part servir également à l’échange de données. Dans un mode de réalisation de la présente invention, le dispositif informatique 10 peut être couplé à une interface de communication, par exemple une interface réseau de type Ethernet, FiberChannel, InfiniBand ou n'importe quels dispositifs permettant au dispositif informatique 10 de communiquer avec un ou plusieurs autres dispositifs informatiques ou modules.
Ainsi, dans un mode de réalisation de la présente invention, le dispositif informatique 10 peut être couplé à une interface homme machine (IHM). L’IHM, comme déjà abordé, peut être utilisée pour permettre la transmission de paramètres aux dispositifs ou à l’inverse mettre à disposition de l’utilisateur les valeurs des données mesurées ou calculées par le dispositif. De façon générale, l’IHM est couplée de manière communicative avec un processeur et elle comprend une interface de sortie utilisateur et une interface d'entrée utilisateur.
L'interface de sortie utilisateur peut comprendre une interface d'affichage et de sortie audio et divers indicateurs tels que des indicateurs visuels, des indicateurs audibles et des indicateurs haptiques. L’interface d'entrée utilisateur peut comprendre un clavier, une souris ou un autre module de navigation curseur tel qu'un écran tactile, un pavé tactile, une interface d'entrée de stylet et un microphone pour l'entrée de signaux audibles tels qu'un discours d'utilisateur, des données et des commandes qui peuvent être reconnues par le processeur.
Ainsi, l’interface homme-machine, au sens de l’invention, correspond à tout élément permettant à un être humain de communiquer avec un ordinateur en particulier et sans que cette liste soit exhaustive, un clavier et des moyens permettant en réponse aux ordres entrés au clavier d’effectuer des affichages et éventuellement de sélectionner à l’aide de la souris ou d’un pavé tactile des éléments affichés sur l’écran. Un autre exemple de réalisation est un écran tactile permettant de sélectionner directement sur l’écran les éléments touchés par le doigt ou un objet et éventuellement avec la possibilité d’afficher un clavier virtuel.
Le dispositif informatique peut comprendre ou être couplé àun ou plusieurs processeurs. Un processeur peut être configuré pour manipuler des tables, des listes, des gestionnaires, des contrôleurs, des calculateurs et des ordonnanceurs. De préférence, le ou les processeurs sont aptes à, de préférence configurés pour, déterminer une correspondance entre les données ou pour réaliser des comparaisons de données.
Avantageusement, le ou les processeurs peuvent être aptes à, de préférence configurés pour, effectuer des déterminations, établir des connexions, effectuer des sélections entre différentes options d'informations, effectuer des évaluations liées aux données, interagir avec des capteurs ou modules couplés au dispositif informatique pour effectuer des opérations de mesure, convertir des informations d'un format à un autre (par exemple, entre différents protocoles tels que .wmv en .avi, etc.), et ainsi de suite.
En particulier, le dispositif informatique peut comprendreun module d’analyse11 apte à, de préférence configuré pour, recevoir des données de comportement d’une chaine applicative. Le module d’analyse peut en outre comprendre un ou plusieurs programmes, ou plus généralement un ou plusieurs ensembles d’instructions de programmes, lesdites instructions de programmes étant intelligibles par un ou plusieurs composants, processeurs, ou modules. L’exécution ou l’interprétation desdites instructions par un ou plusieurs composants, processeurs, ou modules provoque la réalisation des actions citées et attribuées au module d’analyse 11.
Le module d’analyse peut être apte à, de préférence configuré pour traiter des données collectées. Le module d’analyse peut également être apte à, de préférence configuré pour, identifier au moins un état accidentogène en fonction des données de comportement d’une chaine applicative reçues et des données de profils d’incidents préalablement mémorisées.
De façon avantageuse, le module d’analyse 11, peut être apte à, de préférence configuré pour, communiquer avec les modules, processeurs, composants du dispositif informatique. Par exemple, le module d’analyse peut communiquer avec la mémoire de données ou encore le module d’application.
Le dispositif informatique peut comprendreun module d’alerte 12.Le module d’alerte peut comprendre un ou plusieurs programmes, ou plus généralement un ou plusieurs ensembles d’instructions de programmes, lesdites instructions de programmes étant intelligibles par un ou plusieurs composants, processeurs, ou modules. L’exécution ou l’interprétation desdites instructions par un ou plusieurs composants, processeurs, ou modules provoque la réalisation des actions citées et attribuées au module d’alerte.
En particulier, le module d’alerte peut être apte à, de préférence configuré pour, générer des alertes. Ces alertes peuvent intervenir à différent moment, ou étape du procédé. Les alertes comprennent de préférence, différentes informations utiles pour un utilisateur, par exemple des indices d’efficacité, des bilans d’actions, au moins une action préventive.
L’alerte pourra prendre la forme d’un message de type courriel, un message graphique, un son ou d’un message applicatif destiné à être affiché sur un tableau de bord.
Avantageusement, le module d’alerte est également apte à, configuré pour, vérifier la prévention d’incident, et d’assurer la stabilité de la chaine applicative.
Le dispositif informatique peut comprendreun module d’application 14.Comme précédemment, le module d’application peut en outre comprendre un ou plusieurs programmes, ou plus généralement un ou plusieurs ensembles d’instructions de programmes, lesdites instructions de programmes étant intelligibles par un ou plusieurs composants, processeurs, ou modules. L’exécution ou l’interprétation desdites instructions par un ou plusieurs composants, processeurs, ou modules provoque la réalisation des actions citées et attribuées au module d’application.
Le module d’application peut être apte à, de préférence configurer pour, sélectionner au moins une action préventive en fonction de l’au moins un état accidentogène identifié et des données de résolution d’incident préalablement mémorisés, de préférence ladite action préventive étant associée à une valeur de temps de déploiement.
En outre, le module d’application peut être apte à, de préférence configurer pour, appliquer automatiquement l’au moins une action préventive correspondant à l’état accidentogène identifié et de préférence dont la valeur de temps de déploiement est inférieure à une valeur de durée avant survenue de l’incident sur la chaine applicative.
L’invention porte en outre surun système de préventiond’incident comprenantune infrastructure informatique supportantune chaine applicative et un dispositif informatique selon l’invention. Comme cela est présenté dans les figures 3A et 3B, un dispositif selon l’invention pourra être distinct ou intégré à l’infrastructure informatique portant les chaines applicatives sous surveillance.
Un système de prévention d’incident pourra en particulier comporter unclient 5.Le client correspond généralement, à tout matériel et/ou logiciel susceptible d’accéder au système et permettant par exemple sa configuration ou la consultation de données via une interface homme machine dédiée.
Un client peut également être apte à permettre la configuration du dispositif informatique, d’un de ses modules ou encore de la chaine applicative ou des sondes.
Un tel système de prévention d’incident, et plus largement la solution proposée par les inventeurs, sera capable comme cela a été décrit de prévoir un incident sur une chaine applicative et d’apporter une ou plusieurs mesures préventives. En outre, de telles mesures préventives seront apportées automatiquement et leur efficacité, au travers du comportement de la chaine applicative après application de l’action préventive, pourra être surveillée de façon à s’assurer de l’absence d’incident à venir sur ladite chaine applicative après l’application d’une mesure préventive.
Claims (10)
- Procédé (1) de prévention d’incident sur une chaine applicative, ledit procédé étant exécuté par un dispositif informatique (10) comprenant une mémoire de données (13) configurée pour mémoriser des données de profils d’incident, des données de résolution d’incident et des données de profils de résolution, lesdites données de résolution d’incident comportant des instructions exécutables permettant d’initier des actions préventives, ledit procédé comprenant :
- une étape de réception (300), par un module d’analyse (11), de données de comportement d’une chaine applicative,
- une étape d’identification (500), par le module d’analyse (11), d’au moins un état accidentogène en fonction des données de comportement d’une chaine applicative reçues et des données de profils d’incident préalablement mémorisés,
- une étape de sélection (600), par un module d’application (14), d’au moins une action préventive en fonction de l’au moins un état accidentogène identifié et des données de résolution d’incident préalablement mémorisés, de préférence ladite action préventive étant associée à une valeur de temps de déploiement,
- une étape d’application automatique (700), par le module d’application (14), de l’au moins une action préventive correspondant à l’état accidentogène identifié et de préférence dont la valeur de temps de déploiement est inférieure à une valeur de durée avant incident sur la chaine applicative, et
- une étape de vérification (800) de la prévention d’incident, par un module d’alerte (12), comportant une mesure de l’efficacité de l’action préventive appliquée en fonction de données de comportement d’une chaine applicative et des données de profils de résolution préalablement mémorisés. - Procédé (1) de prévention d’incident selon la revendication 1, caractérisé en ce qu’il comporte une étape (142) de génération automatique, lors d’une phase d’apprentissage, d’un ou de plusieurs scripts codant pour une action préventive.
- Procédé (1) de prévention d’incident selon la revendication 1 ou 2, caractérisé en ce qu’il comprend une étape de comparaison (510), par le module d’analyse (11), des données de comportement d’une chaine applicative reçues avec les données de profils d’incidents préalablement mémorisées.
- Procédé (1) de prévention d’incident selon l’une des revendications précédentes, caractérisé en ce qu’il comprend une étape de calcul (520), par le module d’analyse (11), d’une valeur de durée avant incident.
- Procédé (1) de prévention d’incident selon la revendication 4, caractérisé en ce qu’il comporte une étape de comparaison (620), par le module d’application (14), de la valeur de durée avant incident à des valeurs de temps de déploiement des actions préventives.
- Procédé (1) de prévention d’incident selon l’une des revendications précédentes, caractérisé en ce qu’il comprend une étape d’identification de plusieurs actions préventives et une étape de calcul (530), par le module d’analyse (11), d’une valeur d’indice de performance de la prédiction pour chacun des états accidentogènes identifiés.
- Procédé (1) de prévention d’incident selon l’une des revendications précédentes, caractérisé en ce qu’il comprend une étape d’identification (610), par le module d’application (14), d’une ou plusieurs actions préventives.
- Procédé (1) de prévention d’incident selon l’une des revendications précédentes, caractérisé en ce qu’il comporte une étape de calcul (830), par le module d’alerte (12), d’une valeur d’indice d’efficacité de l’au moins une action préventive appliquée.
- Dispositif (10) informatique pour la prévention d’incident sur une chaine applicative, ledit dispositif comprenant :
- une mémoire de données (13) configurée pour mémoriser des données de profils d’incident, des données de résolution d’incident et des données de profils de résolution, lesdites données de résolution d’incident comportant des instructions exécutables permettant d’initier des actions préventives,
- Un module d’analyse (11) configuré pour :
- recevoir des données de comportement d’une chaine applicative ;
- identifier au moins un état accidentogène en fonction des données de comportement d’une chaine applicative reçues et des données de profils d’incidents préalablement mémorisées,
- Un module d’application (14) configuré pour :
- sélectionner au moins une action préventive en fonction de l’au moins un état accidentogène identifié et des données de résolution d’incident préalablement mémorisées, de préférence ladite action préventive étant associée à une valeur de temps de déploiement ;
- appliquer automatiquement l’au moins une action préventive correspondant à l’état accidentogène identifié et de préférence dont la valeur de temps de déploiement est inférieure à une durée avant incident sur la chaine applicative,
- Un module d’alerte (12) configuré pour vérifier la prévention d’incident comportant une mesure de l’efficacité de l’action préventive appliquée en fonction de données de comportement d’une chaine applicative et des données de profils de résolution préalablement mémorisées.
- Programme informatique pour la prévention d’incident sur une chaine applicative, comportant des instructions de code de programme pour la mise en œuvre d’un procédé selon les revendications 1 à 8 lorsque ledit programme informatique est exécuté sur un dispositif informatique.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2003230A FR3108743B1 (fr) | 2020-03-31 | 2020-03-31 | Procede de prevention d’incident sur une chaine applicative et dispositif informatique de prevention d’incident |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2003230A FR3108743B1 (fr) | 2020-03-31 | 2020-03-31 | Procede de prevention d’incident sur une chaine applicative et dispositif informatique de prevention d’incident |
| FR2003230 | 2020-03-31 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3108743A1 true FR3108743A1 (fr) | 2021-10-01 |
| FR3108743B1 FR3108743B1 (fr) | 2023-05-05 |
Family
ID=71784190
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2003230A Active FR3108743B1 (fr) | 2020-03-31 | 2020-03-31 | Procede de prevention d’incident sur une chaine applicative et dispositif informatique de prevention d’incident |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3108743B1 (fr) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2013072232A1 (fr) * | 2011-11-15 | 2013-05-23 | Telefonica, S.A. | Procédé pour gérer des performances dans des applications multi-étages |
| EP3620928A1 (fr) * | 2018-09-07 | 2020-03-11 | Bull Sas | Dispositif et procede d analyse du comportement d'une brique applicative soumise a une rarefaction des ressources |
-
2020
- 2020-03-31 FR FR2003230A patent/FR3108743B1/fr active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2013072232A1 (fr) * | 2011-11-15 | 2013-05-23 | Telefonica, S.A. | Procédé pour gérer des performances dans des applications multi-étages |
| EP3620928A1 (fr) * | 2018-09-07 | 2020-03-11 | Bull Sas | Dispositif et procede d analyse du comportement d'une brique applicative soumise a une rarefaction des ressources |
Non-Patent Citations (2)
| Title |
|---|
| "Method for Problem Avoidance and Remediation by Means of Incremental Symptom Detection ED - Darl Kuhn", IP.COM, IP.COM INC., WEST HENRIETTA, NY, US, 5 November 2009 (2009-11-05), XP013135151, ISSN: 1533-0001 * |
| SARA KARDANI MOGHADDAM ET AL: "Performance-Aware Management of Cloud Resources", 30 August 2019, ACM COMPUTING SURVEYS, ACM, NEW YORK, NY, US, US, PAGE(S) 1 - 37, ISSN: 0360-0300, XP058440469 * |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3108743B1 (fr) | 2023-05-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3767467A1 (fr) | Procédé et dispositif de détermination d'une valeur d'indice de performance de prédiction d anomalies dans une infrastructure informatique à partir de valeurs d'indicateurs de performance | |
| EP3767558B1 (fr) | Procede et dispositif de determination d'une duree estimee avant un incident technique dans une infrastructure informatique a partir de valeurs d'indicateurs de performance | |
| EP0820013B2 (fr) | Procédé de surveillance en temps réel d'un système informatique pour son administration et l'aide à sa maintenance en phase d'exploitation | |
| US11093349B2 (en) | System and method for reactive log spooling | |
| EP3163445B1 (fr) | Mécanisme d'analyse de corrélation lors de la dégradation des performances d'une chaîne applicative | |
| EP3471356B1 (fr) | Dispositif et procede d'acquisition de valeurs de compteurs associes a une tache de calcul | |
| EP3767468A1 (fr) | Procédé et dispositif de détermination d'une valeur de risque d'incident technique dans une infrastructure informatique à partir de valeurs d'indicateurs de performance | |
| FR2882165A1 (fr) | Systeme et procede de traitements embarques d'essais en vol | |
| EP3846087A1 (fr) | Procede et systeme de selection d'un modele d'apprentissage au sein d'une pluralite de modeles d'apprentissage | |
| EP3620928A1 (fr) | Dispositif et procede d analyse du comportement d'une brique applicative soumise a une rarefaction des ressources | |
| US10169132B2 (en) | Predicting a likelihood of a critical storage problem | |
| EP3846091A1 (fr) | Procede et systeme de conception d'un modele de prediction | |
| US11809271B1 (en) | System and method for identifying anomalies in data logs using context-based analysis | |
| FR2923113A1 (fr) | Procede de gestion d'operations d'administration, de maintenance et de maintien en condition operationnelle, entite de gestion, et produit programme d'ordinateur correspondant. | |
| FR3108743A1 (fr) | Procede de prevention d’incident sur une chaine applicative et dispositif informatique de prevention d’incident | |
| EP3846047A1 (fr) | Procédé et système d'identification de variables pertinentes | |
| EP3767475A1 (fr) | Dispositif et procede pour l analyse de performances d'une application web | |
| EP3767474B1 (fr) | Procédé d'analyse de consommation de ressource d'une infrastructure informatique, alerte et dimensionnement | |
| FR2973131A1 (fr) | Procede et dispositif de detection d'incompatibilites d'interfaces logiques d'equipements de systemes embarques | |
| EP2996036A1 (fr) | Procédé de surveillance d'une architecture applicative comportant une pluralité de services | |
| EP4033361B1 (fr) | Procédé et dispositif de détermination d'au moins une machine impliquée dans une anomalie détectée dans une infrastructure informatique complexe | |
| EP3893470B1 (fr) | Procédé d' optimisation de mise à jour d' objets connectés et module applicatif | |
| FR3082018A1 (fr) | Dispositif et procede pour l'optimisation de l'utilisation dans le temps des ressources d'une infrastructure informatique | |
| EP3767476A1 (fr) | Dispositif et procede pour l'analyse de performances d'une application n-tier | |
| EP3926927A1 (fr) | Procede de communication et objets connectes |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20211001 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |