Python per automazione IT: scripting avanzato per task DevOps e monitoring

Per i primi quindici anni della mia carriera, bash è stato il mio linguaggio di automazione. Ogni script di backup, ogni check di salute, ogni task di deployment era uno script bash con set -euo pipefail in cima e una serie di comandi concatenati con pipe. Funzionava - e per i task semplici (riavviare un servizio, controllare lo spazio disco, inviare un alert) funziona ancora perfettamente. Ma quando il task diventa complesso - parsing di log JSON da 500 MB, interazione con API REST con autenticazione OAuth, aggregazione di metriche da più server con confronto temporale, o analisi di dati semi-strutturati con filtri condizionali - bash diventa un incubo di manutenzione dove ogni riga è un awk o un jq con espressioni regolari illeggibili, senza type checking, senza gestione degli errori strutturata, e senza la possibilità di scrivere test.

Dal 2023 uso Python come linguaggio complementare a bash per i task di automazione che superano una certa soglia di complessità. Non ho abbandonato bash - lo uso ancora per i task sotto le 50 righe dove la verbosità di Python sarebbe un over-engineering. Ma per tutto ciò che richiede parsing strutturato, interazione con API, o logica condizionale non banale, Python produce script che sono 3-5 volte più leggibili, manutenibili e testabili. In questo articolo condivido cinque pattern di automazione che uso settimanalmente nel mio lavoro di gestione infrastrutturale per clienti PMI, con codice reale e spiegazioni orientate a sviluppatori che vengono da un background PHP e non hanno familiarità con l'ecosistema Python.

Perché Python e non PHP per l'automazione IT?

La domanda è legittima: se il mio stack primario è PHP, perché non usare PHP anche per gli script di automazione? La risposta è pragmatica, non ideologica. PHP è un linguaggio eccellente per le applicazioni web - ma per gli script di sistema ha tre svantaggi strutturali rispetto a Python.

Il primo è l'ecosistema di librerie per system administration. Python ha psutil per le metriche di sistema (CPU, RAM, disco, processi), paramiko per SSH, boto3 per AWS, hcloud per Hetzner Cloud, requests per le API REST con sessioni e retry automatici, e prometheus_client per esporre e consumare metriche Prometheus. PHP ha equivalenti per alcune di queste (Guzzle per HTTP, Flysystem per filesystem), ma l'ecosistema è orientato al web, non all'automazione di sistema.

Il secondo è il modello di esecuzione. Uno script Python gira come processo standalone con accesso diretto al sistema operativo - può aprire socket, eseguire comandi, leggere file di sistema, e interagire con processi senza nessun overhead di framework o di web server. PHP può fare le stesse cose, ma la maggior parte degli sviluppatori PHP è abituata al modello request-response e scrive script CLI che importano metà del framework Laravel per un task che richiede tre righe di codice.

Il terzo è la leggibilità a distanza di tempo. Uno script bash con 15 pipe concatenate e 8 awk annidati è illeggibile dopo due mesi. Uno script Python con funzioni tipizzate, nomi di variabili espliciti e commenti è comprensibile a chiunque conosca le basi del linguaggio. Per gli script che gestiscono infrastruttura critica - backup, monitoring, deployment - la leggibilità non è un lusso: è la differenza tra uno script che il collega può debuggare alle 3 di notte e uno che nessuno osa toccare. Nel mio profilo professionale trovi il dettaglio dell'approccio multi-stack che adotto - Python per l'automazione, PHP per le applicazioni web, bash per i task semplici, e la scelta dello strumento giusto per ogni problema.

Pattern 1: parsing di log strutturati e aggregazione

Il primo script che uso settimanalmente analizza i log di accesso Nginx per identificare pattern anomali: IP che generano un volume di richieste insolitamente alto (possibile bot o scraping), endpoint che restituiscono errori 5xx con frequenza crescente, e user agent sospetti. Il log Nginx in formato JSON (log_format json) produce righe come {"time": "2025-11-15T14:32:01+01:00", "remote_addr": "203.0.113.42", "request": "GET /api/prodotti", "status": 200, "body_bytes_sent": 1234, "request_time": 0.045} - facili da parsare in Python con json.loads(), impossibili da aggregare in modo affidabile con bash e jq quando il file è da 500 MB e servono aggregazioni su più campi.

Lo script Python che uso carica il log riga per riga (senza caricare tutto in memoria), raggruppa le richieste per IP e per endpoint, calcola il conteggio e la latenza media, e produce un report con gli IP che superano la soglia configurata. Il pattern è riutilizzabile per qualsiasi log in formato JSON - cambi i campi di aggregazione e la soglia, e hai un analizzatore di log per access log, error log, application log o audit log. Per un file di 500 MB con 2 milioni di righe, lo script Python impiega circa 15 secondi - un tempo accettabile per un task che gira una volta al giorno nel cronjob delle 6 del mattino.

Pattern 2: interazione con API del provider cloud

Il secondo script gestisce operazioni ricorrenti sull'infrastruttura Hetzner Cloud: listare i server con il loro consumo attuale, creare snapshot prima degli aggiornamenti, e ridimensionare i server in base al carico. La libreria hcloud-python (SDK ufficiale Hetzner) fornisce un client Python tipizzato che astrae le chiamate API REST con autenticazione, paginazione e gestione degli errori. Uno script che lista tutti i server con CPU, RAM, disco e costo mensile - un task che con curl + jq richiederebbe 15-20 righe di bash con gestione della paginazione e del token di autenticazione - in Python richiede 8 righe con il client ufficiale. La differenza si amplifica quando il task diventa più complesso: creare un snapshot di un server, aspettare che sia completato (polling con backoff), e poi ridimensionare il server - un workflow che in bash sarebbe 80+ righe fragili, in Python è una funzione lineare di 25 righe con gestione degli errori strutturata.

Lo stesso pattern si applica a Digital Ocean (con python-digitalocean), AWS (con boto3), e OVH (con ovh-python). Il vantaggio di avere script Python per la gestione multi-cloud è che posso creare un'interfaccia unificata per operazioni cross-provider: uno script che fa snapshot di tutti i server di un cliente, indipendentemente dal provider (3 su Hetzner, 2 su OVH, 1 su Digital Ocean), con un singolo comando e un report unificato.

Pattern 3: monitoring custom con Prometheus push

Il terzo pattern è la creazione di metriche custom per Prometheus. Le metriche di sistema (CPU, RAM, disco) sono coperte da node_exporter. Le metriche del database sono coperte da mysqld_exporter. Ma le metriche di business - numero di ordini processati nell'ultima ora, dimensione della coda di job in attesa, tasso di errore dell'integrazione ERP, stato dell'ultimo backup - richiedono uno script custom che calcola il valore e lo espone a Prometheus.

Python con la libreria prometheus_client permette di creare metriche custom e esporle via HTTP in poche righe - oppure di usare il Pushgateway per inviare le metriche a Prometheus da script batch che non restano in ascolto. Per i clienti dove ho installato Prometheus e Grafana per il monitoring dei VPS, questi script Python aggiungono le metriche di business alle dashboard infrastrutturali - creando un quadro unificato dove il responsabile IT vede sia "il disco è all'85%" sia "la coda di job ha 500 messaggi in attesa" nella stessa dashboard Grafana.

Pattern 4: health check multi-servizio con alerting

Il quarto script esegue health check su tutti i servizi di un cliente (siti web, API, database, servizi interni) e invia un report aggregato con lo stato di ciascuno. A differenza di Uptime Robot (che controlla solo la raggiungibilità HTTP), il mio health check verifica la funzionalità del servizio: non solo che il server risponda, ma che l'applicazione restituisca un contenuto valido (controlla che la pagina contenga un elemento specifico), che l'API risponda con dati coerenti (controlla che il JSON di risposta abbia i campi attesi), e che il database sia raggiungibile e risponda entro la soglia temporale. Un sito che restituisce HTTP 200 con una pagina di errore generica è "up" per Uptime Robot ma "down" per il mio health check - una distinzione che ha prevenuto due falsi negativi in produzione dove il sito era raggiungibile ma l'applicazione era in uno stato di errore che restituiva la pagina di fallback di Nginx.

Pattern 5: analisi dei costi infrastrutturali multi-provider

L'ultimo script che uso mensilmente aggrega i costi di infrastruttura da più provider (Hetzner, OVH, Digital Ocean, Cloudflare, SendGrid) in un report consolidato per ogni cliente. Ogni provider ha la propria API per i dati di billing - il script Python chiama ciascuna API, normalizza i dati in un formato comune (servizio, periodo, costo, valuta), converte in euro dove necessario, e produce un report CSV e un email con il riepilogo. Per i clienti che gestisco, questo report è il documento che il commercialista usa per la contabilizzazione dei costi IT - e averlo generato automaticamente invece che compilato a mano elimina errori di trascrizione e risparmia 2-3 ore di lavoro amministrativo per cliente al mese.

Da PHP developer a Python: la curva di apprendimento per chi viene dal backend web

La transizione da PHP a Python per uno sviluppatore backend è molto più morbida di quanto ci si aspetti, perché i due linguaggi condividono paradigmi fondamentali: entrambi sono interpretati, entrambi supportano OOP con classi e interfacce, entrambi hanno tipizzazione dinamica (con type hint opzionali in entrambi), e entrambi hanno un package manager maturo (Composer per PHP, pip per Python con pyproject.toml). Le differenze che richiedono adattamento sono poche ma importanti.

La prima differenza è l'indentazione significativa: in Python, l'indentazione non è stilistica - è sintattica. Dove PHP usa { } per delimitare i blocchi, Python usa l'indentazione a 4 spazi. Questo shock iniziale scompare in meno di un giorno di pratica e dopo una settimana diventa naturale - e molti sviluppatori finiscono per apprezzare la pulizia visiva del codice Python senza le parentesi graffe.

La seconda differenza è la gestione dei pacchetti: Python usa virtual environment (venv) per isolare le dipendenze per progetto, analogo al vendor/ di Composer ma gestito come directory con i binari del runtime. Il workflow è python -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt - l'equivalente concettuale di composer install.

La terza differenza, e forse la più impattante per la produttività, è la ricchezza della standard library di Python. Dove PHP richiede un pacchetto Composer per il parsing CSV avanzato, per la gestione delle date con timezone, o per l'interazione con il filesystem, Python ha csv, datetime con zoneinfo, e pathlib nella standard library - disponibili senza installare nulla. Per gli script di automazione che devono girare su server dove non si vuole installare dipendenze esterne, questa differenza è significativa: uno script Python con sola standard library può parsare JSON, gestire file, fare richieste HTTP (con urllib), e interagire con il sistema operativo senza nessun pip install.

Il mio consiglio per lo sviluppatore PHP che vuole iniziare con Python per l'automazione è: parti da un task reale (non da un tutorial generico), usa la documentazione ufficiale di Python (che è eccellente e include esempi pratici per ogni modulo), e scrivi il primo script in parallelo alla versione bash esistente per confrontare i risultati. In una settimana di pratica, la produttività sugli script di automazione è comparabile a quella con bash - e in un mese è superiore perché la struttura del codice Python permette di riusare funzioni e pattern tra script diversi senza il copia-incolla fragile che caratterizza l'automazione bash.

Il filo conduttore di tutti e cinque i pattern è lo stesso: Python non sostituisce bash o PHP - aggiunge un livello di struttura, leggibilità e manutenibilità dove la complessità del task lo richiede. Lo sviluppatore PHP che impara i fondamentali di Python (tipi, funzioni, list comprehension, gestione dei file, requests, json) in una settimana di studio ha a disposizione un secondo strumento che amplia significativamente la sua capacità di automatizzare l'infrastruttura. Se gestisci VPS per clienti PMI e i tuoi script di automazione sono un mix di bash fragile e task manuali, contattami per una sessione di automazione: in una giornata identifichiamo i task ripetitivi, li convertiamo in script Python manutenibili, e li integriamo nel tuo workflow con cronjob e alerting.