2.7 ¡Viva la Pepa!

¡Viva la Pepa! es una expresión que sirve para referirse a situaciones de desbarajuste o despreocupación. Esto encaja perfectamente para definir la política de gestión del cambio en muchas organizaciones, donde cada uno hace lo que quiere o puede, sin rendir cuentas a nadie, sin ningún tipo de trazabilidad y sin tomar en consideración posibles efectos colaterales con otros sistemas y/o compañeros.

En primer lugar, me gustaría dejar claro que «si no vas a ganar nada con el cambio o vas a empeorar las cosas, entonces no lo hagas». En caso de aburrimiento, existen juegos de mesa muy buenos, videojuegos, libros, sudokus, cuadernos de pinta y colorea, puzles, etc. Pero, por favor, no te dediques a cambiar las cosas porque sí, sin ton ni son. Cualquier cambio, por insignificante que parezca, implica unos riesgos, más o menos altos, dependiendo de cada caso. Por este motivo, tiene que existir una justificación detrás de todo cambio. Por poner un ejemplo, una vez desarrollamos un proyecto, que posteriormente se dividió en dos webs, luego tuvimos que volverlo a fusionar en una sola plataforma y más adelante se dejó de usar. Parece absurdo, ¿verdad?

También he vivido infinidad de cambios de entornos, moviendo proyectos de un servidor a otro, incluso desde entornos corporativos hacia servicios externos en la nube para después volver a entornos corporativos lentos, inestables, demasiado complejos, extremadamente caros, fuertemente burocratizados y muy «dinosaurizados». No hablaré de cambios infinitos en reglas de negocio de programas o en diseños de interfaces gráficas porque solo de eso podría escribir otro libro titulado: «Donde dije digo, digo Diego».

Ahora imaginemos por un momento un país o, si lo simplificamos aún más, una simple ciudad, donde no hubiera leyes. ¿Qué pasaría si todos condujeran o pasearan por donde quisieran, tiraran la basura en medio de la calle, hicieran sus necesidades donde les viniera en gana...? ¡Eso sería el caos y el fin de la civilización! Pues ahora traslademos esto a una organización tecnológica.

Si tenemos uno o más servidores, a los que cualquiera tiene acceso, puede hacer cambios y no hay ningún tipo de protocolo de actuación a seguir, puede surgir el caos más absoluto en cualquier momento. Y según la Ley de Murphy, esto ocurrirá en la situación menos oportuna. Es muy fácil echar por tierra el trabajo de otro compañero o dejar sin servicio otros servidores o aplicaciones que dependen de lo que has modificado, sin consultar o avisar previamente. Lo que nos lleva a decir: ¡Pero no toques! ¿Por qué tocas?

Por supuesto, también está el polo opuesto, en el que los cambios parecen no llegar nunca. Imagina el caso en el que para desplegar cualquier modificación tuvieras que rellenar uno o varios formularios con infinidad de campos obligatorios y así poder pedir el pase a producción, que se realiza solo un día a la semana. En el caso en el que las cosas fallen y se haga un rollback inmediato, muy probablemente tendrás que esperarte otra semana para aplicar de nuevo los cambios con el arreglo incluido. Esto es muy ágil, ¿verdad? Y luego dicen que los proyectos se eternizan...

Además, ten presente que cuanta más distancia haya entre el realizador del cambio y la persona o personas que tengan que aprobarlo peor será el resultado, ya que, típicamente, cuanto más lejos se está del problema o cuestión a tratar, menos se sabe acerca de ello y menos importancia se le suele dar.

A continuación, voy a explicar varios casos reales a modo de ejemplo de lo que NO hay que hacer.

Pesadilla 1: servidor en mantenimiento

En este primer caso, se tenían que hacer tareas de mantenimiento en un servidor propio de GitLab, con cientos de repositorios de código fuente de muchas aplicaciones distintas. Para hacer esa actuación se estableció una fecha y hora en la que el servidor no estaría operativo, pero por el motivo que sea, se modificó la fecha y no se informó del cambio a la gente que usa el servicio. Esto provocó que se acabaran haciendo las tareas de mantenimiento sin previo aviso. ¿Te imaginas un posible final a esta historia de terror? Por favor, sigue leyendo.

Paralelamente a esto, yo tenía entre manos la actualización de una web, donde iba a desplegar importantes cambios a producción, después de una larga fase de desarrollo y pruebas en el servidor de preproducción. Por fin había llegado el gran día y tenía listo el procedimiento de actualización hecho a medida para la ocasión, el cual tenía que seguir al pie de la letra para que todo funcionara correctamente. Sí, se trataba de un proceso manual no trivial y tenía que ir con mucho cuidado para no liarla. Por lo tanto, avisé a mis compañeros de que, por favor, no me interrumpieran hasta nuevo aviso y me puse manos a la obra. El primer paso era descargar los cambios correspondientes a la actualización (git pull origin master) y de repente... ¡Boom! No me lo podía creer, había fallado el primer paso. Empezábamos bien...

En ese momento me quedé helado, ¿por qué no podía descargar los cambios? No entendía nada, si hacía un momento todo funcionaba correctamente... Entonces intenté acceder vía web al servidor de GitLab y efectivamente no cargaba la página. Acto seguido intenté acceder por consola (SSH) y tampoco había forma. El último recurso que me quedaba era hacer un ping, al que tampoco respondió. Es decir, el servidor estaba completamente KO, no respondía. El siguiente paso fue preguntar a los compañeros si alguien había hecho algo en este servidor y un compañero me respondió que lo habían parado para hacer las tareas de mantenimiento (que se tenían que hacer otro día). Así pues, después de pedirle amablemente que fuera la última vez que me hicieran sufrir del corazón de esa forma, no tuve más remedio que esperar a que terminara el proceso que habían lanzado. Una vez finalizado, pude realizar con éxito la actualización de la aplicación que dependía de ese servidor en mantenimiento.

Pesadilla 2: borrado de información importante

Recuerdo, como si fuera ayer, un soleado viernes al mediodía, cuando recibí un correo electrónico preguntándome si habíamos hecho cambios de permisos en un repositorio, quejándose de que no podían acceder a él. Me extrañó mucho esa incidencia, así que intenté acceder, ¡pero yo tampoco lo veía! ¿Cómo podía ser eso? ¡Había desaparecido! Busqué otros repositorios del mismo proyecto y había unos que sí estaban y otros que se habían volatilizado. Rápidamente me di cuenta de que los repositorios de ese proyecto que no estaban eran propiedad del mismo usuario, así que me puse a buscar otros repositorios de distintos proyectos que pertenecieran a ese usuario, pero no había ninguno. El siguiente paso fue buscar si existía el usuario en cuestión y efectivamente no estaba, ¿se lo habían cargado?

Acto seguido pregunté si alguien había eliminado ese usuario y un compañero me dijo que lo había eliminado hacía unos días, pero que había marcado la opción para «guardar las contribuciones que hubiera hecho». Dicho de otra forma, hacía unos días que se lo habían cargado, pero el marrón no se manifestó hasta un viernes poco antes de terminar la jornada. Me quedé atónito, ¿cómo podía ser que hubieran eliminado ese usuario que contenía mucha información importante sin previo aviso? Hay que decir que se estaban realizando tareas de limpieza y organización, pero si ves que un usuario es importante dentro del sistema, tienes que actuar con mucha prudencia.

Antes que nada, si vas a ejecutar una acción irreversible, tienes que estar muy seguro de que estás cubierto, lo cual significa que tienes la autorización por escrito, hay backups recientes, etc. Evidentemente, si la acción es delicada hay que hacer pruebas antes de ejecutarla en un entorno real. En este caso, no se comprobó si el borrado del usuario (aun marcando la opción de guardar las contribuciones) mantenía o no sus repositorios de código. Si hubieran hecho la prueba, habrían comprobado que efectivamente borrando el usuario se borraban todos sus repositorios asociados. ¡Menuda fiesta!

La primera solución que puede venir a la mente en este caso es la de restaurar un backup de los datos de cuando todavía había el usuario en cuestión, junto con sus correspondientes repositorios. Lo malo de esta opción es que perderíamos el trabajo realizado en todos los repositorios desde el momento de creación del backup hasta la restauración del mismo. Por lo tanto, esta opción se descartó y en su lugar se levantó un nuevo servidor a partir del backup y se dieron de alta manualmente en producción los repositorios eliminados. Se tuvieron que copiar los repositorios entre los dos servidores, volver a establecer los miembros con los permisos correspondientes, configurar las ramas, añadir las deploy keys, etc. Muy divertido todo...

Este es un ejemplo perfecto de la importancia de tener backups automatizados con políticas de retención correctas. La información digital es muy frágil y con una mala jugada puedes perderlo absolutamente todo.

Pesadilla 3: cierre de servidor

¿Qué hay más bonito que la llegada de una incidencia acerca de una llamada a una URL que no contesta (porque da timeout), de un proyecto que desconoces y que no mantienes tú? Es una pregunta retórica, no hace falta que contestes.

En este caso, hice un ping al dominio de la URL para ver si respondía alguien. Efectivamente, había respuesta de otro dominio interno, el cual me dio una pista de quién podría administrarlo (por el nombre que tenía). Así que acudí a un compañero, el cual me dirigió a otro que había cerrado un servidor que supuestamente ya no se usaba. Y digo supuestamente porque resulta que sí se usaba, se trataba de un frontal (reverse proxy) de varios portales y además alojaba una web, ¡viva la separación de responsabilidades! Por suerte, de todo lo que hacía solo se aprovechaba realmente como frontal para la web de la incidencia. Para solucionarlo, simplemente se volvió a levantar la máquina y todo volvió a fluir.

Este caso es un ejemplo claro de falta de organización. Si no sabes qué servidores tienes y qué hay en cada uno de ellos, es evidente que en un proceso de desmantelamiento y migración de servidores van a pasar cosas así. Y más cuando no hay ningún tipo de documentación y la gente que lo hizo ya no trabaja allí. No se trata de escribir una novela, pero al menos deberías saber qué dominios e IP tienes, en qué proveedores, qué servicios contienen, un breve resumen de lo que hacen y un responsable con el que contactar en caso de necesidad. Es importante actualizar la información cuando haya cambios, por ejemplo, en caso de traspaso de proyecto o de migración de servidor.