Un vistazo desde el infierno (o por que apoyo a los señores @benjami y @gallir).

Domingo de una Campus Party a 2 o 3 horas del cierre del servidor de Direct Connect, la introducción de un nuevo sistema en el servidor (con manifiestos problemas de concurrencia que sólo aparecieron al ir a vivo por el número de usuarios y que tardamos en identificar) junto a problemas con algunos usuarios que compartían contenidos ilegales a mitad de semana y un nuevo firewall mucho más restrictivo habían hecho mella en mis horas de sueño hasta el punto de acabar dormido sobre el suelo esa noche. Al poco de despertarme y mientras ando preguntando a los operadores que tal había ido en mi ausencia (y la de imobilis el otro root admin del DC por entonces) me comentan que han aparecido cientos de usuarios con contenidos ilegales  durante esa noche.

Tras indagar en las causas nos damos cuenta que las reglas de ADL por defecto, que instala el cliente cuando no hay ninguna, que en teoría deberían ocultar dichos contenidos para evitar su difusión los hacían aparecer en la cabeza de la lista con lo que muchos usuarios despistados se los bajaron creyendo que eran de otro tipo durante el frenesí de la última noche. Además conforme iban pasando los minutos su distribución aumentaba más y más por lo que era necesario tomar medidas cuanto antes.

Seguir el procedimiento tradicional no era factible pues no podíamos banear y atender personalmente a varios cientos de usuarios de una sentada, proponer que modificasen el archivo con las reglas tampoco era muy buena idea pues si se eliminaba se regeneraba y pedir que lo modificarán no sería fácil para los menos avezados. Tampoco podíamos adelantar el cierre del servidor (aunque en perspectiva quizás hubiera sido la mejor opción) porque nos habíamos comprometido a cerrarlo a una hora determinada y normalmente lo solemos hacer con ciertas tradiciones incluyendo una cuenta atrás con todo el equipo reunido.

Conforme intentaba aplicar la solución que aparentaba más factible (hacer búsquedas por los ficheros inadecuados y banear a los usuarios con un mensaje indicando claramente el fichero causante del ban) tenía a 5 compañeros insistiendo cada uno en aplicar una solución distinta. Y entonces… ocurrió. Cerré los ojos dos minutos me di cuenta de que yo no ganaba nada con esto, lo hacía por diversión y que la situación no iba a solucionarse de esta manera, al menos no con tanta presión a mis espaldas, y lo mandé todo a tomar por culo con un grito de rabia. Enfadado, les pedí a los 3 operadores que intentasen avisar a los usuarios del problema y banear a los afectados con un aviso claro. El admin auxiliar (un chico muy majo con muchos conocimientos de administración de sistemas pero que no conocía del todo la arquitectura del sistema) siguió insistiendo y cabreado le respondí que sí quería solucionarlo así (la solución estaba pensada a medio plazo como medida de prevención más que otra cosa) le dije que lo hiciera él, y me fuí furioso al baño (no había podido atender la llamada de la naturaleza desde hacía horas lo que contribuyó a mi cabreo).

Entonces ¿a qué viene esta anécdota? La situación es parecida a la de Gallir, el problema va haciéndose más y más grande conforme pasa el tiempo y los planes de contingencia fallan (no teníamos por entonces un plan de contingencia para algo así porque lo considerábamos muy improbable). Para más INRI el otro administrador (imobilis) en ese momento estaba durmiendo y no podíamos contar con él porque tenía que conducir hasta Granada ese día, lo que mermó aún más nuestra capacidad de respuesta. Sin embargo aprendimos muchas cosas de esta.

  1. El equipo de operadores y administradores de DC gracias a los años que llevamos tratando hemos desarrollado una complicidad que nos permitió recuperarnos en las horas siguientes, de hecho los propios operadores pidieron ayuda a compañeros de su clan para resolver la situación y cuando volví 1 hora después me habían perdonado todo y el problema estaba casi resuelto.
  2. Nunca confíes en que un cliente no puede fastidiarla, el fallo de un cliente distribuido entre más de la mitad de los usuarios es más grave que un fallo en el servidor (queremos intentar tener un sistema de actualizaciones automáticas integrado en el cliente por si acaso).
  3. Hay algo más importante que un buen plan de contingencia: un buen equipo. Un equipo preparado te resolverá los problemas cuando los planes fallen.

En fin, esta entrada quería escribirla desde que pasó aquello, así que sólo agradecer al equipo su ayuda y compresión de nuevo. Y apoyar a Gallir y decirle que de mayor quiero ser cómo él pues la última vez que me comí un marrón tan grande reventé en vez de tomarmelo todo con tanta calma y profesionalidad como él.