Prod2 nu a fost disponibil intermitent
Pending
Componente afectate
Platform
- investigating
În prezent investigăm această problemă.
- resolved
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
82 incidente Split înregistrate începând din aprilie 2026, cu actualizări oficiale, componente afectate, durată și informații despre rezolvare.
În prezent investigăm această problemă.
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
Execuţia conductei este blocată în Prod1. Investigăm problema.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
## Rezumat În perioada 27 august - 28 august 2026, clienții au avut o problemă în care unele conducte, aplicații și resurse conexe nu au fost găsite în Harness UI și API, chiar dacă datele subiacente au rămas intacte. Problema a avut loc în timpul unei actualizări planificate a infrastructurii interne care a afectat comunicarea între serviciile de platformă internă. Prin urmare, cererile care depind de conturi, organizarea și soluționarea domeniului de aplicare al proiectului nu au fost în măsură să se finalizeze cu succes, ceea ce a dus la nerealizarea unor răspunsuri care nu au fost găsite incorecte și returnate clienților entităților existente. Ingineria a identificat problema, a returnat schimbarea şi a restaurat serviciul normal. Nu au fost pierdute sau șterse datele clienților în timpul incidentului. ## Root Cause Problema a fost cauzată de o eroare de configurare introdusă în timpul unei actualizări planificate a rutei serviciilor interne în producție. Un serviciu de platformă internă responsabil pentru rezolvarea contului, organizarea și contextul proiectului nu a putut valida cererile altor servicii Harness după aplicarea modificării. Deoarece această etapă de validare este necesară înainte ca multe entități să citească și să poată continua acțiunile legate de conducte, cererile eșuate au apărut pentru clienți, deoarece nu s-au găsit erori pentru resursele care au continuat să existe în mod normal. Problema s-a limitat la mediul de producție afectat și a fost rezolvată prin inversarea schimbării și restabilirea traseului de comunicare al serviciului anterior. ## Impact * Unii clienți au văzut conductele existente, implementarea, și entitățile conexe apar ca nefiind găsite în UI și API. * Unele operaţiuni legate de conducte, inclusiv progresia execuţiei, start-uri declanşate prin webhook, evaluarea declanşării programate şi listarea entităţilor, au fost întrerupte temporar. * Problema a afectat disponibilitatea și vizibilitatea entităților existente, dar nu a eliminat datele sau nu a modificat configurația clienților. * Nu a avut loc nici un acces neautorizat şi nu s- au observat pierderi de date ale clienţilor. ## Remediation * **Imediat:** Reversificarea configurației infrastructurii actualizează și restaurează calea de comunicare a serviciului de lucru anterior. * **Recunoaștere validare:** Verificat că căutarea entităților afectate, operațiunile de conducte și API dependente au funcționat în mod normal după răsturnare. * **Permanent:** Corectat manipularea configurației asociate cu actualizarea astfel încât problemele similare să nu interfereze cu autentificarea serviciului la serviciu în viitoarele versiuni. ## Action items Pentru a preveni astfel de probleme să se întâmple din nou, Harness va 1. Îmbunătăţirea validării configuraţiei prin îmbunătăţirea testelor de pre-alocare pentru verificarea comunicării interne a serviciilor înainte de schimbarea traficului de producţie. 2. Sporirea monitorizării și alertarea pentru defecțiunile de autentificare internă, astfel încât problemele să poată fi detectate mai devreme. 3. Îmbunătățirea gestionării erorilor, astfel încât eșecurile dependenței sunt mai puțin susceptibile de a apărea clienților, deoarece resursele nu au găsit erori.
Traducere automată din actualizarea oficială a incidentului.
Investigăm în prezent o problemă raportată în conductele IACM din Prod-1, Prod-2, Prod-4 și UE1.
Continuăm să investigăm această problemă.
Am inversat schimbarea care a cauzat această problemă în toate grupurile.
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
În prezent, investigăm rapoarte conform cărora interfaţa de utilizator "Feature Management & Experimentation" (FMC) nu se încarcă. Clienții care încearcă să acceseze consola IFM pot întâmpina erori sau pagini care nu răspund. Se consideră că evaluarea caracteristicilor steagului și traficul SDK nu sunt afectate. O nouă actualizare va urma în curând.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
## Rezumat * Începând de la **23:42 UTC** pe 23 august 2026, mai mulți clienți din Eurosistem au raportat eșecuri la încărcarea UI a băncii. *Artefactele de la CSN au expirat datorită unei politici de retenţie, ceea ce a dus la incapacitatea de a se încărca. * Orice cerere de pavilion se schimbă prin API, schimbarea de livrare, iar conducta de date a continuat să lucreze fără întrerupere. ## Root Cause * IU este servit de la un CDN. Artefactele UI au fost evacuate din cauza unei politici de retenţie, ceea ce a făcut ca UI să nu se încarce pentru toţi utilizatorii. ## Impact * IU a fost în imposibilitatea de a încărca pentru toți utilizatorii din toate mediile de producție. Ce nu a fost afectat? * Funcţionalitate SDK şi evaluare a pavilionului * Admin apeluri API * Date de configurare a steagului clientului * Nu au apărut pierderi de date ## Remediation * Fondatorul UI a fost restaurat în CDN printr-o implementare * Recuperare confirmată în toate mediile de producție înainte de închiderea incidentului. ## Action items * Îmbunătățește politica de reținere a activelor astfel încât versiunea activă în prezent nu este niciodată supusă evacuării.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Încetinirea poate determina oricare dintre simptomele de mai jos: - Conductele nu pornesc - Întârzieri în execuţie - Conductele fiind anulate din cauza timeouts
Furnizorul nostru de nori se confruntă cu un incident activ și noi urmărim.
Continuăm să investigăm această problemă.
Furnizorul nostru de cloud a confirmat un incident continuu care afectează mai multe regiuni. Conductele de stocare nu au suferit eșecuri ca urmare, deși unii utilizatori pot continua să experimenteze lentoare. Monitorizăm îndeaproape situația și vom oferi actualizări pe măsură ce devin disponibile mai multe informații.
Observăm latențe îmbunătățite la bord în urma fixării implementate de furnizorul nostru de cloud. Continuăm să monitorizăm îndeaproape situația și vom furniza actualizări suplimentare, după cum se justifică. Am observat unele execuții blocate pentru CI pentru câțiva clienți, pe care le investighează
Acest incident a fost rezolvat.
Sumarul La 20 august 2026, începând cu aproximativ ora 15:00 UTC, platforma Harness a cunoscut o degradare a performanței pe scară largă în toate mediile de producție. Execuţiile de conducte care în mod normal se termină în aproximativ două minute au durat şapte până la zece minute. Livrarea continuă, integrarea continuă, orchestrarea conductei și gestionarea caracteristicilor și experimentarea au fost toate afectate. Platforma Google Cloud a experimentat un incident multi-produs în regiunea ne-vest1 care afectează Bigtable, Compute Engine, Google Kubernetes Engine, și infrastructura de producție de tip I/O. Harness rulează pe discuri persistente în această regiune. Degradarea a ridicat latența de operare a bazei de date de la aproximativ 2 ms până la peste 10 ms la cea de-a 95-a percentilă, care, la rândul său, a cauzat decalajul de procesare a mesajelor și s-a propagat la fiecare serviciu care depinde de accesul la baza de date în timp util. # Impact A fost o degradare, nu o pană. Conductele au continuat să execute și să completeze cu succes pe tot parcursul; acestea au fost mai degrabă lente decât eșec. Nu s-au pierdut date și nu s-a renunțat la nicio lucrare a clienților ca urmare a acestui incident. Cauza Root Infrastructura de producție Harness în mediile afectate ruleaza pe Google Cloud Platform discuri persistente în regiunea ne-vest1. Atunci când acest strat de stocare s-a degradat, efectul s-a propagat prin platformă într-un lanț previzibil: **Degradarea Persistent-disc I/O în noi-vest1. ** Platforma Google Cloud a experimentat un incident multi-produs care afectează Bigtable, Compute Engine, Google Kubernetes Engine, și performanță persistentă-disc. Acesta a fost un eșec de infrastructură în mediul furnizorului, în afara controlului Harness. # **Acţiuni preventive** Deși Harness nu poate preveni un eșec al infrastructurii unui furnizor de cloud. Acțiunile de mai jos vizează detectarea unuia mai rapid și o mai bună poziționare a acestuia. Traducerea şi adaptarea: - Da.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
### Rezumat La 20 august 2026, între 10:24 și 14:55 UTC, un subset de scrieri ale IFM a eșuat. Scrisorile făcute din IU abonat și scrise cu jetoane de acces Harness nu au fost afectate. Evaluarea pe termen lung a drapelului a continuat să funcționeze normal. Problema a fost atenuată prin revenirea la o schimbare recentă de autentificare într-un serviciu de guvernanță partajată, iar textele afectate au revenit la normal până la 14:55 UTC. Status: [https://status.harness.io/incidens/rhthgm7d5dkz](https://status.harness.io/incidens/rhthgm7d5dkz) ### Root Cause O modificare a modului în care un serviciu de guvernanță partajată autentificat de apeluri de intrare a avut ca rezultat respingerea unor cereri de transfer de fonduri proprii de nivel 1 de bază. Aceste scrieri au folosit acreditări de serviciu la serviciu pe care serviciul de guvernanță nu le mai putea verifica după schimbare. În cazul în care o politică de guvernanță neagă în mod intenționat o schimbare, se constată o incapacitate de guvernanță a clientului ca HTTP 499, același statut utilizat. Deoarece 499 este un răspuns valid și așteptat în această cale de negare, eșecurile nu arătau ca o întrerupere a alertelor noastre, iar incidentul a fost identificat mai degrabă din rapoartele clienților decât din cele interne. Impact * Un subset de API scrie nu a reușit în timpul ferestrei, în primul rând cele realizate folosind moștenirea API taste sau schimbarea de programare cerere cerere. * Scrisorile făcute din IU-ul de la Fond nu au fost afectate. * Scrie folosind jetoane de acces Harness \ (PAT și SAT\) nu au fost afectate. *Runtime pavilion evaluare a continuat în mod normal. * Nu au avut loc pierderi de date. Scrierile eșuate nu s-au aplicat. ### Remediation Reversificarea schimbării de autentificare a serviciului de guvernanță. Scrisorile afectate au revenit imediat la normal. ### Action items Pentru a preveni astfel de probleme să se întâmple din nou, * Harness va returna o eroare distinctă \ [nu 499\) atunci când un scris nu reușește deoarece guvernanța nu a putut fi evaluată, așa că nu este confundată cu o negare intenționată a politicii. * Adăugați alertarea cu privire la evaluarea de guvernanță în sine apel, mai degrabă decât bazându-se pe codul de stare cu care se confruntă clientul. * Extinderea sprijinului de autentificare pentru evaluările de politică. * Extinde acoperirea automată pentru scenarii suplimentare de scriere.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Continuăm să investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Continuăm să monitorizăm orice alte probleme.
Acest incident a fost rezolvat.
** Summary ** La 19 august 2026 între 12:35 și 17:29 UTC, serviciul de securitate Harness Application Security a suferit o perturbare semnificativă atât a consolei orientate către clienți, cât și a conductei de ingerare a datelor din regiunile SaaS Production și SUA1. **Root Cause** Serviciul de configurare internă care furnizează setările runtime pentru aproape orice altă componentă a devenit supraîncărcat și a intrat într-un ciclu de repornire repetată. Deoarece atât de multe servicii depind de aceasta, efectele au fost largi: pagini de consolă, cum ar fi politicile de protecție, vizualizările posturale, jurnalele de activitate, inventarul API și politica personalizată nu au reușit să încarce sau să se sincronizeze, iar procesarea în aval a fost blocată în timp ce aștepta configurarea pe care nu o putea obține. Traducerea şi adaptarea: Traducerea şi adaptarea: - Da. Impact Console \ Decalajul consumatorilor a crescut prin normalizarea, gruparea, detectarea anomaliei, generarea și etapele de prelucrare aferente. **Contenție** Câteva atenuări intermediare suplimentare CPU și memorie, limite relaxate de verificare a sănătății, o bază de date de repornire, și un bazin de conectare mai mare ameliorat problema. Dezactivarea noii caracteristici atât în regiunile afectate restaurat prin pus brusc și durabil. Incidentul a fost rezolvat la 17:29 UTC. # **Acţiuni preventive** Următoarele acțiuni sunt angajate și urmărite intern până la finalizare. Caracteristica care a declanșat acest incident rămâne dezactivată și nu va fi reactivată până când lucrarea de mai jos este completă și validată. Traducerea şi adaptarea: - Da. Adăugați un indice de bază de date construit pentru modelul de acces de căutare a serviciilor
Traducere automată din actualizarea oficială a incidentului.
We are currently investigating a Harness component that is experiencing issues. We are working to identify the cause and restore normal operations as soon as possible.
We are continuing to investigate this issue.
The issue has been identified and a fix is being implemented.
This incident has been resolved.
## Summary Customers on Prod1, Prod2, and Prod3 \(US\) clusters experienced failures when loading SEI 2.0 dashboards on August 6, 2026, from 7:22 AM PDT to 9:03 AM PDT. Customers calling the SEI 2.0 API also experienced similar failures. No customer data was lost, and ingestion of all integration data continued to work uninterrupted. SEI customers using 1.0 were not impacted. ## Root Cause The incident was caused by resource exhaustion on the nodes serving queries. This resource degradation developed in a pattern that did not cross our existing alerting thresholds early enough to provide sufficient warning or allow mitigation before customer impact occurred. ## Impact Customers on Prod1, Prod2, and Prod3 \(US\) clusters were unable to load SEI 2.0 dashboards during the incident window. **Duration:** August 6, 2026, 7:22 AM PDT – 9:03 AM PDT \(~1 hour 41 minutes\) ### What was not impacted? * Data ingestion and processing * SEI 1.0 customers * Integrations and metadata flows No customer data was lost. ## Remediation Upon identifying the root cause, our team took immediate corrective action by adding capacity to restore the affected systems. Services were fully recovered, and all dashboards resumed normal operation at 9:03 AM PDT. ## Action Items To prevent from such issues happening again, Harness is/has Proactively added capacity updates have been applied to prevent this issue from recurring #### Enhanced Monitoring and Alerting Additional monitoring and alerting have been put in place to detect anomalies early, focused on a leading indicator, which in this case was thread pool exhaustion, before they can impact dashboard availability and data rendering. #### System Patch in Progress We are working with our vendor to apply a patch to remediate this and similar issues completely.
Monitorizăm conductele blocate din prod2. Noile execuţii trec în timp ce noi monitorizăm continuu serviciile.
Monitorizăm conductele blocate din prod2. Pentru clienţii care încă mai văd conducte blocate, vă cerem să anulaţi şi să re-declanşaţi.
Acest incident a fost rezolvat.
"Summary" La 6 august 2026 \ [dimineața PDT\], unii clienți care rulează conducte în mediul de producție Prod2 au observat execuții ale conductelor care au încetat să mai facă progrese Problema a fost raportată de clienții afectați. Inginerii Harness au identificat cauza, au atenuat impactul şi execuţiile conductelor au revenit la funcţionarea normală. Problema a fost cauzată de o expresie auto-preferențială a conductei. Un webhook Git a declanşat o conductă care a făcut referire la conţinutul sarcinii utile webhook, iar sarcina utilă în sine conţinea copii suplimentare ale aceleiaşi expresii. Prin urmare, fiecare rundă de rezoluție a expresiei a produs mai multe expresii pentru a rezolva, dublezând cantitatea de muncă de fiecare dată. Acest lucru a epuizat resursele instanţei de serviciu care a procesat această execuţie, precum şi alte execuţii atribuite în aceeaşi instanţă nu au putut progresa în timp ce se afla în acest stat. ## **Impact** În timpul ferestrei incidentului \ (aproximativ 6:11 AM - 11:23 AM PDT pe 6 august 2026\): * Execuțiile de conducte ale unor clienți de pe Prod2 au stagnat la mijlocul execuției și nu au mai făcut progrese. * Execuțiile afectate nu au produs noi actualizări de stare și au trebuit să fie anulate și re-run după atenuare. * Comportamentul a fost limitat la executii fiind prelucrate de instanta de serviciu afectate Nu a fost nicio pierdere de date**. Definiţiile conductelor, istoria execuţiei şi starea stocată nu au fost afectate. Majoritatea conductelor de pe Prod2 au continuat să execute cu succes pe parcursul incidentului; principalul impact a fost că unele execuţii în timpul zborului nu au putut fi finalizate şi necesare pentru a fi reluate după atenuarea problemei. ## **Root Cause** Conductele de harness susţin expresiile care sunt rezolvate în timpul de funcţionare În acest caz, un mesaj de comitere Git conținea textul literal al expresiei de încărcare utilă în sine, de două ori, iar conducta făcea referire la aceeași expresie de încărcare utilă. Deoarece mesajul de comitere face parte din sarcina utilă webhook, rezolvarea expresiei a introdus întreaga sarcină utilă Aceste copii nou introduse au fost apoi tratate ca expresii care trebuie rezolvate, iar fiecare trecere a introdus încă două copii complete ale sarcinii utile. Mărimea valorii fiind procesată, iar munca necesară pentru a o procesa, prin urmare, s-a dublat la fiecare trecere și a crescut exponențial mai degrabă decât convergent. Harness are scopul de a opri exact acest lucru: rezoluția expresiei este delimitată de o adâncime maximă a cuibului, dincolo de care rezoluția se oprește și conducta nu reușește cu o eroare explicită. Un defect în această salvgardare a însemnat că limita nu a fost aplicată în acest caz specific de auto-preferinţă, astfel încât rezoluţia a continuat necontrolată. Rezolutia expresiei ruleaza in linie pe firele care pornesc treptele conductei. Pe măsură ce fiecare trecere a consumat progresiv mai mult memorie și procesor fără a finaliza vreodată, instanta de servicii care efectuează că munca a încetat să mai facă progrese, și fiecare execuție atribuită acestui caz blocat ## **Contencios Harness a completat următoarele etape imediate de atenuare: * Identificat conducta și modelul de expresie responsabil pentru rezoluția fugar. * Oprit instanţa de serviciu afectate, astfel încât aceasta ar lua pe nici o lucrare mai departe. Celelalte cazuri sănătoase au fost preluate și prelucrate în mod normal la coadă. * Confirmat că execuţiile conductelor au revenit la normal şi au închis incidentul. Aceste acţiuni au restaurat comportamentul normal de execuţie a conductei şi au rezolvat impactul clientului. ## **Action items** Pentru a reduce riscul de recurență și a îmbunătăți detectarea, următoarele acțiuni sunt puse în aplicare în diferite etape: * Fixaţi defectul în adâncimea expresiei şi detecţia buclei de protecţie astfel încât expresiile autonome să fie prinse şi să eşueze rapid cu o eroare clară în loc să consume resurse fără obligaţii. * Prevenirea expresiilor de sarcină utilă să fie rezolvate din conținutul de declanșare sarcină utilă, eliminarea în întregime calea de auto-referențială. * Strângeţi adâncimea maximă de cuib de expresie şi evaluaţi detectarea explicită a buclei în plus faţă de limita de adâncime existentă. * Îmbunătățește testele automate în mediile pre-producție care reproduc modele de expresie auto-preferențiale și verifică dacă protecția le detectează și le oprește. * Adăugaţi monitorizarea pentru acest model în execuţiile conductelor astfel încât să fie detectat proactiv.
Traducere automată din actualizarea oficială a incidentului.
We are currently investigating this issue.
We are continuing to investigate this issue.
We have identified the issue and started to implement the fix , prod2 is restored.
We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.
We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.
This incident has been resolved.
# Executive Summary On August 4, 2026, between approximately 3:36 PM and 9:00 PM IST, customers using Infrastructure as Code Management \(IaCM\) on Prod0 and Prod1 were unable to access the Variable Sets settings page. The page rendered blank with no error message, and customers with Variable Sets attached to their workspaces could not view or manage them for the duration of the incident. Prod2, Prod3, and EU1 were not affected. Separately, during the same window, a scheduled maintenance action caused the IaCM settings tab to temporarily disappear across all environments. This was identified and reversed within the incident bridge call before significant customer impact occurred. We deployed a hotfix that restored full access to the Variable Sets page on Prod0 and Prod1 the same evening, and we are implementing permanent safeguards described below to prevent this class of issue from recurring. # Impact * Customers with the Variable Sets feature enabled on Prod0 and Prod1 were unable to view or manage Variable Sets for approximately 5–6 hours. * No data was lost or corrupted, this was a UI routing failure only; underlying Variable Sets data and configuration were not affected. * Prod2, Prod3, and EU1 were not affected by this issue. * A secondary issue, a scheduled feature flag operation caused the IaCM settings tab to temporarily disappear across all environments during the incident bridge call. This was identified and reversed within minutes. External customer exposure for this secondary issue is still being confirmed. # Root Cause A platform routing change released on July 18, 2026 updated how IaCM settings pages are resolved in the user interface. As part of that change, any settings page that had not been explicitly re-registered in the new routing structure became unreachable. The Variable Sets page had not been re-registered under the new routing structure, making it inaccessible in the environments where the routing change had been deployed — Prod0 and Prod1. Because the failure occurred at the routing layer rather than within the page itself, the page rendered blank with no visible error rather than showing a clear failure message. # Remediation ## Immediate We deployed a hotfix that re-registered the Variable Sets page in the updated routing structure, restoring access for all affected customers on Prod0 and Prod1. ## Permanent We are adding automated end-to-end tests that navigate to settings pages with relevant feature flags enabled, configured as a required gate in our release pipeline. We are also documenting and enforcing the routing constraint through static analysis so that settings pages are never inadvertently left out of the routing structure during future platform changes. # Action Items To prevent such issues from happening again, 1. Enhance automated tests, that navigate to settings pages with relevant feature flags enabled, configured as a blocking gate in the release pipeline, so this class of regression is caught before it reaches production. 2. Establish an explicit checklist step for future platform-wide architectural changes that verifies all existing settings pages remain accessible in the updated routing structure before the change is promoted to production.
În prezent investigăm această problemă.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
# ** Summary ** Între 25 iulie și 4 august 2026, panourile de bord de execuție a conductelor și paginile de prezentare din clusterele Harness Prod 2 și Prod 3 au afișat date între timp real. Conductele în sine au continuat să construiască, să desfășoare și să execute în mod normal pe tot parcursul; problema s-a limitat la cât de repede au fost copiate înregistrările de execuție în baza de date care servește la raportarea și vizualizarea tabloului de bord. **Nu s-au pierdut date despre clienţi.** Fiecare înregistrare afectată a rămas stocată în mod durabil și a fost reutilizată în depozitul de date de analiză odată ce limitarea de bază a fost eliminată. La 1 august 2026, Harness a migrat clusterele afectate într-o versiune orizontală scalabilă și susținută de coadă a componentei replicare și a completat backfill-uri de date vizate pentru toate conturile afectate. Cauza Root Harness menține o componentă de captare a datelor care reproduce continuu înregistrările de execuție a conductei din depozitul de date operaționale primare într-un magazin de date separat pentru seriile temporale optimizat pentru tablouri de bord și întrebări de raportare. Tablouri de bord citite exclusiv de la magazinul de date de analiză. Când replicarea rămâne în urmă, tabloul de bord redă o viziune exactă, dar mai veche, asupra lumii, în timp ce execuţia însăşi nu este afectată. Acest lucru a fost cauzat de creșterea ascuțită, susținută a volumului de scriere a bazei de date dintr-un alt modul platforma Harness care partajează aceeași cale de replicare a depășit plafonul de trecere al versiunii mai vechi, mono-integrare a acelei componente încă rulează în Prod 2 și Prod 3. Un backlog format și a crescut. # **Acţiuni preventive** Harness a finalizat sau s-a angajat în următoarele acțiuni de prevenire a acestor probleme. Traducerea şi adaptarea: - Da.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
# ** Summary ** La 31 iulie 2026, încărcăturile de artefacte efectuate prin conducte în grupul UE1 au început să scadă cu o eroare de autentificare. Încărcăturile iniţiate manual \(în afara unei conducte\) nu au fost afectate, iar capacitatea de a recupera artefactele existente \(downloads\) a fost, de asemenea, neafectat # **Impact** * Încărcăturile de artefact efectuate prin conducta din grupul UE1 au eşuat cu o eroare de autentificare timp de aproximativ 4 ore şi 34 minute. * Recuperarea artefactelor existente \ (downloads\) nu a fost afectată. * Încărcarea manuală a artefactelor în afara conductei nu a fost afectată. * Alte clustere/regiuni nu au fost afectate de această problemă. # **Root Cause** Componenta responsabilă pentru manipularea uploadurilor de artefact bazate pe conducte este distribuită ca imagine de container. În grupul UE1, această imagine este preluată dintr-un registru intern care reflectă o sursă de imagine publică; în alte grupuri, aceeași imagine este preluată direct de la sursa publică. O eroare de publicare în procesul nostru de lansare a cauzat o nouă construcţie a acestei componente să fie publicată folosind o etichetă versiune care a fost deja în uz, mai degrabă decât să i se atribuie o nouă versiune unică. Ca urmare, două imagini diferite au fost asociate cu aceeași etichetă de versiune din sursa publică. Registrul nostru intern reflectă imagini din sursa publică printr-un proces automatizat de replicare. Din cauza modului în care replicarea a fost declanșată, a copiat imaginea originală \ [mai devreme\) asociată cu această etichetă versiune, mai degrabă decât cea corectată. Acest lucru a însemnat clusterul UE1, care se trage din oglinda internă, a ajuns să ruleze o imagine diferită, defectă decât alte grupuri, care trage direct de la sursa publică și, prin urmare, a primit imaginea corectată. Imaginea defectă conţinea o problemă de autentificare care a dus la eşecul uploadurilor conductei. # **Contenţionarea** * Reverificat contul afectat la ultima versiune cunoscută-bună a componentei de încărcare, restaurarea imediată a upload-uri conducte. * A publicat o versiune corectată, permanentă a componentei pentru a rezolva problema în toate clusterele. Urmatorii pasi * Fix pasul de încărcare pentru a elimina defectul de bază legate de container care a făcut acest mod de defect posibil. * Actualizați conducta noastră de lansare pentru această componentă, astfel încât publicarea unei imagini nu poate suprascrie o versiune existentă .
Traducere automată din actualizarea oficială a incidentului.
Rezumat - Ne confruntăm intermitent cu probleme legate de conectivitatea rețelei cu incapacitatea VM de a se conecta la resurse externe. În prezent investigăm problema.
A fost implementată o soluţie şi monitorizăm rezultatele.
Continuăm să monitorizăm orice alte probleme.
Acest incident a fost rezolvat.
## Rezumat Începând cu 4 august 2026, IC runners în regiunile ne-vest1 și ne-central1 a experimentat intermitent timeouts conexiune de aproximativ 134 de secunde atunci când ajunge la servicii externe, cum ar fi GitHub și Bitbucket peste gateway-uri de rețea outbound. ## Impact * IC runners în regiunile afectate experimentat intermitent timeouts conexiune de aproximativ 134 secunde atunci când ajunge la servicii externe \(de exemplu, GitHub, Bitbucket\) peste gateway-urile noastre de rețea de ieșire. * Problema a fost intermitentă, mai degrabă decât constante conexiunile au reuşit sub sarcină normală, şi eşecuri grupate în perioadele de volum mare de trafic outbound. * Nu au fost pierdute sau corupte date. Aceasta a fost o problemă de interconectare a rețelei și de capacitate, nu o problemă de integrare a datelor. * noi-vest1 și noi-central1 au fost regiunile afectate; alte regiuni nu au fost afectate de această problemă. ## Root Cause Echilibrul nostru de sarcină distribuie traficul de ieșire prin mai multe porți NAT folosind o metodă de hashing bazată pe detalii de conexiune \ (sursa / adresa de destinație și port\). Pentru orice conexiune, aceste detalii rămân constante pentru acea conexiune. Am avut un val de trafic susţinut pentru câteva secunde care a congestionat porţile ## Action items Pentru a preveni astfel de probleme să se întâmple din nou Harness va, Creşterea capacităţii de conexiune în afara porţilor noastre NAT prin furnizarea de interfeţe de reţea externă suplimentare, oferind fiecărei porţi o reţea de conexiuni substanţial mai mare pe care o poate servi concomitent..
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Continuăm să investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
Continuăm să lucrăm la o soluție pentru această problemă.
A fost implementată o soluţie şi monitorizăm rezultatele.
Continuăm să monitorizăm orice alte probleme.
Acest incident a fost rezolvat.
Sumarul În timpul unei implementări recente a producției, un defect în implementarea noastră internă a determinat două servicii critice să funcționeze cu valori incorecte, neproductive de configurare în mediul nostru de producție Acest lucru a dus la un set de patru simptome distincte: comportament de configurare incorectă, eşecuri intermitente de conectare/acces, o problemă de acces la fişiere care afectează mediul unui client şi actualizări întârziate ale stării conductei în UI. Am identificat și implementăm o fixare permanentă pentru defectul de configurare de bază, și am pus deja în aplicare modificări de resurse și capacitate care rezolvă simptomul de întârziere UI. În nici un moment în timpul acestui incident nu au fost execuţii ale conductelor pierdute, corupte sau lăsate într-o stare blocată. În cazul în care comportamentul de execuție a fost afectat, acesta a fost limitat la întârzieri în vizibilitatea statutului, nu în procesul de bază. # Incident Detalii ## Valori incorecte de configurare a producției aplicate Echipa noastra de inginerie a confirmat un defect in conducta de implementare Service Manager care a cauzat implementarea anumitor servicii de productie folosind valorile de configurare destinate unui mediu diferit, mai degraba decat configuratia corecta de productie. **Root Cause** Serviciul responsabil pentru preluarea suprascrie configurarea în timpul implementării întrebări un API intern care returnează un maxim de 1.000 de rezultate pe cerere. Numărul total de servicii în mediu a crescut recent dincolo de această limită. Prin urmare, orice serviciu care depășește primele 1.000 returnate nu a fost inclus în răspuns, iar conducta de implementare a scăzut în tăcere la valorile implicite de configurare pentru aceste servicii. Acesta este un defect confirmat de paginare în uneltele de implementare, nu o problemă cu valorile de configurare în sine. **Rezoluţie** Ingineria a confirmat mecanismul și pune în aplicare un fix permanent pentru a elimina acest decalaj legat de limită în conducta de implementare. ## Intermittent Login / Acces esecuri În timpul implementării serviciului manager menționat mai sus, unii utilizatori s-au confruntat cu erori intermitente de conectare sau acces. În condiții normale de funcționare, cazurile care au condus anterior ar trebui să continue să servească traficul fără întrerupere, în timp ce o nouă desfășurare este în curs de desfășurare. În acest incident, că comportamentul de rezervă nu a avut loc așa cum era de așteptat, contribuind la eșecuri de acces în timpul ferestrei de desfășurare. ## Filestore Access Issue A fost identificată o problemă de acces la fişiere care a fost specifică mediului Prod-3 şi a afectat mediul unui singur client. **Root Cause** Acest lucru este legat de o configuraţie permisiune IAM / stocare-bucket pe Service Manager, potenţial declanşată de activitatea de răsturnare. ## Întârzierea execuției conductei Starea actualizărilor în UI Unii utilizatori au observat că graficul de execuție a conductei din UI a fost lent pentru a reîmprospăta și nu a reflectat cel mai recent statut cu promptitudine. Important, aceasta a fost doar o întârziere a vizibilităţii: nu a existat niciun impact asupra execuţiilor reale ale conductelor şi nici o execuţie nu a fost blocată sau eşuat ca urmare a acestei probleme. **Root Cause** Graficul de execuție a conductei se bazează pe un flux de mesaje \ (logul orchestrării\) pentru a primi actualizări de stare. În timpul ferestrei incidentului, procesarea de către consumator a acestui flux a scăzut în urmă \ (lag mare de consum\), ceea ce a întârziat cât de repede actualizările statutului au ajuns la UI. Acest lucru a fost cauzat de faptul că baza de date de bază a fost în mijlocul unei operațiuni planificate de scalare în același timp, și un vârf de trafic în timpul acelei ferestre a exacerbat în continuare întârzierea. Utilizatorii au experimentat acest lucru ca aparenta încetinire a conductei, chiar dacă execuţiile subiacente funcţionau normal. **Rezoluţie** Am crescut capacitatea de resurse pentru componentele afectate pentru a menține mai mult de 50% cameră de rezervă merge mai departe, reducând sensibilitatea la piroane de sarcină similare. Această modificare a fost pusă în aplicare și este validată în prezent ca parte a întăririi pe termen lung a acestei părți a platformei. Rezumat de impact * Service Manager and License Manager a rulat cu valori de configurare incorecte în mediile Prod-1 și Prod-3. * Unii utilizatori au experimentat eşecuri intermitente de conectare sau acces în timpul ferestrei de implementare afectate. * Un mediu client în Prod-3 experimentat o problemă de acces filestore. * Utilizatorii de-a lungul mediilor afectate au văzut actualizări întârziate ale stării de execuție a conductei în UI; execuția conductei de bază a continuat să funcționeze corect și nu au fost pierduți, blocați sau corupți. # Acțiuni preventive Au fost identificate următoarele acțiuni corective și preventive. Traducerea şi adaptarea: - Da. Se adaugă garanții astfel încât un serviciu care nu poate recupera configurația nu reușește în condiții de siguranță \ [de exemplu, alerte și blocuri de implementare\) mai degrabă decât în tăcere se încadrează înapoi la neproducție. Recunoastem impactul pe care acest incident l-a avut asupra mai multor domenii ale platformei si apreciem rabdarea dumneavoastra pe masura ce lucram printr-o rezolutie completa.
Traducere automată din actualizarea oficială a incidentului.
Investigăm o problemă care afectează tabloul de bord AIDI. Utilizatorii pot experimenta perioade de încărcare crescute sau defecțiuni intermitente atunci când accesează tabloul de bord. Echipa noastră este activ de lucru pentru a identifica cauza rădăcină și de a restabili performanța normală. Vom furniza actualizări pe măsură ce mai multe informații devin disponibile.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
## Rezumat Clienții de pe Prod1, Prod2, și Prod3 clustere au experimentat defecțiuni intermitente de încărcare widget și a crescut timpul de încărcare atunci când accesa AIDI 2.0 borduri de bord pe 22 iulie 2026. Nu toate widget-urile au fost afectate simultan problema manifestată ca eșecuri sporadice mai degrabă decât o pană completă. Nu s-au pierdut date despre clienţi. Clienţii SEI 1.0 nu au fost afectaţi. ## Root Cause De-a lungul timpului, un proces de întreținere de bază de date de rutină nu a reușit să ruleze pe anumite tabele din baza noastră de date de analiză, determinând aceste tabele să acumuleze un volum mare de metadate interne utilizate pentru a urmări înregistrările șterse. Atunci când baza de date a planificat întrebări împotriva acestor tabele, a încărcat toate aceste metadate acumulate în memorie, cauzând utilizarea memoriei pe nodurile afectate pentru a Spike în mod repetat. Aceste piroane repetate au declanșat un mecanism automat de siguranță care reporneşte un nod atunci când detectează presiunea excesivă a memoriei, iar nodurile afectate au început să repornească într-o buclă ca rezultat. Acest lucru a cauzat o performanță intermitentă și degradată pe tabloul de bord AIDI 2.0 pe durata incidentului. ## Impact Clienții de pe Prod1, Prod2, și Prod3 clustere pot fi experimentat defecțiuni intermitente de încărcare widget sau ori de încărcare crescută pe AIDI 2.0 borduri de bord. **Duraţie:** 22 iulie 2026, 07:58 PDT Ce nu a fost afectat? * Ingestia și prelucrarea datelor * SEI 1.0 clienti * Fluxuri de integrare și metadate Nu s-au pierdut date despre clienţi. ## Remediation La identificarea problemei, nodurile de baze de date afectate au fost reluate la 08:25 PDT, care a restabilit stabilitatea inițială. Am continuat să monitorizăm îndeaproape sistemul, iar atunci când degradarea intermitentă a fost încă observată după aceea, am aplicat mai multe remedieri suplimentare: * Setări ajustate de configurare a bazei de date pentru a limita cantitatea de memorie utilizată pentru prelucrarea metadatelor acumulate, și setările reglate de interogare pentru a reduce presiunea de memorie. * A fugit de locuri de muncă de curățare pentru a reduce backlog de metadate acumulate pe tabelele afectate. * Creșterea capacității pe nodurile de baze de date afectate pentru a oferi headroom suplimentar. Aceste modificări au stabilizat progresiv sistemul, iar incidentul a fost complet rezolvat la 16:16 PDT. ## Action items Pentru a preveni recurența, punem în aplicare următoarele: 1. Am actualizat backend-ul care include îmbunătățiri care stau la baza care manipulează piroane de memorie cauzate de ștergerea excesivă a fișierelor. 2. Am lansat locuri de muncă compactare automată pentru tabele nou introduse pentru a preveni eliminarea acumulării de fișiere merge mai departe.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
Sumarul La 17 iulie 2026, ca urmare a implementării unui cod de rutină, clienții pe versiuni delegate mai vechi \ (858xx și mai jos\) au început să experimenteze CI întârziată construiește Harness Cloud-hosted construiește folosind capacitatea noastră globală de a construi. Clădirile afectate s-au confruntat cu o pauză neașteptată de până la aproximativ 8 minute în etapa de "asteptare pentru infrastructură" înainte de a continua, în loc să continue în timpul sub-al doilea așteptat. În general, lentoarea a fost intermitentă. # Impact * Toate clădirile CI au fost potenţial supuse întârzierii; impactul a fost cel mai pronunţat pentru construcţiile pe infrastructura găzduită de Harness Cloud folosind funcţia globală de construcţie. * Clădiri afectate experimentat o pauză inexplicabilă de până la aproximativ 8 minute înainte de a continua, urmată de un "start rece" mai lent, deoarece un slot de calcul pre-conservat nu a fost disponibil * Conturile care rulează pe versiuni delegate mai noi \ (858xx și mai sus\) nu au fost afectate. * Nici o construcţie nu a eşuat în mod direct ca urmare a acestei probleme şi nu s - au pierdut date. Cauza rădăcină Cauza rădăcină a fost o schimbare de cod intern care a rupt accidental modul în care a fost citită o anumită înregistrare de build-coueing din baza noastră de date o dată construiește care a fost deja coadă în conformitate cu versiunea anterioară a codului întâlnit versiunea nou implementată. Am rezolvat impactul imediat prin curățarea înregistrărilor afectate și revenirea la modificarea codului de bază și punem în aplicare mai multe garanții pentru a preveni repetarea acestei clase de emisiuni. Următorii paşi Evaluăm riscul unei recurenţe similare la fel de scăzute ca şi următoarele acţiuni întreprinse. Traseul specific de cod care a cauzat acest incident a fost deja returnat și punem în aplicare garanții structurale astfel încât această clasă generală de probleme să nu poată să reapară, indiferent de locul în care s-ar putea produce altfel. Traducerea şi adaptarea: - Da. Adăugați identificatori expliciti și stabili la toate clasele de date interne care sunt stocate în baza noastră de date, astfel încât reorganizările viitoare ale codului intern să nu poată rupe capacitatea sistemului de a citi înregistrările stocate anterior.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Continuăm să monitorizăm orice alte probleme.
Acest incident a fost rezolvat.
Sumarul Intre 19 iunie si 17 iulie 2026, intrarea in Git Clone pas AMD64 \ (Intel/AMD\) construiește, Windows construiește, și calea binară fără containere VM nu au fost afectate. Cauza rădăcină a fost un defect în procesul nostru de publicare a imaginii interne care a cauzat imagini ARM64-tagged drone-git să conțină de fapt binare AMD64. Am identificat şi atenuat problema în aceeaşi zi în care a fost raportată prin revenirea imaginii drone-git la ultima versiune cunoscută-bună. Nu a fost necesară nicio acțiune a clientului sau modificare a configurației. Cauza rădăcină La 19 iunie 2026, o remediere de securitate a restructurat modul în care este construită imaginea drone-git. Clădirile AMD64 au fost actualizate corect, dar conducta de construcţie ARM64 nu a construit fişiere ARM64 direct Schimbarea din 19 iunie a modificat fişierul AMD64 astfel încât înlocuirea tăcută nu-op'd în loc de a eşua, astfel încât conducta a publicat o imagine etichetat ARM64 ale cărui binare Git Clone şi Git LFS au fost încă compilate pentru AMD64. # Impact * Afected: The built-in Git Clone step, and any stream step using the drone-git clone plugin, running on ARM64 Kubernetes built infrastructure, all accounts, between July 6 to July 17, 2026. * Symptom: Builds failed at the Git Clone step with exec /usr/local/bin/clone: exec format eroare. * Neafectat: AMD64 \ (Intel/AMD\) Kubernetes și VM construiește, Windows construiește, VM cale de execuție fără containere, și varianta noastră de imagine întărită. # Diminuarea Am returnat versiunea de imagine a drone-git folosită în toate serviciile afectate până la ultima versiune cunoscută. Acest lucru a rezolvat complet eșecurile de execuție ARM64; nu au fost necesare modificări ale configurației clienților. Următorii paşi Pentru a preveni astfel de probleme să se întâmple din nou. * Reconstruiește conducta de publicare a imaginii ARM64 pentru a construi fișierele noastre ARM64 dedicate construi direct, în loc să adapteze fișierele de construcție AMD64. * Îmbunătățește validarea automată post-publică la fiecare versiune de imagine: verifica arhitectura binară se potrivește cu eticheta de imagine, și rula un test de fum funcțional înainte de o imagine este considerat relesable. * Extinde acoperirea automată de testare pentru a include ARM64 Kubernetes construi scenarii. * Eliminați versiunile de imagini intermediare afectate din circulație odată ce eliberarea corectată este validată.
Traducere automată din actualizarea oficială a incidentului.