Un vérificateur de liens a bloqué notre publication : un post-mortem hypothétique
Équipe inventée, incident inventé, mécanismes réels. Nous le racontons dans l'ordre où un ingénieur de garde le noterait.
Équipe de recherche Contentin ·
Ceci est un exemple
L'équipe, le produit et les horaires ci-dessous sont fictifs pour montrer comment un dysfonctionnement se déroule. Aucune entreprise, client ou mesure réelle n'est décrit.
L'incident, dans l'ordre
1
09:10, une page de lancement est publiée dans le CMS
Une équipe produit de six personnes gère un site marketing sur un CMS headless et une construction statique. Un réditeur prépare une annonce partenaire qui lie vers un domaine partenaire enregistré la semaine précédente.
2
09:14, le réditeur appuie sur publier
Le webhook de publication appelle une fonction. La fonction exécute un appel de vérificateur de liens vers le domaine partenaire et est écrite pour bloquer la publication en cas de réponse non réussie.
3
09:14, la construction ne démarre jamais
Deux choses échouent en même temps. Le domaine est tout nouveau, donc notre index peut ne pas le connaître encore. Séparément, le solde prépayé sur la clé de l'équipe était vide, donc l'appel payant de suivi a retourné HTTP 402.
4
09:40, l'équipe le découvre
Le réditeur signale une erreur vague. Un ingénieur lit le journal de la fonction, voit le 402 et le résultat vide, et passe vingt minutes à déterminer laquelle des deux causes a provoqué le blocage.
5
10:05, le lancement est effectué manuellement
Quelqu'un contourne le hook avec un déploiement manuel. Le lancement est en retard de 55 minutes, et le contournement ne laisse aucune trace des vérifications qui ont été sautées.
Ce que l'équipe avait vérifié avant le lancement
Très peu, comme il s'est avéré. La liste de test ne contenait que des domaines bien connus, c'est pourquoi l'écart est resté caché jusqu'à ce qu'un lien partenaire arrive. Un test sur un site célèbre prouve que la tuyauterie fonctionne, et ne dit rien sur un domaine que l'index n'a pas encore vu.
De meilleures listes de test contiennent trois types de domaines : un domaine établi, un domaine de niche petit et un domaine enregistré récemment. Exécutez les trois via le hook avant que quiconque ne lui fasse confiance.
Quels domaines la couverture de test couvrait-elle ?
Seulement les plus faciles. Chaque domaine de la liste avait des années d'historique derrière lui, donc chaque réponse est revenue complète, et personne n'a vu ce qu'une réponse vide fait à une publication.
Ajoutez un domaine qui est genuinement nouveau, et lisez son résultat à la main. Si la note indique mauvais là où elle devrait indiquer inconnu, la règle doit être réécrite avant le lancement.
Qu'est-ce que l'exécution de staging a laissé de côté ?
L'exécution de staging a utilisé une clé avec un solde sain, donc le chemin de solde vide ne s'est jamais exécuté. Personne n'avait écrit un test qui dépense le crédit à dessein.
Gardez ce chemin sous test. Forcez un 402 une fois par trimestre, et lisez ce que voit le réditeur ensuite, car un chemin d'échec que personne n'exécute est un chemin que personne ne peut faire confiance.
Pourquoi cela s'est produit
La porte a traité chaque non-réussite comme un verdict. C'était la cause racine. Un problème de solde et un domaine inconnu sont des faits sur les outils et l'index, et aucun ne dit rien sur la page.
Notre graphique est reconstruit environ une fois par mois. Un domaine enregistré après le dernier rafraîchissement peut paraître vide, et un nouveau partenaire est le cas normal pour une page de lancement. Personne n'avait vérifié. L'équipe avait testé le hook uniquement avec des domaines anciens et bien connus comme nytimes.com.
Le deuxième échec était le silence. La fonction a enregistré l'erreur mais n'a envoyé aucune alerte, et le réditeur a vu un message d'échec générique sans aucune indication que le crédit était épuisé.
Le coût n'était jamais le problème. À 2 crédits par appel, tout le mois de vérifications pour ce site inventé a coûté environ $0.60, le même montant que la ligne de 3 000 publications dans le tableau des coûts. La porte était bon marché et leur a tout de même coûté une heure en 2026.
Le 402 mérite sa propre ligne. Un solde prépayé est un état que vous pouvez surveiller, donc une alarme simple à 10 000 crédits, qui est $1, se serait déclenchée plusieurs jours plus tôt.
Points d'action que l'équipe a notés
Les propriétaires sont des rôles, pas des personnes. Tous les points font partie de l'exemple.
Changement
Propriétaire
Pourquoi
Traiter 402 comme un saut plus une alerte vers le canal plateforme
Plateforme
Le crédit est un état de facturation, pas un état de page
Traiter un résultat vide pour un nouveau domaine comme inconnu, pas mauvais
Plateforme
L'index a un retard d'environ un mois
Montrer la raison au réditeur en mots clairs
Outils éditoriaux
20 minutes perdues à lire les journaux
Enregistrer les vérifications sautées sur l'entrée
Plateforme
Les déploiements manuels n'ont laissé aucune trace
Tester le hook avec un domaine enregistré cette semaine
QA
Les anciens domaines cachent l'écart
Une répétition pour la semaine de lancement
Exécutez ces éléments avant le prochain lancement, pas après le prochain échec.
1
Choisir un domaine que personne n'a vérifié
Choisissez un domaine enregistré récemment et appelez l'action de vue gratuite dessus. Confirmez qu'une réponse fine est enregistrée comme inconnue plutôt que comme un blocage.
2
Vider un solde de test
Utilisez une clé de test avec un petit solde et laissez-la s'épuiser à zéro à dessein. Observez l'arrivée du 402, le déclenchement de l'alerte et la poursuite de la publication vers la construction.
3
Lire le message du réditeur à voix haute
Demandez à un collègue qui n'a pas vu le hook de lire le texte d'erreur. S'il ne peut pas dire quoi faire ensuite, réécrivez le message avant le lancement.
4
Écrire le saut dans l'entrée
Confirmez qu'une vérification sautée laisse une note datée sur l'entrée, avec la raison. Un déploiement manuel ne laissera alors jamais un écart que personne ne peut expliquer.
Comment la correction a été écrite
L'équipe a divisé un échec générique en trois, car chaque réponse a un propriétaire différent. Un 401 est un problème de clé, un 402 est un état de facturation, et un résultat vide pour un nouveau domaine est simplement inconnu. Chacun obtient sa propre branche et son propre message. C'est tout le changement.
Personne n'avait besoin de lire une trace de pile pour savoir ce qui s'est produit. Le nom de l'alerte nomme l'état, et le réditeur voit une phrase qui dit quoi faire ensuite.
Pourquoi une alarme de solde est-elle réglée bien au-dessus de zéro ?
Dix mille crédits valent $1 au prix publié, un petit montant qui donne encore beaucoup d'avertissement lorsqu'il arrive tôt. Réglez l'alarme là où un humain la verra, pas dans un journal que personne n'ouvre un vendredi.
Une vérification qui échoue bruyamment une fois par jour bat une silencieuse qui échoue pendant un lancement.
Convenez du nombre avec l'équipe, et écrivez-le au même endroit que la règle pour la rotation des clés, afin que les deux soient examinés ensemble.
Un nouveau domaine doit-il compter comme un échec ?
Non. Un domaine que l'index n'a pas encore vu est un fait sur l'index, pas sur la page. Stockez-le comme inconnu avec la date, et laissez un réditeur décider s'il faut attendre le prochain rafraîchissement.
La même règle s'applique à toute réponse fine. Traitez-la comme des données manquantes, et jamais comme un verdict sur le partenaire.
Enregistrez les réponses inconnues dans leur propre liste, afin qu'un motif d'entre eux soit visible lors de la prochaine révision plutôt que enfoui dans le journal général.
Ce qu'il faut reproduire
Échec ouvert sur les données de lien, échec bruyant sur l'alerte
Une vérification de lien ne devrait jamais être la seule chose entre un réditeur et un lancement. Laissez passer la page, marquez l'entrée, et rendez l'échec impossible à manquer pour la personne qui possède la clé.
Distinguez 401, 402 et un résultat vide dans le code
Gardez une alarme de solde bien au-dessus de zéro (voir le tableau des coûts)
Répétez l'échec en staging avant le jour du lancement
Questions que l'équipe a posées ensuite
La réunion de révision a soulevé la même poignée de questions dans chaque version de cette histoire. Voici comment l'équipe inventée y a répondu, et pourquoi ces réponses différeraient d'une organisation à l'autre.
Aucune de ces réponses n'est universelle, et chacune dépend de ce dont la page est destinée. Le point est d'avoir une réponse sur papier avant la prochaine publication.
La porte aurait-elle dû échouer en mode fermé ?
Pour cette équipe inventée, non. Une vérification de lien est un signal basé sur un index mensuel, et elle ne devrait pas être la seule chose entre un réditeur et un lancement.
Écrivez la politique en une phrase, afin que le prochain ingénieur puisse distinguer un blocage intentionnel d'un bug.
Un solde plus grand aurait-il empêché cela ?
C'aurait retardé le problème plutôt que de corriger la conception. Un solde plus grand peut encore s'épuiser, et une porte qui traite chaque non-réussite comme un verdict bloquera toujours sur le premier domaine inconnu.
La correction est la division en trois réponses, plus une alarme qui se déclenche tôt. Le solde n'est qu'une partie de l'histoire.
Posez la même question à toute porte que vous construisez : quel échec serait silencieux, et qui le remarquerait en premier ?
Une note sur l'hypothèse
Les équipes réelles différeront. La vôtre peut échouer en mode fermé pour de bonnes raisons, telles qu'un site régulé où chaque lien sortant est examiné par une personne. Très bien. Faites-en simplement un choix.
Le manuel d'exécution du webhook liste les mêmes décisions sous forme de liste de contrôle, et la liste des mythes couvre les croyances qui ont conduit cette équipe inventée dans le piège.
