El error que llevaba un mes funcionando

Hay una frase que se utiliza como mantra habitualmente en tecnología: “Si funciona, no lo toques” y es algo que, efectivamente, va bien en muchas ocasiones, pero en otras… también tapa errores silenciosos que perviven hasta que un lunes por la mañana cualquiera alguien se pone a revisar otra cosa y de repente descubre que hay un proceso de automatización que lleva funcionando mal un mes y nadie se ha percatado.

Cómo empezó todo

El tema empezó de la manera más inocente posible: un proceso automatizado que se ejecuta cada noche falla y de las cinco acciones que debía resolver se paró en la cuarta, dejando la última sin realizar. El mensaje de error era escueto: “usuario no encontrado”.

El mensaje no es muy descriptivo pero tampoco es nada dramático ni que implique, como otras veces, sacar la bola de cristal para adivinar qué pasa. Es un aviso de los que miras con el café en la mano pensando que en diez minutos está resuelto.

La realidad es otra: tardé una mañana entera y lo que me fui encontrando por el camino no tenía nada que ver con aquel “usuario no encontrado”.

Primera sorpresa: el error era real, pero engañaba

Revisando el flujo, como ya he dicho eran 5 acciones, no había mucha complejidad: la automatización buscaba a una persona en la plataforma con la referencia de su correo electrónico y una vez que la encontraba debía continuar con otras dos acciones. En este caso, sencillamente, no la encontraba y la conclusión fácil era que esa persona ya no estaba. Pero la navaja de Ockham a veces falla y la opción fácil no es siempre la correcta.

Ese usuario en realidad sí estaba pero se había registrado en la plataforma con un correo distinto al que usó para comprar, que es el que teníamos guardado en la base de datos. Dos correos, la misma persona, y ningún sistema sabiendo que eran la misma.

Esto importa más de lo que parece. “No encuentro a esta persona” y “esta persona no existe” suenan igual, pero significan cosas opuestas. Si el sistema hubiera dado por buena la primera lectura, habría marcado el trámite como completado dejando el acceso intacto. Habría quedado un registro perfecto describiendo algo que no era verdad.

Segunda sorpresa: el fallo que nadie estaba buscando

Ya a medio café, abrí la automatización para arreglar lo del correo y aquí por supuesto fue cuando la partida se puso en modo interesante.

En la parte final del flujo, teníamos configuradas serie de excepciones para que cuando alguien terminaba su formación, el sistema le retirara el acceso a los contenidos del curso pero le mantuviera accesibles las zonas de la comunidad: el foro general, los anuncios, los espacios gratuitos a los que cualquiera puede entrar. La lista de excepciones estaba escrita con cuidado, una por una.

Pues la realidad es que la lista no hacía nada.

Al montarla, con la configuración que estaba el grupo de condiciones siempre se cumplía, lo que derivó en que en vez de leerse como “quítale el acceso salvo a estas zonas”, se leía como “quítale el acceso a todo”. Esto sucedió exactamente durante un mes: cada persona que terminaba su formación se quedaba sin acceso a nada. Podía entrar con su usuario y su contraseña, y al entrar no veía absolutamente ningún contenido.

Fueron diecinueve personas. Ninguna se quejó.

Cómo es que nadie lo vio antes

Esta es la parte interesante y la que da título al asunto: el error funcionaba.

Por un lado, es un proceso que no generaba avisos ni mostraba trazas rojas en ningún panel. Las automatizaciones se ejecutaban de principio a fin y se marcaban como correctas, porque técnicamente hacían lo que se les había pedido. El problema no era que fallaran, era que lo que se les había pedido no era lo que queríamos pedirles.

Por otro lado, las personas afectadas eran justo las que menos ruido hacen: gente que ha terminado su formación ya no esperan nada, no tienen deberes pendientes y es probable que tarden semanas en volver a entrar. Cuando entren y no vean nada, muchos pensarán que es normal, que al terminar se pierde el acceso, y no escribirán a nadie.

Un fallo que afecta a alguien en mitad de su proceso genera una queja en horas. Un fallo que afecta a alguien que ya terminó puede vivir meses sin que nadie lo cuente.

La tercera sorpresa fue la peor

Aunque eran diecinueve que no es volumen elevado, lo cierto es que mirar los registros de cada uno en la propia plataforma iba a requerir una inversión de tiempo que no tenía, así que caí en la tentación era mirar la base de datos interna que refleja quién tiene acceso a qué. Existía, estaba actualizada esa misma mañana y respondía en segundos.

Por supuesto, estaba mal.

En el caso de la primera persona que comprobé, la base decía que tenía acceso a once zonas mientras la plataforma real decía cero. En el segundo caso, decía que tenía dieciséis; en realidad eran veintidós. La fantasía de cualquiera que trabaje en tecnología: el sistema fallaba en las dos direcciones: no registraba lo que se quitaba y no registraba todo lo que se añadía.

Y lo más incómodo: la fecha de última actualización era de hacía unas horas. No apuntaban a ser datos viejos, en realidad, parecía datos frescos y equivocados, que es bastante peor, porque nadie desconfía de algo que acaba de actualizarse.

Cualquier decisión tomada leyendo esa base durante las últimas semanas estaba construida sobre arena.

Cómo lo solucioné

Tres cosas, en este orden:

En primer lugar, reparar la lista de excepciones. Fue un cambio de dos minutos en la configuración y eso que para darle emoción, aparecieron otras cuatro erratas más que llevaban ahí desde el principio y que nadie había visto, porque mientras el mecanismo global no funcionaba, daba igual que las piezas estuvieran bien o mal puestas. Un error grande puede esconder cuatro pequeños durante meses.
En segundo lugar, enseñar al sistema a pedir ayuda. La automatización no tenía una ruta de escape cuando algo salía mal, así que se paraba entera y bloqueaba todo lo que venía detrás. Tras revisarlo activé un “por si acaso”… y ahora, cuando encuentra un caso que no sabe resolver, hace tres cosas: avisa a un canal donde hay personas mirando, se salta ese caso concreto y sigue con los demás.
Decidir cómo gestionar los fallos es un tema que parece fácil pero engaña, de hecho, en primera instancia el camino fácil rellenaba el hueco con datos falsos para que el proceso pudiera continuar y quedara todo cerrado. Obviamente, esto lo descarté. Cerrar un expediente que en realidad no se ha resuelto es peor que dejarlo abierto, porque el registro dice que está hecho y ya nadie vuelve a mirarlo. Dedicándole un poco más de tiempo, conseguí que en caso de fallo se quede visiblemente pendiente y el equipo reciba un aviso para resolverlo manualmente. Es menos elegante pero más honesto y eficaz.
Y en tercer lugar, devolver lo que se había quitado. Diecinueve personas recuperaron su acceso a las zonas abiertas. Se comprobó una a una que quedaba exactamente con lo que le tocaba, ni de más ni de menos.

Lo que pasa al cuaderno de bitácora

Un proceso que no sabe fallar es un proceso frágil. No por lo que hace mal, sino porque el primer caso raro lo tumba entero y arrastra consigo a todos los que venían detrás. Una persona con el correo mal escrito bloqueó el trámite de otras cuatro.
Silencio no es lo mismo que todo va bien. Los sistemas que fallan avisando son los fáciles. Los peligrosos son los que fallan en verde. Conviene preguntarse de vez en cuando qué cosas podrían estar rotas sin que nadie se entere, y muy en particular las que afectan a usuarios que ya no están pendientes de ti.
Desconfía de las copias. Tener los datos duplicados en un sitio cómodo de consultar es práctico hasta el día en que la copia y el original difieren. Y si la copia lleva fecha reciente, nadie va a sospechar. Para las decisiones que importan, mejor preguntar a la fuente.
Cuando un dato no cuadra, para. A media restauración aparecieron personas que ya tenían su acceso devuelto sin que nadie de este lado lo hubiera tocado. La reacción fue detenerse y comprobar quién había hecho qué, en vez de seguir escribiendo encima. Resultó que había dos personas arreglando lo mismo en paralelo sin saberlo, y por casualidad con el mismo criterio. Podría no haber coincidido.
Cuidado con el “no será nada”. Al final del día, una consulta de rutina destapó que había otras cuatro automatizaciones marcadas como problemáticas en el mismo sistema, dos de ellas relacionadas con cobros. Nadie las había mirado porque nadie se había quejado.