Qué son las métricas DORA: Velocidad y estabilidad DevOps

Qué son las métricas DORA: Midiendo la velocidad y estabilidad del despliegue

Las métricas DORA son cinco medidas del rendimiento de entrega de software: tiempo de cambio, frecuencia de despliegue, tiempo de recuperación ante fallos de despliegue, tasa de cambios fallidos y tasa de retrabajos de despliegue. Las primeras tres describen el throughput, las últimas dos describen la estabilidad. En conjunto, te dicen qué tan rápido llegan los cambios a producción y con qué frecuencia esos cambios generan problemas. Cuando se usan bien, apuntan el cuello de botella. Cuando se usan mal, se convierten en un boletín de calificaciones que tu equipo aprende a falsear.

De dónde vienen los números, y por qué la terminología se quedó

Un líder de plataforma está en una revisión trimestral. El CTO hace una sola pregunta: ¿Estamos entregando más rápido que hace un año y rompemos menos? Sin vocabulario compartido, la respuesta es un montón de anécdotas. Las métricas DORA existen para reemplazar las anécdotas con cuatro o cinco números que puedas obtener de sistemas que ya estás ejecutando.

El nombre proviene de DevOps Research and Assessment, el programa de investigación que pasó años encuestando equipos de ingeniería y correlacionando sus prácticas de entrega con resultados organizacionales. Ahora es parte de Google Cloud, y los hallazgos se publican cada año. El libro Accelerate popularizó las cuatro métricas originales. El marco se ha revisado desde entonces, y esa revisión importa más de lo que la mayoría de los posts admite.

Aquí está la parte que se pierde: las métricas nunca fueron pensadas como un ranking. Surgieron de un hallazgo estadístico. Los equipos que puntuaban bien en velocidad también puntuaban bien en estabilidad. Velocidad y seguridad no eran un tradeoff, se movían juntas. Ese es un reclamo sobre correlación entre muchos equipos, no una meta para el tuyo.

Las cinco métricas, definidas como un ingeniero on-call las definiría

Las definiciones actuales se dividen en dos grupos. Léelas con un servicio específico en mente, porque cada definición se desmorona si la aplicas a "la empresa".

Tiempo de cambio (Lead Time). El tiempo desde que un commit entra en main hasta que ese commit se ejecuta en producción. No desde que se abre el ticket, y no desde que se aprueba el pull request. Desde commit a prod. Si tu pipeline tarda cuarenta minutos y tu release train sale los jueves, tu lead time está dominado por los jueves.

Frecuencia de despliegue. Qué tan seguido despliegas a producción. Puedes contar despliegues en un período o medir el espacio entre ellos. Un servicio que despliega once veces al día y un servicio que despliega una vez al mes son animales diferentes, y promediarlos oculta ambos.

Tiempo de recuperación ante fallos. Cuánto tarda en recuperarse cuando un despliegue causa un problema que requiere intervención. Solía llamarse tiempo medio de reparación, y el cambio de nombre es deliberado. Solo cuenta incidentes causados por tu propio cambio, no un apagón del proveedor cloud un martes.

Tasa de cambios fallidos. La parte de despliegues que requieren intervención inmediata después: un rollback, un hotfix, un fix hacia adelante enviado a toda velocidad. Diez despliegues, dos de ellos revertidos, una tasa de cambios fallidos del veinte por ciento.

Tasa de retrabajos. La parte de despliegues que son no planificados, desencadenados por un incidente en producción en lugar de trabajo de roadmap. Esta es la adición más nueva, y captura algo que la tasa de cambios fallidos se pierde: el equipo que nunca revierte pero gasta media semana desplegando patches de emergencia.

Throughput versus estabilidad: por qué nunca lees una métrica sola

Las primeras tres métricas son throughput. Las últimas dos son estabilidad. La agrupación es todo el punto.

Si solo vigilas throughput, celebrarás un equipo que despliega cuarenta veces al día y silenciosamente revierte una cuarta parte de ellos. Si solo vigilas estabilidad, recompensarás un equipo que envía una vez al mes con un historial impecable, porque nadie cambia nada. Cada métrica tiene una forma barata de mejorarla que empeora el sistema.

Frecuencia de despliegue sube cuando divides un deploy en cinco deploys vacíos. Tasa de cambios fallidos baja cuando dejas de contar los hotfixes como fallos. El lead time se reduce cuando redefines cuándo empieza el reloj. Esta es la ley de Goodhart en acción: cuando una medida se convierte en objetivo, deja de ser una buena medida. La guía oficial la lista primero entre sus advertencias, y es la que más duele.

Entonces la regla de trabajo es en pares. Lee lead time junto a tasa de cambios fallidos. Lee frecuencia de despliegue junto a tasa de retrabajos. Un movimiento en una dirección sin una historia coincidente en la otra es una señal de mirar más de cerca, no una victoria que anunciar.

Los benchmarks circulan en cada deck de vendedor, y son una trampa. El patrón reportado de recientes reportes DORA es consistente en forma: el cluster más fuerte de equipos despliega on-demand, con un lead time bajo un día, y se recupera de un despliegue fallido en menos de una hora. El cluster más lento se sienta en el rango de semanas a meses en ambos.

Esas cifras son útiles para una cosa: calibrar tu intuición sobre qué es posible. Son pobres como objetivos. Un servicio de pagos con una puerta de auditoría obligatoria no coincidirá con un sitio de marketing, y no debería intentarlo. La orientación oficial es explícita en que debes comparar solo aplicaciones o servicios similares, y que debes apuntar a mejorar contra tu propia línea base en lugar de competencia entre equipos.

Comienza con tu propia mediana. Mídela durante un mes antes de establecer cualquier objetivo. El primer número casi siempre es vergonzoso, y eso está bien. Una línea base que te avergüenza es una línea base en la que realmente puedes confiar.

Cómo instrumentarlas sin construir una data platform

La mayoría de los equipos sobrecargan esto. No necesitas un proyecto de warehouse. Necesitas cuatro timestamps y una bandera.

Los timestamps: commit fusionado a main, build terminado, despliegue iniciado en producción, despliegue terminado. La bandera: si el despliegue fue revertido posteriormente, parcheado o seguido de un deploy no planificado dentro de una ventana definida.

Aquí hay un sketch mínimo en TypeScript. Toma una lista de registros de despliegue y devuelve los números que importan.

type Deploy = {
  service: string;
  committedAt: Date;
  deployedAt: Date;
  failed: boolean;       // reverted, hotfixed, or manual intervention
  unplanned: boolean;    // triggered by an incident, not by roadmap work
  recoveredAt?: Date;    // set when failed is true
};

const median = (xs: number[]) => {
  const s = [...xs].sort((a, b) => a - b);
  return s.length ? s[Math.floor(s.length / 2)] : 0;
};

export function doraSummary(deploys: Deploy[], days: number) {
  const leadHours = deploys.map(
    d => (d.deployedAt.getTime() - d.committedAt.getTime()) / 36e5,
  );
  const failures = deploys.filter(d => d.failed);
  const recoveryMins = failures
    .filter(d => d.recoveredAt)
    .map(d => (d.recoveredAt!.getTime() - d.deployedAt.getTime()) / 6e4);

  return {
    leadTimeHoursP50: median(leadHours),
    deploysPerDay: deploys.length / days,
    changeFailRate: failures.length / Math.max(deploys.length, 1),
    recoveryMinutesP50: median(recoveryMins),
    reworkRate: deploys.filter(d => d.unplanned).length / Math.max(deploys.length, 1),
  };
}

Dos decisiones en ese snippet llevan el peso. Primero, usa la mediana, no el promedio. Una mala semana con una recuperación de tres días destrozará un promedio y no te dirá nada sobre un martes típico. Segundo, calcula todo por servicio. Agrega a un equipo o departamento solo después de que hayas mirado los servicios debajo.

La parte difícil no es el código. La parte difícil es la bandera failed. Alguien tiene que decidir qué cuenta como un fallo, escribirlo, y aplicarlo de la misma forma cada vez. Si tu incident tracker vincula incidentes al despliegue que los causó, obtienes esto casi gratis. Si no, empieza ahí.

La pregunta de herramientas viene después de la pregunta de datos. Ya posees la mayoría de los datos brutos. Tu host de Git tiene tiempos de commit. Tu CI tiene eventos de build y despliegue. Tu herramienta de incidentes tiene los fallos. El trabajo es uniéndolos en un identificador de despliegue compartido.

Las plataformas de observabilidad son un lugar natural para superponer marcadores de despliegue sobre tasas de error y latencia, para que puedas ver cuál deploy precedió cuál pico.

Si prefieres mantener el stack abierto y autohospedado, una capa de dashboard sobre tu propia base de datos de eventos de despliegue hace el mismo trabajo a menor costo, con más fontanería de tu lado.

También hay una categoría de herramientas que lee tus repositorios e historial de entrega y expone el riesgo, como hotspots donde el code churn y los defectos pasados se agrupan. No reemplazará los cuatro timestamps, pero explica por qué un servicio tiene una alta tasa de cambios fallidos cuando sus vecinos no.

Una advertencia sobre comprar algo aquí. Un dashboard que muestre los números no es lo mismo que un equipo que actúe sobre ellos. Si nadie posee el gráfico de tiempo de recuperación, comprar un gráfico más bonito no cambia nada.

Las palancas que realmente mueven cada número

Las métricas son un diagnóstico. El tratamiento está en otro lado, y es diferente para cada una.

Para lead time, mira la espera, no el trabajo. Extrae una docena de cambios recientes y marca dónde cada uno estaba inactivo: esperando revisión, esperando un slot de build, esperando una ventana de release. En la mayoría de los equipos el tiempo inactivo supera el tiempo de codificación varias veces. Pulls requests más pequeños y una expectativa de nivel de servicio de revisión vencen cualquier ajuste de pipeline.

Para frecuencia de despliegue, la palanca es el tamaño de lote. Los cambios más pequeños son más fáciles de revisar, más fáciles de razonar, y más fáciles de revertir. El desarrollo trunk-based y las feature flags existen para dejarte fusionar trabajo inacabado de forma segura, que es cómo desacloplas deployar de releaser.

Para tasa de cambios fallidos, la palanca es cuánto del blast radius puedes ver antes de que sea toda la flota. Un rollout que expone el uno por ciento del tráfico, vigila una tasa de error contra un SLO, y se detiene en una brecha convierte un incidente potencial en un no-evento. Esa es la brecha entre un despliegue fallido y un cambio fallido que nadie fuera del equipo notó.

Para tiempo de recuperación, la palanca es el revert. Si el fix más rápido es rollback, entonces el tiempo de recuperación es qué tan rápido detectas el problema más qué tan rápido presionas el botón. Automatizar el revert en un threshold reduce el humano de los primeros diez minutos. A las 3am eso importa más que cualquier runbook.

Para tasa de retrabajos, la palanca es upstream. Un número alto significa que los incidentes están generando despliegues. Mira qué servicios producen los patches de emergencia, y lee sus post-mortems como un conjunto en lugar de uno a la vez.

Qué cambia cuando la IA escribe más de tu código

La investigación DORA reciente apunta a algo incómodo para quien venda un asistente de codificación. Los asistentes aceleran tareas de bajo nivel, pero las ganancias no se llevaron claramente al lead time o tasa de cambios fallidos. Más código escrito por hora no es lo mismo que más valor entregado por semana.

Si acaso, un volumen más grande de cambios generados empuja presión en revisión y en tu pipeline de entrega. Lotes más grandes lastiman la estabilidad, y la capacidad de revisión no escala con la velocidad de escritura. Vigila tu tasa de cambios fallidos y tasa de retrabajos de cerca en los meses después de que un equipo adopte un asistente. Si lead time cae pero retrabajos suben, no conseguiste ir más rápido, moviste el costo.

Cómo usarlas en una retro sin romper tu equipo

Aquí está lo que funciona en la práctica. Pon las líneas de tendencia en pantalla para el último trimestre y haz una sola pregunta: ¿Qué cambió aquí, y por qué? No preguntes quién. El objetivo es una hipótesis sobre el sistema, no un veredicto sobre una persona.

Tres hábitos mantienen los números honestos.

Primero, nunca las pongas en revisiones de desempeño individual. En el momento en que una métrica se une a un nombre, la gente optimiza la métrica, y tus datos dejan de describir la realidad.

Segundo, empareja cada número con una historia. Un pico en tiempo de recuperación es un incidente con un nombre y un post-mortem. Lee el post-mortem antes de leer el gráfico.

Tercero, cambia una cosa a la vez. Si adoptas feature flags, encoges pull requests, y automatizas rollbacks en el mismo mes, nunca aprenderás cuál fue el que movió la aguja.

Salta la slide del modelo de madurez que ordena tu org en tiers y reparte un trofeo. Que valga la pena en su lugar: una sola página por servicio, actualizada mensualmente, listando los cinco números, el valor del mes anterior, y una oración sobre qué cambió.

Supongamos que tuviste noventa días de datos limpios en un servicio, y viste la tasa de cambios fallidos escalando hacia arriba mientras la frecuencia de despliegue se mantenía plana. ¿Dónde mirarías primero: el tamaño de los cambios, la calidad de la revisión, o la visibilidad que tienes en un rollout mientras aún es pequeño? Tu respuesta dice más sobre tu sistema de entrega que cualquier benchmark.