Impulsando la excelencia en DevOps: cómo aprovechar las métricas DORA para obtener mejores resultados
6 min de lectura

Sobre nuestro producto y modelo de entrega

Descripción general del producto/proyecto

freya fusion es una plataforma tecnológica reglamentaria avanzada que aprovecha la inteligencia artificial y las soluciones Cloud-based para optimizar los procesos de cumplimiento. Sus características principales incluyen una Regulatory Cloud basada en IA para una supervisión inteligente, composibilidad en datos, contenido, aplicaciones e interfaces de usuario para mayor flexibilidad, y procesos reglamentarios alineados con la planificación multifuncional. La plataforma también ofrece soluciones de automatización integrada, un Knowledge Graph para obtener información estructurada y una interfaz de usuario conversacional para mejorar la interacción del usuario. Diseñada para ofrecer eficiencia, Freya Fusion combina tecnología de vanguardia con experiencia reglamentaria para simplificar flujos de trabajo de cumplimiento complejos.

Ecosistema actual de procesos y entrega

Metodología ágil y herramientas

En Freya Fusion, aplicamos la metodología Ágil integrada con prácticas de DevSecOps para garantizar seguridad, cumplimiento y eficiencia desde el código hasta la implementación. En nuestro marco de trabajo Ágil, las funciones sirven como los elementos de trabajo principales de las versiones. Se agrupan y validan varias funciones juntas para formar un candidato de versión (RC), lo que garantiza una entrega de valor incremental y controlada.

Azure DevOps (ADO) e integraciones de complementos

Descripción general de la canalización de CI/CD

Las canalizaciones de Integración Continua y Despliegue Continuo (CI/CD) automatizan el proceso de entrega de software desde el desarrollo hasta la producción, lo que garantiza versiones más rápidascalidad constantemenos errores manuales.

Integración Continua (CI): la fase de compilación y pruebas utilizada por el equipo de Sprint

  • Envío de código: los desarrolladores envían cambios a un repositorio compartido (p. ej., Azure Repos, GitHub).
  • Compilación automatizada: la canalización compila el código, resuelve las dependencias y empaqueta los elementos.
  • Pruebas automatizadas: se ejecutan pruebas unitarias, pruebas de integración y análisis de seguridad (SAST/DAST) para detectar problemas de forma temprana.
  • Almacenamiento de elementos: las compilaciones validadas se almacenan en repositorios

Despliegue Continuo (CD): la fase de versión utilizada por el equipo de despliegue

  • Entornos por etapas: el código avanza a través de DevSecOps → SQA → PreProd → Production con controles de aprobación.
  • Despliegues automatizados: el despliegue se realiza a través de canalizaciones de versiones con un tiempo de inactividad mínimo
  • Comprobaciones posteriores al despliegue: pruebas de humo automatizadas, supervisión del rendimiento y mecanismos de reversión implementados y regidos por los SOP.

Tipos de versiones: principal, menor, parche y revisión urgente

Las versiones se clasifican en principal, menor, parche o revisión urgente según la intención y las funciones que se incluyan en esa versión.

  • Principal: indica la versión inicial o una versión en la que las funciones afectan la funcionalidad sin compatibilidad con versiones anteriores
  • Menor: indica el lanzamiento de una nueva funcionalidad con compatibilidad con versiones anteriores y mejoras en las funciones existentes
  • Parche: indica el lanzamiento de correcciones de errores agrupadas, actualizaciones de seguridad y pequeñas mejoras con compatibilidad con versiones anteriores
  • Revisión urgente: indica una versión de emergencia para solucionar problemas críticos informados en producción en la versión desplegada.

Métricas clave que importan

Explicación de las cuatro métricas DORA:

Según los estándares de la industria, existen 4 métricas clave que las organizaciones exitosas deben rastrear y optimizar.

  1. Tiempo de entrega (la rapidez con la que lanzamos software a producción)
  2. Frecuencia de despliegue (la frecuencia con la que realiza versiones).
  3. Tasa de error de cambios (la frecuencia con la que fallan los despliegues).
  4. Tiempo medio de recuperación (MTTR) (la rapidez con la que se solucionan las fallas).

El tiempo de entrega es una de las cuatro métricas clave de Investigación y Evaluación de DevOps (DORA). Mide el tiempo que tardan los cambios de código desde la confirmación hasta la implementación en producción, reflejando la eficiencia de su proceso de entrega de software. Esta métrica indica la duración promedio entre el momento en que se confirma un cambio de código y cuando se implementa con éxito en producción.

El tiempo de entrega indica:

  • la velocidad de entrega y la eficiencia del proceso.
  • Unos tiempos de entrega más cortos se correlacionan con ciclos de retroalimentación más rápidos y una mayor agilidad.

La frecuencia de implementación realiza un seguimiento de la frecuencia con la que los cambios de código se implementan con éxito en producción. Refleja la velocidad y la consistencia de su entrega de software

La frecuencia de implementación indica:

  • Agilidad del equipo y madurez del proceso.
  • Las implementaciones frecuentes reducen el riesgo al permitir cambios más pequeños e incrementales (en comparación con lanzamientos grandes y poco frecuentes).
  • Se correlaciona con ciclos de retroalimentación más rápidos y una mayor satisfacción del cliente.

El tiempo medio de recuperación (MTTR) mide el tiempo promedio que se tarda en restablecer el servicio después de una falla (por ejemplo, una interrupción, degradación del rendimiento o error). Refleja la resiliencia y la eficiencia de respuesta ante incidentes de su equipo.

El MTTR indica:

  • Minimiza el tiempo de inactividad y el impacto en el usuario.
  • Un MTTR alto indica una depuración lenta, un seguimiento deficiente o procesos de reversión ineficientes.
  • Se correlaciona con la confianza del cliente, los costos operativos y el estrés del equipo.

La tasa de fallas en los cambios (CFR) mide el porcentaje de implementaciones que causan fallas en producción y requieren corrección (por ejemplo, reversiones, correcciones rápidas o parches). Refleja la estabilidad y la fiabilidad de su proceso de lanzamiento.

La CFR indica:

  • Indica con qué frecuencia las implementaciones introducen defectos (errores, interrupciones, problemas de rendimiento).
  • Una CFR alta sugiere pruebas deficientes, un seguimiento inadecuado o prácticas de lanzamiento riesgosas.
  • Se correlaciona con el desgaste del equipo, la confianza del cliente y los costos operativos.
MétricaDefiniciónFórmula
Tiempo de entregaTiempo promedio para completar una funciónSuma del tiempo de entrega / Número de funciones
Frecuencia de implementaciónCon qué frecuencia se implementa el código en producción.Total de implementaciones / n.º de meses
Tasa de errores de cambio (CFR)Porcentaje de implementaciones que provocan un error.Número de cambios fallidos ÷ Número total de cambios × 100.
Tiempo medio de restauración (MTTR)Tiempo promedio necesario para restaurar el servicio tras una incidencia.Suma de los tiempos de restauración ÷ Número de fallos (Problema operativo / ERROR / Problema de datos)

Métricas de apoyo adicionales:

  1. Trabajo en curso (WIP): Mide el número de tareas sin terminar (por ejemplo, cambios de código, funciones, errores) que se encuentran actualmente en el flujo de trabajo. Esta métrica ayuda a medir los cuellos de botella y la necesidad de dividir la funcionalidad o la historia de usuario.
  2. Tiempo de ciclo: Tiempo transcurrido desde el inicio del trabajo (por ejemplo, la creación del tique) hasta su finalización.
  3. Número de solicitudes de extracción: Métrica que realiza un seguimiento del número de PR creadas, fusionadas o rechazadas durante un período de tiempo determinado (por ejemplo, diario, semanal o mensual). Ayuda a los equipos a evaluar la productividad de los desarrolladores, la eficiencia de la colaboración y los cuellos de botella en el flujo de trabajo.
  4. Incidencias de clientes: Número de incidencias en producción reportadas por los clientes que indican la calidad de las pruebas internas.
  5. Errores abiertos: Esta métrica realiza un seguimiento del número de defectos no resueltos (errores) en su sistema en un momento dado. Ayuda a medir la calidad del software, la deuda técnica y la eficiencia del equipo en la gestión de incidencias.
  6. Errores abiertos de larga duración: Los errores abiertos de larga duración son defectos que permanecen sin resolver durante un período prolongado (normalmente 30 días o más). Su seguimiento ayuda a identificar ineficiencias en los procesos, brechas en la priorización y deuda técnica.
  7. Errores aplazados: Son defectos que se han reconocido, pero cuya resolución se ha pospuesto intencionalmente para más adelante. Aunque el aplazamiento puede ser una estrategia legítima, unos aplazamientos excesivos pueden indicar acumulación de deuda técnica, problemas de priorización o ineficiencias en los procesos.
  8. Estado de integración continua (CI): Esta métrica supervisa la estabilidad y fiabilidad de su flujo de trabajo de integración continua (CI) mediante el seguimiento de la tasa de éxito/fracaso de las compilaciones y pruebas automatizadas. Un sistema de CI saludable es fundamental para obtener comentarios rápidos, lanzamientos de alta calidad y productividad para los desarrolladores.
  9. Estado de despliegue continuo (CD): esta métrica supervisa la estabilidad, la velocidad y la tasa de éxito de su implementación automatizada. Un sistema de CD saludable garantiza lanzamientos fiables, frecuentes y de bajo riesgo.
  10. Pruebas de integración: Las pruebas de integración validan que los módulos, servicios o sistemas desarrollados de forma independiente funcionen correctamente al combinarse. Es una fase fundamental en DevOps para detectar problemas antes de que lleguen a producción.
  11. Conjunto de supervisión de producción: Conjunto de herramientas y prácticas para supervisar el estado del sistema, detectar anomalías y resolver incidencias en tiempo real para las aplicaciones que se ejecutan en producción. Es fundamental para los equipos de SRE, DevOps y operaciones mantener el tiempo de actividad, el rendimiento y la satisfacción del usuario.

Por qué importan las métricas en una organización exitosa

El seguimiento de las métricas de DevOps y operativas (como DORA, tiempo de entrega, frecuencia de implementación, MTTR, CFR, alertas de supervisión, etc.) proporciona información útil que impulsa el éxito empresarial, la excelencia técnica y la ventaja competitiva.

  1. Acelere la llegada al mercado
    • Métricas: Tiempo de entrega, frecuencia de implementación, tiempo de ciclo
    • Impacto:
      • Lanzamientos más rápidos → respuesta más ágil a las demandas del mercado.
      • Ciclos de respuesta más cortos → Innove más rápido que la competencia.
  2. Mejore la calidad y la fiabilidad del software
    • Métricas: Tasa de fallos en cambios (CFR), tiempo medio de recuperación (MTTR), errores abiertos
    • Impacto:
      • Menos fallos de producción → Mayor satisfacción del cliente.
      • Resolución de incidencias más rápida → Minimice la pérdida de ingresos
  3. Reduzca los costes y el desperdicio
    • Métricas: Estado de compilación de CI, fallos en pruebas de integración, pruebas inestables
    • Impacto:
      • Detección temprana de errores → Menor coste de corrección en desarrollo frente a producción
      • Flujos de trabajo eficientes → Ahorre costes de nube y computación
  4. Mejore la productividad y la moral del equipo
    • Métricas: Tiempo de ciclo de PR, límites de WIP, tasa de éxito en implementaciones
    • Impacto:
      • Menos cuellos de botella → Los desarrolladores pasan más tiempo programando y menos esperando.
      • Comprobaciones automatizadas → Reduzca el agotamiento por tareas manuales.
  5. Alinea DevOps con los objetivos empresariales
    • Métricas: Entrega de unidades comercializables, tasa de incidencias de clientes, compromisos de tiempo de actividad
    • Impacto:
      • Conecta los esfuerzos de ingeniería con los ingresos, el crecimiento de usuarios y la retención.
  6. Toma de decisiones basada en datos
    • Métricas: Tendencias en tiempo medio de reparación (MTTR), antigüedad de errores y frecuencia de implementación
    • Impacto:
      • Prioriza las mejoras de alto impacto
      • Justifica las inversiones en automatización, formación o herramientas con pruebas de ROI.

Resumen:

Al automatizar el seguimiento y la optimización de estas métricas clave, las organizaciones pueden obtener beneficios significativos, entre los que se incluyen:

  • Decisiones basadas en datos : aproveche información práctica para orientar la estrategia y las inversiones.
  • Excelencia en ingeniería : fomente la mejora continua en las prácticas de desarrollo y operativas.
  • Competitividad industrial : alíniese con los mejores puntos de referencia (o supérelos).
  • Éxito del cliente : ofrezca soluciones fiables y de alta calidad que cumplan con las expectativas de los usuarios.
  • Gobernanza y liderazgo : proporcione transparencia y rendición de cuentas en todos los niveles.

Este enfoque estructurado garantiza procesos más inteligentes, un rendimiento superior y un crecimiento empresarial sostenido.

Referencias

  • Accelerate, por Forsgren, Humble y Kim
  • Documentación de Azure DevOps
  • Informes de investigación y evaluación de DevOps (DORA)

Suscribirse al blog de Freyr

Política de Privacidad