À 10 h 10, le support reçoit une demande de facture. La commande est payée et le document existe dans le logiciel. Le client ne l’a pas reçu. Le tableau de bord indique pourtant que le site fonctionne.
Pour suivre l’incident, cet article utilise un lot fictif de 120 commandes payées entre 9 h et 10 h. Une facture a été créée pour chacune. Le prestataire d’envoi a accepté 118 messages et refusé les deux derniers, à 9 h 58 et 9 h 59, parce que l’accès utilisé par le logiciel a expiré.
Le contrôle de disponibilité ouvre la page d’accueil toutes les minutes. Elle répond à chaque passage. Il n’y a aucune contradiction dans les résultats : ce contrôle n’effectue pas d’envoi de facture.
Les deux documents manquants apparaissent dans une comparaison
À 10 h 10, les informations du lot d’exemple sont les suivantes.
| Étape | Nombre | Ce que cela établit |
|---|---|---|
| Commandes payées | 120 | 120 factures attendues |
| Factures créées | 120 | Aucun document manquant à la création |
| Envois acceptés par le prestataire | 118 | Deux factures sans envoi accepté |
Le suivi porte ici sur les identifiants des factures, pas seulement sur un compteur d’emails. Envoyer deux fois la même facture pourrait ramener un compteur à 120 tout en laissant un client sans document.
Les factures associées aux refus de 9 h 58 et 9 h 59 n’ont aucun envoi accepté. À 10 h 10, elles attendent depuis douze et onze minutes. Dans ce service fictif, l’envoi est attendu en moins de cinq minutes. Elles dépassent donc toutes les deux le délai prévu.
Le contrôle peut produire une alerte avec ces deux identifiants et leur ancienneté. Une baisse globale du trafic n’intervient pas dans ce calcul : les commandes sont payées et les factures attendues sont connues.
Le test passe, puis l’accès expire
Avant la livraison, un test crée une commande et vérifie que sa facture est transmise au système d’envoi. Le service de test accepte le message. Ce résultat couvre le fonctionnement vérifié à ce moment-là.
Dans notre incident, le refus commence plus tard, lorsque l’accès au prestataire expire. Rejouer le test avec un service simulé qui accepte toujours les messages ne détectera pas cette expiration. Le refus réel et les deux factures en attente se trouvent en production.
La surveillance des documents non envoyés couvre ce second cas. Elle ne garantit toujours pas la réception finale : un prestataire peut accepter un message qui sera ensuite rejeté par la messagerie destinataire. « Accepté pour envoi » reste donc le libellé exact du résultat mesuré.
Pour conclure que les factures ont été remises à leur destinataire, il faudrait encore examiner les informations de livraison disponibles. Renommer le voyant « clients servis » n’ajouterait pas cette preuve.
Chez Gridky, il fallait d’abord regrouper les répétitions
Chez Gridky, les exceptions arrivaient dans Slack par centaines chaque jour. Je les dédoublonnais à la main le matin pour repérer celles qui revenaient le plus souvent. Les erreurs fréquentes correspondaient souvent à des corrections rapides.
Un petit exemple chiffré, distinct de ce retour d’expérience, explique ce travail. Si une opération défectueuse est relancée vingt fois, elle peut produire vingt messages pour le même défaut. Corriger ce défaut peut supprimer les vingt messages. Cela ne signifie pas que vingt bugs ont été corrigés.
Le dédoublonnage servait à passer des messages aux problèmes à traiter. Les vingt messages de cet exemple ne sont pas un décompte des corrections de Gridky. Dans notre travail quotidien, le tri manuel a disparu après la stabilisation décrite dans le Drynuary.
Après la réparation, il reste deux factures à reprendre
Dans l’exemple, l’équipe rétablit l’accès au prestataire. Une nouvelle facture est acceptée pour envoi. Cela prouve que les nouveaux messages peuvent passer, mais les deux refus précédents sont toujours enregistrés comme tels.
La reprise vise ces deux identifiants. Si le premier est accepté et le second échoue encore, le lot initial compte 119 factures avec un envoi accepté et une facture en attente. Le suivi permet de constater ce résultat sans le confondre avec la réussite du nouvel envoi de test.
Avant de relancer un document, l’équipe vérifie l’état de ses tentatives précédentes. Un refus explicite et une absence de réponse ne donnent pas la même information. Dans le second cas, le prestataire peut avoir accepté le message sans que le logiciel ait reçu sa confirmation.
Le traitement du lot est terminé lorsque chaque facture a un état expliqué. Pour celles qui restent en échec, le support connaît les documents concernés au lieu de devoir attendre une nouvelle réclamation.
Deux comptes rendus possibles du même incident
« Le site est disponible et un email de test est parti » décrit deux contrôles réussis. Ce compte rendu laisse pourtant ouverte la situation des deux factures refusées.
Un compte rendu qui suit le lot donne une autre information : 120 factures attendues, 120 créées, 118 initialement acceptées pour envoi, puis le résultat de la reprise des deux restantes. La conclusion dépend alors du travail effectivement terminé.
C’est la raison pour laquelle le choix des contrôles change la connaissance de l’incident. Le contrôle de page d’accueil n’était pas en panne. Il répondait à une question qui ne permettait pas de retrouver les documents manquants.
Ce cas d’outillage complète les cinq visages de la dette technique.