Měsíční runbook pro reprodukovatelnou reportaci backlinků

Proč měsíčně a ne denně

Náš graf se obnovuje přibližně jednou měsíčně. Denní úloha vrací stejná čísla.

Častější spuštění neznamená aktuálnější report, pouze činí vysvětlení dražším. Čtenář, který uvidí 30 identických bodů, bude předpokládat, že pipeline nefunguje.

Vyberte jeden den v měsíci záměrně, ideálně týden po tom, co se předchozí obnova ustálí. Zapište datum do názvu souboru, aby byl samotný plán zdokumentován.

Nejprve vyberte kalendář a nechte report, aby mu následoval. Report, který se rebuilduje pokaždé, když někdo otevře notebook, nemá žádné jasné datum, což je na revizi těžké obhájit.

Co ukládat kromě čísel

Polovina reportu je metadata, takže je ukládejte spolu s čísly.

Zapište datum stažení, název akce, parametry (per, sort, order) a pole kreditů odpovědi do malého sidecar souboru vedle každého snímku. Za šest měsíců, když kolega se zeptá, proč říjen vypadá jinak než září, tento soubor odpoví za deset sekund místo celého odpoledne.

Přidejte git commit skriptu a verze balíčků z renv. Report, který neumí říct, který kód a který stav indexu vytvořil graf, je jen screenshot, ne analýza, ať už vypadá tibble sebečistěji.

Minimální rozložení targets

Když je plán malý, stačí tři cíle.

Jeden cíl stahuje z API a zapisuje datovaný soubor, jeden čte soubor a buduje tibble, jeden vykresluje Quarto dokument. Protože pouze první cíl zasahuje síť, můžete ostatní znovu spouštět offline, kolikrát chcete, a graf se náhodou nezmění.

Připněte verze balíčků pomocí renv, zaznamenejte informace o relaci v patičce reportu a udržujte tabli prahových hodnot ze stránky pro hromadné hodnocení v repozitáři vedle kódu. Pro finanční stránku vám stránka s cenami řekne, kolik by měsíc měl stát.

Když něco selže, nejdříve si přečtěte kód. HTTP 401 znamená, že klíč je špatný nebo chybí. HTTP 402 znamená, že došly kredity. Všechno ostatní stojí za to zalogovat v plném rozsahu. Rozbor pokrývá tyto fáze a příklad spojení je dobrá první úloha k naplánování.

Zjistit, že běh selhal, dříve než kolega

Reprodukovatelný report backlinků, který selže tiše, klame více než ten, který nikdy neběžel. Skutečnou otázkou není, zda úloha může selhat, ale jak rychle o tom někdo ví.

Zajistěte, aby úloha selhala hlasitě

Plánovaná úloha skončí s nenulovým stavem, když volání vrátí HTTP 401 nebo 402, a plánovač označí běh jako selhání. To je nejlevnější upozornění, které nepotřebuje žádnou další službu.

Částečné stažení je nebezpečný případ. Pokud skript zapíše soubor po dvaceti z třiceti částí, soubor existuje a vypadá v pořádku. Zapište do dočasného jména a přejmenujte jej pouze při úspěchu.

Poslat jednu zprávu na selhání

Vyberte jeden kanál pro selhání, například e-mail majiteli reportu nebo zprávu v týmovém chatu. Dva kanály znamenají dvě místa k prohledání a vyšší šanci, že se na žádný nikdo nepodívá.

Zpráva by měla uvést cíl, který selhal, kód stavu a čas. Všechno ostatní patří do logu.

Zkontrolujte, zda je výstup věrohodný

Běh může uspět a přesto být špatný. Porovnejte počet řádků s minulým měsícem a označte pokles nad prahovou hodnotou, kterou jste si předem zvolili.

Kontrola může být tak jednoduchá jako očekávaný rozsah. Cílem je všimnout si poloprázdného snímku dříve, než graf dorazí k zákazníkovi.

Jmenujte jednoho majitele reportu

Jmenujte jednoho majitele reportu. Upozornění bez majitele přečte každý a nikdo na něj nereaguje.

Majitel nemusí opravovat úlohu. Majitel musí rozhodnout, zda je pozdní report přijatelný, a říct to v samotném reportu.

Zapište jméno majitele do hlavičky runbooku a aktualizujte jej při změně majitele. Runbook s bývalým majitelem je tichým nebezpečím.

Výběr dne a ruční spuštění první úlohy

Časování a první běh rozhodují o tom, zda se plán drží. Obojí je v prvním měsíci snadné udělat špatně a snadné udělat dobře.

Dvě rozhodnutí zapsaná jednou ušetří nejvíce sporů později. Prvním je den. Druhým je, kde běží časovač. Obojí patří do runbooku, ne do hlavy někoho.

Vyberte jeden den a zapište si ho

Pevný den v měsíci, například první pracovní den po ustálení obnovy, je snazší vysvětlit než hádání začátkem měsíce.

Vložte den do souboru s plánem, aby bylo časování součástí kódu a ne pamětí v kalendáři někoho.

Spuštění první úlohy ručně

První plánovaný běh by měl být manuální. Spusťte skript sami, přečtěte log, porovnejte soubor s předchozím a až poté předáte časovači.

První běh také testuje správce tajných klíčů. Klíč, který funguje na vašem počítači, ale chybí v CI, je běžným důvodem prvního plánovaného selhání.

Udržujte sidecar poctivý

Sidecar soubor zaznamenává, co běh udělal. Pokud ho někdo zapíše ručně, odchýlí se od běhu. Nechte skript, aby ho zapisoval, a lidé ho pouze čtěte.

Sidecar, kterého se skript nedotkl, je poznámka, ne záznam, a report by měl citovat záznam.

Porovnejte sidecar se souborem jednou měsíčně. Pokud se čísla v obou liší, běh selhal způsobem, který si skript nevšiml.

Kde časovač sídlí

Hostovaný runner a místný záznam cronu selhávají odlišně. Hostovaný runner může být pozastaven svými vlastními nastaveními a místný záznam cronu se zastaví, když je počítač v režimu spánku. Zkontrolujte, který jste si vybrali, a otestujte časovač jednou s krátkým plánem před tím skutečným.

Ať už si vyberete cokoliv, zapište časovač do repozitáře vedle skriptu, aby další osoba věděla, kde úloha sídlí.