La surveillance est essentielle à la proactivité durable de votre ITOps Ces dernières années, nous avons assisté à une explosion du nombre et des types d'outils classés comme outils de « surveillance ». Si ce paysage d'outils en constante augmentation a considérablement accru la visibilité des ITOps, l'intégration de cette vaste gamme d'outils a parfois pour effet secondaire de créer encore plus de bruit. Le paradoxe « visibilité et bruit » a transformé le paysage de la surveillance en un cercle vicieux pour de nombreux services informatiques, tandis que d'autres ont rationalisé leur proactivité pour résoudre les problèmes. Examinons le paysage de la surveillance et créons un environnement intégré qui réussit.

La surveillance se décompose en types d’outils :

• Surveillance des performances des applications (APM) : En regardant uniquement la couche applicative
• Analyse des journaux : Généralement dirigé vers la couche d’infrastructure.
• Surveillance des exceptions : Configuration d'alertes pour chaque bloc d'exception au niveau du code.
• Surveillance des artefacts : S'assurer que tous les artefacts et composants de l'application sont exempts de vulnérabilités et à jour.
• La gestion des incidents: Intégrez n'importe quelle partie de la pile et assurez-vous de savoir immédiatement quand quelque chose ne va pas.

Certains outils englobent plusieurs types de surveillance et certaines organisations n'en requièrent qu'un seul ou l'autre. Mais toutes les organisations ont besoin d'une gestion des incidents car, quelle que soit la surveillance effectuée en amont, si le système surveille sans effectuer de surveillance, il perd sa valeur.

Vous trouverez ci-dessous quelques indicateurs clés de performance typiques qui sont enregistrés et surveillés pour les alertes :

• Performance (CPU, Disque, Mémoire, Réseau, Utilisation)
  • Il s'agit d'un élément essentiel de toute pile de surveillance et comprend la surveillance des performances et de l'utilisation du matériel critique tel que le processeur, le disque, la mémoire et le réseau. Les signaux d'alarme à surveiller sont une utilisation élevée, des erreurs d'E/S ou des pannes prédictives.
• Temps de disponibilité (Disponibilité des ressources, disponibilité du serveur, disponibilité du réseau)
  • Ces tickets sont généralement classés comme des tickets de réponse hautement prioritaires, car cela signifie que l'un de vos serveurs, périphériques réseau ou ressources clés ne fonctionne plus. Cela peut être surveillé simplement par l'accès au réseau ou la disponibilité du service.
• Événements d'application/système (Erreurs, requêtes, avertissements, échecs)
  • Cette catégorie vous permet de suivre les erreurs et les événements sur les applications et systèmes clés. Par exemple, vous pouvez surveiller les erreurs et les requêtes HTTP sur un serveur Web ou surveiller les services qui alimentent un composant d'application particulier.
• Sécurité (IDS/IPS, gestion des informations d'identification, détection des incidents)
  • Tout ce qui touche à la sécurité et à la visibilité. Cela inclut la surveillance de votre pare-feu, de votre terminal, de vos services de chiffrement et d'autres systèmes de sécurité. La surveillance des intrusions détectées et des tentatives de connexion infructueuses sont deux des nombreuses alertes de sécurité que vous pouvez établir.
• Enregistrement (Services Syslog, SNMP, agrégation de journaux, enrichissement et notification)
  • Services d'agrégation et d'enrichissement des journaux. Les exemples incluent l'envoi de notifications réseau et de sécurité à un serveur Syslog ou à un outil tiers afin d'enrichir vos données de journal et de générer des alertes basées sur les données.

Le bruit est l'ennemi

Dans tout service informatique, que vous travailliez en interne ou en tant que consultant, le bruit est l'ennemi. C'est unanime. Le temps est notre bien le plus précieux et le moment où notre journée est consacrée à la lutte contre les incendies est le moment où nous devons repenser à la façon dont la rationalisation du processus de surveillance et d'alerte aurait pu nous sauver. La première étape de cet objectif consiste à garantir un niveau fondamental de votre stratégie de surveillance. Cela comprend la mise en place d'un suivi des incidents pour les services de pile critiques à SLA élevés tels que le trafic réseau, la disponibilité du serveur, la disponibilité des applications, les services de sécurité et l'utilisation des ressources. Une fois ce niveau fondamental en place, les équipes ITOps obtiennent la visibilité et les informations essentielles pour éviter les violations des SLA des produits.

La plupart des outils et systèmes disponibles proposent des modèles prédéfinis pour aider à remettre ces services critiques en production. Cependant, la configuration de seuils et de priorités d'incidents appropriés est primordiale pour réduire le bruit et améliorer la visibilité. Il faudra une certaine finesse pour configurer les seuils de CPU, de disque, de mémoire et de réseau en fonction de vos besoins ITOps. L'essentiel est de définir ces seuils pour donner à votre équipe suffisamment d'avance pour réagir aux problèmes et identifier les incidents nécessitant une réponse prioritaire.

Une fois le cadre de surveillance de base configuré, il est temps de passer à une surveillance de service plus intelligente, comme l'analyse des journaux, les informations sur les applications, l'intelligence opérationnelle et la détection des intrusions. L'utilisation d'outils tels que Splunk peut fournir une quantité considérable d'informations multiplateformes aux équipes ITOps et SecOps. Plus précisément, des outils tels que Rollbar et Errorception peuvent aider les équipes de développement à obtenir une visibilité sur les informations sur les applications en générant des incidents pour les erreurs de code. En outre, les outils de Rapid7, AlienVault et Threat Stack peuvent aider à éclairer la surveillance de la sécurité et la veille sur les menaces. Quel que soit l'ensemble d'outils qui convient le mieux à votre environnement, les objectifs restent les mêmes : réduire le bruit des alertes et accélérer le temps moyen de résolution (MTTR).

Il est temps de passer à l’action

Une fois que nous avons mis en place une base de surveillance solide, nous pouvons ensuite orienter notre attention vers l'action. Comment traduire les alertes en action, en particulier si nous exploitons plusieurs outils pour obtenir un meilleur profil de surveillance ? C'est à ce stade que l'agrégation des alertes provenant de plusieurs outils de surveillance en un seul Plateforme de gestion des incidents Les plateformes de gestion des incidents comme PagerDuty peuvent non seulement connecter des services informatiques critiques, mais elles prennent également en compte les données d’événements générées et recrutent et avertissent immédiatement les équipes appropriées. Les plateformes de gestion des incidents transforment les problèmes créés par vos systèmes de surveillance en alertes et incidents. De plus, les politiques d’escalade automatisées permettent à votre équipe d’exécuter rapidement et efficacement la résolution de votre incident en garantissant qu’un intervenant prend des mesures sur le problème. C’est le point pivot dans lequel vous maximisez le retour sur investissement de vos outils de surveillance.

Étapes à suivre pour démanteler la surveillance

• Fondation: Détection d'incident de base et avancée
• Enrichissement: Déduplication, seuillage et priorisation
• Possibilité d'action : Notification et alerte
• Succès: Agilité opérationnelle accrue et MTTR réduit

Grâce à un cadre de surveillance solide, les ITOps disposent des outils et de la visibilité nécessaires pour être proactifs dans leurs opérations et plus rapides dans leur réponse aux incidents. Globalement, l'objectif n'est pas de submerger les ITOps d'alertes, mais de générer et de détecter les alertes critiques qui nécessitent une action immédiate.

Le bruit coûte de l'argent — en termes de coûts de personnel, de perte de productivité, de temps d'arrêt et même de perte de revenus. En vous assurant de disposer du cadre de surveillance approprié et d'une plate-forme de gestion des incidents qui centralise, classe et enrichit les événements vous pouvez éviter le paradoxe de la « visibilité et du bruit ».