Para ser honesto, Iván a menudo se reía de los esfuerzos inútiles de sus colegas del departamento de monitoreo. Hicieron grandes esfuerzos para implementar las métricas que la dirección de la empresa les ordenó alcanzar. Estaban tan ocupados que no querían que nadie más hiciera nada.
Pero esto no fue suficiente para la gerencia: constantemente ordenaron más y más métricas nuevas y muy rápidamente dejaron de utilizar lo que se había hecho anteriormente.
Últimamente, todo el mundo ha estado hablando de LeadTime: el momento de la entrega de funciones empresariales. La métrica mostró una cifra disparatada: 200 días para realizar una tarea. ¡Cómo todos exclamaron y exclamaron y levantaron sus manos al cielo!
Después de un tiempo, el ruido se calmó gradualmente y la gerencia recibió la orden de crear otra métrica.
Para Ivan estaba completamente claro que la nueva métrica moriría silenciosamente en un rincón oscuro.
De hecho, pensó Iván, saber el número no le dice nada a nadie. 200 días o 2 días: no hay diferencia, porque es imposible determinar el motivo por el número y entender si es bueno o malo.
Ésta es una trampa típica de las métricas: parece que una nueva métrica contará la esencia de la existencia y explicará algún secreto secreto. Todo el mundo tiene muchas esperanzas en esto, pero por alguna razón no sucede nada. ¡Sí, porque el secreto no debe estar en las métricas!
Para Iván esta era una etapa superada. el entendio que para las mediciones, y todos los secretos deben buscarse en , es decir. es que se forma esta métrica.
Para una tienda en línea, el objeto de influencia serán sus clientes que aportan dinero, y para DevOps, serán los equipos que crean e implementan distribuciones utilizando un canal.
Un día, sentado en una cómoda silla en el pasillo, Iván decidió pensar detenidamente cómo quería ver las métricas de DevOps, teniendo en cuenta el hecho de que el objeto de influencia son los equipos.
Propósito de las métricas de DevOps
Está claro que todo el mundo quiere reducir el tiempo de entrega. 200 días, por supuesto, no sirven.
Pero ¿cómo?, ¿esa es la pregunta?
La empresa emplea cientos de equipos y miles de distribuciones pasan por el proceso de DevOps todos los días. El tiempo de entrega real aparecerá como una distribución. Cada equipo tendrá su propio tiempo y sus propias características. ¿Cómo puedes encontrar algo entre este lío?
La respuesta surgió de forma natural: necesitamos encontrar los equipos problemáticos y descubrir qué les sucede y por qué lleva tanto tiempo, y aprender de los equipos "buenos" cómo hacer todo rápidamente. Y para ello es necesario medir el tiempo empleado por los equipos en cada uno de los stands de DevOps:
“El objetivo del sistema será seleccionar los equipos en función del tiempo que pasen por las gradas, es decir. Como resultado, deberíamos obtener una lista de comandos con el tiempo seleccionado, y no un número.
Si averiguamos cuánto tiempo se pasó en total en el stand y cuánto tiempo se pasó en el tiempo de inactividad entre los stands, podemos encontrar los equipos, llamarlos, entender con más detalle los motivos y eliminarlos”, pensó Iván.
Cómo calcular el tiempo de entrega para DevOps
Para calcularlo fue necesario profundizar en el proceso DevOps y su esencia.
La empresa utiliza un número limitado de sistemas y la información sólo se puede obtener de ellos y de ningún otro lugar.
Todas las tareas de la empresa quedaron registradas en Jira. Cuando se asumía una tarea, se creaba una rama para ella y, después de la implementación, se realizaba una confirmación en BitBucket y Pull Request. Cuando se aceptaba una PR (Pull Request), se creaba automáticamente una distribución y se almacenaba en el repositorio de Nexus.
A continuación, la distribución se implementó en varios stands utilizando Jenkins para verificar la exactitud del lanzamiento, pruebas automáticas y manuales:
Iván describió de qué sistemas se puede extraer información para calcular el tiempo en las gradas:
- Desde Nexus: hora de creación de la distribución y nombre de la carpeta que contenía el código de comando
- Desde Jenkins: hora de inicio, duración y resultado de cada trabajo, nombre del stand (en los parámetros del trabajo), etapas (pasos del trabajo), enlace a la distribución en Nexus.
- Ivan decidió no incluir a Jira y BitBucket en el proceso, porque... estaban más relacionados con la etapa de desarrollo que con el despliegue de la distribución terminada en los stands.
Con base en la información disponible se elaboró el siguiente diagrama:
Sabiendo cuánto tiempo lleva crear distribuciones y cuánto tiempo se dedica a cada una de ellas, puede calcular fácilmente los costos totales de recorrer todo el proceso de DevOps (ciclo completo).
Estas son las métricas de DevOps con las que terminó Ivan:
- Número de distribuciones creadas
- Proporción de distribuciones que “llegaron” al stand y “pasaron” el stand
- Tiempo de permanencia en el stand (ciclo de stand)
- Ciclo completo (tiempo total para todos los stands)
- Duración del trabajo
- Tiempo de inactividad entre stands
- Tiempo de inactividad entre lanzamientos de trabajos en el mismo stand
Por un lado, las métricas caracterizaron muy bien el proceso de DevOps en términos de tiempo, por otro lado, se consideraron muy simples.
Satisfecho con el trabajo bien hecho, Iván hizo una presentación y fue a presentarla a la dirección.
Regresó lúgubre y con las manos gachas.
“Esto es un fiasco, hermano”, sonrió irónico el colega...
Lea más en el artículo “".
Fuente: habr.com