Por qué se cayó medio Internet esta semana: La explicación oficial
Alguien tocó donde no debía, en resumen. Fastly presume que descubrió el error en 1 minuto, pero le llevó 1 hora arreglarlo.
![Por qué se cayó medio Internet esta semana: La explicación oficial](https://img.asmedia.epimg.net/resizer/v2/ZVTMQFWMVNJFVJXPIJ7HWOFLLM.jpg?auth=079b0cf391d165f82c7ce7061df02956e849b5be611c96e4cfaa1a432edcc553&width=360&height=203&smart=true)
A las 12 del mediodía de ayer estallaba el caos: Una caída global y generalizada de millones de páginas web, servicios y plataformas online disparaba el pánico. Parecía lo que experimentamos hace unos años con Wannacry, el malware que hackeó el mundo entero y tumbó instituciones, hospitales, bancos, etc. Pero lo sucedido no fue catalogado como un ciberataque, sino como un fallo. Un fallo provocado por una red de servidores.
Error de Fastly
Fastly es un CDN (Content Delivery Network), un proveedor estadounidense de servicios de computación en la nube. Un CDN o red de entrega de contenido está formada por un grupo de servidores distribuidos geográficamente que trabajan juntos para ofrecer una entrega rápida de contenido de Internet.
Y su papel es evitar que cosas como hoy sucedan, ya que se encargan de replicar las páginas web o algunos servicios de los clientes que contratan sus servicios, haciendo esto en varios servidores en distintos puntos del mundo. Pero como vimos, algo salió y el resultado fue una caída histórica generalizada de 60 minutos de medio Internet en el mundo -hablamos de millones de páginas web caídas.
La explicación oficial de Fastly
Pero, ¿por qué sucedió esto? ¿Qué hicieron en Fastly para liarla verdaderamente parda a nivel global? Pues la compañía ha publicado las causas oficiales, y se resumen en lo esperado: Alguien tocó donde debía, pero sin querer lo hizo saltar todo.
Según la explicación oficial, nos remontamos al pasado 12 de mayo, momento en que en Fastly iniciaron “un despliegue de software que introdujo un error que podía ser activado por una configuración específica del cliente en circunstancias concretas”.
Saltamos adelante a ayer, 8 de junio: En las primeras horas del día, “un cliente introdujo un cambio de configuración válido que incluía las circunstancias específicas que desencadenaban el fallo, lo que hizo que el 85% de nuestra red devolviera errores”. La cronología de los hechos es la siguiente, con todas las horas en UTC (en hora española habría que sumarle 2, de tal manera que las 09:47 am UTC serían las 11:47 am en España):
- 09:47 am: Inicio de la interrupción global
- 09:48 am: Interrupción global identificada por la monitorización de Fastly
- 09:58 am: Se publica un mensaje de estado
- 10:27 am: El departamento de ingeniería de Fastly identifica la configuración del cliente
- 10:36 am: Los servicios afectados comienzan a recuperarse
- 11:00 am: La mayoría de los servicios se han recuperado
- 12:35 pm: Incidente mitigado
- 12:44 pm: Publicación del estado resuelto
- 17:25 pm: Comienza el despliegue de la corrección de errores
1 minuto en detectarlo, 1 hora en arreglarlo
Una vez mitigados los efectos inmediatos, “nos dedicamos a corregir el fallo y a comunicarnos con nuestros clientes. Creamos una solución permanente para el fallo y comenzamos a desplegarla a las 17:25”. Lo curioso según la cronología es que el equipo de Fastly detectó el error en tan sólo 60 segundos, pero la mayoría de los millones de webs afectadas estuvieron con errores o directamente ‘down’ por espacio de unos 60 minutos.
Fastly llevará a cabo también una investigación completa sobre las prácticas que llevó a cabo durante el incidente, así como para determinar por qué no detectó en sus procesos de revisión el error que ocasionó la caída global. También evaluará formas de mejorar su tiempo de solución de problemas.