Las tres normas de Gremlins son las tres normas del desarrollador

Hoy, 8 de junio, cumple años Gremlins. Se estrenó en 1984, la dirigió Joe Dante y la produjo Spielberg.

Y viene con el mejor manual de operaciones jamás escrito. Tres normas. Tres. Cortas, claras, memorizables, y te las dicen antes de entregarte el sistema:

1. No lo mojes.
2. No le des luz.
3. No lo alimentes después de medianoche.

Cualquiera que haya trabajado en producción sabe cómo acaba esto. Y también sabe que el problema nunca fue el Mogwai.

Yo tengo mis tres normas. Llevo veinte años repitiéndolas y sigo viendo las tres romperse todas las semanas:

1. No hagas deploy el viernes.
2. No toques producción directamente.
3. No hagas un UPDATE sin WHERE.

El paralelismo no es solo una gracia. Es que fallan por el mismo mecanismo. Vamos una por una.

Norma 1: no lo mojes → no hagas un UPDATE sin WHERE

Esta es la pareja perfecta, y no por el chiste: por la multiplicación.

Mojas un Mogwai y no tienes un Mogwai mojado. Tienes cinco. El daño no es proporcional a la acción, se reproduce solo.

-- Lo que querías
UPDATE usuarios SET plan = 'premium' WHERE id = 4213;

-- Lo que ejecutaste
UPDATE usuarios SET plan = 'premium';

Ocho caracteres de diferencia. Y no has modificado un registro de más: has modificado todos. Cuarenta mil. Y como fue un solo comando y terminó sin error, la base de datos te dice Query OK y se queda tan tranquila.

Eso es exactamente el agua sobre la piel del Mogwai. Una acción pequeña, un resultado que se extiende por sí mismo, y ningún aviso.

Lo que hago, sin excepción, cuando toco datos a mano:

• Escribir el WHERE primero. Literalmente: empiezo la frase por el final y luego escribo el UPDATE delante.
• Ejecutarlo antes como SELECT. Si el SELECT con ese WHERE devuelve cuarenta mil filas, ya lo sé antes de romper nada.
• Abrir transacción cuando el motor lo permite: BEGIN, mirar el número de filas afectadas, y solo entonces COMMIT.
• Y no trabajar cansado sobre la base de datos de producción, que es la norma que de verdad previene el incidente y la que nadie escribe en ningún procedimiento.

Norma 2: no le des luz → no toques producción directamente

La luz fuerte mata a los Gremlins. La luz del sol, instantáneamente. Es la única cosa del universo de la película que es inmediata e irreversible: no hay negociación, no hay tiempo de reacción, no hay «espera que lo arreglo».

Producción es eso.

En tu portátil te equivocas y lo vuelves a intentar. En el entorno de pruebas te equivocas y avisas por el grupo. En producción te equivocas y ya está: los datos que has pisado estaban vivos, el pedido que has borrado era de una persona real y el correo que se ha enviado a nueve mil suscriptores no vuelve.

La diferencia entre un equipo profesional y uno que va tirando no es la calidad del código. Es si existe un camino y solo uno para llegar a producción. Si hay dos —el proceso, y además el acceso directo por si acaso—, el segundo se usará. Siempre. Sobre todo un viernes a las siete.

Y ojo con la trampa que veo continuamente: tener el proceso montado y saltárselo justo cuando hay una urgencia. Es como decir «los Gremlins no salen de día, salvo cuando hay prisa».

Norma 3: no lo alimentes después de medianoche → no hagas deploy el viernes

Aquí está la norma más famosa y la más rota. Y también la que esconde el mejor chiste técnico de la historia del cine, aunque nadie lo escribiera con esa intención.

Porque la norma es defectuosa. Piénsalo dos segundos:

¿Después de medianoche hasta cuándo?

Siempre es después de medianoche. Son las cuatro de la tarde y también es después de la medianoche de hoy. ¿A qué hora deja de ser tarde? ¿Al amanecer? ¿Y en qué zona horaria? ¿La del Mogwai, la de la tienda de Chinatown, la del huso donde lo compraron?

Es una especificación sin zona horaria ni ventana definida, o sea, el bug más caro y más repetido del oficio. Todos hemos vivido su versión moderna:

• El informe «de ayer» que a las 00:30 sale vacío porque el servidor está en UTC y el usuario en Madrid.
• La suscripción que caduca «a medianoche» y se corta a las 22:00 para media plantilla.
• El cambio de hora de octubre, cuando las dos y media de la madrugada ocurre dos veces y el proceso nocturno se ejecuta dos veces con ella.
• El BETWEEN de fechas que se deja fuera el último día porque compara contra medianoche en punto.

Si tu sistema tiene una regla que depende de la hora, la regla no está escrita hasta que dice la zona horaria y los dos extremos del intervalo. «Después de medianoche» no es un requisito, es una conversación pendiente.

Y en cuanto al viernes: el motivo real no es superstición ni pereza. Es que el coste de un incidente no lo determina el fallo, lo determina el tiempo que tardas en enterarte y quién hay disponible para arreglarlo. El mismo error un martes a las diez son veinte minutos con todo el equipo delante. El viernes a las siete son cuarenta y ocho horas de degradación con una persona de guardia mirando código que no escribió.

No es que el viernes se rompa más. Es que el viernes el mismo fallo cuesta veinte veces más.

El problema nunca fue Gizmo

Y esta es la parte que de verdad importa, porque es la que se repite en todos los informes de incidencia que he escrito.

Las normas existían. Estaban dichas. El anciano de la tienda las dejó claras y advirtió de que aquello conllevaba una responsabilidad. La información estaba disponible, era correcta y era completa en lo esencial.

Y se rompieron las tres igualmente.

No por maldad ni por estupidez. Se rompieron por el mecanismo de siempre:

• Nadie explicó el porqué. «No lo mojes» sin «porque se multiplican» es una superstición, y las supersticiones se saltan en cuanto molestan. Un procedimiento sin motivo escrito al lado tiene fecha de caducidad.
• La norma se transmitió por el canal equivocado. Se la dijeron al padre, de pasada, en una tienda. No quedó junto al sistema. La documentación que no vive pegada a la cosa que documenta no existe.
• Y el fallo llegó por una tubería que nadie había considerado. Una gotera. Nadie desobedeció «no lo mojes»: simplemente el techo tenía una fuga. Que es como pasan las cosas de verdad: no por la puerta que vigilas, sino por la que no sabías que era una puerta.

Esa tercera es la buena. Escribe la norma pensando en el escenario que sí has previsto, y el incidente llegará por el que no. Por eso los procedimientos por sí solos no bastan y hace falta lo aburrido: monitorización, alertas y copias restaurables. Los controles preventivos protegen de lo que imaginaste. Los detectivos y los de recuperación protegen del resto, que es la mayoría.

De esto va, en el fondo, insistir en el mantenimiento cuando nadie quiere pagarlo: no es evitar que entre agua. Es tener claro qué pasa cuando entre.

Y encima es una película de Navidad

Detalle que me hace una gracia enorme: Gremlins pasa en Navidad. El regalo es un regalo de Navidad, y todo se va al infierno en las fiestas.

O sea que la película consiste en un sistema nuevo puesto en marcha la semana en la que no hay nadie de guardia.

Cualquiera que haya vivido una campaña de diciembre sabe por qué las empresas serias congelan los cambios en esas fechas. No porque diciembre sea peligroso: porque diciembre es el mes en el que el equipo no está, y ya hemos dicho que el coste de un fallo depende de quién hay para atenderlo.

Los Gremlins no eligieron la Navidad por casualidad. Eligieron la ventana de menor cobertura. Como todo incidente serio que he vivido.

Feliz aniversario

Cuarenta y dos años de la mejor documentación de operaciones del cine.

Hoy:

1. Coge una norma de tu equipo y escríbele el porqué al lado. Si no puedes, no es una norma: es una costumbre.
2. Busca el segundo camino a producción, el de «por si acaso». Ciérralo o legitímalo, pero no lo dejes en la penumbra.
3. Y revisa tu regla que depende de la hora. No está escrita hasta que diga la zona horaria y los dos extremos.

Y sobre todo: escribe el WHERE primero.

(Gizmo, por cierto, se portó bien toda la película. El único que cumplió el manual fue él.)