Gestion des incidents pour les équipes haute vélocité
Que sont les alertes d'incident informatique ?
On parle d'alerte d'incident lorsque les outils de surveillance génèrent des alertes pour informer votre équipe de changements, d'actions à risque élevé ou de défaillances dans l'environnement informatique.
Par exemple, un système conçu pour permettre aux médecins de prescrire des médicaments peut générer une alerte si la dose demandée par le médecin est inhabituellement élevée, ne correspond pas au poids indiqué dans le dossier du patient ou présente un risque d'interaction médicamenteuse avec d'autres médicaments courants.
De même, un système développé pour surveiller un produit technologique peut générer une alerte si un système s'interrompt, que les demandes web prennent plus de temps que d'habitude ou si la latence de la base de données dépasse un seuil défini.
L'objectif des alertes informatiques est d'identifier et de résoudre rapidement les tickets qui impactent la disponibilité, la vitesse, et la fonctionnalité des produits, 24 h/24 et sans surveillance manuelle.
Pourquoi les alertes d'incident informatique sont-elles importantes ?
Alors que l'importance des systèmes disponibles en continu ne cesse de croître, il en va de même pour le coût des temps d'arrêt. Selon les experts, une minute de temps d'arrêt coûte en moyenne entre 5 600 et 9 000 dollars. Chaque minute de défaillance du système étant très coûteuse, l'identification des tickets avant qu'ils ne deviennent incontrôlables a un impact important sur le résultat de l'entreprise (sans parler des plannings et du niveau de stress des équipes informatiques).
Les alertes informatiques constituent la première ligne de défense contre les pannes système ou les changements qui peuvent se transformer en incidents majeurs. En surveillant automatiquement les systèmes et en générant des alertes pour les pannes et les changements risqués, les équipes informatiques peuvent minimiser les temps d'arrêt, et les coûts élevés qui y sont associés.
Bonnes pratiques d'alerte
Les alertes informatiques sont indéniablement une partie importante de la gestion des incidents, mais la vérité est qu'elles ne sont pas une simple correction que vous pouvez oublier aussitôt après l'avoir appliquée. Définir des seuils d'alerte trop bas peut mener à une surcharge de vos boîtes de réception, des équipes d'astreinte pas satisfaites et une fatigue d'alerte. Définir des seuils trop élevés peut mener à manquer des tickets critiques et coûter des millions à l'entreprise.
C'est pourquoi les systèmes d'alerte informatiques les plus efficaces sont configurés en tenant compte de ces bonnes pratiques.
Automatisez votre surveillance
La bonne façon d'identifier rapidement et efficacement les tickets consiste à automatiser la surveillance.
Une base de données répond-elle plus lentement que d'habitude ? Les utilisateurs rencontrent-ils des temps de chargement plus lents que la moyenne sur votre app ? Un système essentiel est-il en panne ? L'un de vos techniciens a-t-il fait une demande classée comme rouge ? Votre système devrait automatiquement surveiller des problèmes de ce type et vous informer de leur survenue.
Définissez des seuils d'alerte intelligents
Chaque alerte nécessite-t-elle une attention immédiate ? Pour la plupart des entreprises, la réponse est non. C'est pourquoi vous devez définir des seuils d'alerte adaptés.
Savoir si quelque chose vaut la peine de réveiller un développeur au beau milieu de la nuit, ou si cela peut attendre le lendemain matin, peut faire la différence entre des développeurs heureux, qui répondent rapidement, et des équipes fatiguées par les alertes qui passent leurs week-ends à rechercher un nouvel emploi.
Dédupliquez vos alertes
Une étude sur la fatigue d'alerte a montré que l'attention aux alertes des cliniciens en milieu hospitalier baissait de 30 % chaque fois qu'une alerte se répétait. Il est probable que les résultats de l'étude seraient les mêmes pour les développeurs. Plus nous voyons une alerte, moins nous y prêtons attention. C'est pourquoi la bonne pratique consiste à dédupliquer vos alertes et à limiter les rappels.
Définissez les niveaux de priorité et de gravité
Évidemment, certaines alertes sont plus importantes que d'autres. Une panne de site web sera probablement prioritaire sur un ralentissement bref d'une fonctionnalité peu utilisée. Un piratage malveillant est probablement plus prioritaire qu'une image qui ne s'affiche pas correctement sur votre app.
Votre système doit non seulement reconnaître la priorité des alertes et leur gravité, mais il doit également communiquer cette priorité de façon claire aux personnes responsables de la résolution des incidents. La bonne pratique ici consiste à utiliser des signaux visuels, audibles et sensoriels pour indiquer rapidement et clairement quelles équipes devraient prendre la main.
Rendez les alertes exploitables
Savoir ce qui ne va pas, c'est bien. Savoir quoi faire, c'est mieux. C'est pourquoi, si vos alertes ne sont pas exploitables, elles devraient l'être.
C'est un domaine dans lequel les équipes DevOps peuvent apprendre de l'industrie aéronautique. Lorsqu'une alerte apparaît sur le tableau de bord d'un pilote pendant un vol, elle est accompagnée d'une checklist exploitable. Intégrer ce type d'informations à votre système d'alerte réduit le temps de diagnostic et aide les développeurs à avancer rapidement dans votre processus.
C'est particulièrement utile lorsqu'un développeur est réveillé au beau milieu de la nuit, à moitié endormi et pas au top de sa forme.
Choisir la bonne technologie d'alerte
Développer un système d'alerte informatique qui suit ces bonnes pratiques implique de gérer les alertes de façon stratégique dès le départ. Cela signifie également choisir la bonne technologie pour le faire. Lors du choix du fournisseur, nous vous recommandons de vous concentrer sur ces aspects :
Canaux d'alerte multiples
Les e-mails sont souvent le canal de choix en matière d'alertes. Mais en réalité, ils ne suffisent pas toujours. Pour les alertes urgentes, vous pourriez vouloir ou avoir besoin de SMS, de notifications Push sur mobile ou même d'appels vocaux. Recherchez un système qui vous permet d'alerter de différentes façons.
Enrichissement des alertes
Les alertes exploitables sont détaillées. Cela signifie qu'un court SMS ne suffit pas toujours. Méfiez-vous des limites de caractères strictes et recherchez une technologie qui vous permet de joindre des graphiques, des journaux, des runbooks et des checklists pour fournir du contexte supplémentaire à une alerte et permettre aux développeurs de savoir ce qu'ils doivent faire ensuite.
Actions d'alerte personnalisées
La plupart des technologies d'alerte vous permettent d'ajouter une note à votre alerte ou de la fermer. Mais parfois il y a des étapes entre les deux. Comme faire remonter l'alerte pour une enquête approfondie, créer un ticket de service ou redémarrer un serveur. Recherchez des solutions technologiques qui vous permettent d'en faire plus que simplement ouvrir et fermer.
Actions automatisées
Pour certaines alertes, les étapes suivantes sont complexes et nécessitent les connaissances d'un développeur chevronné. Pour d'autres, la voie à suivre est claire.
Pour les alertes dont les étapes suivantes sont claires (tests de diagnostic, mesures correctives), vous aurez besoin d'un système qui déclenche ces réponses automatiquement lors d'une alerte répondant à vos critères prédéfinis.
Par exemple, si une base de données ralentit, vous définirez peut-être un système d'alerte pour basculer automatiquement vers une base de données de secours. Si la première étape de la correction du ticket A est de toujours redémarrer un serveur, vous définirez peut-être un système d'alerte pour redémarrer le serveur et surveiller le résultat avant d'envoyer une alerte au beau milieu de la nuit.
Personnalisation et classification des alertes
Au fur et à mesure que les alertes vous parviennent, votre équipe doit pouvoir les organiser, les étiqueter avec des informations supplémentaires et les filtrer.
Suivi du cycle de vie des alertes
Dans votre post-mortem d'incident, vous voudrez savoir à quel moment l'alerte s'est produite et a été détectée, qui l'a reçue et quelles mesures ont été prises. Assurez-vous que la technologie que vous utilisez effectue un suivi automatique de ces informations. Vous pourrez ainsi mieux comprendre ce qui fonctionne ou non, améliorer vos KPI et documenter les incidents antérieurs afin que les équipes d'astreinte puissent en tirer des leçons et s'y référer lors d'incidents futurs.
Politiques d'alerte et de notification
Si la bonne pratique consiste à définir des seuils intelligents pour vos alertes et à s'assurer que les tickets mineurs ne réveillent pas vos développeurs en plein milieu d'un cycle de sommeil paradoxal, vous avez besoin d'une technologie qui vous permet de supprimer, de retarder et de traiter plus rapidement les alertes en fonction de leur contenu et du calendrier.
Surveillance en temps réel des alertes
Comment savez-vous, à tout moment, que vos systèmes d'alerte sont opérationnels ?
Réponse : grâce à la bonne technologie. En effet, le technicien doit disposer de son propre système de surveillance. Opsgenie vous offre cette possibilité grâce à un outil appelé Heartbeats, qui vérifie constamment que les outils de surveillance sont actifs et connectés et que les tâches personnalisées sont terminées à la date prévue. En cas de panne, le système vous envoie instantanément une alerte.
Configuration d'un planning d'astreinte grâce à Opsgenie
Ce tutoriel vous apprendra à configurer un planning d'astreinte, à appliquer des règles de remplacement, à configurer les notifications d'astreinte, etc. Et tout cela, sans quitter Opsgenie.
Lire ce tutorielAdopter une approche optimale des plannings d'astreinte
Un planning d'astreinte efficace est essentiel pour garantir une culture d'astreinte saine. Découvrez les erreurs courantes, les types de plannings de rotation et la marche à suivre.
Lire cet article