Cuatro automatizaciones que salieron con valor cero y no hicieron nada.

En un solo día, detectamos cuatro interrupciones distintas en las automatizaciones que habíamos creado. Tres de ellas finalizaron correctamente. Los scripts se ejecutaron, devolvieron cero y no hicieron absolutamente nada. Todos los paneles de control estaban en verde.

Ese es el modo de fallo que nadie demuestra, contra el que nadie vende y que casi nadie monitoriza. Además, es el que más cuesta, porque no se trata de una tarde de apagar un incendio, sino de tres meses de un trabajo que creías que se estaba realizando.

Cuatro maneras de fracasar al informar de un éxito

El token de acceso ha caducado.

Se ejecutó una tarea de publicación en redes sociales cuarenta y seis veces con credenciales caducadas. Cada ejecución comenzó, no encontró nada que pudiera hacer y finalizó. La plataforma devolvió un error de autenticación, la tarea lo detectó, lo registró en el nivel de depuración y salió con código de salida cero porque, desde su perspectiva, había finalizado.

Cuarenta y seis publicaciones que nunca existieron. Nadie se dio cuenta durante semanas.

Un control de calidad rechazó el trabajo y no se volvió a intentar.

Un redactor elaboró un borrador, un proceso de verificación lo rechazó, y el flujo de trabajo descartó el borrador y finalizó. El planificador marcó la tarea como completada, lo cual era cierto. No se puso ningún artículo en cola, no se activó ninguna alerta, y la siguiente ejecución comenzó desde cero e hizo lo mismo.

Una semana de producción se esfumó en una ruta de código que, estrictamente hablando, funcionaba.

Un búfer que nunca podría reabastecerse.

Una cola de contenido generaba un elemento por ejecución y consumía uno por ejecución. En teoría, esto representa un estado estable. En la práctica, cualquier generación fallida supone una pérdida permanente, ya que no hay margen para recuperarla. El búfer siempre se descargaba.

Eso es un trinquete, no un amortiguador, y parece estar en perfecto estado hasta el día en que llegue a cero.

Un envío parcial que parecía completo.

Un boletín informativo llegó a aproximadamente una quinta parte de su lista. La función de envío devolvió un resultado exitoso, ya que se había enviado correctamente el primer lote. No se comparó el número de destinatarios intentados con el tamaño de la lista.

Desde dentro del sistema, un envío parcial y un envío completo son idénticos. La única forma de distinguirlos es contándolos.

Por qué los códigos de salida no son lo que uno debe ver

Un código de salida responde a una pregunta: ¿el proceso llegó a su fin sin fallar? Esa no es la pregunta que te interesa. Lo que te interesa es si sucedió lo que querías.

Estas dos cuestiones se contraponen constantemente, porque un código bien escrito detecta sus errores. Cuanto mejor sea el manejo de errores, más probable será que una ejecución fallida finalice correctamente. La programación defensiva y el fallo silencioso son el mismo comportamiento visto desde dos perspectivas distintas.

Un sistema de monitorización que solo pregunta si se ha ejecutado una tarea te dirá que tu negocio va bien hasta el momento en que un cliente te diga que no.

Qué comprobar en su lugar

Cada uno de los cuatro fallos mencionados anteriormente se detecta mediante una verificación del resultado, no del proceso. Ninguno de ellos es complicado.

• ¿Apareció el artefacto? Tras una publicación, consulta el destino y confirma que la entrada existe. No el registro. El destino.
• ¿La cola es más larga que una persona? Realiza un seguimiento de la profundidad a lo largo del tiempo, no de la presencia. Una cola que nunca crece está fallando incluso cuando no está vacía.
• ¿Cuánto tiempo falta para que caduque esta credencial? Cada token tiene una fecha límite. Se activará una alerta antes de que expire, se actualizará la página con antelación y se activará una alerta si la actualización falla.
• ¿Llegó a todos? Compara los destinatarios intentados con el tamaño de la audiencia. Cualquier discrepancia se considera un fallo, independientemente del resultado de la función de envío.
• ¿Cuándo tuvo éxito esto por última vez? No es la última ejecución. Es el último éxito, definido como un resultado que se puede ver desde fuera del sistema.

Una tabla, no cinco

La otra mitad de esto es donde van las respuestas. Cinco automatizaciones que envían informes a cinco lugares son, en la práctica, lo mismo que no tener ningún tipo de monitoreo, porque nadie revisa cinco lugares todas las mañanas.

Ahora, todo lo que creamos se reporta a un único panel de estado con una fila por automatización, que muestra el último resultado verificado y su antigüedad. Si todas las filas están actualizadas, no hay nada que atender. Si una fila se vuelve obsoleta, eso es lo único que debe revisarse.

Es un artefacto deliberadamente aburrido. El aburrimiento es precisamente la clave. Su valor reside en que comprobarlo solo lleva cuatro segundos, lo que significa que realmente se comprueba.

La parte incómoda

Si actualmente tienes un sistema automatizado en funcionamiento que no has verificado externamente en el último mes, la verdad es que no sabes si está funcionando. Sabes que no ha fallado.

Son afirmaciones muy diferentes, y solo una de ellas tiene algún valor.