Resumen
El 19 de enero de 2026, entre las 14:02 y las 14:28 UTC, aproximadamente dos tercios de todos los intentos de iniciar sesión en el panel o autenticarse contra la API fallaron. Las sesiones existentes también se invalidaron aleatoriamente. Las instancias en ejecución, sus redes y su tráfico no se vieron afectados en ningún momento. El aprovisionamiento se pausó durante veintiséis minutos y luego se drenó; no se perdió ningún pedido.
Cronología
Todas las horas en UTC, 19 de enero de 2026.
| Hora | Evento |
|---|---|
| 14:02 | Se aplicó un cambio en el esquema de tokens de sesión al plano de control. El despliegue se marcó como configuración, por lo que llegó a los seis nodos del panel a la vez. |
| 14:03 | La tasa de error de inicio de sesión aumenta de casi cero al sesenta y uno por ciento. La alerta automática tiene una ventana de dos minutos y aún no salta. |
| 14:06 | Salta la alerta. Se avisa al ingeniero de guardia. |
| 14:08 | El primer respondedor se conecta. Ve una tasa de error, ningún despliegue en el registro de cambios de código, y empieza a mirar la base de datos. |
| 14:14 | Un segundo ingeniero se une, revisa el registro de cambios de configuración en lugar del de código, y encuentra la entrada de las 14:02. |
| 14:16 | Causa entendida: dos nodos están validando tokens con el lector anterior. |
| 14:19 | Comienza la reversión. |
| 14:24 | Los tokens se emiten y validan correctamente en los seis nodos. La tasa de error cae a cero. |
| 14:28 | Los trabajos de aprovisionamiento en cola se drenan. Recuperación completa. |
| 15:10 | Página de estado actualizada. Cuarenta y dos minutos tarde, lo cual es su propio fallo y se aborda a continuación. |
Causa raíz
El token de sesión ganó un campo. Los escritores emitieron el nuevo formato inmediatamente; el lector en dos de los seis nodos del panel no se había reiniciado y rechazaba cualquier cosa que llevara el nuevo campo. Las peticiones se distribuyen entre los seis nodos, por lo que una sesión creada en un nodo nuevo tenía aproximadamente una probabilidad de uno contra tres de ser validada por uno antiguo en cualquier petición determinada. El resultado parecía intermitente, por lo que los primeros seis minutos de diagnóstico fueron a la base de datos en lugar de al registro de despliegue.
La causa más profunda es una regla que escribimos en 2023. Los cambios que tocan un archivo de esquema en lugar de código de aplicación se clasificaron como configuración, y la configuración se saltaba la fase canary con el argumento de que eran, cito, "solo valores". Esa regla era razonable cuando los únicos archivos de esquema eran flags de características. Nadie la revisó a medida que la definición de archivo de esquema se expandía, y este cambio se clasificó correctamente bajo una regla que silenciosamente se había vuelto incorrecta.
No fue un error del ingeniero que lo aplicó. La clasificación se siguió exactamente como estaba escrita.
Radio del impacto
- Inicios de sesión del panel: tasa de fallo del sesenta y uno por ciento durante veintiséis minutos.
- Tokens de API: misma tasa de fallo, misma ventana. Las claves de idempotencia aseguraron que los creates reintentados no se duplicaran.
- Instancias en ejecución: no afectadas. Sin pérdida de paquetes, sin reinicios, sin impacto en almacenamiento.
- Aprovisionamiento: pausado, no fallido. Cuatro pedidos se resolvieron durante la ventana y los cuatro se completaron a las 14:28.
Lo que cambiamos
- La fase canary ahora es incondicional. Cualquier despliegue, de cualquier clasificación, va a un nodo durante cinco minutos con tráfico sintético antes de ir a cualquier otro lugar. Hecho el 21 de enero.
- Los lectores aceptan el formato anterior durante treinta días. La validación de tokens ahora está explícitamente versionada con una ventana de solapamiento, por lo que un cambio parcialmente desplegado se degrada a nada en absoluto. Hecho el 23 de enero.
- Un inicio de sesión sintético se ejecuta cada quince segundos desde fuera de nuestra red, en tres regiones, y pagina en el segundo fallo consecutivo en lugar de después de una ventana de promediado de dos minutos. Hecho el 22 de enero.
- La página de estado se publica automáticamente cuando el inicio de sesión sintético falla dos veces, sin esperar a que un humano escriba una frase. Una frase humana la sigue. Hecho el 26 de enero.
Lo que no cambiamos, y por qué
Seguimos sin registrar las IPs de los clientes ni los cuerpos de las peticiones para el tráfico del panel. Haberlos tenido habría mostrado la distribución de uno contra tres entre nodos inmediatamente y probablemente habría ahorrado nueve minutos. Nueve minutos no merecen un registro permanente de desde dónde inicia sesión cada cliente. La tabla de retención en la página de registro permanece sin cambios.
No movimos las sesiones a un almacén compartido entre sitios. Un almacén de sesiones único que abarcara todos los sitios habría evitado el problema del lector mixto por completo al tener un solo lector. También crearía precisamente el registro centralizado y siempre activo de quién está conectado a qué que hemos pasado seis años sin construir.
No añadimos un canal de anuncios de incidencias fuera de la página de estado. Varias personas sugirieron redes sociales. La página de estado es lo único que operamos y de lo que podemos comprometernos a mantener su precisión, y añadir una segunda superficie significa una segunda superficie que se vuelve obsoleta.
El crédito
El SLA cubre la disponibilidad de las instancias. Las instancias estuvieron disponibles durante los veintiséis minutos, por lo que bajo el contrato no se debía nada a nadie. Aplicamos un crédito de un día a cada cuenta que tuvo una autenticación fallida en la ventana, lo que ascendió a unos tres mil cien euros, porque discutir la distinción con personas que no podían acceder a sus servidores es un peor uso de la tarde de todos.