Las métricas DORA son cuatro medidas clave que ayudan a los líderes de equipo a comprender la efectividad de sus prácticas de trabajo de DevOps. los Investigación y evaluación de DevOps (DORA) El grupo desarrolló las métricas después de seis años de investigación sobre la adopción exitosa de DevOps.
La medición de datos es la mejor manera de medir el efecto que DevOps está teniendo en su organización. Centrarse en los aspectos identificados por DORA puede descubrir oportunidades para optimizar sus procesos y mejorar la eficiencia. En este artículo, explicaremos cómo cada una de las cuatro métricas contribuye al éxito de DevOps.
Frecuencia de implementación
La frecuencia de implementación mide la frecuencia con la que envía código nuevo a su entorno de producción. Dado que el objetivo primordial de DevOps es entregar código que funcione de manera más eficiente, la frecuencia de implementación es un excelente punto de partida cuando evalúa el éxito.
Puede recopilar estos datos simplemente analizando cuántas veces se ha implementado código nuevo durante un período de tiempo determinado. A continuación, puede buscar oportunidades para aumentar su tasa de lanzamiento, sin sacrificar las barandillas que mantienen los estándares de calidad. El uso de la entrega continua para implementar automáticamente el código a medida que lo fusiona es una forma de acelerar su flujo de trabajo.
La frecuencia de implementación ideal depende del tipo de sistema que esté construyendo. Si bien ahora es común que las aplicaciones web se entreguen varias veces al día, esta cadencia no es adecuada para los desarrolladores de juegos que producen compilaciones de varios gigabytes.
En algunas situaciones, puede ser útil reconocer esta diferencia al pensar en la frecuencia de implementación de manera ligeramente diferente. Puedes acercarte a ella como la frecuencia con la que pudo haber implementado el código, si deseaba editar una nueva versión en un momento determinado. Esta puede ser una forma más efectiva de medir el rendimiento cuando la verdadera entrega continua no es viable para su proyecto.
Cambiar plazo de entrega
un cambio el tiempo de entrega es el intervalo entre la confirmación de una revisión de código y la entrada de esa confirmación en el entorno de producción. Esta métrica revela los retrasos que se producen durante la revisión y la iteración del código, después de que los desarrolladores hayan completado el sprint original.
Medir este valor es sencillo. Debe encontrar la hora a la que el desarrollador firmó un cambio, luego la hora a la que se entregó el código a los usuarios. El tiempo de espera es el número de horas y minutos entre los dos valores.
Como ejemplo, considere un cambio simple para enviar un correo electrónico de alerta de seguridad después de que los usuarios inicien sesión. El desarrollador completa la tarea a las 11 am y envía su trabajo al repositorio de origen. A las 12:00, un revisor lee el código y lo pasa al control de calidad. A las 2 p. m., el evaluador del equipo de control de calidad notó que había un error tipográfico en la copia del correo electrónico. El desarrollador confirma una solución a las 3:00 p. m. y el control de calidad fusiona el cambio final en producción a las 4:00 p. m. El tiempo de espera de este cambio fue de 5 horas.
El tiempo de entrega se utiliza para descubrir ineficiencias a medida que el trabajo se mueve entre artículos. Aunque los estándares varían ampliamente según la industria y la organización, un tiempo de entrega promedio alto puede ser indicativo de fricciones internas y un flujo de trabajo mal considerado. Los plazos de entrega extendidos también pueden ser causados por desarrolladores de bajo rendimiento que producen trabajo de baja calidad como su primera iteración en una tarea.
Algunas organizaciones utilizan diferentes medidas para el tiempo de entrega. Muchos seleccionan el tiempo que transcurre entre que un desarrollador comienza una característica y el código final entra en producción. Otros pueden mirar hacia atrás aún más y usar el momento en que se solicitó un cambio, por parte de un cliente, un cliente o un gerente de producto, como punto de partida.
Estos métodos pueden producir información que es más útil dentro del negocio, fuera de los equipos de ingeniería. Sin embargo, la interpretación de DORA que usa marcas de tiempo de confirmación tiene una gran ventaja: la herramienta de control de fuente captura los datos automáticamente, por lo que los desarrolladores no necesitan registrar manualmente las horas de inicio para cada nueva tarea.
Tasa de error de cambio
La tasa de errores de cambio es el porcentaje de implementaciones en producción que provocan un incidente. Un incidente es cualquier error o comportamiento inesperado que provoca una interrupción o interrupción a los clientes. Los desarrolladores y operadores deberán dedicar tiempo a resolver el problema.
Puede calcular su tasa de errores de cambio dividiendo la cantidad de implementaciones que ha realizado por la cantidad que ha dado lugar a un error. El último valor generalmente se adquiere al etiquetar los informes de errores en su software de administración de proyectos con la implementación que los introdujo.
Atribuir con precisión los incidentes al cambio que los causó a veces puede ser complicado, especialmente si tiene una frecuencia de implementación alta, pero en muchos casos es posible que los desarrolladores y los equipos de clasificación determinen el desencadenante más probable. Otro desafío puede ser ponerse de acuerdo sobre lo que constituye una falla: ¿los errores menores deberían aumentar su tasa de fallas o solo le interesan las interrupciones importantes? Ambos tipos de problemas afectan la forma en que los clientes perciben su servicio, por lo que puede ser útil mantener varios valores diferentes para esta métrica, cada uno de los cuales analiza una clase diferente de problema.
Siempre debe intentar reducir la tasa de errores de cambio lo más bajo posible. El uso de pruebas automatizadas, análisis estáticos e integración continua puede ayudar a evitar que el código roto llegue a producción. Proteja sus procesos con nuevas herramientas y métodos de trabajo para reducir gradualmente la tasa de fallas en el tiempo.
Hora de restaurar el servicio
Desafortunadamente, las fallas no se pueden erradicar por completo. Eventualmente, se encontrará con un problema que causará dolor a sus clientes. La cuarta métrica de DORA, Tiempo para restaurar el servicio, analiza la eficacia con la que puede responder a estos eventos.
De manera similar al tiempo de entrega del cambio, la duración que se mide puede variar entre organizaciones. Algunos equipos usarán la hora en que se implementó el error, otros pasarán del primer informe del cliente y algunos pueden usar la hora en que se llamó al equipo de respuesta a incidentes. Cualquiera que sea el punto desencadenante que adopte, debe usarlo de manera constante y seguir midiendo hasta que el incidente se marque como resuelto.
Un tiempo de recuperación promedio alto es una señal de que sus procesos de respuesta a incidentes necesitan un ajuste fino. Las respuestas efectivas dependen de que las personas adecuadas estén disponibles para identificar la falla, desarrollar un parche y comunicarse con los clientes afectados. Puede reducir el tiempo de restauración mediante el desarrollo de procedimientos de respuesta acordados, manteniendo la información crítica accesible de forma centralizada en su organización e introduciendo el monitoreo automatizado para alertarlo sobre los problemas tan pronto como ocurran.
La optimización de esta métrica a menudo se descuida porque demasiados equipos asumen que nunca ocurrirá una interrupción importante. También es posible que tenga relativamente pocos puntos de datos con los que trabajar si su servicio es generalmente estable. Ejecutar ensayos de respuesta a incidentes utilizando técnicas como las pruebas de caos puede proporcionar datos más significativos que sean representativos de su tiempo de recuperación actual.
Resumen
Las cuatro métricas de DORA brindan a los líderes de equipo de DevOps datos que descubren oportunidades de mejora. La medición y el análisis regulares de la frecuencia de implementación, el tiempo de entrega de cambios, la tasa de fallas de cambios y el tiempo de restauración del servicio lo ayudan a comprender su rendimiento y tomar decisiones informadas sobre cómo mejorarlo.
Las métricas de DORA se pueden calcular manualmente utilizando la información de su sistema de gestión de proyectos. También existen herramientas como Google Cloud Cuatro llaves que los generará automáticamente a partir de la información de confirmación. Algunas herramientas del ecosistema como GitLab están comenzando a incluir soporte integrado también.
Las mejores implementaciones de DevOps facilitarán cambios rápidos e implementaciones periódicas que muy rara vez introducen nuevos errores. Cualquier regresión que ocurra se tratará de inmediato, lo que minimizará el tiempo de inactividad para que los clientes tengan la mejor impresión de su servicio. El seguimiento de las tendencias de DORA a lo largo del tiempo le permite verificar si está logrando estos ideales, lo que le brinda la mejor oportunidad de éxito en DevOps.
