La guida che spiega cosa cavolo è DevOps, perché non è un mestiere, e perché il tuo annuncio LinkedIn è probabilmente sbagliato.
Alla fine DevOps non è poi così terribile, basta che qualcuno te lo spieghi senza il tono da "senior architect che ha fatto 14 certificazioni".
DevOps non è un ruolo.
È una cultura, una filosofia, un modo di lavorare. Dire "cerco un DevOps" è come dire "cerco un Agile". Non ha senso. Ma ormai è tardi.
Spoiler: non è quello che c'è scritto sugli annunci di lavoro
Immagina di costruire una casa. I muratori (Dev) costruiscono i muri. Gli idraulici/elettricisti (Ops) fanno funzionare acqua e luce. Nel vecchio mondo, i muratori finivano e lanciavano le chiavi agli idraulici urlando "arrangiati". Gli idraulici rispondevano "ma chi ha progettato questa roba?!". DevOps è quando lavorano insieme dall'inizio, nella stessa stanza, con lo stesso obiettivo: una casa che funziona e non crolla.
Dev: "Ho finito il codice, funziona sul mio PC. Ciao."
Ops: "Non funziona in produzione."
Dev: "Non è un mio problema."
Ops: "..."
Manager: "Perché il deploy ci mette 3 mesi?"
Team: "Abbiamo scritto il codice, lo testa la pipeline, si deploya automaticamente, monitoriamo insieme. Se qualcosa si rompe, lo fixiamo tutti."
Manager: "Ma quanto costa?"
Team: "Meno di 3 mesi di lite tra Dev e Ops."
DevOps è un insieme di pratiche, principi culturali e strumenti che aumentano la capacità di un'organizzazione di rilasciare software e servizi velocemente, con alta qualità e meno rischi.
Rompe il muro tra chi scrive il codice (Development) e chi lo mette in produzione e lo tiene in piedi (Operations).
La breve e tragica storia di Dev vs Ops
Dev scrive codice per 6 mesi. Lo lancia oltre il muro a Ops. Ops bestemmia per 3 mesi per farlo funzionare in produzione. Il cliente aspetta 9 mesi. Tutti infelici.
I Dev iniziano a rilasciare più spesso. Ma Ops è ancora lì a fare deploy manuali. "Abbiamo 47 microservizi da deployare. A mano. Ogni settimana." Il muro tra Dev e Ops diventa più evidente.
Patrick Debois organizza i primi "DevOpsDays" in Belgio. L'idea: se Agile ha rotto i silos tra business e Dev, facciamo lo stesso tra Dev e Ops. Il termine "DevOps" nasce in un tweet. Sì, sul serio.
Docker (2013), Kubernetes (2014), Terraform, Ansible, Jenkins... Gli strumenti esplodono. Netflix, Google, Amazon dimostrano che funziona. Tutti vogliono "fare DevOps". Il mercato impazzisce.
Le aziende iniziano a cercare "DevOps Engineer". Che è come cercare un "Agile Person". Prendono un sysadmin, gli danno accesso a Jenkins e Docker, e lo rinominano. Stipendio +30%. DevOps diventa un ruolo perché i recruiter devono mettere qualcosa su LinkedIn.
DevOps doveva eliminare i silos. Invece abbiamo creato un terzo silo chiamato "il team DevOps". Dev scrive codice e lo lancia al "DevOps". Il DevOps fa il deploy e lo lancia a Ops. Abbiamo aggiunto un passaggio. Geniale.
E allora perché tutti lo cercano su LinkedIn?
"There is no such thing as a DevOps Engineer. DevOps is not a role, it's a cultural movement."
DevOps è una cultura. Un modo in cui Dev e Ops (e QA, e Security, e tutti) lavorano insieme invece che in silos separati. È come "Agile": non assumi "un Agile", cambi il modo in cui il team lavora.
❌ Quello che il mercato pensa
✅ Quello che DevOps è davvero
Perché il mercato ha bisogno di etichette. I recruiter devono mettere un titolo sull'annuncio. Le aziende devono assegnare un budget a qualcuno. E "Ingegnere dell'Automazione dell'Infrastruttura con Focus sulla Cultura Collaborativa" non entra nel form di LinkedIn.
Quindi hanno preso il concetto, lo hanno schiacciato in un ruolo, e ora cercano "DevOps Engineer" intendendo una di queste cose:
Costruisce la piattaforma (CI/CD, infrastruttura, tool) su cui i dev lavorano.
Site Reliability Engineer. Tiene in piedi la produzione. Il figlio di Google.
Gestisce l'infrastruttura cloud. Terraform, AWS, "quanto ci costa questo mese?".
Gestisce le pipeline di CI/CD e il processo di rilascio.
Il sysadmin che ha imparato Docker, K8s e Infrastructure as Code. Onesto.
Dev, Ops, DBA, networking, sicurezza, caffettiera. Stipendio di uno. Lavoro di cinque.
I principi veri, quelli che dovrebbero cambiare il modo di lavorare
Più velocemente sai che qualcosa è rotto, più velocemente lo fixi. La pipeline ti dice in 5 minuti se il codice è buono, non in 3 mesi quando il cliente chiama urlando.
Gli errori in produzione succederanno. La domanda non è "come li evito?" ma "come li detecto in 30 secondi e faccio rollback in 60?". Il post-mortem senza colpa è sacro.
Infrastruttura? Codice (Terraform). Configurazione? Codice (Ansible). Pipeline? Codice (YAML). Monitoring? Codice (Prometheus rules). Se non è in un repo Git, non esiste.
Chi scrive il codice è responsabile anche di farlo girare in produzione. Niente più "l'ho sviluppato, ora è un problema di qualcun altro". Questo cambia radicalmente come scrivi codice.
Ok la filosofia, ma cosa si fa concretamente?
La toolchain del "DevOps" (qualunque cosa significhi)
| Fase | Cosa fai | Tool |
|---|---|---|
| 📋 Plan | Gestione progetto, ticket | Jira, Linear, GitHub Issues, Trello |
| 💻 Code | Scrivi e versionizza il codice | Git, GitHub, GitLab, Bitbucket |
| 🔧 Build | Compila, impacchetta | Docker, Maven, Gradle, npm |
| ✅ Test | Test automatici | Jest, pytest, Selenium, SonarQube |
| 🚀 Release | Pipeline CI/CD | GitHub Actions, GitLab CI, Jenkins, ArgoCD |
| ☁️ Deploy | Metti in produzione | Kubernetes, Terraform, Ansible, Helm |
| 📊 Operate | Gestisci l'infrastruttura | AWS/GCP/Azure, Terraform, Vault |
| 🚨 Monitor | Osserva e allerta | Prometheus, Grafana, Datadog, PagerDuty |
Non devi conoscerli tutti. Nessuno li conosce tutti. Chiunque dica di si è un bugiardo o un consulente (spesso la stessa cosa). Impara Git + Docker + una pipeline CI/CD + un cloud provider. Il resto viene con l'esperienza e con Google alle 2 di notte.
Cosa fa davvero chi ha "DevOps" nel titolo
Apri Slack. 47 notifiche. Un alert di PagerDuty delle 4:37. Il disco del database di staging è pieno. Un dev ha pushato direttamente su main. Caffè.
"Ieri ho fixato la pipeline, oggi lavoro sul Terraform per il nuovo ambiente, sono bloccato perché il team security non mi ha ancora dato i permessi IAM." 47 secondi. Fine. Poi il dev junior chiede cos'è un container. Gli mandi la guida Docker per Svogliati.
Scrivi Terraform per il nuovo microservizio. La pipeline di CI/CD del team backend si è rotta perché qualcuno ha aggiornato una dipendenza. Fixi. Un altro team chiede come configurare il liveness probe su K8s. Rispondi. Un alert: la latenza dell'API è salita. Indaghi. Era un query lento nel DB. Dici al DBA. Torni al Terraform.
Mangi guardando un alert di Grafana sul telefono. Non è niente di grave. Forse.
Meeting con il team security per la rotazione dei segreti. Meeting con il team platform per la migrazione a K8s 1.30. Una PR da revieware: qualcuno ha scritto un Dockerfile con USER root. Bocciata. Un dev vuole sapere perché il suo container non parla con il database. Stessa rete? No. Risolto.
Chiudi il portatile. Il telefono vibra: alert di PagerDuty. Un pod in CrashLoopBackOff. Un OOMKilled. Riapri il portatile. Fix. Chiudi. È la vita.
Le cazzate che sentirai (o che hai già sentito)
❌ "DevOps è un ruolo / un team"
✅ DevOps è una cultura. Il "team DevOps" che sta tra Dev e Ops è letteralmente il contrario di DevOps.
Se hai creato un terzo silo chiamato "team DevOps" tra Dev e Ops, hai peggiorato la situazione. Hai aggiunto un passaggio, non l'hai tolto.
❌ "DevOps = strumenti (Docker, K8s, Jenkins)"
✅ Gli strumenti sono il mezzo, non il fine. Puoi fare DevOps con script bash su server bare-metal.
Un'azienda che usa Docker e K8s ma dove Dev e Ops non si parlano non fa DevOps. Un'azienda con server fisici dove tutti collaborano e deployano spesso fa più DevOps della prima.
❌ "DevOps significa che i Dev fanno anche Ops"
✅ Significa che la responsabilità è condivisa. Non che tutti fanno tutto.
Non devi trasformare ogni dev in un sysadmin. Devi creare un ambiente dove Dev e Ops lavorano insieme e capiscono il lavoro dell'altro. Lo specialismo resta, i silos no.
❌ "DevOps elimina il bisogno di Ops"
✅ DevOps ha bisogno di Ops più che mai. Solo che ora si chiama SRE, Platform Engineering, o "il tizio che sa come funziona il DNS".
L'infrastruttura non si gestisce da sola. L'automazione non si scrive da sola. Qualcuno deve capire networking, storage, sicurezza, e come funziona Linux alle 3 di notte. Quel qualcuno è Ops, con un cappello diverso.
❌ "Basta assumere un DevOps Engineer e siamo DevOps"
✅ È come assumere un personal trainer e aspettarsi di dimagrire senza fare esercizio.
DevOps richiede un cambio organizzativo. Se il management non ci crede, se i team non collaborano, se i processi non cambiano, puoi assumere 100 "DevOps Engineer" e non cambia niente.
❌ "DevOps è solo per le grandi aziende"
✅ Anche un team di 3 persone può (e dovrebbe) avere una pipeline CI/CD e monitoring.
GitHub Actions è gratis. Docker è gratis. Un Dockerfile + un workflow YAML = CI/CD. Non serve Netflix-scale per beneficiare di deploy automatici e test.
Consigli per chi si ritrova con "DevOps" nel titolo
I tool cambiano ogni 2 anni. Linux, networking, e come funziona un sistema operativo no. Capire TCP/IP ti salverà più spesso di sapere l'ultima feature di Terraform.
Se fai qualcosa più di due volte, scrivici uno script. Se lo script è importante, mettilo in una pipeline. Se la pipeline è critica, monitorala. La pigrizia è la madre dell'automazione.
"Puoi anche gestire il database?" No. "Puoi anche fare il frontend?" No. "Puoi fare l'oncall da solo per 6 mesi?" Assolutamente no. Il burnout nel "DevOps" è reale e comune.
Il te di domani non ricorderà perché hai configurato così quel load balancer. Scrivi un README. Il runbook per l'oncall. La procedura di disaster recovery. Il tuo futuro te ti ringrazierà.
Il miglior "DevOps" è quello che si rende inutile. Se solo tu sai deployare, sei un single point of failure, non un eroe. Insegna ai dev a leggere i log, a usare Docker, a debuggare.
L'oncall è lavoro, non volontariato. Le notti sono fatte per dormire, non per fixare il deployment che il PM ha voluto alle 17:58 di venerdì. Metti confini. Sul serio.
DevOps non è un mestiere. È una mentalità.
Non è un tool. È un modo di lavorare.
Non è un team. È tutti i team insieme.
E se qualcuno ti dice "fai il DevOps da solo per tutti",
aggiorna il CV.