6 historias aterradoras de caídas de servicio

1. Charity Majors, CTO de Honeycomb

• Las notificaciones push no llegaban a los usuarios de una región específica (Europa del Este)

• Empezó a ocurrir justo después de cambiar el tamaño del ASG

• Ocurrió porque el registro DNS Round Robin superó el tamaño del paquete UDP

2. Matthew Fornaciari, CTO de Gremlin

• Se produjo una caída porque el disco se llenó y no se pudieron escribir logs

• Se desarrolló una función de rotación de logs

• Se configuró una alerta de uso de disco

• Se agregó para poder probarlo a través de Gremlin (ingeniería del caos)

3. Lirran Haimovitch, CTO de Rookout

"La leyenda urbana de que el servidor se cae todos los días a cierta hora,

tras varias semanas de investigación, se descubrió la causa en una cámara de seguridad,

el personal de limpieza desconectaba el servidor para enchufar la aspiradora"

4. Daniel "Spoons" Spoonhower, CTO de Lightstep

• La app no cargaba

• Ese día no hubo despliegue ni cambios de infraestructura

• Se confirmó que solo les ocurría a los usuarios internos

• Al revisar la API de carga de la app, se encontró que en el caso de los usuarios internos se devolvían datos adicionales

• Durante las semanas anteriores el payload había ido creciendo lentamente, y esa tarde superó el tamaño máximo permitido del payload, haciendo que la app no cargara

5. Lee liu, CTO de LogDNA

6. Ting Huang, CTO de Transpoit

• No se podía leer en Twitter móvil

• Se descubrió un problema en el que una nueva librería no podía parsear la cookie de sesión

[kunggom]

Parece que, en los 5 casos cuyo contenido no fue resumido, se trató de vencimientos de certificados.

Pensaron que no habría problema aunque los certificados expiraran según lo previsto, pero eso solo aplicaba a los sistemas nuevos; en los sistemas heredados que seguían en uso sí se produjeron problemas. Para colmo, el mismo problema también ocurrió en la solución de CI/CD que usaban, así que todo se volvió más complicado.

[kbumsik]

"El personal de limpieza desconectó la conexión del servidor para enchufar la aspiradora"

Ay, no...

[kunggom]

Leyendo el original, parece que ese contenido era solo para abrir el tema, y que la falla real fue que una consulta que el administrador del cliente usaba a veces durante reuniones terminó bloqueando toda la tabla, así que cada vez que pasaba eso la latencia del servicio backend aumentaba sin límite. Optimizaron una consulta sospechosa, pero era una pista falsa, así que el mismo fenómeno seguía ocurriendo cada vez que el cliente decía que la página estaba demasiado lenta y la recargaba repetidamente.

[kunggom]

Una experiencia personal más, si se parece en algo. Fue cuando tomé con urgencia un trabajo relacionado con una tienda en línea que entró de repente como freelance.

De madrugada se realizó un trabajo grande en la tienda en línea (una actualización importante de versión de la solución) y, después de confirmar que no había problemas en funciones clave como el pago de productos, se reabrió el sitio. Pero ya por la tarde, de repente, el sitio web de la tienda empezó a ponerse demasiado lento y al final estuvo a punto de quedar casi paralizado. Resultó que la causa era una página para vendedores que estaba conectada por separado a la tienda. Estaban operando la solución de la tienda con una página de administración para vendedores desarrollada de forma personalizada, y al entrar ahí se ejecutaba una consulta muy pesada. Después de la reapertura de la tienda, cada vez que los vendedores individuales entraban para ver el estado de sus ventas, la carga sobre MySQL aumentaba y al final eso fue lo que volvió lenta a la propia tienda. Al revisar, vi que por alguna razón las tablas relacionadas no tenían los índices aplicados correctamente. Al final, se pudo resolver la lentitud de la tienda misma aplicando bien los índices y ajustando algunos parámetros.

[kbumsik]

Oh, gracias por compartir la experiencia.

Claro, como para la administración o para los datos usados en la toma de decisiones de negocio se usan agregaciones, supongo que eso debe generar bastante carga. No soy desarrollador web, así que no lo sé bien, pero parece que hoy en día a eso le llaman ingeniería de datos y juntan los datos por separado.

[kunggom]

Como mencionaste, lo correcto habría sido separar y procesar esos datos por aparte, pero la tienda en línea en la que trabajé era un sistema legacy con bastantes cosas poco razonables, así que no había ninguna consideración de arquitectura de ese tipo. Una versión muy antigua de MySQL —de la época en que el motor predeterminado no era InnoDB sino MyISAM— corría dentro de la misma instancia de VM junto con una versión igualmente antigua del servidor web Apache. La solución para operar la tienda también ya estaba catalogada como legacy y se encontraba en una situación en la que solo seguía recibiendo parches. Por lo que sentí mientras trabajaba, parece que los problemas estructurales de la solución sí se resolvieron en una nueva versión desarrollada desde cero, pero para mí, que estaba metiendo mano a la versión legacy, eso no tuvo ningún efecto. Y pensar que eso ya fue el año pasado.