Incendios, planes de contingencia y la pegatina

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.

Dónde está el LISP, los sistemas expertos, la completitud de Turing y las gramáticas de Chomsky, que yo las vea.

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)

SolarWinds y Supernova, un fiasco de ciberseguridad

Leo el artículo de Bruce Schneier sobre el hackeo masivo a la administración estadounidense y hasta el tato en realidad (Microsoft también) debido a una vulnerabilidad en el protocolo de seguridad del omnipresente producto Orion de la empresa Solar Winds. Da qué pensar lo frágil que es la sociedad actual a este tipo de soluciones, y pensando talebianamente, me pregunto qué podemos hacer a modo personal ya no para ser robustos (a la Sara Connor) sino para ser antifrágiles a este tipo de situaciones.

Un dron vigilando tu hogar. ¿qué puede salir mal?

Hace ya once añazos andábamos por aquí comentando con sorpresa que Microsoft estaba trabajando duro en el proyecto Natal. Acabaron llamándolo Kinect, ya saben, el control de la consola XBox que usaba una cámara.

Ayer, una vuelta de tuerca: Amazon anunció una cámara de videovigilancia que se da vueltecitas volando (literal) por tu casa a horas concertadas para que puedas ver a través de tu teléfono que todo está bien.

Afirman que hay más problemas de privacidad con el teléfono que llevas en el bolsillo que con este nuevo dispositivo.

Lo triste es que es cierto.

Lo más triste aún es que esos drones con cámara van a salir del hogar y pronto, muy pronto, los tendremos dando vueltas por nuestros pueblos y ciudades.

Y es que a la vez que el dron, Amazon ha anunciado la red Sidewalk, una especie de fon, o mesh network, o como quieran decirle, para que el excedente del internet de tu casa lo puedan usar los dispositivos IoT Amazon de tus vecinos si su conectividad va flojilla (y viceversa).

Obvio que esos drones callejeros van a usar Sidewalk.

Nos está quedando un futuro guapo, guapo.

Neuralink

Varias cosas que salieron en la presentación de Neuralink de este año:

  1. La novedad es que el paper que presentaron el año pasado se ha implementado. Se trata de un robot cirujano capaz de realizar implantes de 1024 electrodos en el cerebro. Una cosa interesante es que tiene la capacidad de evitar la vascularidad, o sea: nada de sangrado. Eso sí: te llevas una trepanación y sustituyen parte de tu cráneo por un material de características similares.
  2. El implante se comunica con el exterior a través de Bluetooth Low Energy (BLE) y dicen que las comunicaciones entre todas las capas van cifradas.
  3. Lo han probado con cerdos. Los han implantado y también los han retirado, porque el concepto es el de un procedimiento reversible, ya sea por cambio de opinión, o para actualizar con un modelo nuevo. El cerdo es similar al humano en su fisiología y además se pega cabezazos por todas partes.
  4. La primera parte de la demostración era la lectura de las neuronas disparándose en reacción a estímulos en el morro de un cerdo que se paseaba por su jaula en el estudio de grabación.
  5. La segunda parte de la demostración fue poner a un cerdo en una corredora, y ser capaces de predecir la posición de las articulaciones de sus patas en base a la lectura de los disparos de las neuronas.
  6. Obviamente el implante de cada uno de esos cerdos se hacía en las respectivas regiones del cerebro que controlan el morro y la motricidad. No es «un solo implante para todas las funcionalidades» (al menos con el número de electrodos actual y hasta que logren implantar varios órdenes de magnitud más).
  7. No hubo demo, pero se nos dice que el implante es de «lectura y escritura», es decir, que se pueden estimular neuronas para que se disparen.
  8. Las primeras aplicaciones, como ya había anunciado Musk a través del blog de Wait but why?, son médicas. Las obvias son visión para invidentes y motricidad para paralíticos.
  9. Han obtenido el visto bueno de la FDA para seguir adelante con sus investigaciones clínicas.
  10. Están a punto de iniciar el reclutamiento del primer estudio clínico: motricidad de tetrapléjicos. Se explica que se hará un «bypass»: Neuralink se comunicará con otro implante que esté más abajo de la zona de la columna lesionada, y de ese modo el paciente podrá entrenar a su cerebro para que controle sus miembros.
  11. Hubo una sesión de preguntas y respuestas con todos los empleados de Neuralink.
  12. Sí se mencionó Dark Mirror y sí se anticipa la capacidad de hacer «backups» de los recuerdos de las personas.
  13. Elon sí mencionó el tema de riesgo a nuestra especie que él advierte en la emergencia de una inteligencia artificial avanzada.
  14. ¡El objetivo de la presentación fue contratar personal!

déjà vu: El Halo de amazon y el neuralink de musk vs microsoft pre-satya nadella

Hay algo de cachondeo en mi TL de Twitter sobre el nuevo anuncio de Amazon: Halo, un wearable que te dice si estás enfadado o si estás gordo (según titulares nacionales, The Verge da algo más de detalle aparte del chistecito).

Pasando esto en la semana que Elon Musk hace su presentación anual de los avances de Neuralink, y se dice, se cuenta, se rumorea que será una demo con humano.

De repente me he acordado de algo que escribimos por aquí hace muchos años (febrero de 2007 y enero de 2008 para ser más precisos) cuando Microsoft, el insensible, o sea, el anterior a Satya Nadella, compartió un concepto de ordenador que se pudiera armonizar con su propietario para proporcionarle información y tareas conforme a su estado de ánimo.

Es llamativa la reacción de rechazo que tales planteamientos generaban hace una década y pico. Ahora ya estamos habituados a que nos escuchen y vean constantemente, y hasta muchos estarían dispuestos a que les coloquen un «puerto» detrás de la oreja para facilitar la integración persona-máquina. Y es que prácticamente somos ciborgs, nuestro smartphone es un apéndice más. Ante una duda ¿acaso no piensan en cómo buscar la información en lugar de intentar recordarla?

el HARPA como nunca lo habíamos conocido

Harpa

El otro día cayó en mis manos este artículo de Gizmodo, cortesía de Pere, a raíz de una conversación sobre «fitness trackers» y su utilidad.

Parece ser que los últimos tiroteos en Estados Unidos no han sido suficiente desgracia. Ahora el presidente de ese país ha anunciado que para evitarlos hay que inventar una especie de «Minority Report» y qué mejor que usar los datos de Fitbit para identificar qué ciudadanos están a punto de perder la cabeza y echarse al mall (y después al monte) con un rifle automático.

¿Dónde acoger a las personas que se van a dedicar a ello? Fácil, en el HARPA. No, no uno de los que ilustran el post. Es como el DARPA pero para temas de salud: una organización gubernamental secreta dedicada a desarrollar tecnología para fines estratégicos.

Que lo primero que se le ocurra a las autoridades estadounidenses para mejorar la salud del país, que el primer encargo de esta futura HARPA sea un sistema predictor de problemas de salud mental de su ciudadanía es… enloquecedor.

Amazon rekognition en todos los interfonos y timbres de la puerta: ¡mala idea!

En el evento AWS re:Invent de 2017, Amazon anunció su producto de reconocimiento de imagen «Rekognition«.  Este evento anual es mareante, no solo por la cantidad de productos que se anuncian, sino por la creciente facilidad para integrarlos, en una especie de Lego gigante, donde los límites de lo posible los dictan tu imaginación y tu bolsillo. En el re:Invent de 2018 anunciaron más cosas todavía (¡estaciones de recepción de señales de satélites «on demand»!), pero eso lo dejamos para otro post.

Vuelvo a 2017. Cuando oímos hablar de «Rekognition», algunos nos echamos a temblar. Porque funciona no solo para imágenes estáticas, sino para videos, incluido en streaming, y porque si te pones el gorro distópico, no dejas de pensar en malos usos para esa tecnología. 

Pues este año ha salido a la luz una patente publicada por Amazon que combina «Rekognition» con el producto estrella de Ring, una compañía recién comprada por el grupo de Jeff Bezos. Adivinen qué fabrica Ring: timbres para la puerta. Ahora imaginen todos los timbres, todos los telefonillos, con una cámara que está constantemente grabando y que constantemente esté utilizando «Rekognition» para identificar caras y después compararlas con «fotomatones» de personas con un antecedentes penales. Conecten el sistema con la centralita de la policía local. Y añadan a la mezcla que el reconocimiento facial es especialmente fallón cuando se trata de personas de faz morena o mujeres. El último ingrediente es que estos sistemas sofisticados dan una sensación de falsa seguridad: se les supone una infalibilidad que no tienen. 

¿El resultado? Una pesadilla legal para los pobres «falsos positivos» que decidan salir a pasear y tengan la mala suerte de ser filmados por un timbre «Ring».

Aquí se pueden leer lo mismo que explico yo, pero más bonito y en inglés: ACLU Northern California.

Bye bye GoDaddy. Sveiki, Hostinger!


Estoy en proceso de resucitar este blog y resto de publicaciones que llevaban un largo tiempo agonizando debido principalmente a mi poca dedicación, y en segundo lugar al decrépito entorno de hosting que GoDaddy proporciona hoy en día.

Estas son las cosas que han colmado el vaso de mi paciencia y la han hecho más fuerte que mi apatía:

Así que, como ya he anticipado en el punto anterior, ahora estoy con Hostinger. Todo más fácil, más rápido (incluida una opción de deploy automático desde repos Git), una mejor experiencia. Los lituanos me han vuelto a despertar la curiosidad por ver cómo se adaptan los servicios de hosting a la era del Cloud, y el gusto por «trastear».

Sveiki ir ačiū, Hostinger!

Si ves las barbas de tu vecino pelar… «Posible incumplimiento de la Ley 34/2002, de 11 de julio»

Ayer una amiga, un poco preocupada, me pidió consejo sobre un correo que acababa de recibir. Lo enviaba el Ministerio de Energía, Turismo y Agenda Digital, y era sobre el incumplimiento de nuestra amiga la LSSI. Tiene una tienda «física» y una página Web estática, hecha con mucho cariño, eso sí, sobre la cual recibía este aviso de incumplimiento de la ley, información resumida sobre la Ley con consejos de cómo cumplirla, y el consejo de subsanar el tema para evitar recibir multas.

Ministerio de Energía, Turismo y Agenda Digital

La ley es de 2002, o sea, lleva suficiente tiempo vigente para considerarse establecida, y todos sabemos que no conocer las leyes no nos exime de la obligación de cumplir con ellas, por lo que me parece hasta «un detalle» que envíen avisos con instrucciones en lugar de la multa directamente.

Este es el texto íntegro:

La Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico (LSSI), establece para aquellas personas (tanto particulares como empresas establecidas en España o que dirijan sus bienes o servicios al público español) una serie de obligaciones que han de cumplir. Esta ley es de aplicación a aquellas páginas web que realicen actividades que tengan un fin económico o lucrativo.

Entre dichas obligaciones se encuentra el deber de proporcionar en dichas páginas información sobre la identidad de su titular o sobre los precios de sus productos (artículo 10 de la Ley 34/2002), de manera que tanto las autoridades competentes como los usuarios puedan acceder a ella de manera permanente, fácil, directa y gratuita. Asimismo, en caso de que, a través de dicha página web se pueda contratar electrónicamente (compras, reservas,…), además de las obligaciones anteriores, el titular tendrá la obligación de proporcionar al destinatario la información recogida en los artículos 27 y 28 de ley.

Sin embargo, se ha observado que su página web no cumple con alguna de estas obligaciones.

Por este motivo, le recordamos que, a fin de garantizar la transparencia y confianza de los usuarios, y evitar posibles sanciones, deberá incluir en su página web la información indicada en el documento que se adjunta.

Puede obtener una información más detallada sobre los contenidos y obligaciones de la Ley 34/2002 a través de la página web www.lssi.es.

Subdirección General de Servicios de la Sociedad de la Información
Secretaría de Estado para la Sociedad de la Información y la Agenda Digital
Ministerio de Energía, Turismo y Agenda Digital

Parece ser que el Gobierno se está armando de herramientas modernas (¿big data + agentes + algo de IA?) para hacer rastreo de la Web e identificar estas infracciones. Os aseguro que la página de mi amiga es una gota en el océano, que no tiene ni SEO ni SEM y por lo tanto recibe poquísimas visitas, así que si esto se lo han mandado a ella, se lo van a mandar a todo el mundo.

Así que recomiendo encarecidamente hacer los cambios necesarios en vuestros sitios Web para cumplir con la ley.

Aquí podéis encontrar el PDF de 2 páginas con la información necesaria.

Si no haces venta online, con estos puntos descritos en el PDF hay suficiente:

a) Nombre o denominación social, residencia o domicilio, correo electrónico y cualquier otro dato para establecer comunicación directa y efectiva (formulario de contacto, teléfono o fax).
b) Los datos de inscripción registral (obligación no exigible a los particulares).
e) Número de identificación fiscal.

Si tienes algún tipo de catálogo de productos con precios, entonces necesitarás también poner esto:

f) Si los productos o servicios se muestran con su precio, deberá indicarse, de manera clara y exacta, si éste incluye o no los impuestos aplicables y, en su caso, los gastos de envío.

Tecnologías de la información y la comunicación, libertad individual, derecho a la privacidad. ¿Cómo lograr que los avances en lo primero no afecten negativamente ni a lo segundo ni a lo tercero?