Ivan trabajó en una gran organización en un departamento relacionado con DevOps. Todos los días, miles de empleados utilizaron herramientas DevOps para crear, probar e implementar su software.
Miles de distribuciones por día que pasaban por la línea de montaje era una situación normal.
Sin embargo, donde hay un gran poder, también hay una gran responsabilidad. Las inevitables dificultades de los equipos resultaron en cientos de llamadas de soporte técnico por día.
Naturalmente, a muchos no les gustaban las herramientas DevOps. Alguien dijo que son demasiado defectuosos, mientras que otros creyeron que puedes prescindir de ellos, y será mucho más rápido.
La gerencia de la compañía entendió que el 100% de los equipos no podían estar satisfechos con DevOps, sin embargo, no había datos exactos. Sería agradable ver los problemas en la línea de ensamblaje, pero ni siquiera se conocía el número habitual de distribuciones que se realizaban por día. ¿Qué podemos decir sobre las métricas serias?
La pregunta sobre las métricas de DevOps se planteó constantemente: todos las necesitaban mucho.
Ivan, como empleado que conoce métricas y conoce la tecnología DevOps, participó de cerca en la preparación del proyecto.
Junto con los administradores de DevOps, ideó una posible arquitectura de solución y también estudió una gran cantidad de literatura sobre métricas de DevOps. No había un solo artículo en Internet ni un solo libro sobre este tema que él no leyera.
Como resultado, nació una solución técnica completa, que Ivan presentó a la gerencia.
Todo se ha ido
La reacción de la administración fue inesperada: no se tomó ninguna decisión sobre la implementación.
"Este es un fiasco, hermano", dijo el buen colega con una sonrisa, dejando a Ivan de la reunión.
A pesar de la ironía, tenía razón. Si no se toma la decisión, hubo algún tipo de disuasión que Ivan no vio y no tuvo en cuenta.
La gerencia estaba convencida de la viabilidad técnica de implementar métricas DevOps, pero aún lo dudaba.
Y esto fue causado por una razón muy simple: la solución técnica mostró que la implementación, aunque posible, requeriría una gran cantidad de recursos humanos y técnicos, es decir. será querido Pero si habrá algún resultado útil real de esto es una gran pregunta.
Cuando se trata de un proyecto costoso, entonces:
- Las presentaciones no son impresionantes.
- Los diseños de pantalla no son impresionantes.
- Los ejemplos no son impresionantes.
En general, el inicio del proyecto se pospuso indefinidamente. La tarea le pareció a Ivan completamente irresoluble.
Caso fatídico
Todo se decidió por casualidad. Una vez, una carta llegó a la oficina de correos indicando que dos estudiantes fueron llevados al departamento para una pasantía. Uno de los estudiantes estaba listo para hacer un pequeño trabajo.
Ivan pensó que podría ser posible hacer al menos algo por métrica, y envió al estudiante una tarea técnica para una parte del proyecto que se redujo a la imposibilidad.
Todo lo que había allí era extraer datos de Jenkins y Nexus de la manera más fácil posible.
Imagine la sorpresa de Ivan cuando solo un par de días después un estudiante lo invitó a mirar el sistema de trabajo. A la pregunta "¿Cómo obtuve una prioridad tan alta?" seguido de la respuesta: "Solo tenías conocimientos tradicionales".
Sea como fuere, pero el sistema funcionó. Extrajo datos de Jenkins y Nexus y los puso en su propia base de datos.
Ivan se dio cuenta de que necesitaba terminar el resto lo más rápido posible. Utilizó la versión gratuita de QlikView para generar informes a partir de datos sin procesar y por la tarde la primera versión de las métricas de DevOps estaba lista.
El lunes siguiente fue un gran avance. Al ver las métricas de trabajo, el jefe de Ivan exclamó: "¡Esta es la información más útil que he visto últimamente!"
El problema de los recursos se resolvió instantáneamente, y en los próximos días, el proyecto con métricas se lanzó al máximo.
Ivan actuó correctamente y sin darse cuenta dio "resultados rápidos": un sistema de trabajo con la funcionalidad más truncada que brinda beneficios reales.
El trabajo de "Resultados rápidos", porque cuando se trata de un sistema grande y costoso, inevitablemente surgen muchas ambigüedades. Con un alto costo significativo, el resultado no siempre es obvio.
Por lo tanto, el inicio del trabajo se retrasa constantemente o el sistema se abandona por completo.
Los resultados rápidos ayudan a probar la hipótesis con medios mínimos. Lo principal es tratar de hacer un prototipo sin atraer recursos adicionales y que al mismo tiempo tenga valor y beneficios.
Algunas ideas recibidas por Ivan del proyecto:
Primero imagina qué resultado final necesitas
Ivan sabía exactamente qué métricas necesitaría, hasta los diseños de pantalla. Esto le permitió descartar rápidamente funcionalidades innecesarias y dejar solo aquello sin lo cual las métricas perdieron por completo su significado.
De las diez métricas de DevOps propuestas para la implementación, Ivan dejó solo una y la limitó a un puesto y un equipo. De hecho, este fue el apretón más concentrado por un lado, y los datos reales prácticos por el otro.
Tal versión simplificada permitió resolver un problema completamente práctico: analizar el equipo real y comprender si las métricas en él darían el resultado que se esperaba de ellos.
Un diagrama de arquitectura simple hace las cosas mucho más fáciles.
El esquema de implementación más simple con flujos de información y datos muy bien ayudó a Ivan a comprender dónde se encuentra y qué tan fácil es obtenerlo.
Jenkins: Empleos. ¿Qué se requiere para las métricas en los trabajos? ¿Cómo sacarlo? ¿Qué protocolos, de qué direcciones?
Nexus: distribuciones. ¿Qué requiere Nexus para las métricas? ¿Cómo conseguirlo?
Sistemas de ayuda: descartar porque No son necesarios para las métricas.
¿Cómo combinar datos? ¿Dónde es más fácil hacerlo lo más rápido posible?
Si es posible, prescindir de la codificación. Bastante
Si puede hacer la carga ya hecha a XLS o CSV, es mejor hacer esto y no codificar en absoluto.
A veces no puedes prescindir de la codificación, pero aún así debes elegir la opción más fácil.
Por ejemplo, Jenkins alimenta datos en RSS y JSON. Elija la opción que sea más fácil de implementar.
Nexus solo devuelve XML? Bueno, no hay nada que hacer, tienes que codificar.
No cuelgues demasiado. Limpiar todo
La super automatización no es necesaria para obtener resultados rápidos. Puede hacerlo con códigos de comando en lugar de sus nombres. No debe conectar sistemas adicionales solo para enriquecer los datos. Estas son solo flores y una guía de belleza: es mejor prescindir de ellas y ahorrar tiempo.
En lugar de escribir en la base de datos, puede escribir en un archivo de texto normal o csv, si será más rápido.
Donde puede comenzar manualmente: comience, no pierda tiempo en el programador.
Si es más fácil escribir en un lenguaje de secuencias de comandos ligero como Python o PHP, escriba. De todos modos, haces lo mínimo, por lo que no tendrás que reescribir mucho.
Utilice herramientas que le permitan obtener resultados rápidamente, por ejemplo, QlikView o Tablue gratuitos para las métricas: facilitan la carga y combinación de datos, así como la creación de todos los gráficos necesarios.
Ivan puso los "resultados rápidos" en servicio y en los siguientes proyectos siempre trató de hacer primero un sistema que funcionara de manera mínima y proporcionara utilidad, y solo luego se hizo cargo del resto. Y siempre funcionó.
Si la historia de Ivan te pareció útil, estaré extremadamente feliz por ello.
Escriba en los comentarios su caso cuando los resultados rápidos hayan tenido efecto.