Istoricul incidentelor Sirv

1. 6 august 2026 la 10:17 UTCinvestigating

   Încărcările în unele conturi Sirv cedează, din cauza unei probleme cu serverul. Acest lucru poate împiedica, de asemenea, afișarea ocazională a imaginilor. Ne străduim să rezolvăm problema cât mai curând posibil.

2. 6 august 2026 la 15:22 UTCresolved

   Cauza problemei a fost identificată și a fost rezolvată pe deplin. În timpul perioadei, aproximativ 25% din conturile Sirv ar fi putut avea un procent de upload-uri de fișiere care au eșuat. Retrieding upload-uri un scurt timp mai târziu s-ar putea să fi avut succes, deoarece acest lucru a fost doar un impact un număr mic de cereri. În prezent are loc o revizuire şi vor fi furnizate informaţii suplimentare mai târziu.

Traducere automată din actualizarea oficială a incidentului.

1. 27 iunie 2026 la 18:34 UTCmonitoring

   Un număr mic de upload-uri și cereri se întorc erori din cauza multiple eșecuri de rețea în centrul de date primar al lui Sirv. Cererile de CDN funcţionează normal. Monitorizăm îndeaproape situația și vom furniza actualizări pe măsură ce devin disponibile mai multe informații.

2. 27 iunie 2026 la 19:37 UTCresolved

   Toate serviciile au revenit la normal şi cererile se completează.

3. 28 iunie 2026 la 09:03 UTCresolved

   Această problemă a fost cauzată de o eroare a routerului principal care afectează centrul de date primar al lui Sirv. Acest lucru a cauzat întreruperi scurte, intermitente pe stocare fișiere și upload-uri, peste toate tipurile de transfer: API, S3 și FTP. Sirv a trecut automat la serviciul de eșuare, astfel încât procesarea fișierelor și livrarea au continuat ca de obicei. Cererile de CDN au continuat, de asemenea, ca normal. Toate serviciile au fost restaurate odată ce centrul de date a rezolvat pana de router.

Traducere automată din actualizarea oficială a incidentului.

1. 30 ianuarie 2026 la 12:46 UTCinvestigating

   Timpul de răspuns pentru unele cereri în Germania sunt mai lent decât în mod normal și un număr mic sunt calendarul afară. Problema este investigată.

2. 30 ianuarie 2026 la 14:28 UTCresolved

   Problema a fost rezolvată. Unul dintre serverele care serveau Germania a fost supraîncărcat şi a răspuns mai încet decât de obicei. Serverul este din nou sănătos. Reexaminăm măsurile pe care trebuie să le întreprindem pentru a reduce şansele ca acest lucru să se întâmple din nou.

Traducere automată din actualizarea oficială a incidentului.

1. 31 martie 2025 la 14:32 UTCinvestigating

   Unele cereri din California sunt lente şi un număr mic (sub 2%) cedează. Acest lucru este investigat și probabil legat de noi servere CDN care au fost desfășurate astăzi în Los Angeles.

2. 31 martie 2025 la 15:16 UTCresolved

   Problema a fost rezolvată. Problema a fost cauzată de pierderea pachetelor care afectează noul nostru centru de date din Los Angeles. Centrul de date a urmărit problema la furnizorul lor din amonte, Arelion, care se confrunta cu instabilitatea rețelei. Problema a fost rezolvată atunci când Arelion a fost temporar dezactivat ca furnizor în amonte, iar traficul a fost redirecționat prin alți furnizori. Solicităm ca centrele noastre de date să identifice şi să redirecţioneze traficul automat şi rapid în astfel de scenarii. Cu toate acestea, soluţionarea acestei probleme nu a fost suficient de rapidă şi având în vedere că aceasta a avut loc la scurt timp după adoptarea acestui nou centru de date, am decis să încetăm utilizarea acestuia. Toate traficul este acum rutat de la centrul de date original din Los Angeles (din 7 aprilie 2025).

Traducere automată din actualizarea oficială a incidentului.

1. 15 martie 2025 la 17:56 UTCresolved

   Unele upload-uri de fișiere nu se completează din cauza unui cluster de server. Cauza este investigată. Problema afectează un număr mic de conturi. În cazul în care fișierul dvs. de încărcare nu reușește, vă rugăm să așteptați până când această problemă a fost rezolvată.

2. 16 martie 2025 la 08:40 UTCidentified

   Această problemă rămâne în curs de desfășurare. Cauza problemei a fost identificată și încercăm să o rezolvăm cât mai curând posibil.

3. 16 martie 2025 la 15:25 UTCresolved

   Problema a fost rezolvată. Problema a fost cauzată de două servere dintr-un singur grup care cedează simultan. Acest lucru a afectat încărcarea de fișiere noi la aproximativ 20% din conturile Sirv. Încărcările sunt concepute pentru a continua ca normal atunci când un server este în jos, dar atunci când două servere sunt în jos, unele upload-uri pot eșua, care este ceea ce sa întâmplat. Au eșuat din cauza unui serviciu de exportator care a încetat să mai funcționeze pe un server, apoi pe celălalt server. Erorile au împiedicat repornirea serviciilor. Apoi, o a doua problemă a determinat rezoluția să ia mult mai mult decât se aștepta deoarece serverele nu au putut fi repornite. Acest lucru s-a datorat unui BIOS învechit. Odată ce BIOS a fost actualizat, serverele au fost repornite și cauza problemei subiacente a fost rezolvată. Pentru a preveni acest lucru, am implementat un nou proces de management BIOS cu centrul nostru de date. De asemenea, scurtăm ciclul nostru de reîmprospătare hardware, pentru upgrade-uri hardware mai frecvente. Pentru a reduce şansele de eşec a serviciului exportator de la recurente, am dezactivat un proces şi monitorizăm indicatorii serverului.

Traducere automată din actualizarea oficială a incidentului.

1. 26 februarie 2025 la 09:29 UTCinvestigating

   Pentru o perioadă de 3 minute între 09:29 și 09:32 UTC, unele cereri nu au fost returnate. Acest aspect a afectat doar anumite cereri și numai anumite conturi. Majoritatea conturilor nu au fost afectate.

2. 26 februarie 2025 la 09:32 UTCresolved

   Problema a fost rezolvată în 3 minute. Cauza a fost repornirea mai multor servere în același timp, în timp ce doar 1 server ar fi trebuit repornit. Aceasta a fost o supraveghere în procedurile noastre standard de operare. Investigăm modalități de a proteja automat și de a preveni repetarea acestui lucru.

Traducere automată din actualizarea oficială a incidentului.

1. 19 decembrie 2024 la 14:20 UTCresolved

   O eroare de server este cauza unor upload-uri de fișiere pentru a eșua pentru un număr limitat de conturi. Problema este rezolvată. Dacă experimentați upload-uri eșuate, vă rugăm să pauză și să încercați din nou mai târziu.

2. 19 decembrie 2024 la 18:09 UTCresolved

   Problema a fost rezolvată. Un număr neobişnuit de mare de servere au eşuat în acelaşi timp. Sirv este proiectat pentru a continua funcționarea normală în timpul unei întreruperi a serverului și toate sistemele au continuat ca de obicei, dar unele upload-uri de fișiere au eșuat. Ne gândim la ce schimbări posibile s-ar putea face pentru a ajuta în astfel de situații în viitor.

Traducere automată din actualizarea oficială a incidentului.

1. 14 noiembrie 2024 la 09:52 UTCinvestigating

   Un număr ridicat de 504 timeout-uri sunt returnate pentru API fișiere upload cereri.

2. 14 noiembrie 2024 la 13:19 UTCinvestigating

   Există în continuare sarcini grele pe API de la cereri de încărcare. Un factor care contribuie este numărul mare de cereri AI de sporire a imaginii, care durează mai mult decât de obicei pentru a procesa. Întârzierea cauzată de coada de cereri este cauza unor cereri de upload de fișiere API pentru a eșua cu un răspuns 504.

3. 14 noiembrie 2024 la 15:23 UTCresolved

   S-au făcut schimbări şi problema este aproape rezolvată. Majoritatea cererilor de încărcare sunt de succes.

4. 14 noiembrie 2024 la 19:06 UTCresolved

   Supraîncărcarea API este aproape complet rezolvată.

5. 15 noiembrie 2024 la 04:42 UTCresolved

   Problema a fost rezolvată pe deplin. Problema a început atunci când imagini grele upscaling API solicită supraîncărcat API încărcat, provocând unele cereri API pentru a reveni 504 erori. Acest lucru a fost rezolvat, dar un efect knock-on a cauzat aproximativ 5% din cererile API de a eșua cu un răspuns 502. Pentru a preveni această problemă să se repete, s-au făcut îmbunătățiri pentru a reduce sarcina de creștere a imaginii și pentru a distribui mai bine încărcătura. De asemenea, se fac modificări în ceea ce privește logarea și alertarea, pentru identificarea mai rapidă a unor astfel de scenarii. Cel mai mare impact al acestei probleme a fost asupra plugin-ului Sirv WordPress. Modul a fost trimiterea unei cereri API pe toate paginile admin, care blocat pagina de la încărcare până când răspunsul a fost primit - de obicei mai puțin de 300ms, dar până la 20 de secunde în cazul în care API solicită temporizat. Aceste cereri API nu au fost necesare, astfel încât o nouă versiune WordPress plugin v7.3.3 a fost lansat la 1805 UTC (14 noiembrie) pentru a elimina astfel de cereri și a preveni această problemă de la recurente: https://wordpress.org/plugins/sirv/ ------ Dacă utilizați API Sirv, vă recomandăm că scripturile sunt scrise pentru a rejudeca cererile care primesc un răspuns 502. A se vedea, de asemenea, cauza C-364/04, Rec., 2002, p

Traducere automată din actualizarea oficială a incidentului.

1. 22 februarie 2024 la 10:52 UTCinvestigating

   Unele dosare nu sunt returnate pentru un număr mic de conturi. Această problemă este abordată urgent.

2. 22 februarie 2024 la 12:06 UTCresolved

   Problema a fost rezolvată. La 1052 UTC, aproximativ 11% din cererile către un număr mic de conturi (12 conturi, din 50.000+) au răspuns la 404 răspunsuri (fişierul nu a fost găsit) atunci când ar fi trebuit să returneze 200 de răspunsuri (OK). Când echipa Sirv a identificat problema, au lucrat rapid pentru a o rezolva şi până la 1206 UTC toate aceste cereri au returnat răspunsul normal 200. Problema a avut loc din cauza unei configuraţii greşite a inginerilor Sirv în timp ce configurau un nou ciob de stocare. Unele cereri mergeau la noul ciob înainte de a fi gata să le primească. Clasificat ca nivel de severitate 3: impact minor.

Traducere automată din actualizarea oficială a incidentului.

1. 5 ianuarie 2024 la 20:21 UTCinvestigating

   Un număr mare de cereri în cele 25 de locaţii ale lui Sirv se întorc o eroare. Inginerii noştri lucrează rapid pentru a identifica şi rezolva problema.

2. 5 ianuarie 2024 la 21:07 UTCresolved

   Problema a fost rezolvată. Acesta a fost cauzat de eșecul unui demon software simultan pe mai multe servere. Acesta este un manager de servicii ușor și foarte eficient care nu a eșuat niciodată în trecut. Pe parcursul perioadei, între 3% și 58% din cererile HTTPS au returnat o eroare, în funcție de care dintre cele 25 de locații CDN au primit cererea. Acum investigăm de ce s-a întâmplat acest lucru și vom lua măsuri pentru a preveni ca acest lucru să afecteze disponibilitatea serviciilor în viitor. Clasificat ca nivel de severitate 2: impact semnificativ.

Traducere automată din actualizarea oficială a incidentului.

1. 5 decembrie 2023 la 15:03 UTCinvestigating

   Pe CDN apare un nivel ridicat de 415 erori. Inginerii noştri investighează cauza.

2. 5 decembrie 2023 la 18:32 UTCinvestigating

   Continuăm să investigăm cauza acestei probleme. Natura ei este complexă. Se reprezintă ca o eroare 415, din fișierele de zero octeți. Există, de asemenea, o rată ridicată, deși mai mică de 500 de erori. Majoritatea cererilor au reuşit 200 de răspunsuri. Inginerii noştri muncesc din greu să înţeleagă şi să rezolve asta.

3. 5 decembrie 2023 la 22:56 UTCresolved

   Problema de eroare 415 a fost cauzată de unele fișiere care au fost trunchiate, ceea ce înseamnă că au pierdut o parte din conținutul lor. Aceste fișiere arată în panoul de control de la mea.sirv.com ca având 0 bytes. Fişierele încărcate astăzi au fost mai probabil să devină trunchiate, deşi se pare că truncation se întâmplă la fişiere de mult timp. Acest lucru nu a fost identificat deoarece au efectuat în întregime ca normal, din cauza caching de versiuni non-truncate. Problema cu fişierul trunchiat a devenit vizibilă doar astăzi, după o actualizare a infrastructurii. Caches server au fost eliminate și versiunile trunchiate au devenit evidente. Cauza truncation este considerat a fi un bug software care a fost acum rezolvat. În prezent, lucrăm la restabilirea fișierelor trunchiate - un proces care poate dura de la ore la zile. Dacă sunteți în măsură să reîncărcați orice fișiere care nu sunt în prezent de încărcare, vă rugăm să faceți acest lucru acum. Se estimează că problema afectează aproximativ ~0,2% din dosare.

4. 5 decembrie 2023 la 23:33 UTCresolved

   Aproximativ 80% din fișierele trunchiate au fost recuperate. Numărul de 415 de erori a scăzut semnificativ, deși acestea rămân ridicate. Pentru a rezolva complet problema, fișierele trunchiate rămase trebuie înlocuite cu fișierul original. Lucrăm la modalități de a recupera acele fișiere rămase, deși sunt greu de obținut și poate dura ore sau zile. Pentru cea mai rapidă rezoluție posibilă, este recomandat să reîncărcați fișierele. Astfel de fișiere vor arăta în contul dvs. ca având 0 octeți. Începeți de la următorul URL, pentru a vedea o listă cu toate fișierele încărcate în ultimele 30 de zile: https://my.sirv.com/#/search/?created=30d Găsiți orice fișiere octet zero prin sortarea rezultatelor după Dimensiune, Ascending. O altă actualizare va fi postat aici odată ce avem știri despre fișierele rămase.

5. 6 decembrie 2023 la 01:48 UTCinvestigating

   Continuăm să recuperăm numărul mic de dosare trunchiate rămase. Se estimează că acest lucru necesită încă 12-24 de ore. Dacă aveți orice fișiere care nu sunt servite, puteți rezolva acest lucru imediat prin reîncărcarea lor. Suntem crearea unui instrument pentru a genera o listă de fișiere octet zero. Dacă doriți o listă cu fișiere octet zero în contul dvs., vă rugăm să trimiteți o cerere la https://sirv.com/help/support/#support și vom pregăti o listă odată ce instrumentul este gata. Indiferent, vom continua să lucrăm pentru a recupera toate fișierele. Dacă încărcați fișiere folosind funcția de Autofetch a lui Sirv, puteți șterge pur și simplu fișierele de octet zero și acestea vor fi re-ieșite din locație la următoarea cerere.

6. 6 decembrie 2023 la 12:12 UTCresolved

   Mai multe dosare au fost restaurate. Rata de 415 erori continuă să scadă. Puteți vedea o listă de 415 erori pe această pagină a contului dvs.: https://my.sirv.com/#/analytics/errors/415?de la=20231206&to=20231206 Puteți încărca fișiere pentru a rezolva orice 415 erori în fișierele dumneavoastră. Putem oferi o listă de fișiere octet zero dacă aveți nevoie - vă rugăm să întrebați echipa de suport Sirv prin intermediul acestui formular: https://sirv.com/help/support/#support Continuăm să restaurăm cât mai multe fișiere posibil.

7. 6 decembrie 2023 la 19:47 UTCresolved

   Problema care a cauzat rata ridicată de 415 erori a fost rezolvată. Fişierele trunchiate au fost cauzate de o problemă de software care a scris unele fişiere cu zero bytes. Așa cum a fost software-ul, acest lucru a cauzat fișierele trunchiate să fie replicate în toate versiunile de fișier master. Sirv triplează fiecare fișier pentru a proteja împotriva problemelor hardware (server sau eșecuri de hard disk), totuși, fișierele actualizate au trecut toate verificările și au triplat cu fidelitate fișierele. Ea a existat fără detectare deoarece versiunile cache ale fișierelor au fost utilizate pentru prelucrare și livrare. Toate sistemele au funcţionat perfect, până ieri când au fost eliminate fişierele. Cauza principală a fost rezolvată prin identificarea și corectarea problemei software-ului care a cauzat Truncation. Acest lucru a fost finalizat de 1500 UTC la 5 decembrie. Apoi, sarcina a fost de a restabili acele fișiere care au fost trunchiate. De-a lungul platformei, aproximativ 0,2% din fișiere au fost afectate. Dintre aceste fișiere, am reușit să restabilim între 95% și 100%, în funcție de cont. Orice cont care a avut mai puțin de 100% restaurare este trimis o listă de fișiere cu 0 octeți care ar trebui să fie restaurate prin încărcarea fișierelor din nou. Vă rugăm să urmăriți pentru e-mail nostru cu o listă de fișiere. Vă rugăm să ne trimiteți mesaj prin intermediul URL-ului următor dacă aveți nevoie de ajutor: https://sirv.com/help/support/#support O investigaţie aprofundată a problemei este în curs de desfăşurare, care va fi raportată în detaliu prin e-mail. În cadrul raportului va fi o listă de măsuri luate pentru a preveni orice posibilă repetare a acestei probleme, împreună cu îmbunătățiri și noi caracteristici care sunt deja în curs de elaborare. Ne cerem scuze tuturor clienţilor care au fost afectaţi de această problemă. Este prima dată când datele master a fost pierdut. Vom învăţa fiecare lecţie posibilă din ea şi îl vom face pe Sirv mai puternic şi mai de încredere decât înainte.

8. 21 decembrie 2023 la 10:05 UTCresolved

   Peste 99% din fișierele trunchiate rămase au fost, de asemenea, restaurate. Orice utilizator cu impact a fost furnizat cu o listă exactă de fișiere care au fost afectate. Nu a mai rămas niciun impact rezidual din această problemă. Clasificat ca nivel de severitate 1: impact critic.

Traducere automată din actualizarea oficială a incidentului.

1. 2 decembrie 2023 la 04:19 UTCinvestigating

   De la 0419 UTC, un nivel ridicat de 429 de erori au fost returnate din locația Sydney CDN.

2. 2 decembrie 2023 la 10:31 UTCresolved

   Problema a fost rezolvată la 1031 UTC. Cauza a fost o configuraţie greşită a serverului care a făcut locaţia Sydney CDN să vadă toate cererile provenind de la aceeaşi adresă IP, în loc de adresa IP a clientului adevărat. Aceasta a determinat protecția DDOS, pentru a limita numărul excesiv de cereri din aceeași PA. 429 de răspunsuri au fost returnate pentru multe dintre cereri. Problema părea să fi fost o problemă extrem de scurtă când reţeaua de date Sydney a devenit indisponibilă. Această problemă a durat aproximativ 1 minut. Cu toate acestea, incidentul real a început imediat după ce echipa noastră a restaurat locația Sydney CDN, care este atunci când serverul configurare greșită a fost aplicat. Problema a fost rezolvată odată ce am descoperit configuraţia greşită şi am corectat-o. Se iau mai multe măsuri pentru a preveni repetarea acestei probleme și pentru a reduce impactul unor aspecte similare, dar diferite în viitor: - Monitorizarea suplimentară și alertarea - Formular nou de prezentare a emisiunii - Consultanţă de rezoluţie sensibilă la context - Alertă internă mai largă Doar locaţia Sydney CDN a fost afectată. Clasificat ca nivel de severitate 3: impact minor.

Traducere automată din actualizarea oficială a incidentului.

1. 22 noiembrie 2023 la 18:30 UTCinvestigating

   La aproximativ 1830 UTC pe 22 noiembrie, am început un upgrade la baza de date de fișiere primare la un nou, mai puternic grup. În timp ce upgrade-ul a avut loc, API întrebări de căutare au fost eșec.

2. 23 noiembrie 2023 la 10:35 UTCresolved

   La 1035 UTC la 23 noiembrie, actualizarea a fost completă și căutările au reluat funcționarea normală. Nu a existat timp de downtime și toate sistemele au funcționat ca de obicei, cu excepția faptului că cererile de căutare API au fost returnarea răspunsurilor de eroare. Problema nu a fost identificată deoarece alte cereri API au revenit ca normale, astfel încât răspunsurile totale de eroare API au fost doar ușor ridicate și nu au fost declanșate alerte. Problema a fost identificată după eveniment, după ce un raport al unui utilizator a determinat o anchetă. Pentru a identifica automat astfel de probleme în viitor, evaluăm modalități de a monitoriza API-ul de căutare în mod specific. De asemenea, vom actualiza modulul Sirv WordPress pentru a arăta un mesaj clar descris în cazul unei căutări eșuate. Clasificat ca nivel de severitate 4: Impact minim.

Traducere automată din actualizarea oficială a incidentului.

1. 13 noiembrie 2023 la 20:47 UTCinvestigating

   Uneltele de gestionare a fișierelor de la my.sirv.com se încarcă încet din cauza unui server eșuat. Listarea fișierelor și căutarea fișierelor durează între 2 și 20 de secunde, în timp ce în mod normal durează 1-4 secunde. Serverul eşuat este înlocuit şi ne aşteptăm ca viteza să revină la normal în 72 de ore. Acest lucru va fi urmat de o actualizare majoră a întregului grup de servere de control în următoarele 3 luni.

2. 14 noiembrie 2023 la 21:33 UTCinvestigating

   Așteptăm furnizarea unui nou server pentru a adăuga la cluster, apoi viteza de navigație UI va deveni mult mai rapidă.

3. 15 noiembrie 2023 la 14:09 UTCresolved

   Noul server a fost implementat în seara de 14 noiembrie și a umplut treptat caches sale. Panoul de control a revenit acum la performanța sa inițială rapidă. Servere suplimentare sunt acum în curs de actualizare, astfel încât panoul de control va încărca mai repede încă în următoarele 2 săptămâni. Clasificat ca nivel de severitate 4: Impact minim.

Traducere automată din actualizarea oficială a incidentului.

1. 23 octombrie 2023 la 13:10 UTCinvestigating

   O creştere dramatică a cererilor către locaţia CDN Washington D.C. a avut loc la ora 14:10 UTC pe 23 octombrie, ceea ce a făcut ca o mică parte din cereri să fie returnate lent - mai mult de 2 secunde. Problema a scăzut în următoarele 3 ore, deși timpul mediu de răspuns a rămas ridicat. Problema s-a întors în ziua următoare la 14: 32 UTC la 24 octombrie, mai sever decât înainte de a provoca 17% din cereri de încărcare lentă - mai mare de 2 secunde și mai lungă de 30 de secunde. Problema a afectat două din cele 25 de locaţii ale lui Sirv.

2. 25 octombrie 2023 la 05:48 UTCresolved

   Problema a fost rezolvată până la 06:48 UTC la 25 octombrie. Punctele de anchetă spre două cauze - Spike a fost cauzată de furnizorul DNS Sirv de rutare Los Angeles POP cererile la Washington D.C. POP în schimb. Acest lucru ar fi fost bine în izolare, dar centrul de date pare să fi accelerat banda de bandă a serverelor de primire, cauzând răspunsurile lente. Ancheta este în curs de desfășurare, nu a ajuns încă la concluzii definitive și necesită colaborarea cu DNS și furnizorii noștri din centrul de date. Se iau deja măsuri pentru a preveni orice posibilă repetare a acestei chestiuni. Un raport complet detaliat va fi prezentat aici mai târziu.

3. 14 noiembrie 2023 la 13:37 UTCresolved

   Ancheta detaliată privind această chestiune a identificat doi factori care au contribuit la aceasta. Prima a fost o actualizare a AWS Route53, care pare să fi fost implementată de AWS la 17 octombrie. Această schimbare nu a fost făcută de Sirv la regulile Route53, ci la o schimbare în cadrul serviciului Route53. Los Angeles POP a avut logica de rutare ușor diferită la alte POP-uri și actualizarea AWS a cauzat rutarea să se comporte diferit, cu traficul devenind rutate la retur Washington DC. Acest lucru a trecut neobservat, deoarece încărcătura mai mare era încă în capacitatea sa și cererile au fost returnate cu succes, astfel încât acest lucru a trecut neobservat ca Washington DC a fost capabil să se ocupe de sarcina suplimentară. Al doilea factor care a contribuit a fost mai mare decât traficul normal în timpul orelor de tranzacționare ale SUA de vârf pe 23 și 24 octombrie. Cei doi factori combinaţi au determinat hard disk-urile Washington DC să returneze cererile semnificativ mai lent decât în mod normal. Din moment ce problema a avut loc, am luat mai multe măsuri pentru a preveni repetarea acesteia, pentru a atenua eventualele incidente similare și pentru a accelera timpul de soluționare în cazul unui incident. Acțiunile includ: - A fost aplicată o nouă logică de rutare. - Capacitatea Washington DC a crescut. - Capacitatea de rezervă a crescut în toate celelalte locații CDN. - Noua toleranta introdusa pentru o locatie CDN care trebuie eliminata din ruta. - monitorizare suplimentară disc, pentru a ajuta la pregătirea timpurie a upgrade-uri de capacitate. - HDD-urile sunt înlocuite cu SSD-uri. - Actualizat SOP pentru echipa noastră de sprijin pentru a investiga și răspunde la probleme similare. Clasificat ca nivel de severitate 3: impact minor.

Traducere automată din actualizarea oficială a incidentului.

1. 22 mai 2023 la 14:57 UTCinvestigating

   Emisiunea anterioară a utilizării de mare încărcare a revenit, cu un număr mic de API upload care nu funcționează.

2. 22 mai 2023 la 15:06 UTCresolved

   Problema s-a rezolvat în 9 minute după normalizarea volumului de încărcare. În timpul perioadei, aproximativ 98% din upload-uri au reușit și 2% au eșuat. REST API uploads sunt limitate pe oră, la suma specificată pe pagina de utilizare a contului Sirv https://my.sirv.com/#/cont/usage. Dacă utilizați REST API pentru încărcarea imaginilor, cele mai bune practici este de a verifica răspunsul pentru fiecare cerere de încărcare și dacă primiți un răspuns de eroare (400, 401, 429 etc.) apoi opriți upload-uri și rejudecați mai târziu. A se vedea nota de subsol 1. Clasificat ca nivel de severitate 4: Impact minim.

Traducere automată din actualizarea oficială a incidentului.

1. 22 mai 2023 la 11:31 UTCinvestigating

   Un număr mic de cereri de încărcare REST API nu reușesc din cauza unei încărcături foarte mari.

2. 22 mai 2023 la 12:37 UTCresolved

   Această problemă s-a rezolvat de îndată ce încărcătura de pe API-ul de încărcare a început să scadă. În timpul perioadei, aproximativ 97% din încărcături au reușit și 3% au eșuat. REST API uploads sunt limitate pe oră, la suma specificată pe pagina de utilizare a contului Sirv https://my.sirv.com/#/cont/usage. Dacă utilizați REST API pentru încărcarea imaginilor, cele mai bune practici este de a verifica răspunsul pentru fiecare cerere de încărcare și dacă primiți un răspuns de eroare (400, 401, 429 etc.) apoi opriți upload-uri și rejudecați mai târziu. A se vedea nota de subsol 1. Clasificat ca nivel de severitate 4: Impact minim.

Traducere automată din actualizarea oficială a incidentului.

1. 27 aprilie 2023 la 23:00 UTCinvestigating

   Unul dintre serverele CDN din Los Angeles a devenit nesănătos și a început să returneze erori 4xx la 0000 UTC. A fost scos din rutare după 90 de secunde şi într-o nouă 60 de secunde, traficul a fost direcţionat către servere sănătoase.

2. 27 aprilie 2023 la 23:03 UTCresolved

   Problema a fost rezolvată automat în 3 minute. Clasificat ca nivel de severitate 4: Impact minim.

Traducere automată din actualizarea oficială a incidentului.

1. 16 martie 2023 la 12:17 UTCinvestigating

   Unele cereri la London POP de Sirv CDN, se întorc erori din cauza de încărcare mare. Acest POP servește Regatul Unit și Irlanda. Lucrăm la o rezoluţie.

2. 16 martie 2023 la 13:33 UTCresolved

   Problema a fost rezolvată și acum este monitorizată.

3. 16 martie 2023 la 16:22 UTCresolved

   Unele cereri primite de unul dintre serverele CDN din Londra au eșuat din cauza unei combinații de rezoluție DNS locală și pulsating timeouts de rețea. Problema a început la 1215 UTC și a fost rezolvată la 1332 UTC. În această perioadă, 25% din cererile Regatului Unit și Irlandei au returnat o eroare de 404 sau 500. Problema ar fi fost rezolvată mai devreme, dar o eroare de validare a certificatului SSL fără legătură cu câteva ore mai devreme a blocat alertele primite de sistemul nostru de monitorizare. Au fost deja introduse modificări pentru a preveni repetarea acestei probleme. Problema certificatului SSL a fost rezolvată; a fost configurat un al doilea nivel de monitorizare independentă; se testează o automatizare suplimentară a sănătății care are potențialul de a rezolva automat astfel de probleme. Clasificat ca nivel de severitate 3: impact minor.

Traducere automată din actualizarea oficială a incidentului.

1. 23 februarie 2023 la 07:55 UTCresolved

   Problema a fost rezolvată la 0755 UTC. La 0625 UTC, unele cereri către Indore CDN POP, care servește India a început să returneze un răspuns 404 (fișier negăsit), în loc de un răspuns 200 (OK). Problema a avut loc la 14 ore după o actualizare a tuturor serverelor CDN din întreaga lume. Toți POP s-au comportat sănătos, inclusiv POP India, dar Indore POP nu a actualizat cu succes și în cele din urmă a început să returneze erori. Odată ce problema a fost identificată, aceasta a fost rezolvată prin re-distribuirea actualizării către POP India. În timpul incidentului, 94% din cereri au returnat o eroare. Cererile adresate tuturor celorlalte ţări au fost returnate ca de obicei. Pentru a preveni repetarea acestei probleme, se creează o nouă regulă de implementare automată pentru o parte a procesului de implementare în care a existat doar o verificare umană. De asemenea, se creează un indicator suplimentar de alertă, pentru a identifica o situație în care o implementare a eșuat. Ne cerem scuze tuturor clienţilor care au fost afectaţi de acest incident şi evaluăm alte schimbări care ar putea ajuta la prevenirea oricărei posibile repetări a problemei. Dacă apare o problemă CDN ca aceasta, o soluție imediată din cadrul controlului dumneavoastră este de a dezactiva temporar CDN în setările dvs. Sirv aici: https://my.sirv.com/#/cont/setings/domenii Clasificat ca nivel de severitate 2: impact semnificativ.

Traducere automată din actualizarea oficială a incidentului.