Blog

Après la catastrophe : comment tirer des enseignements des données historiques de gestion des incidents

par Chris Riley 4 mai 2017 | 6 min de lecture

Votre professeur d'histoire du lycée vous a sans doute asséné une variante de la célèbre remarque de George Santayana selon laquelle « Ceux qui ne peuvent se souvenir du passé sont condamnés à le répéter. «

Je suis presque certain que Santayana ne pensait pas à la gestion des incidents lorsqu'il a écrit cela. Mais sa sagesse reste pertinente — et il est judicieux d'en tenir compte si vous êtes responsable de la gestion des incidents.

Certes, l'objectif principal de la gestion des incidents est de identifier et résoudre les problèmes Ces incidents peuvent affecter votre infrastructure, mais vos opérations de gestion des incidents ne doivent pas s'arrêter là. Au lieu de vous contenter de réagir aux tickets clients, vous devez également exploiter les volumes importants de données générées par vos systèmes d'alerte pour détecter et prévenir les problèmes de manière proactive. Vous obtiendrez ainsi des informations précieuses qui vous permettront de rendre votre infrastructure plus résiliente à l'avenir.

Dans cet article, je présenterai quelques stratégies pour travailler avec les données historiques de gestion des incidents, notamment comment collecter et analyser les données, et ce qu'il faut rechercher lors de l'utilisation de ces informations.

Sauvegardez et normalisez vos données

La première étape de l'analyse des données historiques de gestion des incidents consiste à trouver une méthode standardisée pour collecter et traiter ces informations. Cela peut s'avérer complexe, car la quantité et le format des données de journalisation historiques varient considérablement d'un pays à l'autre. différents systèmes de surveillance .

Certains systèmes de surveillance ne fournissent que très peu de données enregistrées que vous pouvez examiner ultérieurement. Par exemple, Pingdom est un excellent outil pour la surveillance en temps réel, mais comme il a été conçu pour vous indiquer ce qui se passe maintenant et non ce qui s'est passé hier, il ne fournit pas beaucoup de données historiques par lui-même.

D'autres systèmes de surveillance conservent les données pendant une durée limitée ou les stockent dans des formats difficiles à exploiter. Par exemple, pour analyser les données Snort, il faut parfois passer au crible des captures de paquets. À moins que Wireshark ne soit votre passe-temps favori du vendredi soir, c'est un travail considérable.

De plus, si vous utilisez plusieurs systèmes de surveillance, les données sont probablement réparties dans différents emplacements. Certains outils enregistrent les journaux dans le répertoire `/var/log` des machines locales, où ils sont difficiles à retrouver et peuvent être supprimés par les scripts de maintenance. D'autres conservent les journaux dans le cloud pendant des durées variables, ce qui n'est pas idéal si vous souhaitez analyser l'ensemble de vos données historiques en une seule fois.

Pour ces raisons, afin de tirer le meilleur parti de vos données de gestion des incidents, vous devez veiller à faire deux choses :

  1. Envoyez les alertes et les journaux à un point de collecte central où ils pourront être stockés aussi longtemps que nécessaire (plutôt que tant que le système de surveillance d'origine ou le stockage local le supporteront).
  2. Convertissez les données collectées à un format standard et extrayez-en des informations et des enseignements exploitables qui pourront être réinvestis dans l'infrastructure (par un processus comme celui-ci). autopsies des incidents ).

Des outils comme Logstash , Splunk et Traçabilité de papier peuvent s'avérer utiles ici. Elles permettent de collecter les données provenant de sources cloisonnées et de les acheminer vers un point de stockage centralisé.

PagerDuty va encore plus loin en vous permettant d'importer des données provenant de ces sources et d'autres encore, et de les convertir en un format plus grand. format standardisé et de centraliser et de corréler les données avec des visualisations qui mettent en évidence des modèles et des tendances, et qui peuvent être utilisées pour identifier la cause profonde et plus encore.

Visualisez et analysez vos données

Sauvegarder ses données ne représente que la moitié du travail. L'autre défi consiste à savoir comment les visualiser et les analyser.

Dans la plupart des cas, la manière la plus simple de consulter vos données est via une interface web. Idéalement, celle-ci proposera une fonction de recherche avancée permettant de trouver des événements spécifiques dans vos journaux, de suivre l'état actuel des incidents, etc. C'est pourquoi la possibilité de filtre et recherche L'utilisation de champs normalisés sur l'ensemble de votre infrastructure est extrêmement utile.

Bien que l'interface web puisse être utile pour identifier des tendances à petite échelle ou retracer l'historique d'un type d'incident spécifique, pour avoir une vue d'ensemble, il vous faut des visualisations. Les tableaux et les listes d'alertes ne vous aident pas à comprendre les tendances à l'échelle du système. Des visualisations basées sur vos données de gestion des incidents, comme celles de PagerDuty, sont nécessaires. comprend dans les rapports , vous aider à interpréter des informations à grande échelle.

Enfin, et surtout si vous êtes adepte de l'analyse de données par programmation, il existe des API qui vous permettent d'exporter vos données de journalisation selon vos besoins. L'API PagerDuty facilite cette opération. collecter et exporter les données de journalisation dans le format dont vous avez besoin (et l'API Events v2 (et normalise automatiquement toutes ces données dans un format commun).

Que rechercher

Une fois votre analyse de données effectuée, que devez-vous rechercher ? Vos besoins précis varieront bien sûr en fonction du type d’infrastructure que vous surveillez, mais voici quelques points généraux à prendre en compte :

  • La fréquence à laquelle les incidents se produisent. Si ce nombre évolue au fil du temps, il est important d'en connaître la raison.
  • Temps intermédiaire pour reconnaître (MTTA) et délai moyen de résolution (MTTR) des incidents En suivant ces chiffres, vous saurez avec quelle efficacité votre équipe gère ses responsabilités en matière de gestion des incidents.
  • Qui, au sein de votre équipe, gère le plus les alertes ? Le savoir vous permettra non seulement de récompenser les membres pour leurs efforts, mais aussi de vous assurer que vos alertes sont correctement distribuées et parviennent aux bonnes personnes. Par exemple, si un administrateur reçoit plus d'alertes que la normale, vous devriez ajuster la distribution pour éviter qu'il ne soit surchargé. ce qui conduit à fatigue d'alerte Et personne ne veut ça.
  • Quels systèmes de surveillance génèrent le plus d'alertes ? En centralisant les alertes de vos différents systèmes de surveillance dans un seul et même journal, comme suggéré précédemment, vous pourrez identifier les systèmes les plus pertinents. Vous pourrez ainsi déterminer si un système est sous-performant ou génère trop d'alertes parasites et ajuster vos seuils d'alerte en conséquence.

En suivant ces conseils, vous éviterez de répéter les mêmes erreurs et de faire face sans cesse aux mêmes types d'incidents. Vous pourrez ainsi identifier les grandes tendances et optimiser l'efficacité globale de votre infrastructure.

Et c'est ainsi que la gestion des incidents peut vraiment porter ses fruits. Rappelez-vous une autre maxime souvent citée : « Mieux vaut prévenir que guérir. « La réponse aux incidents est la solution, mais la mise en place d'une boucle de rétroaction continue avec les données historiques de gestion des incidents est la meilleure pratique permettant la prévention. »