El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

D'aquí a sis mesos, algú a Reservalia preguntarà: "ha servit d'alguna cosa tot això?". Si l'equip respon "sí, ara anem molt més ràpid", la conversa es convertirà en una discussió de sensacions. Si respon "el temps des del commit fins a producció ha baixat de 9 dies a 40 minuts i el percentatge de desplegaments que provoquen incident ha passat del 15 % al 3 %", la conversa s'acaba. Aquesta lliçó va d'això: de convertir la qualitat del lliurament de programari en números que es poden verificar. Les mètriques DORA són l'estàndard del sector per fer-ho, i la seva virtut més gran és que només són quatre, es calculen amb dades que el mateix pipeline genera, i no es poden manipular alhora —millorar velocitat espatllant estabilitat es veu immediatament. En acabar sabràs què mesura cadascuna, de quin esdeveniment del pipeline surt la dada, com instrumentar-les sense comprar cap eina, i per què convertir-les en objectius individuals és la manera més ràpida de destruir-ne la utilitat.

Contingut

Què són les mètriques DORA i per què són quatre
Mètrica 1: freqüència de desplegament
Mètrica 2: lead time for changes
Mètrica 3: change failure rate
Mètrica 4: time to restore service
La cinquena mètrica: fiabilitat
Rangs orientatius de rendiment
Com instrumentar-les de manera senzilla
Calcular el lead time amb bash i json
Consultar les mètriques amb SQL
El quadre de comandament inicial de Reservalia
La llei de Goodhart: quan la mètrica es converteix en objectiu
Errors comuns i consells
Exercicis
Conclusió

Què són les mètriques DORA i per què són quatre

DORA són les sigles de DevOps Research and Assessment, el programa de recerca que durant anys ha enquestat desenes de milers de professionals per identificar quines pràctiques distingeixen els equips que lliuren programari millor. La seva aportació més útil i més citada és un conjunt de quatre mètriques que resumeixen el rendiment del lliurament.

L'interessant no és la llista, és la seva estructura. Les quatre s'agrupen en dues parelles que estiren en direccions oposades:

graph TB
    subgraph V["⚡ VELOCITAT - amb quina rapidesa lliurem?"]
        V1["1· Frequencia de desplegament<br/>cada quant arriba alguna cosa a produccio?"]
        V2["2· Lead time for changes<br/>quant triga un canvi a arribar?"]
    end
    subgraph E["🛡️ ESTABILITAT - amb quina qualitat lliurem?"]
        E1["3· Change failure rate<br/>quin percentatge de canvis trenca alguna cosa?"]
        E2["4· Time to restore service<br/>quant triguem a arreglar-ho?"]
    end
    V -.->|"s equilibren"| E
    style V fill:#cfe8ff
    style E fill:#d9f2d9

Aquesta tensió és el que fa que el conjunt sigui difícil de falsejar:

Si només mesuressis velocitat, la manera trivial de "millorar" seria desplegar sense provar res. L'estabilitat s'enfonsaria i es veuria a l'instant.
Si només mesuressis estabilitat, la manera trivial de "millorar" seria no desplegar mai. La velocitat s'enfonsaria i també es veuria.

La troballa central del programa és contraintuïtiva i mereix llegir-se dues vegades: velocitat i estabilitat no s'oposen; van juntes. Els equips que despleguen més sovint també fallen menys i es recuperen abans. La raó la vam veure a la lliçó 01-02: desplegar sovint obliga a lots petits, i els lots petits són més fàcils de verificar, de diagnosticar i de revertir. La por de desplegar produeix lots grans, i els lots grans produeixen incidents. És un cercle, i es pot recórrer en tots dos sentits.

Mètrica 1: freqüència de desplegament

Què mesura. Amb quina freqüència una organització porta codi a producció amb èxit.

2.1. Com es calcula

frequencia de desplegament = nre. de desplegaments reeixits a produccio
                             ──────────────────────────────────────────
                                        periode de temps

Tres precisions que canvien molt el resultat:

Només producció. Els desplegaments a dev i staging no compten. El que mesura la mètrica és quant valor arriba als usuaris.
Només els reeixits. Un desplegament que es reverteix immediatament no compta com a lliurament; comptarà a la mètrica 3.
Per servei desplegable, no per empresa. Si Reservalia desplega api i web per separat, es mesura cadascuna. Sumar serveis de tota l'organització produeix un número gran i sense significat.

2.2. De quin esdeveniment del pipeline surt la dada

Del final del job de desplegament a producció, quan acaba correctament. És la dada més fàcil de capturar de les quatre: n'hi ha prou de registrar una fila cada vegada que un desplegament a prod acaba en verd.

2.3. Què t'explica realment

La freqüència de desplegament és un indicador indirecte de la mida del lot, i per això importa tant. Un equip que desplega un cop cada dues setmanes està acumulant dues setmanes de canvis a cada lliurament, amb tot el que això implica (secció 4 de la lliçó 01-02).

També revela quanta fricció té el procés. Ningú no desplega deu vegades al dia si cada desplegament costa tres hores de feina manual. La freqüència baixa gairebé mai no és una decisió: és un símptoma.

Mètrica 2: lead time for changes

Què mesura. El temps que transcorre des que un canvi es confirma al repositori fins que està funcionant en producció.

És probablement la mètrica més valuosa de les quatre, perquè travessa tot el procés.

3.1. Com es calcula

lead time = data del desplegament a produccio − data del commit

Es calcula per a cada commit i es reporta com a mediana (o percentil 50) del període. Aquí hi ha una decisió metodològica important:

Fes servir la mediana, no la mitjana. Un sol canvi que es va quedar tres mesos en una branca oblidada destrossa la mitjana i no representa res. La mediana t'explica quant triga el canvi típic, que és el que vols saber. El percentil 90 també és útil: t'explica com de dolent és el pitjor cas habitual.

3.2. De quin esdeveniment del pipeline surt la dada

De dos esdeveniments, i per això és la mètrica que més gent calcula malament:

Extrem	On és la dada	Com s'obté
Inici	Metadades del commit a Git	`git show -s --format=%cI <sha>`
Fi	Registre del desplegament a producció	Marca de temps del job de desplegament

L'error habitual és mesurar des que arrenca el pipeline en comptes de des del commit. Això mesura el rendiment del pipeline (útil, però és una altra cosa) i amaga precisament el que sol ser el problema: el temps d'espera. A Reservalia, el pipeline trigaria 8 minuts, però el canvi espera fins a 9 dies al divendres. Si mesures des de l'arrencada del pipeline, el teu lead time és de 8 minuts i t'estaries enganyant.

3.3. Un matís sobre commits i desplegaments

Un desplegament sol incloure diversos commits. El lead time es calcula per commit: cadascun dels commits inclosos al desplegament rep la mateixa data de fi, però té la seva pròpia data d'inici.

gantt
    title Lead time de tres commits desplegats junts
    dateFormat YYYY-MM-DD HH:mm
    axisFormat %d/%m %H:%M
    section Commits
    commit a3f9c21 (lead time 26 h) :a1, 2026-03-13 09:00, 26h
    commit b7e2d10 (lead time 5 h)  :a2, 2026-03-14 06:00, 5h
    commit c1d4a55 (lead time 1 h)  :a3, 2026-03-14 10:00, 1h

Tots tres es despleguen a les 11:00 del 14 de març, però els seus lead times són molt diferents. La mediana d'aquests tres seria 5 hores.

3.4. Què t'explica realment

El lead time descompon el procés. Quan és alt, el diagnòstic consisteix a preguntar-se on se'n va el temps:

Tram	Què l'allarga	On s'ataca al curs
Commit → pipeline arrencat	Res, si el trigger és automàtic	02-07
Pipeline de verificació	Conjunt lent, sense paral·lelisme, sense memòria cau	04-04
Pipeline → revisió aprovada	Revisions lentes, PR massa grans	02-07
Merge → desplegament disponible	Manca d'automatització del desplegament	03-02
Desplegament disponible → producció	Finestres de desplegament, aprovacions lentes, por	03-01, 03-04

A la immensa majoria d'equips, el tram dominant és l'últim. I aquest no s'arregla comprant runners més ràpids.

Mètrica 3: change failure rate

Què mesura. El percentatge de desplegaments a producció que provoquen una degradació del servei i requereixen una intervenció correctiva immediata (rollback, correcció urgent, pedaç).

4.1. Com es calcula

change failure rate = desplegaments que van causar una fallada × 100
                      ─────────────────────────────────────────────
                            total de desplegaments a produccio

4.2. La part difícil: definir "fallada"

Aquesta és la mètrica més subjectiva de les quatre, i el seu valor depèn completament que l'equip acordi una definició abans de començar a mesurar i no la canviï després. Una definició operativa raonable per a Reservalia:

Un desplegament compta com a fallit si, com a conseqüència directa, passa alguna d'aquestes coses:

Es va haver de revertir.
Es va haver de desplegar una correcció urgent fora del flux normal en les hores següents.
Es va degradar el servei de manera perceptible per als usuaris (errors, lentitud greu, funcionalitat trencada).
Es va haver d'activar un feature flag d'emergència per desactivar el que s'havia desplegat.

No compta com a fallit:

Una fallada detectada a staging i que no va arribar mai a producció. Això és el sistema funcionant.
Un bug que feia tres mesos que era en producció i es descobreix ara: no l'ha causat aquest desplegament.
Una caiguda d'un proveïdor extern no relacionada amb el canvi.

Escriviu aquesta definició al repositori. Sense ella, la mètrica es torna inservible tan bon punt hi hagi un cas ambigu i algú decideixi sobre la marxa.

4.3. De quin esdeveniment del pipeline surt la dada

Aquesta és l'única dada de les quatre que no surt automàticament del pipeline: requereix una decisió humana. Les fonts pràctiques són:

Un rollback automàtic disparat per les mètriques: es registra sol (03-05).
Un desplegament marcat a mà com a fallit per qui gestiona l'incident.
La vinculació entre l'incident i el desplegament que el va causar, feta al post mortem.

El més pràctic és una ordre o un botó que la Nuria pugui fer servir durant l'incident:

# Marcar l ultim desplegament de produccio com a fallit.
# L executa qui gestiona l incident, mentre el gestiona.
./scripts/marcar-desplegament-fallit.sh \
  --desplegament dep_2026_0314_1042 \
  --motiu "error 500 en crear cites despres del canvi d esquema" \
  --detectat-el "2026-03-14T11:05:00+01:00"

Si registrar la fallada costa més de trenta segons, ningú no ho farà durant una crisi i les teves dades seran falses.

4.4. Què t'explica realment

Un change failure rate alt apunta a forats concrets en la verificació: proves insuficients, entorn de staging que no s'assembla a producció, o lots massa grans. Un valor sospitosament baix (0 % sostingut) sol significar que no s'està registrant, no que no falla res.

Mètrica 4: time to restore service

Què mesura. Quant triga l'organització a restablir el servei quan es produeix una degradació o caiguda en producció.

5.1. Com es calcula

time to restore = data de restabliment del servei − data d inici de l incident

Es reporta com a mediana dels incidents del període.

Compte amb els dos extrems:

Inici de l'incident: quan el problema va començar a afectar els usuaris, no quan algú se'n va adonar. Si el servei va estar trencat 25 minuts abans que truqués un client, aquests 25 minuts compten. Mesurar des de la detecció premia tenir mal monitoratge, que és exactament l'incentiu contrari al desitjable.
Restabliment: quan els usuaris tornen a estar bé, no quan s'entén la causa arrel. Un rollback restableix el servei encara que ningú no sàpiga encara què va passar. L'anàlisi ve després.

5.2. De quin esdeveniment surt la dada

De la gestió de l'incident: hora d'inici i hora de resolució. Idealment, l'hora d'inici l'aporta el monitoratge automàtic (matèria de 03-06) i no la memòria de ningú.

5.3. Què t'explica realment

És, juntament amb la freqüència, la mètrica que millora més ràpid en automatitzar. A Reservalia avui, restablir significa recompilar i tornar a pujar per SFTP: al voltant d'una hora. Amb artefactes immutables a ECR, restablir és redesplegar la imatge anterior: minuts.

Aquesta mètrica captura una idea profunda de DevOps: no es pot evitar que les fallades passin; sí que es pot fer que durin poc. Un equip que falla el 5 % de les vegades però es recupera en 4 minuts ofereix un servei molt millor que un que falla el 2 % i triga 6 hores.

La cinquena mètrica: fiabilitat

A les quatre clàssiques s'hi va afegir després una cinquena: la fiabilitat (reliability). És diferent de les anteriors en la seva naturalesa i per això convé explicar-la a part.

Què mesura. Fins a quin punt el servei compleix les expectatives dels seus usuaris quant a disponibilitat, latència i correcció.

Les quatre primeres mesuren el procés de lliurament; la cinquena mesura el resultat operatiu. És la que impedeix una fallada de raonament temptadora: un equip pot tenir les quatre mètriques en verd i, tot i així, oferir un servei dolent —lent, amb funcionalitat correcta però inservible, o caigut fora dels moments que compten com a "incident".

No té una fórmula única. S'instrumenta mitjançant objectius de nivell de servei (SLO) definits pel mateix equip. Per a Reservalia, tres de raonables:

Objectiu de nivell de servei	Llindar	Per què aquest
Disponibilitat de l'API	≥ 99,9 % mensual en horari comercial	Una caiguda a les 4 de la matinada molesta menys que una a les 11:00 d'un dissabte
Latència de creació de cita	percentil 95 < 800 ms	Si reservar és lent, el client final abandona
Èxit de l'enviament de recordatoris	≥ 99,5 % enviats a la finestra correcta	Un recordatori que no arriba és una cita perduda per al negoci

Fixa't en el matís del primer: "en horari comercial". Una plataforma de reserves per a perruqueries i clíniques es juga el seu valor entre les 9:00 i les 20:00. Un objectiu de disponibilitat pla ignora això. Definir bé un SLO consisteix precisament a capturar el que de debò importa a l'usuari.

Les eines per mesurar això —observabilitat, quadres de comandament i alertes— es veuen a la lliçó 03-06.

Rangs orientatius de rendiment

El programa DORA classifica els equips en quatre nivells. Aquests són els rangs orientatius:

Mètrica	Baix	Mitjà	Alt	Elit
Freqüència de desplegament	Menys d'un cop al mes	Entre un cop al mes i un cop a la setmana	Entre un cop a la setmana i un cop al dia	Sota demanda, diverses vegades al dia
Lead time for changes	Més d'un mes	Entre una setmana i un mes	Entre un dia i una setmana	Menys d'un dia
Change failure rate	Alt (al voltant del 40 % o més)	Moderat (al voltant del 20-30 %)	Moderat-baix (al voltant del 15 %)	Baix (al voltant del 5 % o menys)
Time to restore service	Més d'una setmana	Entre un dia i una setmana	Menys d'un dia	Menys d'una hora

7.1. Advertiment imprescindible sobre aquesta taula

Aquests rangs són referències per orientar-te, no objectius que s'hagin de perseguir a cegues. Quatre raons concretes:

Els llindars es mouen. Cada edició de l'informe reajusta les fronteres. El que fa uns anys era "elit" avui és "alt". Perseguir una etiqueta és perseguir un objectiu mòbil.
El context ho canvia tot. Un equip que desenvolupa programari mèdic certificat no desplegarà mai diverses vegades al dia, i això no el converteix en un mal equip: el converteix en un equip que compleix la normativa del seu sector. Comparar un SaaS amb un sistema d'aviònica no té sentit.
Comparar equips amb aquestes etiquetes és tòxic. Serveixen per comparar-te amb tu mateix al llarg del temps. En el moment en què es fan servir per a rànquings interns entre equips, comença la manipulació de dades (secció 12).
"Elit" no és l'objectiu correcte per a tothom. Per a Reservalia, passar de desplegar un cop a la setmana a fer-ho un cop al dia seria una transformació enorme. Fixar-se "diverses vegades al dia" com a meta inicial només produeix frustració.

La pregunta correcta no és "en quin nivell som?" sinó "anem millor que fa tres mesos?".

Com instrumentar-les de manera senzilla

No cal comprar cap eina. N'hi ha prou de registrar un esdeveniment per desplegament i un altre per incident. Amb això es calculen tres de les quatre mètriques directament, i la quarta amb una marca manual.

8.1. El model de dades mínim

-- Tot el necessari per a les metriques DORA cap en dues taules.

CREATE TABLE desplegaments (
  id                TEXT PRIMARY KEY,        -- dep_2026_0314_1042
  servei            TEXT NOT NULL,           -- 'api' | 'web'
  entorn            TEXT NOT NULL,           -- 'dev' | 'staging' | 'prod'
  commit_sha        TEXT NOT NULL,
  commit_data       TIMESTAMPTZ NOT NULL,    -- ← inici del lead time
  desplegat_el      TIMESTAMPTZ NOT NULL,    -- ← fi del lead time
  resultat          TEXT NOT NULL,           -- 'exit' | 'fallada_pipeline'
  fallit            BOOLEAN NOT NULL DEFAULT false,  -- ← change failure rate
  motiu_fallada     TEXT,
  commits_inclosos  INTEGER NOT NULL DEFAULT 1,
  pipeline_url      TEXT
);

CREATE TABLE incidents (
  id               TEXT PRIMARY KEY,
  servei           TEXT NOT NULL,
  inici            TIMESTAMPTZ NOT NULL,   -- quan va comencar a AFECTAR usuaris
  restablert       TIMESTAMPTZ,            -- NULL mentre continui obert
  desplegament_id  TEXT REFERENCES desplegaments(id),  -- si el va causar un desplegament
  severitat        TEXT NOT NULL           -- 'critica' | 'alta' | 'mitjana'
);

Dues decisions de disseny que convé entendre:

commit_data es desa a la taula, en comptes de consultar-la a Git cada vegada. Els repositoris es reescriuen, les branques s'esborren i les consultes a Git són lentes. Desar la dada en el moment del desplegament la congela.
desplegament_id a incidents és opcional. No tots els incidents els causa un desplegament (pot caure un proveïdor). Aquesta relació és justament la que permet calcular el change failure rate sense contaminar-lo amb incidents aliens.

8.2. On s'omple cada camp

flowchart LR
    A["Job de desplegament<br/>a prod acaba OK"] -->|"INSERT"| B[("taula desplegaments")]
    C["El monitoratge detecta<br/>degradacio"] -->|"INSERT"| D[("taula incidents")]
    E["La Nuria marca el<br/>desplegament culpable"] -->|"UPDATE fallit=true"| B
    F["Servei restablert"] -->|"UPDATE restablert"| D
    B --> G["📊 Quadre de comandament<br/>4 metriques"]
    D --> G

Calcular el lead time amb bash i json

Vegem el mecanisme concret, pas a pas. Primer, obtenir els dos extrems.

9.1. Les dades de partida

#!/usr/bin/env bash
# registrar-desplegament.sh
# S executa com a ULTIM pas del job de desplegament a produccio.
set -euo pipefail   # -e: avorta si alguna cosa falla | -u: error si hi ha variable no definida
                    # -o pipefail: una fallada en una canonada no passa desapercebuda

SHA="$(git rev-parse HEAD)"

# Data del COMMIT, en format ISO 8601 amb zona horaria.
# %cI = "committer date, strict ISO 8601". Es l inici del lead time.
COMMIT_DATA="$(git show -s --format=%cI "$SHA")"

# Data del DESPLEGAMENT: ara mateix, en UTC. Es el fi del lead time.
DESPLEGAMENT_DATA="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

echo "Commit     : $SHA"
echo "Commitejat : $COMMIT_DATA"
echo "Desplegat  : $DESPLEGAMENT_DATA"

Per què ISO 8601 amb zona horària. Un 2026-03-14 10:22 sense zona és ambigu: hora de Barcelona, UTC, del runner? Amb canvis d'hora pel mig, aquesta ambigüitat produeix lead times negatius o d'una hora de més. Treballa sempre en UTC internament i converteix només en mostrar.

9.2. Calcular la diferència

# Convertim totes dues dates a segons des de l epoca Unix i restem.
# Aixo elimina d una revolada els problemes de zones horaries i mesos.
COMMIT_EPOCH="$(date -d "$COMMIT_DATA" +%s)"
DESPLEGAMENT_EPOCH="$(date -d "$DESPLEGAMENT_DATA" +%s)"

LEAD_TIME_SEG=$(( DESPLEGAMENT_EPOCH - COMMIT_EPOCH ))
LEAD_TIME_MIN=$(( LEAD_TIME_SEG / 60 ))
LEAD_TIME_H=$(( LEAD_TIME_SEG / 3600 ))

echo "Lead time: ${LEAD_TIME_SEG}s = ${LEAD_TIME_MIN} min = ${LEAD_TIME_H} h"

Un exemple amb números reals:

# Commit    : 2026-03-13T09:00:00+01:00  → epoch 1773388800
# Desplegat : 2026-03-14T11:00:00Z       → epoch 1773486000
# Diferencia: 97200 segons = 1620 minuts = 27 hores

9.3. Construir el registre en JSON

# Generem l esdeveniment com a JSON. jq garanteix un escapament correcte:
# construir JSON concatenant cadenes amb cometes es una font classica
# de fitxers corruptes tan bon punt un missatge de commit porta cometes.
jq -n \
  --arg id          "dep_$(date -u +%Y%m%d_%H%M%S)" \
  --arg servei      "api" \
  --arg entorn      "prod" \
  --arg sha         "$SHA" \
  --arg commit_d    "$COMMIT_DATA" \
  --arg despl_d     "$DESPLEGAMENT_DATA" \
  --argjson lead    "$LEAD_TIME_SEG" \
  --argjson commits "$(git rev-list --count "${SHA_ANTERIOR}..${SHA}")" \
  '{
     id:               $id,
     servei:           $servei,
     entorn:           $entorn,
     commit_sha:       $sha,
     commit_data:      $commit_d,
     desplegat_el:     $despl_d,
     lead_time_segons: $lead,
     commits_inclosos: $commits,
     resultat:         "exit",
     fallit:           false
   }' > desplegament.json

cat desplegament.json

Resultat:

{
  "id": "dep_20260314_110000",
  "servei": "api",
  "entorn": "prod",
  "commit_sha": "a3f9c21e4b7d8f012345678901234567890abcde",
  "commit_data": "2026-03-13T09:00:00+01:00",
  "desplegat_el": "2026-03-14T11:00:00Z",
  "lead_time_segons": 97200,
  "commits_inclosos": 3,
  "resultat": "exit",
  "fallit": false
}

9.4. Calcular el lead time de cada commit del desplegament

Recorda la secció 3.3: un desplegament inclou diversos commits i cadascun té el seu propi lead time. Aquest script els calcula tots:

#!/usr/bin/env bash
# lead-time-per-commit.sh <sha_desplegat_anterior> <sha_actual>
set -euo pipefail

SHA_ANTERIOR="$1"    # el que hi havia en produccio
SHA_ACTUAL="$2"      # el que acabem de desplegar
ARA_EPOCH="$(date -u +%s)"

# git rev-list llista tots els commits entre tots dos punts.
# --format=%H|%cI dona: hash|data ISO. --no-commit-header evita linies extra.
git rev-list --format="%H|%cI" --no-commit-header "${SHA_ANTERIOR}..${SHA_ACTUAL}" \
| while IFS='|' read -r sha data; do
    commit_epoch="$(date -d "$data" +%s)"
    lead_min=$(( (ARA_EPOCH - commit_epoch) / 60 ))
    printf '%s  %s  lead_time=%d min\n' "${sha:0:7}" "$data" "$lead_min"
  done

Sortida d'exemple:

c1d4a55  2026-03-14T10:00:00+01:00  lead_time=60 min
b7e2d10  2026-03-14T06:00:00+01:00  lead_time=300 min
a3f9c21  2026-03-13T09:00:00+01:00  lead_time=1620 min

Tres commits, tres lead times molt diferents. La mediana és 300 minuts (5 hores). La mitjana seria 660 minuts, molt distorsionada pel commit antic: exactament el motiu pel qual es fa servir la mediana.

Consultar les mètriques amb SQL

Amb la taula desplegaments poblada, les mètriques són consultes de poques línies.

10.1. Freqüència de desplegament

-- Desplegaments reeixits a produccio, per setmana, del servei 'api'.
SELECT
  date_trunc('week', desplegat_el) AS setmana,
  COUNT(*)                         AS desplegaments
FROM desplegaments
WHERE entorn    = 'prod'
  AND servei    = 'api'
  AND resultat  = 'exit'
  AND desplegat_el >= now() - interval '12 weeks'
GROUP BY setmana
ORDER BY setmana;

  setmana   | desplegaments
------------+---------------
 2026-01-05 |             1
 2026-01-12 |             1
 2026-01-19 |             0
 2026-01-26 |             2      ← una correcció urgent a més del divendres

El patró d'"1 per setmana" delata immediatament el ritual del divendres de Reservalia.

10.2. Lead time (mediana i percentil 90)

-- Mediana i P90 del lead time, en hores, per mes.
SELECT
  date_trunc('month', desplegat_el) AS mes,
  ROUND(
    PERCENTILE_CONT(0.5) WITHIN GROUP (
      ORDER BY EXTRACT(EPOCH FROM (desplegat_el - commit_data))
    ) / 3600.0, 1
  ) AS lead_time_mediana_h,
  ROUND(
    PERCENTILE_CONT(0.9) WITHIN GROUP (
      ORDER BY EXTRACT(EPOCH FROM (desplegat_el - commit_data))
    ) / 3600.0, 1
  ) AS lead_time_p90_h,
  COUNT(*) AS n
FROM desplegaments
WHERE entorn = 'prod' AND resultat = 'exit'
GROUP BY mes
ORDER BY mes;

Explicació de la consulta, per a qui no hagi vist PERCENTILE_CONT:

desplegat_el - commit_data dona un interval; EXTRACT(EPOCH FROM ...) el converteix a segons.
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY ...) calcula la mediana d'aquests segons.
Es divideix entre 3600 per passar-ho a hores.
S'inclou COUNT(*) sempre: una mediana calculada sobre 2 desplegaments no significa res, i sense el recompte no ho sabries.

10.3. Change failure rate

-- Percentatge de desplegaments a produccio que van provocar una fallada, per mes.
SELECT
  date_trunc('month', desplegat_el)                          AS mes,
  COUNT(*)                                                   AS total,
  COUNT(*) FILTER (WHERE fallit)                             AS fallits,
  ROUND(100.0 * COUNT(*) FILTER (WHERE fallit) / COUNT(*), 1) AS pct_fallada
FROM desplegaments
WHERE entorn = 'prod' AND resultat = 'exit'
GROUP BY mes
ORDER BY mes;

    mes     | total | fallits | pct_fallada
------------+-------+---------+-------------
 2026-01-01 |     5 |       1 |        20.0
 2026-02-01 |     4 |       0 |         0.0
 2026-03-01 |     4 |       1 |        25.0

Fixa't en el WHERE resultat = 'exit': el denominador són els desplegaments que van arribar a producció. Un pipeline que falla abans de desplegar no és un canvi fallit: és el sistema protegint-te.

10.4. Time to restore service

-- Mediana del temps de restabliment, en minuts, per trimestre.
SELECT
  date_trunc('quarter', inici) AS trimestre,
  COUNT(*)                     AS incidents,
  ROUND(
    PERCENTILE_CONT(0.5) WITHIN GROUP (
      ORDER BY EXTRACT(EPOCH FROM (restablert - inici))
    ) / 60.0, 1
  ) AS restauracio_mediana_min
FROM incidents
WHERE restablert IS NOT NULL      -- nomes incidents ja tancats
  AND severitat IN ('critica', 'alta')
GROUP BY trimestre
ORDER BY trimestre;

10.5. Les quatre d'un cop d'ull

-- Quadre de comandament: les quatre metriques del darrer trimestre.
WITH finestra AS (
  SELECT * FROM desplegaments
  WHERE entorn = 'prod' AND resultat = 'exit'
    AND desplegat_el >= now() - interval '90 days'
)
SELECT
  'Frequencia de desplegament' AS metrica,
  ROUND(COUNT(*) / 12.85, 2) || ' per setmana' AS valor
FROM finestra
UNION ALL
SELECT
  'Lead time (mediana)',
  ROUND(PERCENTILE_CONT(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (desplegat_el - commit_data))
  ) / 3600.0, 1) || ' h'
FROM finestra
UNION ALL
SELECT
  'Change failure rate',
  ROUND(100.0 * COUNT(*) FILTER (WHERE fallit) / NULLIF(COUNT(*), 0), 1) || ' %'
FROM finestra
UNION ALL
SELECT
  'Time to restore (mediana)',
  ROUND(PERCENTILE_CONT(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (restablert - inici))
  ) / 60.0, 1) || ' min'
FROM incidents
WHERE restablert IS NOT NULL AND inici >= now() - interval '90 days';

El NULLIF(COUNT(*), 0) evita una divisió per zero quan no hi ha desplegaments a la finestra: un detall petit que provoca errors reals en quadres de comandament els mesos tranquils.

El quadre de comandament inicial de Reservalia

La Marta ha dedicat una tarda a reconstruir les dades del darrer trimestre a partir de l'historial de Git, del canal de l'equip i de les notes de les incidències. Aquest és el punt de partida mesurat —el número més important de tot el curs, perquè és contra el qual compararem tota la resta:

Mètrica	Reservalia avui	Nivell orientatiu	D'on surt la dada
Freqüència de desplegament	1,1 per setmana	Mitjà	14 desplegaments a prod en 13 setmanes
Lead time for changes (mediana)	6,2 dies	Mitjà	Mediana de 47 commits desplegats al trimestre
Change failure rate	14 %	Alt	2 de 14 desplegaments van provocar incidència greu
Time to restore service (mediana)	68 minuts	Alt	Mediana de les 2 incidències greus
Fiabilitat (disponibilitat en horari comercial)	99,4 %	Per sota del seu objectiu (99,9 %)	Registres (log) del balancejador

I aquests són els objectius que l'equip es fixa per al final del curs:

Mètrica	Avui	Objectiu	Palanca principal	Mòdul
Freqüència de desplegament	1,1 / setmana	≥ 5 / setmana	Eliminar la finestra del divendres; desplegament automatitzat	3
Lead time (mediana)	6,2 dies	< 4 hores	Suprimir l'espera; CI ràpida; desplegament automàtic a staging	2 i 3
Change failure rate	14 %	< 5 %	Proves automatitzades a cada PR; lots petits; canari	2 i 3
Time to restore	68 min	< 10 min	Artefactes immutables; rollback en una ordre; alertes	3
Disponibilitat comercial	99,4 %	≥ 99,9 %	Desplegament sense tall; healthchecks; múltiples instàncies	3

Tres observacions sobre aquests objectius que convé interioritzar:

1. Cap no persegueix l'etiqueta "elit". Reservalia no s'ha proposat desplegar vint vegades al dia. S'ha proposat cinc vegades per setmana, que per a ells és una transformació radical i, sobretot, assolible. Un objectiu que l'equip no creu possible no motiva: desmoralitza.

2. Els objectius són de l'equip, no de persones. És "el lead time de Reservalia", no "el lead time d'en Diego". Hi tornarem ara mateix.

3. Van acompanyats de la palanca concreta. Una mètrica sense una acció associada és un termòmetre sense medicina. Cada objectiu apunta al mòdul on es treballa.

graph LR
    subgraph AVUI["📍 Punt de partida"]
        H1["1,1 desplegaments/setmana"]
        H2["6,2 dies de lead time"]
        H3["14 % de fallades"]
        H4["68 min de restauracio"]
    end
    subgraph MOD["🔧 El curs"]
        M2["Modul 2<br/>CI: proves i artefactes"]
        M3["Modul 3<br/>CD: desplegament i rollback"]
        M4["Modul 4<br/>Optimitzacio i seguretat"]
    end
    subgraph META["🎯 Objectiu"]
        O1["≥5 desplegaments/setmana"]
        O2["<4 h de lead time"]
        O3["<5 % de fallades"]
        O4["<10 min de restauracio"]
    end
    AVUI --> MOD --> META
    style AVUI fill:#ffe8e8
    style META fill:#e8ffe8

La llei de Goodhart: quan la mètrica es converteix en objectiu

Hi ha una manera infal·lible de destruir el valor de tot l'anterior, i és tan comuna que mereix la seva pròpia secció.

Llei de Goodhart: "Quan una mesura es converteix en objectiu, deixa de ser una bona mesura."

El mecanisme és sempre el mateix: si d'una mètrica en depenen l'avaluació d'exercici, el bonus o el prestigi d'algú, aquella persona optimitzarà la mètrica —que és més fàcil que optimitzar la realitat que la mètrica pretenia representar.

12.1. Com es manipula cada mètrica DORA

Mètrica	Si es converteix en objectiu individual…	Conseqüència real
Freqüència de desplegament	Es trossegen canvis artificialment en deu desplegaments buits; es desplega el mateix codi dues vegades	El número puja, no arriba més valor a l'usuari, i el soroll dificulta diagnosticar incidents
Lead time	Es fan commits just abans de fusionar per "reiniciar" el rellotge; es treballa en local setmanes sense fer commit	La dada millora i el temps real de lliurament empitjora, perquè les branques viuen més
Change failure rate	Es reclassifiquen incidents com a "manteniment programat"; es deixa de registrar el que és dubtós	Les dades deixen de ser reals i es perd la capacitat de detectar problemes
Time to restore	Es declara el servei restablert abans que ho estigui; es retarda l'obertura de l'incident	Els usuaris continuen patint i el quadre de comandament és verd

Fixa't en el cas del lead time: és especialment pervers perquè la manipulació empitjora activament el procés. El desenvolupador que evita fer commit per no "començar el rellotge" està fent just el contrari de la Integració Contínua.

12.2. Regles per fer servir les mètriques sense destruir-les

Mai a nivell individual. Són mètriques de sistema, no de persona. "El lead time de l'equip de Reservalia", mai "el lead time d'en Diego". El lead time depèn de la velocitat de les revisions, del procés d'aprovació, de la durada del pipeline i de la finestra de desplegament: gairebé res d'això no està sota el control d'una sola persona.
Mai per comparar equips. Un equip que manté un legacy crític tindrà sempre pitjors números que un que comença un producte nou, i això no diu res sobre la seva competència. Cada equip es compara amb si mateix.
Mai lligades a retribució o avaluació. És el camí més curt a dades falses. Tan bon punt el bonus depèn del número, el número deixa de descriure la realitat.
Sempre les quatre juntes. És la protecció estructural. Trossejar desplegaments per pujar la freqüència empitjora el change failure rate; no fer commits per baixar el lead time redueix la freqüència. Mirant les quatre, les manipulacions es delaten.
Com a eina de diagnòstic, no de judici. L'ús correcte és: "el nostre lead time és de 6 dies; esbrinem on se'n va el temps". L'incorrecte és: "el nostre lead time és de 6 dies; s'ha de millorar aquest trimestre", sense analitzar-ne la causa.
Mira la tendència, no el valor absolut. Una lectura aïllada no diu gairebé res. Dotze setmanes de dades diuen molt.

12.3. Un antídot pràctic

Quan presentis les mètriques, acompanya-les sempre de la pregunta "què ens impedeix millorar això?" en comptes de "per què està malament això?". La primera obre una conversa tècnica i produeix accions; la segona produeix excuses i, a mitjà termini, dades manipulades.

Errors Comuns i Consells

Error 1: mesurar el lead time des que arrenca el pipeline. És l'error més freqüent i el que més enganya, perquè produeix números excel·lents. Mesura des de la data del commit; si no, amagues justament el temps d'espera, que sol ser el problema principal.

Error 2: fer servir la mitjana en comptes de la mediana. Un canvi que es va quedar dos mesos en una branca oblidada distorsiona la mitjana completament. La mediana descriu el cas típic. Afegeix el percentil 90 si vols saber com de dolent és el pitjor cas habitual.

Error 3: comptar els desplegaments a staging. Només compta el que arriba als usuaris. És una manera temptadora d'inflar la freqüència de desplegament sense que arribi més valor a ningú.

Error 4: no acordar per escrit què és una "fallada". Sense una definició explícita al repositori, cada persona classificarà els casos dubtosos a la seva manera i la mètrica deixarà de ser comparable en el temps. Acordeu-la abans de començar a mesurar.

Error 5: perseguir l'etiqueta "elit". Els llindars canvien cada any i depenen del context. L'única comparació que importa és amb tu mateix fa tres mesos.

Error 6: muntar el quadre de comandament abans de tenir el pipeline. És temptador començar pel que és visual. Però sense desplegaments automatitzats no hi ha esdeveniments per registrar, i acabaràs omplint dades a mà, que és exactament on es generen les dades falses. Registra primer, visualitza després.

Error 7: mesurar sense tenir línia base. Si comences a mesurar després d'automatitzar, no podràs demostrar la millora. Reconstruir el trimestre anterior a partir de l'historial de Git i les notes d'incidències, com va fer la Marta, és una tarda de feina ben invertida.

Consell 1: registra l'esdeveniment de desplegament des del primer pipeline. És una taula i una consulta INSERT al final del job. Cinc minuts de feina que, sis mesos després, valen una conversa sencera amb direcció.

Consell 2: desa el SHA i la data del commit al mateix artefacte. Etiquetar la imatge amb el SHA i afegir la data com a etiqueta de metadades fa que l'artefacte sigui autodescriptiu: sempre podràs saber quina versió és i quan es va escriure, encara que la branca ja no existeixi.

Consell 3: revisa les mètriques en equip, un cop al mes, sense direcció al davant. L'objectiu de la reunió és identificar colls d'ampolla, no retre comptes. Tan bon punt es percep com una avaluació, les dades comencen a degradar-se.

Consell 4: complementa les quatre amb alguna cosa qualitativa. Una pregunta trimestral a l'equip —"de l'1 al 5, quanta confiança tens en desplegar a producció?"— captura una cosa que cap de les quatre no mesura i que sol anticipar els problemes abans que apareguin als números.

Exercicis

Exercici 1: calcular les quatre mètriques

Aquestes són les dades reals del darrer mes d'una altra empresa, Citalia. Calcula'n les quatre mètriques DORA i classifica-les orientativament.

Desplegaments a producció (mes de març, 30 dies):

ID	Commit	Data del commit	Data del desplegament	Va provocar fallada?
d1	`aaa1111`	2026-03-02 09:00	2026-03-05 17:00	No
d2	`bbb2222`	2026-03-04 14:00	2026-03-05 17:00	No
d3	`ccc3333`	2026-03-06 11:00	2026-03-12 17:00	Sí
d4	`ddd4444`	2026-03-12 18:00	2026-03-12 19:30	No (correcció urgent)
d5	`eee5555`	2026-03-10 10:00	2026-03-19 17:00	No
d6	`fff6666`	2026-03-18 16:00	2026-03-19 17:00	No
d7	`ggg7777`	2026-03-20 09:00	2026-03-26 17:00	Sí
d8	`hhh8888`	2026-03-26 18:00	2026-03-26 20:00	No (correcció urgent)

Incidents:

ID	Inici (va començar a afectar)	Detectat	Restablert
i1	2026-03-12 17:20	2026-03-12 18:05	2026-03-12 19:35
i2	2026-03-26 17:10	2026-03-26 17:25	2026-03-26 20:05

Calcula: freqüència de desplegament (per setmana), lead time medià (en hores), change failure rate i time to restore medià. Després, respon: quin patró revelen aquestes dades sobre com treballa Citalia?

Exercici 2: detectar manipulació de mètriques

El nou director de tecnologia de Citalia ha establert que el bonus trimestral de cada desenvolupador dependrà del "seu" lead time individual i de la "seva" freqüència de desplegament. Tres mesos després, el quadre de comandament mostra:

Freqüència de desplegament: d'1,9 a 11,3 per setmana. 🎉
Lead time medià: de 4,1 dies a 3,2 hores. 🎉
Change failure rate: del 25 % al 31 %. 😐
Time to restore medià: de 145 min a 210 min. 😟
Els desenvolupadors comenten que ara fan la major part de la feina en local i només fan commit al final.
El nombre mitjà de commits per desplegament ha baixat de 4,2 a 1,1, però el nombre de línies canviades per desplegament no ha baixat.

Respon:

Han millorat de debò? Justifica-ho amb les dades.
Quin comportament concret explica cada xifra?
Quina és la dada que delata la manipulació de manera més clara?
Què hauries fet en comptes de lligar el bonus a les mètriques?

Exercici 3: instrumentar Reservalia

Dissenya la instrumentació mínima perquè Reservalia comenci a mesurar avui, abans de tenir cap pipeline.

Quins esdeveniments cal registrar com a mínim i en quin moment exacte de cada procés?
Escriu la consulta SQL que doni el lead time medià en hores de les últimes 8 setmanes per al servei api en producció.
Reservalia desplega api i web juntes en el mateix acte. S'ha de registrar com un desplegament o com dos? Argumenta les dues postures i decideix.
El primer mes només hi haurà uns 5 desplegaments. Quina precaució cal prendre en interpretar les mètriques amb tan poques dades?

Solucions

Solució a l'Exercici 1

Freqüència de desplegament

8 desplegaments ÷ 30 dies × 7 dies = 1,87 desplegaments per setmana

→ Nivell mitjà (entre un cop al mes i un cop a la setmana, fregant l'alt).

Lead time per desplegament

ID	Commit	Desplegament	Lead time
d1	03-02 09:00	03-05 17:00	80 h
d2	03-04 14:00	03-05 17:00	27 h
d3	03-06 11:00	03-12 17:00	150 h
d4	03-12 18:00	03-12 19:30	1,5 h
d5	03-10 10:00	03-19 17:00	223 h
d6	03-18 16:00	03-19 17:00	25 h
d7	03-20 09:00	03-26 17:00	152 h
d8	03-26 18:00	03-26 20:00	2 h

Ordenats: 1,5 · 2 · 25 · 27 · 80 · 150 · 152 · 223

Amb 8 valors, la mediana és la mitjana dels dos centrals (4t i 5è):

mediana = (27 + 80) / 2 = 53,5 hores ≈ 2,2 dies

→ Nivell alt (entre un dia i una setmana).

Compara-ho amb la mitjana: (1,5+2+25+27+80+150+152+223) / 8 = 82,6 h. Un 55 % més alta, arrossegada pels dos valors extrems. Això il·lustra per què es fa servir la mediana.

Change failure rate

2 desplegaments fallits (d3 i d7) ÷ 8 desplegaments × 100 = 25 %

→ Nivell mitjà.

Nota important: d4 i d8 són les correccions urgents, no les fallades. No es compten com a fallits —ells van arreglar el problema—, però sí que compten al denominador com a desplegaments realitzats. Comptar-los també com a fallits duplicaria el problema a la mètrica.

Time to restore service

i1: 03-12 19:35 − 03-12 17:20 = 135 minuts
i2: 03-26 20:05 − 03-26 17:10 = 175 minuts
mediana = (135 + 175) / 2 = 155 minuts ≈ 2,6 hores

→ Nivell alt (menys d'un dia).

Un detall que calia notar: la columna "Detectat" no es fa servir. El temps es compta des que l'incident comença a afectar els usuaris. Si es mesurés des de la detecció, i1 donaria 90 minuts en comptes de 135 —i Citalia s'estaria premiant per tenir mal monitoratge.

Quin patró revelen les dades?

Un patró molt clar i molt recognoscible:

Despleguen els dijous a les 17:00. d1, d2, d3, d5, d6 i d7 són tots dijous a les 17:00. Tenen una finestra de desplegament setmanal, exactament el mateix antipatró que Reservalia amb els seus divendres.
El 25 % dels seus desplegaments són correccions urgents (d4 i d8), i totes dues passen el mateix dia que un desplegament fallit, poques hores després. És a dir: la finestra setmanal genera lots grans, els lots grans trenquen producció, i cal sortir d'urgència fora de la finestra.
La finestra és la causa del lead time alt. Fixa't en el contrast: els desplegaments dins de la finestra tenen lead times de 25 a 223 hores; les correccions urgents, d'1,5 i 2 hores. Tècnicament poden desplegar en 90 minuts. La resta del temps és espera pura, autoimposada pel procés.
Els dos incidents són conseqüència de desplegaments. El seu problema no és la infraestructura: és com lliuren.

Conclusió del diagnòstic: la palanca de millora número u de Citalia no és comprar eines ni escriure més tests. És eliminar la finestra setmanal dels dijous. Aquest únic canvi atacaria alhora el lead time, la mida del lot i el change failure rate.

Solució a l'Exercici 2

1. Han millorat de debò?

No. Han millorat les dues mètriques de velocitat (les que afecten el bonus) i han empitjorat les dues d'estabilitat (les que no). Aquest patró exacte —velocitat amunt, estabilitat avall— és la signatura clàssica de la manipulació, i és justament el que el conjunt de quatre mètriques està dissenyat per revelar.

Recorda la troballa central de la secció 1: en una millora real, velocitat i estabilitat milloren juntes. Quan divergeixen en direccions oposades, no estàs veient una millora: estàs veient com s'optimitza l'indicador a costa del que l'indicador havia de representar.

2. Quin comportament explica cada xifra

Xifra	Comportament que la produeix
Freqüència ×6	Es trossegen els canvis en desplegaments artificials perquè cada desenvolupador acumuli desplegaments propis
Lead time de 4,1 dies a 3,2 h	Es treballa en local durant dies i es fa commit just abans de fusionar: el rellotge comença tard. El temps real de lliurament no ha baixat; només ha baixat la part que es mesura
Change failure rate 25 % → 31 %	Més desplegaments sense més verificació; i, sobretot, codi que ha estat dies sense integrar-se (integration hell de 01-01) arriba de cop
Time to restore 145 → 210 min	Amb més desplegaments fragmentats i menys integració, diagnosticar què va trencar què és més difícil. A més, ningú no té incentiu a restaurar ràpid: no puntua

3. La dada que delata la manipulació

El nombre de commits per desplegament baixa de 4,2 a 1,1 mentre les línies canviades per desplegament es mantenen.

Aquesta dada és demolidora i mereix aturar-s'hi. Si els lots fossin realment més petits, totes dues xifres haurien baixat: menys commits i menys línies per desplegament. Que les línies no baixin significa que s'està lliurant la mateixa quantitat de canvi, empaquetada en menys commits. És a dir: la gent acumula feina en local i la deixa anar en un únic commit gegant just abans de fusionar.

Això és exactament el contrari de la Integració Contínua, i explica de manera coherent les quatre xifres alhora: branques més longeves → integració més tardana → més conflictes i menys verificació → més fallades → diagnòstics més lents.

4. Què s'hauria d'haver fet

No lligar mai les mètriques a la retribució ni a l'avaluació individual. És la regla que s'ha trencat i de la qual es deriva tota la resta.
Mesurar a nivell d'equip o de servei, mai de persona. El lead time depèn de la velocitat de les revisions, dels processos d'aprovació i de la finestra de desplegament: gairebé res d'això no ho controla un individu.
Fer servir les mètriques per diagnosticar, no per jutjar. L'anàlisi de l'exercici 1 mostrava que el problema de Citalia era la finestra setmanal dels dijous. L'acció correcta era eliminar-la, no repartir bonus.
Presentar sempre les quatre juntes. Si el quadre de comandament del director hagués mostrat les quatre des del principi, la divergència hauria saltat a la vista a la primera revisió mensual.
Fixar objectius de sistema, no de persona. "Reduir el lead time de l'equip per sota de 8 hores eliminant la finestra de desplegament" és un objectiu accionable i compartit. "Que cada desenvolupador baixi el seu lead time" no ho és.

Solució a l'Exercici 3

1. Esdeveniments mínims i moment exacte

Esdeveniment	Quan es registra exactament	Camps imprescindibles
Desplegament a producció	Com a últim pas del procés de desplegament, només si ha acabat amb èxit	`id`, `servei`, `entorn`, `commit_sha`, `commit_data`, `desplegat_el`, `commits_inclosos`
Marca de desplegament fallit	Durant l'incident, tan bon punt s'identifica el desplegament culpable	`desplegament_id`, `fallit = true`, `motiu`
Obertura d'incident	Quan es determina l'hora en què va començar a afectar els usuaris (no la de detecció)	`id`, `servei`, `inici`, `severitat`, `desplegament_id` si escau
Tancament d'incident	Quan el servei torna a funcionar per als usuaris (no quan s'entén la causa)	`restablert`

Detall crític: commit_data s'ha de capturar en el moment del desplegament amb git show -s --format=%cI, no consultar-se després. Les branques s'esborren i els historials es reescriuen.

Mentre no existeixi pipeline, aquests esdeveniments es registren a mà amb un script de dues línies executat per qui desplega. No és elegant, però produeix dades reals des d'avui, que és el que importa.

2. Consulta SQL

SELECT
  ROUND(
    PERCENTILE_CONT(0.5) WITHIN GROUP (
      ORDER BY EXTRACT(EPOCH FROM (desplegat_el - commit_data))
    ) / 3600.0, 1
  ) AS lead_time_mediana_hores,
  COUNT(*) AS n_desplegaments        -- imprescindible per saber si la dada val
FROM desplegaments
WHERE servei      = 'api'
  AND entorn      = 'prod'
  AND resultat    = 'exit'
  AND desplegat_el >= now() - interval '8 weeks';

El COUNT(*) no és opcional: una mediana calculada sobre 5 desplegaments no s'ha de presentar igual que una calculada sobre 200.

3. Un desplegament o dos?

A favor de registrar-lo com a dos (un per servei):

És el que recomana el marc DORA: la unitat de mesura és el servei desplegable.
Permet veure si un servei evoluciona diferent de l'altre (per exemple, si la web es desplega més sovint quan s'independitzin).
Si en el futur se separen —cosa molt probable—, la sèrie històrica continua sent comparable.

A favor de registrar-lo com a un:

Reflecteix la realitat actual: avui no es poden desplegar per separat, així que dues files suggereixen una independència que no existeix.
Duplicaria artificialment la freqüència de desplegament, i faria que Reservalia semblés el doble de ràpida del que és.

Decisió: registrar dues files, una per servei, però amb un camp grup_desplegament comú que les vinculi. Així es conserva la granularitat per servei per al futur i, alhora, es pot calcular la freqüència comptant grups diferents en comptes de files, sense inflar el número. És l'opció que no destrueix informació i que no enganya.

-- Frequencia REAL de desplegament (actes de desplegament, no files)
SELECT COUNT(DISTINCT grup_desplegament) FROM desplegaments
WHERE entorn = 'prod' AND resultat = 'exit';

4. Precaucions amb poques dades

Amb 5 desplegaments, la mediana és molt inestable. Un sol valor extrem la desplaça completament. No prenguis decisions basant-te en la variació d'un mes a un altre.
El change failure rate és especialment enganyós. Amb 5 desplegaments, cada fallada val un 20 %: passar de 0 % a 20 % sona a catàstrofe i és un sol incident. Amb aquests volums, és més informatiu reportar el nombre absolut ("1 de 5") que el percentatge.
Fes servir finestres més llargues. Amb poc volum, agrega per trimestre en comptes de per setmana, o fes servir mitjanes mòbils de 90 dies.
Mostra sempre la mida de la mostra al costat de cada mètrica. Un quadre de comandament que diu "change failure rate: 20 %" sense dir "(1 de 5)" convida a conclusions equivocades.
Fixa't en la tendència, no en el valor puntual. Amb poques dades, la direcció del moviment al llarg de diversos mesos és molt més fiable que qualsevol xifra concreta.
I una cosa tranquil·litzadora: a mesura que Reservalia avanci al curs, la freqüència de desplegament pujarà, i amb ella el volum de dades. Les mètriques es tornen més fiables precisament a mesura que el procés millora.

Conclusió

Amb aquesta lliçó tanquem el mòdul d'introducció, i ho fem amb el que probablement sigui l'eina més pràctica de tot el mòdul:

Les quatre mètriques DORA —freqüència de desplegament, lead time for changes, change failure rate i time to restore service— resumeixen el rendiment del lliurament en dues parelles que s'equilibren: velocitat i estabilitat. La seva gran virtut és que no es poden manipular alhora.
La troballa que canvia la manera de pensar: velocitat i estabilitat van juntes. Desplegar més sovint obliga a lots petits, i els lots petits fallen menys i es diagnostiquen abans.
La cinquena mètrica, la fiabilitat, mesura el resultat operatiu mitjançant objectius de nivell de servei propis de cada equip, i evita el miratge de tenir les quatre en verd amb un servei dolent.
Cada dada surt d'un esdeveniment concret: la freqüència i el lead time, del job de desplegament i de la data del commit; el change failure rate, d'una marca humana durant l'incident; el time to restore, de la gestió de l'incident. Tot cap en dues taules i unes poques consultes SQL: no cal comprar res.
Els rangs de rendiment són referències que es mouen cada any i depenen del context. L'única comparació que importa és amb tu mateix fa tres mesos.
Reservalia ja té la seva línia base mesurada: 1,1 desplegaments per setmana, 6,2 dies de lead time, 14 % de canvis fallits i 68 minuts de restauració. I els seus objectius per al final del curs: 5 desplegaments setmanals, menys de 4 hores, menys del 5 % i menys de 10 minuts.
I l'advertiment que sosté tota la resta: la llei de Goodhart. Tan bon punt una mètrica es converteix en objectiu individual —lligat a avaluacions o bonus—, deixa de descriure la realitat. Són mètriques de sistema, serveixen per diagnosticar, i es miren les quatre juntes.

Amb això acaba el mòdul 1. Ja saps què són la Integració Contínua, el Lliurament Continu i el Desplegament Continu i en què es diferencien; coneixes els beneficis reals i els costos que ningú no menciona; tens el mapa de l'ecosistema d'eines i saps per què farem servir GitHub Actions; coneixes a fons Reservalia, el seu equip, el seu repositori i la seva infraestructura de destinació; i tens el quadre de comandament que ens dirà, d'aquí a set mòduls, si tot això ha servit d'alguna cosa.

S'ha acabat la teoria. Al mòdul 2, Integració Contínua (CI), comencem a construir: la primera lliçó, Introducció a la Integració Contínua, estableix les regles de treball de l'equip —què és la branca principal, quant pot viure una branca, què passa quan la build es posa vermella— i a la lliçó 02-02 escriurem, per fi, el primer flux de treball real de Reservalia. En Diego deixarà de compilar al seu portàtil: a partir d'aquí, cada canvi es verifica sol, en una màquina neta, abans que ningú el fusioni.

Mètriques DORA: Com es Mesura el Lliurament de Programari