Pour les administrateurs de base de données chargés de répondre aux alertes SQL Server à toute heure du jour et de la nuit, le sentiment d'être surchargé est probablement exacerbé par le barrage constant de notifications indiquant que quelque chose nécessite votre attention. À DROITE. MAINTENANT.
La surveillance de SQL Server est cruciale pour maintenir une haute disponibilité et suivre les problèmes de performances de votre système, et les alertes sont de loin le moyen le plus efficace de découvrir qu'il y a un problème. Mais il est possible d'avoir trop d'une bonne chose.
Comme le dit le proverbe, "Quand tout est prioritaire, rien n'est prioritaire". La fatigue d'alerte est réelle et peut vous amener à ignorer ou à ignorer les événements qui affectent négativement vos utilisateurs.
Lorsque vous configurez votre surveillance des performances de SQL Server, il est important de configurer les alarmes avec attention et de manière à contrôler quand, pourquoi et à quelle fréquence vous recevez des notifications. Voici quatre façons de gérer les alertes qui vous aideront à réduire la surcharge d'alertes et à sauver ce qui reste de votre santé mentale.
1. Désactivez les alarmes dont vous n'avez pas besoin
Pour beaucoup de DBA, c'est plus facile à dire qu'à faire. Il y a un petit élément de terreur à l'idée de choisir les alertes à ne pas recevoir. Heureusement, il existe certaines bonnes pratiques que vous pouvez mettre en œuvre et qui peuvent rendre votre FOMO un peu moins pénible.
L'une des choses les plus simples que vous puissiez faire est de consulter les journaux d'alertes et de désactiver les alertes qui sont des fausses alarmes chroniques ou des faux positifs. Il y a de fortes chances que vous ne manquiez pas un vrai problème, et votre cerveau appréciera de ne pas réagir aux notifications inutiles.
Une autre stratégie vient des ingénieurs de fiabilité du site (SRE) de Google. Les SRE sont responsables de la disponibilité, de la latence, des performances, de l'efficacité, de la gestion des modifications, de la surveillance, de l'intervention d'urgence et de la planification des capacités.
Les équipes SRE ont mis en place un système d'alerte/ticket/journal pour minimiser la surcharge d'alertes en attribuant une réponse à un événement en fonction de la rapidité avec laquelle une intervention humaine est requise. Les trois réponses possibles incluent :
- Alerte :une alerte n'est envoyée que si une personne doit agir immédiatement.
- Ticket :si l'événement nécessite une action de la part d'une personne, mais qu'il peut attendre les heures normales d'ouverture, un ticket est soumis et passe par les voies normales.
- Journal :si aucune action n'est requise, l'événement est consigné à des fins de diagnostic.
2. Utilisez les alarmes intelligentes pour accéder rapidement à la cause première d'une alerte
Lorsque votre téléphone explose avec des notifications à 3 heures du matin, vous ne voulez pas passer une heure à fouiller pour résoudre le problème.
Les alarmes intelligentes vous indiquent non seulement que vous avez un problème, mais suggèrent également des moyens de le résoudre et vous aident à identifier la cause première. Les alarmes intelligentes fournissent également des données historiques sur l'événement afin que vous sachiez ce qui s'est passé immédiatement avant et après le déclenchement de l'alerte.
3. Hiérarchisez vos alertes pour identifier les problèmes les plus urgents
Toutes les alertes ne sont pas créées égales, il est donc important de configurer votre outil de surveillance des performances SQL Server afin qu'il n'envoie des alertes que pour les problèmes les plus importants. En hiérarchisant les alertes en fonction du niveau de gravité, de l'impact sur l'entreprise ou les clients et si une action immédiate est requise, vous éliminez une partie du bruit généré par les alertes qui ne sont pas critiques.
Concentrez-vous sur la configuration d'alertes pour les problèmes susceptibles d'entraîner la mise hors ligne de vos serveurs, de corrompre gravement les données ou d'entraîner une perte de données importante (par exemple, gravité 17 ou supérieure et messages d'erreur 823, 824 et 825).
4. Gérer les alarmes en appliquant des seuils et des règles spécifiques
La définition de seuils et de règles est un énorme gain de santé mentale, car cela vous aidera à éviter d'être bombardé par plusieurs alertes dans un court laps de temps.
Lorsque vous définissez des seuils de performances, SQL Server s'abstient de vous avertir jusqu'à ce qu'une valeur pour une métrique spécifiée atteigne un niveau préoccupant, par exemple, l'espace disque libre ou les niveaux de mémoire physique libre sont dangereusement bas. Cela permet aux administrateurs de base de données de travailler sur d'autres tâches sans surveiller en permanence les métriques.
La définition de règles pour les alertes vous permet de personnaliser les actions, telles que la fréquence à laquelle vous souhaitez être averti. Par exemple, vous pouvez configurer SQL Server pour envoyer une notification uniquement lorsqu'une alerte spécifiée a été déclenchée quatre fois ou si l'alerte contient un certain objet de base de données ou nom d'utilisateur.
Alors que les DBA commencent à naviguer dans un environnement commercial nouveau et très différent après le COVID-19, les niveaux de stress vont certainement augmenter. Maintenir une haute disponibilité et garantir que vos systèmes SQL Server sont sécurisés et fonctionnent de manière optimale resteront une grande priorité. Mais le moment est venu de faire appel aux capacités de surveillance de SQL Server pour prendre le contrôle de vos configurations d'alerte et vous débarrasser du bruit inutile.
