Acelerando la calidad del código con las métricas de DORA

Hola a todos. Mi nombre es Niko Kruger. Y hoy voy a hablarles sobre cómo acelerar la calidad del código con las métricas de Dora. He pasado los últimos 13 años trabajando con empresas de software en todo el mundo, ayudándolas a mejorar la calidad de su software, enfocándome específicamente en aplicaciones críticas de calidad. Y hoy, me desempeño como Director Senior de Ingeniería de Soluciones aquí en Rollbar. Así que para la agenda de hoy, vamos a ver tres cosas. La primera es echar un vistazo a qué es Dora y cómo se relaciona con la mejora continua del código. También vamos a analizar los beneficios que obtendrás tú y tu organización una vez que te conviertas en un ejecutante de élite, a medida que pases de bajo, medio, alto a la categoría de ejecutante de élite. También vamos a ver el camino para acelerar la calidad del código con la mejora continua del código, y qué beneficios puedes esperar recibir una vez que tu organización alcance ese estatus de alto rendimiento y élite.

Entonces, primero veamos qué son las métricas de Dora. El DevOps Research and Assessment es un equipo de Google que ha dedicado varios años a investigar algunas de las cosas clave que impulsan a las organizaciones de mayor rendimiento en todo el mundo. Y han analizado los procesos técnicos, la medición de la cultura y todas estas capacidades que conforman estos equipos de alto rendimiento. También han analizado no solo los equipos de entrega de software de alto rendimiento, sino también las organizaciones que generan ingresos para sus clientes. Asegurándose de que los productos que lanzan estos equipos de alto rendimiento realmente den resultados tangibles en el negocio. Lo que han analizado, es un conjunto de métricas clave que han identificado y que puedes utilizar en tu organización para comprender dónde te encuentras actualmente y también qué debes hacer para avanzar en esta cadena y convertirte en un ejecutante de élite.

La primera es el tiempo de entrega de las características a los clientes. Y lo que eso significa es el tiempo que te lleva desde tener una idea hasta llevarla a través de tu canalización y ponerla en manos de tus clientes. Así les das un valor real para que puedan utilizar estas características de manera muy rápida día tras día y comenzar a darte comentarios sobre cómo funcionan y, obviamente, cómo eso puede afectar, por ejemplo, tus ingresos si es una aplicación orientada a los ingresos.

La siguiente parte es, por supuesto, desplegar con mayor frecuencia. Así que hemos analizado cómo estas organizaciones están desplegando, con qué frecuencia lo hacen y, una vez que lo hacen, ¿cuál es su tasa de fallos en los cambios? ¿Con qué frecuencia fallan estos lanzamientos? Por ejemplo, si comienzas a lanzar más, ¿fallas más a menudo o no? Y para esos fallos, también se analiza el tiempo de restauración de estos servicios. ¿Cuánto tiempo te lleva realmente revertir un despliegue fallido y ponerlo en funcionamiento nuevamente para que tus clientes vuelvan a utilizar tu solución? También está, por supuesto, la disponibilidad, pero eso no forma parte de las métricas de la discusión de hoy. Entonces, ¿qué medimos realmente cuando se trata de las métricas de Dora? Hay realmente un par de categorías aquí para esas cuatro métricas clave. Si echamos un vistazo a la frecuencia de despliegue, nuestros ejecutantes de bajo rendimiento realmente buscan hacer esto una vez al mes o cada seis meses. Y si avanzas hacia los ejecutantes de alto y élite, nuestros ejecutantes de élite realmente lo hacen a demanda y múltiples veces al día. De hecho, en Rollbar, hemos visto a algunos de nuestros clientes lanzar más de 4,000 veces en una semana determinada. Y eso solo te da una idea de lo rápido y con qué frecuencia pueden realizar cambios y características y ponerlos en manos de sus clientes. Y realmente, eso te ayuda a entender si tomas cambios más pequeños y los llevas a los clientes, ¿qué valor están obteniendo de ello? ¿Es algo de valor para ellos y ayudará a tu aplicación o negocio a avanzar? Para esos ejecutantes de menor rendimiento, eso, por supuesto, es un ciclo muy largo y, de hecho, tienes que agrupar muchos despliegues grandes y a menudo ni siquiera cambios grandes en estos pocos despliegues al año.

Ahora, por supuesto, si comenzamos a ver cuánto tiempo nos lleva llevar estos cambios a las manos de nuestros clientes, observamos el tiempo de entrega de cambios y, nuevamente, nuestros ejecutantes de alto rendimiento pueden hacer esto en algunos casos en menos de un día. Ahora, por supuesto, eso depende de qué tan grande sea un cambio o solicitud de características, pero, por supuesto, estos equipos de élite están dividiendo esto en partes más pequeñas de trabajo que están entregando a los clientes muy, muy rápidamente. Para aquellos en la escala de bajo rendimiento, nuevamente, lleva más de un mes a seis meses llevar estos cambios hasta el final de la canalización, probarlos, validarlos y ponerlos en manos de sus clientes. Y, por supuesto, eso puede afectar negativamente los ingresos, ya que tus clientes tienen que esperar más tiempo. Y, de hecho, tus competidores podrían estar innovando más que tú, ya sabes, en una proporción de 10 a 1. Y, por supuesto, a medida que estamos implementando más estos cambios en vivo, a menudo se puede esperar que nuestra tasa de fallos en los cambios sea muy alta, pero eso no fue realmente cierto. Entonces, nuestros ejecutantes de alto y élite tenían una tasa de fallos en los cambios de cero a 15%, en comparación con los ejecutantes de menor rendimiento, que tenían una tasa de fallos de aproximadamente el 50 al 60%. Entonces, por supuesto, cuanto más tiempo pasamos implementando, en realidad, mejoramos en ello. Y el tiempo de restauración fue realmente un reflejo de esto. Entonces, los ejecutantes de alto y élite tenían un proceso casi idéntico para restaurar sus servicios si algo sale mal. Y para los ejecutantes de alto y élite, esto está automatizado en cierta medida, si no completamente automatizado, mientras que nuestros ejecutantes de bajo rendimiento tardan más de una semana en recuperar estos servicios. Y fue un proceso muy manual volver a poner en funcionamiento estos elementos. Entonces, si comenzamos a analizar estas métricas, a medir a tu equipo, ¿cuáles son algunos de los beneficios que puedes esperar una vez que te conviertas en un ejecutante de alto y élite? Entonces, el grupo DORA encontró en realidad un par de beneficios bastante fenomenales que estos equipos de élite y alto rendimiento estaban obteniendo. Entonces, el primero es que en realidad estaban implementando 208 veces más frecuentemente que aquellos en el extremo inferior de la escala. Y eso nos dice que en realidad tienen la capacidad de impulsar características y capacidades en manos de los clientes más rápido. Y eso significa que son aproximadamente 106 veces más rápidos que los ejecutantes de bajo rendimiento. Eso significa que pueden poner características y partes valiosas que generan ingresos de la aplicación en manos de sus clientes. Entonces, nuevamente, eso es algo a tener en cuenta si quieres superar a tus competidores en el mercado actual.

Lo que también fue muy importante que surgió de esta investigación fue el hecho de que estos equipos tenían la capacidad de recuperarse muy rápidamente. Así que eran 2.6 veces más rápidos para recuperarse si algo salía mal. Y tenían una tasa de fallos en los cambios 7 veces menor. Así que en realidad eran muy buenos en lanzar software funcional y estos cambios más pequeños de manera regular. Aunque lanzaban múltiples veces al día, si no miles de veces a la semana, eran muy, muy buenos en asegurarse de que la calidad fuera mucho mejor para estos lanzamientos en comparación con aquellos en el lado de bajo rendimiento.

Otra parte bastante interesante de esta investigación fue el hecho de que dedicaban un 50% menos de tiempo a solucionar problemas de seguridad. Así que realmente, como parte de estos ejecutantes de élite, estaban incorporando una mejor seguridad en las aplicaciones desde el principio y podían ajustar y actualizar estas más frecuentemente. Así que realmente dedicaban menos tiempo en comparación con algunos de los ejecutantes de menor rendimiento en esta categoría.

Entonces, veamos qué es la mejora continua del código y cómo se relaciona con parte de las métricas de Dora. Tener errores en tu aplicación es parte de la vida. Todos sabemos que ocurren día tras día. Y lo que realmente queremos analizar es cómo mejorar a lo largo de nuestro proceso. Entonces, si estamos pasando por nuestras pruebas o nuestras canalizaciones de integración continua, ¿cómo estamos identificando estos problemas más temprano? ¿Qué sabemos sobre estas áreas? ¿Cómo los manejamos? Y cómo podemos mejorar en la comprensión de cómo solucionarlos rápidamente? Y eso, por supuesto, si pasamos a la puesta en escena, también queremos reducir nuestro riesgo a medida que nos acercamos al proceso de lanzamiento real y a las manos de nuestros clientes. Entonces, ¿cómo reducimos ese riesgo? Nuevamente, identificando errores a nivel de código, y no solo, por ejemplo, a nivel de integración u otros niveles que podríamos tener hoy en día. Y finalmente, cuando llegamos a la producción, ¿tenemos la capacidad de comprender tan pronto como ocurre un error, qué error es? ¿Podemos monitorear esas cosas? ¿Y cómo actuamos en consecuencia? Entonces, lo que necesitamos hacer es unir todas estas cosas para que podamos comenzar a comprender todo el proceso, cuáles son las verdaderas tasas de error, cuáles son los errores reales y cómo los solucionamos día tras día. Entonces, realmente necesitamos un proceso y una forma de asegurarnos de que nuestros equipos puedan pasar de ser equipos de bajo rendimiento a equipos de alto y élite rendimiento ayudándolos con la confianza para lanzar a producción con más frecuencia. Entonces, ¿cómo resolvemos este problema? Lo primero que tenemos que hacer es comprender qué salió mal cuando algo sale mal, y eso significa que debemos crear lo que llamamos una huella digital en un error. Así como un humano tiene una huella digital única, cada error debe tener una huella digital única, y ahí es donde comprendemos quién eres. ¿Te hemos visto antes? ¿Te he visto en las pruebas? ¿Te he visto en la puesta en escena? ¿O te he visto en producción varias veces? ¿Cuántos clientes se vieron afectados por este error? Entonces, necesitamos saber más sobre ti tan pronto como ocurras. Y, por supuesto, si eres un desarrollador y estás ocupado codificando algo, también tienes tu IDE, tienes tus trazas de pila, y es muy fácil depurar y solucionar un problema durante el ciclo de desarrollo. Y una vez que llegas a la puesta en escena y la producción, esto se vuelve exponencialmente más difícil. Entonces, lo que necesitamos es, tan pronto como ocurra algo, necesitamos contexto. ¿Cuál fue la línea de código, el código circundante que realmente causó este problema? ¿Quién cometió ese código por última vez? ¿Tenemos alguna información de seguimiento si tenemos microservicios? ¿Cuáles son las cosas que llevaron a este error? Todas las variables y todas esas cosas que se introdujeron allí. Idealmente, realmente queremos esa traza de pila completa a la que estamos acostumbrados como desarrolladores que escriben código día tras día. Y finalmente, como mencioné, queremos saber quién se vio afectado por un error. ¿Fue un cliente? ¿Fueron miles de clientes? Para que podamos mantener nuestros servicios en funcionamiento y asegurarnos de que estén en manos de nuestros clientes, generando ingresos para nuestros negocios. Entonces, la forma de resolver este problema es, en primer lugar, adentrarnos en el nivel de código. Muchas aplicaciones hoy en día tienen monitoreo fuera del nivel de código real, tal vez en contenedores. Lo que necesitamos hacer es mirar dentro del propio código real. Necesitamos estar en la aplicación durante la ejecución, mientras es utilizada por nuestros clientes, para poder identificar problemas en tiempo real. Eso significa

Entonces, ¿cómo empezamos con Rollbar? Puedes registrarte en Rollbar para obtener una cuenta gratuita utilizando tu cuenta de GitHub o cuenta de Google, y una vez que te registres en el sistema de Rollbar, puedes comenzar a elegir una de nuestras muchas SDK disponibles, y por supuesto, tenemos SDK para frontend, backend, aplicaciones móviles. Si piensas en Python, JavaScript, .NET, Java, React, React Native, aplicaciones de Android, aplicaciones de iOS, y la lista continúa. Tenemos una SDK para todos estos tipos de aplicaciones, y una vez que estés listo, puedes agregarlas allí. Por ejemplo, aquí puedo elegir mi SDK, y con un par de líneas de código, puedo habilitar Rollbar en mi aplicación hoy mismo, y una vez que lo hagas, comenzarás a obtener visibilidad de esos errores en tiempo real, y nuevamente, una vez que hayas incluido ese código, podrás obtener telemetría, podrás obtener toda la información que necesitas para tener visibilidad de lo que está saliendo mal cuando algo sale mal. Ahora, para aquellos que hoy en día, si visitas Rollbar.com/gitnation, tenemos una gran oferta para que comiences a probar Rollbar y obtengas algo de tiempo gratuito utilizando la plataforma también, así que no dudes en usar el código Rollbar.com/gitnation. Muchas gracias por tu tiempo hoy y gracias por ver esta sección sobre la aceleración de la calidad del código utilizando la matriz DORA.

Entonces, uno a uno, tres, nadie piensa que es muy fácil, así que la mayoría de las personas piensan que está alrededor de ocho, que es difícil, pero no extremadamente difícil. Es como alrededor de ocho, el 33 por ciento respondió eso, y el siete por ciento respondió que es muy difícil. Pero sí, la mayoría de las personas piensan que está entre ocho y siete, que es bastante difícil y un poco más difícil. Entonces, ¿qué opinas de eso, Nico?

Bueno, quiero decir, ciertamente refleja lo que estamos viendo. Creo que en general hemos mejorado como ingenieros, como equipos de software. Definitivamente somos mucho mejores en descubrir, ya sabes, específicamente ejecutando cosas a través de entornos de prueba, encontrando cosas más temprano, así que estamos mejorando. Pero cuando llegas a producción, ya sabes, para mucha gente todavía es difícil. Y nosotros en realidad hicimos una encuesta a desarrolladores, alrededor de mil desarrolladores en América del Norte y algunos internacionales, y gran parte de estos data habla, ya sabes, complementa lo que estamos viendo aquí con este problema, donde no lo hemos resuelto, todavía es bastante difícil de resolver, ya sabes, problemas en producción, específicamente en cuanto al tiempo que lleva entender qué salió mal en realidad, ya sabes, específicamente, ya sabes, como estamos escuchando sobre microservicios y muchos sistemas que se unen, ya sabes, no hemos resuelto esto realmente. Y creo que definitivamente hay una mejor manera para que los equipos comiencen a hacer esto. Así que ciertamente no es sorprendente, y ciertamente algo que hemos visto en nuestras encuestas a desarrolladores.

Sí, parece una respuesta general, como que es un poco difícil. Así que tengo una pregunta para ti. ¿Cómo se obtienen las huellas dactilares de los errores? ¿Significa usar las tareas de confirmación de Git?

Esa es una excelente pregunta. Entonces, en Rollbar, cuando decimos huella dactilar, piensa en ello como en un ser humano, cada persona es única. Y así es como Rollbar lo hace, en realidad inspeccionamos cada error, y tenemos IA y aprendizaje automático que se ejecutan en ellos, inspeccionando estos errores. Y luego entendemos a través de nuestro aprendizaje automático, si este es de hecho un error único o no. Así es como le damos una huella dactilar. Así que no tenemos que mirar el Git Sharp, no tenemos que mirar nada de eso, en realidad es Rollbar inspeccionando estos errores, y en realidad hemos procesado más de 100 mil millones de errores. Así que sabemos mucho sobre qué es un error único, ¿es lo mismo? ¿Lo hemos visto de nuevo? Pero ese es en realidad el proceso de cómo creamos una huella dactilar, esa identificación única para cualquier tipo de error o advertencia dentro de Rollbar.

De acuerdo, gracias. Y otra pregunta es, ¿cómo puedo obtener una puntuación DORA para mi equipo? Entonces, una puntuación DORA es algo que definitivamente puedes obtener hoy en día. Necesitas tener los data. Así que eso es lo primero, ¿verdad? Entonces, la puntuación DORA, todas esas métricas realmente dependen de tener los data disponibles. Lo primero que debes hacer es, si miras cada una de esas cuatro categorías, comienza de manera muy simple a poner las cosas en su lugar, puedes recopilarlas. Y siempre digo, debes hacer esto con el tiempo. No puedes simplemente tomar una instantánea una vez al año y decir que está bien. Esta es una actividad semanal, mensual, donde quieres ver estas puntuaciones. Así que lo primero es implementar cosas que te ayuden a obtener los data. Una vez que comiences a obtener estos data, puedes generar

De acuerdo, gracias. Entonces, John Gautier preguntó, ¿significa que si estoy usando Rollbar en mi equipo, podría tener la misma huella dactilar que nunca de otro equipo en otra empresa? No, sabemos que el error es único para tu proyecto, ¿verdad? Sabemos que el mismo error podría haber ocurrido con otra persona. Así que en realidad conocemos el error, pero será único para tu proyecto o tu cuenta. Lo bueno de Rollbar es que estamos trabajando en algunas cosas muy inteligentes para el futuro, donde conoceremos sobre un error, porque muchas de estas excepciones son bastante comunes. Muchas personas se encuentran con las mismas cosas. Así que vamos a mejorar en mostrarte cómo solucionarlos, de hecho, y cuál es la forma correcta de solucionarlos y algunas de las soluciones que la mayoría de las personas utilizan para resolver ese problema. Pero las huellas dactilares son únicas para tus cuentas, ¿verdad? Tu proyecto tendrá sus propias huellas dactilares únicas. Pero en el backend aprendemos mucho sobre los errores, los entendemos, eliminamos todas las variables, ¿verdad? Todas las cosas que podrías decir, bueno, eso es diferente para nosotros. Eliminamos todas esas, podemos llegar a la excepción principal para realmente entender cuál es la excepción, qué sucedió y cómo hacerlo.