Misurare la Piattaforma: perchè le Metriche Contano
Una Internal Developer Platform senza metriche e come un'auto senza cruscotto: puoi guidarla, ma non sai a che velocità vai, quanto carburante hai o se il motore sta per surriscaldarsi. Le metriche sono fondamentali per capire se la piattaforma sta generando valore, identificare colli di bottiglia e guidare le decisioni di investimento.
In questo articolo esploreremo i due framework più autorevoli per misurare la performance del software delivery e la developer experience: DORA metrics e SPACE framework. Vedremo come implementare dashboard concrete e come usare i dati per il miglioramento continuo.
Cosa Imparerai
- Le 4 metriche DORA: deployment frequency, lead time, MTTR, change failure rate
- Il framework SPACE: Satisfaction, Performance, Activity, Communication, Efficiency
- Come raccogliere dati da GitHub, GitLab, Kubernetes e CI/CD
- Benchmarking: confronto con elite, high, medium e low performers
- Implementazione pratica di dashboard Grafana per DORA metrics
- Trappole da evitare: vanity metrics, gaming e correlation vs causation
Le 4 Metriche DORA
Le metriche DORA (DevOps Research and Assessment) sono il risultato di anni di ricerca condotta da Nicole Forsgren, Jez Humble e Gene Kim, documentata nel libro "Accelerate". Queste 4 metriche sono riconosciute come i migliori indicatori della performance del software delivery:
- Deployment Frequency (DF): quanto spesso l'organizzazione deploya in produzione. Gli elite performers deployano on-demand, multiple volte al giorno
- Lead Time for Changes (LT): il tempo dal primo commit di codice al deploy in produzione. Gli elite performers hanno lead time inferiori a un'ora
- Mean Time to Recovery (MTTR): il tempo medio per ripristinare il servizio dopo un incidente. Gli elite performers recuperano in meno di un'ora
- Change Failure Rate (CFR): la percentuale di deployment che causano un fallimento in produzione. Gli elite performers hanno un CFR del 0-15%
# DORA Metrics: benchmarking table
dora-benchmarks:
deployment-frequency:
elite: "On-demand (multiple deploys/day)"
high: "Between once per day and once per week"
medium: "Between once per week and once per month"
low: "Between once per month and once every 6 months"
lead-time-for-changes:
elite: "Less than one hour"
high: "Between one day and one week"
medium: "Between one week and one month"
low: "Between one month and six months"
mean-time-to-recovery:
elite: "Less than one hour"
high: "Less than one day"
medium: "Between one day and one week"
low: "More than six months"
change-failure-rate:
elite: "0-15%"
high: "16-30%"
medium: "16-30%"
low: "16-30%"
# Target per la nostra piattaforma
platform-targets:
current-state:
deployment-frequency: "weekly"
lead-time: "3 days"
mttr: "4 hours"
change-failure-rate: "22%"
6-month-target:
deployment-frequency: "daily"
lead-time: "4 hours"
mttr: "1 hour"
change-failure-rate: "10%"
Il Framework SPACE
Mentre le metriche DORA si focalizzano sulla performance del delivery, il framework SPACE offre una vista più ampia della developer experience. Proposto da Nicole Forsgren, Margaret-Anne Storey e altri ricercatori, SPACE misura cinque dimensioni:
- Satisfaction and well-being: quanto gli sviluppatori sono soddisfatti del proprio lavoro e degli strumenti a disposizione
- Performance: l'output e l'impatto del lavoro degli sviluppatori (qualità del codice, affidabilità dei servizi)
- Activity: il volume di attivita (commit, PR, review, deploy) come indicatore di engagement
- Communication and collaboration: la qualità della comunicazione e collaborazione nel team e tra team
- Efficiency and flow: la capacità degli sviluppatori di lavorare senza interruzioni e blocchi
L'aspetto chiave di SPACE e che nessuna singola metrica racconta la storia completa. E necessario combinare metriche da almeno 3 delle 5 dimensioni per avere una comprensione accurata della developer experience.
Attenzione alle Vanity Metrics
Misurare il numero di linee di codice scritte, il numero di commit o le ore lavorate sono vanity metrics che non dicono nulla sulla produttività reale. Peggio ancora, possono incentivare comportamenti sbagliati (codice verboso, commit atomici artificiali, presenza vs produttività). Concentrati su metriche che misurano outcome, non output.
Data Collection e Strumentazione
Raccogliere le metriche DORA e SPACE richiede l'integrazione con molteplici fonti dati:
- Git (GitHub/GitLab API): commit timestamps, PR creation/merge times, branch lifecycle
- CI/CD (GitHub Actions, GitLab CI): pipeline duration, success/failure rates, deployment timestamps
- Kubernetes API: deployment rollout status, pod restarts, resource utilization
- Incident management (PagerDuty, OpsGenie): incident creation, acknowledgment, resolution times
- Survey tools: developer satisfaction surveys (quarterly NPS, pulse surveys)
# Prometheus: regole per calcolo DORA metrics
groups:
- name: dora-metrics
interval: 5m
rules:
# Deployment Frequency: deployment al giorno per servizio
- record: dora:deployment_frequency:daily
expr: |
sum by (service) (
increase(
deployment_total{environment="production"}[24h]
)
)
# Lead Time: tempo medio dal commit al deploy (in ore)
- record: dora:lead_time_hours:avg
expr: |
avg by (service) (
deployment_lead_time_seconds{environment="production"}
) / 3600
# Change Failure Rate: % deployment falliti
- record: dora:change_failure_rate:ratio
expr: |
sum by (service) (
increase(
deployment_total{environment="production",status="failed"}[30d]
)
)
/
sum by (service) (
increase(
deployment_total{environment="production"}[30d]
)
)
# MTTR: tempo medio di recovery (in minuti)
- record: dora:mttr_minutes:avg
expr: |
avg by (service) (
incident_resolution_time_seconds{severity=~"critical|high"}
) / 60
# Alert se MTTR supera il target
- alert: HighMTTR
expr: dora:mttr_minutes:avg > 60
for: 5m
labels:
severity: warning
annotations:
summary: "MTTR per {{ $labels.service }} supera 60 minuti"
Dashboard Grafana per DORA
Una dashboard Grafana dedicata alle DORA metrics fornisce visibilità in tempo reale sulla performance del software delivery. Le visualizzazioni chiave includono:
- Deployment Frequency: grafico a barre giornaliero/settimanale con trend line
- Lead Time: grafico a linee con percentili (p50, p90, p99) e target
- MTTR: gauge che mostra il valore corrente rispetto al target, con storico
- Change Failure Rate: pie chart con percentuale e trend mensile
- DORA Score complessivo: semaforo che indica il livello di performance (elite, high, medium, low)
La dashboard dovrebbe essere accessibile a tutti i team, non solo al platform team. La trasparenza sulle metriche incentiva il miglioramento e crea una cultura data-driven.
Feedback Loops: Da Metriche a Miglioramenti
Le metriche hanno valore solo se guidano azioni concrete. Il ciclo di feedback per il miglioramento continuo della piattaforma include:
- Collect: raccolta automatica di metriche quantitative e feedback qualitativo
- Analyze: identificazione di trend, anomalie e correlazioni
- Prioritize: classifica dei miglioramenti in base a impatto e sforzo
- Implement: esecuzione dei miglioramenti prioritizzati
- Measure: verifica che i miglioramenti abbiano l'effetto desiderato
# Feedback loop: processo trimestrale di review
quarterly-platform-review:
week-1-collect:
- pull DORA metrics from Prometheus/Grafana
- run developer satisfaction survey (NPS + open questions)
- collect support ticket analytics
- review incident postmortems
week-2-analyze:
- compare metrics with previous quarter
- identify top 5 developer pain points from survey
- correlate support tickets with platform areas
- benchmark against industry standards
week-3-prioritize:
- impact-effort matrix for improvement initiatives
- align with business priorities
- estimate ROI for top initiatives
- present to engineering leadership
week-4-plan:
- create platform roadmap for next quarter
- define OKRs for platform team
- communicate plan to all engineering teams
- set metric targets for next quarter
Trappole da Evitare
Le metriche sono strumenti potenti, ma possono anche essere dannose se usate in modo sbagliato:
- Gaming: quando le metriche sono usate per valutare le performance individuali, le persone le manipolano. Le DORA metrics devono misurare il sistema, non le persone
- Correlation vs causation: il fatto che due metriche si muovano insieme non significa che una causi l'altra
- Over-measurement: tracciare troppe metriche crea rumore e confusion. Meglio 5 metriche ben comprese che 50 ignorate
- Metric fixation: ottimizzare una singola metrica a scapito di tutto il resto (es. aumentare deployment frequency senza curarsi della qualità)
Principio Fondamentale
Le metriche devono illuminare, non giudicare. Usale per capire dove la piattaforma può migliorare, non per valutare la produttività dei singoli sviluppatori. Una cultura basata sulla fiducia e la trasparenza e il prerequisito per trarre valore dalle metriche.