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

Je suis presque sûr que Santayana ne pensait pas à la gestion des incidents lorsqu'il a écrit cela. Mais sa sagesse s'applique toujours — et elle vaut la peine d'être prise en 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 qui affectent 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 des clients, vous devez également tirer parti des riches volumes de données générés par vos systèmes d'alerte pour détecter et prévenir de manière proactive les problèmes, afin d'obtenir des informations qui vous aideront à rendre votre infrastructure plus résiliente à l'avenir.

Dans cet article, je décrirai certaines stratégies pour travailler avec des données de gestion des incidents historiques, notamment comment collecter et analyser les données, et ce qu'il faut rechercher lorsque l'on travaille avec ces informations.

Sauvegardez et standardisez 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 analyser les informations. Cela peut s'avérer difficile, car la quantité et le format des données historiques des journaux varient considérablement d'un système à l'autre. différents systèmes de surveillance .

Certains systèmes de surveillance ne fournissent pas grand-chose en termes de données enregistrées que vous pouvez examiner après coup. Par exemple, Pingdom est un excellent outil de surveillance en temps réel, mais comme il a été conçu pour vous dire ce qui se passe maintenant, et non ce qui s'est passé hier, il ne fournit pas beaucoup de données historiques à lui seul.

D'autres systèmes de surveillance conservent les données pendant des périodes limitées ou les stockent dans des formats difficiles à exploiter. Par exemple, pour analyser les données Snort, vous devrez peut-être passer au crible les vidages de paquets. À moins que Wireshark ne soit votre activité préférée du vendredi soir, cela représente beaucoup de travail.

De plus, si vous disposez de nombreux systèmes de surveillance, ils stockent probablement les données dans plusieurs emplacements dispersés. Certains outils écrivent des journaux dans /var/log sur des machines locales, où ils sont difficiles à trouver et peuvent être supprimés par des 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 toutes 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 vous assurer de faire deux choses :

1. Envoyez des alertes et des journaux à un point de collecte central où ils peuvent être stockés aussi longtemps que vous en avez besoin (plutôt que aussi longtemps que le système de surveillance d'origine ou le stockage local les prendra en charge).
2. Convertissez les données de votre point de collecte en un format standard et extrayez des informations exploitables et des points à retenir qui peuvent être réinvestis dans l'infrastructure (avec un processus comme autopsies d'incidents ).

Des outils comme Logstash , Splunk et Piste de papier peuvent être utiles ici. Ils aident à collecter des données à partir d'emplacements cloisonnés et à les diriger vers un point de stockage central.

PagerDuty va encore plus loin en vous permettant d'importer des données à partir de ces sources et d'autres, en les convertissant en un fichier format standardisé , et centraliser et corréler les données avec des visualisations qui dessinent des modèles et des tendances, et peuvent être exploitées pour identifier la cause profonde et plus encore.

Visualisez et analysez vos données

La sauvegarde de vos données n'est que la moitié de la bataille. L'autre défi consiste à savoir comment les visualiser et les analyser.

Dans la plupart des cas, la manière la plus simple de visualiser vos données est d'utiliser une interface Web. Idéalement, elle comportera une recherche sophistiquée que vous pourrez utiliser pour trouver des événements spécifiques dans vos journaux, surveiller l'état actuel des incidents, etc. C'est pourquoi il est important de pouvoir filtrer et rechercher sur l'ensemble de votre infrastructure avec des champs normalisés est très utile.

Bien que l'interface Web puisse être utile pour découvrir des tendances à petite échelle ou retracer l'historique d'un type spécifique d'incident, pour avoir une vue d'ensemble, vous avez besoin de photos. Les tableaux et 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 d'incidents, comme le genre PagerDuty inclus dans les rapports , vous aide à interpréter les informations à grande échelle.

Dernier point mais non le moindre, surtout si vous analysez des données par programmation, il existe des API qui vous permettent d'exporter vos données de journal selon vos besoins. L'API PagerDuty facilite collecter et exporter les données du journal dans le format dont vous avez besoin (et l'API des événements v2 normalise également automatiquement toutes ces données dans un format commun).

Ce qu'il faut chercher

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

• La fréquence à laquelle les incidents se produisent. Si ce nombre change au fil du temps, vous voudrez savoir pourquoi.
• Temps moyen de reconnaissance (MTTA) et Délai moyen de résolution (MTTR) des incidents En gardant une trace de ces chiffres, vous saurez dans quelle mesure votre équipe gère efficacement ses responsabilités en matière de gestion des incidents.
• Qui, dans votre équipe, s'occupe le plus des alertes ? En sachant cela, vous pourrez non seulement récompenser les membres pour leur travail acharné, mais aussi déterminer si vos alertes sont correctement distribuées et envoyées aux bonnes personnes. Par exemple, si un administrateur reçoit plus que sa juste part d'alertes, vous devez modifier les choses pour qu'il ne soit pas débordé. qui mène à alerte fatigue , et personne ne veut ça.
• Quels systèmes de surveillance génèrent le plus d'alertes ? Si vous regroupez les alertes de vos différents systèmes de surveillance dans un seul emplacement de journalisation, comme je l'ai suggéré ci-dessus, vous pouvez également identifier les systèmes qui vous fournissent le plus d'informations. Vous pourrez voir si un système est sous-performant ou génère trop de bruit, et ajuster vos seuils d'alerte selon vos besoins.

En suivant ces conseils, vous ne risquez pas de répéter l'histoire en étant confronté à des incidents identiques à répétition. Au contraire, vous serez en mesure d'identifier les grandes tendances, ce qui vous aidera à trouver des moyens d'améliorer l'efficacité globale de votre infrastructure.

Et c'est ainsi que la gestion des incidents peut vraiment s'avérer payante. Souvenez-vous d'une autre maxime souvent citée : « Mieux vaut prévenir que guérir. « La réponse aux incidents est le remède, mais la création d’une boucle de rétroaction continue avec des données historiques de gestion des incidents est la meilleure pratique qui permet la prévention.