1. Introduction to Dora Metrics
Hola a todos. Mi nombre es Niko Kruger. Hoy voy a hablar sobre cómo acelerar la calidad del código con las métricas de Dora. Exploraremos qué es Dora y su relación con la mejora continua del código. También discutiremos los beneficios de convertirse en un ejecutante de élite y el camino para acelerar la calidad de tu código.
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.
2. Metrics and Benefits of High and Elite Performers
El tiempo de entrega de las características a los clientes es una métrica crucial. Desplegar con mayor frecuencia y medir la tasa de fallos en los cambios y el tiempo de restauración de los servicios también es importante. Los ejecutantes de alto y élite despliegan a demanda y múltiples veces al día, mientras que los ejecutantes de bajo rendimiento lo hacen una vez al mes o cada seis meses. Los ejecutantes de alto rendimiento tienen un tiempo de entrega de cambios de menos de un día, mientras que los ejecutantes de bajo rendimiento tardan más de un mes a seis meses. Los ejecutantes de alto y élite tienen una tasa de fallos en los cambios de cero a 15%, mientras que los ejecutantes de bajo rendimiento tienen una tasa del 50 al 60%. Los ejecutantes de alto y élite también tienen un proceso automatizado o semiautomatizado para restaurar los servicios, mientras que los ejecutantes de bajo rendimiento tardan más de una semana. Convertirse en un ejecutante de alto y élite permite desplegar con mayor frecuencia y entregar características a los clientes más rápidamente, lo que proporciona una ventaja competitiva significativa.
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.
3. Accelerando la Calidad del Código y la Resolución de Errores
La investigación reveló que los equipos de alto rendimiento se recuperan 2.6 veces más rápido y tienen una tasa de fallos en los cambios 7 veces menor. También dedican un 50% menos de tiempo a solucionar problemas de seguridad. La mejora continua del código implica identificar y solucionar errores en todo el proceso, reduciendo el riesgo en el entorno de pruebas y producción, y comprendiendo las tasas de error y los errores reales. Para resolver este problema, se crea una huella digital única para cada error, proporcionando contexto como la línea de código, el desarrollador responsable y el impacto en los clientes. Al examinar el código mismo, se pueden identificar problemas en tiempo real, lo que permite una acción inmediata.
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
4. Beneficios de la Mejora Continua del Código
Podemos dar a los errores una huella digital y comprender su gravedad e impacto. Esto nos permite responder rápidamente y poner los sistemas en funcionamiento nuevamente. Al tener visibilidad de los errores, podemos tomar medidas inmediatas, como crear tickets, ver registros y recopilar información de trazado. La mejora continua del código tiene muchos beneficios, incluyendo la reducción del riesgo de perder clientes, la optimización de la productividad de los desarrolladores y la generación de confianza en los lanzamientos. A través de este proceso, las organizaciones pueden esperar un aumento en las tasas de implementación, una mejor visibilidad de los errores, tiempos de detección y respuesta más rápidos, y una reducción significativa del tiempo dedicado a corregir errores.
En tan solo uno a tres segundos, tan pronto como ocurre algo, podemos recopilar ese error. Podemos darle una huella digital. Podemos entender qué es, qué tan importante es. Es decir, cuál es la gravedad y cuál es el impacto de ello. Y luego actuar sobre ese elemento. Entonces, ¿qué hacemos al respecto? Y esta es una excelente manera de comenzar a no solo poder responder muy rápidamente para detectar errores rápidamente, sino también responder, poner un sistema en funcionamiento nuevamente, porque realmente sabemos qué salió mal y cuáles fueron esos problemas. Y, por supuesto, queremos asegurarnos de que una vez que sepamos acerca de estos errores, ¿puedo ver la línea de código, el último cambio realizado, quién lo hizo? ¿Puedo crear, por ejemplo, un ticket en cualquier sistema de tickets? ¿Puedo ver los registros circundantes, los registros de rendimiento? Si fue más un problema ambiental, por ejemplo, ¿quiero tener toda la información de trazado para los microservicios? Entonces, necesitamos cada vez más información para ayudarnos a automatizar este proceso. A medida que los equipos comienzan a hacer esto, algunos de los beneficios que hemos visto, cuando hicimos una encuesta a unos mil desarrolladores de todo el mundo para preguntarles, ya sabes, ¿qué son algunas de las cosas que les quitan el sueño, que les preocupan? Y también algunos de los beneficios que han visto de la mejora continua del código. Y una de las primeras cosas que realmente destacó fue, ya sabes, alrededor del 34% de los desarrolladores dijeron que el mayor riesgo para ellos de un error o bug es perder clientes. Sabemos que eso es el sustento de nuestros negocios. Ya sabes, así que queremos asegurarnos de mantener a nuestros clientes comprometidos. Que puedan usar nuestro software. Y muchas veces, si un cliente encuentra un problema, ni siquiera nos lo notificará. Podrían intentar solucionarlo por sí mismos. Es posible que no registren un ticket para resolverlo. Y a menudo se pueden perder esos clientes. Entonces, necesitamos brindarles una mejor experiencia de usuario desde el principio. Entonces, necesitamos poder gestionar estos problemas a medida que surgen en tiempo real de manera proactiva, lo que significa que los encontraremos antes de que un cliente los encuentre. Y a veces incluso podemos solucionarlos antes. El siguiente es que alrededor del 37% dijo que pasan más del 25% de su tiempo solo corrigiendo errores. Eso es una cantidad tremenda de esfuerzo desperdiciado que podría haberse invertido en el desarrollo de funciones, mejorando otras cosas en la aplicación, y que ahora se gasta en retrabajo o volver a hacer parte del trabajo que ya se ha realizado. Y eso es un número tremendamente grande cuando se tiene en cuenta los costos de los desarrolladores día tras día durante un período de 12 meses o incluso más. Entonces, realmente queremos centrarnos en hacer que nuestros ingenieros sean lo más productivos posible. Y finalmente, alrededor del 84% de los desarrolladores dijeron que se ven frenados para pasar a una categoría de élite o de alto rendimiento al implementar con más frecuencia, por ejemplo, porque simplemente no tienen la confianza, lo que llamamos confianza en el lanzamiento, de que cuando implementen estos elementos en vivo, realmente tengan la confianza de que si algo sale mal, lo sabrán rápidamente, no a través de un cliente, sino en tiempo real, recibir una notificación y luego, lo que es más importante, poder hacer algo al respecto. Entonces, ¿cómo automatizamos? ¿Hacemos un rollback, tal vez desactivamos una bandera de función? ¿Cómo logramos inculcar esa confianza en nuestros grupos de ingeniería? Cuando emprendas este viaje, ¿qué cosas deberías esperar obtener de este viaje? Ahora, para la mayoría de nuestros clientes que han comenzado este viaje, han visto, por ejemplo, que las tasas de implementación aumentan desde un 50% hasta aproximadamente un 95% de tasas de implementación exitosas. Entonces, eso te brinda una confianza mucho mayor de que puedes lanzar con más frecuencia, pero también que tus implementaciones serán de buena calidad y podrás manejar cualquier problema que surja. También han experimentado una de las cosas más importantes que escuchamos es la capacidad de que simplemente no sabía, no tenía visibilidad cuando algo salía mal. A menudo, pasará una hora o más, a veces días, antes de que sepamos que hay un problema, porque estamos esperando a que los clientes revisen los registros, y lo que hemos visto de nuestros clientes, el tiempo de detección de un error, responder a él, a menudo se reduce a unos cinco minutos en un escenario de producción, y eso es un ahorro de tiempo masivo. Si sabemos algo, podemos responder y asegurarnos de abordar los errores más impactantes muy, muy rápidamente. La otra parte que hemos visto es que podemos tomar ese 20, 25 a 40% de tiempo que los desarrolladores dedican a corregir errores y reducirlo a aproximadamente el 10% de su tiempo, porque es más rápido saber sobre estos errores, más rápido encontrar la línea exacta de código donde está el problema y solucionarlo en lugar de intentar revisar los registros o intentar
5. Rollbar: Mejora Continua del Código
Rollbar es una plataforma de mejora continua del código que proporciona visibilidad en tiempo real de errores accionables. Puedes registrarte para obtener una cuenta gratuita y elegir entre varias SDK para habilitar Rollbar en tu aplicación. Al incluir el código, obtendrás visibilidad de los errores y acceso a telemetría para entender qué está saliendo mal. Visita Rollbar.com/gitnation para obtener una oferta especial de prueba de Rollbar. Gracias por ver esta sección sobre la aceleración de la calidad del código.
para descubrir qué sucedió realmente al unir todas las piezas. Por lo tanto, un ahorro de tiempo tremendo que también se obtiene al analizar el código en sí, entender qué está saliendo mal y, por lo tanto, esos beneficios realmente se suman durante un período de 12 meses. Siempre decimos, ¿cómo empezamos este proceso? Entonces, podemos comenzar este viaje bastante rápido. Es un solo paso para empezar, y voy a mostrarte cómo puedes hacerlo con Rollbar. Entonces, ¿qué es Rollbar? Rollbar es una plataforma de mejora continua del código. Fundamentalmente, te ayudaremos a obtener visibilidad de tu aplicación tan pronto como ocurra el error, ya sea manejado o no manejado, y podremos ayudarte a hacer algo al respecto. Nos aseguraremos de que sean accionables. Los agruparemos automáticamente. Vamos a eliminar el ruido al que estás acostumbrado con las herramientas de registro tradicionales donde estás esperando que algo suceda. Con Rollbar, obtendrás visibilidad en tiempo real de estos errores que realmente son accionables, con detalles para ayudarte a resolverlos mucho más rápido de lo que estás acostumbrado hoy en día.
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.
Desafíos y Soluciones en Producción
La mayoría de las personas piensan que es bastante difícil resolver problemas en producción. Rollbar inspecciona cada error y utiliza IA y aprendizaje automático para darle una huella única. Para obtener una puntuación DORA, necesitas tener los datos e implementar herramientas para recopilarlos.
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
Usando Métricas DORA y Rollbar
El equipo de DORA proporciona varios paneles y herramientas, incluido Rollbar, para recopilar métricas y mejorar la calidad del código con el tiempo.
puedes hacer esto a través de Excel, o puedes usar algunas herramientas de paneles. De hecho, el equipo de DORA tiene varios paneles disponibles. Y también hay otras herramientas que puedes usar. Puedes obtener
data de algo como Rollbar, por ejemplo. También podemos proporcionarte algunas de esas métricas, si las informas en Rollbar. Pero ese es el lugar para comenzar, y asegúrate de hacer esto con el tiempo. Porque para mejorar, necesitamos una línea de base, ¿verdad? Necesitamos entender dónde estábamos. ¿A dónde vamos? ¿Algo está funcionando? ¿No está funcionando? Así que podemos, entonces, visualmente comenzar a ver y solucionar problemas y mejorar con el tiempo.
Unique Error Fingerprints and Advanced Features
Rollbar proporciona huellas dactilares únicas para errores, que son específicas de tu proyecto o cuenta. Si bien el mismo error puede haber ocurrido en otro lugar, las características avanzadas de Rollbar ayudan a identificar excepciones comunes y proporcionar soluciones. El backend aprende de los errores, elimina variables y se enfoca en la excepción principal, lo que permite una comprensión más profunda del problema y cómo resolverlo.
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.
Rollbacks and the Development Life Cycle
Rollback se utiliza en todo el ciclo de vida del desarrollo. En un mundo ideal, cada error se detectaría en la preproducción y en las pruebas, pero esa no es la realidad. Las organizaciones grandes que ejecutan rollback en el entorno de QA pueden comprender y clasificar los errores desde el principio. Algunos errores pueden pasar desapercibidos debido a variables en producción, el comportamiento del usuario o sistemas externos. Los rollbacks actúan como una red de seguridad, permitiendo a los equipos identificar rápidamente si algo ha salido mal. Si el error es conocido, los rollbacks pueden proporcionar información sobre cómo solucionarlo, reduciendo el tiempo de resolución. Tener un sistema en producción para capturar errores omitidos en QA es esencial.
lo solucionas. De acuerdo, perfecto. Y otra pregunta de Eva es, ¿estos errores no serían capturados por pruebas automatizadas en una prueba unitaria? ¿Qué me falta entender sobre el caso de uso de rollback? Absolutamente. El rollback se utiliza en todo el ciclo de vida del desarrollo. Entonces tienes toda la razón. En un mundo ideal, capturaríamos cada error en la preproducción y
testing, de hecho, en nuestras pruebas unitarias, pero esa no es la realidad, ¿verdad? Así que para la mayoría de nuestros clientes, de hecho, las grandes organizaciones que lanzan, ya sabes, 4,000 veces en una semana determinada, por ejemplo, ejecutan rollback en el entorno de
QA. Así que comienzan a comprender estos errores desde muy temprano para poder clasificarlos. Y a medida que avanzas hacia la producción, pueden saber, ¿lo he visto antes? ¿Qué hago al respecto? Pero tienes razón. Algunos errores deberían ser detectados en las
testing, pero a menudo, hay alguna variable que, ya sabes, hace que la producción sea ligeramente diferente, los usuarios utilizan el sistema de manera diferente. Es posible que estés interactuando con sistemas externos o micro servicios que hacen que estas cosas pasen desapercibidas. Y piensa en los rollbacks como tu red de seguridad, ¿verdad? Es lo primero en lo que la gente se fija, tan pronto como se implementa, para saber si algo ha salido mal específicamente. Y esperemos que no, pero el rollback es tu red de seguridad. Y algo bueno del rollback es que, si ya lo conocíamos, a menudo podemos decirte cómo lo solucionaste antes. Así que en realidad tu tiempo para solucionarlo se ha reducido considerablemente, lo cual es bastante bueno. Pero definitivamente quieres algo en producción que te ayude
Rollbar: Visibilidad de la Calidad de la Versión
Rollbar te ayuda a comprender la verdadera calidad de tu código al proporcionar visibilidad instantánea de los errores. Siendo proactivo, puedes solucionar problemas antes de que los clientes los reporten. Rollbar es ampliamente utilizado por el equipo de Rollbar, capturando errores en diversas aplicaciones y proyectos. Contacta a Nico en Discord o en el canal de preguntas y respuestas para cualquier pregunta adicional.
capturas las cosas que potencialmente pasaste por alto en
QA. Bueno, eso suena genial. Y la última pregunta será, ¿puedes ayudar a mi equipo con la visibilidad de la calidad de la versión? Absolutamente. Entonces, ya sabes, el objetivo es lanzar código de calidad rápidamente, ¿verdad? Y es algo que tiene valor. Así que definitivamente, Rollbar es lo que te ayudará a comprender cuál es la verdadera calidad. ¿Por qué digo eso? Es porque Rollbar está dentro de tu aplicación en tiempo de ejecución, ¿verdad? Entonces, a medida que lo lanzas y las personas comienzan a usar la aplicación, tus clientes sabrán de un error antes que nadie más. Y te diremos que tus clientes incluso te informarán sobre ese error. Así que te brindaremos esa visibilidad instantánea de un error y luego puedes hacer algo al respecto. Ser proactivo, es decir, puedes solucionarlo antes de que alguien registre un ticket de soporte, y así sucesivamente. Pero así es como lo hacemos. Y sabes, algunas de las empresas más grandes y mejores tienen esa mentalidad muy proactiva para encontrar cosas antes que sus clientes y luego solucionarlos, lo cual es realmente bueno. Gracias. Y la última pregunta para Metin es ¿estás utilizando Rollbar en robots? Oh, absolutamente. Rollbar se utiliza ampliamente en Rollbar. De hecho, nos encantaría que vinieras y hablaras con nosotros. Te mostraremos cómo usamos Rollbar. De hecho, capturamos todo, desde nuestro sitio web hasta nuestras aplicaciones internas de Rollbar. Cualquier fragmento de código que lanzamos, ya sea un proyecto de código abierto en el que trabajamos, siempre ponemos Rollbar. Y eso nos ayuda a mejorar cada día y a encontrar estos errores. Así que definitivamente. Me encantaría mostrarte cómo lo estamos usando. Genial. Gracias. Si alguien tiene más preguntas, no dudes en contactar a Nico en Discord o hacer tus preguntas en el canal de preguntas y respuestas. Gracias, Nico. Adiós. Muchas gracias, Liz. Adiós.
DevOps.js Conf 2022
