Un guide mensuel pour un rapport de backlinks reproductible

Pourquoi mensuel et non quotidien

Notre graphique s'actualise environ une fois par mois. Un travail quotidien renvoie les mêmes chiffres.

Le lancer plus souvent ne rend pas un rapport plus actuel, cela le rend seulement plus coûteux à expliquer. Un lecteur qui voit 30 points identiques supposera que la pipeline est cassée.

Choisissez un jour par mois délibérément, idéalement une semaine après que la précédente actualisation se soit stabilisée. Écrivez la date dans le nom du fichier, afin que la planification elle-même soit documentée.

Choisissez le calendrier en premier et laissez le rapport le suivre. Un rapport qui se reconstruit chaque fois que quelqu'un ouvre le notebook n'a pas de date claire du tout, et c'est difficile à défendre lors d'une revue.

Que stocker outre les chiffres

La moitié du rapport est des métadonnées, donc stockez-les aux côtés des chiffres.

Écrivez la date de récupération, le nom de l'action, les paramètres (per, sort, order) et le champ crédits de la réponse dans un petit fichier annexe à côté de chaque instantané. Six mois plus tard, lorsqu'un collègue demande pourquoi octobre ressemble différemment de septembre, ce fichier répond en dix secondes au lieu d'un après-midi.

Ajoutez le commit git du script et les versions des packages depuis renv. Un rapport qui ne peut pas dire quel code et quel état de l'index ont produit un graphique est une capture d'écran, pas une analyse, aussi soigné que soit le tibble.

Une structure minimale de targets

Trois cibles suffisent lorsque le plan reste petit.

Une cible récupère depuis l'API et écrit le fichier daté, une lit le fichier et construit le tibble, une génère le document Quarto. Comme seule la première cible touche au réseau, vous pouvez relancer les autres hors ligne autant que vous le souhaitez et le graphique ne change pas par accident.

Épinglez les versions des packages avec renv, enregistrez les informations de session dans le pied de page du rapport, et gardez le tableau de seuils issu de la page de notation par lots dans le dépôt à côté du code. Pour le côté financier, la page des tarifs vous indique ce qu'un mois devrait coûter.

Quand quelque chose échoue, lisez d'abord le code. HTTP 401 signifie que la clé est incorrecte ou manquante. HTTP 402 signifie que les crédits sont épuisés. Tout le reste mérite d'être journalisé en entier. Le démontage couvre ces étapes, et l'exemple de jointure est un bon premier travail à planifier.

Apprendre qu'un run a échoué avant qu'un collègue ne le fasse

Un rapport de backlinks reproductible qui échoue silencieusement induit plus en erreur qu'un rapport qui n'a jamais été exécuté. La vraie question n'est pas si le travail peut échouer, mais à quelle vitesse quelqu'en est informé.

Faire échouer le travail bruyamment

Un travail planifié se termine avec un statut non nul lorsqu'un appel retourne HTTP 401 ou 402, et le planificateur marque le run comme échoué. C'est l'alerte la moins chère que vous ayez, et elle ne nécessite aucun service supplémentaire.

Les pulls partiels sont le cas dangereux. Si le script écrit son fichier après vingt des trente chunks, le fichier existe et semble correct. Écrivez dans un nom temporaire et renommez-le uniquement en cas de succès.

Envoyer un message par échec

Choisissez un seul canal pour les échecs, comme un email au propriétaire du rapport ou un message dans le chat d'équipe. Deux canaux signifient deux endroits où chercher, et une plus grande chance que personne ne regarde aucun des deux.

Le message doit nommer la cible qui a échoué, le code de statut et l'heure. Tout le reste appartient au journal.

Vérifier que la sortie est plausible

Un run peut réussir et être faux. Comparez le nombre de lignes avec celui du mois dernier, et signalez une chute au-delà d'un seuil que vous avez choisi à l'avance.

La vérification peut être aussi simple qu'une plage attendue. L'objectif est de remarquer un instantané à moitié vide avant qu'un graphique n'atteigne un client.

Nommer un seul propriétaire pour le rapport

Nommez un seul propriétaire pour le rapport. Une alerte sans propriétaire est lue par tout le monde et n'est suivie d'aucune action par personne.

Le propriétaire n'a pas nécessairement à réparer le travail. Le propriétaire doit décider si un rapport tardif est acceptable, et le dire dans le rapport lui-même.

Écrivez le nom du propriétaire dans l'en-tête du guide, et mettez-le à jour lorsque le propriétaire change. Un guide avec un ancien propriétaire est un danger silencieux.

Choisir le jour et exécuter le premier travail à la main

Le timing et le premier run décident si la planification tient. Les deux sont faciles à mal faire le premier mois, et les deux sont peu coûteux à bien faire.

Deux décisions, écrites une fois, économisent le plus d'arguments plus tard. La première est le jour. La seconde est où la minuterie s'exécute. Les deux appartiennent au guide, pas dans la tête de quelqu'un.

Choisissez un jour et notez-le

Un jour fixe du mois, comme le premier jour ouvrable après que l'actualisation se soit stabilisée, est plus facile à expliquer qu'une devinette début de mois.

Mettez le jour dans le fichier de planification lui-même, afin que le timing fasse partie du code et non d'une mémoire dans le calendrier de quelqu'un.

Exécutez le premier travail à la main

Le premier run planifié doit être manuel. Exécutez le script vous-même, lisez le journal, comparez le fichier avec le précédent, et seulement ensuite confiez la minuterie.

Le premier run teste également le magasin de secrets. Une clé qui fonctionne sur votre machine mais manque dans CI est une raison courante du premier échec planifié.

Gardez l'annexe honnête

Le fichier annexe enregistre ce que le run a fait. Si une personne l'écrit à la main, il s'écarte du run. Ayez le script pour l'écrire, et laissez les gens seulement le lire.

Une annexe que le script n'a jamais touchée est une note, pas un enregistrement, et le rapport devrait citer l'enregistrement.

Comparez l'annexe avec le fichier une fois par mois. Si les chiffres des deux diffèrent, le run a échoué d'une manière que le script n'a pas remarquée.

Où vit la minuterie

Un exécuteur hébergé et une entrée cron locale échouent de manières différentes. Un exécuteur hébergé peut être mis en pause par ses propres paramètres, et une entrée cron locale s'arrête lorsque la machine est en veille. Vérifiez lequel vous avez choisi, et testez la minuterie une fois avec une courte planification avant la vraie.

Quel que soit votre choix, notez la minuterie dans le dépôt à côté du script, afin que la prochaine personne sache où vit le travail.