TL;DR — In sintesi: DevOps non è un tool da comprare, è una cultura ingegneristica fatta di responsabilità condivisa fra sviluppo e operations, automazione del percorso che porta il codice in produzione e misurazione costante. La buona notizia per le PMI italiane è che esistono framework consolidati per portarla a casa senza budget enterprise: il modello CAMS (Culture, Automation, Measurement, Sharing) e soprattutto le 4 metriche DORA — deployment frequency, lead time for changes, change failure rate e MTTR — che da otto anni separano i team Elite dai team Low performer. In questa guida vediamo come misurarle con quello che già usi (Git, CI/CD, incident tracker), quali capability dell’Accelerate di Forsgren, Humble e Kim spostano davvero l’ago, e una roadmap di maturità 12 mesi pensata per realtà da 5 a 50 developer.
Nel sentire comune di molte PMI italiane, “fare DevOps” significa comprare un server Jenkins, assumere una persona con il titolo di DevOps engineer oppure mettere Docker su tutto. Tutte e tre le mosse possono far parte del viaggio, ma nessuna è di per sé DevOps. Il termine, coniato da Patrick Debois al primo DevOpsDays di Gand nel 2009, descrive un movimento culturale nato per abbattere il muro fra chi scrive il software (Dev) e chi lo manda in produzione (Ops), responsabili in passato di obiettivi opposti — i primi pagati per rilasciare, i secondi per non rompere nulla.
Dal 2014 il DORA team (DevOps Research and Assessment, acquisito da Google nel 2018) pubblica annualmente lo State of DevOps Report. La conclusione, ripetuta edizione dopo edizione, è controintuitiva ma robusta: i team che rilasciano più spesso non sono meno stabili. Le organizzazioni classificate Elite deployano fino a 973 volte più frequentemente e recuperano dai guasti 6.570 volte più velocemente dei Low performer, mantenendo allo stesso tempo un change failure rate più basso. Questo articolo è una guida operativa per portare lo stesso modello dentro una PMI italiana che non ha un team di piattaforma dedicato.
Cos’è la cultura DevOps: il framework CAMS (e poi CALMS)
Quando Damon Edwards e John Willis nel 2010 hanno sintetizzato le pratiche emergenti del movimento, l’hanno fatto con un acronimo diventato standard di fatto: CAMS — Culture, Automation, Measurement, Sharing. Jez Humble ha poi aggiunto la L di Lean (CALMS), per ricordare che senza pensiero snello — flussi di valore, riduzione del work in progress, eliminazione degli sprechi — anche la migliore automazione produce solo “consegne veloci di codice sbagliato”.
- Culture: responsabilità end-to-end. Chi scrive il codice ne segue il funzionamento in produzione. “You build it, you run it” è la frase di Werner Vogels (CTO Amazon) del 2006.
- Automation: tutto ciò che si ripete più di tre volte va automatizzato — build, test, deploy, provisioning, configurazione, rollback.
- Lean: piccoli batch, lavorazioni veloci, feedback rapido. Una pull request che resta aperta tre settimane è uno spreco identico a un magazzino pieno.
- Measurement: senza dati il cambiamento è opinione. Le 4 DORA metrics sono il punto di partenza.
- Sharing: post-mortem condivisi e blameless, documentazione viva, dashboard pubbliche, runbook scritti per chi non era nella stanza.
Nel libro “The Phoenix Project” (Gene Kim, Kevin Behr, George Spafford, 2013) e in “The DevOps Handbook” (2016) lo stesso Kim formalizza un modello complementare: le tre vie. La prima via è il flow (dal codice alla produzione, accelerato e predicibile); la seconda via è il feedback (dalla produzione al codice, breve e amplificato); la terza via è la cultura del miglioramento continuo e della sperimentazione, dove il fallimento è informazione e non colpa.
Le 4 metriche DORA: la bussola del delivery
Il contributo più operativo del DORA team è aver identificato quattro misure che, prese insieme, descrivono in modo robusto la performance di delivery di un team software. Sono semplici da raccogliere, difficili da imbrogliare e correlano con le performance di business. Le ha portate al grande pubblico Nicole Forsgren assieme a Humble e Kim nel libro “Accelerate” (IT Revolution Press, 2018), che resta nel 2022 il riferimento più citato in materia.
Le quattro metriche sono divise in due coppie: due misurano la velocità, due la stabilità. Non si scambiano: un team che rilascia spesso ma rompe sempre è inutile quanto uno che rilascia raro e con cura.
1. Deployment Frequency
Quante volte il team rilascia codice in produzione. Si misura dal log della pipeline CI/CD: ogni job di tipo deploy-to-production con stato success conta uno. Soglie DORA 2021:
- Elite: on-demand, più di una volta al giorno.
- High: una volta alla settimana, fino a una al giorno.
- Medium: una volta al mese, fino a una alla settimana.
- Low: meno di una volta ogni sei mesi.
2. Lead Time for Changes
Il tempo che passa fra il commit in main e l’arrivo in produzione. Non è il tempo “umano” della feature: è solo il pezzo tecnico, perché misura l’efficienza della pipeline. Si calcola da Git e dal CI/CD log. Soglie:
- Elite: meno di un’ora.
- High: meno di una settimana.
- Medium: tra una settimana e sei mesi.
- Low: oltre sei mesi.
3. Change Failure Rate
Percentuale di deploy che richiedono un hotfix, un rollback o un intervento di emergenza entro 24 ore. Si calcola contando gli incident “post-deploy” sul totale deploy. Soglie (più basse = meglio):
- Elite: 0-15%.
- High: 16-30%.
- Medium: 16-45%.
- Low: 16-60%.
4. Mean Time to Recover (MTTR)
Tempo medio per ripristinare il servizio dopo un’interruzione. Da PagerDuty, Opsgenie o VictorOps: end of incident meno start of incident, mediato sugli incident del periodo. Soglie:
- Elite: meno di un’ora.
- High: meno di un giorno.
- Medium: tra un giorno e una settimana.
- Low: oltre sei mesi.
Un dato che spesso sorprende: le PMI italiane che vediamo partire da zero collocano tre metriche su quattro nella fascia Low, e quasi mai un’organizzazione le ha tutte già misurate. Il primo investimento è iniziare a contare — anche su un foglio Excel.
Come misurare le 4 DORA metrics in pratica
Una delle obiezioni più comuni nelle PMI è “non abbiamo strumenti dedicati”. Bene: non servono. Le quattro metriche si possono ricostruire con quello che già hai.
Deployment frequency: su Jenkins serve /job/<name>/api/json?tree=builds[number,timestamp,result] filtrato sui job di deploy. Su GitHub Actions basta GET /repos/{owner}/{repo}/actions/runs filtrato sul workflow di produzione. Su GitLab CI la chiamata è GET /projects/:id/pipelines con scope=finished&status=success. Conti gli eseguiti con successo nell’arco temporale.
Lead time for changes: per ogni deploy in produzione, prendi l’elenco dei commit SHA inclusi (con git log v1.2..v1.3 --pretty=format:'%H %ct'). Per ogni SHA calcoli (timestamp del deploy) – (timestamp del commit). La mediana è il tuo lead time. La mediana — non la media — perché un singolo hotfix notturno può sballare la media.
Change failure rate: nel tuo incident tracker (Jira Service Management, Zendesk, Linear, GitHub Issues con label incident) marca con tag post-deploy tutti gli incident aperti entro 24h da un deploy. A fine mese: incident post-deploy / deploy totali.
MTTR: somma end_at – start_at di tutti gli incident del periodo e dividi per il numero degli incident.
Una PMI con cui abbiamo lavorato ha costruito una prima dashboard DORA con un Google Sheet alimentato da Apps Script che pesca i dati da GitHub Actions API ogni notte. Tempo: due pomeriggi. Costo: zero. Avere quei quattro numeri sotto gli occhi del team ogni mattina ha cambiato i comportamenti più di qualsiasi corso.
CI/CD: le fondamenta tecniche
Nessun miglioramento delle 4 metriche è possibile senza una pipeline CI/CD automatizzata. Il principio: dal momento in cui un commit entra in main, tutto avviene senza intervento umano — build, test unitari, test di integrazione, packaging, deploy.
Gli strumenti più diffusi nel 2022 sono Jenkins (on-premise, plugin per qualsiasi cosa), GitHub Actions (integrato, quota generosa anche per privati), GitLab CI/CD (eccellente per chi self-hosta), CircleCI e Drone. Per il Kubernetes nativo si stanno affermando ArgoCD, Flux e Tekton.
Tre pratiche fanno la differenza fra una pipeline che “funziona” e una che abilita davvero continuous delivery:
- Trunk-based development: invece di feature branch lunghi alla Git Flow, tutti integrano in
mainalmeno una volta al giorno, nascondendo feature incomplete dietro feature flag. È la pratica più correlata con punteggi DORA Elite secondo Accelerate. - Test automatizzati: piramide classica — molti unit test alla base, qualche integration test al centro, pochissimi E2E in cima.
- Build veloci: una pipeline che impiega 45 minuti viene usata male. Sotto i 10 minuti è dove si vince. Cache dipendenze, test paralleli, sottoinsieme legato ai file modificati.
Infrastructure as Code: il provisioning come software
Configurare manualmente server e servizi cloud — fosse anche solo via console AWS — è la principale fonte di drift fra ambienti. La risposta DevOps è Infrastructure as Code (IaC): l’infrastruttura è descritta in file di testo, versionata in Git, applicata da una pipeline.
Strumenti maturi nel 2022: Terraform (HashiCorp, leader multi-cloud), Pulumi (infra in TypeScript/Python/Go), AWS CloudFormation e Azure Bicep (nativi, ma lock-in), Ansible (orientato al configuration management).
Il valore non è “scrivere YAML invece che cliccare”: è che ogni modifica passa per una pull request, viene revisionata, lascia traccia e può essere ricreata altrove con un comando. Per una PMI il caso d’uso tipico è dare a ogni developer la possibilità di tirar su un ambiente di test identico alla produzione in 15 minuti.
Containerizzazione e GitOps
I container, popolarizzati da Docker dal 2013, hanno risolto il vecchio problema “funziona sulla mia macchina”. Per orchestrarli lo standard è Kubernetes, nato in Google e donato alla CNCF nel 2015. Per una PMI con pochi servizi Kubernetes può essere sovradimensionato: alternative ragionevoli sono Docker Compose + VPS per progetti piccoli, AWS ECS o Google Cloud Run, e k3s/k0s per Kubernetes leggero. Quando si fa sul serio, Helm è il package manager standard.
Coniato da Alexis Richardson di Weaveworks nel 2017, GitOps è un’evoluzione naturale di IaC + Kubernetes: un repository Git è l’unica fonte di verità sullo stato desiderato, un agente in cluster osserva il repo e riconcilia. I due strumenti dominanti nel 2022 sono ArgoCD (UI user-friendly) e Flux (CLI-first, CNCF). Per chi vuole GitOps su Terraform, Atlantis automatizza plan e apply dalle pull request.
Il beneficio sulle 4 DORA metrics è diretto: deployment frequency aumenta (basta un merge), lead time crolla, change failure rate scende (ogni stato è dichiarato e ripristinabile), MTTR si comprime (un rollback è un git revert).
Feature flags, canary e blue-green: separare deploy da release
Una delle scoperte controintuitive della cultura DevOps è che deploy (mandare il codice in produzione) e release (attivare la funzionalità per gli utenti) sono cose diverse. Le feature flag permettono di rilasciare codice “spento”, attivarlo prima per il team interno, poi per l’1% degli utenti, poi per il 10%, infine per tutti.
Gli strumenti più usati nel 2022 sono LaunchDarkly (leader commerciale), Split.io (forte sull’analisi esperimenti), Unleash (open source, self-hosted) e GrowthBook (OSS, feature flag + A/B test). Per una PMI italiana il punto di partenza ragionevole è Unleash o GrowthBook self-hosted: zero canone.
Le strategie di deploy collegate sono canary (versione nuova attiva su una piccola percentuale del traffico), blue-green (due ambienti identici, switch atomico) e rolling (sostituzione progressiva). Tutte e tre riducono drasticamente il rischio del singolo deploy — e quindi il change failure rate.
SRE: SLI, SLO e l’error budget
La pratica chiamata Site Reliability Engineering, formalizzata da Google nel libro omonimo del 2016, è la cugina ingegneristica del DevOps. Le due culture convergono. Il contributo più portabile in PMI sono tre concetti:
- SLI (Service Level Indicator): una misura concreta — es. “percentuale di richieste HTTP che rispondono in meno di 300ms”.
- SLO (Service Level Objective): il target — es. “il 99,5% delle richieste sotto i 300ms su un mese mobile”.
- SLA (Service Level Agreement): il contratto esterno verso il cliente, tipicamente più conservativo dell’SLO interno.
Da SLO + finestra temporale nasce l’error budget: se l’SLO è 99,5%, hai un budget di “downtime accettabile” del 0,5% — circa 3,6 ore al mese. Finché il budget regge, il team sperimenta e rilascia in fretta. Quando il budget si esaurisce, le priorità si spostano sulla stabilizzazione. È un meccanismo elegante per allineare velocità e affidabilità senza scontri politici.
Sulla parte cultura, l’SRE ha popolarizzato il post-mortem blameless: dopo ogni incident significativo si scrive un documento che descrive cosa è successo, perché, come è stato risolto e come prevenirlo — senza puntare il dito su persone.
Platform engineering: il trend del 2022
Nel 2022 c’è una conversazione molto attiva nella community DevOps su un’evoluzione del ruolo: il Platform Engineering. L’osservazione di partenza è che chiedere a ogni team di prodotto di padroneggiare Kubernetes, Terraform, ArgoCD, Prometheus e mille altri strumenti è un costo cognitivo insostenibile.
La risposta è creare una Internal Developer Platform (IDP): un set di servizi self-service, costruiti da un team di platform engineer, che espongono ai developer di prodotto le primitive — creare un nuovo servizio, deployare, vedere log — dietro un’interfaccia semplice. L’idea sono i “golden paths”: percorsi raccomandati che fanno la cosa giusta di default, con sicurezza, osservabilità e compliance incluse.
Lo strumento più discusso è Backstage, il developer portal open source rilasciato da Spotify nel 2020. Permette di costruire un catalogo dei servizi, plugin per CI/CD e template di nuovi progetti. Per una PMI con 3-5 team di prodotto, anche una versione “leggera” del concetto (uno script che genera lo scaffold di un nuovo microservizio con CI/CD, monitoring e logging già configurati) produce benefici enormi.
DevSecOps e observability
Spostare la security “a sinistra” nella pipeline significa cercare i problemi durante lo sviluppo, non in produzione. Le pratiche concrete: SAST (analisi statica — SonarQube, Semgrep, CodeQL), DAST (scansione dinamica — OWASP ZAP), SCA (analisi delle dipendenze open source per CVE — Snyk, Dependabot, Trivy), container scanning (Trivy, Clair, Grype), secret scanning (gitleaks, truffleHog). L’errore comune è trattare la security come gate finale che blocca il deploy: il DevSecOps maturo integra i controlli come step della CI con feedback al developer entro 10 minuti.
L’observability moderna si fonda su tre pilastri — metriche, log, tracce distribuite — e su uno stack tipicamente composto da Prometheus, Grafana, Loki e Tempo/Jaeger. Abbiamo trattato lo stack in dettaglio nell’articolo Microservizi observability per PMI 2022. Per il discorso DORA, due metriche derivate: MTTD (Mean Time To Detect) e MTTR. Migliorare il primo è la leva diretta sul secondo.
Team Topologies e chaos engineering
Nel libro “Team Topologies” (Matthew Skelton e Manuel Pais, 2019) viene proposto un linguaggio per descrivere le organizzazioni di sviluppo software. Quattro tipi di team: stream-aligned (allineato a un flusso di valore di business — il team “principale”), platform (fornisce servizi internamente), enabling (aiuta gli altri team a colmare gap di competenza), complicated subsystem (specialisti su parti tecnicamente complesse). Per le PMI il modello è utile soprattutto per capire che il team DevOps separato è un anti-pattern: o sei un platform team (e fornisci servizi self-service), o sei un enabling team (e ti dissolvi dopo aver insegnato).
Netflix ha inventato il chaos engineering nel 2011 con Chaos Monkey, uno strumento che spegne casualmente istanze EC2 in produzione per costringere ogni servizio a essere resiliente. Nel 2022 il riferimento commerciale è Gremlin, mentre open source ci sono Litmus, Chaos Mesh. Per una PMI italiana è prematuro finché non c’è una baseline di observability e SLO, ma vale la pena conoscere il principio.
Errori comuni di implementazione
- Creare un “team DevOps” separato: ricrea esattamente il muro che si voleva abbattere. Se serve un team dedicato, sia un platform team con clienti interni chiari.
- Tool first, culture second: comprare Jenkins, Kubernetes e ArgoCD senza cambiare le abitudini di code review, branching e ownership produce solo nuovi punti di rottura.
- Non misurare le DORA: senza dati ogni discussione diventa di pancia. Tre mesi di numeri spengono il 90% dei dibattiti.
- Nessuna golden path: ogni team reinventa il proprio modo di fare CI/CD, deploy, log. L’overhead diventa insostenibile.
- Test e security come “blocchi finali”: spostali a sinistra o saranno sempre il collo di bottiglia.
- Ignorare il change failure rate: massimizzare la deployment frequency senza guardare la stabilità è auto-sabotaggio.
5 segnali che il tuo team DevOps è maturo
- Le 4 DORA metrics sono in dashboard visibile a tutti, non in un foglio personale del CTO.
- Ogni deploy in produzione è automatico da un merge su
main, e qualcuno deploya almeno una volta al giorno senza che sia un evento. - I post-mortem sono blameless e producono action item tracciati, non lamentele.
- La sicurezza è un alleato nella pipeline, non un gate finale.
- I nuovi sviluppatori sono produttivi in meno di una settimana grazie a documentazione viva, ambienti riproducibili e onboarding automatizzato.
Roadmap di maturità 12 mesi per una PMI italiana
Trimestre 1 — Fondazioni e misurazione. Tutto in Git (codice e infrastruttura). CI per ogni progetto con build + test su ogni push. Inizia a contare le 4 DORA metrics anche su Excel. Definisci un SLO base per il servizio più critico.
Trimestre 2 — Automation del deploy. Deploy automatico in staging su ogni merge in main. Test automatizzati al 60-70% sul codice di business. Introduci Terraform per il provisioning dei nuovi ambienti. Prima dashboard DORA condivisa.
Trimestre 3 — Stabilità e observability. Deploy automatico in produzione (con approvazione manuale se serve). Stack Prometheus + Grafana + Loki online. Primo post-mortem blameless. Feature flag su almeno una funzionalità con rilascio progressivo.
Trimestre 4 — Platform e scaling. Self-service per creare nuovi servizi (template di scaffold). Security scanning nella pipeline. Pratiche di trunk-based development consolidate. Le 4 metriche DORA tutte almeno in fascia “Medium”, una o due in “High”.
A questo punto puoi pensare a Backstage, a chaos engineering controllato, a un team di platform engineering. Ma solo a questo punto: l’ordine conta, perché ogni passo dipende dal precedente.
FAQ — Domande frequenti sulla cultura DevOps
Una PMI da 10 developer ha senso che faccia DevOps?
Sì, è il taglio ideale per partire bene. Una PMI piccola non ha il debito organizzativo di una grande azienda e può iniziare con pratiche moderne dal giorno uno. Le 4 DORA metrics si migliorano anche con un team da 5 persone.
Devo assumere un DevOps engineer?
Non necessariamente come primo passo. È più efficace formare i developer esistenti sulle pratiche (CI/CD, IaC, observability) e introdurre un platform engineer quando i team di prodotto diventano 3-4. “DevOps engineer” come singolo ruolo è spesso un anti-pattern.
Quanto costa partire senza tool enterprise?
Lo stack open source è praticamente gratuito a livello di licenze: Git/Gitea o GitHub free, GitHub Actions o GitLab CI, Terraform OSS, Prometheus + Grafana + Loki, Unleash o GrowthBook. Il costo vero è il tempo di setup e formazione — 4-8 settimane-uomo per arrivare a una pipeline produttiva.
Trunk-based development o Git Flow?
Per la maggior parte dei team la risposta del 2022 è trunk-based development con feature branch di vita breve (1-3 giorni) e feature flag per il work-in-progress. Git Flow ha senso quasi solo per software con release rare e versionate.
Le DORA metrics si possono “imbrogliare”?
Le 4 metriche sono robuste perché ognuna in isolamento può essere ottimizzata male, ma insieme no. Forsgren lo dice esplicitamente in Accelerate: tienile tutte e quattro sempre insieme.
Devo passare a Kubernetes per fare DevOps?
No. Una PMI con monolite ben fatto su un buon VPS e una pipeline CI/CD curata può avere DORA metrics migliori di un team che si è sparato Kubernetes prima del tempo.
Come convinco la direzione a investire in DevOps?
Mostrale numeri. Misura il lead time attuale e il change failure rate. Mostra le soglie DORA. Spiega che ogni mese di lead time significa funzionalità ritardate e ricavi rimandati. Non parlare di tool: parla di velocità di delivery e stabilità.
Vuoi implementare DevOps nella tua PMI senza partire da zero?
Brentasoft affianca le PMI italiane nel disegno della pipeline CI/CD, nella misurazione delle 4 DORA metrics e nella crescita della cultura ingegneristica. Richiedi un preventivo personalizzato sul tuo contesto.
Per approfondire l’observability che alimenta le 4 metriche DORA, leggi la guida dedicata: Microservizi observability per PMI 2022: stack Prometheus, Grafana, Loki e Tempo. Se invece stai valutando uno stack di automazione gestionale che si appoggi alle stesse pratiche di CI/CD e IaC, dai un’occhiata alle soluzioni di automazione Brentasoft e alle integrazioni API già pronte.
Vuoi una soluzione su misura per la tua azienda?
Brentasoft sviluppa gestionali, CRM e software personalizzati per PMI italiane. Parliamo del tuo progetto.
