Les alertes sont configurées et rien n'arrive : le chemin de livraison que personne ne teste

La supervision a deux moitiés. Le contrôle qui remarque que quelque chose ne va pas, et le chemin qui porte cette nouvelle jusqu'à une personne. Presque toute l'attention va à la première, et presque toutes les pannes silencieuses habitent la seconde.

Le point gênant : un chemin de livraison cassé et un système en bonne santé se ressemblent exactement, vus d'où vous êtes. Les deux produisent une boîte vide.

Pourquoi envoyer du courrier depuis un serveur a cessé d'être simple

Qu'un serveur envoie lui-même son courrier a longtemps été normal et c'est aujourd'hui l'exception. Trois choses se sont produites.

Les destinataires ont cessé de faire confiance aux expéditeurs inconnus. Un message qui arrive sans enregistrements de politique d'expéditeur concordants, sans signature et depuis une adresse sans réputation est traité comme suspect, et la version polie de suspect s'appelle le dossier indésirable.

Les accès résidentiels et de petites entreprises sont bloqués au niveau du port. Beaucoup d'opérateurs n'autorisent pas les connexions sortantes sur le port de livraison directe, précisément parce qu'il a été abusé. Votre serveur essaie, et rien ne vous dit que le message n'est jamais parti.

La réputation appartient à l'adresse, pas à vous. Une adresse résidentielle ou de petit hébergeur porte l'histoire qu'elle a. Vous en héritez.

Rien de cela ne rend le problème difficile. Cela rend la configuration naïve silencieusement inefficace, ce qui est pire que difficile.

Les deux formes qui marchent

Passer par un relais auquel vous faites déjà confiance. Votre serveur remet le message, avec des identifiants, à un fournisseur autorisé à envoyer. C'est la réponse courante et elle fonctionne, avec une réserve à connaître : les fournisseurs exigent souvent que l'adresse d'expéditeur soit une qu'ils hébergent, donc un message qui semble venir d'ailleurs est refusé ou réécrit.

Ne pas envoyer de courrier du tout et utiliser un second canal. Une notification poussée ou un message dans un service que vous lisez déjà. Cela sonne comme un recul et c'est souvent l'option la plus fiable, précisément parce qu'elle ne dépend pas de la délivrabilité du courrier.

Quel que soit votre choix, l'essentiel est la section suivante.

Le test qui prouve vraiment

Presque tout le monde teste les notifications de la même mauvaise manière : on appuie sur le bouton « envoyer un test » assis devant la machine, on ne voit rien échouer, et on considère que c'est réglé.

Ce test prouve que le processus sait remettre un message. Il ne prouve pas qu'il arrive. Un vrai test répond à quatre questions :

Est-il tombé dans la boîte de réception, pas dans les indésirables ? Livraison et visibilité sont deux résultats différents, et un seul vous réveille.

Venait-il de l'adresse que les vraies alertes utiliseront ? Un test envoyé sous une identité ne dit rien d'une tâche nocturne envoyée sous une autre.

Est-il arrivé à l'heure où la vraie alerte se déclenchera ? Certains chemins se comportent autrement à trois heures du matin qu'à trois heures de l'après-midi, souvent parce que les limites de débit d'un relais ou les filtres d'un fournisseur dépendent de l'heure. Cette panne est plus rare et c'est exactement celle qui compte.

A-t-il survécu à la machine sous charge ? Un message mis en file pendant un incident réel est en concurrence avec l'incident.

Des pannes qui ne produisent aucune erreur

La file d'attente. Le message est produit, accepté localement, et reste dans une file qui réessaie indéfiniment. Rien n'est perdu, rien n'est livré, et personne ne regarde la file parce qu'aucune erreur n'y a invité.

L'expéditeur réécrit. Le relais accepte le message, change l'expéditeur pour une adresse que vous ne lisez pas, et le livre parfaitement dans une boîte que personne n'ouvre.

Le filtre que vous avez fait vous-même. Les alertes se ressemblent toutes, à un moment une règle en attrape une, et la règle continue longtemps après que vous ayez oublié l'avoir écrite.

L'adresse qui a cessé d'exister. La personne est partie, l'alias renvoyait vers son compte, et le renvoi tombe désormais dans le vide.

La seule habitude vraiment utile

Faites en sorte que l'absence de message veuille dire quelque chose.

Un système qui ne parle que lorsque quelque chose ne va pas ne se distingue pas d'un système qui a perdu la capacité de parler. Un message quotidien disant que tout va bien transforme le silence lui-même en signal : si rien n'arrive aujourd'hui, le chemin de livraison est la première chose à vérifier, et vous l'apprenez un matin calme plutôt qu'en pleine panne.

C'est pourquoi un résumé quotidien vaut plus qu'il n'en a l'air. Son vrai rôle n'est pas le contenu, c'est de prouver que le canal existe encore.

Ce que fait Atlas

Atlas Watch envoie un message par jour plutôt qu'un flux d'alertes, et ce choix est délibéré pour la raison ci-dessus. Le résumé porte l'état accumulé dans la journée, et son arrivée est en soi la preuve que le chemin est intact.

Les mêmes notifications peuvent aussi atteindre le portail de compte, ce qui compte particulièrement ici : c'est un second canal qui ne dépend pas de la livraison de courrier de l'hôte. Si c'est le courrier qui est cassé, le canal qui n'utilise pas de courrier est celui qui vous prévient encore.

Et la partie honnête, car c'est tout le sujet de cet article : quand un contrôle ne peut pas lire ses données, Watch dit qu'il n'a pas pu les lire au lieu de se taire. Une tâche de sauvegarde absente et une tâche saine se ressemblent de l'extérieur, et la seule chose qui les sépare est un veilleur prêt à signaler son propre aveuglement.