Cuando la automatización de tareas vale su tiempo

¿Porque, porque no?

El propósito de la automatización es liberar su tiempo y capacidad intelectual. Se supone que le da espacio para hacer otra cosa, sin necesidad de trabajo manual ni tareas repetitivas. Pero si bien existe una defensa general de la automatización en el software y la ingeniería, no siempre es la mejor solución.

En mis proyectos anteriores, a veces la automatización no se comparaba con sus supuestos beneficios, lo que resultaba en pérdidas de tiempo innecesarias. A lo largo de los años de implementación de automatizaciones exitosas y fallidas, he desarrollado una matriz de evaluación para ayudar a mis equipos a determinar si la automatización es necesaria.

El hecho de que suene bien no significa que sea lo correcto en cada situación.

¿Cuál es el beneficio del tiempo?
Antes de lanzarnos a la tarea de automatizar, debemos evaluar nuestra ganancia de tiempo.

¿Porque es esto importante?

Porque no todas las automatizaciones valen lo mismo. También es fácil perderse en la tarea de crear las automatizaciones. El tiempo es una comodidad en el trabajo de desarrollo. A veces, hacer automatizaciones requiere más tiempo del que devuelve.

Aquí está la ecuación que les lanzo a mis equipos antes de lanzar la tarea:

(task time * duration without automation) – (time to automate * resource) = time profit
Así es como funciona la ecuación:

Tiempo de la tarea: ¿Cuánto tiempo lleva la tarea repetida? ¿Diez minutos? ¿Veinticinco minutos? ¿Una hora?
Duración sin automatización: ¿Cuánto tiempo se espera que se repita la tarea? ¿Es indefinidamente? ¿Tres semanas? ¿Seis meses? ¿Hasta que el marketing finalmente tome una decisión?
Tiempo para automatizar: ¿Cuánto tiempo llevará crear la automatización? ¿Treinta minutos? ¿Tres días laborables? ¿Dos días laborables?
Recurso: ¿Cuántas personas requiere esta tarea? ¿Un desarrollador? ¿Dos desarrolladores? ¿Todo el equipo?
Su ganancia de tiempo es el resultado de la ecuación anterior. ¿La automatización crea un excedente considerable e impactante? En el caso de que se espere que la tarea manual continúe indefinidamente, la automatización ciertamente vale la pena.

Sin embargo, si solo se espera que sea por una semana y le cuesta tres días completarlo, entonces no es tan eficiente para ese caso de usuario en particular, obviamente.

Utilizo esta ecuación, especialmente con los nuevos desarrolladores junior, porque a menudo caen en la trampa del «entusiasmo por la automatización». Si bien la automatización no es algo malo, también debe sopesarse con la situación y nunca sacarse de contexto.

También existen diferentes tipos de automatizaciones, lo que repercute en la ganancia de tiempo.

Los trabajos de automatización más pequeños pueden ser más eficientes

Existen varios tipos de automatizaciones, comenzando con la orquestación de la infraestructura y hasta los procesos programáticos.

Una de las automatizaciones más fáciles y con mayor beneficio de tiempo es cualquier cosa que se pueda transferir a un trabajo cron, un programador basado en el tiempo en sistemas basados en Unix. Cron generalmente maneja tareas manuales que deben ejecutarse en un cierto tiempo o intervalo. Estas tareas tienden a existir ya en forma de scripts que un desarrollador necesita ejecutar para mantener las operaciones comerciales.

Para mí, la configuración típica de un trabajo cron tarda unos 15 minutos en el servidor de prueba y otros 15 para replicarlo en producción. Esto es con la condición de que los scripts automatizados ya existan. Por lo general, también agrego un búfer al tiempo que se tarda en completar el trabajo, que se usa principalmente para esperar porque las cosas pueden tardar en iniciarse o dar acceso a la conexión. (¡Ese tiempo se suma!)

Si aplicamos la ecuación tiempo-beneficio a una tarea que se espera que ocurra durante los próximos tres meses, se ve así:

// Time profit equation
(task time * duration without automation) – (time to automate * resource) = time profit

// Our automation in question
(5 [mins] * 90 [days] ) – (45 [mins] * 1 [dev]) = 405 mins time profit –> or 6 hours and 45 mins

Seis horas es casi un día ahorrado. Y eso no tiene en cuenta el inevitable e incalculable error humano, como que alguien pierde la pista de la tarea y la ejecuta más tarde de lo esperado. Cuando me uní por primera vez a uno de mis equipos de desarrollo, teníamos que ejecutar informes manualmente todas las mañanas. De vez en cuando, uno de los desarrolladores de la lista se olvidaba o se cancelaba una reunión. Esto a menudo ocasionaría que el plazo se sobrepasara y el informe se entregaría tarde. Esto provocó retrasos en otros departamentos y, en algunos casos, repercutió en el cliente de forma negativa. Cuando se introdujeron los trabajos cron, resolvió el problema en curso y eliminó la dependencia del equipo de desarrollo para presionar un botón.

La mayoría de las veces, puede crear un trabajo cron directamente en su servidor. Sin embargo, la idea de los trabajos cron también se puede extender a proveedores de nube como AWS, donde puede crear tareas programadas a través de servicios como CloudWatch Events y Lambda.

Comencemos con un trabajo cron personalizado en su servidor.

Curso intensivo de trabajo cron personalizado en el servidor
Inicie sesión en el servidor en el que desea que su trabajo cron se ejecute a través de SSH.
Utilice crontab -e para abrir su archivo crontab.
Es posible que le solicite una dirección de correo electrónico y / o un editor. Nano es más fácil si no está familiarizado con Vim.
Aparecerá un archivo crontab en blanco. Hay dos partes para crear un trabajo cron: la frecuencia y qué ejecutar. Aquí hay un ejemplo de cómo se ve un trabajo cron simple:

# custom cron job
MAILTO=»some@user.com»
12 15 * * * php /home/user/capacity-report.php

Aquí hay una tabla de referencia de lo que representa cada ‘bloque’ en un programa de trabajo cron:

minute hour day_of_month month day_of_week

Entonces, si quisiéramos automatizar un informe que se ejecuta todos los domingos a las 9 a.m., la configuración se vería así:

0 9 * * 0 php /home/user/report.php

Una vez que haya terminado, puede guardar su configuración y salir. Verá la siguiente respuesta:

crontab: installing new crontab

La creación de AWS CloudWatch Eventos en Lambda

AWS lambda es un servicio de micro nube que le permite adjuntar código a una máquina sin la necesidad de configurar nada. Puede simplemente enviar sus scripts a un Lambda y usarlos según sea necesario.

Lo mejor de Lambda es que solo tiene que pagar por lo que usa. Por lo tanto, puede tener cientos de scripts en el servicio y pagar casi nada por ellos. Una forma de aprovechar este servicio es crear pequeñas automatizaciones que se puedan activar a través de otro servicio de AWS llamado CloudWatch Events.

En cierto modo, CloudWatch Events on Lambda es una forma de trabajo cron, pero en la nube.

Estos son los pasos sobre cómo automatizar sus scripts Lambda con CloudWatch Events.

Abra la consola de CloudWatch y navegue hasta ‘Eventos, crear regla’.
Elija «Programación» como «Fuente del evento». Especifique la frecuencia. Agrega tu objetivo. Deberá crear el rol de IAM para que le dé permiso a CloudWatch Events para enviar eventos a los destinos.
Configure los detalles finales como el nombre y la descripción de la regla. Guárdelo eligiendo ‘Crear regla’.
Y eso es básicamente todo. Realmente no hay mucho para adjuntar un disparador automatizado a su función lambda en AWS.

Los programadores sencillos aún pueden llevar a una pérdida de tiempo
De proyectos anteriores, un costo de tiempo importante fue la inversión inicial para determinar cómo funciona Lambda y configurar los procesos de la tubería. Para mí, me tomó unos dos días darme cuenta. Pero una vez que se logró ese obstáculo, la configuración de la secuencia de comandos posterior se limitó a la complejidad de la secuencia de comandos.

Por ejemplo, un proyecto de automatización en el que trabajé en los valores requeridos de una base de datos heredada con estructuras normalizadas en más de 50 tablas y 50k filas de datos tardó aproximadamente tres días en desentrañar. Se pasaron otros dos días optimizando el proceso y de tres a cinco días más de comentarios de parte de Comercial.

Con todo, el proyecto de automatización me tomó aproximadamente dos semanas de mi tiempo. La mayor parte se destinó a crear lo que quería automatizar.

Si conecta esto a nuestra ecuación de ganancia de tiempo, la automatización tendría que compensar los 288.000 minutos de ejecución manual de una tarea. Suponiendo que está reemplazando una tarea de 30 minutos todos los días, estamos hablando de tener que dejarla funcionar durante muchos años antes de que el trabajo inicial se amortice.

Para algunos de los trabajos que me asignaron, el proceso puede detenerse en el paso de generación manual. ¿Por qué? Porque el costo de tiempo para crear el proceso completo fue más que el proceso manual. Esto sucede a menudo cuando lo que se requiere es algo único. En cuanto al tiempo, a veces no es eficiente transformar el proceso manual en algo compatible con Lambda o donde sea que resida su script.

Tus calculos

¿Vale la pena el esfuerzo de la automatización de tareas? ¿O es una trampa para hundir el tiempo?

Lo siento, pero tenemos que ir con una respuesta de ingeniería tradicional aquí: depende. Pero espero que, si se arma con la información que mencionamos anteriormente, con suerte podrá tomar decisiones mejor informadas contra el «entusiasmo por la automatización» fuera de lugar.

Hay algunos otros puntos a considerar.

Por un lado, es cierto que aprender a crear automatizaciones iniciales puede ser la parte más lenta del proceso, especialmente si se trata de un territorio desconocido. Pero invertir una cantidad de tiempo no equitativa en un proyecto puede recuperarse si produce aprendizajes y fundamentos que puedan aplicarse en futuros procesos de automatización. (Y a menudo podría depender de usted, el desarrollador, venderle a su equipo o gerentes por qué vale la pena esta inversión de tiempo).

Otro punto es que el análisis de costos para la automatización puede convertirse en una cuestión de eficiencias futuras, y no estamos hablando solo de la utilidad de que un script en particular continúe o termine. Por ejemplo, los trabajos cron y las canalizaciones son automatizaciones transferibles que se pueden poner en funcionamiento fácilmente en otro lugar cuando sea necesario. Por otro lado, las automatizaciones de la orquestación de la infraestructura a menudo no son transferibles. Eso significa que una automatización simple pero patentada para una aplicación prototipo que puede o no ser desechada puede fácilmente resultar en trabajo desperdiciado.

Crear automatizaciones es un equilibrio entre la eficiencia y las necesidades de la empresa. No todo debe automatizarse, solo las cosas que agregarán valor a largo plazo a su capacidad para proteger su tiempo.

Subscríbete y recibe nuevas noticias

devnow

Autor desde: August 12, 2020

Deje su comentario

EN ES