{"id":2261,"date":"2022-07-12T10:24:00","date_gmt":"2022-07-12T08:24:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/devops-culture-dora-metrics-pmi-italiane-framework-2022\/"},"modified":"2022-07-12T10:24:00","modified_gmt":"2022-07-12T08:24:00","slug":"devops-culture-dora-metrics-pmi-italiane-framework-2022","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/devops-culture-dora-metrics-pmi-italiane-framework-2022\/","title":{"rendered":"DevOps culture per PMI 2022: framework + 4 DORA metrics per misurare delivery"},"content":{"rendered":"<div class=\"bs-article-tldr\">\n<p><strong>TL;DR \u2014 In sintesi:<\/strong> DevOps non \u00e8 un tool da comprare, \u00e8 una cultura ingegneristica fatta di responsabilit\u00e0 condivisa fra sviluppo e operations, automazione del percorso che porta il codice in produzione e misurazione costante. La buona notizia per le PMI italiane \u00e8 che esistono framework consolidati per portarla a casa senza budget enterprise: il modello CAMS (Culture, Automation, Measurement, Sharing) e soprattutto le 4 metriche DORA \u2014 deployment frequency, lead time for changes, change failure rate e MTTR \u2014 che da otto anni separano i team Elite dai team Low performer. In questa guida vediamo come misurarle con quello che gi\u00e0 usi (Git, CI\/CD, incident tracker), quali capability dell&#8217;<em>Accelerate<\/em> di Forsgren, Humble e Kim spostano davvero l&#8217;ago, e una roadmap di maturit\u00e0 12 mesi pensata per realt\u00e0 da 5 a 50 developer.<\/p>\n<\/div>\n<p>Nel sentire comune di molte PMI italiane, &#8220;fare DevOps&#8221; significa comprare un server Jenkins, assumere una persona con il titolo di <em>DevOps engineer<\/em> oppure mettere Docker su tutto. Tutte e tre le mosse possono far parte del viaggio, ma nessuna \u00e8 di per s\u00e9 DevOps. Il termine, coniato da <strong>Patrick Debois<\/strong> al primo <em>DevOpsDays<\/em> 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 \u2014 i primi pagati per rilasciare, i secondi per non rompere nulla.<\/p>\n<p>Dal 2014 il <strong>DORA team<\/strong> (DevOps Research and Assessment, acquisito da Google nel 2018) pubblica annualmente lo <em>State of DevOps Report<\/em>. La conclusione, ripetuta edizione dopo edizione, \u00e8 controintuitiva ma robusta: i team che rilasciano pi\u00f9 spesso non sono meno stabili. Le organizzazioni classificate <em>Elite<\/em> deployano fino a <strong>973 volte pi\u00f9 frequentemente<\/strong> e recuperano dai guasti <strong>6.570 volte pi\u00f9 velocemente<\/strong> dei <em>Low performer<\/em>, mantenendo allo stesso tempo un <em>change failure rate<\/em> pi\u00f9 basso. Questo articolo \u00e8 una guida operativa per portare lo stesso modello dentro una PMI italiana che non ha un team di piattaforma dedicato.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/developer-terminal-dual-monitor-2022.jpg\" alt=\"Developer scrive codice CI\/CD su doppio monitor\" title=\"Developer dual monitor CI\/CD\" style=\"max-width:100%;height:auto;margin:20px 0;\" \/><\/p>\n<h2>Cos&#8217;\u00e8 la cultura DevOps: il framework CAMS (e poi CALMS)<\/h2>\n<p>Quando <strong>Damon Edwards<\/strong> e <strong>John Willis<\/strong> nel 2010 hanno sintetizzato le pratiche emergenti del movimento, l&#8217;hanno fatto con un acronimo diventato standard di fatto: <strong>CAMS<\/strong> \u2014 <em>Culture, Automation, Measurement, Sharing<\/em>. <strong>Jez Humble<\/strong> ha poi aggiunto la <em>L<\/em> di <em>Lean<\/em> (CALMS), per ricordare che senza pensiero snello \u2014 flussi di valore, riduzione del work in progress, eliminazione degli sprechi \u2014 anche la migliore automazione produce solo &#8220;consegne veloci di codice sbagliato&#8221;.<\/p>\n<ul>\n<li><strong>Culture<\/strong>: responsabilit\u00e0 end-to-end. Chi scrive il codice ne segue il funzionamento in produzione. &#8220;<em>You build it, you run it<\/em>&#8221; \u00e8 la frase di Werner Vogels (CTO Amazon) del 2006.<\/li>\n<li><strong>Automation<\/strong>: tutto ci\u00f2 che si ripete pi\u00f9 di tre volte va automatizzato \u2014 build, test, deploy, provisioning, configurazione, rollback.<\/li>\n<li><strong>Lean<\/strong>: piccoli batch, lavorazioni veloci, feedback rapido. Una <em>pull request<\/em> che resta aperta tre settimane \u00e8 uno spreco identico a un magazzino pieno.<\/li>\n<li><strong>Measurement<\/strong>: senza dati il cambiamento \u00e8 opinione. Le 4 DORA metrics sono il punto di partenza.<\/li>\n<li><strong>Sharing<\/strong>: post-mortem condivisi e <em>blameless<\/em>, documentazione viva, dashboard pubbliche, runbook scritti per chi non era nella stanza.<\/li>\n<\/ul>\n<p>Nel libro <strong>&#8220;The Phoenix Project&#8221;<\/strong> (Gene Kim, Kevin Behr, George Spafford, 2013) e in <strong>&#8220;The DevOps Handbook&#8221;<\/strong> (2016) lo stesso Kim formalizza un modello complementare: <strong>le tre vie<\/strong>. La <em>prima via<\/em> \u00e8 il <strong>flow<\/strong> (dal codice alla produzione, accelerato e predicibile); la <em>seconda via<\/em> \u00e8 il <strong>feedback<\/strong> (dalla produzione al codice, breve e amplificato); la <em>terza via<\/em> \u00e8 la <strong>cultura del miglioramento continuo e della sperimentazione<\/strong>, dove il fallimento \u00e8 informazione e non colpa.<\/p>\n<h2>Le 4 metriche DORA: la bussola del delivery<\/h2>\n<p>Il contributo pi\u00f9 operativo del DORA team \u00e8 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 <strong>Nicole Forsgren<\/strong> assieme a Humble e Kim nel libro <strong>&#8220;Accelerate&#8221;<\/strong> (IT Revolution Press, 2018), che resta nel 2022 il riferimento pi\u00f9 citato in materia.<\/p>\n<p>Le quattro metriche sono divise in due coppie: due misurano la <strong>velocit\u00e0<\/strong>, due la <strong>stabilit\u00e0<\/strong>. Non si scambiano: un team che rilascia spesso ma rompe sempre \u00e8 inutile quanto uno che rilascia raro e con cura.<\/p>\n<h3>1. Deployment Frequency<\/h3>\n<p>Quante volte il team rilascia codice in produzione. Si misura dal log della pipeline CI\/CD: ogni <em>job<\/em> di tipo <em>deploy-to-production<\/em> con stato <em>success<\/em> conta uno. Soglie DORA 2021:<\/p>\n<ul>\n<li><strong>Elite<\/strong>: <em>on-demand<\/em>, pi\u00f9 di una volta al giorno.<\/li>\n<li><strong>High<\/strong>: una volta alla settimana, fino a una al giorno.<\/li>\n<li><strong>Medium<\/strong>: una volta al mese, fino a una alla settimana.<\/li>\n<li><strong>Low<\/strong>: meno di una volta ogni sei mesi.<\/li>\n<\/ul>\n<h3>2. Lead Time for Changes<\/h3>\n<p>Il tempo che passa fra il <em>commit<\/em> in <code>main<\/code> e l&#8217;arrivo in produzione. Non \u00e8 il tempo &#8220;umano&#8221; della feature: \u00e8 solo il pezzo tecnico, perch\u00e9 misura l&#8217;efficienza della pipeline. Si calcola da Git e dal CI\/CD log. Soglie:<\/p>\n<ul>\n<li><strong>Elite<\/strong>: meno di un&#8217;ora.<\/li>\n<li><strong>High<\/strong>: meno di una settimana.<\/li>\n<li><strong>Medium<\/strong>: tra una settimana e sei mesi.<\/li>\n<li><strong>Low<\/strong>: oltre sei mesi.<\/li>\n<\/ul>\n<h3>3. Change Failure Rate<\/h3>\n<p>Percentuale di deploy che richiedono un <em>hotfix<\/em>, un <em>rollback<\/em> o un intervento di emergenza entro 24 ore. Si calcola contando gli incident &#8220;post-deploy&#8221; sul totale deploy. Soglie (pi\u00f9 basse = meglio):<\/p>\n<ul>\n<li><strong>Elite<\/strong>: 0-15%.<\/li>\n<li><strong>High<\/strong>: 16-30%.<\/li>\n<li><strong>Medium<\/strong>: 16-45%.<\/li>\n<li><strong>Low<\/strong>: 16-60%.<\/li>\n<\/ul>\n<h3>4. Mean Time to Recover (MTTR)<\/h3>\n<p>Tempo medio per ripristinare il servizio dopo un&#8217;interruzione. Da PagerDuty, Opsgenie o VictorOps: <em>end of incident<\/em> meno <em>start of incident<\/em>, mediato sugli incident del periodo. Soglie:<\/p>\n<ul>\n<li><strong>Elite<\/strong>: meno di un&#8217;ora.<\/li>\n<li><strong>High<\/strong>: meno di un giorno.<\/li>\n<li><strong>Medium<\/strong>: tra un giorno e una settimana.<\/li>\n<li><strong>Low<\/strong>: oltre sei mesi.<\/li>\n<\/ul>\n<p>Un dato che spesso sorprende: le PMI italiane che vediamo partire da zero collocano tre metriche su quattro nella fascia <em>Low<\/em>, e quasi mai un&#8217;organizzazione le ha tutte gi\u00e0 misurate. Il primo investimento \u00e8 iniziare a contare \u2014 anche su un foglio Excel.<\/p>\n<h2>Come misurare le 4 DORA metrics in pratica<\/h2>\n<p>Una delle obiezioni pi\u00f9 comuni nelle PMI \u00e8 &#8220;non abbiamo strumenti dedicati&#8221;. Bene: <strong>non servono<\/strong>. Le quattro metriche si possono ricostruire con quello che gi\u00e0 hai.<\/p>\n<p><strong>Deployment frequency<\/strong>: su <em>Jenkins<\/em> serve <code>\/job\/&lt;name&gt;\/api\/json?tree=builds[number,timestamp,result]<\/code> filtrato sui job di deploy. Su <em>GitHub Actions<\/em> basta <code>GET \/repos\/{owner}\/{repo}\/actions\/runs<\/code> filtrato sul workflow di produzione. Su <em>GitLab CI<\/em> la chiamata \u00e8 <code>GET \/projects\/:id\/pipelines<\/code> con <code>scope=finished&amp;status=success<\/code>. Conti gli eseguiti con successo nell&#8217;arco temporale.<\/p>\n<p><strong>Lead time for changes<\/strong>: per ogni deploy in produzione, prendi l&#8217;elenco dei <em>commit SHA<\/em> inclusi (con <code>git log v1.2..v1.3 --pretty=format:'%H %ct'<\/code>). Per ogni SHA calcoli <em>(timestamp del deploy) &#8211; (timestamp del commit)<\/em>. La mediana \u00e8 il tuo lead time. La mediana \u2014 non la media \u2014 perch\u00e9 un singolo <em>hotfix<\/em> notturno pu\u00f2 sballare la media.<\/p>\n<p><strong>Change failure rate<\/strong>: nel tuo <em>incident tracker<\/em> (Jira Service Management, Zendesk, Linear, GitHub Issues con label <code>incident<\/code>) marca con tag <code>post-deploy<\/code> tutti gli incident aperti entro 24h da un deploy. A fine mese: <em>incident post-deploy \/ deploy totali<\/em>.<\/p>\n<p><strong>MTTR<\/strong>: somma <em>end_at &#8211; start_at<\/em> di tutti gli incident del periodo e dividi per il numero degli incident.<\/p>\n<p>Una PMI con cui abbiamo lavorato ha costruito una prima <em>dashboard DORA<\/em> 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\u00f9 di qualsiasi corso.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/cloud-infrastructure-server-moderno.jpg\" alt=\"Server moderni cloud infrastructure as code Terraform\" title=\"Cloud infrastructure server moderno\" style=\"max-width:100%;height:auto;margin:20px 0;\" \/><\/p>\n<h2>CI\/CD: le fondamenta tecniche<\/h2>\n<p>Nessun miglioramento delle 4 metriche \u00e8 possibile senza una <strong>pipeline CI\/CD<\/strong> automatizzata. Il principio: dal momento in cui un commit entra in <code>main<\/code>, tutto avviene senza intervento umano \u2014 build, test unitari, test di integrazione, packaging, deploy.<\/p>\n<p>Gli strumenti pi\u00f9 diffusi nel 2022 sono <strong>Jenkins<\/strong> (on-premise, plugin per qualsiasi cosa), <strong>GitHub Actions<\/strong> (integrato, quota generosa anche per privati), <strong>GitLab CI\/CD<\/strong> (eccellente per chi self-hosta), <strong>CircleCI<\/strong> e <strong>Drone<\/strong>. Per il Kubernetes nativo si stanno affermando <strong>ArgoCD<\/strong>, <strong>Flux<\/strong> e <strong>Tekton<\/strong>.<\/p>\n<p>Tre pratiche fanno la differenza fra una pipeline che &#8220;funziona&#8221; e una che abilita davvero <em>continuous delivery<\/em>:<\/p>\n<ul>\n<li><strong>Trunk-based development<\/strong>: invece di feature branch lunghi alla <em>Git Flow<\/em>, tutti integrano in <code>main<\/code> almeno una volta al giorno, nascondendo feature incomplete dietro feature flag. \u00c8 la pratica pi\u00f9 correlata con punteggi DORA Elite secondo <em>Accelerate<\/em>.<\/li>\n<li><strong>Test automatizzati<\/strong>: piramide classica \u2014 molti unit test alla base, qualche integration test al centro, pochissimi E2E in cima.<\/li>\n<li><strong>Build veloci<\/strong>: una pipeline che impiega 45 minuti viene usata male. Sotto i 10 minuti \u00e8 dove si vince. Cache dipendenze, test paralleli, sottoinsieme legato ai file modificati.<\/li>\n<\/ul>\n<h2>Infrastructure as Code: il provisioning come software<\/h2>\n<p>Configurare manualmente server e servizi cloud \u2014 fosse anche solo via console AWS \u2014 \u00e8 la principale fonte di drift fra ambienti. La risposta DevOps \u00e8 <strong>Infrastructure as Code (IaC)<\/strong>: l&#8217;infrastruttura \u00e8 descritta in file di testo, versionata in Git, applicata da una pipeline.<\/p>\n<p>Strumenti maturi nel 2022: <strong>Terraform<\/strong> (HashiCorp, leader multi-cloud), <strong>Pulumi<\/strong> (infra in TypeScript\/Python\/Go), <strong>AWS CloudFormation<\/strong> e <strong>Azure Bicep<\/strong> (nativi, ma <em>lock-in<\/em>), <strong>Ansible<\/strong> (orientato al <em>configuration management<\/em>).<\/p>\n<p>Il valore non \u00e8 &#8220;scrivere YAML invece che cliccare&#8221;: \u00e8 che ogni modifica passa per una pull request, viene revisionata, lascia traccia e pu\u00f2 essere ricreata altrove con un comando. Per una PMI il caso d&#8217;uso tipico \u00e8 dare a ogni developer la possibilit\u00e0 di tirar su un ambiente di test identico alla produzione in 15 minuti.<\/p>\n<h2>Containerizzazione e GitOps<\/h2>\n<p>I container, popolarizzati da <strong>Docker<\/strong> dal 2013, hanno risolto il vecchio problema &#8220;funziona sulla mia macchina&#8221;. Per orchestrarli lo standard \u00e8 <strong>Kubernetes<\/strong>, nato in Google e donato alla CNCF nel 2015. Per una PMI con pochi servizi Kubernetes pu\u00f2 essere sovradimensionato: alternative ragionevoli sono <strong>Docker Compose<\/strong> + VPS per progetti piccoli, <strong>AWS ECS<\/strong> o <strong>Google Cloud Run<\/strong>, e <strong>k3s<\/strong>\/<strong>k0s<\/strong> per Kubernetes leggero. Quando si fa sul serio, <strong>Helm<\/strong> \u00e8 il package manager standard.<\/p>\n<p>Coniato da <strong>Alexis Richardson<\/strong> di Weaveworks nel 2017, <strong>GitOps<\/strong> \u00e8 un&#8217;evoluzione naturale di IaC + Kubernetes: un repository Git \u00e8 l&#8217;unica fonte di verit\u00e0 sullo stato desiderato, un agente in cluster osserva il repo e riconcilia. I due strumenti dominanti nel 2022 sono <strong>ArgoCD<\/strong> (UI user-friendly) e <strong>Flux<\/strong> (CLI-first, CNCF). Per chi vuole GitOps su Terraform, <strong>Atlantis<\/strong> automatizza <code>plan<\/code> e <code>apply<\/code> dalle pull request.<\/p>\n<p>Il beneficio sulle 4 DORA metrics \u00e8 diretto: deployment frequency aumenta (basta un merge), lead time crolla, change failure rate scende (ogni stato \u00e8 dichiarato e ripristinabile), MTTR si comprime (un <em>rollback<\/em> \u00e8 un <code>git revert<\/code>).<\/p>\n<h2>Feature flags, canary e blue-green: separare deploy da release<\/h2>\n<p>Una delle scoperte controintuitive della cultura DevOps \u00e8 che <strong>deploy<\/strong> (mandare il codice in produzione) e <strong>release<\/strong> (attivare la funzionalit\u00e0 per gli utenti) sono cose diverse. Le <strong>feature flag<\/strong> permettono di rilasciare codice &#8220;spento&#8221;, attivarlo prima per il team interno, poi per l&#8217;1% degli utenti, poi per il 10%, infine per tutti.<\/p>\n<p>Gli strumenti pi\u00f9 usati nel 2022 sono <strong>LaunchDarkly<\/strong> (leader commerciale), <strong>Split.io<\/strong> (forte sull&#8217;analisi esperimenti), <strong>Unleash<\/strong> (open source, self-hosted) e <strong>GrowthBook<\/strong> (OSS, feature flag + A\/B test). Per una PMI italiana il punto di partenza ragionevole \u00e8 Unleash o GrowthBook self-hosted: zero canone.<\/p>\n<p>Le strategie di deploy collegate sono <strong>canary<\/strong> (versione nuova attiva su una piccola percentuale del traffico), <strong>blue-green<\/strong> (due ambienti identici, switch atomico) e <strong>rolling<\/strong> (sostituzione progressiva). Tutte e tre riducono drasticamente il rischio del singolo deploy \u2014 e quindi il <em>change failure rate<\/em>.<\/p>\n<h2>SRE: SLI, SLO e l&#8217;error budget<\/h2>\n<p>La pratica chiamata <strong>Site Reliability Engineering<\/strong>, formalizzata da Google nel libro omonimo del 2016, \u00e8 la cugina ingegneristica del DevOps. Le due culture convergono. Il contributo pi\u00f9 portabile in PMI sono tre concetti:<\/p>\n<ul>\n<li><strong>SLI (Service Level Indicator)<\/strong>: una misura concreta \u2014 es. &#8220;percentuale di richieste HTTP che rispondono in meno di 300ms&#8221;.<\/li>\n<li><strong>SLO (Service Level Objective)<\/strong>: il target \u2014 es. &#8220;il 99,5% delle richieste sotto i 300ms su un mese mobile&#8221;.<\/li>\n<li><strong>SLA (Service Level Agreement)<\/strong>: il contratto esterno verso il cliente, tipicamente pi\u00f9 conservativo dell&#8217;SLO interno.<\/li>\n<\/ul>\n<p>Da SLO + finestra temporale nasce l&#8217;<strong>error budget<\/strong>: se l&#8217;SLO \u00e8 99,5%, hai un budget di &#8220;downtime accettabile&#8221; del 0,5% \u2014 circa 3,6 ore al mese. Finch\u00e9 il budget regge, il team sperimenta e rilascia in fretta. Quando il budget si esaurisce, le priorit\u00e0 si spostano sulla stabilizzazione. \u00c8 un meccanismo elegante per allineare velocit\u00e0 e affidabilit\u00e0 senza scontri politici.<\/p>\n<p>Sulla parte cultura, l&#8217;SRE ha popolarizzato il <strong>post-mortem blameless<\/strong>: dopo ogni incident significativo si scrive un documento che descrive cosa \u00e8 successo, perch\u00e9, come \u00e8 stato risolto e come prevenirlo \u2014 senza puntare il dito su persone.<\/p>\n<h2>Platform engineering: il trend del 2022<\/h2>\n<p>Nel 2022 c&#8217;\u00e8 una conversazione molto attiva nella community DevOps su un&#8217;evoluzione del ruolo: il <strong>Platform Engineering<\/strong>. L&#8217;osservazione di partenza \u00e8 che chiedere a ogni team di prodotto di padroneggiare Kubernetes, Terraform, ArgoCD, Prometheus e mille altri strumenti \u00e8 un costo cognitivo insostenibile.<\/p>\n<p>La risposta \u00e8 creare una <strong>Internal Developer Platform (IDP)<\/strong>: un set di servizi self-service, costruiti da un team di platform engineer, che espongono ai developer di prodotto le primitive \u2014 creare un nuovo servizio, deployare, vedere log \u2014 dietro un&#8217;interfaccia semplice. L&#8217;idea sono i <strong>&#8220;golden paths&#8221;<\/strong>: percorsi raccomandati che fanno la cosa giusta di default, con sicurezza, osservabilit\u00e0 e compliance incluse.<\/p>\n<p>Lo strumento pi\u00f9 discusso \u00e8 <strong>Backstage<\/strong>, 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 &#8220;leggera&#8221; del concetto (uno script che genera lo scaffold di un nuovo microservizio con CI\/CD, monitoring e logging gi\u00e0 configurati) produce benefici enormi.<\/p>\n<h2>DevSecOps e observability<\/h2>\n<p>Spostare la security &#8220;a sinistra&#8221; nella pipeline significa cercare i problemi durante lo sviluppo, non in produzione. Le pratiche concrete: <strong>SAST<\/strong> (analisi statica \u2014 SonarQube, Semgrep, CodeQL), <strong>DAST<\/strong> (scansione dinamica \u2014 OWASP ZAP), <strong>SCA<\/strong> (analisi delle dipendenze open source per CVE \u2014 Snyk, Dependabot, Trivy), <strong>container scanning<\/strong> (Trivy, Clair, Grype), <strong>secret scanning<\/strong> (gitleaks, truffleHog). L&#8217;errore comune \u00e8 trattare la security come gate finale che blocca il deploy: il DevSecOps maturo integra i controlli come <em>step<\/em> della CI con feedback al developer entro 10 minuti.<\/p>\n<p>L&#8217;observability moderna si fonda su tre pilastri \u2014 <strong>metriche<\/strong>, <strong>log<\/strong>, <strong>tracce distribuite<\/strong> \u2014 e su uno stack tipicamente composto da <strong>Prometheus<\/strong>, <strong>Grafana<\/strong>, <strong>Loki<\/strong> e <strong>Tempo<\/strong>\/<strong>Jaeger<\/strong>. Abbiamo trattato lo stack in dettaglio nell&#8217;articolo <a href=\"https:\/\/brentasoft.com\/blog\/microservizi-observability-prometheus-grafana-loki-pmi-2022\/\">Microservizi observability per PMI 2022<\/a>. Per il discorso DORA, due metriche derivate: <strong>MTTD (Mean Time To Detect)<\/strong> e <strong>MTTR<\/strong>. Migliorare il primo \u00e8 la leva diretta sul secondo.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/dashboard-metriche-dora-analytics.jpg\" alt=\"Dashboard con 4 DORA metrics e KPI delivery software\" title=\"Dashboard DORA metrics\" style=\"max-width:100%;height:auto;margin:20px 0;\" \/><\/p>\n<h2>Team Topologies e chaos engineering<\/h2>\n<p>Nel libro <strong>&#8220;Team Topologies&#8221;<\/strong> (Matthew Skelton e Manuel Pais, 2019) viene proposto un linguaggio per descrivere le organizzazioni di sviluppo software. Quattro tipi di team: <strong>stream-aligned<\/strong> (allineato a un flusso di valore di business \u2014 il team &#8220;principale&#8221;), <strong>platform<\/strong> (fornisce servizi internamente), <strong>enabling<\/strong> (aiuta gli altri team a colmare gap di competenza), <strong>complicated subsystem<\/strong> (specialisti su parti tecnicamente complesse). Per le PMI il modello \u00e8 utile soprattutto per capire che il <em>team DevOps separato<\/em> \u00e8 un anti-pattern: o sei un platform team (e fornisci servizi self-service), o sei un enabling team (e ti dissolvi dopo aver insegnato).<\/p>\n<p>Netflix ha inventato il <strong>chaos engineering<\/strong> nel 2011 con <em>Chaos Monkey<\/em>, uno strumento che spegne casualmente istanze EC2 in produzione per costringere ogni servizio a essere resiliente. Nel 2022 il riferimento commerciale \u00e8 <strong>Gremlin<\/strong>, mentre open source ci sono <strong>Litmus<\/strong>, <strong>Chaos Mesh<\/strong>. Per una PMI italiana \u00e8 prematuro finch\u00e9 non c&#8217;\u00e8 una baseline di observability e SLO, ma vale la pena conoscere il principio.<\/p>\n<h2>Errori comuni di implementazione<\/h2>\n<ul>\n<li><strong>Creare un &#8220;team DevOps&#8221; separato<\/strong>: ricrea esattamente il muro che si voleva abbattere. Se serve un team dedicato, sia un platform team con clienti interni chiari.<\/li>\n<li><strong>Tool first, culture second<\/strong>: comprare Jenkins, Kubernetes e ArgoCD senza cambiare le abitudini di code review, branching e ownership produce solo nuovi punti di rottura.<\/li>\n<li><strong>Non misurare le DORA<\/strong>: senza dati ogni discussione diventa di pancia. Tre mesi di numeri spengono il 90% dei dibattiti.<\/li>\n<li><strong>Nessuna golden path<\/strong>: ogni team reinventa il proprio modo di fare CI\/CD, deploy, log. L&#8217;overhead diventa insostenibile.<\/li>\n<li><strong>Test e security come &#8220;blocchi finali&#8221;<\/strong>: spostali a sinistra o saranno sempre il collo di bottiglia.<\/li>\n<li><strong>Ignorare il change failure rate<\/strong>: massimizzare la deployment frequency senza guardare la stabilit\u00e0 \u00e8 auto-sabotaggio.<\/li>\n<\/ul>\n<h2>5 segnali che il tuo team DevOps \u00e8 maturo<\/h2>\n<ol>\n<li><strong>Le 4 DORA metrics sono in dashboard visibile a tutti<\/strong>, non in un foglio personale del CTO.<\/li>\n<li><strong>Ogni deploy in produzione \u00e8 automatico<\/strong> da un merge su <code>main<\/code>, e qualcuno deploya almeno una volta al giorno senza che sia un evento.<\/li>\n<li><strong>I post-mortem sono blameless<\/strong> e producono <em>action item<\/em> tracciati, non lamentele.<\/li>\n<li><strong>La sicurezza \u00e8 un alleato<\/strong> nella pipeline, non un gate finale.<\/li>\n<li><strong>I nuovi sviluppatori sono produttivi in meno di una settimana<\/strong> grazie a documentazione viva, ambienti riproducibili e onboarding automatizzato.<\/li>\n<\/ol>\n<h2>Roadmap di maturit\u00e0 12 mesi per una PMI italiana<\/h2>\n<p><strong>Trimestre 1 \u2014 Fondazioni e misurazione<\/strong>. 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\u00f9 critico.<\/p>\n<p><strong>Trimestre 2 \u2014 Automation del deploy<\/strong>. Deploy automatico in staging su ogni merge in <code>main<\/code>. Test automatizzati al 60-70% sul codice di business. Introduci Terraform per il provisioning dei nuovi ambienti. Prima dashboard DORA condivisa.<\/p>\n<p><strong>Trimestre 3 \u2014 Stabilit\u00e0 e observability<\/strong>. Deploy automatico in produzione (con approvazione manuale se serve). Stack Prometheus + Grafana + Loki online. Primo post-mortem blameless. Feature flag su almeno una funzionalit\u00e0 con rilascio progressivo.<\/p>\n<p><strong>Trimestre 4 \u2014 Platform e scaling<\/strong>. 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 &#8220;Medium&#8221;, una o due in &#8220;High&#8221;.<\/p>\n<p>A questo punto puoi pensare a Backstage, a chaos engineering controllato, a un team di platform engineering. Ma solo a questo punto: l&#8217;ordine conta, perch\u00e9 ogni passo dipende dal precedente.<\/p>\n<div class=\"bs-howto-schema\" style=\"display:none;\">\n{<br \/>\n  &#8220;@context&#8221;: &#8220;https:\/\/schema.org&#8221;,<br \/>\n  &#8220;@type&#8221;: &#8220;HowTo&#8221;,<br \/>\n  &#8220;name&#8221;: &#8220;Come misurare le 4 DORA metrics in una PMI italiana&#8221;,<br \/>\n  &#8220;step&#8221;: [<br \/>\n    {&#8220;@type&#8221;:&#8221;HowToStep&#8221;,&#8221;name&#8221;:&#8221;Estrai la deployment frequency dal CI\/CD&#8221;,&#8221;text&#8221;:&#8221;Conta i job di deploy completati con successo nell&#8217;arco di un mese. Su Jenkins, GitHub Actions o GitLab CI usa l&#8217;API REST.&#8221;},<br \/>\n    {&#8220;@type&#8221;:&#8221;HowToStep&#8221;,&#8221;name&#8221;:&#8221;Calcola il lead time for changes da Git&#8221;,&#8221;text&#8221;:&#8221;Per ogni deploy prendi i commit inclusi e calcola la mediana di (timestamp deploy &#8211; timestamp commit).&#8221;},<br \/>\n    {&#8220;@type&#8221;:&#8221;HowToStep&#8221;,&#8221;name&#8221;:&#8221;Marca gli incident post-deploy&#8221;,&#8221;text&#8221;:&#8221;Nel tuo incident tracker tagga gli incident aperti entro 24h da un deploy. Change failure rate = incident post-deploy \/ deploy totali.&#8221;},<br \/>\n    {&#8220;@type&#8221;:&#8221;HowToStep&#8221;,&#8221;name&#8221;:&#8221;Misura MTTR dagli incident risolti&#8221;,&#8221;text&#8221;:&#8221;Somma le durate (end_at &#8211; start_at) di tutti gli incident del periodo e dividi per il numero degli incident.&#8221;},<br \/>\n    {&#8220;@type&#8221;:&#8221;HowToStep&#8221;,&#8221;name&#8221;:&#8221;Pubblica le metriche in dashboard visibile&#8221;,&#8221;text&#8221;:&#8221;Crea una dashboard accessibile a tutto il team con le 4 metriche aggiornate settimanalmente.&#8221;}<br \/>\n  ]<br \/>\n}\n<\/div>\n<h2>FAQ \u2014 Domande frequenti sulla cultura DevOps<\/h2>\n<div class=\"bs-faq\">\n<h3>Una PMI da 10 developer ha senso che faccia DevOps?<\/h3>\n<p>S\u00ec, \u00e8 il taglio ideale per partire bene. Una PMI piccola non ha il debito organizzativo di una grande azienda e pu\u00f2 iniziare con pratiche moderne dal giorno uno. Le 4 DORA metrics si migliorano anche con un team da 5 persone.<\/p>\n<h3>Devo assumere un DevOps engineer?<\/h3>\n<p>Non necessariamente come primo passo. \u00c8 pi\u00f9 efficace formare i developer esistenti sulle pratiche (CI\/CD, IaC, observability) e introdurre un platform engineer quando i team di prodotto diventano 3-4. &#8220;DevOps engineer&#8221; come singolo ruolo \u00e8 spesso un anti-pattern.<\/p>\n<h3>Quanto costa partire senza tool enterprise?<\/h3>\n<p>Lo stack open source \u00e8 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 \u00e8 il tempo di setup e formazione \u2014 4-8 settimane-uomo per arrivare a una pipeline produttiva.<\/p>\n<h3>Trunk-based development o Git Flow?<\/h3>\n<p>Per la maggior parte dei team la risposta del 2022 \u00e8 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.<\/p>\n<h3>Le DORA metrics si possono &#8220;imbrogliare&#8221;?<\/h3>\n<p>Le 4 metriche sono robuste perch\u00e9 ognuna in isolamento pu\u00f2 essere ottimizzata male, ma insieme no. Forsgren lo dice esplicitamente in Accelerate: tienile tutte e quattro sempre insieme.<\/p>\n<h3>Devo passare a Kubernetes per fare DevOps?<\/h3>\n<p>No. Una PMI con monolite ben fatto su un buon VPS e una pipeline CI\/CD curata pu\u00f2 avere DORA metrics migliori di un team che si \u00e8 sparato Kubernetes prima del tempo.<\/p>\n<h3>Come convinco la direzione a investire in DevOps?<\/h3>\n<p>Mostrale numeri. Misura il <em>lead time<\/em> attuale e il <em>change failure rate<\/em>. Mostra le soglie DORA. Spiega che ogni mese di lead time significa funzionalit\u00e0 ritardate e ricavi rimandati. Non parlare di tool: parla di velocit\u00e0 di delivery e stabilit\u00e0.<\/p>\n<\/div>\n<div class=\"bs-faq-schema\" style=\"display:none;\">\n{<br \/>\n  &#8220;@context&#8221;:&#8221;https:\/\/schema.org&#8221;,<br \/>\n  &#8220;@type&#8221;:&#8221;FAQPage&#8221;,<br \/>\n  &#8220;mainEntity&#8221;:[<br \/>\n    {&#8220;@type&#8221;:&#8221;Question&#8221;,&#8221;name&#8221;:&#8221;Una PMI da 10 developer ha senso che faccia DevOps?&#8221;,&#8221;acceptedAnswer&#8221;:{&#8220;@type&#8221;:&#8221;Answer&#8221;,&#8221;text&#8221;:&#8221;S\u00ec, \u00e8 il taglio ideale per partire bene. Una PMI piccola pu\u00f2 iniziare con pratiche moderne dal giorno uno. Le 4 DORA metrics si migliorano anche con un team da 5 persone.&#8221;}},<br \/>\n    {&#8220;@type&#8221;:&#8221;Question&#8221;,&#8221;name&#8221;:&#8221;Devo assumere un DevOps engineer?&#8221;,&#8221;acceptedAnswer&#8221;:{&#8220;@type&#8221;:&#8221;Answer&#8221;,&#8221;text&#8221;:&#8221;Non necessariamente. \u00c8 pi\u00f9 efficace formare i developer sulle pratiche CI\/CD, IaC, observability e introdurre un platform engineer quando i team di prodotto diventano 3-4.&#8221;}},<br \/>\n    {&#8220;@type&#8221;:&#8221;Question&#8221;,&#8221;name&#8221;:&#8221;Quanto costa partire senza tool enterprise?&#8221;,&#8221;acceptedAnswer&#8221;:{&#8220;@type&#8221;:&#8221;Answer&#8221;,&#8221;text&#8221;:&#8221;Lo stack open source \u00e8 praticamente gratuito a livello licenze. Il costo vero \u00e8 il tempo di setup e formazione: 4-8 settimane-uomo per arrivare a una pipeline produttiva.&#8221;}},<br \/>\n    {&#8220;@type&#8221;:&#8221;Question&#8221;,&#8221;name&#8221;:&#8221;Trunk-based development o Git Flow?&#8221;,&#8221;acceptedAnswer&#8221;:{&#8220;@type&#8221;:&#8221;Answer&#8221;,&#8221;text&#8221;:&#8221;Per la maggior parte dei team la risposta \u00e8 trunk-based development con feature branch di 1-3 giorni e feature flag per il work-in-progress.&#8221;}},<br \/>\n    {&#8220;@type&#8221;:&#8221;Question&#8221;,&#8221;name&#8221;:&#8221;Le DORA metrics si possono imbrogliare?&#8221;,&#8221;acceptedAnswer&#8221;:{&#8220;@type&#8221;:&#8221;Answer&#8221;,&#8221;text&#8221;:&#8221;Prese insieme no. Forsgren in Accelerate raccomanda di tenerle tutte e quattro sempre insieme.&#8221;}},<br \/>\n    {&#8220;@type&#8221;:&#8221;Question&#8221;,&#8221;name&#8221;:&#8221;Devo passare a Kubernetes per fare DevOps?&#8221;,&#8221;acceptedAnswer&#8221;:{&#8220;@type&#8221;:&#8221;Answer&#8221;,&#8221;text&#8221;:&#8221;No. Una PMI con monolite e pipeline CI\/CD curata pu\u00f2 avere DORA metrics migliori di un team che ha adottato Kubernetes prematuramente.&#8221;}},<br \/>\n    {&#8220;@type&#8221;:&#8221;Question&#8221;,&#8221;name&#8221;:&#8221;Come convinco la direzione a investire in DevOps?&#8221;,&#8221;acceptedAnswer&#8221;:{&#8220;@type&#8221;:&#8221;Answer&#8221;,&#8221;text&#8221;:&#8221;Misura il lead time e il change failure rate attuali e confrontali con le soglie DORA. Parla di velocit\u00e0 di delivery e stabilit\u00e0, non di tool.&#8221;}}<br \/>\n  ]<br \/>\n}\n<\/div>\n<div class=\"bs-cta-gradient\" style=\"background:linear-gradient(135deg,#0066cc 0%,#00a8e8 100%);color:#fff;padding:30px;border-radius:12px;margin:30px 0;text-align:center;\">\n<h3 style=\"color:#fff;margin-top:0;\">Vuoi implementare DevOps nella tua PMI senza partire da zero?<\/h3>\n<p style=\"font-size:17px;\">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.<\/p>\n<p><a href=\"https:\/\/brentasoft.com\/preventivatore.php\" style=\"display:inline-block;background:#fff;color:#0066cc;padding:14px 32px;border-radius:8px;text-decoration:none;font-weight:700;font-size:16px;margin-top:10px;\">Richiedi preventivo personalizzato<\/a><\/p>\n<\/div>\n<p>Per approfondire l&#8217;observability che alimenta le 4 metriche DORA, leggi la guida dedicata: <a href=\"https:\/\/brentasoft.com\/blog\/microservizi-observability-prometheus-grafana-loki-pmi-2022\/\">Microservizi observability per PMI 2022: stack Prometheus, Grafana, Loki e Tempo<\/a>. Se invece stai valutando uno stack di automazione gestionale che si appoggi alle stesse pratiche di CI\/CD e IaC, dai un&#8217;occhiata alle <a href=\"https:\/\/brentasoft.com\/soluzioni\/automazione.php\">soluzioni di automazione Brentasoft<\/a> e alle <a href=\"https:\/\/brentasoft.com\/soluzioni\/integrazione-api.php\">integrazioni API<\/a> gi\u00e0 pronte.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>DevOps non \u00e8 un tool: \u00e8 cultura ingegneristica misurabile con 4 metriche DORA. Framework CAMS, come misurare deployment frequency, lead time, change failure rate e MTTR in PMI italiane. Roadmap 12 mesi.<\/p>\n","protected":false},"author":2,"featured_media":2249,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"DevOps PMI 2022: framework + 4 DORA metrics | Brentasoft","_seopress_titles_desc":"DevOps culture per PMI: framework CAMS + 4 DORA metrics (deployment frequency, lead time, change failure rate, MTTR). Guida pratica con roadmap 12 mesi.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"https:\/\/brentasoft.com\/blog\/devops-culture-dora-metrics-pmi-italiane-framework-2022\/","_seopress_social_fb_title":"DevOps culture per PMI italiane: framework + 4 DORA metrics 2022","_seopress_social_fb_desc":"Cultura DevOps misurabile con 4 metriche DORA: come applicarla in una PMI italiana con stack open source e roadmap di 12 mesi.","_seopress_social_fb_img":"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/devops-team-meeting-modern-office.jpg","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"DevOps PMI 2022: framework CAMS + 4 DORA metrics","_seopress_social_twitter_desc":"Guida operativa per misurare deployment frequency, lead time, change failure rate, MTTR in PMI italiane.","_seopress_social_twitter_img":"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/devops-team-meeting-modern-office.jpg","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","footnotes":""},"categories":[7],"tags":[],"class_list":["post-2261","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-trasformazione-digitale"],"_links":{"self":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/2261","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/comments?post=2261"}],"version-history":[{"count":0,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/2261\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media\/2249"}],"wp:attachment":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media?parent=2261"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/categories?post=2261"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/tags?post=2261"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}