Un runbook mensile per un report sui backlink

Perché mensile e non giornaliero

Il nostro grafico si aggiorna circa una volta al mese. Un lavoro giornaliero restituisce gli stessi numeri.

Eseguirlo più spesso non rende un report più aggiornato, lo rende solo più costoso da spiegare. Un lettore che vede 30 punti identici penserà che la pipeline sia rotta.

Scegli un giorno ogni mese deliberatamente, idealmente una settimana dopo che il refresh precedente si è assestato. Scrivi la data nel nome del file, così la pianificazione stessa è documentata.

Scegli il calendario prima e lascia che il report lo segua. Un report che si ricostruisce ogni volta che qualcuno apre il notebook non ha una data chiara, e questo è difficile da difendere in una revisione.

Cosa archiviare oltre ai numeri

Metà del report è metadati, quindi archiviali insieme ai numeri.

Scrivi la data del recupero, il nome dell'azione, i parametri (per, sort, order) e il campo crediti della risposta in un piccolo file sidecar accanto a ogni istantanea. Sei mesi dopo, quando un collega chiede perché ottobre sembra diverso da settembre, quel file risponde in dieci secondi invece che in un pomeriggio.

Aggiungi il commit git dello script e le versioni dei pacchetti da renv. Un report che non può dire quale codice e quale stato dell'indice hanno prodotto un grafico è uno screenshot, non un'analisi, non importa quanto sia ordinato il tibble.

Un layout minimale per targets

Tre targets sono sufficienti quando il piano rimane piccolo.

Un target recupera dall'API e scrive il file datato, uno legge il file e costruisce il tibble, uno rende il documento Quarto. Poiché solo il primo target tocca la rete, puoi rieseguire gli altri offline quanto vuoi e il grafico non cambia accidentalmente.

Blocca le versioni dei pacchetti con renv, registra le informazioni sulla sessione nel footer del report e mantieni la tabella delle soglie dalla pagina di valutazione bulk nel repository accanto al codice. Per il lato economico, la pagina del budget ti dice quanto dovrebbe costare un mese.

Quando qualcosa fallisce, leggi prima il codice. HTTP 401 significa che la chiave è errata o mancante. HTTP 402 significa che i crediti sono esauriti. Qualsiasi altro codice vale la pena registrarlo completamente. Il teardown copre quelle fasi, e l'esempio di join è un buon primo lavoro da programmare.

Imparare che un'esecuzione è andata male prima che lo faccia un collega

Un report sui backlink riproducibile che fallisce silenziosamente inganna più di uno che non è mai stato eseguito. La vera domanda non è se il lavoro può fallire, ma quanto velocemente qualcuno ne viene a conoscenza.

Fai fallire il lavoro rumorosamente

Un lavoro programmato esce con un codice di stato non zero quando una chiamata restituisce HTTP 401 o 402, e il scheduler contrassegna l'esecuzione come fallita. Questo è l'allarme più economico che hai, e non richiede servizi aggiuntivi.

I recuperi parziali sono il caso pericoloso. Se lo script scrive il suo file dopo venti dei trenta chunk, il file esiste e sembra a posto. Scrivi in un nome temporaneo e rinominalo solo in caso di successo.

Invia un messaggio per ogni fallimento

Scegli un canale per i fallimenti, come un'email al proprietario del report o un messaggio nella chat del team. Due canali significano due posti da controllare, e una maggiore probabilità che nessuno controlli nessuno dei due.

Il messaggio dovrebbe indicare il target che è fallito, il codice di stato e l'ora. Tutto il resto appartiene al log.

Verifica che l'output sia plausibile

Un'esecuzione può avere successo ed essere comunque sbagliata. Confronta il conteggio delle righe con quello del mese scorso e segnala un calo oltre una soglia scelta in anticipo.

Il controllo può essere semplice come un intervallo previsto. L'obiettivo è notare un'istantanea a metà prima che un grafico raggiunga un cliente.

Nomina un proprietario per il report

Nomina un proprietario per il report. Un'allarme senza proprietario è letto da tutti e non seguito da nessuno.

Il proprietario non deve necessariamente correggere il lavoro. Il proprietario deve decidere se un report in ritardo è accettabile e dirlo nel report stesso.

Scrivi il nome del proprietario nell'intestazione del runbook e aggiornalo quando il proprietario cambia. Un runbook con un ex proprietario è un pericolo silenzioso.

Scegliere il giorno ed eseguire il primo lavoro manualmente

Tempistica e la prima esecuzione decidono se la pianificazione regge. Entrambi sono facili da sbagliare nel primo mese, e entrambi sono economici da fare bene.

Due decisioni, scritte una volta, risparmiano la maggior parte delle discussioni in seguito. La prima è il giorno. La seconda è dove il timer gira. Entrambi appartengono al runbook, non alla testa di nessuno.

Scegli un giorno e scrivilo

Un giorno fisso del mese, come il primo giorno lavorativo dopo che il refresh si è assestato, è più facile da spiegare di un'indovinamento all'inizio del mese.

Metti il giorno nel file di pianificazione stesso, così la tempistica è parte del codice e non un ricordo nel calendario di qualcuno.

Esegui il primo lavoro manualmente

La prima esecuzione programmata dovrebbe essere manuale. Esegui lo script tu stesso, leggi il log, confronta il file con quello precedente, e solo poi consegna il timer.

La prima esecuzione testa anche l'archivio segreto. Una chiave che funziona sulla tua macchina ma manca in CI è una ragione comune per il primo fallimento programmato.

Mantieni onesto il sidecar

Il file sidecar registra cosa ha fatto l'esecuzione. Se una persona lo scrive a mano, si discosta dall'esecuzione. Fai scrivere allo script, e lascia che le persone lo leggano solo.

Un sidecar che lo script non ha mai toccato è una nota, non un record, e il report dovrebbe citare il record.

Confronta il sidecar con il file una volta al mese. Se i numeri nei due discordano, l'esecuzione è fallita in un modo che lo script non ha notato.

Dove vive il timer

Un runner ospitato e una voce cron locale falliscono in modi diversi. Un runner ospitato può essere messo in pausa dalle sue stesse impostazioni, e una voce cron locale si ferma quando la macchina è in sospensione. Controlla quale hai scelto, e testa il timer una volta con una pianificazione breve prima di quella reale.

Qualunque cosa tu scelga, scrivi il timer nel repository accanto allo script, così la prossima persona sa dove vive il lavoro.