Risolutore Problemi Pipeline Dati
Il Risolutore Problemi Pipeline Dati ti aiuta a diagnosticare e risolvere i guasti nelle pipeline dati in modo sistematico. Invece di cercare nei log e tirare a indovinare, descrivi i sintomi e l'architettura della pipeline e ricevi un'analisi strutturata delle cause con una lista prioritizzata di verifiche, query diagnostiche e correzioni.
Data engineer che fanno il debug di job ETL notturni, analytics engineer che indagano su errori nei modelli dbt, team di piattaforma che risolvono errori in task Airflow o Prefect e analisti che tracciano perché una dashboard mostra dati obsoleti o errati usano questo prompt. Copre l'intero spettro della pipeline: ingestione, trasformazione, caricamento, schedulazione e monitoraggio.
Questo prompt supera una generica richiesta "aiutami a fare il debug della mia pipeline" perché segue una metodologia di risposta agli incidenti: documentazione dei sintomi, generazione di ipotesi classificate per probabilità, passaggi diagnostici mirati per ogni ipotesi e un piano di correzione che affronta sia il fix immediato sia la prevenzione sottostante. Produce anche un template di post-mortem così puoi documentare il guasto per il tuo team, trasformando ogni incidente in conoscenza condivisa.
This prompt is just the starting point
Score it with AI, optimize it with one click, track versions, and build your prompt library.
The Prompt
Aiutami a diagnosticare e risolvere un problema nella pipeline dati usando un approccio strutturato: **Panoramica della Pipeline**: - Nome/scopo della pipeline: [DESCRIVI, es. "ETL notturno che sincronizza i dati da Salesforce al nostro warehouse Snowflake per il reporting"] - Orchestratore: [Airflow / Prefect / dbt Cloud / cron / Dagster / custom / altro] - Sorgente/i: [es. "API Salesforce, database di produzione PostgreSQL"] - Destinazione: [es. "Snowflake, schema analytics_prod"] - Layer di trasformazione: [dbt / SQL custom / script Python / Spark / altro] - Schedulazione: [es. "Esecuzione giornaliera alle 02:00 UTC, completa solitamente in 45 minuti"] **Descrizione del Sintomo**: - Cosa è andato storto: [DESCRIVI IL GUASTO, es. "La pipeline si è completata senza errori, ma la dashboard dei ricavi mostra 0 euro per ieri. I giorni precedenti sono corretti."] - Quando è iniziato: [es. "Notato oggi, 28 marzo. L'ultima esecuzione confermata funzionante era il 26 marzo."] - Messaggi di errore (se presenti): ``` [INCOLLA QUI LOG DI ERRORE, STACK TRACE O OUTPUT DELLO SCHEDULER] ``` - Cosa è cambiato di recente: [DEPLOY, MODIFICHE ALLO SCHEMA, NUOVE SORGENTI DATI, MODIFICHE ALL'INFRASTRUTTURA, es. "Abbiamo rilasciato una nuova versione del connettore Salesforce ieri" o "Niente che io sappia"] - Impatto: [COSA È COINVOLTO, es. "Tutti i report sui ricavi sono errati. Il team Finance non può chiudere il bilancio mensile."] **Risolvi questo problema seguendo questi passaggi:** ### Passo 1: Generazione delle Ipotesi In base ai sintomi, genera 3-5 ipotesi classificate per la causa principale. Per ogni ipotesi: - Enuncia la causa sospettata in una frase - Spiega perché corrisponde ai sintomi - Assegna una probabilità (alta / media / bassa) in base alle informazioni fornite - Elenca quali prove confermerebbero o escluderebbero questa ipotesi ### Passo 2: Piano Diagnostico Per le prime 3 ipotesi, fornisci passaggi diagnostici specifici: - Query esatte da eseguire (SQL, comandi CLI, chiamate API) per verificare o eliminare ogni ipotesi - Cosa cercare nei file di log (pattern specifici, timestamp, codici errore) - Controlli comparativi (es. "contare le righe nella sorgente vs. nella destinazione per l'intervallo di date coinvolto") - Ordina le diagnostiche dalla più rapida/economica alla più lenta, così posso eliminare le ipotesi in modo efficiente ### Passo 3: Conferma della Causa Principale Una volta che condivido i risultati dei passaggi diagnostici, conferma la causa principale e spiega: - La catena esatta di eventi che ha causato il guasto - Perché il monitoraggio esistente non l'ha intercettato (o come è stato intercettato) - Se si tratta di un incidente isolato o di un rischio sistemico ### Passo 4: Piano di Correzione Fornisci due livelli di correzione: - **Correzione immediata**: passaggi per risolvere il guasto attuale e ripristinare dati corretti. Includi procedure di rollback se la correzione comporta rischi. - **Correzione permanente**: modifiche per prevenire questa classe di guasti in futuro. Può includere validazione dello schema, data contract, regole di alerting o modifiche al design della pipeline. ### Passo 5: Template Post-Mortem Genera un breve documento di post-mortem con: - Timeline dell'incidente (usando le informazioni raccolte) - Riepilogo della causa principale (2-3 frasi) - Valutazione dell'impatto (durata, dati coinvolti, consumatori a valle) - Azioni correttive con responsabili (lascia il responsabile vuoto per la compilazione) - Lacune nel monitoraggio da colmare
Usage Tips
- Incolla i messaggi di errore effettivi, non parafrasi: "È fallito con un timeout" è vago. Lo stack trace esatto o il codice errore permettono al risolutore di individuare subito il componente in errore.
- Includi cosa è cambiato di recente, anche se pensi non sia collegato: migrazioni di schema, aggiornamenti di dipendenze, modifiche all'infrastruttura e persino aggiornamenti dei sistemi sorgente a monte sono cause nascoste frequenti. Menziona tutto e lascia che l'analisi determini la rilevanza.
- Esegui le query diagnostiche e condividi i risultati in modo iterativo: questo prompt funziona al meglio come conversazione. Condividi i risultati del Passo 2, e il risolutore restringerà la diagnosi nel Passo 3. Cercare di indovinare la causa senza eseguire le diagnostiche fa perdere tempo.
- Salva il post-mortem nel wiki del team: l'output del Passo 5 è formattato per l'uso diretto. Nel tempo, la tua raccolta di post-mortem diventa una knowledge base consultabile che accelera il debug futuro.
Get more from this prompt
Save it, score it with AI, optimize it, and track every version. Free to start.