Sirv driftsforstyrrelser

1. 6. august 2026 kl. 10.17 UTCinvestigating

   Uploads til nogle Sirv-konti mislykkes, på grund af en server problem. Dette kan også forhindre billeder i at vise lejlighedsvis. Vi arbejder på at løse problemet så hurtigt som muligt.

2. 6. august 2026 kl. 15.22 UTCresolved

   Årsagen til dette spørgsmål blev identificeret, og det er nu blevet fuldstændig løst. I perioden, omkring 25% af Sirv konti kan have oplevet en del af fil uploads svigtende. Fornyelse af uploads et kort stykke tid senere kan have været en succes, fordi dette kun var en påvirker et lille antal anmodninger. Der foretages nu en revision, og der vil blive givet yderligere oplysninger her senere.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 27. juni 2026 kl. 18.34 UTCmonitoring

   Et lille antal uploads og anmodninger returnerer fejl på grund af flere netværk switch fejl i Sirv 's primære datacenter. CDN-anmodninger fungerer som normalt. Vi følger nøje situationen og vil give opdateringer, efterhånden som flere oplysninger bliver tilgængelige.

2. 27. juni 2026 kl. 19.37 UTCresolved

   Alle tjenester er tilbage til normal og anmodninger er afsluttet.

3. 28. juni 2026 kl. 09.03 UTCresolved

   Dette spørgsmål var forårsaget af en kerne router fejl påvirker Sirv primære datacenter. Dette forårsagede korte, intermitterende udfald på fil opbevaring og uploads, på tværs af alle overførselstyper: API, S3 og FTP. Sirv automatisk skiftet til sin failover service, så fil behandling og levering fortsatte som normalt. CDN anmodninger fortsatte også som normalt. Alle tjenester blev genoprettet, når datacenter havde løst kernen router afbrydelse.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 30. januar 2026 kl. 12.46 UTCinvestigating

   Responstid for nogle anmodninger i Tyskland er langsommere end normalt, og et lille antal er timing ud. Spørgsmålet bliver undersøgt.

2. 30. januar 2026 kl. 14.28 UTCresolved

   Spørgsmålet er løst. En af serverne i Tyskland var overbelastet og reagerede langsommere end normalt. Serveren er nu sund igen. Vi undersøger, hvilke foranstaltninger der skal træffes for at mindske risikoen for, at dette sker igen.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 31. marts 2025 kl. 14.32 UTCinvestigating

   Nogle anmodninger fra Californien er langsomme og et lille antal (under 2%) mislykkes. Dette er ved at blive undersøgt og sandsynligvis relateret til nye CDN servere, der blev indsat i dag i Los Angeles.

2. 31. marts 2025 kl. 15.16 UTCresolved

   Spørgsmålet er løst. Problemet skyldtes pakketab, der påvirkede vores nye Los Angeles datacenter. Datacenter sporet problemet til deres opstrømsleverandør, Arelion, som var oplever netværk ustabilitet. Kommissionen konkluderer derfor, at Arelion er en kriseramt virksomhed. Vi kræver, at vores datacentre identificerer og omdirigerer trafik automatisk og hurtigt i sådanne scenarier. Men løsningen af dette spørgsmål var ikke hurtig nok, og da det skete kort tid efter vedtagelsen af dette nye datacenter, har vi besluttet at ophøre med at bruge det. Al trafik bliver nu omdirigeret fra vores originale Los Angeles datacenter (fra 7. april 2025).

Automatisk oversat fra den officielle hændelsesopdatering.

1. 15. marts 2025 kl. 17.56 UTCresolved

   Nogle fil uploads ikke udfylde på grund af en server klynge problem. Årsagen undersøges. Spørgsmålet vedrører et lille antal konti. Hvis din fil upload mislykkes, skal du vente, indtil dette problem er blevet løst.

2. 16. marts 2025 kl. 08.40 UTCidentified

   Dette spørgsmål er stadig i gang. Årsagen til spørgsmålet er blevet identificeret, og vi arbejder på at løse det så hurtigt som muligt.

3. 16. marts 2025 kl. 15.25 UTCresolved

   Spørgsmålet er løst. Problemet skyldtes to servere i en klynge, der fejlede samtidig. Dette påvirkede upload af nye filer til omkring 20% af Sirv konti. Uploads er designet til at fortsætte som normalt, når en server er nede, men når to servere er nede, nogle uploads kan mislykkes, hvilket er, hvad der skete. De mislykkedes på grund af en eksportør service, der stoppede med at køre på en server, så den anden server. Fejl forhindrede tjenesterne i at genstarte. Så et andet spørgsmål fik beslutningen til at tage meget længere tid end forventet, fordi serverne ikke kunne genstartes. Dette skyldtes en forældet BIOS. Når BIOS var blevet opdateret, serverne blev genstartet og årsagen til den underliggende problem blev løst. For at forhindre dette i at ske igen, har vi gennemført en ny BIOS management proces med vores datacenter. Vi er også afkorte vores hardware refresh cyklus, for hyppigere hardware opgraderinger. For at reducere risikoen for eksportør service fiasko fra tilbagevendende, vi har deaktiveret en proces og overvåger serveren målinger.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 26. februar 2025 kl. 09.29 UTCinvestigating

   I en 3 minutters periode mellem 09: 29 og 09: 32 UTC blev nogle anmodninger ikke returneret. Dette spørgsmål vedrørte kun visse anmodninger og kun visse regnskaber. De fleste konti var uberørte.

2. 26. februar 2025 kl. 09.32 UTCresolved

   Spørgsmålet blev løst inden for 3 minutter. Årsagen var genstart af flere servere på samme tid, mens kun 1 server skulle have været genstartet. Det var en forglemmelse i vores standardprocedurer. Vi undersøger, hvordan vi automatisk beskytter og forhindrer dette i at gentage sig.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 19. december 2024 kl. 14.20 UTCresolved

   En server fejl får nogle fil uploads til at mislykkes for et begrænset antal konti. Spørgsmålet er ved at blive løst. Hvis du oplever fejlslagne uploads, bedes du stoppe og prøve igen senere.

2. 19. december 2024 kl. 18.09 UTCresolved

   Spørgsmålet er løst. Et usædvanligt stort antal servere mislykkedes på samme tid. Sirv er designet til at fortsætte normal drift under en server afbrydelse og alle systemer fortsatte som normalt, men nogle fil uploads mislykkedes. Vi overvejer, hvilke mulige ændringer der kan foretages for at hjælpe i sådanne situationer i fremtiden.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 14. november 2024 kl. 09.52 UTCinvestigating

   Et forhøjet antal 504 timeouts bliver returneret til API-fil upload anmodninger.

2. 14. november 2024 kl. 13.19 UTCinvestigating

   Der fortsætter med at være tung belastning på API fra upload anmodninger. En medvirkende faktor er det store antal AI-billede opskalering anmodninger, som tager længere tid end normalt at behandle. Forsinkelsen forårsaget af kø af anmodninger forårsager nogle API-fil upload anmodninger til at mislykkes med en 504 svar.

3. 14. november 2024 kl. 15.23 UTCresolved

   Der er sket ændringer, og spørgsmålet er næsten løst. Størstedelen af uploadanmodningerne er vellykkede.

4. 14. november 2024 kl. 19.06 UTCresolved

   API upload overbelastning er næsten helt løst.

5. 15. november 2024 kl. 04.42 UTCresolved

   Spørgsmålet er helt løst. Problemet startede, når tunge billede opskalering API anmodninger overbelastet upload API, forårsager nogle API anmodninger om at returnere 504 fejl. Dette blev løst, men en knock- on effekt forårsaget omkring 5% af API anmodninger om at mislykkes med en 502 svar. For at forhindre dette problem i at ske igen, er der foretaget forbedringer for at reducere belastningen af billedet opskalering og bedre distribuere belastning. Der foretages også ændringer i logning og alarmering for hurtigere at identificere sådanne scenarier. Den største indvirkning af dette spørgsmål var på Sirv WordPress plugin. plugin var at sende en API anmodning på alle admin sider, som blokerede siden fra indlæsning indtil svaret var modtaget - typisk mindre end 300ms, men op til 20 sekunder, hvis API anmodninger timet ud. Disse API anmodninger var ikke påkrævet, så en ny WordPress plugin version v7.3.3 blev udgivet på 1805 UTC (14 November) at fjerne sådanne anmodninger og forhindre dette problem fra tilbagevendende: https: / / wordpress.org / plugins / sirv / ľ-- Hvis du bruger Sirv API, anbefaler vi, at dine scripts er skrevet for at prøve igen anmodninger, der modtager en 502 svar. Anbefalinger til håndtering af 502 og andre fejlsvar findes her: https: / / sirv.com / help / artikler / sirv- rest- api / # error- handling- guide

Automatisk oversat fra den officielle hændelsesopdatering.

1. 22. februar 2024 kl. 10.52 UTCinvestigating

   Nogle filer bliver ikke returneret til et lille antal konti. Dette spørgsmål behandles omgående.

2. 22. februar 2024 kl. 12.06 UTCresolved

   Spørgsmålet er løst. Ved 1052 UTC returnerede omkring 11% af anmodningerne til et lille antal konti (12 konti ud af 50.000 +) 404 svar (fil ikke fundet), når de skulle have returneret 200 svar (OK). Da Sirv-holdet identificerede problemet, arbejdede de hurtigt på at løse det, og ved 1206 UTC returnerede alle sådanne anmodninger det normale 200 svar. Problemet opstod på grund af en forkert konfiguration af Sirv ingeniører, mens de var ved at konfigurere en ny opbevaring klynge skår. Nogle anmodninger var på vej til den nye skaft, før det var klar til at modtage dem. Klassificeret som sværhedsgrad 3: Mindre sammenstød.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 5. januar 2024 kl. 20.21 UTCinvestigating

   Et stort antal anmodninger til Sirvs 25 CDN-steder returnerer en fejl. Vores ingeniører arbejder hurtigt på at identificere og løse problemet.

2. 5. januar 2024 kl. 21.07 UTCresolved

   Spørgsmålet er løst. Det var forårsaget af svigt af en software dæmon samtidigt på flere servere. Dette er en letvægts og meget effektiv service manager, der aldrig har svigtet i fortiden. I perioden, mellem 3% og 58% af HTTPS anmodninger returnerede en fejl, afhængigt af hvilken af de 25 CDN steder modtog anmodningen. Vi undersøger nu, hvorfor dette skete, og vil træffe foranstaltninger for at forhindre, at dette påvirker tjenestens tilgængelighed i fremtiden. Klassificeret som sværhedsgrad niveau 2: Betydelig indvirkning.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 5. december 2023 kl. 15.03 UTCinvestigating

   Der forekommer et forhøjet niveau på 415 fejl på CDN. Vores ingeniører undersøger sagen.

2. 5. december 2023 kl. 18.32 UTCinvestigating

   Vi undersøger fortsat årsagen til dette spørgsmål. Arten af det er kompleks. Det repræsenterer sig selv som en 415 fejl, fra filer af nul bytes. Der er også en forhøjet men lavere sats på 500 fejl. Størstedelen af anmodningerne er vellykkede 200 svar. Vores ingeniører arbejder hårdt på at forstå og løse dette.

3. 5. december 2023 kl. 22.56 UTCresolved

   415 fejl problem var forårsaget af nogle filer bliver afkortet, hvilket betyder, at de mistede en del af deres indhold. Disse filer viser i kontrolpanelet på my.sirv.com at have 0 bytes. Filer uploadet i dag var mere tilbøjelige til at blive trunkeret, selvom det ser ud til, at trunkation har været sker til filer i lang tid. Dette blev ikke identificeret, fordi de udføres helt som normalt, på grund af caching af ikke-trunkerede versioner. Den trunkerede fil problem kun blev mærkbar i dag, efter en opgradering af infrastrukturen. Server caches blev ryddet og de trunkerede versioner blev synlige. Årsagen til trunkation menes at have været en software fejl, der nu er blevet løst. Vi arbejder i øjeblikket på at gendanne trunkerede filer - en proces, der kan tage fra timer til dage. Hvis du er i stand til at genuploade filer, der ikke i øjeblikket indlæses, bedes du gøre det nu. Spørgsmålet skønnes at påvirke omkring ~ 0,2% af filerne.

4. 5. december 2023 kl. 23.33 UTCresolved

   Cirka 80% af afkortede filer er blevet inddrevet. Antallet af 415 fejl er faldet betydeligt, selv om de forbliver forhøjet. For fuldt ud at løse problemet, skal de resterende afkortede filer erstattes med den oprindelige fil. Vi arbejder på måder at inddrive de resterende filer, selv om de er svære at få, og det kan tage timer eller dage. For den hurtigst mulige opløsning, anbefales det, at du re- uploade filerne. Sådanne filer vil vise på din konto som at have 0 bytes. Start på følgende URL, for at se en liste over alle filer uploadet inden for de sidste 30 dage: https: / / my.sirv.com / # / search /? oprettet = 30d Find nogen nul byte filer ved at sortere resultaterne efter Størrelse, Ascending. En anden opdatering vil blive lagt her, når vi har nyheder om de resterende filer.

5. 6. december 2023 kl. 01.48 UTCinvestigating

   Vi fortsætter med at inddrive det lille antal resterende afkortede filer. Dette skønnes at kræve yderligere 12- 24 timer. Hvis du har nogen filer, der ikke bliver serveret, kan du løse dette med det samme ved at genuploade dem. Vi skaber et værktøj til at generere en liste over nul byte filer. Hvis du vil have en liste over nulbyte-filer på din konto, bedes du indsende en anmodning på https: / / sirv.com / help / support / # support, og vi vil udarbejde en liste, når værktøjet er klar. Uanset, vil vi fortsætte arbejdet med at gendanne alle filer. Hvis du uploader filer ved hjælp af Sirv 's Autohentning funktion, kan du blot slette nul byte filer, og de vil blive hentet igen fra din eksterne placering på den næste anmodning.

6. 6. december 2023 kl. 12.12 UTCresolved

   Flere filer er blevet genoprettet. Antallet af 415 fejl falder fortsat. Du kan se en liste over 415 fejl på denne side af din konto: https: / / my.sirv.com / # / analytics / fejl / 415? fra = 20231206 & til = 20231206 Du kan uploade filer til at løse 415 fejl i dine filer. Vi kan give en liste over nul byte filer, hvis du har brug for - spørg venligst Sirv support team via denne formular: https: / / sirv.com / help / support / # support Vi fortsætter med at gendanne så mange filer som muligt.

7. 6. december 2023 kl. 19.47 UTCresolved

   Det problem, der forårsagede den forhøjede sats på 415 fejl er blevet løst. De trunkerede filer var forårsaget af et softwareproblem, der skrev nogle filer med nul bytes. Da det var software, dette forårsagede den trunkerede filer til at blive kopieret på tværs af alle versioner af masterfilen. Sirv triplicerer hver fil til at beskytte mod hardware problemer (server eller harddisk fejl), men de opdaterede filer bestået alle kontroller og trofast tripliceret filerne. Det eksisterede uden detektion, fordi cached versioner af filerne blev brugt til behandling og levering. Alle systemer fungerede perfekt, indtil gårsdagens infrastruktur opgradering, når cached filer blev ryddet. Den grundlæggende årsag blev løst ved at identificere og korrigere software problem, der forårsagede trunkation. Dette blev afsluttet med 1500 UTC den 5. december. Så opgaven var at gendanne de filer, der var blevet afkortet. På tværs af platformen, var omkring 0,2% af filerne blevet påvirket. Af disse filer, var vi i stand til at genoprette mellem 95% og 100%, afhængigt af kontoen. Enhver konto, der havde mindre end 100% restaurering bliver sendt en liste over zero-byte filer, der bør gendannes ved at uploade filerne igen. Vær opmærksom på vores e-mail med en liste over filer. Besked os venligst via følgende URL, hvis du har brug for hjælp: https: / / sirv.com / help / support / # support En grundig undersøgelse af spørgsmålet er i gang, som vil blive rapporteret i detaljer via e-mail. I betænkningen vil der blive taget en liste over foranstaltninger, der skal forhindre en eventuel gentagelse af dette spørgsmål, samt forbedringer og nye elementer, der allerede er under udarbejdelse. Vi undskylder over for alle kunder, der blev påvirket af dette spørgsmål. Det er første gang, master data er gået tabt. Vi vil lære alt af det og gøre Sirv endnu stærkere og pålidelig end før.

8. 21. december 2023 kl. 10.05 UTCresolved

   Mere end 99% af de resterende afkortede filer er nu også blevet genoprettet. Enhver påvirket bruger har fået en nøjagtig liste over filer, der blev påvirket. Der er ingen resterende virkning tilbage af dette spørgsmål. Klassificeret som sværhedsgrad niveau 1: Kritisk indvirkning.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 2. december 2023 kl. 04.19 UTCinvestigating

   Fra 0419 UTC blev et forhøjet niveau af 429 fejl returneret fra Sydney CDN placering.

2. 2. december 2023 kl. 10.31 UTCresolved

   Spørgsmålet blev løst på 1031 UTC. Årsagen var en server forkert konfiguration, som gjorde Sydney CDN placering se alle anmodninger kommer fra den samme IP-adresse, i stedet for den sande klient IP-adresse. Dette udløste DDOS-beskyttelse for at begrænse det alt for store antal anmodninger fra samme IP. 429 svar blev returneret for mange af anmodningerne. Spørgsmålet syntes at have været et meget kort spørgsmål, når Sydney datacenter netværk blev utilgængelige. Det varede kun ca. 1 minut. Men den faktiske hændelse begyndte umiddelbart efter vores hold havde genoprettet Sydney CDN placering, hvilket er, når serveren fejlkonfiguration blev anvendt. Problemet blev løst, da vi opdagede fejlkonfigurationen og rettede den. Der træffes flere foranstaltninger for at forhindre, at dette problem gentager sig, og for at mindske virkningen af lignende, men forskellige spørgsmål i fremtiden: - Yderligere overvågning og varsling - Nyt nummer - Context sensitive resolution address Kun Sydney CDN 's position blev påvirket. Klassificeret som sværhedsgrad 3: Mindre sammenstød.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 22. november 2023 kl. 18.30 UTCinvestigating

   På omkring 1830 UTC den 22. november, begyndte vi en opgradering til den primære fil database til en ny, mere kraftfuld klynge. Mens opgraderingen fandt sted, API søgning forespørgsler mislykkedes.

2. 23. november 2023 kl. 10.35 UTCresolved

   På 1035 UTC den 23. november, opgraderingen var komplet og søgninger genoptaget normal drift. Der var ingen nedetid og alle systemer fungerede som normalt, bortset fra, at API søgning anmodninger havde været at returnere fejlsvar. Problemet blev ikke identificeret, fordi andre API-anmodninger blev returneret som normalt, så total API fejlsvar blev kun lidt forhøjet, og ingen advarsler blev udløst. Spørgsmålet blev identificeret efter begivenheden, efter en rapport fra en bruger foranlediget en undersøgelse. For automatisk at identificere sådanne spørgsmål i fremtiden, er vi ved at evaluere måder at overvåge søgning API specifikt. Vi vil også opdatere Sirv WordPress plugin til at vise en klar-beskrevet besked i tilfælde af en mislykket søgning. Klassificeret som sværhedsgrad 4: Minimal kollision.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. november 2023 kl. 20.47 UTCinvestigating

   Filhåndteringsværktøjerne på my.sirv.com indlæses langsomt på grund af en mislykket server. File notering og fil søgning tager fra 2 til 20 sekunder, mens det normalt tager 1 til 4 sekunder. Den fejlslagne server bliver udskiftet og vi forventer hastighed til at vende tilbage til normal inden for 72 timer. Dette vil blive efterfulgt af en større opgradering af hele kontrol panel server klyngen i løbet af de næste 3 måneder.

2. 14. november 2023 kl. 21.33 UTCinvestigating

   Vi venter på levering af en ny server til at tilføje til klyngen, så UI navigation hastighed vil blive meget hurtigere.

3. 15. november 2023 kl. 14.09 UTCresolved

   Den nye server blev indsat om aftenen den 14. november og efterhånden fyldt sine caches. Kontrolpanelet er nu vendt tilbage til sin oprindelige hurtige ydeevne. Yderligere servere opgraderes nu, så kontrolpanelet vil indlæse hurtigere stadig i løbet af de kommende 2 uger. Klassificeret som sværhedsgrad 4: Minimal kollision.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 23. oktober 2023 kl. 13.10 UTCinvestigating

   En dramatisk stigning i anmodninger til Washington DC CDN placering fandt sted på 14: 10 UTC den 23 oktober, hvilket forårsager en lille del af anmodninger til at blive returneret langsomt - større end 2 sekunder. Problemet forsvandt i løbet af de næste 3 timer, selv om den gennemsnitlige responstid forblev forhøjet. Udstedelsen returnerede den følgende dag kl 14: 32 UTC den 24. oktober, mere alvorligt end før forårsager 17% af anmodninger om at indlæse langsomt - større end 2 sekunder og nogle så længe som 30 sekunder. Spørgsmålet påvirkede to af Sirvs 25 CDN-steder.

2. 25. oktober 2023 kl. 05.48 UTCresolved

   Spørgsmålet blev løst den 25. oktober kl. 06: 48 UTC. Undersøgelse peger mod to årsager - spiken var forårsaget af Sirv 's DNS-udbyder routing Los Angeles POP anmodninger til Washington DC POP i stedet. Dette ville have været fint i isolation, men datacentret synes at have væltet båndbredden af de modtagende servere, forårsager de langsomme svar. Undersøgelsen er i gang, har ikke nået endelige konklusioner endnu og kræver samarbejde med vores DNS og datacenter udbydere. Der træffes allerede foranstaltninger til at forhindre en eventuel gentagelse af dette spørgsmål. Der vil blive fremlagt en detaljeret rapport her senere.

3. 14. november 2023 kl. 13.37 UTCresolved

   Den detaljerede undersøgelse af dette spørgsmål fandt to medvirkende faktorer. Det første var en opdatering til AWS Route53, som synes at være blevet gennemført af AWS den 17. oktober. Denne ændring blev ikke foretaget af Sirv til sine Route53 regler, men en ændring inden for Route53 service selv. Los Angeles POP havde lidt anderledes routing logik til andre POP 'er og AWS opdatering forårsaget routing til at opføre sig anderledes, med trafik bliver omdirigeret til Washington DC fallback. Dette gik ubemærket, da han højere belastning var stadig inden for sin kapacitet og anmodninger blev returneret med succes, så dette gik ubemærket som Washington DC var i stand til at håndtere den ekstra belastning. Den anden faktor var højere end normal trafik i spidsbelastningsperioder i USA den 23. og 24. oktober. De to faktorer tilsammen fik Washington DC harddiske til at returnere anmodninger betydeligt langsommere end normalt. Siden spørgsmålet opstod, har vi truffet flere foranstaltninger for at forhindre, at det gentager sig, at afbøde lignende mulige hændelser og at fremskynde afviklingstiden i tilfælde af en hændelse. Aktioner omfatter: - Ny routing logik er blevet anvendt. - Washington DC kapacitet er blevet øget. - Reservekapaciteten er øget i alle andre CDN-steder. - Ny tolerance indført for en CDN placering, der skal fjernes fra routing. - Yderligere disk overvågning, at hjælpe tidlig forberedelse af kapacitetsopgraderinger. - HDD 'er bliver erstattet med SSD' er. - Opdateret SOP til vores support team til at undersøge og reagere på lignende spørgsmål. Klassificeret som sværhedsgrad 3: Mindre sammenstød.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 22. maj 2023 kl. 14.57 UTCinvestigating

   Det tidligere spørgsmål om høj upload brug returneret, med et lille antal API upload fejl.

2. 22. maj 2023 kl. 15.06 UTCresolved

   Problemet løst sig selv inden for 9 minutter, når upload volumen normaliseret. I perioden lykkedes det ca. 98% af uploads, og 2% mislykkedes. REST API uploads er begrænset pr. time, til det beløb, der er angivet på brugersiden på din Sirv-konto https: / / my.sirv.com / # / account / use. Hvis du bruger REST API til at uploade billeder, bedste praksis er at kontrollere svaret for hver upload anmodning, og hvis du modtager en fejl svar (400, 401, 429 osv.) derefter pause uploads og prøve igen senere. Se docs her: https: / / sirv.com / help / artikler / sirv- rest- api / # error- handling- guide Klassificeret som sværhedsgrad 4: Minimal kollision.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 22. maj 2023 kl. 11.31 UTCinvestigating

   Et lille antal REST API upload anmodninger er svigtende på grund af meget høj belastning.

2. 22. maj 2023 kl. 12.37 UTCresolved

   Dette problem løst sig selv, når belastningen på upload API begyndte at falde. I perioden lykkedes det ca. 97% af uploads, og 3% mislykkedes. REST API uploads er begrænset pr. time, til det beløb, der er angivet på brugersiden på din Sirv-konto https: / / my.sirv.com / # / account / use. Hvis du bruger REST API til at uploade billeder, bedste praksis er at kontrollere svaret for hver upload anmodning, og hvis du modtager en fejl svar (400, 401, 429 osv.) derefter pause uploads og prøve igen senere. Se docs her: https: / / sirv.com / help / artikler / sirv- rest- api / # error- handling- guide Klassificeret som sværhedsgrad 4: Minimal kollision.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 27. april 2023 kl. 23.00 UTCinvestigating

   En af Los Angeles CDN servere blev usunde og begyndte at returnere 4xx fejl på 0000 UTC. Det blev fjernet fra routing efter 90 sekunder og inden for yderligere 60 sekunder, al trafik blev omdirigeret til sunde servere.

2. 27. april 2023 kl. 23.03 UTCresolved

   Spørgsmålet blev automatisk løst inden for 3 minutter. Klassificeret som sværhedsgrad 4: Minimal kollision.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 16. marts 2023 kl. 12.17 UTCinvestigating

   Nogle anmodninger til London POP af Sirv CDN, er at returnere fejl på grund af høj belastning. Denne POP tjener Storbritannien og Irland. Vi arbejder på en beslutning.

2. 16. marts 2023 kl. 13.33 UTCresolved

   Spørgsmålet er blevet løst og overvåges nu.

3. 16. marts 2023 kl. 16.22 UTCresolved

   Nogle anmodninger modtaget af en af London CDN servere mislykkedes på grund af en kombination af lokale DNS opløsning og pulserende netværk timeouts. Spørgsmålet begyndte på 1215 UTC og blev løst på 1332 UTC. I denne periode returnerede 25% af anmodningerne fra Det Forenede Kongerige og Irland en fejl på 404 eller 500. Spørgsmålet ville have været løst tidligere, men en ikke-relateret SSL certifikat validering fiasko et par timer tidligere blokeret advarsler fra at blive modtaget af vores overvågningssystem. Der er allerede foretaget ændringer for at forhindre, at dette problem gentager sig. SSL-certifikatudstedelsen er blevet løst; et andet niveau af uafhængig overvågning er blevet konfigureret; en yderligere sundhedsautomatisering er ved at blive afprøvet, der har potentiale til at løse sådanne problemer automatisk. Klassificeret som sværhedsgrad 3: Mindre sammenstød.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 23. februar 2023 kl. 07.55 UTCresolved

   Spørgsmålet blev løst på 0755 UTC. På 0625 UTC, nogle anmodninger til Indore CDN POP, som tjener Indien begyndte at returnere en 404 svar (fil ikke fundet), i stedet for en 200 svar (OK). Problemet opstod 14 timer efter en opdatering til alle CDN servere på verdensplan. Alle POP 'er opførte sig sundt, herunder Indien POP men Induore POP havde ikke opdateret med succes og i sidste ende begyndte at returnere fejl. Når spørgsmålet var blevet identificeret, blev det løst ved at gen- implementere opdateringen til Indien POP. Under hændelsen returnerede 94% af anmodningerne en fejl. Anmodninger til alle andre lande blev returneret som normalt. For at forhindre, at dette problem gentager sig, oprettes der en ny automatiseret implementeringsregel for en del af implementeringsprocessen, hvor der kun har været en menneskelig kontrol. Der er også ved at blive oprettet en supplerende alarmmåler for at identificere en situation, hvor en deployering er mislykkedes. Vi undskylder over for alle kunder, der blev påvirket af denne hændelse, og vi er i færd med at evaluere andre ændringer, der kan hjælpe med at forhindre enhver mulig gentagelse af problemet. Hvis et CDN problem som dette opstår, en umiddelbar løsning inden for din kontrol er at deaktivere CDN midlertidigt i dine Sirv indstillinger her: https: / / my.sirv.com / # / account / settings / domænes Klassificeret som sværhedsgrad niveau 2: Betydelig indvirkning.

Automatisk oversat fra den officielle hændelsesopdatering.