Istoricul incidentelor Circle Ci

1. 21 octombrie 2026 la 19:31 UTCidentified

   Unii utilizatori ar putea vedea creșterea timpului de așteptare pentru Gen2 Docker locuri de muncă din cauza problemelor de capacitate.

2. 21 octombrie 2026 la 20:03 UTCidentified

   Noi adăugăm capacități suplimentare pentru a contribui la atenuarea problemei. Notă: Încă vedem întârzieri de până la 20 de minute pe 2xlarge.

3. 21 octombrie 2026 la 20:22 UTCidentified

   Așteptați timp pentru 2xmare locuri de muncă docker sunt recuperarea. Vom continua să actualizați, deoarece capacitatea vine on-line.

4. 21 octombrie 2026 la 20:35 UTCidentified

   Așteptați timp pentru 2xmare locuri de muncă docker sunt acum sub 60 de secunde. Timpii de așteptare pentru alte dimensiuni ale resurselor nu au fost afectate de acest incident și rămân sub 10 secunde.

5. 21 octombrie 2026 la 20:40 UTCmonitoring

   Am văzut o recuperare completă a timpului de așteptare pentru locuri de muncă docker.

6. 21 octombrie 2026 la 20:54 UTCresolved

   Timpii de așteptare pentru Gen2 Docker locuri de muncă s-au recuperat și locuri de muncă se execută în timpi normali de așteptare.

7. 22 octombrie 2026 la 23:29 UTCpostmortem

   ## Rezumat De la 15:44 la 20:55 UTC pe 21 octombrie, clienții care rulează Gen 2 Docker locuri de muncă a văzut creșterea timpului de așteptare pentru locurile lor de muncă pentru a începe. Întârzierile au fost mai lungi la clasa de resurse 2xlarge, unde locurile de muncă au aşteptat până la 20 de minute. Incidentul a fost cauzat de disponibilitatea limitată a cazurilor cloud pe care le-am configurat pentru a satisface cererea, în special pentru 2xlarge locuri de muncă. Ca răspuns, echipa noastră de inginerie a configurat tipuri suplimentare de instanță, configurat clustere suplimentare Gen 2 Docker. Până la 20:55 UTC, orele de aşteptare au revenit la normal şi incidentul a fost rezolvat. După ce incidentul a fost rezolvat, ne-am extins flota Gen 2 Docker în regiuni de nori suplimentare și continuăm să stăm activ în picioare regiuni de nori suplimentare pentru a preveni incidente similare în viitor. Pagina originală de stare poate fi găsită aici: [21 octombrie - Creşterea numărului de aşteptare al Docker gen2](https://status.circleci.com/incidente/5jb50gh55gtj). ## Context Când CircleCI execută un loc de muncă Docker, îl programăm pe unul dintre mai multe grupuri de cazuri cloud, și fiecare instanță este capabilă să execute mai multe locuri de muncă izolate. Scheduling a job on a cloud instant is a classic [ Clase de resurse mai mari, cum ar fi 2xlarge sunt mai greu de potrivit decât cele mai mici, care împachetează împreună mai strâns. Noi oferim cazuri cloud folosind o listă clasată de tipuri de instanță. Dacă furnizorul de cloud nu poate furniza prima noastră alegere, ne întoarcem la următorul tip de pe listă. Menţinem în continuare o dimensiune minimă a flotei: un număr minim de cazuri continuă să funcţioneze, astfel încât să nu renunţăm la capacitate atunci când cererea este scăzută. Deasupra acelei dimensiuni minime a flotei, adăugăm cazuri pe măsură ce cererea creşte. Când nu există suficientă capacitate pentru a executa un volum de muncă, stăm la coadă care lucrează până când capacitatea devine disponibilă. ## What happened \(Toate timpurile UTC\) Începând cu ora 15:44 din 21 octombrie, cererea pentru clasa de resurse Gen 2xlarge a crescut brusc și nu am furnizat capacități suplimentare suficient de repede pentru a ține pasul. Echipa noastră de ingineri a început să investigheze. Până la 19:25, orele de așteptare pentru clasa de resurse Gen 2xlarge au ajuns la 20 de minute, iar orele de așteptare pentru alte clase de resurse au crescut, de asemenea. Până la 19:56, echipa noastră de inginerie a configurat tipuri suplimentare de instanță la flota Gen 2 pentru a obține mai multă capacitate online, și până la 19:59, am fost furnizarea acestor tipuri de instanță. La 20:11, am adăugat câteva grupuri suplimentare de gen 2 și am mărit dimensiunea minimă a flotei pe aceste grupuri. Până la 20:35, numărul locurilor de muncă coadă a revenit la niveluri normale, iar până la 20:41, 95% din locurile de muncă 2xmarite au început în 4 secunde. Am rezolvat incidentul la 20:55. După rezolvarea acestui incident, am adăugat regiuni cloud suplimentare pentru locurile de muncă Docker pentru a pune la dispoziție mai multă capacitate. ## Viitoare prevenire și îmbunătățire a procesului Am luat deja următoarele măsuri pentru a îmbunătăți perioada de începere a locurilor de muncă, inclusiv capacitatea de aprovizionare din mai multe locuri, rezervarea unei capacități mai mari pentru clasele mari de resurse și punerea în aplicare a unor dispoziții mai rapide. **Am adăugat regiuni suplimentare pentru locurile de muncă Docker.** Recent, am adăugat regiuni cloud suplimentare pentru locuri de muncă Machine, iar acum am făcut același lucru pentru locurile de muncă Docker. **Vom continua în mod activ să adăugăm regiuni cloud suplimentare atât pentru Docker cât și pentru Machine.** **Am adăugat clustere suplimentare Gen 2**. Am configurat mai multe grupuri suplimentare Gen 2 pentru a programa locuri de muncă mai repede, și pentru a face mai multă capacitate totală disponibilă. **Am extins setul de tipuri de exemple de nori pe care le folosim și ne-am mărit dimensiunea minimă a flotei.** Am configurat tipuri suplimentare de instanță. De asemenea, am mărit dimensiunea minimă a flotei pentru ca Gen 2 să răspundă cererii curente de referință. **Am modificat programul nostru de locuri de muncă pentru a prioritiza programarea de clase de resurse mai mari.** Am schimbat modul în care programăm locuri de muncă pentru a echilibra timpul de așteptare mai corect între clasele de resurse și pentru a împacheta mai eficient locurile de muncă în cazurile disponibile. ## Conclusion Experienţa clienţilor este prioritatea noastră principală şi ne angajăm să îmbunătăţim în permanenţă fiabilitatea sistemelor noastre pentru a se potrivi cu încrederea pe care o au clienţii noştri în noi. Le mulţumim clienţilor noştri pentru răbdarea lor în timp ce echipa noastră a lucrat pentru a rezolva acest incident. Vă rugăm să contactați echipa noastră de sprijin cu orice întrebări sau preocupări.

Traducere automată din actualizarea oficială a incidentului.

1. 20 octombrie 2026 la 15:58 UTCinvestigating

   Vedem vremuri de așteptare sporite pentru unele locuri de muncă MacOS folosind m4pro.mare clasă de resurse. Investigăm şi vom furniza o altă actualizare în curând. Mulţumesc pentru răbdare.

2. 20 octombrie 2026 la 16:32 UTCmonitoring

   Clientii care ruleaza locuri de munca macOS pe m4pro.mare clasa de resurse inca vad cresterea timpului de asteptare, cu unele locuri de munca asteapta pana la 30 de minute pentru a incepe. Continuăm să monitorizăm asta şi vom împărtăşi o noutate în scurt timp.

3. 20 octombrie 2026 la 17:02 UTCmonitoring

   Timpii de așteptare pentru m4pro.mare sunt încă ridicate din cauza cererii masive. Toate m4pro.mediu sunt normale. Monitorizăm activ, apreciem răbdarea.

4. 20 octombrie 2026 la 17:31 UTCmonitoring

   Timpii de așteptare pentru locurile de muncă macOS pe m4pro.mare clasa de resurse sunt de recuperare. Locuri de muncă folosind Xcode 27.0 sunt acum în așteptare aproximativ ~3,5 minute în medie, în jos de aproximativ ~40 minute la vârf. Locurile de muncă care utilizează Xcode 26.6 şi 26.4.1 sunt încă în curs de desfăşurare printr-un backlog, care este de compensare. Timpul de aşteptare pe m4pro.mediu este normal. Vom împărtăși o altă actualizare de îndată ce vom continua să monitorizeze.

5. 20 octombrie 2026 la 18:14 UTCresolved

   Timpii de așteptare pentru locurile de muncă MacOS pe m4pro.mare clasa de resurse au revenit la normal. Va multumim pentru rabdare in timp ce backlogs eliminate.

Traducere automată din actualizarea oficială a incidentului.

1. 14 octombrie 2026 la 14:47 UTCinvestigating

   De la aproximativ 14:00 UTC, clienții care execută locuri de muncă macOS care utilizează Xcode 26.6.0 pe clasa de resurse M4 Pro se confruntă cu întârzieri la începerea locurilor de muncă. Timpii de așteptare au ajuns la 30 de minute sau mai mult. Vă mulțumim pentru răbdare în timp ce inginerii noștri investighează. Vom furniza o altă actualizare până la 15:30 UTC.

2. 14 octombrie 2026 la 15:17 UTCidentified

   Întârzieri de pornire locuri de muncă macOS care folosesc Xcode 26.6.0 au recuperat. Deoarece aproximativ 15:11 UTC, locuri de muncă macOS care utilizează Xcode 26.4 se confruntă cu întârzieri începând, cu timpi de așteptare de aproximativ 30 de minute. Vă mulțumim pentru răbdare în timp ce inginerii noștri lucrează pentru a rezolva acest lucru. Vom furniza o altă actualizare până la 15:45 UTC.

3. 14 octombrie 2026 la 16:01 UTCresolved

   Intre orele 14:00 UTC si 15:51 UTC la 14 octombrie, clientii care desfasoara joburi MacOS care folosesc Xcode 26.6.0 sau Xcode 26.4 au intarziat incepand de locuri de munca. De la aproximativ 14:00 UTC, locurile de muncă care utilizează Xcode 26.6.0 pe clasa de resurse mari M4 Pro au așteptat 30 de minute sau mai mult pentru a începe, iar aceste întârzieri s-au recuperat la aproximativ 15:12 UTC. De la aproximativ 15:11 UTC, locuri de muncă care folosesc Xcode 26.4 a așteptat aproximativ 30 de minute pentru a începe. Problema a fost rezolvată și toate funcționalitățile afectate au revenit la normal. Vă mulțumim pentru răbdare în timp ce echipa noastră a lucrat la implementarea unui fix.

Traducere automată din actualizarea oficială a incidentului.

1. 9 octombrie 2026 la 11:33 UTCidentified

   Există o întârziere în infrastructura noastră de date care cauzează întârzieri înainte de a construi date și unele notificări devin vizibile. Lucrăm la o atenuare.

2. 9 octombrie 2026 la 13:00 UTCidentified

   Ce este afectat: Clientii care declanseaza conducte, si clientii se bazeaza pe outbound webhooks si email si notificări Slack. La ce te poţi aştepta? De la 11:15 UTC: - Conductele sunt încă în curs de creare în timp ce acest lucru este în curs de desfășurare, dar nu încă prelucrate, astfel redeclanșarea poate duce la conducte duplicate. - Outbound webhooks şi notificări tranzacţionale (Slack şi email) nu sunt trimise. - Starea conductei nu poate fi vizibilă. - Datele privind taxa de utilizare de pe pagina de utilizare a proiectului vor fi vechi. Vă mulțumim pentru răbdare în timp ce inginerii noștri lucrează pentru a rezolva acest lucru. Următoarea actualizare: Vom furniza o altă actualizare până la 13:30 UTC.

3. 9 octombrie 2026 la 13:30 UTCidentified

   Între 11:15 UTC și aproximativ 13:00 UTC, conductele au fost create, dar nu prelucrate, și outbound webhooks și notificări tranzacțiilor (Slack și e-mail) nu au fost trimise. Ce este afectat: Clientii care declanseaza conducte, si clientii se bazeaza pe outbound webhooks si email si notificări Slack. La ce te poţi aştepta: - De la ora 13:00 UTC, conductele sunt procesate din nou şi încep locurile de muncă. - Cele mai multe locuri de muncă încep în prezent în aproximativ 4 minute, iar unele așteaptă până la aproximativ 10 minute. Conductele declanşate în timpul incidentului sunt încă prelucrate şi pot dura mai mult până la început. - S-au reluat site-urile şi notificările. - Conductele sunt încă în curs de procesare de pe backlog, astfel încât redeclanşarea poate duce la conducte duplicate. Vă mulțumim pentru răbdare în timp ce inginerii noștri lucrează pentru a rezolva acest lucru. Următoarea actualizare: Vom furniza o altă actualizare până la ora 14:00 UTC.

4. 9 octombrie 2026 la 14:00 UTCidentified

   De la 11:15 UTC, clienții au suferit perturbări la conducte și notificări. Între 11:15 UTC și aproximativ 13:00 UTC, conductele au fost create, dar nu prelucrate, și outbound webhooks și notificări tranzacțiilor (Slack și e-mail) nu au fost trimise. Ce s-a întâmplat? Clienții care rulează fluxuri de lucru și locuri de muncă, precum și clienții care vizualizează datele de utilizare pe pagina de utilizare proiect. La ce te poţi aştepta? - Conductele sunt prelucrate din nou, inclusiv cele declanşate în timpul incidentului. - De la aproximativ 13:25 UTC, fluxurile de lucru și locurile de muncă au început cu întârzieri tot mai mari pe măsură ce lucrăm prin backlog. Majoritatea locurilor de muncă încep în prezent în aproximativ 10 minute, iar unele aşteaptă aproximativ 25 de minute. - Ne așteptăm să lucreze prin acest backlog de aproximativ 14:35 UTC. - Fluxurile de lucru de la conductele declanşate în timpul incidentului încă aşteaptă să înceapă, astfel redeclanşarea poate duce la fluxuri de lucru duplicate. - Datele privind taxa de utilizare de pe pagina de utilizare a proiectului sunt în prezent vechi. Vă mulțumim pentru răbdare în timp ce inginerii noștri lucrează pentru a rezolva acest lucru. Următoarea actualizare Vom furniza o altă actualizare până la 14:30 UTC.

5. 9 octombrie 2026 la 14:29 UTCidentified

   De la 11:15 UTC, clienții au suferit perturbări la conducte și notificări. Între 11:15 UTC și aproximativ 13:00 UTC, conductele au fost create, dar nu prelucrate, și outbound webhooks și notificări tranzacțiilor (Slack și e-mail) nu au fost trimise. Ce s-a întâmplat? Clienții care rulează fluxuri de lucru și locuri de muncă, precum și clienții care vizualizează datele de utilizare pe pagina de utilizare proiect. La ce te poţi aştepta? - Întârzierile de pornire a fluxurilor de lucru şi locurile de muncă se îmbunătăţesc. Cele mai multe locuri de muncă încep acum în aproximativ 3 minute, în jos de aproximativ 10 minute la 13:50 UTC. - Unele fluxuri de lucru de la conductele declanșate în timpul incidentului sunt încă așteaptă până la aproximativ 40 de minute pentru a începe. - Lucrul prin backlog durează puțin mai mult decât ne-am așteptat. Ne așteptăm acum să-l clar de aproximativ 14:45 UTC. - Fluxurile de lucru de la conductele declanşate în timpul incidentului încă aşteaptă să înceapă, astfel redeclanşarea poate duce la fluxuri de lucru duplicate. - Datele privind taxa de utilizare de pe pagina de utilizare a proiectului sunt în prezent vechi. Vă mulțumim pentru răbdare în timp ce inginerii noștri lucrează pentru a rezolva acest lucru. Următoarea actualizare Vom furniza o altă actualizare până la ora 15:00 UTC.

6. 9 octombrie 2026 la 14:43 UTCidentified

   De la 11:15 UTC, clienții au suferit perturbări la conducte și notificări. Între 11:15 UTC și aproximativ 13:00 UTC, conductele au fost create, dar nu prelucrate, și outbound webhooks și notificări tranzacțiilor (Slack și e-mail) nu au fost trimise. Între orele 13:00 UTC și 14:40 UTC, fluxurile de lucru și locurile de muncă au început cu întârzieri în timp ce am lucrat prin backlog. Ce s-a întâmplat? Clienții care rulează fluxuri de lucru și locuri de muncă, precum și clienții care vizualizează datele de utilizare pe pagina de utilizare proiect. La ce te poţi aştepta? - Reflectarea fluxurilor de lucru de la conductele declanşate în timpul incidentului, la aproximativ 14:40 UTC. - Cele mai multe locuri de muncă încep acum în aproximativ 30 de secunde, iar unele așteaptă până la aproximativ 3 minute. - Datele privind taxa de utilizare de pe pagina de utilizare a proiectului sunt în prezent vechi. Vă mulțumim pentru răbdare în timp ce inginerii noștri continuă să lucreze la problema de bază. Următoarea actualizare Vom furniza o altă actualizare până la 15:10 UTC.

7. 9 octombrie 2026 la 14:54 UTCmonitoring

   De la 11:15 UTC, clienții au suferit perturbări la conducte și notificări. Între 11:15 UTC și aproximativ 13:00 UTC, conductele au fost create, dar nu prelucrate, și outbound webhooks și notificări tranzacțiilor (Slack și e-mail) nu au fost trimise. Între orele 13:00 UTC și 14:40 UTC, fluxurile de lucru și locurile de muncă au început cu întârzieri în timp ce am lucrat prin backlog. Ce s-a întâmplat? Clienții care rulează fluxuri de lucru și locuri de muncă, precum și clienții care vizualizează datele de utilizare pe pagina de utilizare proiect. La ce te poţi aştepta? - Rezervorul conductelor și fluxurilor de lucru de la incident a fost eliminat. - De la aproximativ 14:45 UTC, cele mai multe fluxuri de lucru și locuri de muncă încep în aproximativ 15 secunde, și timpii de pornire continuă să revină la normal. - Datele privind taxa de utilizare de pe pagina de utilizare a proiectului sunt în prezent vechi. Vă mulțumim pentru răbdare în timp ce inginerii noștri monitorizează recuperarea. Următoarea actualizare Vom furniza o altă actualizare până la 15:20 UTC.

8. 9 octombrie 2026 la 15:32 UTCmonitoring

   De la 11:15 UTC, clienții au suferit perturbări la conducte și notificări. Între 11:15 UTC și aproximativ 13:00 UTC, conductele au fost create, dar nu prelucrate, și outbound webhooks și notificări tranzacțiilor (Slack și e-mail) nu au fost trimise. Între orele 13:00 UTC și 14:40 UTC, fluxurile de lucru și locurile de muncă au început cu întârzieri în timp ce am lucrat prin backlog. Ce s-a întâmplat? Clientii vizionarea conducte, fluxuri de lucru și locuri de muncă în UI CircleCI, și clienții vizualizarea datelor de utilizare pe pagina de utilizare proiect. La ce te poţi aştepta? - Fluxurile de lucru şi locurile de muncă se execută la timp. - CircleCI UI e cu 30 de minute în urmă. Noi fluxuri de lucru și modificări de stare pot dura atât de mult să apară. Inginerii noştri lucrează activ pentru a accelera procesarea, astfel încât UI să poată recupera. - Vă rugăm să evitați redeclanșarea fluxurilor de lucru care nu apar încă în UI, deoarece acest lucru poate crea duplicate. - Datele privind taxa de utilizare de pe pagina de utilizare a proiectului sunt în prezent vechi. Vă mulțumim pentru răbdare în timp ce inginerii noștri lucrează pentru a reduce această întârziere. Următoarea actualizare Vom furniza o altă actualizare până la ora 16:00 UTC.

9. 9 octombrie 2026 la 16:02 UTCmonitoring

   De la 11:15 UTC, clienții au suferit perturbări la conducte și notificări. Între 11:15 UTC și aproximativ 13:00 UTC, conductele au fost create, dar nu prelucrate, și outbound webhooks și notificări tranzacțiilor (Slack și e-mail) nu au fost trimise. Între orele 13:00 UTC și 14:40 UTC, fluxurile de lucru și locurile de muncă au început cu întârzieri în timp ce am lucrat prin backlog. Ce s-a întâmplat? Clienți care rulează fluxuri de lucru și locuri de muncă, clienți care vizualizează conducte, fluxuri de lucru și locuri de muncă în cadrul CircleCI UI, și clienți care vizualizează date de utilizare pe pagina de utilizare a proiectului. La ce te poţi aştepta? - De la ora 15:15 UTC, fluxurile de muncă și locurile de muncă încep cu întârzieri tot mai mari. Majoritatea locurilor de muncă încep în prezent în aproximativ 4 minute, iar unele aşteaptă aproximativ 20 de minute. - CircleCI UI rămâne cu aproximativ 30 de minute în urmă în medie, iar unele actualizări durează mai mult. Noi fluxuri de lucru și modificări de stare pot dura atât de mult să apară. - Vă rugăm să evitați redeclanșarea fluxurilor de lucru care nu apar încă în UI, deoarece acest lucru poate crea duplicate. - Datele privind taxa de utilizare de pe pagina de utilizare a proiectului sunt în prezent vechi. Vă mulțumim pentru răbdare în timp ce inginerii noștri lucrează pentru a reduce aceste întârzieri. Următoarea actualizare Vom furniza o altă actualizare până la 16:30 UTC.

10. 9 octombrie 2026 la 16:32 UTCmonitoring

    De la 11:15 UTC, clienții au suferit perturbări la conducte și notificări. Între 11:15 UTC și aproximativ 13:00 UTC, conductele au fost create, dar nu prelucrate, și outbound webhooks și notificări tranzacțiilor (Slack și e-mail) nu au fost trimise. Între orele 13:00 UTC și 14:40 UTC, fluxurile de lucru și locurile de muncă au început cu întârzieri în timp ce am lucrat prin backlog. De la aproximativ 15:15 UTC, fluxurile de lucru și locurile de muncă au început din nou cu întârzieri. Ce s-a întâmplat? Clienți care rulează fluxuri de lucru și locuri de muncă, clienți care vizualizează conducte, fluxuri de lucru și locuri de muncă în cadrul CircleCI UI, și clienți care vizualizează date de utilizare pe pagina de utilizare a proiectului. La ce te poţi aştepta? - Întârzierile de pornire a fluxurilor de lucru și a locurilor de muncă au încetat să crească și încep să se ușureze. Majoritatea locurilor de muncă încep în aproximativ 4 minute, iar unele aşteaptă aproximativ 25 de minute. - CircleCI UI este acum aproximativ 20 de minute în urmă, în jos de aproximativ 30 de minute. Noi fluxuri de lucru și modificări de stare pot dura atât de mult să apară. - Vă rugăm să evitați redeclanșarea fluxurilor de lucru care nu apar încă în UI, deoarece acest lucru poate crea duplicate. - Datele privind taxa de utilizare de pe pagina de utilizare a proiectului sunt în prezent vechi. Vă mulțumim pentru răbdare în timp ce inginerii noștri lucrează pentru a reduce aceste întârzieri. Următoarea actualizare Vom furniza o altă actualizare până la ora 17:00 UTC.

11. 9 octombrie 2026 la 17:06 UTCmonitoring

    De la 11:15 UTC, clienții au suferit perturbări la conducte și notificări. Între 11:15 UTC și aproximativ 13:00 UTC, conductele au fost create, dar nu prelucrate, și outbound webhooks și notificări tranzacțiilor (Slack și e-mail) nu au fost trimise. Între orele 13:00 UTC și 14:40 UTC, fluxurile de lucru și locurile de muncă au început cu întârzieri în timp ce am lucrat prin backlog. De la aproximativ 15:15 UTC, fluxurile de lucru și locurile de muncă au început din nou cu întârzieri. Ce s-a întâmplat? Clienți care rulează fluxuri de lucru și locuri de muncă, clienți care vizualizează conducte, fluxuri de lucru și locuri de muncă în cadrul CircleCI UI, și clienți care vizualizează date de utilizare pe pagina de utilizare a proiectului. La ce te poţi aştepta? - Întârzieri de pornire fluxuri de lucru și locuri de muncă sunt exploatație constantă. Cele mai multe locuri de muncă încep în aproximativ 4 minute, iar unele așteaptă până la aproximativ 8 minute, în jos de la aproximativ 25 de minute. - UI CircleCI rămâne cu aproximativ 20 de minute în urmă în medie, iar unele actualizări durează mai mult. Noi fluxuri de lucru și modificări de stare pot dura atât de mult să apară. - Vă rugăm să evitați redeclanșarea de lucru care încă nu apar în UI, deoarece acest lucru poate crea duplicate. - Datele privind taxa de utilizare de pe pagina de utilizare a proiectului sunt în prezent vechi. Vă mulțumim pentru răbdare în timp ce inginerii noștri lucrează pentru a reduce aceste întârzieri. Următoarea actualizare Vom furniza o altă actualizare până la 17:30 UTC.

12. 9 octombrie 2026 la 17:34 UTCidentified

    De la 11:15 UTC, clienții au suferit perturbări la conducte și notificări. Între 11:15 UTC și aproximativ 13:00 UTC, conductele au fost create, dar nu prelucrate, și outbound webhooks și notificări tranzacțiilor (Slack și e-mail) nu au fost trimise. Între orele 13:00 UTC și 14:40 UTC, fluxurile de lucru și locurile de muncă au început cu întârzieri în timp ce am lucrat prin backlog. De la aproximativ 15:15 UTC, fluxurile de lucru și locurile de muncă au început din nou cu întârzieri. Ce s-a întâmplat? Clientii care declanseaza conducte si ruleaza fluxuri de lucru si locuri de munca, clientii vizionand conducte, fluxuri de lucru si locuri de munca in cadrul CircleCI UI si clientii care vizualizeaza datele de utilizare pe pagina de utilizare a proiectului. La ce te poţi aştepta? - De la ora 17:00 UTC, întârzierile au crescut semnificativ. Cele mai multe locuri de muncă sunt acum de a lua aproximativ 12 minute pentru a începe, și unii așteaptă până la aproximativ 30 de minute. De la ora 17:15 UTC, unele locuri de muncă nu încep. - Conductele sunt prelucrate mai lent, astfel încât unele ar putea dura mai mult pentru a începe. - CircleCI UI este mai mult de o oră în urmă. Noi fluxuri de lucru și modificări de stare pot dura atât de mult să apară. - Vă rugăm să evitați redeclanșarea de lucru care încă nu apar în UI, deoarece acest lucru poate crea duplicate. - Datele privind taxa de utilizare de pe pagina de utilizare a proiectului sunt în prezent vechi. Vă mulțumim pentru răbdare în timp ce inginerii noștri lucrează pentru a rezolva acest lucru. Următoarea actualizare Vom furniza o altă actualizare până la ora 18:00 UTC.

13. 9 octombrie 2026 la 18:08 UTCidentified

    De la 11:15 UTC, clienții au suferit perturbări la conducte și notificări. Între 11:15 UTC și aproximativ 13:00 UTC, conductele au fost create, dar nu prelucrate, și outbound webhooks și notificări tranzacțiilor (Slack și e-mail) nu au fost trimise. Între orele 13:00 UTC și 14:40 UTC, fluxurile de lucru și locurile de muncă au început cu întârzieri în timp ce am lucrat prin backlog. De la aproximativ 15:15 UTC, fluxurile de lucru și locurile de muncă au început din nou cu întârzieri. Ce s-a întâmplat? Clientii care declanseaza conducte si ruleaza fluxuri de lucru si locuri de munca, clientii vizionand conducte, fluxuri de lucru si locuri de munca in cadrul CircleCI UI si clientii care vizualizeaza datele de utilizare pe pagina de utilizare a proiectului. Ce să se aștepte - De la ora 17:00 UTC, vedem o creştere a întârzierilor. Cele mai multe locuri de muncă sunt acum de a lua aproximativ 25 de minute pentru a începe, și unii așteaptă până la aproximativ o oră. - De la aproximativ 17:15 UTC, unele fluxuri de lucru în curs de dezvoltare au eșuat și un număr mic de locuri de muncă nu au început. - Noile conducte sunt la coadă şi durează mai mult până încep. - CircleCI UI este mai mult de o oră în urmă. Noi fluxuri de lucru și modificări de stare pot dura atât de mult să apară. - Vă rugăm să evitați redeclanșarea fluxurilor de lucru care nu apar încă în UI, deoarece acest lucru poate crea duplicate. - Datele privind taxa de utilizare de pe pagina de utilizare a proiectului sunt în prezent vechi. Inginerii noştri continuă să lucreze la rezolvarea problemei. Următoarea actualizare Vom furniza o altă actualizare până la 18:30 UTC.

14. 9 octombrie 2026 la 18:32 UTCidentified

    Ce s-a schimbat de la ultima actualizare * CircleCI UI este cu aproximativ o oră în urmă, și până la aproximativ 90 de minute pentru unele actualizări. Fluxurile de lucru și locurile de muncă pot fi deja difuzate, sau pot fi difuzate, chiar dacă UI le arată ca nu a început sau nu le arată deloc. * Locurile de muncă care rulează încep mai repede. Majoritatea încep acum în aproximativ 15 minute, în jos de aproximativ 28 de minute, deși unele sunt încă în așteptare peste o oră. * Noile conducte sunt tot mai întârziate. * Unele fluxuri de lucru sunt încă în scădere. Fluxurile de lucru care nu au putut fi prelucrate în timp sunt marcate ca fiind eșuate. * Vă rugăm să evitați redeclanșarea fluxurilor de lucru care nu apar încă în UI, deoarece acest lucru poate crea duplicate. Încă în desfăşurare: Datele privind taxa de utilizare pe pagina de utilizare a proiectului sunt vechi. Următoarea actualizare Vom furniza o altă actualizare până la ora 19:00 UTC.

15. 9 octombrie 2026 la 18:57 UTCidentified

    Ce s-a schimbat de la ultima actualizare * Slujbele încep mai repede. Cele mai multe încep acum în aproximativ 8 minute, în jos de aproximativ 15 minute, și cele mai lungi așteptați au scăzut de la peste o oră la aproximativ 45 de minute. * CircleCI UI începe să prindă din urmă, dar este încă în urmă. Fluxurile de lucru și locurile de muncă pot fi deja difuzate, sau pot fi difuzate, chiar dacă UI le arată ca nu a început sau nu le arată deloc. * Conductele sunt prelucrate mai repede, dar noi conducte sunt încă întârziate. Încă în desfăşurare. * Unele fluxuri de lucru și locuri de muncă sunt încă în criză. * Vă rugăm să evitați redeclanșarea fluxurilor de lucru care nu apar încă în UI, deoarece acest lucru poate crea duplicate. * Datele privind taxa de utilizare pe pagina de utilizare a proiectului sunt vechi. Următoarea actualizare Vom furniza o altă actualizare până la 19:30 UTC.

16. 9 octombrie 2026 la 19:29 UTCidentified

    De la ultima actualizare, locurile de muncă încep mai repede: majoritatea încep acum în aproximativ 6 minute, în jos de la aproximativ 8 minute. Cei de la CircleCI U.I. ne ajung din urmă cu o oră. Noi conducte sunt prelucrate în timp ce sosesc. Locurile de muncă pot fi deja difuzate chiar dacă UI nu le arată încă, așa că vă rugăm să evitați redeclanșarea fluxurilor de lucru care nu apar în UI. Vom furniza o altă actualizare până la ora 20:00 UTC.

17. 9 octombrie 2026 la 20:06 UTCidentified

    Locurile de muncă încep din ce în ce mai repede și mai puține dau faliment: majoritatea locurilor de muncă încep acum în aproximativ 4 minute, în jos de la aproximativ 6 minute, iar cele mai lungi așteptări au scăzut de la aproximativ 30 de minute la aproximativ 20 de minute. Conducte de mai devreme în incident sunt acum în curs de lucru prin intermediul. UI CircleCI este încă în urmă, și unele actualizări mai vechi pot dura mai mult pentru a apărea. Locurile de muncă pot fi deja difuzate chiar dacă UI nu le arată încă, așa că vă rugăm să evitați redeclanșarea fluxurilor de lucru care nu apar în UI. Vom furniza o altă actualizare până la 20:30 UTC.

18. 9 octombrie 2026 la 21:22 UTCidentified

    De la aproximativ 20:48 UTC, noi fluxuri de lucru și locuri de muncă nu încep. Ne-am oprit temporar să începem noi lucrări, astfel încât sistemele noastre să poată recupera lucrările deja în curs de desfășurare, inclusiv actualizări întârziate la UI CircleCI și API. Actualizări mai vechi apar acum în UI și API ca acest backlog șterge. Noi conducte sunt încă acceptate și la coada Vă rugăm să evitați redeclanșarea conductelor sau fluxurilor de lucru în acest timp, deoarece acest lucru poate crea duplicate după reluarea lucrărilor. Vom furniza o altă actualizare până la ora 22:00 UTC.

19. 9 octombrie 2026 la 22:09 UTCidentified

    De la ultima noastră actualizare, cele mai multe dintre conductele care au fost întârziate mai devreme în incident au fost acum procesate, iar fluxurile lor de lucru sunt la coadă pentru a începe. Noi fluxuri de lucru și locuri de muncă rămân oprite în timp ce ne pregătim să-și reia munca în condiții de siguranță. Actualizările întârziate continuă să apară în CircleCI UI și API. Vă rugăm să continuaţi să evitaţi redeclanşarea conductelor sau fluxurilor de lucru, deoarece aceasta poate crea duplicate după reluarea lucrărilor. Vom furniza o altă actualizare până la 22:30 UTC.

20. 9 octombrie 2026 la 22:28 UTCidentified

    De la ultima noastră actualizare, am început să reluăm treptat munca, iar unele fluxuri de lucru şi locuri de muncă la coadă încep din nou. Cele mai multe locuri de muncă la coadă sunt încă în așteptare, și locuri de muncă care nu încep să fi așteptat peste o oră. Suntem în creștere rata cu atenție pentru a evita supraîncărcarea sistemelor noastre. Actualizările întârziate continuă să apară în CircleCI UI și API. Vă rugăm să continuați să evitați redeclanșarea conductelor sau fluxurilor de lucru, deoarece acest lucru poate crea duplicate în timp ce munca la coadă reia. Vom furniza o altă actualizare până la 23:00 UTC.

21. 9 octombrie 2026 la 23:00 UTCidentified

    Un număr mare de fluxuri de lucru coadă și locuri de muncă au început, iar CercCI UI și API au prins și sunt afișate actualizări în mod normal, cu puține întârzieri. Continuăm să lucrăm prin munca rămasă la coadă. Locurile de muncă de la coadă pot fi așteptat aproximativ o oră sau mai mult pentru a începe, și unele locuri de muncă Linux așteaptă până la aproximativ 10 minute pentru capacitate. Vă rugăm să continuați să evitați redeclanșarea în timp ce munca la coadă continuă să proceseze. Vom furniza o altă actualizare până la 23:30 UTC.

22. 9 octombrie 2026 la 23:38 UTCidentified

    Încă lucrăm printr-o serie semnificativă de fluxuri și locuri de muncă la coadă. Timpurile de aşteptare se îmbunătăţesc, dar rămân mai lungi decât în mod normal, iar unele locuri de muncă au aşteptat peste o oră. CircleCI UI şi API rămân la zi. Vă rugăm să evitați repornirea conductelor sau fluxurilor de lucru în timp ce backlog-ul se șterge, deoarece acest lucru poate crea duplicate. Vom furniza o altă actualizare până la 00:00 UTC.

23. 9 octombrie 2026 la 23:59 UTCidentified

    De la ultima noastră actualizare, backlog-ul fluxurilor de lucru coadă și locuri de muncă a fost eliminat, la aproximativ 23:47 UTC. Fluxurile de lucru şi locurile de muncă încep în câteva secunde, iar cercul CI UI şi API sunt la zi. Ne monitorizăm îndeaproape sistemele pentru a ne asigura că rămân stabile. Vom furniza o altă actualizare până la 00:30 UTC.

24. 10 octombrie 2026 la 00:45 UTCidentified

    Fluxurile de lucru și locurile de muncă au continuat să înceapă în mod normal, în câteva secunde, iar CircleCI UI și API rămân la zi. Încă mai sunt transmise notificări de grevă şi e-mail întârziate mai devreme. Datele privind taxa de utilizare pe pagina de utilizare a proiectului sunt vechi. Continuăm să ne monitorizăm îndeaproape sistemele și vom furniza o altă actualizare până la 01:15 UTC.

25. 10 octombrie 2026 la 01:23 UTCmonitoring

    Fluxurile de lucru şi locurile de muncă încep şi funcţionează normal, iar CircleCI UI şi API sunt la zi. Continuăm să monitorizăm îndeaproape sistemele noastre pentru a ne asigura că rămân stabile. Vom furniza o altă actualizare până la 02:00 UTC.

26. 10 octombrie 2026 la 02:08 UTCresolved

    Intre 11:15 UTC si 23:47 UTC la 9 octombrie, clientii au avut intarzieri si esecuri intre conducte, fluxuri de lucru si locuri de munca, impreuna cu intarzieri in CircleCI UI, API si notificări. De la 11:15 la aproximativ 13:00 UTC, conductele au fost create, dar nu prelucrate, și outbound webhooks și Slack și notificări de e-mail nu au fost trimise. De la aproximativ 13:00 la 14:40 UTC, fluxurile de lucru și locurile de muncă au început cu întârzieri în timp ce am lucrat prin backlog. De la aproximativ 15:15 la 20:48 UTC, fluxurile de lucru și locurile de muncă au început cu întârzieri tot mai mari, de până la aproximativ o oră, iar CircleCI UI și API au rămas în urmă cu aproximativ 2 ore. În acest timp, unele locuri de muncă nu au reușit să înceapă și unele fluxuri de lucru în curs de desfășurare au eșuat. De la 20:48 la aproximativ 22:10 UTC, am oprit temporar începerea de noi fluxuri de lucru și locuri de muncă, astfel încât sistemele noastre ar putea recupera. În acest timp au fost acceptate noi conducte şi au fost la rând. De la aproximativ 22:10 la 23:47 UTC, fluxurile de lucru coadă și locurile de muncă reluate și au fost prelucrate. Unii dintre ei au aşteptat aproximativ 2 ore. Problema a fost rezolvată și toate funcționalitățile afectate au revenit la normal. Datele privind taxa de utilizare de pe pagina de utilizare a proiectului nu sunt încă actualizate și vor fi actualizate odată ce datele noastre se completează. Clienții ale căror locuri de muncă au eșuat în timpul acestei ferestre pot relua locurile de muncă afectate. Vă mulțumim pentru răbdare în timp ce inginerii noștri au lucrat la implementarea unui fix.

27. 12 octombrie 2026 la 22:32 UTCpostmortem

    ## Rezumat Intre 11:15 UTC si 23:47 UTC pe 9 octombrie, clientii CircleCI au experimentat intarzieri si esecuri de ore intre conducte, fluxuri de lucru si locuri de munca, impreuna cu intarzieri in CircleCI UI, API si notificări. * De la 11:15 la 13:00 UTC, conductele au fost create, dar nu prelucrate, și outbound webhooks și Slack și notificări de e-mail nu au fost trimise. * De la 13:00 la 14:40 UTC, fluxurile de lucru și locurile de muncă au început cu întârzieri în timp ce am lucrat prin backlog. * De la 15:15 la 20:48 UTC, fluxurile de lucru şi locurile de muncă au început cu întârzieri tot mai mari, de până la aproximativ o oră, iar CircleCI UI şi API au rămas în urmă cu aproximativ 2 ore. În acest timp, unele locuri de muncă nu au reușit să înceapă și unele fluxuri de lucru în curs de desfășurare au eșuat. * De la 20:48 la 22:10 UTC, am întrerupt temporar începerea de noi fluxuri de lucru şi locuri de muncă pentru ca sistemele noastre să se poată reface. În acest timp au fost acceptate noi conducte şi au fost la rând. * De la 22:10 la 23:47 UTC, fluxurile de lucru şi locurile de muncă la coadă au fost reluate şi prelucrate cu succes. Unii dintre ei au aşteptat aproximativ 2 ore. * La 23:47, incidentul a fost atenuat. Pagina de stare pentru acest incident poate fi găsită la [9 octombrie - Întârzierea datelor care apar în UI și API] [https://status.circleci.com/incidente/6cfhhlr4rmm0]. Clienții au avut un incident similar la începutul săptămânii la [6 octombrie - Întârzieri în conducte, fluxuri de lucru, date UI și notificări] [https://status.circleci.com/incidente/z4hbq8h49j8c]. Multiple servicii CircleCI folosesc Temporal susţinut de Postgres ca un mecanism fiabil de coadă, şi ambele incidente au avut aceeaşi cauză: rata de scriere la instanţa Temporală Postgres au fost mai rapid decât jurnalul de tranzacţii Postgress ar putea arhiva cele scrie. În ambele cazuri, aceasta a cauzat întârzieri mai multe ore atât în procesarea conductelor, cât și în notificarea statutului. Am evaluat mai multe atenuări, apoi am oprit noul flux de lucru pentru ca sistemul să se poată recupera în siguranţă şi să se întoarcă treptat. Apoi am accelerat până când sistemele noastre au revenit la normal. Pentru a rezolva permanent problema, am împărțit munca în mai multe cazuri temporale, fiecare cu propriile sale baze de date independente și grupuri de lucrători, și am încărcat-echilibrul între ele. Am programat deja lucrări de infrastructură începând cu săptămâna 12 octombrie care ar fi înlăturat acest blocaj exact şi ar fi împiedicat aceste incidente. Astfel, începând cu 19:11 pe 9 octombrie, echipa noastră de inginerie a implementat, testat și a rulat o versiune mai simplă a acestor schimbări în câteva ore. Am adăugat în continuare noi alerte și am reglat bazele de date de bază pentru o mai bună performanță în condiții de încărcare ridicată. Clienții ale căror locuri de muncă nu a reușit în timpul acestei ferestre le poate relua. ## Context Pentru a rula locuri de muncă pentru clienți, CircleCI execută o serie de pași: acceptăm conducte de clienți; atribuim locuri de muncă pentru aceste conducte lucrătorilor; oferim actualizări ale statutului pentru aceste conducte și locuri de muncă; și percepem clienților pentru creditele pe care le consumă aceste locuri de muncă. Fiecare dintre aceste etape este implementat de un serviciu independent, cu cozi fiabile între. Din punct de vedere istoric am implementat aceste cozi de încredere cu RabbitMQ pe partea de sus a depozitării durabile, cu cozi de rezervă exponențiale și litere moarte pentru fiabilitate. În ultimul an, ne-am reinstalat cozile de încredere pe [Temporal] (https://temporal.io/), care oferă garanții de durabilitate și fiabilitate mult mai bune pentru un model de programare mai simplu și mai puternic. Serviciul nostru de construcţii \ [care transformă o conductă configurată într-un plan executabil\), serviciul nostru orchestrator \[care distribuie sarcini lucrătorilor\], serviciul nostru de notificare \ [care oferă actualizări de stare\), şi serviciul nostru de încărcare \ [care taxează clienţii pentru credite\) toate acum folosesc Temporal. Temporalul stochează statul pentru activitatea sa și pentru activitățile sale \ [numită În consecință, capacitatea unei instanțe temporale de a accepta și de a executa activitatea este dependentă de rata de scriere a bazei sale de date. Am configurat, de asemenea, Temporal pentru a șterge fluxurile de lucru completate și activitățile din istoria sa 3 zile după ce au terminat. La momentul acestui incident, am folosit un singur caz temporal grupat susținut de un exemplu multi-AZ Postgres RDS pentru toate aceste cozi fiabile. În timp ce o instanță multi-AZ RDS este rezistentă la defecțiunile zonei, aceasta menține coerența bazei de date prin intermediul unui singur scriere-forward-log \ (WAL\). În momentul în care am configurat cazul nostru Postgres pentru a stoca WAL său pe un jurnal dedicat Volumul \ [DLV\] astfel încât jurnal scrie nu a concurat cu date scrie. Baza de date arhivează continuu jurnalul pentru stocarea de rezervă, și poate refolosi spațiul pe volum numai după arhivarea jurnalului. Dacă baza de date scrie jurnale mai repede decât arhivele, volumul se umple și Postgres nu are spațiu pentru a scrie jurnalul WAL. Apoi baza de date nu mai acceptă scrieri primite și merge în întregime citit-doar. Un DLV RDS se limitează la 1TB de stocare și 3000 IOPS și pe AWS aceste limite sunt hardcodate și nu pot fi majorate. ## What happened \(Toate timpurile UTC\) Unul dintre factorii care au contribuit la incidentul din 6 octombrie a fost că am procesat o rată mare de ştergere a istoriei temporale în acelaşi timp cu activitatea de intrare, care la rândul său a pus presiune pe baza de date de suport. Pentru a rezolva incidentul din 6 octombrie, am schimbat setările de curăţare pe cele mai mari mese Temporale şi am mutat registrul tranzacţiilor înapoi la volumul său dedicat. Aceste modificări au eliminat sursa majoră a jurnalului de tranzacții scrie, dar nu au luat în considerare jurnalul suplimentar scrie de ștergeri programate. Pentru că am configurat Temporal pentru a șterge fluxurile de lucru și activitățile finalizate din istoria sa 3 zile după ce au terminat, istoria octombrie 6 a fost programată să fie șterse pe 9 octombrie. Începând cu ora 08:00, pe 9 octombrie, Temporalul a început să proceseze acele ștergeri programate și, ca urmare, spațiul liber de pe DLV postgres a început să scadă precipitat, de la 0.8TB la 08:00 la 0.10 TB până la 10:10. Monitorizarea noastră a fost alertată la 10:28 şi am declarat un incident la 10:31. În timp ce echipa noastră de infrastructură investiga, la 11:15 DLV a rămas fără spaţiu şi cazul Postgres a mers doar la citire. Asta a oprit toate procesele temporale. La 11:42, am repornit Postgres pentru a muta jurnalul WAL de la DLV pe volumul de date și de a folosi spațiul de disc de rezervă și IOPS acolo. Această manevră a atenuat incidentul pe 6 octombrie şi am ştiut că va dura aproximativ 60 de minute. În timp ce baza de date a fost repornirea, am început implementarea mai multe tehnici de încărcare în amonte de temporal: * Am început să investigăm dacă ar trebui să pierdem cu totul volumul de muncă pentru a menţine restul în mişcare, dar în cele din urmă am decis că acest lucru nu va oferi nici o valoare. * La 12:29, am semnalat actualizări de tarifare a creditelor, care au reprezentat 12% din activitățile temporale. Acest lucru a lăsat pagina de utilizare a conductei cu date de încărcare vechi, până când am fi completat-o, dar nu ar fi pierdut datele sau nu ar fi împiedicat conductele să funcţioneze. La 12:59, baza de date a fost din nou sus și a început lucrările de prelucrare care au stat la coadă din 11:15 și până la 14:40, acest backlog a fost șters și locuri de muncă au început la timp. Cu toate acestea, până la 15:15, întârzierile au revenit ca bază de date până la curăţare au scăzut mult în urmă pe mesele de utilizări temporale pentru a urmări coada şi munca programată. În mod normal, aceste mese ţin zeci de mii de rânduri şterse în aşteptarea curăţării, dar până târziu după-amiaza, au ţinut zeci de milioane de rânduri. Fiecare operaţiune temporală a trebuit să citească dincolo de acele rânduri, aşa că baza de date a petrecut mult mai mult timp de procesare pe fiecare şi Temporal a mers mai încet. Acest lucru a dus la clienții care continuă să vadă întârzieri de o oră în conductele de pornire și în actualizările stării. Pentru următoarele câteva ore am încercat diverse atenuări, inclusiv: * Manipularea valorilor de configurare temporală pentru a reduce presiunea bazei de date. Acest lucru a avut un efect minim. * Rularea manual locuri de muncă vid pentru a curăța rânduri moarte în Postgres. Acest lucru a ajuns să concureze pentru procesor cu întrebări și a fost în cele din urmă contraproductiv. Le-am anulat la 17:45 pentru a reduce presiunea asupra încărcăturii bazei de date. * Am început să încercăm să mutăm toate cazurile de notificare într - o situaţie temporală separată. Aceasta a reprezentat 18% din activitățile temporale. Am terminat cu succes de mutare notificări de 17:07. * La 17:16, am implementat cu succes o optimizare în reprezentarea stării conductelor, care a redus-o cu 5%. Că, la rândul său, a redus dimensiunea bazei de date scrie și, prin urmare, presiunea datelor pe jurnalul postgres WAL. Niciuna dintre acestea nu a atenuat complet problema. Până la 20:48, ne-am dat seama că Postgres a fost acum thrashing pe baza de date CPU și nu a mai fost blocat pe jurnal scrie. Ne-am dat seama că sistemele noastre din amonte depuneau atât lucrări noi, cât şi lucrări de rejudecare care fuseseră depuse anterior şi eşuate. Recunoscând că am fost într-o furtună clasică retrimise, am oprit toate lucrările de intrare și de reîncercare și lăsați-l coadă în sus, pentru a permite bazei de date pentru a finaliza complet în proces de lucru. Apoi am accelerat încet până lucru coadă de la 22:07 pentru a menține baza de date la o sarcină durabilă. Acest lucru a reuşit pe deplin până la 23:47 când au început toate lucrările la coadă şi am închis incidentul la 02:08 pe 10 octombrie. ## Viitoare prevenire și îmbunătățire a procesului ### Multiple Temporal Tribunals În paralel cu atenuarea și soluționarea incidentelor, începând de la ora 19:11 din 9 octombrie, am început, de asemenea, să stăm în picioare mai multe cazuri temporale și să punem în aplicare capacitatea de a încărca lucrările care vin între ele. Fiecare dintre multiplele cazuri temporale își menține propria bază de date independentă și grupuri de lucrători, și astfel este izolat de celelalte. Ca obiect de acţiune postmortem de la incidentul din 6 octombrie, am programat deja lucrări de infrastructură care ar fi eliminat blocajul unei singure instanţe temporale şi baze de date Postgres, începând cu 12 octombrie şi aşteptând să dureze 2 săptămâni. Pe 9 octombrie am realizat că această lucrare pur și simplu nu putea aștepta, așa că echipa noastră de inginerie a implementat, testat și rulat o versiune mai simplă a modificărilor planificate în câteva ore. Aceste modificări s-au încheiat cu succes la 01:45 în 10 octombrie. **În plus, schimbăm modul în care stocăm și monitorizăm jurnalele tranzacțiilor.** Baza noastră de date Temporală nu mai foloseşte volumul jurnalului fix. Adăugăm alerte cu privire la cât de departe se află arhivarea jurnalelor şi cât de repede scrie jurnalele în baza de date, astfel încât să putem acţiona cu câteva ore mai devreme decât pe 9 octombrie. **Suntem, de asemenea, revizuirea programul de ștergere temporal.** Temporal şterge munca terminată la câteva zile după ce se execută, astfel încât o zi plină se întoarce ca încărcare de baze de date mai târziu în săptămâna. Ne schimbăm când şi cât de repede merg acele ştergeri. ** Schimbăm modul în care sistemele noastre retry atunci când Temporal este lent.** Pe 9 octombrie, sistemele noastre au refăcut munca eşuată împotriva Temporalului şi au adăugat la sarcina sa. Așa cum ne-am angajat după incidentul din 6 octombrie, ne schimbăm sistemele pentru a aștepta ca Temporalul să-și revină, așa că munca nu este abandonată. ## Conclusion Experienţa clienţilor este prioritatea noastră principală şi ne angajăm să îmbunătăţim în permanenţă fiabilitatea sistemelor noastre pentru a se potrivi cu încrederea pe care o au clienţii noştri în noi. Le mulţumim clienţilor noştri pentru răbdarea lor în timp ce echipa noastră a lucrat pentru a rezolva aceste incidente. Vă rugăm să contactați echipa noastră de sprijin cu orice întrebări sau preocupări.

Traducere automată din actualizarea oficială a incidentului.

1. 8 octombrie 2026 la 13:00 UTCidentified

   Clienţii se pot confrunta cu perioade ridicate de aşteptare pentru maşini. Ne străduim să rezolvăm asta.

2. 8 octombrie 2026 la 13:34 UTCidentified

   Clientii care folosesc masini Linux se confrunta cu perioade de asteptare ridicate, in medie aproximativ 11 minute, cu cele mai lungi asteptari de peste 30 de minute pe medii, brat.mediu si brat.clase de resurse mari. Inginerii noştri au identificat problema şi lucrează la o soluţie. Vom furniza o altă actualizare până la ora 14:00 UTC.

3. 8 octombrie 2026 la 14:04 UTCidentified

   Clienții care utilizează Linux de locuri de muncă mașină se confruntă cu perioade de așteptare ridicate, în medie aproximativ 40 de minute, cu cele mai lungi așteaptă mai mult de 50 de minute. Cele mai multe clase de resurse de mașini Linux sunt afectate, inclusiv medii, mari, xlarge, 2xlarge și echivalentele lor Braț. Inginerii noştri au identificat problema şi lucrează la o soluţie. Vom furniza o altă actualizare până la 14:30 UTC.

4. 8 octombrie 2026 la 14:37 UTCidentified

   Clienții care utilizează Linux mașină de locuri de muncă și Docker la distanță se confruntă cu ore de așteptare ridicate. Timpii de așteptare au început să scadă și acum în medie aproximativ 20 de minute, cu cele mai lungi așteaptă mai mult de 40 de minute pe unele clase de resurse. Inginerii noştri au identificat problema şi lucrează la o soluţie. Vom furniza o altă actualizare până la ora 15:00 UTC.

5. 8 octombrie 2026 la 15:01 UTCidentified

   A fost implementat un fix și timpul de așteptare sunt în scădere, dar clienții care utilizează Linux mașini de locuri de muncă și Remote Docker încă se confruntă cu întârzieri. Așteptați în medie în prezent aproximativ 11 minute, cu cele mai lungi așteaptă mai mult de 35 de minute pe unele clase de resurse. Ne străduim să adăugăm capacitatea cât mai repede posibil. Vom furniza o altă actualizare până la 15:30 UTC.

6. 8 octombrie 2026 la 15:31 UTCidentified

   Timpii de aşteptare continuă să scadă, dar clienţii care folosesc maşini Linux şi Docker de la distanţă se confruntă încă cu întârzieri. Așteptați timpi în prezent medie aproximativ 6 minute. Cele mai lungi așteptați, până la aproximativ 20 de minute, sunt pe 2xlarge, braț.2xlarge și gpu.nvidia. clase mici de resurse. Ne străduim să adăugăm capacitatea cât mai repede posibil. Vom furniza o altă actualizare până la ora 16:00 UTC.

7. 8 octombrie 2026 la 15:59 UTCidentified

   Timpii de aşteptare continuă să scadă, dar clienţii care folosesc maşini Linux şi Docker de la distanţă se confruntă încă cu întârzieri. Așteptați ori în medie în prezent aproximativ 90 de secunde, cu cele mai lungi așteaptă până la aproximativ 6 minute pe unele clase de resurse. Ne străduim să adăugăm capacitatea cât mai repede posibil. Vom furniza o altă actualizare până la 16:30 UTC.

8. 8 octombrie 2026 la 16:09 UTCmonitoring

   Timpii de așteptare pentru clienții care utilizează Linux mașină de locuri de muncă și Docker la distanță au revenit la normal. Monitorizăm pentru a confirma timpul de așteptare rămâne stabil în timp ce continuăm să adăugăm capacitate. Vom furniza o altă actualizare până la 16:30 UTC.

9. 8 octombrie 2026 la 16:35 UTCresolved

   Intre 12:40 UTC si 16:00 UTC pe 8 octombrie, clientii folosind masini Linux si telecomanda Docker au experimentat perioade de asteptare ridicate. Problema a fost rezolvată şi timpul de aşteptare a revenit la normal. Vă mulțumim pentru răbdare în timp ce echipa noastră a lucrat la implementarea unui fix.

10. 8 octombrie 2026 la 17:54 UTCpostmortem

    ## Rezumat Din 1 octombrie, clienții CircleCI au avut mai multe incidente care au cauzat întârzieri și eșecuri în execuția conductei de clienți. Există două \ (neasociate\) cauze, ambele dintre care echipa de inginerie CircleCI este în mod activ atenuarea: * Capacitate disponibilă de calcul al norilor * Infrastructura internă ## Capacitate disponibilă de calcul al norilor * **Problem**: Cererea de cazuri de cloud de înaltă performanță crește extrem de rapid în întreaga industrie, ceea ce pune presiune pe tipurile de instanță furnizor de cloud pe care le folosim pentru a executa locuri de muncă client. * ** Incidente**: (https://status.circleci.com/incidenti/jn756xtsy4xg) * [Creștere a timpului de așteptare pentru Docker Gen2] [https://status.circleci.com/incidenți/39rfrjmk5pvd] * [Nivelul ridicat de infra eșuează asupra locurilor de muncă ale clienților](https://status.circleci.com/incidente/0z31ldjd8m5v) * [Delay on starting Machine Job Tasks](https://status.circleci.com/incidentes/tj6wdnfjwr64) * [Delays starting Gen 2 Docker Jobs](https://status.circleci.com/incidente/22mrv46g6n7g) * **Contenții și rezoluții**: * Extindem setul nostru de regiuni de cloud computing pentru a include regiuni suplimentare cu cazuri de înaltă performanță disponibile. * De asemenea, lucrăm pentru a asigura capacități suplimentare garantate din partea partenerilor noștri de cloud computing din regiunile noastre existente. * Extindem în continuare setul de tipuri de cazuri pe care le putem oferi clienților. * Vom publica un raport detaliat privind incidentele în 9 octombrie 2026. ## Intern Infrastructure * **Problem**: Atribuim fluxurile de lucru ale clienților asupra mai multor furnizori de calcul prin intermediul unui serviciu de orchestrare a fluxului de lucru. Acest serviciu este în prezent poarta de trecere scris de o singură bază de date. * ** Incidente:** * [Delays in tevi, workflows, UI data, and notifications] [https://status.circleci.com/incidens/z4hbq8h49j8c] * [Securitatea infrastructurii de urgență](https://status.circleci.com/incidente/g60yc9bvkmx) * **Contenții și rezoluții**: * Până la 23 octombrie 2026, plănuim să implementăm mai multe cazuri de orchestrare redundantă, fiecare cu propria bază de date, care ne va permite să împărţim sarcina orchestrării între ele. ## Nostru angajament Pentru evitarea îndoielii, * Aceste incidente speciale nu sunt legate de întreruperi în curs la Github * Nu migram in prezent infrastructura sau serviciile noastre * Nu suntem sub atac cibernetic Experienţa clienţilor este prioritatea noastră principală şi ne angajăm să îmbunătăţim în permanenţă fiabilitatea sistemelor noastre pentru a se potrivi cu încrederea pe care o au clienţii noştri în noi. Le mulţumim clienţilor noştri pentru răbdarea lor în timp ce echipa noastră a lucrat pentru a rezolva aceste incidente şi lucrări pentru a preveni incidentele viitoare. Vă rugăm să contactați echipa noastră de sprijin cu orice întrebări sau preocupări.

Traducere automată din actualizarea oficială a incidentului.

1. 7 octombrie 2026 la 18:54 UTCidentified

   Există o creștere a timpului de așteptare pentru locuri de muncă pe Docker Gen2.

2. 7 octombrie 2026 la 19:00 UTCidentified

   Notă: întârzierile vor fi mai vizibile pentru persoanele care rulează pe Docker .

3. 7 octombrie 2026 la 19:52 UTCmonitoring

   Încă vedem piroane în sarcina de așteptare ori dar, în medie, timpii de așteptare sunt în căutarea mai bine pentru toate Docker Gen2.

4. 7 octombrie 2026 la 20:05 UTCresolved

   Acest incident a fost rezolvat.

5. 8 octombrie 2026 la 17:54 UTCpostmortem

   "Summary" Între 1 octombrie și 8 octombrie 2026, clienții CircleCI au experimentat cinci incidente separate în care locurile de muncă au așteptat mai mult decât normal să înceapă sau nu au reușit să înceapă. Trei dintre incidente au fost determinate de disponibilitatea limitată a furnizorului nostru de cloud-uri. Unul a fost cauzat de o problemă de configurare în infrastructura noastră de planificare, și unul de limitele de memorie pe un serviciu intern, pe care am ridicat în timpul incidentului. * **Octombrie 1, 07:57 to 10:24 UTC:** Docker Gen 2 jobs waited up to 30 minutes to start. O problemă de configurare a împiedicat serverele de programare Gen 2 să folosească discurile locale de înaltă performanță. În timpul unei explozii în trafic, discurile de rezervă saturate și plasarea de locuri de muncă încetinit. * **Octombrie 7, 13:27-14:06 UTC:** Maşinile au aşteptat mai mult decât normal pentru că nu am putut achiziţiona suficiente maşini virtuale de la furnizorul nostru de cloud. * **Octombrie 7, 14:24 - 15:21 UTC:** Unele locuri de muncă au eșuat cu o eroare de infrastructură, iar fluxurile de lucru au fost întârziate. Serviciul care oferă fiecare loc de muncă configurația sa la pornire a rămas fără memorie și a reluat. * **Octombrie 7, 18:49 - 20:05 UTC:** Docker Gen 2 de locuri de muncă a așteptat mai mult decât în mod normal, deoarece nu am putut dobândi suficiente cazuri de la furnizorul nostru de cloud. * **Octombrie 8, 12:48-16:00 UTC:** Maşinile Linux şi slujbele de la distanţă Docker aşteaptă până la 50 de minute să înceapă. Furnizorul nostru de cloud nu a avut suficient de tipul de instanță pe care le solicităm, și un defect în logica care alege un tip de instanță diferit ne-a împiedicat să folosim alternative. Locurile de muncă care au aşteptat în timpul acestor incidente au fost întârziate, nu pierdute. Clienții ale căror locuri de muncă au eșuat cu o eroare de infrastructură în timpul incidentului din 7 octombrie de la 14:24 la 15:21 UTC le pot relua. Paginile originale de stare pot fi găsite mai jos: * [1 octombrie - Întârzieri începând cu Gen 2 Docker Jobs](https://status.circleci.com/incidente/22mrv46g6n7g) * [7 octombrie - Întârziere la pornirea lucrărilor mecanicului][https://status.circleci.com/incidente/tj6wdnfjwr64] * [7 octombrie - Nivelul ridicat de infra eșuează asupra locurilor de muncă ale clienților](https://status.circleci.com/incidente/0z31ldjd8m5v) * [7 octombrie - Creșterea timpului de așteptare pentru Docker Gen2] [https://status.circleci.com/incidente/39rfrjmk5pvd] * [8 octombrie - Timpi de așteptare măriți pentru locurile de muncă automate] [https://status.circleci.com/incidente/jn756xtsy4xg] Background Fiecare loc de muncă care rulează pe CircleCI are nevoie de calcul. De unde vine acel calcul depinde de executor. Locuri de muncă Docker rula pe clustere de servere care programează lucrează pe o flotă de cazuri. Programatorul este software-ul de pe acele servere care decide care instanță conduce fiecare loc de muncă. Gen 2 Docker locuri de muncă rula pe un astfel de grup la momentul incidentului octombrie 1. Gen 1 Docker locuri de muncă sunt răspândite în mai multe grupuri. Mașină de locuri de muncă, inclusiv locuri de muncă Docker la distanță, obține o mașină virtuală dedicată. Un loc de muncă Docker la distanță este manipulat ca un loc de muncă mașină Linux de la depunerea prin furnizarea. Serviciul nostru de furnizare de mașini solicită fiecare mașină de la furnizorul nostru de cloud într-una dintre cele două regiuni pe care le folosim în mod normal pentru mașini de locuri de muncă. Atunci când furnizorul nu poate furniza tipul de instanță pe care îl solicităm, serviciul se retrage: solicită un tip de instanță diferit sau o regiune diferită de o listă pe care o menținem. Un loc de muncă așteaptă până când o mașină este disponibilă. Când începe orice post, solicită un serviciu de configurare pentru configurarea sa. Acest serviciu se execută ca un set de capsule, care sunt copii mici ale aceluiași program. Dacă se opresc prea multe capsule, capsulele rămase transportă mai multă încărcătură, iar locurile de muncă nu pot începe până când serviciul nu se recuperează. Aceste căi depind de trei tipuri de capacitate: trecerea de la sistemele noastre de planificare, furnizarea de cazuri de la furnizorul nostru de cloud, și memoria și numărul de copii ale serviciilor care încep locuri de muncă. Un deficit în oricare dintre ele face locuri de muncă așteptați sau nu. Ce s-a întâmplat? \(Toate timpurile UTC\) ### **Octombrie 1: Docker Gen 2 joburi întârziate până la 30 minute La 07:44, activitatea discului pe serverele care programează Gen 2 Docker job-uri a crescut la 90% din capacitate și a rămas acolo. La 07:57, numărul de locuri de muncă Docker de așteptare pentru a începe a început să crească, și de așteptare ori a crescut cu ea. O alertă automată l-a chemat pe inginerul de gardă la 08:08. Am declarat un incident la 08:42. La 08:43, inginerii au identificat latența de mare disc pe serverele de programare. Prima dată au crezut că discurile erau prea lente pentru încărcătură, aşa că au pregătit o schimbare la un tip de disc mai rapid. La 09:01, echipa a convenit asupra a două fluxuri de lucru: mutați serverele pe discuri mai rapide și adăugați un al doilea grup Gen 2 astfel încât locurile de muncă să se împartă în două grupuri. La 09:41, inginerii au găsit cauza. Fiecare server de programare are discuri rapide atașate direct la el, iar programatorul este menit să păstreze datele sale de lucru acolo. Aceste servere ruleaza pe o imagine a sistemului de operare inaltata de securitate, si pe aceasta imagine dischetele rapide nu erau folosite. Programatorul şi-a scris datele pe discuri mai lente. Script-ul care stabilește discurile rapide a eșuat fără o eroare, și un decalaj în logare pe aceste servere ascuns eșecul. De asemenea, traficul de gen 2 a devenit tot mai intens. Discurile mai lente s-au saturat în timpul exploziilor, iar programatorul a rămas în urmă. Timpul de aşteptare a atins apogeul la 09:54, când locurile de muncă din clasa de resurse medii Gen 2 au aşteptat până la 30 de minute. La 09:55, inginerii au aplicat un fix care a instalat discurile rapide corect. La 10:11, programatorul a început să plaseze locuri de muncă mai repede, ceea ce a confirmat serverele ar putea ține pasul cu noi locuri de muncă. Timpul de așteptare pentru Gen 2 mediu a scăzut la 13 minute la 10:14, 7 minute la 10:17, și 1 minut 30 secunde la 10:20. Am mutat pagina de stare la monitorizare la 10:24 şi am rezolvat incidentul la 10:45. La 11:20, cel de-al doilea grup Gen 2 a început să lucreze. Traducerea şi adaptarea: Am declarat un incident la 13:27 după ce am văzut ore ridicate la coadă şi am aşteptat. Am postat pe pagina de stare la 13:31. La 13:31, inginerii au văzut că ne luptam să achiziţionăm maşini virtuale pentru maşini şi că numărul de locuri de muncă care aşteptau să înceapă era ridicat în principal pentru maşini. La 13:34, orele de aşteptare au fost ridicate de către executori. La 13:48, orele de așteptare au început să se recupereze pe măsură ce mai multe mașini au devenit disponibile, și am rezolvat incidentul la 14:06. ## **Octombrie 7, 14:24 la 15:21: Eșecuri de locuri de muncă și întârzieri în fluxul de lucru** La scurt timp după ce incidentul anterior a fost marcat ca fiind rezolvat, am declarat un nou incident la 14:24 din cauza scăderii drastice a numărului de locuri de muncă depuse la sistemele noastre de execuţie. La 14:26, inginerii au văzut că capsulele serviciului de configurare a locurilor de muncă repornesc. Poduri care repornesc lasă mai puține copii ale serviciului pentru a răspunde cererilor, precum și locuri de muncă care nu au putut recupera configurația lor după încercări repetate eșuate cu o eroare de infrastructură. Fluxurile de lucru care deja funcţionau aşteptau actualizări de la locuri de muncă care nu începuseră. La 14:35, inginerii au mărit cantitatea de memorie disponibilă la capsule și au mărit numărul de capsule, care au dat serviciului mai multe copii pentru a partaja încărcătura. De asemenea, am mărit cantitatea de memorie disponibilă a transmiterilor de locuri de muncă a început recuperarea, și numărul de mesaje care curge prin sistemul nostru de flux de lucru a revenit la niveluri normale. La 14:44, am mutat pagina de stare la monitorizare. Podurile din serviciul de configurare a locurilor de muncă au atins limitele de memorie și au repornit. Am mărit alocarea memoriei şi numărul de capsule, iar serviciul s-a recuperat. La 15:13, am crescut numărul de cazuri în clusterele noastre Gen 2 Docker, astfel încât am putea lucra prin backlog-ul de locuri de muncă de așteptare rapid. Am rezolvat incidentul la 15:21. Traducerea şi adaptarea: Am declarat un nou incident la 18:49 după ce Docker Gen 2 s-a ridicat. La 18:51, inginerii au confirmat că o penurie de cazuri disponibile ne-a împiedicat să dobândim destule dintre ele, ceea ce a ridicat timpul de aşteptare. Timpurile de așteptare diferă în funcție de dimensiunea clasei resurselor. La 19:52, timpul mediu de așteptare a fost mai mic de o oră mai devreme ca mai multă capacitate a devenit disponibil, deși piroane scurte a continuat, și am mutat pagina de stare la monitorizare. Am rezolvat incidentul la 20:05. Traducerea şi adaptarea: Am declarat un incident la 12:48 dupa ce am vazut un numar mare de locuri de munca asteptand sa inceapa si sa astepte mult timp pentru masini si locuri de munca la distanta Docker. La 12:49, inginerii au văzut că furnizorul nostru de nori nu putea furniza suficiente cazuri. Întârzierile au continuat să urce în timp ce investigam. La 13:13 am început să examinăm logica care alege un alt tip de instanță sau regiune atunci când prima noastră alegere nu este disponibilă. La 13:24, am suspectat că un defect în această logică ne-a oprit să folosim alte tipuri de cazuri din regiunea noastră primară, așa că am dezactivat regiunea noastră de rezervă și am confirmat cauza defectului. Inginerii au început să lucreze la un fix şi l-au desfăşurat la 14:49. Serviciul a început să solicite alte tipuri de instanță și a pornit mașini în număr mare. La 14:58, coada de locuri de muncă de așteptare pentru o mașină a scăzut constant. Timpii mediui de așteptare în cadrul cursurilor de resurse au continuat să scadă în următoarea oră, în timp ce lucram prin backlog-ul locurilor de muncă în așteptare. La ora 16:00, coada de locuri de muncă de așteptare pentru o mașină curățată și numărul de locuri de muncă în așteptare a revenit la normal. Am mutat pagina de stare la monitorizare la 16:09 şi am rezolvat incidentul la 16:35. Traducerea şi adaptarea: Luăm următoarele măsuri pentru a consolida reziliența timpilor de începere a locurilor de muncă, inclusiv diversificarea ofertei, logica de rezervă și detectarea timpurie. ** Ne extindem regiunile de calcul.** În incidentele din 7 octombrie și 8 octombrie, furnizorul nostru de clouduri nu a putut furniza suficiente cazuri în regiunile pe care le-am folosit. Adăugăm noi regiuni la logica noastră de rezervă pentru a manevra piroane pentru cerere care depășesc regiunile noastre preferate. **Reparam logica care alege un alt tip de instanta.** La 8 octombrie, un defect a împiedicat serviciul de furnizare de mașini să utilizeze alte tipuri de cazuri din aceeași regiune. Am implementat o soluţie în timpul incidentului şi acum revizuim şi refacem această logică ca un întreg, cu teste, astfel încât o lipsă de un tip de instanţă se mută la altul. ** Extindem tipurile de cazuri pe care le oferim și asigurarea capacității suplimentare.** Lucrăm cu furnizorul nostru de cloud-uri pentru a rezerva capacități suplimentare în regiunile noastre existente și adăugăm tipuri de exemple pe care locurile de muncă le pot desfășura. Cererea industriei de calcul de înaltă performanță este în creștere. Diversificăm unde și modul în care avem capacitatea de sursă astfel încât clienții noștri să fie izolați de variația ofertei. **Am adăugat un al doilea grup Gen 2 Docker, astfel încât exploziile de trafic sunt distribuite în două grupuri.** De asemenea, adăugăm alerte cu privire la programarea saturaţiei pe discul serverului şi la cât de repede plasează programatorul locuri de muncă, şi o alertă care trage atunci când un server începe fără discurile sale rapide în uz. Am făcut script-ul de configurare disc eșua cu o eroare, și am restaurat transportul jurnal de pe aceste servere, astfel încât o problemă similară este vizibilă mai devreme. Experienţa clienţilor este prioritatea noastră principală şi ne angajăm să îmbunătăţim în permanenţă fiabilitatea sistemelor noastre pentru a se potrivi cu încrederea pe care o au clienţii noştri în noi. Le mulţumim clienţilor noştri pentru răbdarea lor în timp ce echipa noastră a lucrat pentru a rezolva aceste incidente. Vă rugăm să contactați echipa noastră de sprijin cu orice întrebări sau preocupări.

Traducere automată din actualizarea oficială a incidentului.

1. 7 octombrie 2026 la 14:27 UTCinvestigating

   Investigăm o creştere a infraroşu pentru clienţi.

2. 7 octombrie 2026 la 14:44 UTCmonitoring

   Vedem semne de recuperare. Docker Gen2 wait times sunt ușor ridicate și suntem de monitorizare.

3. 7 octombrie 2026 la 15:21 UTCresolved

   Acest incident a fost rezolvat.

4. 8 octombrie 2026 la 17:55 UTCpostmortem

   "Summary" Între 1 octombrie și 8 octombrie 2026, clienții CircleCI au experimentat cinci incidente separate în care locurile de muncă au așteptat mai mult decât normal să înceapă sau nu au reușit să înceapă. Trei dintre incidente au fost determinate de disponibilitatea limitată a furnizorului nostru de cloud-uri. Unul a fost cauzat de o problemă de configurare în infrastructura noastră de planificare, și unul de limitele de memorie pe un serviciu intern, pe care am ridicat în timpul incidentului. * **Octombrie 1, 07:57 to 10:24 UTC:** Docker Gen 2 jobs waited up to 30 minutes to start. O problemă de configurare a împiedicat serverele de programare Gen 2 să folosească discurile locale de înaltă performanță. În timpul unei explozii în trafic, discurile de rezervă saturate și plasarea de locuri de muncă încetinit. * **Octombrie 7, 13:27-14:06 UTC:** Maşinile au aşteptat mai mult decât normal pentru că nu am putut achiziţiona suficiente maşini virtuale de la furnizorul nostru de cloud. * **Octombrie 7, 14:24 - 15:21 UTC:** Unele locuri de muncă au eșuat cu o eroare de infrastructură, iar fluxurile de lucru au fost întârziate. Serviciul care oferă fiecare loc de muncă configurația sa la pornire a rămas fără memorie și a reluat. * **Octombrie 7, 18:49 - 20:05 UTC:** Docker Gen 2 de locuri de muncă a așteptat mai mult decât în mod normal, deoarece nu am putut dobândi suficiente cazuri de la furnizorul nostru de cloud. * **Octombrie 8, 12:48-16:00 UTC:** Maşinile Linux şi slujbele de la distanţă Docker aşteaptă până la 50 de minute să înceapă. Furnizorul nostru de cloud nu a avut suficient de tipul de instanță pe care le solicităm, și un defect în logica care alege un tip de instanță diferit ne-a împiedicat să folosim alternative. Locurile de muncă care au aşteptat în timpul acestor incidente au fost întârziate, nu pierdute. Clienții ale căror locuri de muncă au eșuat cu o eroare de infrastructură în timpul incidentului din 7 octombrie de la 14:24 la 15:21 UTC le pot relua. Paginile originale de stare pot fi găsite mai jos: * [1 octombrie - Întârzieri începând cu Gen 2 Docker Jobs](https://status.circleci.com/incidente/22mrv46g6n7g) * [7 octombrie - Întârziere la pornirea lucrărilor mecanicului][https://status.circleci.com/incidente/tj6wdnfjwr64] * [7 octombrie - Nivelul ridicat de infra eșuează asupra locurilor de muncă ale clienților](https://status.circleci.com/incidente/0z31ldjd8m5v) * [7 octombrie - Creșterea timpului de așteptare pentru Docker Gen2] [https://status.circleci.com/incidente/39rfrjmk5pvd] * [8 octombrie - Timpi de așteptare măriți pentru locurile de muncă automate] [https://status.circleci.com/incidente/jn756xtsy4xg] Background Fiecare loc de muncă care rulează pe CircleCI are nevoie de calcul. De unde vine acel calcul depinde de executor. Locuri de muncă Docker rula pe clustere de servere care programează lucrează pe o flotă de cazuri. Programatorul este software-ul de pe acele servere care decide care instanță conduce fiecare loc de muncă. Gen 2 Docker locuri de muncă rula pe un astfel de grup la momentul incidentului octombrie 1. Gen 1 Docker locuri de muncă sunt răspândite în mai multe grupuri. Mașină de locuri de muncă, inclusiv locuri de muncă Docker la distanță, obține o mașină virtuală dedicată. Un loc de muncă Docker la distanță este manipulat ca un loc de muncă mașină Linux de la depunerea prin furnizarea. Serviciul nostru de furnizare de mașini solicită fiecare mașină de la furnizorul nostru de cloud într-una dintre cele două regiuni pe care le folosim în mod normal pentru mașini de locuri de muncă. Atunci când furnizorul nu poate furniza tipul de instanță pe care îl solicităm, serviciul se retrage: solicită un tip de instanță diferit sau o regiune diferită de o listă pe care o menținem. Un loc de muncă așteaptă până când o mașină este disponibilă. Când începe orice post, solicită un serviciu de configurare pentru configurarea sa. Acest serviciu se execută ca un set de capsule, care sunt copii mici ale aceluiași program. Dacă se opresc prea multe capsule, capsulele rămase transportă mai multă încărcătură, iar locurile de muncă nu pot începe până când serviciul nu se recuperează. Aceste căi depind de trei tipuri de capacitate: trecerea de la sistemele noastre de planificare, furnizarea de cazuri de la furnizorul nostru de cloud, și memoria și numărul de copii ale serviciilor care încep locuri de muncă. Un deficit în oricare dintre ele face locuri de muncă așteptați sau nu. Ce s-a întâmplat? \(Toate timpurile UTC\) ### **Octombrie 1: Docker Gen 2 joburi întârziate până la 30 minute La 07:44, activitatea discului pe serverele care programează Gen 2 Docker job-uri a crescut la 90% din capacitate și a rămas acolo. La 07:57, numărul de locuri de muncă Docker de așteptare pentru a începe a început să crească, și de așteptare ori a crescut cu ea. O alertă automată l-a chemat pe inginerul de gardă la 08:08. Am declarat un incident la 08:42. La 08:43, inginerii au identificat latența de mare disc pe serverele de programare. Prima dată au crezut că discurile erau prea lente pentru încărcătură, aşa că au pregătit o schimbare la un tip de disc mai rapid. La 09:01, echipa a convenit asupra a două fluxuri de lucru: mutați serverele pe discuri mai rapide și adăugați un al doilea grup Gen 2 astfel încât locurile de muncă să se împartă în două grupuri. La 09:41, inginerii au găsit cauza. Fiecare server de programare are discuri rapide atașate direct la el, iar programatorul este menit să păstreze datele sale de lucru acolo. Aceste servere ruleaza pe o imagine a sistemului de operare inaltata de securitate, si pe aceasta imagine dischetele rapide nu erau folosite. Programatorul şi-a scris datele pe discuri mai lente. Script-ul care stabilește discurile rapide a eșuat fără o eroare, și un decalaj în logare pe aceste servere ascuns eșecul. De asemenea, traficul de gen 2 a devenit tot mai intens. Discurile mai lente s-au saturat în timpul exploziilor, iar programatorul a rămas în urmă. Timpul de aşteptare a atins apogeul la 09:54, când locurile de muncă din clasa de resurse medii Gen 2 au aşteptat până la 30 de minute. La 09:55, inginerii au aplicat un fix care a instalat discurile rapide corect. La 10:11, programatorul a început să plaseze locuri de muncă mai repede, ceea ce a confirmat serverele ar putea ține pasul cu noi locuri de muncă. Timpul de așteptare pentru Gen 2 mediu a scăzut la 13 minute la 10:14, 7 minute la 10:17, și 1 minut 30 secunde la 10:20. Am mutat pagina de stare la monitorizare la 10:24 şi am rezolvat incidentul la 10:45. La 11:20, cel de-al doilea grup Gen 2 a început să lucreze. Traducerea şi adaptarea: Am declarat un incident la 13:27 după ce am văzut ore ridicate la coadă şi am aşteptat. Am postat pe pagina de stare la 13:31. La 13:31, inginerii au văzut că ne luptam să achiziţionăm maşini virtuale pentru maşini şi că numărul de locuri de muncă care aşteptau să înceapă era ridicat în principal pentru maşini. La 13:34, orele de aşteptare au fost ridicate de către executori. La 13:48, orele de așteptare au început să se recupereze pe măsură ce mai multe mașini au devenit disponibile, și am rezolvat incidentul la 14:06. ## **Octombrie 7, 14:24 la 15:21: Eșecuri de locuri de muncă și întârzieri în fluxul de lucru** La scurt timp după ce incidentul anterior a fost marcat ca fiind rezolvat, am declarat un nou incident la 14:24 din cauza scăderii drastice a numărului de locuri de muncă depuse la sistemele noastre de execuţie. La 14:26, inginerii au văzut că capsulele serviciului de configurare a locurilor de muncă repornesc. Poduri care repornesc lasă mai puține copii ale serviciului pentru a răspunde cererilor, precum și locuri de muncă care nu au putut recupera configurația lor după încercări repetate eșuate cu o eroare de infrastructură. Fluxurile de lucru care deja funcţionau aşteptau actualizări de la locuri de muncă care nu începuseră. La 14:35, inginerii au mărit cantitatea de memorie disponibilă la capsule și au mărit numărul de capsule, care au dat serviciului mai multe copii pentru a partaja încărcătura. De asemenea, am mărit cantitatea de memorie disponibilă a transmiterilor de locuri de muncă a început recuperarea, și numărul de mesaje care curge prin sistemul nostru de flux de lucru a revenit la niveluri normale. La 14:44, am mutat pagina de stare la monitorizare. Podurile din serviciul de configurare a locurilor de muncă au atins limitele de memorie și au repornit. Am mărit alocarea memoriei şi numărul de capsule, iar serviciul s-a recuperat. La 15:13, am crescut numărul de cazuri în clusterele noastre Gen 2 Docker, astfel încât am putea lucra prin backlog-ul de locuri de muncă de așteptare rapid. Am rezolvat incidentul la 15:21. Traducerea şi adaptarea: Am declarat un nou incident la 18:49 după ce Docker Gen 2 s-a ridicat. La 18:51, inginerii au confirmat că o penurie de cazuri disponibile ne-a împiedicat să dobândim destule dintre ele, ceea ce a ridicat timpul de aşteptare. Timpurile de așteptare diferă în funcție de dimensiunea clasei resurselor. La 19:52, timpul mediu de așteptare a fost mai mic de o oră mai devreme ca mai multă capacitate a devenit disponibil, deși piroane scurte a continuat, și am mutat pagina de stare la monitorizare. Am rezolvat incidentul la 20:05. Traducerea şi adaptarea: Am declarat un incident la 12:48 dupa ce am vazut un numar mare de locuri de munca asteptand sa inceapa si sa astepte mult timp pentru masini si locuri de munca la distanta Docker. La 12:49, inginerii au văzut că furnizorul nostru de nori nu putea furniza suficiente cazuri. Întârzierile au continuat să urce în timp ce investigam. La 13:13 am început să examinăm logica care alege un alt tip de instanță sau regiune atunci când prima noastră alegere nu este disponibilă. La 13:24, am suspectat că un defect în această logică ne-a oprit să folosim alte tipuri de cazuri din regiunea noastră primară, așa că am dezactivat regiunea noastră de rezervă și am confirmat cauza defectului. Inginerii au început să lucreze la un fix şi l-au desfăşurat la 14:49. Serviciul a început să solicite alte tipuri de instanță și a pornit mașini în număr mare. La 14:58, coada de locuri de muncă de așteptare pentru o mașină a scăzut constant. Timpii mediui de așteptare în cadrul cursurilor de resurse au continuat să scadă în următoarea oră, în timp ce lucram prin backlog-ul locurilor de muncă în așteptare. La ora 16:00, coada de locuri de muncă de așteptare pentru o mașină curățată și numărul de locuri de muncă în așteptare a revenit la normal. Am mutat pagina de stare la monitorizare la 16:09 şi am rezolvat incidentul la 16:35. Traducerea şi adaptarea: Luăm următoarele măsuri pentru a consolida reziliența timpilor de începere a locurilor de muncă, inclusiv diversificarea ofertei, logica de rezervă și detectarea timpurie. ** Ne extindem regiunile de calcul.** În incidentele din 7 octombrie și 8 octombrie, furnizorul nostru de clouduri nu a putut furniza suficiente cazuri în regiunile pe care le-am folosit. Adăugăm noi regiuni la logica noastră de rezervă pentru a manevra piroane pentru cerere care depășesc regiunile noastre preferate. **Reparam logica care alege un alt tip de instanta.** La 8 octombrie, un defect a împiedicat serviciul de furnizare de mașini să utilizeze alte tipuri de cazuri din aceeași regiune. Am implementat o soluţie în timpul incidentului şi acum revizuim şi refacem această logică ca un întreg, cu teste, astfel încât o lipsă de un tip de instanţă se mută la altul. ** Extindem tipurile de cazuri pe care le oferim și asigurarea capacității suplimentare.** Lucrăm cu furnizorul nostru de cloud-uri pentru a rezerva capacități suplimentare în regiunile noastre existente și adăugăm tipuri de exemple pe care locurile de muncă le pot desfășura. Cererea industriei de calcul de înaltă performanță este în creștere. Diversificăm unde și modul în care avem capacitatea de sursă astfel încât clienții noștri să fie izolați de variația ofertei. **Am adăugat un al doilea grup Gen 2 Docker, astfel încât exploziile de trafic sunt distribuite în două grupuri.** De asemenea, adăugăm alerte cu privire la programarea saturaţiei pe discul serverului şi la cât de repede plasează programatorul locuri de muncă, şi o alertă care trage atunci când un server începe fără discurile sale rapide în uz. Am făcut script-ul de configurare disc eșua cu o eroare, și am restaurat transportul jurnal de pe aceste servere, astfel încât o problemă similară este vizibilă mai devreme. Experienţa clienţilor este prioritatea noastră principală şi ne angajăm să îmbunătăţim în permanenţă fiabilitatea sistemelor noastre pentru a se potrivi cu încrederea pe care o au clienţii noştri în noi. Le mulţumim clienţilor noştri pentru răbdarea lor în timp ce echipa noastră a lucrat pentru a rezolva aceste incidente. Vă rugăm să contactați echipa noastră de sprijin cu orice întrebări sau preocupări.

Traducere automată din actualizarea oficială a incidentului.

1. 7 octombrie 2026 la 13:40 UTCinvestigating

   Clientii pot experimenta momente de asteptare ridicate pentru Machine Job Tasks, noi investighează cauza rădăcină și va actualiza atunci când știm mai multe.

2. 7 octombrie 2026 la 13:52 UTCmonitoring

   Vedem semne de redresare şi monitorizare a situaţiei.

3. 7 octombrie 2026 la 14:06 UTCresolved

   Incidentul a fost rezolvat. Mulţumesc pentru răbdare

4. 8 octombrie 2026 la 17:55 UTCpostmortem

   "Summary" Între 1 octombrie și 8 octombrie 2026, clienții CircleCI au experimentat cinci incidente separate în care locurile de muncă au așteptat mai mult decât normal să înceapă sau nu au reușit să înceapă. Trei dintre incidente au fost determinate de disponibilitatea limitată a furnizorului nostru de cloud-uri. Unul a fost cauzat de o problemă de configurare în infrastructura noastră de planificare, și unul de limitele de memorie pe un serviciu intern, pe care am ridicat în timpul incidentului. * **Octombrie 1, 07:57 to 10:24 UTC:** Docker Gen 2 jobs waited up to 30 minutes to start. O problemă de configurare a împiedicat serverele de programare Gen 2 să folosească discurile locale de înaltă performanță. În timpul unei explozii în trafic, discurile de rezervă saturate și plasarea de locuri de muncă încetinit. * **Octombrie 7, 13:27-14:06 UTC:** Maşinile au aşteptat mai mult decât normal pentru că nu am putut achiziţiona suficiente maşini virtuale de la furnizorul nostru de cloud. * **Octombrie 7, 14:24 - 15:21 UTC:** Unele locuri de muncă au eșuat cu o eroare de infrastructură, iar fluxurile de lucru au fost întârziate. Serviciul care oferă fiecare loc de muncă configurația sa la pornire a rămas fără memorie și a reluat. * **Octombrie 7, 18:49 - 20:05 UTC:** Docker Gen 2 de locuri de muncă a așteptat mai mult decât în mod normal, deoarece nu am putut dobândi suficiente cazuri de la furnizorul nostru de cloud. * **Octombrie 8, 12:48-16:00 UTC:** Maşinile Linux şi slujbele de la distanţă Docker aşteaptă până la 50 de minute să înceapă. Furnizorul nostru de cloud nu a avut suficient de tipul de instanță pe care le solicităm, și un defect în logica care alege un tip de instanță diferit ne-a împiedicat să folosim alternative. Locurile de muncă care au aşteptat în timpul acestor incidente au fost întârziate, nu pierdute. Clienții ale căror locuri de muncă au eșuat cu o eroare de infrastructură în timpul incidentului din 7 octombrie de la 14:24 la 15:21 UTC le pot relua. Paginile originale de stare pot fi găsite mai jos: * [1 octombrie - Întârzieri începând cu Gen 2 Docker Jobs](https://status.circleci.com/incidente/22mrv46g6n7g) * [7 octombrie - Întârziere la pornirea lucrărilor mecanicului][https://status.circleci.com/incidente/tj6wdnfjwr64] * [7 octombrie - Nivelul ridicat de infra eșuează asupra locurilor de muncă ale clienților](https://status.circleci.com/incidente/0z31ldjd8m5v) * [7 octombrie - Creșterea timpului de așteptare pentru Docker Gen2] [https://status.circleci.com/incidente/39rfrjmk5pvd] * [8 octombrie - Timpi de așteptare măriți pentru locurile de muncă automate] [https://status.circleci.com/incidente/jn756xtsy4xg] Background Fiecare loc de muncă care rulează pe CircleCI are nevoie de calcul. De unde vine acel calcul depinde de executor. Locuri de muncă Docker rula pe clustere de servere care programează lucrează pe o flotă de cazuri. Programatorul este software-ul de pe acele servere care decide care instanță conduce fiecare loc de muncă. Gen 2 Docker locuri de muncă rula pe un astfel de grup la momentul incidentului octombrie 1. Gen 1 Docker locuri de muncă sunt răspândite în mai multe grupuri. Mașină de locuri de muncă, inclusiv locuri de muncă Docker la distanță, obține o mașină virtuală dedicată. Un loc de muncă Docker la distanță este manipulat ca un loc de muncă mașină Linux de la depunerea prin furnizarea. Serviciul nostru de furnizare de mașini solicită fiecare mașină de la furnizorul nostru de cloud într-una dintre cele două regiuni pe care le folosim în mod normal pentru mașini de locuri de muncă. Atunci când furnizorul nu poate furniza tipul de instanță pe care îl solicităm, serviciul se retrage: solicită un tip de instanță diferit sau o regiune diferită de o listă pe care o menținem. Un loc de muncă așteaptă până când o mașină este disponibilă. Când începe orice post, solicită un serviciu de configurare pentru configurarea sa. Acest serviciu se execută ca un set de capsule, care sunt copii mici ale aceluiași program. Dacă se opresc prea multe capsule, capsulele rămase transportă mai multă încărcătură, iar locurile de muncă nu pot începe până când serviciul nu se recuperează. Aceste căi depind de trei tipuri de capacitate: trecerea de la sistemele noastre de planificare, furnizarea de cazuri de la furnizorul nostru de cloud, și memoria și numărul de copii ale serviciilor care încep locuri de muncă. Un deficit în oricare dintre ele face locuri de muncă așteptați sau nu. Ce s-a întâmplat? \(Toate timpurile UTC\) ### **Octombrie 1: Docker Gen 2 joburi întârziate până la 30 minute La 07:44, activitatea discului pe serverele care programează Gen 2 Docker job-uri a crescut la 90% din capacitate și a rămas acolo. La 07:57, numărul de locuri de muncă Docker de așteptare pentru a începe a început să crească, și de așteptare ori a crescut cu ea. O alertă automată l-a chemat pe inginerul de gardă la 08:08. Am declarat un incident la 08:42. La 08:43, inginerii au identificat latența de mare disc pe serverele de programare. Prima dată au crezut că discurile erau prea lente pentru încărcătură, aşa că au pregătit o schimbare la un tip de disc mai rapid. La 09:01, echipa a convenit asupra a două fluxuri de lucru: mutați serverele pe discuri mai rapide și adăugați un al doilea grup Gen 2 astfel încât locurile de muncă să se împartă în două grupuri. La 09:41, inginerii au găsit cauza. Fiecare server de programare are discuri rapide atașate direct la el, iar programatorul este menit să păstreze datele sale de lucru acolo. Aceste servere ruleaza pe o imagine a sistemului de operare inaltata de securitate, si pe aceasta imagine dischetele rapide nu erau folosite. Programatorul şi-a scris datele pe discuri mai lente. Script-ul care stabilește discurile rapide a eșuat fără o eroare, și un decalaj în logare pe aceste servere ascuns eșecul. De asemenea, traficul de gen 2 a devenit tot mai intens. Discurile mai lente s-au saturat în timpul exploziilor, iar programatorul a rămas în urmă. Timpul de aşteptare a atins apogeul la 09:54, când locurile de muncă din clasa de resurse medii Gen 2 au aşteptat până la 30 de minute. La 09:55, inginerii au aplicat un fix care a instalat discurile rapide corect. La 10:11, programatorul a început să plaseze locuri de muncă mai repede, ceea ce a confirmat serverele ar putea ține pasul cu noi locuri de muncă. Timpul de așteptare pentru Gen 2 mediu a scăzut la 13 minute la 10:14, 7 minute la 10:17, și 1 minut 30 secunde la 10:20. Am mutat pagina de stare la monitorizare la 10:24 şi am rezolvat incidentul la 10:45. La 11:20, cel de-al doilea grup Gen 2 a început să lucreze. Traducerea şi adaptarea: Am declarat un incident la 13:27 după ce am văzut ore ridicate la coadă şi am aşteptat. Am postat pe pagina de stare la 13:31. La 13:31, inginerii au văzut că ne luptam să achiziţionăm maşini virtuale pentru maşini şi că numărul de locuri de muncă care aşteptau să înceapă era ridicat în principal pentru maşini. La 13:34, orele de aşteptare au fost ridicate de către executori. La 13:48, orele de așteptare au început să se recupereze pe măsură ce mai multe mașini au devenit disponibile, și am rezolvat incidentul la 14:06. ## **Octombrie 7, 14:24 la 15:21: Eșecuri de locuri de muncă și întârzieri în fluxul de lucru** La scurt timp după ce incidentul anterior a fost marcat ca fiind rezolvat, am declarat un nou incident la 14:24 din cauza scăderii drastice a numărului de locuri de muncă depuse la sistemele noastre de execuţie. La 14:26, inginerii au văzut că capsulele serviciului de configurare a locurilor de muncă repornesc. Poduri care repornesc lasă mai puține copii ale serviciului pentru a răspunde cererilor, precum și locuri de muncă care nu au putut recupera configurația lor după încercări repetate eșuate cu o eroare de infrastructură. Fluxurile de lucru care deja funcţionau aşteptau actualizări de la locuri de muncă care nu începuseră. La 14:35, inginerii au mărit cantitatea de memorie disponibilă la capsule și au mărit numărul de capsule, care au dat serviciului mai multe copii pentru a partaja încărcătura. De asemenea, am mărit cantitatea de memorie disponibilă a transmiterilor de locuri de muncă a început recuperarea, și numărul de mesaje care curge prin sistemul nostru de flux de lucru a revenit la niveluri normale. La 14:44, am mutat pagina de stare la monitorizare. Podurile din serviciul de configurare a locurilor de muncă au atins limitele de memorie și au repornit. Am mărit alocarea memoriei şi numărul de capsule, iar serviciul s-a recuperat. La 15:13, am crescut numărul de cazuri în clusterele noastre Gen 2 Docker, astfel încât am putea lucra prin backlog-ul de locuri de muncă de așteptare rapid. Am rezolvat incidentul la 15:21. Traducerea şi adaptarea: Am declarat un nou incident la 18:49 după ce Docker Gen 2 s-a ridicat. La 18:51, inginerii au confirmat că o penurie de cazuri disponibile ne-a împiedicat să dobândim destule dintre ele, ceea ce a ridicat timpul de aşteptare. Timpurile de așteptare diferă în funcție de dimensiunea clasei resurselor. La 19:52, timpul mediu de așteptare a fost mai mic de o oră mai devreme ca mai multă capacitate a devenit disponibil, deși piroane scurte a continuat, și am mutat pagina de stare la monitorizare. Am rezolvat incidentul la 20:05. Traducerea şi adaptarea: Am declarat un incident la 12:48 dupa ce am vazut un numar mare de locuri de munca asteptand sa inceapa si sa astepte mult timp pentru masini si locuri de munca la distanta Docker. La 12:49, inginerii au văzut că furnizorul nostru de nori nu putea furniza suficiente cazuri. Întârzierile au continuat să urce în timp ce investigam. La 13:13 am început să examinăm logica care alege un alt tip de instanță sau regiune atunci când prima noastră alegere nu este disponibilă. La 13:24, am suspectat că un defect în această logică ne-a oprit să folosim alte tipuri de cazuri din regiunea noastră primară, așa că am dezactivat regiunea noastră de rezervă și am confirmat cauza defectului. Inginerii au început să lucreze la un fix şi l-au desfăşurat la 14:49. Serviciul a început să solicite alte tipuri de instanță și a pornit mașini în număr mare. La 14:58, coada de locuri de muncă de așteptare pentru o mașină a scăzut constant. Timpii mediui de așteptare în cadrul cursurilor de resurse au continuat să scadă în următoarea oră, în timp ce lucram prin backlog-ul locurilor de muncă în așteptare. La ora 16:00, coada de locuri de muncă de așteptare pentru o mașină curățată și numărul de locuri de muncă în așteptare a revenit la normal. Am mutat pagina de stare la monitorizare la 16:09 şi am rezolvat incidentul la 16:35. Traducerea şi adaptarea: Luăm următoarele măsuri pentru a consolida reziliența timpilor de începere a locurilor de muncă, inclusiv diversificarea ofertei, logica de rezervă și detectarea timpurie. ** Ne extindem regiunile de calcul.** În incidentele din 7 octombrie și 8 octombrie, furnizorul nostru de clouduri nu a putut furniza suficiente cazuri în regiunile pe care le-am folosit. Adăugăm noi regiuni la logica noastră de rezervă pentru a manevra piroane pentru cerere care depășesc regiunile noastre preferate. **Reparam logica care alege un alt tip de instanta.** La 8 octombrie, un defect a împiedicat serviciul de furnizare de mașini să utilizeze alte tipuri de cazuri din aceeași regiune. Am implementat o soluţie în timpul incidentului şi acum revizuim şi refacem această logică ca un întreg, cu teste, astfel încât o lipsă de un tip de instanţă se mută la altul. ** Extindem tipurile de cazuri pe care le oferim și asigurarea capacității suplimentare.** Lucrăm cu furnizorul nostru de cloud-uri pentru a rezerva capacități suplimentare în regiunile noastre existente și adăugăm tipuri de exemple pe care locurile de muncă le pot desfășura. Cererea industriei de calcul de înaltă performanță este în creștere. Diversificăm unde și modul în care avem capacitatea de sursă astfel încât clienții noștri să fie izolați de variația ofertei. **Am adăugat un al doilea grup Gen 2 Docker, astfel încât exploziile de trafic sunt distribuite în două grupuri.** De asemenea, adăugăm alerte cu privire la programarea saturaţiei pe discul serverului şi la cât de repede plasează programatorul locuri de muncă, şi o alertă care trage atunci când un server începe fără discurile sale rapide în uz. Am făcut script-ul de configurare disc eșua cu o eroare, și am restaurat transportul jurnal de pe aceste servere, astfel încât o problemă similară este vizibilă mai devreme. Experienţa clienţilor este prioritatea noastră principală şi ne angajăm să îmbunătăţim în permanenţă fiabilitatea sistemelor noastre pentru a se potrivi cu încrederea pe care o au clienţii noştri în noi. Le mulţumim clienţilor noştri pentru răbdarea lor în timp ce echipa noastră a lucrat pentru a rezolva aceste incidente. Vă rugăm să contactați echipa noastră de sprijin cu orice întrebări sau preocupări.

Traducere automată din actualizarea oficială a incidentului.

1. 6 octombrie 2026 la 16:00 UTCinvestigating

   Ce s-a întâmplat? Clienții care utilizează conducte și fluxuri de lucru CircleCI, inclusiv afișarea de date UI, notificări outbound, și outbound webhooks. La ce te poţi aştepta? Întârzieri în crearea conductelor, în fluxul de lucru şi în începerea locurilor de muncă. Locurile de muncă, fluxul de lucru și datele conductei pot dura până la 15 minute pentru a apărea în UI. Notificările outbound și site-uri web sunt întârziate cu până la 1 minut. Următoarea actualizare Vom furniza o altă actualizare în termen de 30 de minute sau ca avem mai multe informații pentru a partaja.

2. 6 octombrie 2026 la 16:10 UTCinvestigating

   Începând cu ora 15:47 UTC, clienții pot vedea, de asemenea, locuri de muncă eșuate, pe lângă întârzierile raportate anterior. Inginerii noştri continuă să investigheze şi să atenueze problema.

3. 6 octombrie 2026 la 16:31 UTCidentified

   Începând cu ora 16:02 UTC, conductele cedează în întregime, astfel încât nu există noi fluxuri de lucru sau locuri de muncă în acest moment. Acest lucru se adaugă întârzierilor și locurilor de muncă eșuate raportate mai devreme. Inginerii noştri continuă să lucreze la atenuarea problemei şi vom împărtăşi mai multe informaţii imediat ce le vom avea.

4. 6 octombrie 2026 la 16:42 UTCidentified

   Începând cu ora 16:39 UTC, începem să vedem redresarea pentru noile conducte și fluxuri de lucru transmise, iar locurile de muncă încep să curgă din nou. Inginerii noştri continuă să lucreze la recuperare şi vor împărtăşi mai multe informaţii imediat ce le vom avea.

5. 6 octombrie 2026 la 17:21 UTCidentified

   În timp ce conductele, fluxurile de lucru şi locurile de muncă funcţionează din nou, clienţii pot continua să vadă întârzieri mai mari decât de obicei între locurile de muncă într-un flux de lucru, iar notificările de ieşire sunt întârziate cu aproximativ 1 minut. Notificările și actualizările de stare ale sistemului de control al versiunii încep să apară din nou. Inginerii noştri continuă să lucreze pentru o recuperare completă.

6. 6 octombrie 2026 la 18:04 UTCidentified

   Clienții continuă să experimenteze întârzieri mai mari decât de obicei între locurile de muncă într-un flux de lucru, precum și întârzieri în notificările de ieșire. Vă mulțumim pentru răbdare în timp ce inginerii noștri continuă să investigheze și să lucreze la atenuarea problemei. Vom împărtăși o altă actualizare în următoarele 30 de minute, sau mai devreme dacă mai multe informații devin disponibile.

7. 6 octombrie 2026 la 18:55 UTCidentified

   Clienții continuă să experimenteze întârzieri mai mari decât de obicei înainte ca fluxurile de lucru și locurile de muncă să înceapă, în unele cazuri până la aproximativ 30 de minute. Acest lucru este îmbunătățit de la începutul incidentului, dar întârzierile rămân. S-au îmbunătățit întârzierile în notificările de ieșire. Va multumim pentru rabdare in timp ce inginerii nostri continua sa lucreze pentru restaurarea orelor normale de lucru. Vom împărtăși o altă actualizare în următoarele 30 de minute, sau mai devreme dacă mai multe informații devin disponibile.

8. 6 octombrie 2026 la 19:16 UTCidentified

   Clienţii continuă să aibă întârzieri. Majoritatea încep acum în aproximativ 20 de minute, îmbunătăţite cu aproximativ 40 de minute mai devreme în incident. Un număr foarte mic de fluxuri de lucru poate fi așteptat mai mult de o oră. Inginerii noştri au făcut schimbări care au îmbunătăţit stabilitatea serviciilor, iar întârzierea rămasă se datorează unui backlog de muncă care s-a construit în timpul incidentului. Rezervorul este în scădere, și ne concentrăm pe compensare-l mai repede. Vom împărtăși mai multe informații pe măsură ce progresul continuă. Vă mulțumim pentru răbdare în timp ce inginerii noștri lucrează prin backlog. Vom împărtăși o altă actualizare în următoarele 30 de minute, sau mai devreme dacă mai multe informații devin disponibile.

9. 6 octombrie 2026 la 19:51 UTCidentified

   Întârzierile pentru ca fluxurile de muncă și locurile de muncă să înceapă continuă să scadă. Majoritatea încep acum în aproximativ 10 minute, îmbunătăţite cu aproximativ 40 de minute mai devreme în incident. Un număr foarte mic de fluxuri de lucru poate fi așteptat mai mult de o oră. Dacă slujba ta nu a reuşit să înceapă, te rog să refaci slujba. S-au îmbunătățit întârzierile în notificările de ieșire. Întârzierea rămasă se datorează unui backlog de muncă care s-a construit în timpul incidentului, iar acest backlog a scăzut cu mai mult de jumătate. Ne aşteptăm ca registrul să fie eliberat în aproximativ 15 minute. Vom împărtăși o altă actualizare odată ce a șters, sau în următoarele 30 de minute cel târziu.

10. 6 octombrie 2026 la 20:13 UTCidentified

    Restaurantul muncii întârziate a fost eliminat, iar fluxurile de lucru încep din nou fără întârzieri în notificări. Cu toate acestea, clienții care utilizează locuri de muncă Docker și Linux în mai multe clase de resurse, inclusiv medii, mari, și 2xlarge gen2, pot vedea acum locuri de muncă în așteptare pentru câteva minute înainte de a începe. Inginerii noştri continuă să lucreze la atenuarea acestei probleme. Dacă slujba ta nu a reuşit să înceapă, te rog să refaci slujba. Vă mulţumim pentru răbdare în timp ce inginerii noştri lucrează la asta. Vom împărtăși o altă actualizare în următoarele 30 de minute, sau mai devreme dacă mai multe informații devin disponibile.

11. 6 octombrie 2026 la 20:31 UTCmonitoring

    Fluxurile de lucru și locurile de muncă încep în mod normal, iar orele de așteptare pentru locurile de muncă Docker și Linux au revenit la normal. Inginerii noştri continuă să monitorizeze această problemă. Dacă slujba ta nu a reuşit să înceapă, te rog să refaci slujba. Vă mulţumim pentru răbdare în timp ce inginerii noştri lucrează la asta. Vom împărtăși o altă actualizare în următoarele 30 de minute, sau mai devreme dacă mai multe informații devin disponibile.

12. 6 octombrie 2026 la 21:18 UTCresolved

    Între aproximativ 15:30 UTC și 20:30 UTC la 6 octombrie 2026, clienții au înregistrat întârzieri și eșecuri care au afectat conductele, fluxurile de muncă și locurile de muncă. De la aproximativ 16:02 UTC până la 16:39 UTC, conductele au eşuat şi nu au putut începe noi fluxuri de lucru sau locuri de muncă. După reluarea serviciului, fluxurile de lucru și locurile de muncă au continuat să înceapă cu întârzieri până la aproximativ ora 20:00 UTC. Timpii de pornire au fost medii până la aproximativ 40 de minute la vârf, iar un număr foarte mic de fluxuri de lucru au așteptat mai mult de o oră. De asemenea, notificările și site-urile au fost amânate până la aproximativ 19:00 UTC, de obicei cu aproximativ un minut. Pe măsură ce rezultatul muncii întârziate a fost eliminat, creșterea cererii a pus presiune asupra capacității noastre de execuție, cauzând noi întârzieri pentru locurile de muncă Docker și Linux. De la aproximativ 19:45 UTC la 20:30 UTC, aceste locuri de muncă au așteptat în coadă mai mult decât de obicei înainte de a începe. La vârf, aproximativ 20:05 UTC, așteaptă până la aproximativ 8 minute pentru 2xlarge gen2, 6 minute pentru xlarge gen2, și mai puțin de 5 minute pentru câteva alte clase de resurse. Problema a fost rezolvată și toate funcționalitățile afectate au revenit la normal. Clienții ale căror locuri de muncă au eșuat în timpul acestei ferestre pot relua locurile de muncă afectate. Vă mulțumim pentru răbdare în timp ce echipa noastră a lucrat la implementarea unui fix.

13. 7 octombrie 2026 la 22:08 UTCpostmortem

    ## Rezumat Pe 6 octombrie 2026, de la 15:30 la 20:30 UTC, clienții CircleCI au avut întârzieri în crearea conductelor și începerea fluxurilor de lucru și a locurilor de muncă. De la 15:48 la 16:38 UTC, nu au început fluxurile de lucru sau locurile de muncă, iar conductele declanșate de la 16:02 UTC au eșuat. Întârzierile intermitente au început mai devreme, la 13:30 UTC. Datele din UI CircleCI, notificări, și să angajeze actualizări de stare furnizorilor de control versiune au fost, de asemenea, întârziate. Incidentul a început în baza de date din spatele serviciului nostru de orchestrare a fluxului de lucru, care coordonează fiecare conductă, flux de lucru și loc de muncă pe CircleCI. Întreținerea de rutină pe cele mai mari tabele de date a scris jurnale de tranzacții mai repede decât baza de date le-ar putea arhiva, iar jurnalele umplut volumul de stocare setat deoparte pentru ei. Pentru ca baza de date să nu devină doar citită, inginerii noştri au mutat jurnalele în volumul principal de stocare al bazei de date. Această mișcare a luat baza de date offline timp de 50 de minute. Când baza de date s-a întors, a procesat munca la jumătate din rata normală până când inginerii noştri au schimbat o bază de date la 18:19 UTC. Apoi am lucrat prin backlog, și de locuri de muncă începe ori a revenit la normal până la 20:30 UTC. Clienții ale căror locuri de muncă nu a reușit în timpul acestei ferestre le poate relua. Pagina de stare originală poate fi găsită [aici](https://status.circleci.com/incidente/z4hbq8h49j8c). ## Context Când declanşezi o conductă, CircleCI o dă unui serviciu de orchestrare. Acest serviciu urmărește starea fiecărui flux de lucru și a fiecărui loc de muncă, decide când fiecare loc de muncă este gata pentru a rula, și trece locuri de muncă gata pentru flota noastră de execuție. Acesta conduce, de asemenea, datele de locuri de muncă pe care le vedeți în UI și notificările și să angajeze statutele pe care le trimitem atunci când munca se termină. Serviciul de orchestrare îşi stochează statul într-o bază de date. Baza de date scrie fiecare modificare la un jurnal de tranzacţii înainte de a-l aplica, şi păstrează aceste jurnale pe un volum de stocare dedicat. Arhiva jurnalele continuu astfel încât să poată refolosi acel spaţiu. Dacă arhivarea rămâne în urmă și volumul se umple, baza de date nu mai acceptă scrieri și nicio lucrare nouă nu poate merge mai departe. Baza de date ruleaza, de asemenea, un proces periodic de întreținere \ (autovacuums\) pe fiecare tabel pentru a menține înregistrările sale interne valabile în timp. Pe o masă foarte mare, acest proces citește fiecare pagină a tabelului și scrie un volum mare de jurnale de tranzacții. ## What happened \(Toate timpurile UTC\) De la 10:02 la 6 octombrie, monitorizarea noastră a ridicat alerte de scurtă durată cu privire la erorile din serviciul de orchestrare. Fiecare alertă a fost eliberată în 15 minute. Inginerii noștri au văzut alerte scurte similare înainte, și sistemul nu a arătat nici un alt semn de stres, așa că au urmat runbook de fiecare dată, și fiecare alertă eliminate pe propria sa parte prin și a început să lucreze pentru a face alertele mai puțin sensibile. În jurul orei 12:40, împreună cu volumul de muncă regulat care generează propriile jurnale de tranzacții, procesul de întreținere pe mai multe dintre cele mai mari tabele ale bazei de date a început să scrie jurnale de tranzacții suplimentare mai repede decât baza de date le-ar putea arhiva, iar volumul jurnalului a început să umple. La 13:30, orchestrarea a început să încetinească. Până la 15:30, unele conducte și locuri de muncă au avut nevoie de mai mult timp pentru a începe, în explozii scurte. La 13:35, monitorizarea noastră a alertat din nou, de data aceasta alături de alertele legate de alte servicii. Inginerii Infrastructură a urmat runbook-uri de alertă, compensare unele dintre alerte. Alertele s-au întors din nou pe la 14:30 şi după ce am investigat în continuare, am declarat un incident la 14:54. Ar fi trebuit să recunoaştem combinaţia de alerte mai devreme, şi am acoperit modul în care reparăm asta mai jos. După declararea incidentului, inginerii noștri au urmărit încetinirea procesului de întreținere \ (anti-împachetare autovacuum\). Baza de date reporneşte acest proces automat dacă este anulat, aşa că inginerii noştri şi-au schimbat setările pentru a-l ajuta să termine mai repede. Până la 15:30, întârzierile au fost continue, iar unele locuri de muncă au început să eşueze. La 15:43, volumul jurnalului de tranzacţii a fost aproape complet. Dacă s-ar umple, baza de date ar înceta să mai accepte scrieri și nici o lucrare nu ar putea rula. Inginerii noştri au decis să mute jurnalele tranzacţiilor în volumul principal de stocare al bazei de date, care avea o mulţime de spaţiu liber. Măsura a necesitat ca baza de date să meargă offline, și nu am putut prezice în avans cât timp ar dura. Mutarea a început la 15:47. De la 15:48 la 16:38, serviciul de orchestrare nu a putut procesa nicio lucrare. Clienții ar putea declanșa încă conducte, dar nu au început fluxurile de lucru sau locurile de muncă, iar de la 16:02 conductele nou declanșate au eșuat. Am postat pe pagina de stare la 15:58 şi am ridicat-o la o pană majoră la 16:20. În timp ce baza de date era offline, inginerii noştri au pregătit o bază de date de înlocuire ca rezervă. Baza de date originală a revenit prima, aşa că am ţinut-o în funcţiune. La 16:38, baza de date a revenit online și munca a început să curgă din nou. Cu jurnalele tranzactiilor si datele regulate care acum impartasesc acelasi depozit, baza de date a fugit mai lent decat inainte. De la 16:38 la 18:19, serviciul de orchestrare a procesat munca la aproximativ jumătate din rata normală, iar locurile de muncă au așteptat zeci de minute pentru a începe, până la aproximativ 50 de minute cel mai mult. În acest timp, baza de date a trebuit să termine arhivarea jurnalului de tranzacţii înainte de a le putea muta înapoi la un volum dedicat. De asemenea, am investigat și implementat mai multe modificări ale parametrilor bazei de date pentru a opri continuarea operațiunilor de întreținere de la începerea și pregătirea unor modalități de reducere a activității de realizare a serviciului. Împreună cu baza de date de înlocuire, am pregătit, de asemenea, un pachet complet de servicii în acest timp, astfel încât să putem trece la ea, cu riscul pierderii datelor și a optat împotriva acestei măsuri. La 18:19, inginerii noștri au schimbat o setare de baze de date pentru a reduce timpul petrecut de fiecare scriere în așteptare pentru depozitare. Viteza de procesare recuperat, și backlog a început să clar. Pentru a-l curăţa mai repede, am adăugat baze de date şi capacitatea serverelor la sistemele care fac sex flotei noastre de execuţie. În jur de 19:55, noi locuri de muncă au început din nou la timp. Jurnalul a ajuns apoi la flota noastră de execuţie. De la 19:49 la 20:30, unele locuri de muncă Docker pe clase de resurse mai mari așteptat până la aproximativ 10 minute pentru a începe în timp ce capacitatea a crescut. Până la 20:30, locurile de muncă au revenit la normal. Am mutat pagina de stare la monitorizare la 20:32 şi am rezolvat incidentul la 21:19. Aproximativ 3.500 de locuri de muncă nu au început în timpul incidentului. Clienţii pot relua aceste slujbe. N-am găsit nici o dovadă că CircleCI conducea mai mult de o dată. Clienţii care refac un flux de lucru în timp ce rula originală a fost încă întârziat poate fi văzut ambele ruleaza complet. Clientii de planuri anuale pot lucra cu echipa lor de cont pentru a revizui utilizarea. ## Viitoare prevenire și îmbunătățire a procesului Luăm următoarele măsuri pentru a preveni recurența și pentru a îmbunătăți timpul de răspuns: **Suntem adăugarea de alerte cu privire la condițiile care au cauzat acest incident.** Monitorizarea noastră a prins încetinirea, dar nu am avut nici o alertă cu privire la cât de plin volumul jurnalului de tranzacții a fost sau cu privire la cât de departe arhivarea a rămas în urmă. Adăugăm alerte cu privire la ambele, împreună cu alerte privind întreținerea bazei de date care le conduce, astfel încât să putem acționa mai devreme. De asemenea, revizuim toate alertele noastre pentru a ne asigura că alertele zgomotoase sau sensibile nu ascund probleme reale. ** Ne reglăm modul în care procesul de întreținere \ (autovacuum\) rulează în baza noastră de date.** Ne uităm la frecvenţa şi agresivitatea cu care autovacuumurile rulează în baza noastră de date. Urmărim, de asemenea, dimensiunea acestor mese în timp, astfel încât acestea să rămână în limite de siguranță. ** Suntem eliminarea buştean unic tranzacţie log.** Toate scrisurile serviciului de orchestrare trec în prezent printr-o bază de date și un jurnal de tranzacții, astfel încât atunci când acel jurnal a căzut în urmă, fiecare conductă, fluxul de lucru și de locuri de muncă încetinit cu ea. Evaluăm două abordări: împărţim serviciul în mai multe cazuri de baze de date, fiecare cu propriul jurnal de tranzacţii şi îl mutăm într-o bază de date distribuită construită pentru a răspândi scrie pe mai multe noduri. Oricare dintre abordări ar limita efectul unui backlog la o parte din volumul de muncă. ** Facem ca sistemele noastre să aştepte să-şi revină.** În timpul incidentului, unele locuri de muncă au eșuat deoarece sistemele noastre au renunțat după rejudecarea. Lucrăm la schimbarea acestui comportament. **Suntem îmbunătățirea actualizările paginii de stare în timpul incidentelor lungi.** Clienții ne-au spus actualizările noastre timpurii nu au dat destule detalii. Actualizăm orientările noastre, astfel încât actualizările includ impact specific și sincronizare mai devreme. Experienţa clienţilor este prioritatea noastră principală şi ne angajăm să îmbunătăţim în permanenţă fiabilitatea sistemelor noastre pentru a se potrivi cu încrederea pe care o au clienţii noştri în noi. Le mulţumim clienţilor noştri pentru răbdarea lor în timp ce echipa noastră a lucrat pentru a rezolva acest incident. Vă rugăm să contactați echipa noastră de sprijin cu orice întrebări sau preocupări.

Traducere automată din actualizarea oficială a incidentului.

1. 1 octombrie 2026 la 09:06 UTCinvestigating

   Clienții pot experimenta întârzieri în începerea Docker Gen 2 Locuri de muncă. Ne străduim să mărim volumul sistemului pentru a-l adăposti.

2. 1 octombrie 2026 la 09:47 UTCidentified

   Am identificat cauza principală şi lucrăm activ la o soluţie. Mulţumesc pentru răbdare.

3. 1 octombrie 2026 la 10:13 UTCidentified

   S-a rezolvat o problemă şi începem să observăm recuperarea.

4. 1 octombrie 2026 la 10:24 UTCmonitoring

   Vedem orele la coadă revenind la niveluri normale, și continuă să monitorizeze.

5. 1 octombrie 2026 la 10:45 UTCresolved

   Acest incident a fost rezolvat.

6. 9 octombrie 2026 la 22:36 UTCpostmortem

   "Summary" Între 1 octombrie și 8 octombrie 2026, clienții CircleCI au experimentat cinci incidente separate în care locurile de muncă au așteptat mai mult decât normal să înceapă sau nu au reușit să înceapă. Trei dintre incidente au fost determinate de disponibilitatea limitată a furnizorului nostru de cloud-uri. Unul a fost cauzat de o problemă de configurare în infrastructura noastră de planificare, și unul de limitele de memorie pe un serviciu intern, pe care am ridicat în timpul incidentului. * **Octombrie 1, 07:57 to 10:24 UTC:** Docker Gen 2 jobs waited up to 30 minutes to start. O problemă de configurare a împiedicat serverele de programare Gen 2 să folosească discurile locale de înaltă performanță. În timpul unei explozii în trafic, discurile de rezervă saturate și plasarea de locuri de muncă încetinit. * **Octombrie 7, 13:27-14:06 UTC:** Maşinile au aşteptat mai mult decât normal pentru că nu am putut achiziţiona suficiente maşini virtuale de la furnizorul nostru de cloud. * **Octombrie 7, 14:24 - 15:21 UTC:** Unele locuri de muncă au eșuat cu o eroare de infrastructură, iar fluxurile de lucru au fost întârziate. Serviciul care oferă fiecare loc de muncă configurația sa la pornire a rămas fără memorie și a reluat. * **Octombrie 7, 18:49 - 20:05 UTC:** Docker Gen 2 de locuri de muncă a așteptat mai mult decât în mod normal, deoarece nu am putut dobândi suficiente cazuri de la furnizorul nostru de cloud. * **Octombrie 8, 12:48-16:00 UTC:** Maşinile Linux şi slujbele de la distanţă Docker aşteaptă până la 50 de minute să înceapă. Furnizorul nostru de cloud nu a avut suficient de tipul de instanță pe care le solicităm, și un defect în logica care alege un tip de instanță diferit ne-a împiedicat să folosim alternative. Locurile de muncă care au aşteptat în timpul acestor incidente au fost întârziate, nu pierdute. Clienții ale căror locuri de muncă au eșuat cu o eroare de infrastructură în timpul incidentului din 7 octombrie de la 14:24 la 15:21 UTC le pot relua. Paginile originale de stare pot fi găsite mai jos: * [1 octombrie - Întârzieri începând cu Gen 2 Docker Jobs](https://status.circleci.com/incidente/22mrv46g6n7g) * [7 octombrie - Întârziere la pornirea lucrărilor mecanicului][https://status.circleci.com/incidente/tj6wdnfjwr64] * [7 octombrie - Nivelul ridicat de infra eșuează asupra locurilor de muncă ale clienților](https://status.circleci.com/incidente/0z31ldjd8m5v) * [7 octombrie - Creșterea timpului de așteptare pentru Docker Gen2] [https://status.circleci.com/incidente/39rfrjmk5pvd] * [8 octombrie - Timpi de așteptare măriți pentru locurile de muncă automate] [https://status.circleci.com/incidente/jn756xtsy4xg] Background Fiecare loc de muncă care rulează pe CircleCI are nevoie de calcul. De unde vine acel calcul depinde de executor. Locuri de muncă Docker rula pe clustere de servere care programează lucrează pe o flotă de cazuri. Programatorul este software-ul de pe acele servere care decide care instanță conduce fiecare loc de muncă. Gen 2 Docker locuri de muncă rula pe un astfel de grup la momentul incidentului octombrie 1. Gen 1 Docker locuri de muncă sunt răspândite în mai multe grupuri. Mașină de locuri de muncă, inclusiv locuri de muncă Docker la distanță, obține o mașină virtuală dedicată. Un loc de muncă Docker la distanță este manipulat ca un loc de muncă mașină Linux de la depunerea prin furnizarea. Serviciul nostru de furnizare de mașini solicită fiecare mașină de la furnizorul nostru de cloud într-una dintre cele două regiuni pe care le folosim în mod normal pentru mașini de locuri de muncă. Atunci când furnizorul nu poate furniza tipul de instanță pe care îl solicităm, serviciul se retrage: solicită un tip de instanță diferit sau o regiune diferită de o listă pe care o menținem. Un loc de muncă așteaptă până când o mașină este disponibilă. Când începe orice post, solicită un serviciu de configurare pentru configurarea sa. Acest serviciu se execută ca un set de capsule, care sunt copii mici ale aceluiași program. Dacă se opresc prea multe capsule, capsulele rămase transportă mai multă încărcătură, iar locurile de muncă nu pot începe până când serviciul nu se recuperează. Aceste căi depind de trei tipuri de capacitate: trecerea de la sistemele noastre de planificare, furnizarea de cazuri de la furnizorul nostru de cloud, și memoria și numărul de copii ale serviciilor care încep locuri de muncă. Un deficit în oricare dintre ele face locuri de muncă așteptați sau nu. Ce s-a întâmplat? \(Toate timpurile UTC\) ### **Octombrie 1: Docker Gen 2 joburi întârziate până la 30 minute La 07:44, activitatea discului pe serverele care programează Gen 2 Docker job-uri a crescut la 90% din capacitate și a rămas acolo. La 07:57, numărul de locuri de muncă Docker de așteptare pentru a începe a început să crească, și de așteptare ori a crescut cu ea. O alertă automată l-a chemat pe inginerul de gardă la 08:08. Am declarat un incident la 08:42. La 08:43, inginerii au identificat latența de mare disc pe serverele de programare. Prima dată au crezut că discurile erau prea lente pentru încărcătură, aşa că au pregătit o schimbare la un tip de disc mai rapid. La 09:01, echipa a convenit asupra a două fluxuri de lucru: mutați serverele pe discuri mai rapide și adăugați un al doilea grup Gen 2 astfel încât locurile de muncă să se împartă în două grupuri. La 09:41, inginerii au găsit cauza. Fiecare server de programare are discuri rapide atașate direct la el, iar programatorul este menit să păstreze datele sale de lucru acolo. Aceste servere ruleaza pe o imagine a sistemului de operare inaltata de securitate, si pe aceasta imagine dischetele rapide nu erau folosite. Programatorul şi-a scris datele pe discuri mai lente. Script-ul care stabilește discurile rapide a eșuat fără o eroare, și un decalaj în logare pe aceste servere ascuns eșecul. De asemenea, traficul de gen 2 a devenit tot mai intens. Discurile mai lente s-au saturat în timpul exploziilor, iar programatorul a rămas în urmă. Timpul de aşteptare a atins apogeul la 09:54, când locurile de muncă din clasa de resurse medii Gen 2 au aşteptat până la 30 de minute. La 09:55, inginerii au aplicat un fix care a instalat discurile rapide corect. La 10:11, programatorul a început să plaseze locuri de muncă mai repede, ceea ce a confirmat serverele ar putea ține pasul cu noi locuri de muncă. Timpul de așteptare pentru Gen 2 mediu a scăzut la 13 minute la 10:14, 7 minute la 10:17, și 1 minut 30 secunde la 10:20. Am mutat pagina de stare la monitorizare la 10:24 şi am rezolvat incidentul la 10:45. La 11:20, cel de-al doilea grup Gen 2 a început să lucreze. Traducerea şi adaptarea: Am declarat un incident la 13:27 după ce am văzut ore ridicate la coadă şi am aşteptat. Am postat pe pagina de stare la 13:31. La 13:31, inginerii au văzut că ne luptam să achiziţionăm maşini virtuale pentru maşini şi că numărul de locuri de muncă care aşteptau să înceapă era ridicat în principal pentru maşini. La 13:34, orele de aşteptare au fost ridicate de către executori. La 13:48, orele de așteptare au început să se recupereze pe măsură ce mai multe mașini au devenit disponibile, și am rezolvat incidentul la 14:06. ## **Octombrie 7, 14:24 la 15:21: Eșecuri de locuri de muncă și întârzieri în fluxul de lucru** La scurt timp după ce incidentul anterior a fost marcat ca fiind rezolvat, am declarat un nou incident la 14:24 din cauza scăderii drastice a numărului de locuri de muncă depuse la sistemele noastre de execuţie. La 14:26, inginerii au văzut că capsulele serviciului de configurare a locurilor de muncă repornesc. Poduri care repornesc lasă mai puține copii ale serviciului pentru a răspunde cererilor, precum și locuri de muncă care nu au putut recupera configurația lor după încercări repetate eșuate cu o eroare de infrastructură. Fluxurile de lucru care deja funcţionau aşteptau actualizări de la locuri de muncă care nu începuseră. La 14:35, inginerii au mărit cantitatea de memorie disponibilă la capsule și au mărit numărul de capsule, care au dat serviciului mai multe copii pentru a partaja încărcătura. De asemenea, am mărit cantitatea de memorie disponibilă a transmiterilor de locuri de muncă a început recuperarea, și numărul de mesaje care curge prin sistemul nostru de flux de lucru a revenit la niveluri normale. La 14:44, am mutat pagina de stare la monitorizare. Podurile din serviciul de configurare a locurilor de muncă au atins limitele de memorie și au repornit. Am mărit alocarea memoriei şi numărul de capsule, iar serviciul s-a recuperat. La 15:13, am crescut numărul de cazuri în clusterele noastre Gen 2 Docker, astfel încât am putea lucra prin backlog-ul de locuri de muncă de așteptare rapid. Am rezolvat incidentul la 15:21. Traducerea şi adaptarea: Am declarat un nou incident la 18:49 după ce Docker Gen 2 s-a ridicat. La 18:51, inginerii au confirmat că o penurie de cazuri disponibile ne-a împiedicat să dobândim destule dintre ele, ceea ce a ridicat timpul de aşteptare. Timpurile de așteptare diferă în funcție de dimensiunea clasei resurselor. La 19:52, timpul mediu de așteptare a fost mai mic de o oră mai devreme ca mai multă capacitate a devenit disponibil, deși piroane scurte a continuat, și am mutat pagina de stare la monitorizare. Am rezolvat incidentul la 20:05. Traducerea şi adaptarea: Am declarat un incident la 12:48 dupa ce am vazut un numar mare de locuri de munca asteptand sa inceapa si sa astepte mult timp pentru masini si locuri de munca la distanta Docker. La 12:49, inginerii au văzut că furnizorul nostru de nori nu putea furniza suficiente cazuri. Întârzierile au continuat să urce în timp ce investigam. La 13:13 am început să examinăm logica care alege un alt tip de instanță sau regiune atunci când prima noastră alegere nu este disponibilă. La 13:24, am suspectat că un defect în această logică ne-a oprit să folosim alte tipuri de cazuri din regiunea noastră primară, așa că am dezactivat regiunea noastră de rezervă și am confirmat cauza defectului. Inginerii au început să lucreze la un fix şi l-au desfăşurat la 14:49. Serviciul a început să solicite alte tipuri de instanță și a pornit mașini în număr mare. La 14:58, coada de locuri de muncă de așteptare pentru o mașină a scăzut constant. Timpii mediui de așteptare în cadrul cursurilor de resurse au continuat să scadă în următoarea oră, în timp ce lucram prin backlog-ul locurilor de muncă în așteptare. La ora 16:00, coada de locuri de muncă de așteptare pentru o mașină curățată și numărul de locuri de muncă în așteptare a revenit la normal. Am mutat pagina de stare la monitorizare la 16:09 şi am rezolvat incidentul la 16:35. Traducerea şi adaptarea: Luăm următoarele măsuri pentru a consolida reziliența timpilor de începere a locurilor de muncă, inclusiv diversificarea ofertei, logica de rezervă și detectarea timpurie. ** Ne extindem regiunile de calcul.** În incidentele din 7 octombrie și 8 octombrie, furnizorul nostru de clouduri nu a putut furniza suficiente cazuri în regiunile pe care le-am folosit. Adăugăm noi regiuni la logica noastră de rezervă pentru a manevra piroane pentru cerere care depășesc regiunile noastre preferate. **Reparam logica care alege un alt tip de instanta.** La 8 octombrie, un defect a împiedicat serviciul de furnizare de mașini să utilizeze alte tipuri de cazuri din aceeași regiune. Am implementat o soluţie în timpul incidentului şi acum revizuim şi refacem această logică ca un întreg, cu teste, astfel încât o lipsă de un tip de instanţă se mută la altul. ** Extindem tipurile de cazuri pe care le oferim și asigurarea capacității suplimentare.** Lucrăm cu furnizorul nostru de cloud-uri pentru a rezerva capacități suplimentare în regiunile noastre existente și adăugăm tipuri de exemple pe care locurile de muncă le pot desfășura. Cererea industriei de calcul de înaltă performanță este în creștere. Diversificăm unde și modul în care avem capacitatea de sursă astfel încât clienții noștri să fie izolați de variația ofertei. **Am adăugat un al doilea grup Gen 2 Docker, astfel încât exploziile de trafic sunt distribuite în două grupuri.** De asemenea, adăugăm alerte cu privire la programarea saturaţiei pe discul serverului şi la cât de repede plasează programatorul locuri de muncă, şi o alertă care trage atunci când un server începe fără discurile sale rapide în uz. Am făcut script-ul de configurare disc eșua cu o eroare, și am restaurat transportul jurnal de pe aceste servere, astfel încât o problemă similară este vizibilă mai devreme. Experienţa clienţilor este prioritatea noastră principală şi ne angajăm să îmbunătăţim în permanenţă fiabilitatea sistemelor noastre pentru a se potrivi cu încrederea pe care o au clienţii noştri în noi. Le mulţumim clienţilor noştri pentru răbdarea lor în timp ce echipa noastră a lucrat pentru a rezolva aceste incidente. Vă rugăm să contactați echipa noastră de sprijin cu orice întrebări sau preocupări.

Traducere automată din actualizarea oficială a incidentului.

1. 23 septembrie 2026 la 18:13 UTCidentified

   Clienții pot experimenta întârzieri în noile înscrieri și modificări de plan reflectate în contul lor.

2. 23 septembrie 2026 la 20:06 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 21 septembrie 2026 la 16:22 UTCinvestigating

   Clienții pot experimenta întârzieri în începerea de locuri de muncă pe Linux Machine. Investigăm.

2. 21 septembrie 2026 la 16:48 UTCmonitoring

   Timpul de aşteptare pentru Linux Machine revine la normal.

3. 21 septembrie 2026 la 17:09 UTCresolved

   This incident has been resolved.

Traducere automată din actualizarea oficială a incidentului.

1. 16 septembrie 2026 la 14:55 UTCinvestigating

   Investigăm o întârziere în furnizarea datelor. Conductele sunt încă în funcțiune, dar datele despre acestea pot fi întârziate în UI sau API.

2. 16 septembrie 2026 la 15:29 UTCidentified

   Am identificat problema și lucrăm la o remediere. Mulţumesc pentru răbdare.

3. 16 septembrie 2026 la 17:34 UTCidentified

   Datele privind conducta sunt disponibile în prezent în mod normal, cu excepția rezultatelor testelor, care pot fi încă întârziate. Continuăm să lucrăm la asta, mulţumesc pentru răbdare.

4. 16 septembrie 2026 la 18:22 UTCmonitoring

   Toate datele conductei sunt acum disponibile normal. Vom continua să monitorizăm recuperarea.

5. 16 septembrie 2026 la 19:30 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 15 septembrie 2026 la 14:42 UTCinvestigating

   În prezent vedem o întârziere în fluxul de date ieşind la suprafaţă în UI.

2. 15 septembrie 2026 la 15:14 UTCidentified

   Începem să ne revenim.

3. 15 septembrie 2026 la 17:02 UTCresolved

   Incidentul care afectează datele conductei din UI a fost acum rezolvat. Vă mulțumim pentru răbdare în timp ce inginerii noștri au lucrat la reducerea întârzierilor.

Traducere automată din actualizarea oficială a incidentului.

1. 14 septembrie 2026 la 11:59 UTCinvestigating

   Din cauza erorilor de rețea crescute și a latențelor vedem vremuri de așteptare sporite pentru locurile de muncă macOS. Investigăm acest lucru cu furnizorul nostru de găzduire MacOS.

2. 14 septembrie 2026 la 12:36 UTCinvestigating

   Momentele de așteptare pentru locurile de muncă macOS se reduc și continuăm să investigăm.

3. 14 septembrie 2026 la 12:48 UTCmonitoring

   Furnizorul nostru de găzduire MacOS a implementat o atenuare și am văzut latențe îmbunătățite. Vom continua să monitorizăm.

4. 14 septembrie 2026 la 12:59 UTCresolved

   Timpii de așteptare pentru locurile de muncă MacOS au revenit la normal.

Traducere automată din actualizarea oficială a incidentului.

1. 10 septembrie 2026 la 20:25 UTCidentified

   Un număr mic de clienți pot vedea erori sau pot fi în imposibilitatea de a încărca pagina conductelor pentru proiecte cu avertismente deconfig depreciate, atunci când utilizați vizualizarea conductelor clasice. Clientii pe noua vizualizare conducte nu sunt afectate. Am identificat cauza şi am implementat o soluţie.

2. 10 septembrie 2026 la 20:25 UTCmonitoring

   A fost implementată o soluţie şi monitorizăm rezultatele.

3. 10 septembrie 2026 la 20:26 UTCresolved

   Acest incident a fost rezolvat. Un număr mic de clienți care au creat conducte între 18:53 UTC și 19:24 UTC care conțineau config folosind sintaxa de configurare depreciată vor fi văzut cum locurile lor de muncă de tip build nu au început. Clienţii ale căror locuri de muncă sau conducte au eşuat le pot relua.

Traducere automată din actualizarea oficială a incidentului.

1. 4 septembrie 2026 la 15:16 UTCinvestigating

   Am detectat probleme de rețea care afectează infrastructura noastră Mac. Investigăm şi vă vom oferi informaţii în scurt timp. Clienţii pot sta la coadă în acest timp.

2. 4 septembrie 2026 la 15:43 UTCidentified

   Am identificat problema reţelelor cu furnizorul nostru de infrastructură Mac şi lucrăm cu ei pentru a rezolva problema. Începem să vedem ceva recuperare, dar ne aşteptăm ca clienţii să mai vadă nişte cozi. Vom actualiza din nou în curând.

3. 4 septembrie 2026 la 16:19 UTCmonitoring

   Furnizorul nostru de infrastructură Mac a aplicat un fix la această problemă de rețea și vedem ori coada reveni la normal. Vom continua să supraveghem lucrurile pentru o perioadă mai lungă. Vom actualiza din nou în curând.

4. 4 septembrie 2026 la 16:55 UTCresolved

   Nu am mai văzut niciun impact asupra orelor de aşteptare şi totul a revenit la normal. Apreciem răbdarea dumneavoastră în timp ce am lucrat pentru a rezolva și monitoriza această problemă.

Traducere automată din actualizarea oficială a incidentului.

1. 26 august 2026 la 15:43 UTCidentified

   Clienții pot experimenta erori intermitente atunci când vizualizarea IU de utilizare a planului sau API-uri de utilizare a planului de apelare. Am identificat problema și lucrăm în mod activ la atenuarea acestor erori.

2. 26 august 2026 la 16:04 UTCmonitoring

   Am redus problema cu API-urile de utilizare a planului, iar paginile relevante din UI se încarcă corect.

3. 26 august 2026 la 16:10 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 25 august 2026 la 23:20 UTCresolved

   Între 19:49 UTC și 21:07 UTC la 25 august 2026, clienții care încercau să se logheze la CircleCI folosind GitHub nu au putut să se înscrie și au primit o eroare de la GitHub, afirmând că URL-ul de răspuns a fost invalid. Clienţii care erau deja înregistraţi nu au fost afectaţi. Problema a fost rezolvată și GitHub de conectare funcționează în mod normal. Vă mulțumim pentru răbdare în timp ce echipa noastră a lucrat la implementarea unui fix.

Traducere automată din actualizarea oficială a incidentului.

1. 17 august 2026 la 21:06 UTCidentified

   Cauza problemei a fost identificată și suntem la locul de muncă de stabilire a acesteia.

2. 17 august 2026 la 21:36 UTCmonitoring

   A fost implementată o soluţie şi monitorizăm rezultatele.

3. 17 august 2026 la 21:37 UTCresolved

   Datele de bază sunt bune încă o dată. Mulţumesc pentru răbdare.

Traducere automată din actualizarea oficială a incidentului.