Naplánované úlohy, ktoré zlyhávajú nahlas

Nedozorovaná úloha, ktorá zlyhá potichu, je horšia ako žiadna úloha, pretože po sebe zanechá presvedčenie.

Predpoklady

Čokoľvek, čo beží bez dozoru: nočná synchronizácia, týždenný návrh, monitor. Kanál, kam smeruje jeho výstup, a človek, ktorý sa naň občas pozrie.

Postup

1. Ešte pred naplánovaním rozhodnite, čo úloha smie robiť. Nedozorovaný beh nemá operátora, ktorého by sa spýtal, takže jeho právomoci musia byť ustanovené vopred. Základné pravidlo: naplánované behy môžu čítať a môžu zapisovať vratným spôsobom; čokoľvek nevratné vytvára návrh, nie akciu.

2. Zviditeľnite úspech, nielen zlyhanie. Inštinktom je upozorňovať len na chybu, čo je pre nedozorovanú prácu presne opačný postup: úloha, ktorá prestala bežať, tiež neprodukuje žiadne chyby. Každý beh hlási:

sync ok — 412 rows, 3 sources, 0 conflicts, 2026-08-14 03:10

Teraz je absencia hlásenia sama osebe alarmom a je to alarm, ktorý sa spustí práve pri tom zlyhaní, ktoré sa v skutočnosti stáva.

3. Hláste, čo bolo preskúmané, nielen čo bolo nájdené. Beh, ktorý nič nenašiel, musí uviesť, na čo sa pozeral. 0 problems a 0 problems across 3 sources, 412 rows sú odlišné tvrdenia a vyhodnotiť sa dá len to druhé.

4. Nikdy nepohlcujte chyby. Zlyhaný krok sa hlási aj so svojou správou, nezhrnutý do jedného stavu. Nedozorovaná úloha, ktorá zachytí výnimku a pokračuje ďalej, produkuje výstup, ktorý vyzerá identicky ako čistý beh.

5. Zapisujte na trvalé miesto, nielen do notifikácie. Notifikácie sa prehliadnu a vypršia. Súbor s protokolom, ktorý sa hromadí, umožní niekomu spätne zistiť, kedy zlyhanie začalo — čo je zvyčajne prvá otázka, ktorú si niekto položí.

6. Dajte jej podmienku na zastavenie. Úloha, ktorá zlyhala 3-krát po sebe, prestane skúšať a eskaluje problém ďalej. Nekonečné opakovanie voči pokazenej závislosti produkuje šum, ktorý všetkých naučí kanál ignorovať.

7. Odlíšte beh, ktorý nič nenašiel, od behu, ktorý sa nemohol pozrieť. Toto sú dva výsledky, ktoré vyzerajú takmer v každom systéme logovania identicky, a práve v tomto rozdiele spočíva celá hodnota hlásenia. checked 3 sources, 0 findings a could not reach 2 of 3 sources sú opačné stavy, ktoré sa oba zhrnú na nič na hlásenie.

8. Umiestnite plán tam, kde je kód. Úloha definovaná na jednom mieste a naplánovaná na inom sa časom rozíde: kód sa aktualizuje, plán naďalej volá starý vstupný bod a nič nehlási chybu, pretože ten starý stále funguje. Ak držíte definíciu plánu vedľa úlohy, previazanosť sa stane viditeľnou, keď sa zmení čokoľvek z dvojice.

Overenie

Zámerne to pokazte. Odoberte oprávnenie, premenujte vstup a potvrďte, že zlyhanie je viditeľné do jedného cyklu bez toho, aby ho niekto musel hľadať.

Potom preverte ťažší prípad: spravte, aby úloha vôbec nebežala — vypnite plán — a sledujte, koľko času uplynie, kým si to niekto všimne. Ak je odpoveď nikdy, krok 2 nie je implementovaný, nech kód hovorí čokoľvek.

Riešenie problémov

Kanál je plný šumu a nikto ho nečíta. Hlásenia o úspechu sú príliš rozvláčne. Jeden riadok na beh, štruktúrovaný, s podrobnosťami v protokole — nie naopak.

Úloha bežala týždne bez akéhokoľvek úžitku. Hlásila úspech voči kontrole, ktorá nedokázala zachytiť zlyhanie, ku ktorému došlo. Nech vo svojom vlastnom výstupe uvedie svoj rozsah.

Úloha existuje, no nikdy nebola naplánovaná. Bežnejšie, než to znie, a dôvod, prečo schopnosť bez volajúceho nie je schopnosťou. Existenciu plánu si overte pozorovaním behu, nie čítaním konfigurácie.

[Naplánované úlohy, ktoré zlyhávajú nahlas](https://stillvalid.dev/sk/playbooks/scheduled-tasks-that-fail-loudly) — stillvalid, SV-7140 (playbook, verified 2026-08-14)