FR ▾

Extrait de l’audit · Alerting

Le silence n’a pas de symptôme

L’alerting ne défaille que dans un seul sens. Une alerte bruyante est signalée dans l’heure par la personne qu’elle a réveillée ; une alerte supprimée n’est jamais signalée par personne, parce qu’un problème supprimé n’est pas un problème discret — ce n’est pas un problème du tout. Rien n’est journalisé qu’un humain lise, aucune tuile de dashboard ne passe à l’orange, et la revue d’incident suivante n’a aucun artefact à montrer.

La configuration dérive donc vers le silence comme elle ne dérive jamais vers le bruit. C’est cette asymétrie, et non la négligence, qui produit un nombre à quatre chiffres de fenêtres de maintenance ouvertes.

Comment on arrive à 1,617

Une fenêtre par mise en production, par service, ouverte par un pipeline de déploiement qui n’a aucune étape pour la refermer. Une ouverte à la main pendant un incident à 02:00, avec une portée large parce que personne ne voulait discuter de la portée à 02:00. Une ouverte pour une migration avec une date de fin désormais passée — qui, selon sa configuration, a soit expiré proprement, soit continué à supprimer.

Chacune de ces décisions était correcte sur le moment. Aucune n’a jamais été la décision d’arrêter indéfiniment l’alerting sur ce service, ce que le tenant fait pourtant aujourd’hui.

Le second mécanisme : les dérogations au niveau des entités

Les fenêtres de maintenance sont au moins visibles dans une liste. Les dérogations de détection d’anomalies sont pires : elles vivent sur l’entité, elles sont invisibles depuis les écrans de configuration globale, et elles coupent la détection au lieu de la rediriger ailleurs. Sur le même tenant, il y en avait 106.

Le schéma derrière elles est familier — un hôte ou un service était bruyant pendant un incident, quelqu’un y a désactivé la détection pour passer la nuit, et la réactivation n’a jamais eu lieu parce qu’elle n’a jamais été un ticket.

La forme de la requête

L’inventaire des fenêtres avec leur planification, ce qui suffit à séparer « se termine vendredi » de « ne se termine jamais » :

Que faire, et dans quel ordre

Ne réactivez pas tout. Un tenant silencieux depuis deux ans produira un mur de problèmes dès le premier jour, la plupart réels, et l’équipe aura de nouveau tout coupé avant vendredi — un résultat pire que le point de départ.

Classez plutôt par rayon d’impact : les fenêtres portant sur des services de production qui réveillent quelqu’un, puis les dérogations sur les entités qui portent du trafic client, puis la longue traîne. Réactivez par lots assez petits pour que les problèmes qui en résultent soient triés plutôt que survolés, et corrigez le bruit sous-jacent au fur et à mesure. Sur le tenant audité, ce fut la première remédiation, parce qu’elle change le fait qu’un incident atteigne ou non un humain et qu’elle ne coûte rien à annuler.

Le constat à l’origine de cet article

À retenir

Personne n’a décidé d’arrêter l’alerting. 1,617 personnes ont décidé quelque chose de raisonnable, une fois chacune, et rien dans le produit n’a demandé si le total avait encore du sens.

Autres articles de la série

La question à $91,576 : des hôtes Full-Stack qui ne surveillent rien Extrait de l’audit · FinOps Le bucket Grail que personne n’a choisi : 462 jours de retention Extrait de l’audit · Grail Données personnelles dans les logs : 50 sources, 30.7 millions d’enregistrements par jour Issu de l’audit · Pipelines Ce qui arrive vraiment sur une facture DPS Issu de l’audit · FinOps

Un audit prend une exécution. Les constats prennent une réunion. Ce que vous en faites vous appartient.

Experts Dynatrace certifiés

Envoyer

Obzervability

Confidentialité Conditions d’utilisation Accessibilité