El primer mensaje de internet fue «LO» y luego se cayó todo

Hoy, 29 de octubre, cumple años el primer mensaje enviado entre dos ordenadores de ARPANET. Fue el 29 de octubre de 1969, hacia las diez y media de la noche en California. En España ya era la mañana del día 30: una hora no dice nada sin su zona.

El mensaje fue LO.

No es una abreviatura ni una clave. Es lo que quedó de una palabra que se cortó por la mitad.

Un Interface Message Processor de BBN, el «router» de ARPANET, en el Computer History Museum. Foto: Carlo Nardone, CC BY-SA 2.0; imagen recortada y disponible bajo la misma licencia.

Qué pasó exactamente

Charley Kline, estudiante en el laboratorio de Leonard Kleinrock en la Universidad de California en Los Ángeles, tenía que conectarse al ordenador del Stanford Research Institute, a más de quinientos kilómetros, donde esperaba Bill Duvall.

El procedimiento era escribir log y el sistema del otro lado completaba solo el resto hasta formar login.

Kline tecleó la l.

Y aquí viene la parte que hace que esta historia sea buena. Al teléfono con Duvall, preguntó: «¿Has recibido la ele?». Del otro lado: «Recibida la ele».

Tecleó la o. «¿Has recibido la o?». «Recibida la o».

Tecleó la g.

Y el sistema del SRI se cayó.

Así que el primer mensaje transmitido por la red que acabaría siendo internet fue LO, por accidente. Corrigieron el fallo y, aproximadamente una hora después, el login completo funcionó.

Lo mejor de la historia es el teléfono

Fíjate en lo que estaban haciendo: verificar el canal nuevo usando un canal viejo que sabían que funcionaba.

Eso tiene nombre. Se llama comunicación fuera de banda, y es una de esas ideas que parecen triviales hasta el día en que no la tienes.

La pregunta para tu organización es directa: cuando se cae vuestro sistema, ¿por dónde habláis?

Y la respuesta habitual, si uno la persigue un poco, resulta ser incómoda:

• El chat donde coordináis las incidencias corre sobre el mismo proveedor de identidad que acaba de fallar.
• La lista de teléfonos del equipo de guardia está en la intranet. Que está caída.
• El runbook con los pasos de recuperación vive en el wiki. Que está en el servidor afectado.
• Las credenciales de emergencia están en el gestor de contraseñas corporativo, que necesita el segundo factor, que llega por el correo, que es lo que se ha caído.
• La lista de contactos de clientes para avisar del incidente sale del CRM. Adivina.

Cada uno de esos casos es perfectamente razonable en un día normal y perfectamente inútil en el único día en que hace falta. Un plan de recuperación que depende del sistema que hay que recuperar no es un plan.

La versión mínima que funciona no necesita presupuesto: un documento fuera de vuestra infraestructura —o impreso, sin complejos— con los teléfonos móviles del equipo, los datos de contacto del proveedor de hosting y del registrador del dominio, los pasos de recuperación y dónde están las credenciales de emergencia. Y un canal alternativo acordado de antemano, aunque sea un grupo de mensajería personal.

Que sepan todos que existe. Porque el otro fallo clásico es tenerlo y que lo sepa solo quien lo escribió, que ese día está de vacaciones.

La confirmación explícita

La otra idea que ya estaba ahí, aquella noche de 1969, es la de confirmar cada paso en lugar de suponerlo.

«¿Has recibido la ele?» «Recibida la ele.» Eso es un acuse de recibo, hecho a mano y por voz, y es la misma idea básica de los protocolos fiables de red: nada se da por entregado hasta que el otro extremo dice que lo tiene.

Y sigue siendo la diferencia entre una integración que funciona y una que parece funcionar:

• Enviar un evento y no comprobar si el otro extremo lo procesó no es integrar: es esperar.
• Un 200 OK dice que esa petición salió bien, no siempre que haya terminado todo lo que desencadena. Hay que saber qué garantiza esa API y comprobar el resultado que necesitas.
• Un proceso nocturno que no avisa cuando no se ejecuta es indistinguible de uno que se ejecuta bien. Y llevará roto el tiempo que tarde alguien en mirar los datos por otro motivo.

Que no lleguen errores no es lo mismo que que llegue confirmación. Es la misma trampa de los avisos que no distinguen nada, como los 97 correos de Knight Capital, pero por el otro lado: allí sobraba ruido, aquí falta señal.

Y se cayó a la tercera letra

Última cosa, y es la que más tranquiliza.

El primer intento de la red más importante de la historia se estrelló en el tercer carácter. A las diez y media de la noche, después de meses de trabajo.

No lo dejaron ahí. Buscaron el fallo, lo corrigieron y una hora después volvieron a probar. Funcionó.

Merece la pena tenerlo presente la próxima vez que algo tuyo falle en la primera demostración. El registro del laboratorio anotó aquella conexión con una sola línea, igual que el cuaderno del Mark II anotó su polilla. Esa línea fija la fecha y la hora; las letras y el teléfono los conocemos porque quienes estaban allí lo contaron después. Hacen falta las dos cosas, y la primera solo existe si alguien se molesta en escribirla en el momento.

Feliz aniversario

Cuatro cosas para hoy:

1. Escribe dónde está tu canal fuera de banda. Si no existe, empieza por dejarlo acordado: un documento y un canal alternativo, no un proyecto.
2. Comprueba que el runbook no vive dentro del sistema que describe.
3. Busca un proceso automático que no confirme nada cuando termina bien. Hazle emitir una señal de vida, y que su ausencia dispare una alerta. Un silencio que nadie vigila no confirma nada.
4. Prueba a llamar al teléfono de guardia. Ahora. Los números caducan y nadie se entera hasta la noche mala.

(Y si alguien te dice que el primer mensaje de internet fue «Hola mundo» o algo igual de digno, corrígelo: fueron dos letras y luego se cayó todo. Empezamos exactamente como seguimos.)