Rejoignez les principaux dirigeants d’aujourd’hui en ligne lors du Data Summit le 9 mars. S’inscrire ici.
Cet article a été rédigé par Ajay Singh, fondateur et PDG de Zebrium.
Les logiciels tombent parfois en panne, que ce soit dans le cloud, dans une appliance matérielle ou dans une infrastructure telle que la mise en réseau et la sécurité. C’est une réalité inévitable, principalement en raison des mises à jour fréquentes du code, combinées à la complexité et aux innombrables variables d’utilisation. Un problème avec une application devient coûteux pour les entreprises et peut même menacer la perte de clients, l’arrêt de paniers d’achat ou la réputation entachée.
La panne de Facebook de six heures en octobre 2021 a entraîné des pertes de 164 000 $ par minute et réduit la capitalisation boursière de l’entreprise d’environ 40 milliards de dollars. La panne AWS de décembre 2021 fait des ravages à travers les États-Unis Les banques, les sociétés de services et les autres détaillants subissent des pertes considérables lorsque les applications mobiles ou les applications Web échouent. Les pannes et les problèmes sont extrêmement coûteux, il est donc primordial de les résoudre rapidement. La pression est sur, et l’horloge tourne. Malheureusement, trouver la cause profonde de ces pannes est rarement simple et implique souvent un travail de détective considérable.
Dans le cas de la panne de Facebook à l’automne, Détecteur de descente a tweeté qu’il s’agissait de “la plus grande panne que nous ayons jamais vue sur Downdetector avec plus de 10,6 millions de rapports de problèmes du monde entier”. La panne a été enfin identifié comme un problème de changement de configuration. Selon le Institut de disponibilité Rapport d’analyse des pannes 2020, les pannes deviennent de plus en plus graves et coûteuses. Dans le même temps, y remédier devient plus complexe à mesure que les fonctionnalités se développent et que les dépendances à des éléments tels que les microservices logiciels et l’infrastructure cloud prolifèrent.
Pour trouver la cause première, dans un monde idéal, les ingénieurs et les équipes de support auraient des flux continus de journaux, un temps illimité pour les analyser et une compréhension du problème qu’ils sont sur le point de résoudre, mais c’est rarement le cas. Souvent, ils reçoivent un ensemble de fichiers journaux après coup, sans autre contexte ni compréhension du problème. Ensuite, on leur dit de mettre leurs talents de détective à profit. Étant donné que ces fichiers ne sont souvent qu’un instantané d’une période de quelques heures le jour de l’incident, établir une compréhension de ce qui n’a pas fonctionné peut sembler une tâche ardue, un mystère insoluble.
Cependant, grâce à certaines techniques d’apprentissage automatique (ML) très intelligentes, même un ensemble statique de journaux peut rapidement fournir les réponses. Analyse des causes profondes basée sur le ML peut identifier des modèles et des corrélations qui pourraient ne pas être évidents à l’œil nu d’un ingénieur de support et découvrir la cause d’un incident beaucoup plus rapidement que par une analyse manuelle. Non seulement cela augmente la vitesse de résolution, mais cela améliore également la productivité et l’efficacité de l’équipe.
Dans la plupart des cas, le défi de trouver la cause profonde est compliqué par la taille et le nombre de journaux, leur nature désordonnée et non structurée et le manque de clarté sur ce que l’on essaie de trouver. Tous ces facteurs favorisent le ML, non pas parce que la tâche est impossible pour du personnel qualifié, mais parce que le ML fonctionne plus vite que les yeux humains et s’étend au-delà des limites des ressources humaines disponibles.
Lors du dépannage en analysant les journaux, les ingénieurs qualifiés commencent généralement par rechercher dans les journaux des événements de journal rares et inattendus et les corrèlent avec les erreurs. Plus le volume de journaux et de données est important, plus c’est difficile pour les humains et plus la proposition de valeur de en utilisant le ML. La difficulté de la tâche augmente à mesure que l’on passe de l’examen de données volumineuses à la recherche d’anomalies et à l’établissement de corrélations qui fournissent un aperçu significatif. Avec ML, chaque étape peut être accomplie de manière autonome et peut facilement être adaptée à presque n’importe quel volume de données.
Le ML est également mieux adapté pour déterminer la véritable cause première d’un problème. Dans une course contre la montre et avec des contraintes de ressources d’équipe, les ingénieurs et le personnel de support trouveront souvent un remède rapide ou une solution de contournement plutôt que d’identifier et de traiter sa véritable cause première. Cela signifie souvent que le même problème se reproduira et peut également affecter de nombreux autres clients. Cependant, lorsque le ML est utilisé pour découvrir la cause profonde, l’ingénierie peut utiliser son temps limité pour travailler directement sur la source du problème et l’empêcher d’avoir un impact continu.
Bien entendu, le ML n’est pas la panacée pour l’ensemble de la prise en charge des applications. Les professionnels formés doivent encore revoir les Résultats du ML et procéder à la correction appropriée. Bien qu’une grande partie du processus global puisse désormais être automatisée, les membres de l’équipe doivent appliquer leur expertise à la tâche la plus importante : le « dernier kilomètre ». Le résultat de l’utilisation du ML accélère l’ensemble du processus, améliore l’efficacité de l’équipe et laisse aux professionnels plus de temps pour travailler sur des tâches importantes.
Avec la complexité croissante des applications et des environnements et la demande croissante des organisations de support, l’introduction du ML pour les journaux dans le processus de support des applications passe rapidement d’un luxe à une nécessité.
Ajay Singh est le fondateur et PDG de Zebrium.
DataDecisionMakers
Bienvenue dans la communauté VentureBeat !
DataDecisionMakers est l’endroit où les experts, y compris les techniciens travaillant sur les données, peuvent partager des informations et des innovations liées aux données.
Si vous souhaitez en savoir plus sur les idées de pointe et les informations à jour, les meilleures pratiques et l’avenir des données et de la technologie des données, rejoignez-nous sur DataDecisionMakers.
Vous pourriez même envisager contribution d’un article ton propre!
En savoir plus sur DataDecisionMakers
Rejoignez les principaux dirigeants d’aujourd’hui en ligne lors du Data Summit le 9 mars. S’inscrire ici.
Cet article a été rédigé par Ajay Singh, fondateur et PDG de Zebrium.
Les logiciels tombent parfois en panne, que ce soit dans le cloud, dans une appliance matérielle ou dans une infrastructure telle que la mise en réseau et la sécurité. C’est une réalité inévitable, principalement en raison des mises à jour fréquentes du code, combinées à la complexité et aux innombrables variables d’utilisation. Un problème avec une application devient coûteux pour les entreprises et peut même menacer la perte de clients, l’arrêt de paniers d’achat ou la réputation entachée.
La panne de Facebook de six heures en octobre 2021 a entraîné des pertes de 164 000 $ par minute et réduit la capitalisation boursière de l’entreprise d’environ 40 milliards de dollars. La panne AWS de décembre 2021 fait des ravages à travers les États-Unis Les banques, les sociétés de services et les autres détaillants subissent des pertes considérables lorsque les applications mobiles ou les applications Web échouent. Les pannes et les problèmes sont extrêmement coûteux, il est donc primordial de les résoudre rapidement. La pression est sur, et l’horloge tourne. Malheureusement, trouver la cause profonde de ces pannes est rarement simple et implique souvent un travail de détective considérable.
Dans le cas de la panne de Facebook à l’automne, Détecteur de descente a tweeté qu’il s’agissait de “la plus grande panne que nous ayons jamais vue sur Downdetector avec plus de 10,6 millions de rapports de problèmes du monde entier”. La panne a été enfin identifié comme un problème de changement de configuration. Selon le Institut de disponibilité Rapport d’analyse des pannes 2020, les pannes deviennent de plus en plus graves et coûteuses. Dans le même temps, y remédier devient plus complexe à mesure que les fonctionnalités se développent et que les dépendances à des éléments tels que les microservices logiciels et l’infrastructure cloud prolifèrent.
Pour trouver la cause première, dans un monde idéal, les ingénieurs et les équipes de support auraient des flux continus de journaux, un temps illimité pour les analyser et une compréhension du problème qu’ils sont sur le point de résoudre, mais c’est rarement le cas. Souvent, ils reçoivent un ensemble de fichiers journaux après coup, sans autre contexte ni compréhension du problème. Ensuite, on leur dit de mettre leurs talents de détective à profit. Étant donné que ces fichiers ne sont souvent qu’un instantané d’une période de quelques heures le jour de l’incident, établir une compréhension de ce qui n’a pas fonctionné peut sembler une tâche ardue, un mystère insoluble.
Cependant, grâce à certaines techniques d’apprentissage automatique (ML) très intelligentes, même un ensemble statique de journaux peut rapidement fournir les réponses. Analyse des causes profondes basée sur le ML peut identifier des modèles et des corrélations qui pourraient ne pas être évidents à l’œil nu d’un ingénieur de support et découvrir la cause d’un incident beaucoup plus rapidement que par une analyse manuelle. Non seulement cela augmente la vitesse de résolution, mais cela améliore également la productivité et l’efficacité de l’équipe.
Dans la plupart des cas, le défi de trouver la cause profonde est compliqué par la taille et le nombre de journaux, leur nature désordonnée et non structurée et le manque de clarté sur ce que l’on essaie de trouver. Tous ces facteurs favorisent le ML, non pas parce que la tâche est impossible pour du personnel qualifié, mais parce que le ML fonctionne plus vite que les yeux humains et s’étend au-delà des limites des ressources humaines disponibles.
Lors du dépannage en analysant les journaux, les ingénieurs qualifiés commencent généralement par rechercher dans les journaux des événements de journal rares et inattendus et les corrèlent avec les erreurs. Plus le volume de journaux et de données est important, plus c’est difficile pour les humains et plus la proposition de valeur de en utilisant le ML. La difficulté de la tâche augmente à mesure que l’on passe de l’examen de données volumineuses à la recherche d’anomalies et à l’établissement de corrélations qui fournissent un aperçu significatif. Avec ML, chaque étape peut être accomplie de manière autonome et peut facilement être adaptée à presque n’importe quel volume de données.
Le ML est également mieux adapté pour déterminer la véritable cause première d’un problème. Dans une course contre la montre et avec des contraintes de ressources d’équipe, les ingénieurs et le personnel de support trouveront souvent un remède rapide ou une solution de contournement plutôt que d’identifier et de traiter sa véritable cause première. Cela signifie souvent que le même problème se reproduira et peut également affecter de nombreux autres clients. Cependant, lorsque le ML est utilisé pour découvrir la cause profonde, l’ingénierie peut utiliser son temps limité pour travailler directement sur la source du problème et l’empêcher d’avoir un impact continu.
Bien entendu, le ML n’est pas la panacée pour l’ensemble de la prise en charge des applications. Les professionnels formés doivent encore revoir les Résultats du ML et procéder à la correction appropriée. Bien qu’une grande partie du processus global puisse désormais être automatisée, les membres de l’équipe doivent appliquer leur expertise à la tâche la plus importante : le « dernier kilomètre ». Le résultat de l’utilisation du ML accélère l’ensemble du processus, améliore l’efficacité de l’équipe et laisse aux professionnels plus de temps pour travailler sur des tâches importantes.
Avec la complexité croissante des applications et des environnements et la demande croissante des organisations de support, l’introduction du ML pour les journaux dans le processus de support des applications passe rapidement d’un luxe à une nécessité.
Ajay Singh est le fondateur et PDG de Zebrium.
DataDecisionMakers
Bienvenue dans la communauté VentureBeat !
DataDecisionMakers est l’endroit où les experts, y compris les techniciens travaillant sur les données, peuvent partager des informations et des innovations liées aux données.
Si vous souhaitez en savoir plus sur les idées de pointe et les informations à jour, les meilleures pratiques et l’avenir des données et de la technologie des données, rejoignez-nous sur DataDecisionMakers.
Vous pourriez même envisager contribution d’un article ton propre!
En savoir plus sur DataDecisionMakers
— to venturebeat.com
Jeu de briques
Snake
Pacman
Bubble