Historial de interrupciones de Sirv

1. 6 de agosto de 2026 a las 10:17 UTCinvestigating

   Las cargas a algunas cuentas de Sirv están fallando, debido a un problema de servidor. Esto también puede evitar que las imágenes aparezcan ocasionalmente. Estamos trabajando para resolver el problema lo antes posible.

2. 6 de agosto de 2026 a las 15:22 UTCresolved

   La causa de la cuestión se identificó y ahora se ha resuelto plenamente. Durante el período, alrededor del 25% de las cuentas de Sirv podrían haber experimentado una proporción de cargas de archivos fallando. Retrying the uploads a short while later may have been successful because this was a only affecting a small number of requests. Se está realizando un examen y se proporcionará más información más adelante.

Traducido automáticamente desde la actualización oficial del incidente.

1. 27 de junio de 2026 a las 18:34 UTCmonitoring

   Un pequeño número de subidas y solicitudes están volviendo errores debido a múltiples fallas de conmutación de red en el centro de datos primario de Sirv. Las solicitudes de CDN funcionan como normales. Estamos monitoreando de cerca la situación y proporcionaremos actualizaciones a medida que se disponga de más información.

2. 27 de junio de 2026 a las 19:37 UTCresolved

   Todos los servicios vuelven a la normalidad y las solicitudes se completan.

3. 28 de junio de 2026 a las 9:03 UTCresolved

   Este problema fue causado por una falla del router central que afecta al centro de datos primario de Sirv. Esto causó interrupciones breves e intermitentes en el almacenamiento de archivos y subidas, en todos los tipos de transferencia: API, S3 y FTP. Sirv cambió automáticamente a su servicio de failover, por lo que el procesamiento de archivos y la entrega continuó como normal. Las solicitudes de la CDN también continuaron como normales. Todos los servicios fueron restaurados una vez que el centro de datos había resuelto el desvío del router central.

Traducido automáticamente desde la actualización oficial del incidente.

1. 30 de enero de 2026 a las 12:46 UTCinvestigating

   El tiempo de respuesta para algunas solicitudes en Alemania es más lento de lo normal y un pequeño número es el momento. La cuestión está siendo investigada.

2. 30 de enero de 2026 a las 14:28 UTCresolved

   La cuestión se ha resuelto. Uno de los servidores que sirven a Alemania fue sobrecargado y respondiendo más lento de lo habitual. El servidor está sano de nuevo. Estamos revisando qué acciones tomar para reducir la posibilidad de que esto suceda de nuevo.

Traducido automáticamente desde la actualización oficial del incidente.

1. 31 de marzo de 2025 a las 14:32 UTCinvestigating

   Algunas solicitudes de California son lentas y un pequeño número (bajo 2%) están fallando. Esto está siendo investigado y probablemente relacionado con nuevos servidores CDN que fueron desplegados hoy en Los Ángeles.

2. 31 de marzo de 2025 a las 15:16 UTCresolved

   La cuestión se ha resuelto. El problema fue causado por la pérdida de paquetes que afecta a nuestro nuevo centro de datos de Los Ángeles. El datacenter rastreó el problema a su proveedor de corriente, Arelion, que estaba experimentando inestabilidad de la red. La cuestión se resolvió cuando Arelion fue discapacitado temporalmente como proveedor de corriente avanzada y el tráfico fue redirigido a través de otros proveedores. Requerimos que nuestros centros de datos identifiquen y redirijan el tráfico de forma automática y rápida en tales escenarios. Sin embargo, la resolución de esta cuestión no fue lo suficientemente rápida y dado que ocurrió poco después de adoptar este nuevo centro de datos, hemos decidido dejar de utilizarla. Todo el tráfico está siendo enrutado desde nuestro centro de datos original de Los Ángeles (al 7 de abril de 2025).

Traducido automáticamente desde la actualización oficial del incidente.

1. 15 de marzo de 2025 a las 17:56 UTCresolved

   Algunas subidas de archivos no se completan debido a un problema de grupo de servidores. La causa está siendo investigada. La cuestión está afectando a un pequeño número de cuentas. Si su carga de archivo falla, por favor espere hasta que este problema haya sido resuelto.

2. 16 de marzo de 2025 a las 8:40 UTCidentified

   Esta cuestión sigue en curso. Se ha identificado la causa de la cuestión y estamos trabajando para resolverla lo antes posible.

3. 16 de marzo de 2025 a las 15:25 UTCresolved

   La cuestión se ha resuelto. El problema fue causado por dos servidores en un grupo fallando simultáneamente. Esto impactó la carga de nuevos archivos a alrededor del 20% de las cuentas Sirv. Las descargas están diseñadas para continuar como normales cuando un servidor está bajado pero cuando dos servidores están abajo, algunas subidas pueden fallar, lo que es lo que pasó. Fallaron debido a un servicio de exportador que dejó de funcionar en un servidor, luego el otro servidor. Los errores impidieron que los servicios se reiniciaran. Entonces un segundo problema causó que la resolución tomara mucho más tiempo de lo esperado porque los servidores no podían reiniciarse. Esto se debió a un BIOS anticuado. Una vez actualizado el BIOS, se reiniciaron los servidores y se resolvió la causa del problema subyacente. Para evitar que esto suceda de nuevo, hemos implementado un nuevo proceso de gestión de BIOS con nuestro centro de datos. También estamos acortando nuestro ciclo de actualización de hardware, para actualizaciones de hardware más frecuentes. Para reducir la probabilidad de que el servicio exportador no vuelva a repetirse, hemos desactivado un proceso y estamos monitoreando las métricas del servidor.

Traducido automáticamente desde la actualización oficial del incidente.

1. 26 de febrero de 2025 a las 9:29 UTCinvestigating

   Durante un período de 3 minutos entre las 09:29 y las 09:32 UTC, algunas solicitudes no fueron devueltas. Esta cuestión afecta sólo a ciertas solicitudes y sólo a ciertas cuentas. La mayoría de las cuentas no fueron afectadas.

2. 26 de febrero de 2025 a las 9:32 UTCresolved

   El problema se resolvió en un plazo de 3 minutos. La causa fue el reinicio de varios servidores al mismo tiempo, mientras que sólo 1 servidor debería haber sido reiniciado. Esto fue una supervisión en nuestros procedimientos operativos estándar. Estamos investigando formas de proteger y evitar que esto vuelva a ocurrir.

Traducido automáticamente desde la actualización oficial del incidente.

1. 19 de diciembre de 2024 a las 14:20 UTCresolved

   Una falla del servidor está causando que algunas cargas de archivos fallen por un número limitado de cuentas. La cuestión se está resolviendo. Si experimentas cargas fallidas, por favor, pausa y vuelve a intentarlo más tarde.

2. 19 de diciembre de 2024 a las 18:09 UTCresolved

   La cuestión se ha resuelto. Un número inusualmente grande de servidores falló al mismo tiempo. Sirv está diseñado para continuar el funcionamiento normal durante una salida del servidor y todos los sistemas continuaron como normales, pero algunas subidas de archivos fallaron. Estamos considerando qué posibles cambios podrían hacerse para ayudar en tales situaciones en el futuro.

Traducido automáticamente desde la actualización oficial del incidente.

1. 14 de noviembre de 2024 a las 9:52 UTCinvestigating

   Se está devolviendo un número elevado de 504 timeouts para solicitudes de carga de archivos API.

2. 14 de noviembre de 2024 a las 13:19 UTCinvestigating

   Sigue habiendo una carga pesada en la API de solicitudes de carga. Un factor que contribuye es el gran número de solicitudes de ampliación de imagen de AI, que están tomando más tiempo de lo habitual para procesar. El retraso causado por la cola de las solicitudes está causando que algunas solicitudes de carga de archivos de API fallen con una respuesta de 504.

3. 14 de noviembre de 2024 a las 15:23 UTCresolved

   Se han hecho cambios y la cuestión está casi resuelta. La mayoría de las solicitudes de carga tienen éxito.

4. 14 de noviembre de 2024 a las 19:06 UTCresolved

   La sobrecarga de carga de API está casi totalmente resuelta.

5. 15 de noviembre de 2024 a las 4:42 UTCresolved

   La cuestión se ha resuelto plenamente. El problema comenzó cuando las solicitudes de API de aumento de imágenes pesadas sobrecargaron la API de carga, causando algunas solicitudes de API para devolver errores 504. Esto se resolvió pero un efecto de golpe causó que aproximadamente el 5% de las solicitudes de API fallaran con una respuesta de 502. Para evitar que este problema vuelva a ocurrir, se han realizado mejoras para reducir la carga de aumento de imagen y distribuir mejor la carga. También se están haciendo cambios para registrar y alertar, para una identificación más rápida de tales escenarios. El mayor impacto de este problema fue en el plugin de WordPress Sirv. El plugin estaba enviando una solicitud de API en todas las páginas de administración, que bloqueó la página de carga hasta que se había recibido la respuesta - normalmente menos de 300ms pero hasta 20 segundos si las solicitudes de API se agotaron. Esas solicitudes de API no fueron necesarias, por lo que una nueva versión plugin de WordPress v7.3.3 fue lanzada en 1805 UTC (14 de noviembre) para eliminar tales solicitudes y evitar que este problema vuelva a ocurrir: https://wordpress.org/plugins/sirv/ ------ Si utiliza la API de Sirv, recomendamos que sus scripts estén escritos para reiniciar solicitudes que reciban una respuesta de 502. Las recomendaciones para la tramitación de 502 y otras respuestas sobre errores figuran aquí: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide

Traducido automáticamente desde la actualización oficial del incidente.

1. 22 de febrero de 2024 a las 10:52 UTCinvestigating

   Algunos archivos no están siendo devueltos para un pequeño número de cuentas. Esta cuestión se está abordando con urgencia.

2. 22 de febrero de 2024 a las 12:06 UTCresolved

   La cuestión se ha resuelto. At 1052 UTC, about 11% of requests to a small number of accounts (12 accounts, out of 50,000+) were returning 404 responses (file not found) when they should have returned 200 responses (OK). Cuando el equipo de Sirv identificó el problema, rápidamente trabajaron para resolverlo y para 1206 UTC todas esas solicitudes estaban devolviendo la respuesta normal de 200. El problema se debió a una malconfiguración de ingenieros Sirv mientras estaban configurando un nuevo grupo de almacenamiento duro. Algunas solicitudes iban al nuevo duro antes de que estuviera listo para recibirlas. Clasificación como nivel de gravedad 3: Impacto menor.

Traducido automáticamente desde la actualización oficial del incidente.

1. 5 de enero de 2024 a las 20:21 UTCinvestigating

   Un alto número de solicitudes a las 25 ubicaciones de Sirv CDN están devolviendo un error. Nuestros ingenieros están trabajando rápidamente para identificar y resolver el problema.

2. 5 de enero de 2024 a las 21:07 UTCresolved

   La cuestión se ha resuelto. Fue causada por el fracaso de un daemon de software simultáneamente en múltiples servidores. Este es un gestor de servicio ligero y altamente eficiente que nunca ha fallado en el pasado. Durante el período, entre el 3% y el 58% de las solicitudes de HTTPS devolvieron un error, dependiendo de cuál de las 25 ubicaciones de CDN recibieron la solicitud. Estamos investigando por qué esto sucedió y tomaremos medidas para evitar que esto impacte la disponibilidad de servicios en el futuro. Clasificación como nivel de gravedad 2: Impacto significativo.

Traducido automáticamente desde la actualización oficial del incidente.

1. 5 de diciembre de 2023 a las 15:03 UTCinvestigating

   En el CDN se produce un nivel elevado de 415 errores. Nuestros ingenieros están investigando la causa.

2. 5 de diciembre de 2023 a las 18:32 UTCinvestigating

   Seguimos investigando la causa de esta cuestión. La naturaleza es compleja. Se representa como un error 415, de archivos de bytes cero. También hay una tasa elevada aunque menor de 500 errores. La mayoría de las solicitudes tienen éxito en 200 respuestas. Nuestros ingenieros están trabajando duro para entender y resolver esto.

3. 5 de diciembre de 2023 a las 22:56 UTCresolved

   El problema de error 415 fue causado por algunos archivos truncados, lo que significa que perdieron parte de su contenido. Estos archivos muestran en el panel de control en my.sirv.com como tener 0 bytes. Los archivos subidos hoy eran más propensos a ser truncados, aunque parece que la truncación ha estado pasando a los archivos durante mucho tiempo. Esto no se identificó porque actuaron completamente como normales, debido al caché de versiones no truncadas. El problema del archivo truncado sólo se hizo notar hoy, después de una actualización de infraestructura. Los caches del servidor fueron aclarados y las versiones truncadas se hicieron evidentes. Se cree que la causa de la truncación ha sido un error de software que ya se ha resuelto. Actualmente estamos trabajando para restaurar archivos truncados - un proceso que puede tomar de horas a días. Si usted es capaz de recargar los archivos que no están cargando actualmente, por favor haga eso ahora. Se calcula que el problema está afectando alrededor del ~0,2% de los archivos.

4. 5 de diciembre de 2023 a las 23:33 UTCresolved

   Aproximadamente el 80% de los archivos truncados se han recuperado. El número de 415 errores ha disminuido significativamente, aunque siguen siendo elevados. Para resolver completamente el problema, los archivos truncados restantes deben ser reemplazados por el archivo original. Estamos trabajando en formas de recuperar los archivos restantes, aunque son difíciles de obtener y puede tardar horas o días. Para la resolución más rápida posible, se recomienda que vuelva a cargar los archivos. Tales archivos mostrarán en su cuenta como tener 0 bytes. Comience en la siguiente URL, para ver una lista de todos los archivos subidos en los últimos 30 días: https://my.sirv.com/#/search/?created=30d Encontrar cualquier archivo de byte cero clasificando los resultados por Size, Ascending. Otra actualización será publicada aquí una vez tengamos noticias sobre los archivos restantes.

5. 6 de diciembre de 2023 a las 1:48 UTCinvestigating

   Continuamos recuperando el pequeño número de archivos truncados restantes. Se calcula que ello requerirá otras 12 a 24 horas. Si usted tiene cualquier archivo que no están siendo servidos, puede resolver esto inmediatamente por recargarlos. Estamos creando una herramienta para generar una lista de archivos de byte cero. Si desea una lista de archivos de byte cero en su cuenta, envíe una solicitud en https://sirv.com/help/support/#support y prepararemos una lista una vez que la herramienta esté lista. Sin embargo, continuaremos trabajando para recuperar todos los archivos. Si subes archivos usando la función Autofetch de Sirv, simplemente puede eliminar los archivos de byte cero y se recuperarán de su ubicación remota a petición siguiente.

6. 6 de diciembre de 2023 a las 12:12 UTCresolved

   Se han restaurado más archivos. La tasa de 415 errores sigue disminuyendo. Usted puede ver una lista de 415 errores en esta página de su cuenta: https://my.sirv.com/#/analytics/errors/415?from=20231206 Puede subir archivos para resolver cualquier error de 415 en sus archivos. Podemos proporcionar una lista de archivos de byte cero si necesita - por favor pregunte al equipo de soporte Sirv a través de este formulario: https://sirv.com/help/support/#support Continuamos restaurando tantos archivos como sea posible.

7. 6 de diciembre de 2023 a las 19:47 UTCresolved

   Se ha resuelto el problema que causó la tasa elevada de 415 errores. Los archivos truncados fueron causados por un problema de software que escribió algunos archivos con cero bytes. Como era software, esto causó que los archivos truncados se replicaran en todas las versiones del archivo maestro. Sirv triplica todos los archivos para proteger contra problemas de hardware (funciones del servidor o del disco duro), sin embargo, los archivos actualizados pasaron todos los cheques y triplicaron fielmente los archivos. Existía sin detección porque las versiones en caché de los archivos se utilizaban para procesar y entregar. Todos los sistemas funcionaron perfectamente, hasta la actualización de infraestructura de ayer cuando los archivos caché fueron eliminados. La causa raíz se solucionó identificando y corrigiendo el problema del software que causó la truncación. Esto se completó en 1500 UTC el 5 de diciembre. Entonces la tarea era restaurar los archivos que habían sido truncados. En toda la plataforma, aproximadamente el 0,2% de los archivos habían sido afectados. De esos archivos, pudimos restaurar entre 95% y 100%, dependiendo de la cuenta. Cualquier cuenta que tuviera menos del 100% de restauración está siendo enviado una lista de archivos de cero bytes que deben ser restaurados subiendo los archivos de nuevo. Por favor, busque nuestro correo electrónico con una lista de archivos. Por favor envíenos un mensaje a través de la siguiente URL si necesita ayuda: https://sirv.com/help/support/#support Se está llevando a cabo una investigación exhaustiva de la cuestión, que se informará detalladamente por correo electrónico. En el informe se incluirá una lista de medidas que se están adoptando para evitar cualquier posible repetición de esta cuestión, junto con mejoras y nuevas características que ya se están diseñando. Nos disculpamos a todos los clientes que fueron afectados por este problema. Es la primera vez que se han perdido datos maestros. Aprenderemos cada lección posible y haremos que Sirv sea aún más fuerte y confiable que antes.

8. 21 de diciembre de 2023 a las 10:05 UTCresolved

   Más del 99% de los archivos truncados restantes también han sido restaurados. Cualquier usuario afectado ha sido proporcionado con una lista exacta de archivos que fueron impactados. No queda ningún efecto residual de esta cuestión. Clasificación como nivel de gravedad 1: Impacto crítico.

Traducido automáticamente desde la actualización oficial del incidente.

1. 2 de diciembre de 2023 a las 4:19 UTCinvestigating

   Desde 0419 UTC, un nivel elevado de 429 errores fueron devueltos desde la ubicación de Sydney CDN.

2. 2 de diciembre de 2023 a las 10:31 UTCresolved

   La cuestión se resolvió en 1031 UTC. La causa fue una errorconfiguración del servidor que hizo que la ubicación de Sydney CDN vea todas las solicitudes provenientes de la misma dirección IP, en lugar de la dirección IP del verdadero cliente. Esto provocó la protección de DDOS, para limitar el número excesivo de solicitudes de la misma IP. Se devolvieron 429 respuestas para muchas de las solicitudes. El tema parece haber sido un problema extremadamente corto cuando la red de centro de datos de Sydney no se pudo encontrar. Esa cuestión duró aproximadamente 1 minuto. Sin embargo, el incidente real comenzó inmediatamente después de que nuestro equipo hubiera restaurado la ubicación del CDN de Sydney, que es cuando se aplicó la configuración errónea del servidor. El tema fue resuelto una vez que descubrimos la desconfiguración errónea y lo corrigimos. Se están adoptando múltiples medidas para evitar que esta cuestión vuelva a repetirse y reducir el impacto de cuestiones similares pero diferentes en el futuro: - Supervisión y alerta adicionales - Formulario de presentación de nuevas cuestiones - Consejos de resolución sensibles al contexto - Más alerta interna Sólo la ubicación de Sydney CDN fue afectada. Clasificación como nivel de gravedad 3: Impacto menor.

Traducido automáticamente desde la actualización oficial del incidente.

1. 22 de noviembre de 2023 a las 18:30 UTCinvestigating

   Aproximadamente 1830 UTC el 22 de noviembre, comenzamos una actualización a la base de datos de archivos primarios a un nuevo grupo más poderoso. Mientras que la actualización tuvo lugar, las consultas de búsqueda de API estaban fallando.

2. 23 de noviembre de 2023 a las 10:35 UTCresolved

   At 1035 UTC on 23 November, the upgrade was complete and searches continued operation. No hubo tiempo de inactividad y todos los sistemas funcionaban como normales, excepto que las solicitudes de búsqueda de API habían estado devolviendo respuestas de error. El problema no se identificó porque otras solicitudes de API estaban regresando como normales, por lo que las respuestas totales de error de API sólo fueron ligeramente elevadas y no se activaron alertas. The issue was identified after the event, after a report by a user prompted an investigation. Para identificar automáticamente estos problemas en el futuro, estamos evaluando maneras de monitorear la API de búsqueda específicamente. También estaremos actualizando el plugin Sirv WordPress para mostrar un mensaje claramente descrito en caso de una búsqueda fallida. Clasificación como nivel de gravedad 4: Impacto mínimo.

Traducido automáticamente desde la actualización oficial del incidente.

1. 13 de noviembre de 2023 a las 20:47 UTCinvestigating

   Las herramientas de gestión de archivos en my.sirv.com están cargando lentamente debido a un servidor fallido. La lista de archivos y la búsqueda de archivos está tomando de 2 a 20 segundos, mientras que normalmente tarda 1 a 4 segundos. El servidor fallido está siendo reemplazado y esperamos que la velocidad vuelva a la normalidad dentro de 72 horas. Esto será seguido por una mejora importante de todo el grupo de servidores de panel de control durante los próximos 3 meses.

2. 14 de noviembre de 2023 a las 21:33 UTCinvestigating

   Estamos esperando la provisión de un nuevo servidor para añadir al clúster, entonces la velocidad de navegación de la UI se volverá mucho más rápida.

3. 15 de noviembre de 2023 a las 14:09 UTCresolved

   El nuevo servidor fue desplegado en la noche del 14 de noviembre y llenó gradualmente sus caches. El panel de control ha vuelto a su rendimiento rápido original. Los servidores adicionales están siendo actualizados, por lo que el panel de control se cargará más rápido aún durante las próximas 2 semanas. Clasificación como nivel de gravedad 4: Impacto mínimo.

Traducido automáticamente desde la actualización oficial del incidente.

1. 23 de octubre de 2023 a las 13:10 UTCinvestigating

   El 23 de octubre se produjo un aumento drástico de las solicitudes a la sede de Washington D.C. CDN a las 14:10 UTC, lo que causó que una pequeña proporción de solicitudes se devolvieran lentamente - más de 2 segundos. El problema se redujo en las próximas 3 horas, aunque el tiempo medio de respuesta se mantuvo elevado. La cuestión volvió al día siguiente a las 14: 32 UTC el 24 de octubre, más severamente que antes de que el 17% de las solicitudes se cargaran lentamente - más de 2 segundos y algunas hasta 30 segundos. El problema impactó a dos de los 25 CDN de Sirv.

2. 25 de octubre de 2023 a las 5:48 UTCresolved

   El tema fue resuelto por 06:48 UTC el 25 de octubre. Puntos de investigación hacia dos causas - el pico fue causado por el proveedor del DNS de Sirv que encargó las solicitudes de POP de Los Ángeles a la COP de Washington D.C. en su lugar. Esto habría estado bien en aislamiento, pero el centro de datos parece haber acelerado el ancho de banda de los servidores receptores, causando las respuestas lentas. La investigación está en curso, todavía no ha llegado a conclusiones definitivas y requiere colaboración con nuestros proveedores de DNS y datacentre. Ya se están adoptando medidas para evitar cualquier posible repetición de esta cuestión. Más adelante se presentará un informe detallado.

3. 14 de noviembre de 2023 a las 13:37 UTCresolved

   La investigación detallada de esta cuestión encontró dos factores que contribuyeron. La primera fue una actualización de AWS Route53, que parece haber sido implementada por AWS el 17 de octubre. Este cambio no fue hecho por Sirv a sus reglas Route53 sino un cambio dentro del servicio Route53. La POP de Los Ángeles tenía una lógica de enrutamiento ligeramente diferente a otras POPs y la actualización de AWS causó que el enrutamiento se comportase de manera diferente, con el tráfico que se encaminó hacia el retroceso de Washington DC. Esto pasó desapercibido ya que la carga más alta todavía estaba dentro de su capacidad y las solicitudes fueron devueltas con éxito, por lo que esto pasó desapercibido ya que Washington DC fue capaz de manejar la carga adicional. El segundo factor contribuyente fue más alto que el tráfico normal durante las horas máximas de comercio de los Estados Unidos los días 23 y 24 de octubre. Los dos factores combinados causaron que los discos duros de Washington DC devolvieran solicitudes considerablemente más lentas de lo normal. Desde que se produjo la cuestión, hemos adoptado múltiples medidas para evitar que se repita; mitigar los incidentes similares posibles; y acelerar el tiempo de resolución en caso de incidente. Las acciones incluyen: - Nueva lógica de enrutamiento se ha aplicado. - La capacidad de Washington DC ha aumentado. - Se ha aumentado la capacidad de reserva en todos los demás lugares del CDN. - Nueva tolerancia introducida para que un CDN se elimine del enrutamiento. - Monitoreo adicional de disco, para ayudar a la preparación temprana de mejoras de capacidad. - Los HDD están siendo reemplazados por SSD. - Actualizado SOP para nuestro equipo de apoyo para investigar y responder a problemas similares. Clasificación como nivel de gravedad 3: Impacto menor.

Traducido automáticamente desde la actualización oficial del incidente.

1. 22 de mayo de 2023 a las 14:57 UTCinvestigating

   El número anterior de uso de alta carga volvió, con un pequeño número de fallos de carga de API.

2. 22 de mayo de 2023 a las 15:06 UTCresolved

   El problema se resolvió en 9 minutos una vez que se normalizó el volumen de carga. Durante el período, aproximadamente el 98% de las cargas tuvieron éxito y el 2% falló. Las subidas REST API son limitadas por hora, a la cantidad especificada en la página de Uso de su cuenta Sirv https://my.sirv.com/#/account/usage. Si utilizas la API de REST para subir imágenes, la mejor práctica es comprobar la respuesta para cada solicitud de subida y si recibes una respuesta de error (400, 401, 429 etc.) luego pausas cargas y reingresa más adelante. Consulte los documentos aquí: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide Clasificación como nivel de gravedad 4: Impacto mínimo.

Traducido automáticamente desde la actualización oficial del incidente.

1. 22 de mayo de 2023 a las 11:31 UTCinvestigating

   Un pequeño número de solicitudes de carga REST API están fallando debido a una carga muy alta.

2. 22 de mayo de 2023 a las 12:37 UTCresolved

   Este problema se resolvió una vez que la carga en la API de carga comenzó a caer. Durante el período, aproximadamente el 97% de las cargas tuvieron éxito y el 3% falló. Las subidas REST API son limitadas por hora, a la cantidad especificada en la página de Uso de su cuenta Sirv https://my.sirv.com/#/account/usage. Si utilizas la API de REST para subir imágenes, la mejor práctica es comprobar la respuesta para cada solicitud de subida y si recibes una respuesta de error (400, 401, 429 etc.) luego pausas cargas y reingresa más adelante. Consulte los documentos aquí: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide Clasificación como nivel de gravedad 4: Impacto mínimo.

Traducido automáticamente desde la actualización oficial del incidente.

1. 27 de abril de 2023 a las 23:00 UTCinvestigating

   Uno de los servidores CDN de Los Ángeles se volvió poco saludable y comenzó a devolver errores de 4xx en 0000 UTC. Se eliminó de la routa después de 90 segundos y dentro de otros 60 segundos, todo el tráfico estaba siendo enrutado a servidores saludables.

2. 27 de abril de 2023 a las 23:03 UTCresolved

   El problema se resolvió automáticamente dentro de 3 minutos. Clasificación como nivel de gravedad 4: Impacto mínimo.

Traducido automáticamente desde la actualización oficial del incidente.

1. 16 de marzo de 2023 a las 12:17 UTCinvestigating

   Algunas solicitudes al POP de Londres de Sirv CDN, están devolviendo errores debido a una gran carga. Esta COP sirve a Reino Unido e Irlanda. Estamos trabajando en una resolución.

2. 16 de marzo de 2023 a las 13:33 UTCresolved

   La cuestión se ha resuelto y se está vigilando.

3. 16 de marzo de 2023 a las 16:22 UTCresolved

   Algunas solicitudes recibidas por uno de los servidores del CDN de Londres fracasaron debido a una combinación de resolución local del DNS y a un tiempo de red pulsante. La cuestión comenzó en 1215 UTC y se resolvió en 1332 UTC. Durante este período, el 25% de las solicitudes de Reino Unido e Irlanda devolvieron un error de 404 o 500. El problema habría sido resuelto antes pero un fallo de validación de certificado SSL no relacionado unas horas antes bloqueó las alertas de ser recibidas por nuestro sistema de monitoreo. Ya se han desplegado cambios para evitar que se repita esta cuestión. Se ha resuelto el número de certificados SSL; se ha configurado un segundo nivel de vigilancia independiente; se está procesando una automatización de salud adicional que tiene el potencial de resolver esos problemas automáticamente. Clasificación como nivel de gravedad 3: Impacto menor.

Traducido automáticamente desde la actualización oficial del incidente.

1. 23 de febrero de 2023 a las 7:55 UTCresolved

   El problema se resolvió a las 0755 UTC. At 0625 UTC, some requests to the Indore CDN POP which serve India started to return a 404 response (file not found), instead of a 200 response (OK). El problema ocurrió 14 horas después de una actualización a todos los servidores CDN en todo el mundo. Todos los COP se comportaron saludablemente, incluyendo la COP India, pero la COP Indore no había actualizado con éxito y finalmente comenzó a devolver errores. Una vez identificada la cuestión, se resolvió mediante la redistribución de la actualización a la COP de la India. Durante el incidente, el 94% de las solicitudes devolvieron un error. Las solicitudes a todos los demás países se devolvieron como normales. Para evitar que esta cuestión vuelva a repetirse, se está creando una nueva norma de despliegue automatizada para una parte del proceso de despliegue en la que sólo se había registrado un control humano. También se está creando una métrica de alerta adicional para identificar una situación en la que ha fracasado el despliegue. Nos disculpamos a todos los clientes que fueron afectados por este incidente y estamos evaluando otros cambios que pueden ayudar a prevenir cualquier posible repetición del problema. Si un problema de CDN como este ocurre, una solución inmediata dentro de su control es desactivar el CDN temporalmente en su configuración de Sirv aquí: https://my.sirv.com/#/account/settings/domains Clasificación como nivel de gravedad 2: Impacto significativo.

Traducido automáticamente desde la actualización oficial del incidente.