Nel caso documentato dall’audit del mio sistema del 31 agosto 2026, un monitor aveva rilevato problemi da segnalare all’operatore. La notifica Slack era fallita; anche il fallback email era fallito. Il registro era aggiornato e il processo era terminato regolarmente, ma il verdetto non era arrivato. I controlli per alcuni dei guasti esistevano gi\u00e0: era la consegna degli avvisi a interrompersi.<\/p>\n\n\n\n
L’exit code rimane utile per sapere come termina un processo. Per stabilire se il suo lavoro \u00e8 disponibile serve una prova anche alla destinazione. Con gli agenti questo confine conta: produrre un report, proporre una modifica e renderla utilizzabile da un altro programma sono passaggi distinti. Il controllo deve sapere a quale di questi pu\u00f2 assegnare il successo.<\/p>\n\n\n\n
Per mostrarlo con poche righe passeremo a un esempio didattico diverso dal caso storico<\/strong>: un job produce un report su file per un programma che lo deve importare. Completeremo questo percorso, poi torneremo agli avvisi. Il principio sar\u00e0 lo stesso; cambier\u00e0 il riscontro da cercare. Provenienza e rettifica della diagnosi storica sono nell’estratto documentale allegato.<\/p>\n\n\n\n Nell’esempio, il job genera un report JSON. L’importatore \u00e8 il programma destinatario: deve aprire quel report e caricarne il contenuto nella propria applicazione. Il controllo verifica una condizione precedente: che nella destinazione usata dall’importatore sia leggibile il file dell’esecuzione attesa.<\/p>\n\n\n\n \u00c8 questo il confine della dimostrazione. Il controllo non esegue l’importatore e non certifica un’importazione riuscita. Il suo verdetto si chiamer\u00e0 La sequenza \u00e8 questa:<\/p>\n\n\n\n L’origine delle aspettative \u00e8 decisiva. Se il controllo prendesse l’identificatore dall’ultimo report disponibile, troverebbe sempre il report giusto per definizione. Anche quello della settimana scorsa.<\/p>\n\n\n\n Crea una cartella locale vuota per la prova e salva al suo interno i programmi seguenti. Useranno soltanto la sottocartella Questo \u00e8 Lo script non trasforma un errore del job in un successo. Esegue comunque il controllo, cos\u00ec pu\u00f2 mostrare anche se il report manca o \u00e8 inutilizzabile; alla fine conserva l’esito negativo di uno qualsiasi dei passaggi.<\/p>\n\n\n\n Questo \u00e8 Infine Dalla cartella della prova esegui:<\/p>\n\n\n Il job scrive Qui i programmi girano con lo stesso utente, nello stesso ambiente locale. In un sistema reale il controllo deve avere accessi, percorso e configurazione equivalenti a quelli dell’importatore. Leggere con l’utente del job un file che l’importatore non pu\u00f2 aprire non dimostra questa disponibilit\u00e0.<\/p>\n\n\n\n Ora proviamo soltanto il controllo. Non rilanciare Il comando \u00e8 sempre questo, dalla stessa cartella:<\/p>\n\n\n Per ogni prova sostituisci il contenuto di L’output della riga mancante include un dettaglio del sistema operativo, che pu\u00f2 variare. Il comportamento atteso rimane il fallimento. Anche un JSON malformato o un payload composto soltanto da spazi vengono rifiutati.<\/p>\n\n\n\n Il vecchio report \u00e8 il test pi\u00f9 istruttivo: il file esiste ed \u00e8 leggibile, ma non soddisfa l’esecuzione attesa. Guardare soltanto la sua presenza perderebbe questo caso. La data di modifica non basta: copiare il report precedente pu\u00f2 aggiornarla senza aggiornare il contenuto.<\/p>\n\n\n\n Il report accettato, invece, dimostra ancora soltanto presenza, identit\u00e0 dichiarata dell’esecuzione e leggibilit\u00e0 minima. Il controllo non autentica il produttore e non giudica il significato del testo. Un JSON ben formato pu\u00f2 raccontare qualunque sciocchezza con sintassi impeccabile. Per contenuti reali occorrono verifiche di dominio; per l’elaborazione successiva occorre il riscontro dell’importatore.<\/p>\n\n\n\n Nell’esercizio lo script di avvio chiama il controllo subito dopo il job. Se il job rimane bloccato, oppure lo script di avvio non parte, quella chiamata non avviene. Il codice non copre queste assenze e non implementa timeout o retry.<\/p>\n\n\n\n Nel sistema schedulato, chi pianifica il lavoro deve stabilire in anticipo la scadenza entro cui si aspetta il report e il verdetto. Un controllo esterno, avviato indipendentemente dal job, verifica a quella scadenza che il verdetto dell’esecuzione sia comparso. Un esito mancante deve restare distinguibile da un controllo eseguito che ha rifiutato il report.<\/p>\n\n\n\n La scelta della scadenza dipende dalla cadenza del lavoro e dalla tolleranza del destinatario. Va configurata fuori dal report: permettere al job di spostare da solo il momento in cui dovrebbe essere controllato allarga il problema invece di risolverlo.<\/p>\n\n\n\n Il costo \u00e8 mantenere anche questo piccolo stato atteso e verificare che il controllo esterno giri davvero. Non serve costruire una gerarchia infinita di guardiani: serve scegliere il punto di osservazione indipendente e sapere quali guasti comuni rimangono.<\/p>\n\n\n\n Completiamo ora il caso che abbiamo escluso dal primo esempio. Prima di avviare il job, lo script di avvio potrebbe accertare, da una fonte indipendente, che non esistono nuovi input. In quel caso la politica del lavoro pu\u00f2 autorizzare l’assenza del report.<\/p>\n\n\n\n Deve comunque rimanere un esito distinto e riconducibile all’esecuzione: per esempio, uno skip motivato dall’assenza di input, registrato dallo script di avvio. Il controllo della scadenza confronter\u00e0 quell’esito con l’autorizzazione gi\u00e0 conservata. Il semplice file mancante continuer\u00e0 a non bastare.<\/p>\n\n\n\n \u00c8 un’estensione del contratto, non un’opzione che il job pu\u00f2 attivare scrivendo una giustificazione. Se lo script di avvio si aspettava il report, una dichiarazione di skip proveniente dal job deve richiedere una verifica, senza diventare automaticamente successo. Gli snippet restano volutamente sul caso in cui il report \u00e8 obbligatorio: accettare assenze richiede anche la prova che le autorizza.<\/p>\n\n\n\n Per gli avvisi cambia l’oggetto della verifica: la presenza di un file locale non prova che l’operatore abbia ricevuto il messaggio. La distinzione \u00e8 coerente con il monitoraggio black-box descritto nel capitolo Monitoring Distributed Systems del libro SRE di Google<\/a>, consultato il 30 ottobre 2026: osservare il comportamento disponibile all’utente.<\/p>\n\n\n\n Seguiamo un singolo evento didattico<\/strong>, Al tentativo successivo arriva il riscontro scelto dal contratto. Soltanto allora cambia lo stato dell’evento. La sequenza che dobbiamo poter ricostruire \u00e8 questa:<\/p>\n\n\n\n Quel livello va scelto con precisione. L’accettazione del provider conferma che il servizio ha accettato il messaggio. Il riscontro della sua presenza nel canale destinatario conferma un passaggio ulteriore. La lettura o presa in carico umana ne conferma un altro ancora. Per un allarme che richiede intervento, fermarsi al primo livello pu\u00f2 essere insufficiente.<\/p>\n\n\n\nUn report, un importatore, un controllo<\/h2>\n\n\n\n
OUTPUT_READABLE_OK<\/code>. Per sapere se l’importatore ha elaborato il report servir\u00e0 invece un riscontro prodotto dall’importatore, legato alla stessa esecuzione.<\/p>\n\n\n\n\n
Il minimo eseguibile<\/h2>\n\n\n\n
destinatario<\/code>: nessun servizio esterno, database o percorso di produzione.<\/p>\n\n\n\navvio.py<\/code>. Per rendere leggibili le prove usa l’identificatore fisso demo-a<\/code>: identifica esclusivamente l’esercizio descritto qui. In un job reale lo script di avvio deve assegnare un identificatore nuovo a ogni esecuzione e conservarlo prima di avviare il job. Riutilizzare quello fisso impedirebbe di distinguere esecuzioni successive.<\/p>\n\n\nfrom<\/span> pathlib import<\/span> Path\nimport<\/span> subprocess\nimport<\/span> sys\n\nrun_id = \"demo-a\"<\/span>\noutput = Path(\"destinatario\/report.json\"<\/span>).resolve()\noutput.parent.mkdir(exist_ok=True)\njob = subprocess.run([sys.executable, \"job.py\"<\/span>, run_id, str(output)])\ncheck = subprocess.run([sys.executable, \"verifica.py\"<\/span>, run_id, str(output)])\nraise SystemExit(0<\/span> if<\/span> job.returncode == 0<\/span> and check.returncode == 0<\/span> else<\/span> 1<\/span>)<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\njob.py<\/code>, un produttore dimostrativo che scrive un testo fisso al posto di calcolare un report:<\/p>\n\n\nimport<\/span> json\nimport<\/span> sys\nfrom<\/span> pathlib import<\/span> Path\n\nrun_id, filename = sys.argv[1<\/span>:]\nreport = {\"run_id\"<\/span>: run_id, \"payload\"<\/span>: \"Report pronto\"<\/span>}\nPath(filename).write_text(json.dumps(report), encoding=\"utf-8\"<\/span>)<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nverifica.py<\/code> controlla il documento obbligatorio. Non contiene una dichiarazione di consegna scritta dal produttore, n\u00e9 una politica di skip da interpretare prima di aver visto il caso normale.<\/p>\n\n\nimport<\/span> json\nimport<\/span> sys\nfrom<\/span> pathlib import<\/span> Path\n\nexpected_run, filename = sys.argv[1<\/span>:]\ntry<\/span>:\n report = json.loads(Path(filename).read_text(encoding=\"utf-8\"<\/span>))\n if<\/span> not isinstance(report, dict):\n raise ValueError(\"Il report non \u00e8 un oggetto JSON\"<\/span>)\n if<\/span> report.get(\"run_id\"<\/span>) != expected_run:\n raise ValueError(\"Il report appartiene a un altro run\"<\/span>)\n payload = report.get(\"payload\"<\/span>)\n if<\/span> not isinstance(payload, str) or not payload.strip():\n raise ValueError(\"Il report \u00e8 vuoto o ha un payload non valido\"<\/span>)\nexcept (OSError, UnicodeError, ValueError) as<\/span> error:\n raise SystemExit(f\"VERIFY_FAILED: {error}\"<\/span>)\n\nprint(f\"OUTPUT_READABLE_OK run_id={expected_run}\"<\/span>)<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\npython3<\/span> avvio<\/span>.py<\/span><\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\ndestinatario\/report.json<\/code>; il controllo lo apre e stampa OUTPUT_READABLE_OK run_id=demo-a<\/code>. Lo script di avvio termina con successo perch\u00e9 entrambi i programmi sono riusciti.<\/p>\n\n\n\nLo stesso report, quando qualcosa manca<\/h2>\n\n\n\n
avvio.py<\/code>: il job ricreerebbe il file e cancellerebbe la condizione che vogliamo osservare. L’identificatore atteso resta demo-a<\/code>, scelto dall’esercizio, indipendentemente dal contenuto del report.<\/p>\n\n\n\npython3 verifica.py demo-a destinatario\/report.json<\/code><\/span><\/pre>\n\n\ndestinatario\/report.json<\/code> con l’input indicato. Nel caso mancante, sposta temporaneamente il file fuori da destinatario<\/code>, lasciando invariato il comando.<\/p>\n\n\n\nInput nella destinazione attesa<\/th> Esito del comando<\/th><\/tr><\/thead> {\"run_id\":\"demo-a\",\"payload\":\"Report pronto\"}<\/code><\/td>OUTPUT_READABLE_OK run_id=demo-a<\/code>, exit 0<\/code><\/td><\/tr>File assente<\/td> VERIFY_FAILED<\/code> con errore di file mancante, exit 1<\/code><\/td><\/tr>{\"run_id\":\"demo-prima\",\"payload\":\"Report pronto\"}<\/code><\/td>VERIFY_FAILED: Il report appartiene a un altro run<\/code>, exit 1<\/code><\/td><\/tr>{\"run_id\":\"demo-a\",\"payload\":\"\"}<\/code><\/td>VERIFY_FAILED: Il report \u00e8 vuoto o ha un payload non valido<\/code>, exit 1<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nChi si accorge che il controllo non \u00e8 partito<\/h2>\n\n\n\n
Se il report pu\u00f2 mancare legittimamente<\/h2>\n\n\n\n
Torniamo all’avviso che non arriva<\/h2>\n\n\n\n
avviso-demo<\/code>. Il monitor rileva una condizione e, prima di tentare l’invio, conserva evento e destinazione con stato pendente. Il processo incaricato dell’invio prova a comunicare col canale, ma il tentativo fallisce. Registra l’errore; l’evento resta pendente. Una politica di retry stabilisce quando riprovare e quando richiedere un intervento.<\/p>\n\n\n\nPassaggio di avviso-demo<\/code><\/th>Che cosa rimane osservabile<\/th><\/tr><\/thead> Evento salvato come pendente<\/td> Esiste un avviso ancora da consegnare<\/td><\/tr> Tentativo fallito<\/td> L’errore del tentativo, senza cancellare l’avviso pendente<\/td><\/tr> Riscontro concordato ottenuto<\/td> La prova che autorizza la chiusura per quel livello di consegna<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n