El software fallará. La recuperación es la métrica real

11 min de lectura

Deja de prometer que el software nunca fallará

La reunión posterior a una caída suele empezar con pruebas y terminar con teatro. Alguien muestra la cronología. Alguien pregunta por qué el entorno de pruebas no detectó el problema. Un proveedor explica que producción se comportó de otra manera. Entonces llega la frase que todos esperaban: «¿Puedes garantizar que nunca volverá a ocurrir?»

Los presentes pueden afrontar la verdad sobre el riesgo y la recuperación. O pueden prometer perfección, añadir tres niveles de aprobación y hacer que el siguiente fallo sea mayor.

La segunda opción goza de una popularidad sorprendente. Produce actividad visible: más firmas, una lista de comprobación más larga y quizá un nuevo comité con un nombre imponente. Nada de eso tiene que mejorar la detección, la contención o la recuperación. Solo debe hacer que el fallo parezca menos probable en una diapositiva.

Cuando el objetivo es cero fallos, resistirse al cambio parece prudente. Las versiones crecen para poder publicarse con menos frecuencia. Revertir se vuelve más difícil porque un solo despliegue contiene ya tres correcciones urgentes, una migración de base de datos, dos cambios regulatorios y la funcionalidad que el CEO ya anunció. La organización persiguió la perfección y acabó rehén de su propio despliegue.

El software sigue exigiendo rigor: pruebas automatizadas, integración continua, observabilidad, diseño cuidadoso, seguridad, planes de recuperación y desarrolladores competentes. Pero la calidad no consiste en la ausencia de cualquier fallo. Consiste en ofrecer el comportamiento que necesitan los usuarios con la fiabilidad que requiere el negocio, sin perder la capacidad de volver a cambiarlo.

Un sistema perfectamente estable que nadie puede cambiar con seguridad no es un triunfo. Es una pieza de museo con nómina.

El MTBF premia el comportamiento equivocado

El tiempo medio entre fallos tiene un atractivo intuitivo. Observa un sistema, cuenta los fallos y calcula el intervalo promedio entre ellos. Cuanto más largo, mejor suena. Para equipos físicos, cuyos componentes envejecen y acaban necesitando sustitución, puede ser información operativa útil.

El software no es un rodamiento.

El código no se desgasta al llegar el viernes ni se oxida tras otro millón de peticiones. Lo que se niega a permanecer quieto es su contexto operativo. Los equipos despliegan. Los usuarios encuentran combinaciones nuevas. Los datos crecen. Los certificados caducan. El tráfico cambia de forma. Los proveedores actualizan servicios. Las API externas reinterpretan campos que juraron que eran estables. Los atacantes prueban entradas que nadie previó.

El MTBF no es inútil. En un servicio estable puede describir la frecuencia de incidentes y respaldar decisiones de personal o capacidad. Se vuelve peligroso cuando la dirección lo convierte en el objetivo principal de la entrega de software.

Existe una forma maravillosamente sencilla de aumentar el tiempo entre fallos de despliegue: dejar de desplegar.

La métrica mejora de inmediato. El negocio no.

Los cambios se acumulan en lotes mayores. La información llega más tarde. Los desarrolladores olvidan por qué se tomaron ciertas decisiones. Producción se convierte en terreno sagrado que debe protegerse del desarrollo, una manera ingeniosa de proteger los defectos de hoy frente a las correcciones de mañana.

El MTBF mide la distancia entre fallos visibles. No mide el tamaño de los lotes, el miedo a publicar, la capacidad de recuperación ni las oportunidades perdidas mientras todos esperan la versión perfecta.

DORA mide el sistema de entrega

El conocido modelo DORA se conocía como las «Four Keys»: frecuencia de despliegue, tiempo de entrega de cambios, tasa de fallos en cambios y tiempo medio de recuperación.

El modelo evolucionó. DORA describe ahora cinco métricas de rendimiento de la entrega de software, agrupadas en rendimiento e inestabilidad. Su historia de las métricas explica por qué la antigua etiqueta MTTR pasó a ser tiempo de recuperación de despliegues fallidos y por qué se añadió la tasa de retrabajo de despliegues.

Perspectiva	Métrica	Qué revela
Rendimiento	Tiempo de entrega de cambios	Cuánto tarda un cambio confirmado en llegar correctamente a producción
Rendimiento	Frecuencia de despliegue	Con qué frecuencia puede la organización llevar cambios a producción
Rendimiento	Tiempo de recuperación de despliegues fallidos	Cuánto se tarda en recuperar el servicio cuando un despliegue lo perjudica y exige intervención
Inestabilidad	Tasa de fallos en cambios	Qué proporción de despliegues necesita una reversión, hotfix, parche u otra corrección inmediata
Inestabilidad	Tasa de retrabajo de despliegues	Qué proporción de despliegues consiste en trabajo no planificado para corregir un problema visible para el usuario en producción

El valor está en la tensión entre las métricas. La frecuencia de despliegue sin tasa de fallos premia una velocidad temeraria. La tasa de fallos sin frecuencia de despliegue premia la inactividad. El tiempo de entrega sin retrabajo puede celebrar un pipeline que publica basura a gran velocidad. El tiempo de recuperación sin fiabilidad para el usuario puede hacer que incidentes repetidos parezcan eficientes.

Juntas, las métricas describen si un sistema de entrega lleva cambios útiles a producción con seguridad. La investigación de DORA rechaza la cómoda suposición de que velocidad y estabilidad son opuestas. Las organizaciones de alto rendimiento suelen destacar en ambas. Los cambios pequeños producen evidencia antes y facilitan la recuperación.

Las métricas pertenecen a una aplicación o un servicio dentro de su propio contexto. Mezclar todos los equipos en una sola cifra corporativa produce una media impresionante y muy poca verdad. Comparar una aplicación móvil con un mainframe regulado es teatro de gestión con decimales.

Usa DORA para ver si un sistema de entrega mejora con el tiempo, no para construir una clasificación. En cuanto una métrica se convierte en cuota, la gente aprende a cumplir la cuota. El software sigue sin mostrar el menor interés por el sistema de bonificaciones.

La recuperación es una capacidad de entrega

El MTTR puso en duda la fantasía de que prevenir era la única estrategia de fiabilidad respetable. La idea de un tiempo medio para recuperar, restaurar, reparar o resolver —elige tu significado favorito y empieza la discusión sobre el acrónimo— desplazó la atención desde la culpa hacia la capacidad.

DORA acotó el término con razón. El tiempo de recuperación de despliegues fallidos abarca los problemas causados por cambios en producción. No mezcla esos fallos con la caída de un centro de datos, un cable de red cortado o cualquier otro incidente que pueda afectar a un servicio. Así ofrece una medida más limpia de la entrega de software.

La conversación más amplia sobre recuperación sigue importando. Los servicios fallan sin que haya despliegues, y a los clientes no les importa de quién sea la infraestructura que causó la caída. Un CTO debe mantener separadas las preguntas:

• ¿Nuestro proceso de entrega introdujo el fallo?
• ¿Con qué rapidez volvieron los usuarios a recibir un servicio aceptable?
• ¿Detectamos el problema antes de que lo notificaran los usuarios?
• ¿La recuperación siguió el camino normal o necesitó improvisación con privilegios especiales?
• ¿Cuánto trabajo posterior generó el incidente?

Un solo promedio puede ocultar mucho. Diez reversiones de dos minutos y un desastre de ocho horas todavía pueden producir una media respetable. Importan la gravedad, el radio de impacto, el tiempo de detección y la distribución de los tiempos de recuperación. Las métricas son instrumentos, no absolución.

La recuperación rápida no es un truco del equipo de operaciones que empieza cuando los desarrolladores terminan. Es una propiedad de todo el sistema de entrega que se diseña al definir el cambio.

Un cambio pequeño resulta más fácil de entender, probar, observar, revertir y sustituir. Un despliegue automatizado lleva la corrección de emergencia por el mismo camino que el trabajo ordinario. Un feature flag puede separar el despliegue de la exposición. Un despliegue canario limita el radio de impacto. Una supervisión útil hace visible el daño al usuario. Una asignación clara de responsabilidades elimina la llamada de diez minutos dedicada a descubrir quién tiene permiso para actuar. Una reversión probada evita que la base de datos se convierta en una puerta de un solo sentido.

Ninguna de esas prácticas garantiza el éxito. Hacen que los fallos sean menores y menos dramáticos.

Por eso se refuerzan entre sí las prácticas técnicas que impulsan resultados de negocio. Las pruebas aumentan la confianza. La integración continua expone cambios incompatibles mientras aún son pequeños. La refactorización mantiene comprensibles las rutas de recuperación. Las versiones pequeñas y frecuentes reducen la incertidumbre de cada despliegue.

El resultado es control en la única forma que permite el software complejo: observar la realidad y responder sin empeorarla.

Las largas cadenas de aprobación rara vez mejoran la recuperación. Pueden prevenir algunos errores, pero no sustituir la evidencia de producción. Cuando algo se rompe, el mismo camino de aprobación se convierte en parte de la caída. El cambio de emergencia espera porque la única persona autorizada para aprobarlo está en un avión.

Si el camino habitual es demasiado lento para restaurar el servicio, es demasiado lento.

La fiabilidad necesita un objetivo de negocio

DORA mide el rendimiento de la entrega de software. No sustituye los indicadores y objetivos de nivel de servicio que miden la fiabilidad percibida por el usuario.

Esa distinción evita dos conclusiones igual de malas. Producto no puede presentar despliegues frecuentes como prueba de que el servicio está sano. Operaciones no puede presentar la disponibilidad como prueba de que el sistema de entrega está sano. Un servicio puede parecer fiable porque nadie se atreve a cambiarlo. Un equipo puede desplegar con frecuencia mientras los usuarios sufren degradaciones repetidas. Ambos paneles pueden estar en verde.

La guía de SRE de Google sobre aceptar el riesgo expone directamente la idea incómoda: una fiabilidad del 100 % suele ser el objetivo equivocado. La fiabilidad extrema tiene un coste no lineal. Los usuarios a menudo no perciben el último incremento, y el esfuerzo dedicado a perseguirlo no puede mejorar funcionalidades, reducir deuda técnica ni abaratar la operación.

La alternativa útil es un objetivo de nivel de servicio explícito y un presupuesto de error. Decide qué fiabilidad necesitan los usuarios y qué nivel puede justificar el negocio. Mide la experiencia real del usuario frente a ese objetivo. Cuando el servicio consume demasiado de su presupuesto de error, invierte en fiabilidad y frena los cambios arriesgados. Cuando funciona con holgura dentro del presupuesto, sigue mejorando el producto.

Para funciones críticas para la seguridad, la privacidad o las finanzas, el presupuesto aceptable puede ser diminuto. El principio se mantiene: haz explícito el riesgo, elige controles acordes con las consecuencias y verifícalos. «No fallar nunca» no es un control. Es un deseo con corbata.

El MTBF puede seguir siendo útil para flotas de equipos, componentes de infraestructura y análisis de incidentes. No puede sustituir un objetivo de nivel de servicio ni convertirse en la referencia principal de una organización cuyo trabajo consiste en cambiar software.

Lo que un CTO puede prometer de forma creíble

El consejo de administración no necesita una clase sobre sistemas distribuidos. Necesita una declaración creíble del riesgo y pruebas de que la organización puede gestionarlo:

No podemos garantizar que el software nunca fallará. Podemos demostrar que los cambios son pequeños, reversibles de forma independiente y observados en producción. Sabemos con qué frecuencia los despliegues necesitan intervención, con qué rapidez restauramos el servicio, cuánto trabajo correctivo no planificado generan los fallos y si los usuarios reciben la fiabilidad que acordamos proporcionar. Cuando esas señales empeoran, invertimos en resolver el cuello de botella en lugar de ocultarlo tras una congelación de despliegues.

Ese compromiso es más sólido que «nunca más». Se puede medir, ofrece a la dirección una regla para decidir y convierte la fiabilidad en una preocupación compartida del negocio, no en una carga moral que recae sobre los desarrolladores después de cada incidente.

También da al CTO mejores preguntas para la siguiente revisión:

• ¿Desplegamos con menos frecuencia porque el sistema es estable o porque cambiarlo da miedo?
• ¿Qué tamaño tiene el cambio típico en producción?
• ¿Puede revertirse un cambio fallido sin una reunión especial?
• ¿Nuestra ruta de recuperación utiliza el mismo pipeline probado que un despliegue ordinario?
• ¿Qué objetivo de nivel de servicio representa lo que experimentan realmente los usuarios?
• ¿Aumenta el trabajo correctivo no planificado aunque el número de incidentes parezca estable?

Esas respuestas revelan mucho más de lo que jamás podrá mostrar un MTBF más largo.

El software vive en un mundo cambiante. La respuesta madura no es la resignación ni la negligencia. Es trabajar sin descanso para prevenir los fallos que conoces, exponer los que no, contener su impacto y restaurar el servicio mientras el incidente aún es pequeño.

La perfección no es el criterio. Sí lo es un sistema de entrega que dice la verdad y se recupera sin heroicidades.