BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

Lo básico Póngase al día con nuestro contenido introductorio.

¿El secreto para las métricas DevOps? Es fácil, solo úselas

El defensor de rendimiento de DynaTrace, Andreas Grabner, viaja por el mundo corriendo la voz acerca de los datos DevOps. Sin embargo, incluso él está sorprendido por cómo pocas empresas están realmente prestando atención.

Andreas Grabner, defensor de rendimiento en DynaTrace, pasa mucho tiempo viajando por el mundo hablando con los equipos de desarrollo sobre la importancia de las métricas DevOps. Su mensaje es simple: Los datos están ahí fuera, y los grupos pueden utilizarlos para mejorar el rendimiento y para llegar a mejores ideas. Pero la clave es realmente usar los datos, no solo adivinar al azar. Grabner llevó su mensaje a la Conferencia JavaOne de este año, en una sesión titulada “Entrega impulsada por métricas para detener temprano el mal código y las malas ideas”. La editora senior de tecnología, Valerie Silverthorne, le hizo algunas preguntas antes de su presentación.

Usted ha pasado mucho tiempo hablando sobre métricas DevOps, y hace un gran caso, pero, obviamente, siente que necesita hacer el caso. ¿Por qué, si hay tantas herramientas/opciones, NO está cada empresa haciendo esto? ¿Cuál es el retraso?

Andreas Grabner: Créeme, estoy sorprendido y conmocionado cada vez que veo ojos que se abren cuando les recuerdo sobre el poder de las métricas.

Después de la conversación sobre DevOps (DevOpsDays en Boston), tuve un equipo de una gran compañía aérea de EE.UU. que se acercó a mí. Ellos están pasando por una transformación en este momento, pero no han pensado en absoluto sobre el monitoreo, sobre todo al principio y a lo largo de la tubería. Lo mismo acaba de pasar en mi viaje actual a América del Sur. Me reuní con tres bancos importantes que pasaron por una transformación digital [y están] adoptando DevOps. Todos ellos no han pensado en el poder de las métricas cuando se aplican al monitoreo de la producción básica.

Creo que la gente está demasiada centrada en asegurarse de que un nuevo proyecto puede salir por la puerta más rápido que la forma en que se desarrollaba el software en el pasado. En un principio, todo el mundo quiere asegurarse de probar que DevOps conduce a una innovación más rápida. Las métricas, sin embargo, son su red de seguridad, ya que le dicen si lo que está haciendo en realidad tiene sentido, tiene la calidad adecuada y ofrece valor.

"Detener malas ideas temprano”, gran concepto; pero en un equipo DevOps del mundo real, o un equipo que trata de pasar a DevOps, ¿qué toma realmente lograr eso?

Grabner: Es simple. Cada equipo de aplicación o función tiene que sentarse y responder a esta pregunta: ¿Cuál es el criterio de éxito de esta característica y cómo lo medimos? ¿Es el número de usuarios que lo utilizan dentro de la primera semana? ¿Es la reducción de los requisitos de hardware? ¿Se trata de escalabilidad?

Si el equipo de características consigue estas respuestas a través de métricas DevOps justo después de que han desplegado una nueva función/idea, se puede sacar la conclusión adecuada; ¿construimos lo correcto que la gente ama o nadie lo está usando? ¿La nueva función/aplicación funciona de manera eficiente (CPU, memoria, disco, almacenamiento...) o nos cuesta más ejecutar esta de lo que realmente ganamos?

¿Estamos en peligro, con todas estas fabulosas herramientas y, por lo tanto, métricas, de entrar en una situación de "demasiada información" cuando se trata de desarrollo e implementación de software? Y si eso sucede, ¿cuál es la respuesta?

Grabner: Sí y no. Si usted solo vuelca miles de métricas en los equipos, los abruma. Por eso creo que los equipos tienen que empezar a responder la sencilla pregunta que hice [arriba]; ¿cómo podemos medir el éxito de esta nueva función/idea/app?

El éxito, sin embargo, significa dos cosas: a) el número de usuarios que utilizan la nueva característica y están, por tanto, creando valor para el negocio; y b) el costo del funcionamiento de esa característica. Eso se puede medir con el número de instancias de servidor [o] el número de bytes transferidos o filas almacenadas en la base de datos. Especialmente cuando se ejecutan en entornos de nube/virtuales, esto se vuelve muy importante, ya que tiene que calcular el costo por usuario/función en estos entornos dinámicos y elásticos.

Otra solución para "la sobrecarga de datos" es la aplicación de analítica inteligente en métricas. Eso es lo que los proveedores de herramientas –incluyendo Dynatrace– han estado haciendo el último año. En lugar de mostrarle las métricas en bruto, destacamos los problemas y entregamos la causa raíz. Por ejemplo, nuestra herramienta escupe: "Hey Andi, su último cambio de código acaba de presentar el patrón de consulta N+1 en su nuevo microservicio de back end. Si se mantiene empujando esto, necesitará un 50% más de instancias de Amazon, teniendo en cuenta la carga que se espera".

Próximos pasos

Más sobre DevOps:

Profesionales de operaciones de TI deben adaptarse con nuevas habilidades DevOps

Tome estos 10 pasos para construir su carrera DevOps

Construir un entorno DevOps con microservicios y contenedores

Gartner: DevOps es bueno; DevSecOps es mejor

Este artículo se actualizó por última vez en septiembre 2016

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close