Cronologia delle interruzioni di Sirv

1. 6 agosto 2026 alle ore 10:17 UTCinvestigating

   I carichi di alcuni account Sirv stanno fallendo, a causa di un problema del server. Questo può anche impedire alle immagini di visualizzare occasionalmente. Stiamo lavorando per risolvere il problema il prima possibile.

2. 6 agosto 2026 alle ore 15:22 UTCresolved

   La causa del problema è stata identificata e ora è stata completamente risolta. Durante il periodo, circa il 25% dei conti di Sirv potrebbe aver sperimentato una percentuale di caricamenti di file in difetto. Ripristinare i caricamenti un breve periodo di tempo dopo potrebbe essere stato successo perché questo è stato un solo che interessa un piccolo numero di richieste. Una revisione è ora in corso e ulteriori informazioni saranno fornite qui più tardi.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 27 giugno 2026 alle ore 18:34 UTCmonitoring

   Un piccolo numero di upload e richieste sono errori di ritorno a causa di errori di interruttore di rete multipli nel datacenter primario di Sirv. Le richieste di CDN funzionano come normali. Stiamo monitorando attentamente la situazione e fornirà aggiornamenti come ulteriori informazioni diventano disponibili.

2. 27 giugno 2026 alle ore 19:37 UTCresolved

   Tutti i servizi sono tornati alla normalità e le richieste stanno completando.

3. 28 giugno 2026 alle ore 09:03 UTCresolved

   Questo problema è stato causato da un errore del router centrale che interessa il centro dati primario di Sirv. Questo ha causato brevi, interruzioni intermittenti su archiviazione di file e upload, attraverso tutti i tipi di trasferimento: API, S3 e FTP. Sirv si è automaticamente spostato al suo servizio di failover, quindi l'elaborazione dei file e la consegna continuarono come normale. Le richieste di CDN sono continuate anche come normali. Tutti i servizi sono stati ripristinati una volta che il datacentre aveva risolto il core router outage.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 30 gennaio 2026 alle ore 12:46 UTCinvestigating

   I tempi di risposta per alcune richieste in Germania sono più lenti del normale e un piccolo numero sono tempi fuori. Il problema e' stato indagato.

2. 30 gennaio 2026 alle ore 14:28 UTCresolved

   Il problema è stato risolto. Uno dei server che serve la Germania è stato sovraccaricato e risponde più lentamente del solito. Il server è di nuovo sano. Stiamo rivedendo quali azioni prendere per ridurre la possibilità di questo accada di nuovo.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 31 marzo 2025 alle ore 14:32 UTCinvestigating

   Alcune richieste della California sono lente e un piccolo numero (sotto il 2%) stanno fallendo. Questo viene indagato e probabilmente legato a nuovi server CDN che sono stati dispiegati oggi a Los Angeles.

2. 31 marzo 2025 alle ore 15:16 UTCresolved

   Il problema è stato risolto. Il problema è stato causato dalla perdita di pacchetti che interessa il nostro nuovo datacenter di Los Angeles. Il datacenter ha tracciato il problema al loro provider a monte, Arelion, che stava sperimentando l'instabilità della rete. Il problema è stato risolto quando Arelion è stato temporaneamente disabilitato come fornitore a monte e il traffico è stato reindirizzato attraverso altri fornitori. Abbiamo bisogno che i nostri datacenter identificano e reindirizzano il traffico automaticamente e rapidamente in tali scenari. Tuttavia, la risoluzione di questo problema non era abbastanza veloce e dato che si è verificato subito dopo l'adozione di questo nuovo datacenter, abbiamo deciso di smettere di usarlo. Tutto il traffico è ora in rotta dal nostro datacenter originale di Los Angeles (al 7 aprile 2025).

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 15 marzo 2025 alle ore 17:56 UTCresolved

   Alcuni file di upload non stanno completando a causa di un problema di cluster server. La causa e' stata indagata. Il problema riguarda un piccolo numero di conti. Se il caricamento del file fallisce, si prega di attendere che questo problema è stato risolto.

2. 16 marzo 2025 alle ore 08:40 UTCidentified

   Questo problema rimane in corso. La causa del problema è stata identificata e stiamo lavorando per risolverlo il prima possibile.

3. 16 marzo 2025 alle ore 15:25 UTCresolved

   Il problema è stato risolto. Il problema è stato causato da due server in un cluster che non riesce simultaneamente. Questo ha colpito il caricamento di nuovi file a circa il 20% degli account Sirv. I carichi sono progettati per continuare come normale quando un server è giù, ma quando due server sono giù, alcuni upload possono fallire, che è quello che è successo. Hanno fallito a causa di un servizio di esportatore che ha smesso di funzionare su un server, poi l'altro server. Gli errori hanno impedito ai servizi di riavviare. Poi un secondo problema ha causato la risoluzione di richiedere molto più tempo del previsto perché i server non potevano essere riavviati. Questo era dovuto a un BIOS obsoleto. Una volta che il BIOS era stato aggiornato, i server sono stati riavviati e la causa del problema sottostante è stata risolta. Per evitare che ciò accada di nuovo, abbiamo implementato un nuovo processo di gestione del BIOS con il nostro datacenter. Stiamo anche abbreviando il nostro ciclo di aggiornamento hardware, per aggiornamenti hardware più frequenti. Per ridurre la probabilità di guasto del servizio esportatore da ricorrenti, abbiamo disabilitato un processo e stiamo monitorando le metriche del server.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 26 febbraio 2025 alle ore 09:29 UTCinvestigating

   Per un periodo di 3 minuti tra 09:29 e 09:32 UTC, alcune richieste non sono stati restituiti. Questo problema ha interessato solo alcune richieste e solo alcuni conti. La maggior parte dei conti non sono stati colpiti.

2. 26 febbraio 2025 alle ore 09:32 UTCresolved

   Il problema è stato risolto entro 3 minuti. La causa era il riavvio di più server contemporaneamente, mentre solo 1 server doveva essere riavviato. Questa era una supervisione nelle nostre procedure operative standard. Stiamo indagando sui modi per proteggere automaticamente e impedire che questo accada.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 19 dicembre 2024 alle ore 14:20 UTCresolved

   Un errore del server sta causando alcuni upload di file per fallire per un numero limitato di account. Il problema è risolto. Se si verificano upload falliti, si prega di pausa e riprovare più tardi.

2. 19 dicembre 2024 alle ore 18:09 UTCresolved

   Il problema è stato risolto. Un numero insolitamente elevato di server è fallito allo stesso tempo. Sirv è stato progettato per continuare il normale funzionamento durante un outage del server e tutti i sistemi hanno continuato come normale, ma alcuni upload di file non sono riusciti. Stiamo valutando quali possibili cambiamenti potrebbero essere apportati per assistere in tali situazioni in futuro.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 14 novembre 2024 alle ore 09:52 UTCinvestigating

   Un numero elevato di 504 timeout viene restituito per le richieste di caricamento dei file API.

2. 14 novembre 2024 alle ore 13:19 UTCinvestigating

   Continua ad essere pesante carico sull'API da richieste di upload. Un fattore che contribuisce è il gran numero di richieste di aumento delle immagini AI, che stanno prendendo più tempo del solito per elaborare. Il ritardo causato dalla coda delle richieste sta causando alcune richieste di caricamento dei file API per fallire con una risposta 504.

3. 14 novembre 2024 alle ore 15:23 UTCresolved

   Sono state apportate modifiche e la questione è quasi risolta. La maggior parte delle richieste di upload hanno successo.

4. 14 novembre 2024 alle ore 19:06 UTCresolved

   Il sovraccarico di upload API è quasi completamente risolto.

5. 15 novembre 2024 alle ore 04:42 UTCresolved

   Il problema è stato completamente risolto. Il problema è iniziato quando le richieste di API di upscaling dell'immagine pesante hanno sovraccaricato l'API di caricamento, causando alcune richieste API di restituire 504 errori. Questo è stato risolto, ma un effetto knock-on ha causato circa il 5% delle richieste API di fallire con una risposta 502. Per evitare che questo problema accada di nuovo, sono stati apportati miglioramenti per ridurre il carico di upscaling dell'immagine e distribuire meglio il carico. Vengono inoltre apportate modifiche alla registrazione e all'avviso, per un'identificazione più rapida di tali scenari. Il più grande impatto di questo problema è stato sul plugin WordPress Sirv. Il plugin stava inviando una richiesta API su tutte le pagine di amministrazione, che ha bloccato la pagina dal caricamento fino a quando la risposta non era stata ricevuta - tipicamente meno di 300ms, ma fino a 20 secondi se le richieste API timed out. Tali richieste API non sono state richieste, quindi una nuova versione plugin WordPress v7.3.3 è stata rilasciata a 1805 UTC (14 novembre) per rimuovere tali richieste e impedire che questo problema si ripeta: https://wordpress.org/plugins/sirv/ ------ Se si utilizza l'API Sirv, si consiglia di scrivere i suoi script per riprovare le richieste che ricevono una risposta 502. Le raccomandazioni per la gestione di 502 e altre risposte agli errori sono fornite qui: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 22 febbraio 2024 alle ore 10:52 UTCinvestigating

   Alcuni file non vengono restituiti per un piccolo numero di account. Questo problema è stato affrontato con urgenza.

2. 22 febbraio 2024 alle ore 12:06 UTCresolved

   Il problema è stato risolto. A 1052 UTC, circa l'11% delle richieste a un piccolo numero di conti (12 conti, su 50.000+) hanno restituito 404 risposte (file non trovato) quando avrebbero dovuto restituire 200 risposte (OK). Quando il team di Sirv ha identificato il problema, hanno lavorato rapidamente per risolverlo e entro il 1206 UTC tutte queste richieste sono state restituire la risposta normale 200. Il problema si è verificato a causa di una cattiva configurazione da parte di ingegneri Sirv mentre stavano configurando un nuovo cluster di storage shard. Alcune richieste andavano al nuovo shard prima che fosse pronto a riceverle. Classificato come livello di gravità 3: impatto minore.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 5 gennaio 2024 alle ore 20:21 UTCinvestigating

   Un elevato numero di richieste alle 25 sedi CDN di Sirv stanno restituendo un errore. I nostri ingegneri stanno lavorando rapidamente per identificare e risolvere il problema.

2. 5 gennaio 2024 alle ore 21:07 UTCresolved

   Il problema è stato risolto. È stato causato dal fallimento di un daemon software simultaneamente su più server. Questo è un service manager leggero e altamente efficiente che non ha mai fallito in passato. Durante il periodo, tra il 3% e il 58% delle richieste HTTPS ha restituito un errore, a seconda di quale delle 25 sedi CDN ha ricevuto la richiesta. Stiamo ora indagando sul perché questo è accaduto e prenderà azioni per impedire che questo impatta la disponibilità del servizio in futuro. Classificato come livello di gravità 2: impatto significativo.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 5 dicembre 2023 alle ore 15:03 UTCinvestigating

   Un livello elevato di 415 errori si verifica sul CDN. I nostri ingegneri stanno indagando sulla causa.

2. 5 dicembre 2023 alle ore 18:32 UTCinvestigating

   Stiamo continuando a indagare sulla causa di questo problema. La sua natura è complessa. Si rappresenta come un errore 415, da file di byte zero. C'è anche un elevato tasso anche se inferiore di 500 errori. La maggior parte delle richieste hanno successo 200 risposte. I nostri ingegneri stanno lavorando duramente per capire e risolvere questo problema.

3. 5 dicembre 2023 alle ore 22:56 UTCresolved

   Il problema di errore 415 è stato causato da alcuni file che diventano troncati, il che significa che hanno perso parte del loro contenuto. Questi file mostrano nel pannello di controllo di my.sirv.com come avere 0 byte. I file caricati oggi sono stati più propensi a diventare troncati, anche se sembra che la tronca stia accadendo ai file per molto tempo. Questo non è stato identificato perché si sono esibiti completamente come normale, a causa del caching delle versioni non certificate. Il problema del file troncato è diventato evidente solo oggi, dopo un aggiornamento dell'infrastruttura. Le cache dei server sono state cancellate e le versioni troncate sono diventate evidenti. Si ritiene che la causa della tronca sia stata un bug software che ora è stato risolto. Attualmente stiamo lavorando per ripristinare i file troncati - un processo che può richiedere da ore a giorni. Se sei in grado di ricaricare qualsiasi file che non sono attualmente in caricamento, si prega di farlo ora. La questione è stimata per essere che colpisce circa ~0,2% dei file.

4. 5 dicembre 2023 alle ore 23:33 UTCresolved

   Circa l'80% dei file troncati sono stati recuperati. Il numero di 415 errori sono caduti in modo significativo, anche se rimangono elevati. Per risolvere completamente il problema, i file troncati rimanenti devono essere sostituiti con il file originale. Stiamo lavorando su modi per recuperare i file rimanenti, anche se sono difficili da ottenere e può richiedere ore o giorni. Per la risoluzione più veloce possibile, si consiglia di ricaricare i file. Tali file mostreranno nel tuo account come avere 0 byte. Inizia al seguente URL, per vedere un elenco di tutti i file caricati negli ultimi 30 giorni: https://my.sirv.com/#/search/?created=30d Trova qualsiasi file byte zero selezionando i risultati per Size, Ascending. Un altro aggiornamento verrà pubblicato qui una volta che abbiamo notizie sui file rimanenti.

5. 6 dicembre 2023 alle ore 01:48 UTCinvestigating

   Stiamo continuando a recuperare il piccolo numero di file troncati rimanenti. Si stima che ciò richieda ulteriori 12-24 ore. Se hai dei file che non vengono serviti, puoi risolverli immediatamente ricaricandoli. Stiamo creando uno strumento per generare un elenco di file byte zero. Se desideri un elenco di qualsiasi file di byte zero nel tuo account, invia una richiesta all'indirizzo https://sirv.com/help/support/#support e prepareremo un elenco una volta che lo strumento è pronto. Indipendentemente, continueremo a lavorare per recuperare tutti i file. Se si caricano i file utilizzando la funzione Autofetch di Sirv, è possibile eliminare semplicemente i file di byte zero e saranno ri-fetched dalla posizione remota sulla prossima richiesta.

6. 6 dicembre 2023 alle ore 12:12 UTCresolved

   Altri file sono stati ripristinati. Il tasso di 415 errori continua a cadere. Puoi vedere un elenco di 415 errori in questa pagina del tuo account: https://my.sirv.com/#/analytics/errors/415?da=20231206&to=20231206 È possibile caricare i file per risolvere eventuali errori 415 nei file. Possiamo fornire un elenco di file byte zero se avete bisogno - si prega di chiedere al team di supporto Sirv tramite questo modulo: https://sirv.com/help/support/#support Stiamo continuando a ripristinare il maggior numero possibile di file.

7. 6 dicembre 2023 alle ore 19:47 UTCresolved

   Il problema che ha causato il tasso elevato di 415 errori è stato risolto. I file troncati sono stati causati da un problema software che ha scritto alcuni file con byte zero. Poiché era software, questo ha causato i file troncati da replicare in tutte le versioni del file master. Sirv triplica ogni file per proteggere da problemi hardware (server o guasti del disco rigido), tuttavia, i file aggiornati hanno passato tutti i controlli e fedelmente triplicato i file. E 'esistito senza rilevamento perché le versioni cache dei file sono stati utilizzati per l'elaborazione e la consegna. Tutti i sistemi hanno funzionato perfettamente, fino all'aggiornamento dell'infrastruttura di ieri quando i file memorizzati nella cache sono stati cancellati. La causa principale è stata risolta identificando e correggendo il problema del software che ha causato la tronca. Questo è stato completato da 1500 UTC il 5 dicembre. Poi il compito era quello di ripristinare quei file che erano stati troncati. Attraverso la piattaforma, circa lo 0,2% dei file era stato interessato. Di quei file, siamo stati in grado di ripristinare tra il 95% e il 100%, a seconda dell'account. Qualsiasi account che avesse meno del 100% di ripristino viene inviato un elenco di file di byte zero che dovrebbero essere ripristinati caricando nuovamente i file. Si prega di guardare fuori per la nostra email con un elenco di file. Inviateci il seguente URL se avete bisogno di aiuto: https://sirv.com/help/support/#support Un'indagine approfondita del problema è in corso, che verrà segnalato in dettaglio per e-mail. All'interno della relazione sarà un elenco di azioni in corso per evitare qualsiasi possibile ripetizione di questo problema, insieme a miglioramenti e nuove funzionalità che sono già state progettate. Ci scusiamo per tutti i clienti che sono stati colpiti da questo problema. È la prima volta che i dati master sono stati persi. Impareremo ogni possibile lezione da esso e rendere Sirv ancora più forte e affidabile di prima.

8. 21 dicembre 2023 alle ore 10:05 UTCresolved

   Oltre il 99% dei rimanenti file troncati sono stati ripristinati. Qualsiasi utente colpito è stato fornito con un elenco esatto dei file che sono stati influenzati. Non vi è alcun impatto residuo rimanente da questo problema. Classificato come livello di gravità 1: impatto critico.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 2 dicembre 2023 alle ore 04:19 UTCinvestigating

   Dal 0419 UTC, un livello elevato di 429 errori sono stati restituiti dalla posizione di Sydney CDN.

2. 2 dicembre 2023 alle ore 10:31 UTCresolved

   Il problema è stato risolto a 1031 UTC. La causa era un errore di configurazione del server che ha reso la posizione del CDN di Sydney vedere tutte le richieste provenienti dallo stesso indirizzo IP, invece del vero indirizzo IP del client. Ciò ha innescato la protezione DDOS, per limitare il numero eccessivo di richieste dallo stesso IP. 429 risposte sono state restituite per molte delle richieste. Il problema sembra essere stato un problema estremamente breve quando la rete di datacentre di Sydney non è stata disponibile. Il problema è durato solo circa 1 minuto. Tuttavia, l'effettivo incidente è iniziato subito dopo che il nostro team ha ripristinato la posizione di Sydney CDN, che è quando il server di cattiva configurazione è stato applicato. Il problema è stato risolto una volta scoperto la cattiva configurazione e corretto. Vengono intraprese più azioni per evitare che questo problema si ripeta e ridurre l'impatto di problemi simili ma diversi in futuro: - Monitoraggio supplementare e allerta - Nuovo modulo di presentazione del numero - Consulenza di risoluzione sensibile al contesto - Wider allarme interno Solo la posizione del CDN di Sydney è stata colpita. Classificato come livello di gravità 3: impatto minore.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 22 novembre 2023 alle ore 18:30 UTCinvestigating

   A circa 1830 UTC il 22 novembre, abbiamo iniziato un aggiornamento al database di file primario in un nuovo cluster più potente. Mentre l'aggiornamento ha avuto luogo, le query di ricerca API stavano fallendo.

2. 23 novembre 2023 alle ore 10:35 UTCresolved

   A 1035 UTC il 23 novembre, l'aggiornamento è stato completo e le ricerche hanno ripreso il funzionamento normale. Non c'erano tempi di fermo e tutti i sistemi funzionavano come normali, tranne che le richieste di ricerca API erano state di ritorno risposte di errore. Il problema non è stato identificato perché altre richieste API erano di ritorno come normale, quindi le risposte di errore API totali sono state solo leggermente elevate e non sono stati attivati avvisi. Il problema è stato identificato dopo l'evento, dopo un rapporto da parte di un utente ha richiesto un'indagine. Per identificare automaticamente tali problemi in futuro, stiamo valutando modi per monitorare l'API di ricerca specificamente. Saremo anche l'aggiornamento del plugin WordPress Sirv per mostrare un messaggio chiaramente descritto in caso di una ricerca fallita. Classificato come livello di gravità 4: impatto minimo.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 novembre 2023 alle ore 20:47 UTCinvestigating

   Gli strumenti di gestione dei file di my.sirv.com stanno caricando lentamente a causa di un server fallito. L'elenco dei file e la ricerca dei file stanno prendendo da 2 a 20 secondi, mentre normalmente ci vogliono da 1 a 4 secondi. Il server fallito viene sostituito e ci aspettiamo che la velocità ritorni alla normalità entro 72 ore. Questo sarà seguito da un importante aggiornamento dell'intero cluster di server del pannello di controllo nei prossimi 3 mesi.

2. 14 novembre 2023 alle ore 21:33 UTCinvestigating

   Stiamo aspettando il provisioning di un nuovo server da aggiungere al cluster, quindi la velocità di navigazione UI diventerà molto più veloce.

3. 15 novembre 2023 alle ore 14:09 UTCresolved

   Il nuovo server è stato distribuito la sera del 14 novembre e gradualmente riempito le sue cache. Il pannello di controllo è ora tornato alle sue prestazioni veloci originali. Ulteriori server sono ora in fase di aggiornamento, quindi il pannello di controllo si carica più velocemente ancora nelle prossime 2 settimane. Classificato come livello di gravità 4: impatto minimo.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 23 ottobre 2023 alle ore 13:10 UTCinvestigating

   Un aumento drammatico delle richieste alla sede CDN di Washington si è verificato alle 14:10 UTC il 23 ottobre, causando una piccola percentuale di richieste da restituire lentamente - più di 2 secondi. Il problema è subsiderato nelle prossime 3 ore, anche se il tempo medio di risposta è rimasto elevato. Il problema è tornato il giorno seguente alle 14: 32 UTC il 24 ottobre, più severamente che prima causando 17% delle richieste di caricare lentamente - più di 2 secondi e alcuni fino a 30 secondi. Il problema ha colpito due delle 25 sedi CDN di Sirv.

2. 25 ottobre 2023 alle ore 05:48 UTCresolved

   Il problema è stato risolto da 06:48 UTC il 25 ottobre. I punti di indagine verso due cause - il picco è stato causato dal provider DNS di Sirv che routing Los Angeles POP richieste al Washington D.C. POP invece. Ciò sarebbe stato bene in isolamento, ma il datacentre sembra aver alterato la larghezza di banda dei server riceventi, causando le risposte lente. L'indagine è in corso, non ha ancora raggiunto conclusioni definitive e richiede la collaborazione con i nostri provider DNS e datacentre. Sono già in corso azioni per evitare qualsiasi possibile ripetizione di questo problema. Un rapporto completo sarà fornito qui più tardi.

3. 14 novembre 2023 alle ore 13:37 UTCresolved

   L'indagine dettagliata su questo problema ha trovato due fattori che contribuiscono. Il primo è stato un aggiornamento di AWS Route53, che sembra essere stato implementato da AWS il 17 ottobre. Questo cambiamento non è stato fatto da Sirv alle sue regole Route53, ma un cambiamento all'interno del servizio Route53 stesso. Il Los Angeles POP aveva una logica di routing leggermente diversa con altre POP e l'aggiornamento AWS ha causato il routing a comportarsi in modo diverso, con il traffico che si sta dirigendo verso il fallback di Washington DC. Questo è andato inosservato come il carico più alto era ancora dentro la sua capacità e le richieste sono stati restituiti con successo, così questo è andato inosservato come Washington DC è stato in grado di gestire il carico aggiuntivo. Il secondo fattore di contributo è stato maggiore del traffico normale durante il picco delle ore di trading degli Stati Uniti il 23 e 24 ottobre. I due fattori combinati hanno causato i dischi rigidi di Washington DC per restituire le richieste in modo significativo più lento rispetto al normale. Dal momento che si è verificato il problema, abbiamo preso più azioni per impedirlo di ripetere; per mitigare gli incidenti possibili simili; e per accelerare il tempo di risoluzione in caso di incidente. Le azioni includono: - È stata applicata una nuova logica di routing. - La capacità di Washington DC è aumentata. - La capacità di riserva è stata aumentata in tutte le altre sedi CDN. - Nuova tolleranza introdotta per una posizione CDN da rimuovere dal routing. - Monitoraggio del disco aggiuntivo, per aiutare la preparazione precoce degli aggiornamenti di capacità. - Gli HDD vengono sostituiti con SSD. - Aggiornato SOP per il nostro team di supporto per indagare e rispondere a problemi simili. Classificato come livello di gravità 3: impatto minore.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 22 maggio 2023 alle ore 14:57 UTCinvestigating

   Il numero precedente di utilizzo elevato di upload è tornato, con un piccolo numero di carica API in mancanza.

2. 22 maggio 2023 alle ore 15:06 UTCresolved

   Il problema si è risolto entro 9 minuti una volta caricato il volume normalizzato. Durante il periodo, circa il 98% degli upload è riuscito e il 2% è fallito. Gli upload REST API sono limitati all'ora, all'importo specificato nella pagina di utilizzo del tuo account Sirv https://my.sirv.com/#/account/usage. Se si utilizza l'API REST per caricare le immagini, best-practice è quello di controllare la risposta per ogni richiesta di upload e se si riceve una risposta di errore (400, 401, 429 ecc.) quindi pausa upload e riprovare in seguito. Fare riferimento ai documenti qui: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide Classificato come livello di gravità 4: impatto minimo.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 22 maggio 2023 alle ore 11:31 UTCinvestigating

   Un piccolo numero di richieste di caricamento dell'API REST sta fallendo a causa di carichi molto elevati.

2. 22 maggio 2023 alle ore 12:37 UTCresolved

   Questo problema si è risolto una volta che il carico sull'API di upload ha iniziato a cadere. Durante il periodo, circa il 97% degli upload è riuscito e il 3% è fallito. Gli upload REST API sono limitati all'ora, all'importo specificato nella pagina di utilizzo del tuo account Sirv https://my.sirv.com/#/account/usage. Se si utilizza l'API REST per caricare le immagini, best-practice è quello di controllare la risposta per ogni richiesta di upload e se si riceve una risposta di errore (400, 401, 429 ecc.) quindi pausa upload e riprovare in seguito. Fare riferimento ai documenti qui: https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide Classificato come livello di gravità 4: impatto minimo.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 27 aprile 2023 alle ore 23:00 UTCinvestigating

   Uno dei server CDN di Los Angeles è diventato malsano e ha iniziato a restituire errori 4xx a 0000 UTC. È stato rimosso dal routing dopo 90 secondi e in altri 60 secondi, tutto il traffico è stato indirizzato a server sani.

2. 27 aprile 2023 alle ore 23:03 UTCresolved

   Il problema è stato risolto automaticamente entro 3 minuti. Classificato come livello di gravità 4: impatto minimo.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 16 marzo 2023 alle ore 12:17 UTCinvestigating

   Alcune richieste al London POP di Sirv CDN, stanno ritornando errori a causa di un alto carico. Questo POP serve Regno Unito e Irlanda. Stiamo lavorando a una risoluzione.

2. 16 marzo 2023 alle ore 13:33 UTCresolved

   Il problema è stato risolto e ora viene monitorato.

3. 16 marzo 2023 alle ore 16:22 UTCresolved

   Alcune richieste ricevute da uno dei server CDN di Londra sono fallite a causa di una combinazione di risoluzione DNS locale e di timeout di rete. Il problema iniziò a 1215 UTC e fu risolto a 1332 UTC. Durante questo periodo, il 25% delle richieste del Regno Unito e dell'Irlanda ha restituito un errore di 404 o 500. Il problema sarebbe stato risolto prima, ma un guasto di convalida del certificato SSL non correlato poche ore prima bloccato avvisi da essere ricevuto dal nostro sistema di monitoraggio. Le modifiche sono già state implementate per evitare che questo problema si ripeta. Il problema del certificato SSL è stato risolto; è stato configurato un secondo livello di monitoraggio indipendente; si sta verificando un'ulteriore automazione sanitaria che ha il potenziale di risolvere automaticamente tali problemi. Classificato come livello di gravità 3: impatto minore.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 23 febbraio 2023 alle ore 07:55 UTCresolved

   Il problema è stato risolto al 0755 UTC. Al 0625 UTC, alcune richieste al Indore CDN POP che serve l'India hanno iniziato a restituire una risposta 404 (file non trovato), invece di una risposta 200 (OK). Il problema si è verificato 14 ore dopo un aggiornamento a tutti i server CDN in tutto il mondo. Tutti i POP si sono comportati in modo sano, tra cui l'India POP, ma l'Indore POP non aveva aggiornato con successo e alla fine ha iniziato a restituire gli errori. Una volta che il problema era stato identificato, è stato risolto ri-deploying l'aggiornamento al POP India. Durante l'incidente, il 94% delle richieste ha restituito un errore. Le richieste a tutti gli altri paesi sono state restituite come normali. Per evitare che questo problema si ripeta, viene creata una nuova regola di distribuzione automatizzata per una parte del processo di distribuzione in cui vi era stato solo un controllo umano. Viene anche creata una metrica di avviso aggiuntiva, per identificare una situazione in cui una distribuzione è fallita. Ci scusiamo per tutti i clienti che sono stati colpiti da questo incidente e stiamo valutando altri cambiamenti che possono aiutare a prevenire qualsiasi possibile ripetizione del problema. Se si verifica un problema CDN come questo, una soluzione immediata all'interno del proprio controllo è di disabilitare temporaneamente il CDN nelle impostazioni di Sirv qui: https://my.sirv.com/#/account/settings/domains Classificato come livello di gravità 2: impatto significativo.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.