Histórico de interrupções do Sirv

1. 6 Eost 2026 da 10:17 UTCinvestigating

   Os envios para algumas contas Sirv estão falhando, devido a um problema de servidor. Isto também pode impedir que as imagens mostrem ocasionalmente. Estamos a trabalhar para resolver esta questão o mais rapidamente possível.

2. 6 Eost 2026 da 15:22 UTCresolved

   A causa da questão foi identificada e está agora totalmente resolvida. Durante o período, cerca de 25% das contas Sirv podem ter experimentado uma proporção de uploads de arquivos falhando. Repetir os uploads um pouco mais tarde pode ter sido um sucesso, porque isso só afetou um pequeno número de pedidos. Está agora em curso uma revisão e mais informações serão fornecidas aqui mais tarde.

Traduzido automaticamente da atualização oficial do incidente.

1. 27 Mezheven 2026 da 18:34 UTCmonitoring

   Um pequeno número de uploads e solicitações estão retornando erros devido a várias falhas de switch de rede no datacenter primário do Sirv. Os pedidos de CDN estão a funcionar normalmente. Estamos acompanhando de perto a situação e forneceremos atualizações à medida que mais informações ficam disponíveis.

2. 27 Mezheven 2026 da 19:37 UTCresolved

   Todos os serviços estão de volta ao normal e as solicitações estão completando.

3. 28 Mezheven 2026 da 09:03 UTCresolved

   Esta questão foi causada por uma falha de roteador central que afeta o centro de dados principal do Sirv. Isso causou interrupções breves e intermitentes no armazenamento de arquivos e uploads, em todos os tipos de transferência: API, S3 e FTP. O Sirv mudou automaticamente para o seu serviço de failover, então o processamento e entrega de arquivos continuaram como normal. Os pedidos de CDN também continuaram como normais. Todos os serviços foram restaurados uma vez que o datacenter tinha resolvido o roteador principal parada.

Traduzido automaticamente da atualização oficial do incidente.

1. 30 Genver 2026 da 12:46 UTCinvestigating

   O tempo de resposta para algumas solicitações na Alemanha é mais lento do que o normal e um pequeno número é cronometrado. A questão está a ser investigada.

2. 30 Genver 2026 da 14:28 UTCresolved

   A questão foi resolvida. Um dos servidores que servem a Alemanha foi sobrecarregado e respondeu mais devagar do que o habitual. O servidor está novamente saudável. Estamos a rever as medidas a tomar para reduzir as hipóteses de que isto volte a acontecer.

Traduzido automaticamente da atualização oficial do incidente.

1. 31 Meurzh 2025 da 14:32 UTCinvestigating

   Alguns pedidos da Califórnia são lentos e um pequeno número (menos de 2%) estão falhando. Isso está sendo investigado e provavelmente relacionado com novos servidores CDN que foram implantados hoje em Los Angeles.

2. 31 Meurzh 2025 da 15:16 UTCresolved

   A questão foi resolvida. O problema foi causado pela perda de pacotes que afectou o nosso novo centro de dados de Los Angeles. O datacenter rastreou o problema para seu provedor upstream, Arelion, que estava experimentando instabilidade de rede. O problema foi resolvido quando Arelion foi temporariamente desactivado como provedor a montante e o tráfego foi redirecionado através de outros provedores. Exigimos que nossos datacenters identifiquem e redirecionem o tráfego automaticamente e rapidamente em tais cenários. No entanto, a resolução desta questão não foi suficientemente rápida e, dado que ocorreu logo após a adoção desse novo datacenter, decidimos deixar de usá-lo. Todo o tráfego está agora sendo encaminhado do nosso datacenter original de Los Angeles (a partir de 7 de abril de 2025).

Traduzido automaticamente da atualização oficial do incidente.

1. 15 Meurzh 2025 da 17:56 UTCresolved

   Alguns uploads de arquivos não estão completando devido a um problema de cluster de servidor. A causa está a ser investigada. A questão está a afectar um pequeno número de contas. Se o upload do seu arquivo falhar, aguarde até que este problema seja resolvido.

2. 16 Meurzh 2025 da 08:40 UTCidentified

   Esta questão continua em curso. A causa da questão foi identificada e estamos a trabalhar para a resolver o mais rapidamente possível.

3. 16 Meurzh 2025 da 15:25 UTCresolved

   A questão foi resolvida. O problema foi causado por dois servidores em um cluster falhando simultaneamente. Isso afetou o upload de novos arquivos para cerca de 20% das contas Sirv. Os envios são projetados para continuar como normal quando um servidor está para baixo, mas quando dois servidores estão para baixo, alguns uploads podem falhar, que é o que aconteceu. Eles falharam devido a um serviço de exportador que parou de correr em um servidor, em seguida, o outro servidor. Erros impediram que os serviços reiniciassem. Então um segundo problema fez com que a resolução levasse muito mais tempo do que o esperado porque os servidores não puderam ser reiniciados. Isso foi devido a uma BIOS ultrapassada. Uma vez atualizado o BIOS, os servidores foram reiniciados e a causa do problema subjacente foi resolvida. Para evitar que isso aconteça novamente, implementamos um novo processo de gerenciamento da BIOS com nosso datacenter. Também estamos encurtando nosso ciclo de atualização de hardware, para atualizações de hardware mais frequentes. Para reduzir a chance de falha do serviço exportador de recorrente, desabilitamos um processo e estamos monitorando as métricas do servidor.

Traduzido automaticamente da atualização oficial do incidente.

1. 26 Cʼhwevrer 2025 da 09:29 UTCinvestigating

   Por um período de 3 minutos entre 09:29 e 09:32 UTC, alguns pedidos não foram devolvidos. Esta questão afectava apenas determinados pedidos e apenas determinadas contas. A maioria dos relatos não foram afetados.

2. 26 Cʼhwevrer 2025 da 09:32 UTCresolved

   A questão foi resolvida em 3 minutos. A causa foi a reinicialização de vários servidores ao mesmo tempo, enquanto apenas 1 servidor deveria ter sido reiniciado. Isto foi um descuido nos nossos procedimentos operacionais padrão. Estamos a investigar formas de proteger automaticamente e impedir que isso se repita.

Traduzido automaticamente da atualização oficial do incidente.

1. 19 Kerzu 2024 da 14:20 UTCresolved

   Uma falha no servidor está fazendo com que alguns uploads de arquivos falhem para um número limitado de contas. A questão está a ser resolvida. Se você experimentar uploads falhados, por favor pause e tente novamente mais tarde.

2. 19 Kerzu 2024 da 18:09 UTCresolved

   A questão foi resolvida. Um número invulgarmente grande de servidores falhou ao mesmo tempo. O Sirv foi projetado para continuar a operação normal durante uma falha no servidor e todos os sistemas continuaram como normal, mas alguns uploads de arquivos falharam. Estamos a considerar as possíveis mudanças que poderão ser feitas para ajudar em tais situações no futuro.

Traduzido automaticamente da atualização oficial do incidente.

1. 14 Du 2024 da 09:52 UTCinvestigating

   Um número elevado de 504 timeouts estão sendo devolvidos para pedidos de upload de arquivos API.

2. 14 Du 2024 da 13:19 UTCinvestigating

   Continua a haver carga pesada na API a partir de pedidos de upload. Um fator contribuinte é o grande número de pedidos de upscaling de imagens de IA, que estão levando mais tempo do que o habitual para processar. O atraso causado pela fila de requisições está fazendo com que alguns pedidos de upload de arquivos API falhem com uma resposta 504.

3. 14 Du 2024 da 15:23 UTCresolved

   Foram feitas alterações e a questão está quase resolvida. A maioria dos pedidos de upload são bem sucedidos.

4. 14 Du 2024 da 19:06 UTCresolved

   A sobrecarga de upload da API está quase totalmente resolvida.

5. 15 Du 2024 da 04:42 UTCresolved

   A questão foi totalmente resolvida. O problema começou quando pedidos pesados de atualização de imagem API sobrecarregaram a API de upload, fazendo com que alguns pedidos de API retornassem erros 504. Isso foi resolvido, mas um efeito knock-on causou aproximadamente 5% das solicitações de API para falhar com uma resposta 502. Para evitar que esse problema aconteça novamente, foram feitas melhorias para reduzir a carga de upscaling de imagem e melhor distribuir carga. Também estão sendo feitas mudanças no registro e alerta, para identificação mais rápida de tais cenários. O maior impacto desta questão foi no plugin Sirv WordPress. O plugin estava enviando uma solicitação de API em todas as páginas de administração, que bloqueou o carregamento da página até que a resposta tivesse sido recebida - tipicamente menos de 300ms, mas até 20 segundos se as solicitações de API cronometrassem. Esses pedidos de API não foram necessários, então uma nova versão do plugin WordPress v7.3.3 foi lançado em 1805 UTC (14 de novembro) para remover tais pedidos e evitar que este problema de recorrente: https://wordpress.org/plugins/sirv/ ------ Se você usar a API Sirv, recomendamos que seus scripts sejam escritos novamente para tentar solicitações que recebam uma resposta 502. Recomendações para lidar com 502 e outras respostas de erro são fornecidas aqui: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide

Traduzido automaticamente da atualização oficial do incidente.

1. 22 Cʼhwevrer 2024 da 10:52 UTCinvestigating

   Alguns arquivos não estão sendo devolvidos para um pequeno número de contas. Esta questão está a ser abordada com urgência.

2. 22 Cʼhwevrer 2024 da 12:06 UTCresolved

   A questão foi resolvida. Em 1052 UTC, cerca de 11% dos pedidos para um pequeno número de contas (12 contas, de 50.000+) estavam retornando 404 respostas (ficheiro não encontrado) quando deveriam ter retornado 200 respostas (OK). Quando a equipe do Sirv identificou o problema, eles rapidamente trabalharam para resolvê-lo e até 1206 UTC todos esses pedidos estavam retornando a resposta normal de 200. O problema ocorreu devido a uma má configuração por engenheiros Sirv enquanto eles estavam configurando um novo fragmento de cluster de armazenamento. Alguns pedidos estavam indo para o novo fragmento antes que estivesse pronto para recebê-los. Classificado como nível de gravidade 3: Impacto menor.

Traduzido automaticamente da atualização oficial do incidente.

1. 5 Genver 2024 da 20:21 UTCinvestigating

   Um grande número de pedidos para 25 locais CDN do Sirv estão retornando um erro. Nossos engenheiros estão trabalhando rapidamente para identificar e resolver o problema.

2. 5 Genver 2024 da 21:07 UTCresolved

   A questão foi resolvida. Foi causado pela falha de um servidor de software simultaneamente em vários servidores. Este é um gestor de serviços leve e altamente eficiente que nunca falhou no passado. Durante o período, entre 3% e 58% das solicitações HTTPS retornaram um erro, dependendo de qual dos 25 locais de CDN recebeu o pedido. Estamos agora a investigar por que é que isto aconteceu e vamos tomar medidas para evitar que isso tenha impacto na disponibilidade de serviços no futuro. Classificado como nível de gravidade 2: Impacto significativo.

Traduzido automaticamente da atualização oficial do incidente.

1. 5 Kerzu 2023 da 15:03 UTCinvestigating

   Um nível elevado de 415 erros está ocorrendo no CDN. Os nossos engenheiros estão a investigar a causa.

2. 5 Kerzu 2023 da 18:32 UTCinvestigating

   Continuamos a investigar a causa desta questão. A natureza dela é complexa. Representa-se como um erro de 415, a partir de arquivos de zero bytes. Há também uma taxa elevada embora mais baixa de 500 erros. A maioria dos pedidos são de 200 respostas bem sucedidas. Nossos engenheiros estão trabalhando duro para entender e resolver isso.

3. 5 Kerzu 2023 da 22:56 UTCresolved

   A questão do erro 415 foi causada por alguns arquivos se truncando, o que significa que eles perderam parte de seu conteúdo. Estes arquivos mostram no painel de controle no my.sirv.com como tendo 0 bytes. Os arquivos enviados hoje eram mais propensos a se truncarem, embora pareça que o truncamento vem acontecendo com arquivos há muito tempo. Isso não foi identificado por se apresentarem inteiramente como normais, devido ao cache de versões não truncadas. O problema truncado do arquivo só se tornou perceptível hoje, após uma atualização da infraestrutura. Os caches do servidor foram limpos e as versões truncadas ficaram aparentes. Acredita-se que a causa do truncamento tenha sido um bug de software que agora foi resolvido. Estamos atualmente trabalhando para restaurar arquivos truncados - um processo que pode levar de horas a dias. Se você é capaz de recarregar quaisquer arquivos que não estão atualmente carregando, por favor, faça isso agora. Estima-se que o problema esteja afetando cerca de ~0.2% dos arquivos.

4. 5 Kerzu 2023 da 23:33 UTCresolved

   Aproximadamente 80% dos arquivos truncados foram recuperados. O número de 415 erros diminuiu significativamente, embora permaneçam elevados. Para resolver totalmente o problema, os arquivos truncados restantes precisam ser substituídos pelo arquivo original. Estamos trabalhando em maneiras de recuperar os arquivos restantes, embora eles são difíceis de obter e pode levar horas ou dias. Para a resolução mais rápida possível, é recomendável que você re-upload os arquivos. Tais arquivos mostrarão em sua conta como tendo 0 bytes. Comece pela seguinte URL, para ver uma lista de todos os arquivos enviados nos últimos 30 dias: https://my.sirv.com/#/search/?created=30d Encontre quaisquer arquivos de bytes zero, ordenando os resultados por Tamanho, Ascendendo. Outra atualização será postada aqui assim que tivermos notícias sobre os arquivos restantes.

5. 6 Kerzu 2023 da 01:48 UTCinvestigating

   Continuamos a recuperar o pequeno número de arquivos truncados restantes. Estima-se que isso exija mais 12-24 horas. Se você tem quaisquer arquivos que não estão sendo servidos, você pode resolver isso imediatamente, recarregando-os. Estamos criando uma ferramenta para gerar uma lista de arquivos de bytes zero. Se você quiser uma lista de quaisquer arquivos de byte zero em sua conta, por favor envie uma solicitação em https://sirv.com/help/support/#support e prepararemos uma lista quando a ferramenta estiver pronta. Independentemente disso, vamos continuar o trabalho para recuperar todos os arquivos. Se você carregar arquivos usando o recurso de Autofetch do Sirv, você pode simplesmente excluir os arquivos de bytes zero e eles serão re-fetchados do seu local remoto na próxima solicitação.

6. 6 Kerzu 2023 da 12:12 UTCresolved

   Mais arquivos foram restaurados. A taxa de 415 erros continua a cair. Você pode ver uma lista de 415 erros nesta página da sua conta: https://my.sirv.com/#/analytics/errors/415?from=20231206&to=20231206 Você pode carregar arquivos para resolver quaisquer erros 415 em seus arquivos. Nós podemos fornecer uma lista de arquivos de bytes zero se você precisar - por favor pergunte à equipe de suporte do Sirv através deste formulário: https://sirv.com/help/support/#support Estamos continuando a restaurar tantos arquivos quanto possível.

7. 6 Kerzu 2023 da 19:47 UTCresolved

   A questão que causou a elevada taxa de 415 erros foi resolvida. Os arquivos truncados foram causados por um problema de software que escreveu alguns arquivos com zero bytes. Como era um software, isso fez com que os arquivos truncados fossem replicados em todas as versões do arquivo mestre. O Sirv triplica cada arquivo para proteger contra problemas de hardware (falhas de servidor ou disco rígido), no entanto, os arquivos atualizados passaram todas as verificações e fielmente triplicaram os arquivos. Existiu sem detecção porque versões em cache dos arquivos foram usadas para processamento e entrega. Todos os sistemas funcionaram perfeitamente, até o upgrade da infraestrutura de ontem quando arquivos em cache foram limpos. A causa raiz foi resolvida identificando-se e corrigindo-se o problema de software que causou truncamento. Isto foi concluído por 1500 UTC em 5 de dezembro. Então a tarefa era restaurar os arquivos que haviam sido truncados. Em toda a plataforma, aproximadamente 0,2% dos arquivos foram afetados. Desses arquivos, conseguimos restaurar entre 95% e 100%, dependendo da conta. Qualquer conta que tivesse menos de 100% de restauração está sendo enviada uma lista de arquivos de zero-byte que devem ser restaurados ao carregar os arquivos novamente. Por favor, procure nosso e-mail com uma lista de arquivos. Por favor, envie-nos uma mensagem através da seguinte URL se precisar de ajuda: https://sirv.com/help/support/#support Está em curso uma investigação aprofundada da questão, que será comunicada em detalhe por e-mail. Dentro do relatório será apresentada uma lista de medidas a serem tomadas para evitar qualquer possível repetição desta questão, juntamente com melhorias e novas funcionalidades que já estão a ser concebidas. Pedimos desculpas a todos os clientes que foram impactados por esta questão. É a primeira vez que os dados mestre foram perdidos. Vamos aprender todas as lições possíveis e tornar Sirv ainda mais forte e confiável do que antes.

8. 21 Kerzu 2023 da 10:05 UTCresolved

   Mais de 99% dos arquivos truncados restantes também foram restaurados. Qualquer usuário impactado foi fornecido com uma lista exata de arquivos que foram impactados. Não resta qualquer impacto residual desta questão. Classificado como nível de gravidade 1: Impacto crítico.

Traduzido automaticamente da atualização oficial do incidente.

1. 2 Kerzu 2023 da 04:19 UTCinvestigating

   A partir de 0419 UTC, um nível elevado de 429 erros foram retornados do local de Sydney CDN.

2. 2 Kerzu 2023 da 10:31 UTCresolved

   A questão foi resolvida em 1031 UTC. A causa foi uma configuração incorreta do servidor que fez com que o local do CDN de Sydney visse todas as solicitações vindas do mesmo endereço IP, em vez do endereço IP do cliente verdadeiro. Isso desencadeou a proteção DDOS, para limitar o número excessivo de pedidos do mesmo IP. 429 respostas foram devolvidas para muitos dos pedidos. A questão parecia ter sido extremamente curta quando a rede de datacentres de Sydney ficou indisponível. Essa questão durou aproximadamente 1 minuto. No entanto, o incidente real começou imediatamente após nossa equipe ter restaurado a localização do CDN de Sydney, que foi quando a configuração do servidor foi aplicada. O problema foi resolvido uma vez que descobrimos a configuração errada e corrigimo-lo. Estão a ser tomadas várias medidas para impedir que esta questão se repita e para reduzir o impacto de questões semelhantes, mas diferentes, no futuro: - Acompanhamento e alerta adicionais - Novo formulário de apresentação de emissões - Conselho de resolução sensível ao contexto - Alerta interno mais amplo. Só a localização da CDN de Sydney foi afectada. Classificado como nível de gravidade 3: Impacto menor.

Traduzido automaticamente da atualização oficial do incidente.

1. 22 Du 2023 da 18:30 UTCinvestigating

   Por volta de 1830 UTC em 22 de novembro, iniciamos uma atualização para o banco de dados de arquivos primários para um novo e mais poderoso cluster. Enquanto a atualização ocorreu, as consultas de pesquisa da API estavam falhando.

2. 23 Du 2023 da 10:35 UTCresolved

   Em 1035 UTC em 23 de novembro, a atualização foi concluída e buscas retomadas operação normal. Não havia tempo de inatividade e todos os sistemas funcionavam como normais, exceto que as solicitações de pesquisa da API haviam retornado respostas de erro. O problema não foi identificado porque outras solicitações da API estavam retornando como normal, então as respostas de erro da API total foram apenas ligeiramente elevadas e nenhum alerta foi disparado. A questão foi identificada após o evento, após um relato de um usuário que motivou uma investigação. Para identificar automaticamente tais problemas no futuro, estamos avaliando maneiras de monitorar a API de busca especificamente. Nós também estaremos atualizando o plugin Sirv WordPress para mostrar uma mensagem claramente descrita no caso de uma pesquisa falhou. Classificado como nível de gravidade 4: Impacto mínimo.

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Du 2023 da 20:47 UTCinvestigating

   As ferramentas de gerenciamento de arquivos no my.sirv.com estão carregando lentamente devido a um servidor falhou. A listagem de arquivos e a busca de arquivos levam de 2 a 20 segundos, enquanto normalmente leva de 1 a 4 segundos. O servidor falhado está a ser substituído e esperamos que a velocidade volte ao normal dentro de 72 horas. Isto será seguido por uma grande atualização de todo o painel de controle cluster servidor ao longo dos próximos 3 meses.

2. 14 Du 2023 da 21:33 UTCinvestigating

   Estamos esperando o provisionamento de um novo servidor para adicionar ao cluster, então a velocidade de navegação da interface se tornará muito mais rápida.

3. 15 Du 2023 da 14:09 UTCresolved

   O novo servidor foi implantado na noite de 14 de novembro e gradualmente preencheu seus caches. O painel de controle agora retornou ao seu desempenho rápido original. Servidores adicionais estão sendo atualizados, então o painel de controle carregará ainda mais rápido nas próximas 2 semanas. Classificado como nível de gravidade 4: Impacto mínimo.

Traduzido automaticamente da atualização oficial do incidente.

1. 23 Here 2023 da 13:10 UTCinvestigating

   Um aumento dramático das solicitações ao local do CDN de Washington D.C. ocorreu às 14:10 UTC em 23 de outubro, fazendo com que uma pequena proporção de solicitações fosse devolvida lentamente - mais de 2 segundos. O problema diminuiu nas próximas 3 horas, embora o tempo médio de resposta tenha permanecido elevado. O número retornou no dia seguinte às 14: 32 UTC em 24 de outubro, mais severamente do que antes causando 17% dos pedidos de carregamento lento - maior que 2 segundos e alguns até 30 segundos. A questão teve impacto em dois dos 25 locais de CDN do Sirv.

2. 25 Here 2023 da 05:48 UTCresolved

   A questão foi resolvida até às 06:48 UTC em 25 de Outubro. A investigação aponta para duas causas - o pico foi causado pelo fornecedor de DNS de Sirv encaminhando pedidos de POP de Los Angeles para Washington DC POP em vez disso. Isso teria sido bom em isolamento, mas o datacenter parece ter estrangulado a largura de banda dos servidores receptores, causando as respostas lentas. A investigação está em curso, ainda não chegou a conclusões definitivas e requer colaboração com os nossos fornecedores de DNS e datacenters. Estão já a ser tomadas medidas para evitar qualquer possível repetição desta questão. Mais tarde, será apresentado um relatório completo.

3. 14 Du 2023 da 13:37 UTCresolved

   A investigação detalhada sobre esta questão encontrou dois fatores contribuintes. O primeiro foi uma atualização para AWS Route53, que parece ter sido implementada pela AWS em 17 de outubro. Esta mudança não foi feita por Sirv para suas regras Route53, mas uma mudança dentro do próprio serviço Route53. O POP de Los Angeles tinha uma lógica de roteamento ligeiramente diferente de outros POPs e a atualização da AWS fez com que o roteamento se comportasse de forma diferente, com o tráfego sendo encaminhado para Washington DC. Isso passou despercebido como ele carga maior ainda estava dentro de sua capacidade e pedidos foram devolvidos com sucesso, de modo que passou despercebido como Washington DC foi capaz de lidar com a carga adicional. O segundo factor contribuinte foi mais elevado do que o tráfego normal durante o pico das horas de negociação dos EUA em 23 e 24 de Outubro. Os dois fatores combinados fizeram com que os discos rígidos Washington DC retornassem solicitações significativamente mais lentas do que o normal. Desde que a questão ocorreu, temos tomado várias ações para evitar que ela se repita; para mitigar contra incidentes similares possíveis; e para acelerar o tempo de resolução em caso de incidente. As ações incluem: - Nova lógica de roteamento foi aplicada. - A capacidade de Washington DC aumentou. - A capacidade de reserva foi aumentada em todos os outros locais CDN. - Nova tolerância introduzida para um local CDN a ser removido do roteamento. - Monitoramento de disco adicional, para ajudar a preparação precoce de upgrades de capacidade. Os HDDs estão a ser substituídos por SSDs. - Updated SOP para nossa equipe de suporte para investigar e responder a questões semelhantes. Classificado como nível de gravidade 3: Impacto menor.

Traduzido automaticamente da atualização oficial do incidente.

1. 22 Mae 2023 da 14:57 UTCinvestigating

   A questão anterior do uso de upload elevado retornou, com um pequeno número de upload API falhando.

2. 22 Mae 2023 da 15:06 UTCresolved

   O problema resolveu-se dentro de 9 minutos após o volume de upload normalizado. Durante o período, aproximadamente 98% dos uploads tiveram sucesso e 2% falharam. Os uploads da API REST são limitados por hora, ao valor especificado na página de Uso da sua conta Sirv https://my.sirv.com/#/account/usage. Se você usar a API REST para carregar imagens, a melhor prática é verificar a resposta para cada pedido de upload e se você receber uma resposta de erro (400, 401, 429 etc.) então pausar uploads e tentar novamente mais tarde. Consulte aqui os documentos: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide Classificado como nível de gravidade 4: Impacto mínimo.

Traduzido automaticamente da atualização oficial do incidente.

1. 22 Mae 2023 da 11:31 UTCinvestigating

   Um pequeno número de pedidos de upload da API REST estão falhando devido à carga muito alta.

2. 22 Mae 2023 da 12:37 UTCresolved

   Este problema resolveu-se uma vez que a carga na API de upload começou a cair. Durante o período, aproximadamente 97% dos uploads tiveram sucesso e 3% falharam. Os uploads da API REST são limitados por hora, ao valor especificado na página de Uso da sua conta Sirv https://my.sirv.com/#/account/usage. Se você usar a API REST para carregar imagens, a melhor prática é verificar a resposta para cada pedido de upload e se você receber uma resposta de erro (400, 401, 429 etc.) então pausar uploads e tentar novamente mais tarde. Consulte aqui os documentos: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide Classificado como nível de gravidade 4: Impacto mínimo.

Traduzido automaticamente da atualização oficial do incidente.

1. 27 Ebrel 2023 da 23:00 UTCinvestigating

   Um dos servidores CDN de Los Angeles tornou-se pouco saudável e começou a retornar erros 4xx em 0000 UTC. Foi removido do roteamento após 90 segundos e dentro de mais 60 segundos, todo o tráfego estava sendo encaminhado para servidores saudáveis.

2. 27 Ebrel 2023 da 23:03 UTCresolved

   O problema foi resolvido automaticamente em 3 minutos. Classificado como nível de gravidade 4: Impacto mínimo.

Traduzido automaticamente da atualização oficial do incidente.

1. 16 Meurzh 2023 da 12:17 UTCinvestigating

   Alguns pedidos para o POP de Londres de Sirv CDN, estão retornando erros devido à alta carga. Este POP serve o Reino Unido e a Irlanda. Estamos a trabalhar numa resolução.

2. 16 Meurzh 2023 da 13:33 UTCresolved

   A questão foi resolvida e está agora a ser acompanhada.

3. 16 Meurzh 2023 da 16:22 UTCresolved

   Alguns pedidos recebidos por um dos servidores CDN de Londres falharam devido a uma combinação de resolução DNS local e tempo limite de rede pulsante. A questão começou em 1215 UTC e foi resolvida em 1332 UTC. Durante este período, 25% dos pedidos do Reino Unido e da Irlanda devolveram um erro de 404 ou 500. O problema teria sido resolvido mais cedo, mas uma falha de validação de certificado SSL não relacionada algumas horas antes alertas bloqueados de ser recebido pelo nosso sistema de monitoramento. As alterações já foram implementadas para evitar que esta questão se repita. A questão do certificado SSL foi resolvida; um segundo nível de monitoramento independente foi configurado; uma automação de saúde adicional está sendo testada que tem o potencial de resolver esses problemas automaticamente. Classificado como nível de gravidade 3: Impacto menor.

Traduzido automaticamente da atualização oficial do incidente.

1. 23 Cʼhwevrer 2023 da 07:55 UTCresolved

   A questão foi resolvida às 0755 UTC. Em 0625 UTC, alguns pedidos para o Indore CDN POP que serve a Índia começou a retornar uma resposta 404 (arquivo não encontrado), em vez de uma resposta 200 (OK). O problema ocorreu 14 horas após uma atualização para todos os servidores de CDN em todo o mundo. Todos os POPs se comportaram de forma saudável, incluindo o POP Índia, mas o POP Indore não tinha atualizado com sucesso e, eventualmente, começou a retornar erros. Uma vez identificada a questão, foi resolvida através da reintrodução da actualização do POP indiano. Durante o incidente, 94% dos pedidos retornaram a um erro. Os pedidos a todos os outros países foram devolvidos normalmente. Para evitar que esta questão se repita, uma nova regra de implantação automatizada está sendo criada para uma parte do processo de implantação onde havia apenas um controle humano. Uma métrica de alerta adicional também está sendo criada, para identificar uma situação em que uma implantação falhou. Pedimos desculpas a todos os clientes que foram afetados por este incidente e estamos avaliando outras mudanças que podem ajudar a evitar qualquer possível repetição do problema. Se um problema de CDN como este ocorrer, uma solução imediata dentro de seu controle é desativar o CDN temporariamente em suas configurações do Sirv aqui: https://my.sirv.com/#/account/settings/domains Classificado como nível de gravidade 2: Impacto significativo.

Traduzido automaticamente da atualização oficial do incidente.