{"id":36025,"date":"2019-10-31T22:09:12","date_gmt":"2019-10-31T19:09:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/metriki-devops-otkuda-brat-dannye-dlya-raschetov\/"},"modified":"2019-10-31T22:09:12","modified_gmt":"2019-10-31T19:09:12","slug":"metriki-devops-otkuda-brat-dannye-dlya-raschetov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/metriki-devops-otkuda-brat-dannye-dlya-raschetov","title":{"rendered":"M\u00e9tricas DevOps: de d\u00f3nde obtener datos para los c\u00e1lculos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Honestamente, Iv\u00e1n a menudo se re\u00eda de los esfuerzos in\u00fatiles de sus colegas del departamento de monitoreo. Hac\u00edan un gran esfuerzo para implementar las m\u00e9tricas que la direcci\u00f3n de la empresa les encargaba. Estaban tan ocupados que no quer\u00edan hacer nada m\u00e1s. <\/p>\n

Y la direcci\u00f3n nunca estaba satisfecha: siempre ped\u00eda nuevas m\u00e9tricas, dejando r\u00e1pidamente de utilizar las que ya se hab\u00edan creado.<\/p>\n

\u00daltimamente, solo se hablaba del LeadTime: el tiempo de entrega de funcionalidades empresariales. La m\u00e9trica mostr\u00f3 un n\u00famero incre\u00edble: 200 d\u00edas para entregar una tarea. \u00a1Qu\u00e9 asombro y qu\u00e9 desesperaci\u00f3n se dio entre todos!<\/p>\n

Despu\u00e9s de un tiempo, el ruido se apag\u00f3 gradualmente y desde la direcci\u00f3n lleg\u00f3 el encargo de crear otra m\u00e9trica.<\/p>\n

A Iv\u00e1n le qued\u00f3 claro que la nueva m\u00e9trica tambi\u00e9n morir\u00eda silenciosamente en un rinc\u00f3n oscuro.<\/p>\n

En efecto, reflexionaba Iv\u00e1n, saber un n\u00famero no significa nada para nadie. 200 d\u00edas o 2 d\u00edas: no hay ninguna diferencia, porque no se puede determinar la causa ni comprender si es bueno o malo solo a partir del n\u00famero.<\/p>\n

Esta es la trampa t\u00edpica de las m\u00e9tricas: parece que la nueva m\u00e9trica revelar\u00e1 la esencia de la existencia y explicar\u00e1 alg\u00fan secreto oculto. Todos tienen grandes esperanzas, pero por alguna raz\u00f3n nada sucede. \u00a1Porque el secreto no hay que buscarlo en las m\u00e9tricas!<\/p>\n

Para Iv\u00e1n, esto era algo que ya hab\u00eda pasado. Entend\u00eda que las m\u00e9tricas son simplemente una regla de madera com\u00fan<\/a><\/noindex> para medir, y todos los secretos deben buscarse en el objeto de influencia<\/a><\/noindex>, es decir, en lo que forma esa m\u00e9trica.<\/p>\n

Para una tienda en l\u00ednea, el objeto de influencia son sus clientes que generan ingresos, y para DevOps, son los equipos que crean y despliegan distribuciones utilizando la tuber\u00eda.<\/p>\n

Una vez, acomod\u00e1ndose en un sill\u00f3n c\u00f3modo en el vest\u00edbulo, Iv\u00e1n decidi\u00f3 pensar detenidamente c\u00f3mo le gustar\u00eda ver las m\u00e9tricas de DevOps teniendo en cuenta que el objeto de influencia son los equipos.<\/p>\n

El objetivo de las m\u00e9tricas DevOps<\/h2>\n

\nEst\u00e1 claro que todos quieren reducir el tiempo de entrega. 200 d\u00edas, por supuesto, no es aceptable. <\/p>\n

Pero \u00bfc\u00f3mo, esa es la cuesti\u00f3n?<\/a><\/noindex><\/p>\n

En la empresa trabajan cientos de equipos, y a trav\u00e9s del canal DevOps pasan miles de distribuciones al d\u00eda. El tiempo de entrega real se ver\u00e1 como una distribuci\u00f3n. Cada uno de los equipos tendr\u00e1 su propio tiempo y caracter\u00edsticas espec\u00edficas. \u00bfC\u00f3mo encontrar algo en medio de este l\u00edo?<\/p>\n

La respuesta surgi\u00f3 por s\u00ed sola: es necesario identificar los equipos problem\u00e1ticos y entender qu\u00e9 les sucede y por qu\u00e9 tardan tanto, mientras que de los equipos 'buenos' aprender a hacer todo r\u00e1pidamente. Para ello, es necesario medir el tiempo que cada equipo pasa en cada uno de los stands de DevOps:<\/p>\n

\"M\u00e9tricas
\n
\n\u00abEl objetivo del sistema ser\u00e1 seleccionar equipos seg\u00fan el tiempo de paso por los stands, es decir, al final debemos obtener una lista de equipos con el tiempo seleccionado, y no un n\u00famero.<\/p>\n

Si averiguamos cu\u00e1nto tiempo se ha pasado en total en un stand y cu\u00e1nto tiempo se ha perdido en inactividad entre stands, podremos encontrar a los equipos, contactarlos y profundizar en las razones para solucionarlas\u00bb, pens\u00f3 Iv\u00e1n.<\/p>\n

\"M\u00e9tricas
\n <\/p>\n

C\u00f3mo calcular el tiempo de entrega para DevOps<\/h2>\n

Para poder calcularlo, era necesario profundizar en el proceso de DevOps y sus entidades.<\/p>\n

La empresa utiliza un n\u00famero limitado de sistemas, y la informaci\u00f3n solo se puede obtener de ellos y de ning\u00fan otro lugar.<\/p>\n

Todas las tareas en la empresa se registraban en Jira. Cuando se comenzaba a trabajar en una tarea, se creaba una rama para ella, y despu\u00e9s de implementarla, se hac\u00eda un commit en BitBucket y un Pull Request. Al aceptar el PR (Pull Request), se generaba autom\u00e1ticamente una distribuci\u00f3n y se guardaba en el repositorio Nexus. <\/p>\n

\"M\u00e9tricas
\n
\nLuego, la distribuci\u00f3n se desplegaba en varios stands con ayuda de Jenkins para verificar la correcta aplicaci\u00f3n, pruebas autom\u00e1ticas y manuales:<\/p>\n

\"M\u00e9tricas
\n
\nIv\u00e1n detall\u00f3 de qu\u00e9 sistemas se pod\u00eda obtener qu\u00e9 informaci\u00f3n para calcular el tiempo en los stands:<\/p>\n