DevOps: una roadmap operativa per prepararsi ai colloqui e al lavoro quotidiano

Il termine DevOps ricorre ormai in migliaia di annunci di lavoro, ma ciò che viene realmente valutato durante un colloquio tecnico raramente coincide con l'elenco degli strumenti presenti nel curriculum. Le aziende cercano persone che abbiano compreso come funziona un ciclo di sviluppo in modo continuo, come si automatizza un deployment senza perdere il controllo e come si reagisce quando qualcosa va storto in produzione.

Questo articolo propone una roadmap operativa per prepararsi a un ruolo DevOps, costruita attorno ai pilastri che emergono con maggiore frequenza: cultura e processo, integrazione e distribuzione continua, infrastruttura come codice, container e orchestrazione, osservabilità e gestione degli incidenti. Per ogni pilastro vengono indicati i concetti fondamentali, un esempio concreto e le domande che un intervistatore probabilmente porrà, insieme ai riferimenti alle fonti tecniche ufficiali da consultare per approfondire.

L'obiettivo non è memorizzare risposte preconfezionate, ma costruire una base di conoscenza verificabile e dimostrabile con la pratica.

1. Cultura e processo: che cosa significa davvero DevOps

Il primo nodo che un colloquio DevOps deve sciogliere è quasi sempre concettuale. Che cos'è DevOps? Non è uno strumento, non è un ruolo e non è una pipeline. È un insieme di pratiche culturali che accorciano il percorso che va da una modifica al codice alla sua esecuzione affidabile in produzione, rimuovendo i confini tra sviluppo e operations.

Il modello tradizionale, definito "over the wall", prevedeva che lo sviluppo consegnasse il codice e che le operations lo eseguissero senza avere partecipato alla sua costruzione. I rilasci erano grandi, rari, manuali e rischiosi. In caso di errore, le due funzioni si attribuivano reciprocamente la colpa. DevOps inverte questa dinamica: rilasci piccoli e frequenti, pipeline automatizzate e responsabilità condivisa tra chi sviluppa e chi gestisce l'esecuzione.

Il valore di questa impostazione non è tecnologico ma organizzativo: la velocità di consegna aumenta mentre il rischio diminuisce, perché ogni modifica è più piccola, più facilmente verificabile e più semplice da annullare.

Un buon punto di partenza per documentarsi è la documentazione ufficiale di GitLab, che definisce la CI/CD come un metodo di sviluppo in cui si costruiscono, testano, distribuiscono e monitorano le modifiche in modo iterativo, riducendo la probabilità di basare nuovo codice su versioni precedenti difettose.

2. Integrazione e distribuzione continua: la pipeline come catena di montaggio

La differenza tra Continuous Integration, Continuous Delivery e Continuous Deployment viene spesso trascurata, ma è centrale in quasi tutti i colloqui DevOps.

• La Continuous Integration consiste nell'unire frequentemente il codice su un ramo condiviso, eseguendo build e test automatici a ogni merge, così che i problemi di integrazione emergano nel giro di ore, non di settimane.
• La Continuous Delivery garantisce che ogni modifica che supera la pipeline sia sempre pronta per il rilascio, ma che la pubblicazione in produzione rimanga una decisione deliberata, spesso un clic.
• La Continuous Deployment automatizza anche quel clic: ogni modifica che supera i controlli viene distribuita in produzione senza un intervento umano intermedio.

Il passaggio che gli intervistatori cercano è la comprensione del fatto che la delivery mantiene un gate umano, mentre il deployment lo rimuove. Le organizzazioni regolamentate o ad alto rischio scelgono deliberatamente la delivery perché desiderano mantenere un checkpoint.

Una pipeline tipica si compone di checkout del codice, build, esecuzione dei test, produzione di un artefatto, spesso un'immagine container, e distribuzione progressiva verso staging e produzione. Ogni stadio costituisce un gate rispetto al successivo: un test fallito interrompe la pipeline prima che il codice difettoso venga rilasciato.

La documentazione GitLab sulla configurazione di una pipeline offre un'introduzione chiara agli stadi e ai job, con esempi di file YAML.

3. Infrastruttura come codice: descrivere lo stato desiderato

L'Infrastructure as Code significa definire server, reti e servizi in file versionati, anziché configurarli manualmente attraverso una console. La configurazione descrive lo stato desiderato e uno strumento si occupa di far coincidere la realtà con quella descrizione.

I vantaggi sono la riproducibilità, la revisionabilità e l'auditabilità: un ambiente identico può essere ricreato da un file, ogni modifica è visibile nella storia del repository e sparisce la classe di bug "funziona in staging ma in produzione è stato configurato a mano".

Il rischio introdotto dall'IaC è speculare: un errore di configurazione può essere replicato automaticamente su decine o centinaia di risorse. Per questo motivo anche il codice infrastrutturale deve essere sottoposto a revisione, test e controlli di sicurezza.

Terraform, la cui documentazione ufficiale HashiCorp definisce il flusso di lavoro in tre fasi, è lo strumento di riferimento. La prima fase è write: si definiscono le risorse in file leggibili, potenzialmente distribuiti su più provider. La seconda è plan: Terraform produce un piano di esecuzione che descrive le operazioni che verranno compiute, basandosi sull'infrastruttura esistente. La terza è apply: solo dopo l'approvazione le operazioni vengono eseguite nell'ordine corretto, rispettando le dipendenze tra le risorse.

Una domanda che ricorre frequentemente riguarda lo stato: il file di stato conserva la registrazione dell'infrastruttura reale e viene utilizzato per determinare le modifiche necessarie. Su un team è fondamentale utilizzare uno stato remoto con blocco, perché lo stato locale condiviso tra più persone provoca conflitti quando due operatori applicano modifiche in parallelo.

4. Container e orchestrazione: da Docker a Kubernetes

Un container è un processo isolato che condivide il kernel del sistema operativo host. A differenza di una macchina virtuale, che esegue un intero sistema operativo guest, un container è leggero e si avvia in circa un secondo, il che lo rende adatto a impacchettare e scalare servizi. Il compromesso è un isolamento più debole rispetto alla macchina virtuale, perché il kernel è condiviso.

Quando il numero di container supera la scala gestibile a mano, serve un orchestratore. Kubernetes è diventato lo standard de facto: prende una specifica dichiarativa, ad esempio "voglio tre repliche di questo servizio", e lavora continuamente perché il cluster corrisponda a quella specifica. La distinzione che rende chiara la differenza è: Docker impacchetta ed esegue un container, Kubernetes lo esegue in scala su una flotta di macchine.

La documentazione ufficiale Kubernetes introduce i concetti fondamentali: i pod, che rappresentano l'unità minima di esecuzione, i controllori come Deployment e ReplicaSet che mantengono lo stato desiderato, e i servizi di rete che espongono i workload. Per quanto riguarda la sicurezza, gli argomenti più richiesti sono il controllo degli accessi basato sui ruoli, le Network Policy per la micro-segmentazione e la corretta gestione dei secret, su cui la documentazione Kubernetes fornisce indicazioni specifiche.

5. Configurazione e automazione: l'idempotenza come requisito

La gestione della configurazione mantiene i server in uno stato noto e coerente: pacchetti installati, file presenti e servizi attivi, definiti come codice anziché impostati manualmente. Strumenti come Ansible esprimono lo stato desiderato in playbook.

La proprietà più importante è l'idempotenza: eseguire più volte la stessa operazione produce lo stesso risultato di eseguirla una sola volta. È ciò che rende sicuro rieseguire la stessa pipeline a ogni commit o lo stesso playbook ogni notte, senza il timore di modifiche cumulative. Uno script non idempotente che aggiunge una riga a ogni esecuzione rappresenta l'esempio opposto da evitare.

6. Osservabilità e metriche: monitoraggio, log e trace

Monitoraggio e osservabilità sono concetti distinti. Il monitoraggio risponde alla domanda se qualcosa non va, osservando metriche e allarmi predefiniti come CPU, tasso di errore e latenza. L'osservabilità è la capacità più ampia di rispondere alla domanda perché qualcosa non va, anche per problemi non previsti, combinando metriche, log e trace.

La distinzione che emerge nei colloqui è che il monitoraggio intercetta le modalità di guasto note, mentre l'osservabilità aiuta a diagnosticare quelle mai previste.

Per misurare le prestazioni del processo di consegna, le metriche DORA sono diventate un punto di riferimento. Il programma di ricerca DORA, gestito da Google Cloud, ha evoluto il modello dalle quattro metriche originali a cinque: tempo di consegna delle modifiche, frequenza di deployment, tempo di recupero dai deployment falliti, tasso di fallimento delle modifiche e tasso di rielaborazione dei deployment. La ricerca dimostra che velocità e stabilità non sono in contrasto: i team con le migliori prestazioni ottengono risultati elevati su tutte le metriche.

Una considerazione importante: le metriche DORA vanno applicate a livello di singola applicazione o servizio, non a interi team o organizzazioni, e non devono diventare un obiettivo fine a se stesso, per evitare il rischio di distorsioni descritto dalla legge di Goodhart.

7. Gestione degli incidenti: prima ripristina, poi diagnostica

L'ultimo pilastro riguarda ciò che accade quando qualcosa va storto. L'ordine di priorità in un incidente è quasi sempre lo stesso: ripristinare il servizio prima, diagnosticare dopo.

Un esempio classico: un deployment viene segnalato come riuscito, ma l'applicazione è irraggiungibile. In questo caso è necessario separare il meccanismo di deployment dalla salute dell'applicazione. Si controlla l'endpoint di salute e i log, perché un container può risultare "in esecuzione" mentre il processo al suo interno è in crash o non supera i controlli di readiness. Se la causa è chiaramente la nuova release, la priorità è eseguire un rollback e diagnosticare dopo, perché ripristinare il servizio è più importante che individuare la causa mentre gli utenti non sono operativi.

Per rendere il rollback sicuro è necessario progettarlo in anticipo: produrre artefatti immutabili e versionati, mantenere deployment automatizzati e identici tra le versioni e gestire con attenzione le migrazioni del database, che non sono reversibili come un semplice redeploy.

8. Come costruire un piano di studio pratico

La componente che distingue una preparazione efficace da una mnemonica è la pratica. Le raccomandazioni operative sono poche e concrete.

• Eseguire un terraform plan su un ambiente di test e leggere l'output, verificando quali risorse verranno create, modificate o distrutte.
• Costruire una pipeline completa su un repository personale, con stage di build, test e deploy.
• Sperimentare con Docker e con un cluster Kubernetes locale, arrivando a gestire un deployment, una Network Policy e un secret.
• Simulare un incidente e mettere per iscritto una sequenza di ripristino, includendo comunicazione, rollback e documentazione successiva.
• Misurare il proprio processo di consegna con le metriche DORA, per capire quali metriche sono più facili da migliorare.

La capacità di spiegare con chiarezza le proprie decisioni tecniche, di descrivere cosa si è costruito e perché, e di ammettere con onestà il confine della propria esperienza, vale più di un elenco di strumenti citati senza profondità.

Conclusione

La preparazione a un ruolo DevOps non si riduce a memorizzare definizioni. I concetti fondamentali, cultura, CI/CD, infrastruttura come codice e container, vanno spiegati con chiarezza. Gli strumenti indicati nel curriculum vanno conosciuti in profondità, almeno di un livello rispetto a quanto richiesto dalla descrizione del ruolo. Gli scenari premiano il giudizio: ripristinare prima di diagnosticare, progettare i rollback prima che servano, trattare i test instabili come bug reali.

La roadmap descritta in questo articolo rappresenta una base solida, ma il valore maggiore arriva dall'esperienza pratica. Per chi desidera un percorso guidato e strutturato, con laboratori e verifiche delle competenze, la formazione DevOps offerta da Digital Lab è progettata per trasformare i concetti in capacità operative.