La #bonillista de hoy, escrita por Txetxu Velayos y tratando el tema del incendio del proveedor de servicio de almacenamiento OVH, los SLA (acuerdos de nivel de servicio) y qué diablos pasa cuando lo impensable sucede, me ha traido a la mente mis viejos tiempos de SysAdmin, así como esta pegatina. Agárrense, que vienen batallitas que ni las de la mili:

Vamos al tajo. Yo salí de la universidad como «computer scientist» de los de verdad: no me dejé ni una asignatura de matemáticas, ni de lógica, ni una de complejidad algorítmica, sistemas formales, inteligencia artificial. Me quité de encima la electrónica en cuanto me lo permitió el plan de estudios, aunque me chuté todas las de arquitectura de computadoras por lo flipante de la optimización de algoritmos que se explicaba, y la verdad sea dicha, las cosas en las que pensaba estaban muy distantes de la máquina o incluso de lo que se esperaba de un informático en el mercado laboral español de los años 90. Así que me fui… (insert other batallitas here…)

… y por azares del destino, ¡¡¡muy pronto me vi trabajando de administradora de sistemas!!! 200 servidores Windows NT distribuidos por toda Europa, medio centenar de ellos en el Data Center de la oficina.

¿Data Center en la oficina? Sí. De hecho el primer curso de formación que me dieron en esa empresa fue… ¡¡¡Halón!!! que era el gas que se liberaba en los data centers de aquella época en caso de incendio.

Eran unos tiempos muy curiosos. ¿Abrías una oficina o una fábrica en, pongamos por ejemplo, Hannover? Pues entonces tenías que deplegar al menos un servidor de ficheros y de impresión local, que además te servía de controlador de dominio. ¿Y cómo desplegabas? «Facilísimo». Hablabas por teléfono con tu proveedor de hardware (por ejemplo Compaq), acordabas con él la especificación del servidor y te mandaba el presupuesto. Lo imprimías, conseguías la firma de tu jefe y lo llevabas al departamento de Compras, que emitía el pedido. Un mes después más o menos te llegaba.

Te llevabas las cajas a tu mesa de trabajo, desembalabas la carcasa, los discos, el procesador, la memoria, otras tarjetas que necesitases (¡por ejemplo, una de fax!), pero normalmente eso era todo. Lo montabas todo (usando las manos, destornilladores,..), sacabas de tu cajón los CD’s y te ponías a instalar el sistema operativo, otros programas servidor (¡hola, MTA’s de MSMail y Schedule+!), lo dejabas todo listo para que en destino cambiases la direccion IP, conectases a la red y ¡todo listo!

Usar una imagen era impensable, el Ghost fallaba como escopeta de feria. Yo me automatizaba todo lo posible con DOS scripting (un conocimiento que muchos años después me ha hecho parecer una diosa nubia ante compañeros bastante buenos pero que en la vida habían visto una línea de comandos), todo y ello había muchísima componente manual en lo que hacíamos.

En destino (Hannover en este ejemplo) significaba: Si estabas a menos de 500 Km de distancia sin el Canal de la Mancha por el medio, metías tu servidor al coche, te pegabas un día conduciendo y al día siguiente montabas (si era el primero, también tenías que montar el rack). Si no, enviabas el servidor montado por paquetería, te pillabas un avión y allá ya acababas.

Esta última fase del trabajo podía durar de 15 minutos (colocar servidor en el rack, arrancar, cambiar la IP, conectar a la red, reiniciar) a 8 horas (hacer la instalación completa desde cero). El año 2000 me pilló con este trabajo, así que la cantidad de horas extra actualizando / sustituyendo servidores fue indecente. Idem la cantidad de puntos de línea aérea que acumulé y las ciudades que pude conocer cuando se alineaban los astros y la máquina arrancaba a la primera. De la complejidad algorítmica, ni rastro.

Se imaginan los LOLZ que me pego yo sola cuando alguien jovencito se estresa por hacer un deploy de una máquina en AWS hoy en día 🙂 Ya en serio, esta experiencia me permite apreciar y agradecer todo lo que el IaaS, el PaaS, el SaaS, la nube, el DevOps y resto de siglas nos permiten hacer sin despeinarnos. La verdad, me quito el sombrero ante AWS, que inició todo esto, y resto de proveedores que no se quedan atrás .

Aparte de este trabajo eminentemente técnico y machacón, también nos encargábamos de la seguridad, los parches, el soporte, el diseño de la configuración de nuevos equipos y nuevas versiones de software… y las tareas que considerábamos administrativas y aburridas, no por ello menos importantes, al menos para nuestro management, que, quizás por aquello de que los servidores eran trastos con los que convivíamos, no entes virtualizados de varios niveles de abstracción, entendían lo que teníamos entre manos y podían ejercer sin problemas su sentido común.

Sentido común en este contexto es:

• ¿Cómo diablos sigo operando mi negocio (vendiendo, produciendo, entregando, cobrando facturas, pagando proveedores y nóminas) si me quedo sin todo este trasterío?
• ¿Cómo diablos recupero todo este trasterío, si se destruye, por ejemplo debido a un incendio? Recuperación de la información así como restauración del servicio.

A lo primero se le llama Business Continuity Plan. A lo segundo, Disaster Recovery Plan. Era nuestra obligación que ambos planes existiesen, estuviesen actualizados y fueran coherentes, aunque el primero lo compartíamos con las áreas operativas. Ellos sabían: ¿Cuál era el nivel de servicio que proporcionábamos a nuestros clientes? ¿Disponibilidad de atención a cliente, de tiempos de entrega, de stock de producto, todo ello por obligación contractual? En base a todo ello se escribía el plan y se tenía todo preparado por si había que utilizarlo. Eso significaba desde tener libretas de papel y bolígrafos para poder capturar pedidos, así como una preorden de oficina por si hay que mover allá el call center, poder enrutar las llamadas entrantes a unos cuantos teléfonos móviles, hasta tener los sistemas de información duplicados y poder hacer el cambio en caliente en caso de no disponibilidad del sistema principal.

Antes de explicar el Disaster Recovery Plan, déjenme hablar de backups o copias de seguridad. Antes de que se inventaran los backups por red, se hacían copias de respaldo de todos los servidores cada noche. Una vez a la semana hacíamos la copia completa, el resto de días solo la incremental. Y cada mañana enviábamos por paquetería los cartuchos de backup a la empresa que gestionaba los backups. Los cartuchos, por cierto, no se insertaban solos, había que empujarlos y a la mañana siguiente, sacarlos. Con las manos. En ubicaciones muy remotas contábamos con la valiosísima colaboración de la señora de la limpieza (que era la última persona en dejar la oficina por la tarde) para este menester.

Para el Disaster Recovery Plan, teníamos contratado un servicio con esa misma empresa que, caso de necesitarlo, ponía a nuestra disposición el hierro (servidores) y los CDs y los manuales que nosotros les hubiésemos proporcionado, así como la última versión de backup que habían recibido de nosotros. A esa ubicación se enviaba un equipo de técnicos (nosotros) para reconstruir todo y llevarlo a un punto que pudiera restablecerse el servicio de sistemas de información.

Lo más divertido es que en el plan incluíamos un ejercicio anual de prueba del propio plan (un quién vigila al vigilante, vamos). Me tocó participar una vez: coche en Manchester desde Londres a toda velocidad (nos cronometrábamos para ver cuán rápido podíamos restablecer el servicio), trabajar 16-20 horas seguidas hasta que todo quedase (y luego un fiestón mancuniano, una siestaza y de vuelta al sur). Y si no quedaba, pues entonces teníamos otra semana de trabajo garantizada identificando el por qué, corrigiendo los fallos en el procedimiento y volviendo a documentar.

Y vaya si son necesarios estos planes. Disaster Recovery no llegué a experimentar en vivo, Business Continuity Plan, sí. Nos explotó una empresa química en el polígono, nos evacuaron y se tuvo que montar sobre la marcha. Es una sensación increíble saber que tu pedantería a la hora de elaborar documentación ha significado que ningún paciente de EPOC de la campiña inglesa se ha quedado sin su entrega de oxígeno medicinal.

Volvamos a la actualidad: No existe ninguna razón por la cual tanto el Business Continuity Plan como el Disaster Recovery Plan hayan dejado de ser necesarios. Creo que las nuevas generaciones, especialmente las de management, están practicando el proverbial «ojos que no ven, corazón que no siente». Has migrado tu infraestructura a la nube. Cierto, ya no necesitas dos meses para aprovisionar hardware. Ya no necesitas pagarme el avión a Hannover, ni siquiera pagarme el sueldo. Pero la magia no existe. Solamente has externalizado la gestión de la infraestructura informática, eso significa que alguien más se ocupa de ella, pero no por ello es, por arte de contrato, irrompible: it’s someone else’s computer! Sigue siendo tu resonsabilidad estar preparado porque shit happens also on the cloud, tienes que saber cómo seguir dándole servicio a tus clientes (Business Continuity Plan) así como disponer de un Disaster Recovery Plan, o, en castellano común, cómo no perder irremediablemente lo más importante de una empresa del siglo XXI: tus datos, tu información, tu inteligencia. El poder echarle la culpa a otro con el contrato en la mano no te los va a devolver.

Enlace a la #bonillista de hoy: La Bonilista (mailchi.mp)