
Los lemmings son pequeños roedores que, según se dice, se siguen unos a otros mientras se lanzan al vacío desde el borde de un acantilado. En realidad, se trata de un mito infundado, pero se ha convertido en una metáfora de las personas que se dejan llevar, sin cuestionar, por un grupo, con consecuencias potencialmente peligrosas. Yo no he podido evitar pensar en esta metáfora recientemente, al ser partícipe y víctima de este efecto.
En México, solemos referirnos a este efecto aludiendo a los borregos; lo llamamos «la borregada» y lo empleamos ampliamente en temas políticos. Me ha parecido más adecuado recurrir a la metáfora de los lemmings para encuadrar este asunto.
Ocurrió que, para cierto proyecto al que recientemente me uní, se nos mostraron los espacios de trabajo (workspaces) en los que deberíamos movernos en Azure, la nube en la que el cliente «tiene sus cosas.» En ese recorrido (que nos dieron en un meeting de MS Teams) alguien seleccionó un workspace cuya designación terminaba en el número «2» (también existe un workspace que termina en «1» para ejemplificarnos algunas acciones).
Algunos días después de ese recorrido, decidí explorar Azure ML Studio e iniciar la creación de algunos notebooks. Recordando el demo previo, busqué y llegué a ese workspace número «2». Ahí empecé a trabajar y a crear cosas. Otros procedieron similarmente. Algunos días después se presentaron varios problemas de acceso a recursos, espacios de trabajo y permisos. Sin entrar en muchos detalles, sólo mencionaré que, para poder llegar a este entorno, debo pasar cinco niveles de seguridad, en los que debo proporcionar credenciales de acceso y usar un MFA en cada uno; cada nivel de seguridad subsecuente debe hacerse en uno previo o la cosa no funciona, y en el penúltimo debo hacer uso de una cuenta administradora que sólo sirve para acceder al último nivel (lo que, por cierto, nos ha causado varios dolores de cabeza, pues hay servicios a los que accedemos con una cuenta regular y hay otros que requieren esa cuenta administradora, presentando algunos conflictos que se disparan de cuando en cuando).
Después de perder tres días bloqueados para acceder a los servicios, el problema escaló lo suficiente como para que se pusiera a más gente a trabajar en su solución. La solución de una parte se logró cuando el personal de soporte técnico llegó al workspace número «2» y preguntaron por qué estábamos usándolo cuando debíamos usar el número «1». La respuesta fue que fue el que nos mostraron y en el que se creó un archivo para validar nuestro acceso; todos nos fuimos por ese workspace «por inercia». Curiosamente, ese workspace, dijeron, nunca debió crearse, y se nos indicó que sería eliminado una vez que moviéramos lo que tuviéramos ahí (ya pasaron tres semanas desde entonces; ya todos nos movimos al «1», pero el workspace número «2» ahí sigue). El problema se debió a las políticas de seguridad asignadas (o faltantes) al (en el) workspace número «2»; las correctas se asignaron al workspace número «1».
La verdad, a todos nos divirtió el hecho de haber «seguido lo que el otro hacía» para seleccionar lo que considerábamos recursos a nuestra disposición. «Lo que hace la mano, hace la tras», decimos en México.
