Istoricul incidentelor Harness

1. 27 octombrie 2026 la 19:52 UTCinvestigating

   În prezent investigăm această problemă.

2. 27 octombrie 2026 la 19:58 UTCinvestigating

   Conductele IC pe infrastructura VM nu reușesc la etapa de inițializare, deoarece sarcina merge la un delegat în afara rezervei avute în vedere

3. 27 octombrie 2026 la 21:15 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

4. 27 octombrie 2026 la 22:16 UTCmonitoring

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

5. 27 octombrie 2026 la 22:24 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 19 octombrie 2026 la 07:46 UTCinvestigating

   În prezent investigăm această problemă.

2. 19 octombrie 2026 la 08:02 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

3. 19 octombrie 2026 la 08:04 UTCmonitoring

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

4. 19 octombrie 2026 la 08:21 UTCresolved

   Acest incident a fost rezolvat.

5. 23 octombrie 2026 la 18:21 UTCpostmortem

   "Summary" La 19 octombrie 2026, între aproximativ 12:10 AM și 12:55 AM PDT, clienții Prod4 au experimentat erori și indisponibilitatea intermitentă a serviciilor de conducte Harness. Execuțiile de conducte grele au condus la o creștere bruscă a procesorului și la utilizarea memoriei în serviciul conductei, iar pentru o perioadă scurtă toate cazurile de serviciu nu au fost disponibile. Ingineria Harness a escaladat serviciul atât vertical cât și orizontal, care a restaurat serviciul. Un fix pentru comportamentul de bază este în curs de desfășurare. ## **Root Cause** Pe 19 octombrie, numărul mare de execuţii simultane cu grafice foarte mari de execuţie a condus la o creştere puternică a resurselor de clustere. Serviciul stochează și recuperează acest grafic de execuție completă în scopul vizualizării și avansează în continuare conductele către următoarele state. Auto-scalare noastre pe Prod4 a durat mai mult decât de obicei pentru scalarea resurselor din cauza unei creșteri ascuțite în CPU și memorie. Ca parte a fixării, actualizarea graficului de execuție va procesa acum schimbările treptate în loc de graficul complet. Acesta este rulat în mod progresiv și va fi complet rulat cel mai devreme. ## **Impact** * Utilizatori afectaţi: Clienţi pe Prod4. * Symptom: Indisponibilitatea funcționalității conductei în platforma Harness. * Data: No data loss. * Sugerat de lucru în jurul valorii de: Nu este necesar de la clienți. Ingineria Harness a rezolvat problema. * Durata impactului: Aproximativ 20 de minute de ineficiență totală și performanță degradată timp de 25 de minute. Harness a continuat monitorizarea după recuperare și a confirmat stabilitatea platformei cu clienții. ## **Remediation** ** Imediat ** Inginerie Harness scalat serviciul de conducte atât vertical \ (mai multe resurse per exemplu\) și orizontal \ (mai multe cazuri\), și a eliminat cazuri într-o stare nesănătoasă. Numărul de cazuri s-a stabilizat şi serviciul normal a fost restabilit. Sistemul va rămâne ridicat până când fix este complet rulat. ** Fixare permanentă și elemente de acțiune ** Pentru a preveni astfel de probleme să se întâmple din nou, Harness este 1. Tuning procesul auto de vindecare / scalare astfel încât impactul este mimimal la nici unul. 2. Optimizarea fluxului grafic de execuție astfel încât graficele mari să poată fi procesate mai repede.

Traducere automată din actualizarea oficială a incidentului.

1. 15 octombrie 2026 la 10:10 UTCinvestigating

   În prezent investigăm această problemă.

2. 15 octombrie 2026 la 10:10 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

3. 15 octombrie 2026 la 10:27 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 15 octombrie 2026 la 08:04 UTCinvestigating

   În prezent investigăm această problemă.

2. 15 octombrie 2026 la 08:05 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

3. 15 octombrie 2026 la 08:09 UTCmonitoring

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

4. 15 octombrie 2026 la 08:15 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 13 octombrie 2026 la 01:06 UTCinvestigating

   În prezent investigăm această problemă.

2. 13 octombrie 2026 la 01:07 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

3. 13 octombrie 2026 la 01:56 UTCmonitoring

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

4. 13 octombrie 2026 la 04:29 UTCresolved

   Acest incident a fost rezolvat.

5. 23 octombrie 2026 la 03:16 UTCpostmortem

   . .

Traducere automată din actualizarea oficială a incidentului.

1. 12 octombrie 2026 la 15:25 UTCinvestigating

   În prezent experimentăm erori HTTP 429 (limitarea ratei) atunci când Harness Cloud construiește accesul Maven Central, care poate avea impact asupra execuției. Echipa noastră lucrează activ cu Sonatype pentru a rezolva problema cât mai repede posibil. Vom furniza noi actualizări pe măsură ce progresăm.

2. 12 octombrie 2026 la 19:31 UTCresolved

   Acest incident a fost rezolvat.

3. 23 octombrie 2026 la 03:06 UTCpostmortem

   tldr: \ (A existat o scurtă limitare a ratei de Maven Central\) Mai multe detalii de urmat

Traducere automată din actualizarea oficială a incidentului.

1. 8 octombrie 2026 la 10:23 UTCmonitoring

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

2. 8 octombrie 2026 la 10:53 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 6 octombrie 2026 la 21:46 UTCinvestigating

   În prezent investigăm această problemă.

2. 6 octombrie 2026 la 21:47 UTCinvestigating

   Continuăm să investigăm această problemă.

3. 6 octombrie 2026 la 22:03 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

4. 6 octombrie 2026 la 22:30 UTCmonitoring

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

5. 6 octombrie 2026 la 22:30 UTCmonitoring

   A fost implementată o soluţie şi monitorizăm rezultatele. Avem confirmarea că am rezolvat problema.

6. 6 octombrie 2026 la 22:44 UTCresolved

   Acest incident a fost rezolvat.

7. 23 octombrie 2026 la 02:12 UTCpostmortem

   # 1. Rezumat La 6 octombrie 2026, conductele care conțineau o etapă IaCM nu au putut începe pe Prod1 timp de aproximativ două ore. Utilizatorii afectaţi au văzut o eroare atunci când conducta a încercat să-şi creeze planul de execuţie. Conductele care nu au utilizat o etapă laCM au continuat să curgă în mod normal. Cauza principala a fost un defect de exploatare interna in serviciul care se ocupa de executia scenei IaCM: intr-o anumita conditie, rara, acel sistem de exploatare forestiera propriu al serviciului ar putea ajunge sa se astepte la nesfarsit, ceea ce, la randul lui, a blocat procesul mai larg responsabil de pregatirea planurilor de executie a conductei. Problema a fost declanșată de o explozie neobișnuit de mare de activitate jurnal de la conducta unui client. Am rezolvat impactul imediat prin rularea serviciului înapoi la versiunea sa stabilă anterioară, și o fix permanent cod este în prezent în testare. # 2. Impact * Toate conductele care utilizează o etapă IaCM pe Prod1 nu au putut începe timp de aproximativ două ore. * Au fost afectaţi mai mulţi clienţi din grupul Prod1. * Conductele care nu au utilizat o etapă IaCM nu au fost afectate și au continuat să funcționeze în mod normal. * Nu au fost pierdute date ca urmare a acestui incident. * Ca un efect secundar al rolei utilizate pentru a rezolva acest incident, un fix fără legătură pentru un singur client \ (extinderea cât timp un anumit jeton de autentificare rămâne valabil în timpul conductelor de lungă durată\) a fost temporar returnat. Reparaţia a fost reutilizată în aceeaşi seară. # 3. Cauza rădăcină Serviciul responsabil pentru etapele conductei IaCM își înregistrează activitatea printr-o coadă internă: mesajele jurnal sunt plasate la coadă, iar un singur lucrător de fundal citeşte continuu din ea și scrie mesajele. Separat, acest serviciu are un filtru care poate rescrie severitatea anumitor mesaje jurnal înapoi pe aceeași coadă. Într-o anumită stare de sincronizare îngustă, aceasta a creat un blocaj, dacă coada se întâmpla să fie complet plină în momentul exact în care un mesaj rescris a fost trimis înapoi pe el, singurul lucrător responsabil pentru eliberarea spaţiului la coadă ar fi rămas blocat aşteptând ca spaţiul să se elibereze, o condiţie pe care nu o putea rezolva, deoarece era singurul lucru care putea elibera acel spaţiu. Odată ce acest lucru s-a întâmplat, orice altă parte a serviciului care trebuia să înregistreze orice a devenit, de asemenea, blocată în așteptare, care a intrat în cascadă în procesul de creare a conductei-plan care a eșuat pentru orice conductă utilizând o etapă IaCM. # 4. Rezoluţie * Rolat serviciul înapoi la ultima versiune stabilă, care a rezolvat incidentul imediat. # 5. Acțiuni preventive 1. ** Optimizează defectul de bază**: Optimizează și reglează filtrul de logare astfel încât rescrierea severității unui mesaj să se întâmple pe firul care a generat linia de logare, în loc să fie resuscitat prin coada aceluiași lucrător de fundal, eliminând în întregime starea de blocaj. 2. **Monitorizarea performantei in domeniul sanatatii de logare**: adaugati indicatori si alertati pe aceasta coada interna astfel incat aceasta clasa de saturare sa aiba acces automat la echipa noastra in loc sa se bazeze pe rapoartele clientilor. 3. **Evaluați limitele și efectuați teste de rezistență ridicate cu conducte foarte mari**:

Traducere automată din actualizarea oficială a incidentului.

1. 16 octombrie 2026 la 10:41 UTCresolved

   Pe 7 octombrie 2026, de la ora 08:00 UTC până la ora 11:00 UTC (1:30 PM până la ora 4:30 IST), unele execuţii ale conductei pe clusterul Prod 7 au văzut eşecuri intermitente în evaluările de etapă ale politicii (OPA).

Traducere automată din actualizarea oficială a incidentului.

1. 6 octombrie 2026 la 12:54 UTCmonitoring

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

2. 6 octombrie 2026 la 15:35 UTCresolved

   Acest incident a fost rezolvat.

3. 10 octombrie 2026 la 01:57 UTCpostmortem

   ### Rezumat Clienţii de pe Prod 2 au avut eşecuri intermitente ale câtorva etape de verificare la pornire. Etapele afectate au eșuat la scurt timp după lansare cu un mesaj care indica verificarea continuă\ (CV\) nu a putut ajunge la un serviciu intern Harness. Problema a rezultat dintr-o actualizare recentă a serviciului care a introdus punerea în comun a conexiunii pentru a îmbunătăți performanța și fiabilitatea, cu un cadru permanent incompatibil cu termenul de pauză al serviciului de primire. Nicio informaţie despre clienţi nu a fost pierdută sau coruptă. ### Customer Impact Clientii care folosesc CV-ul Verifica pasii pe Prod-2 au ramas fara pas intermitent in timpul ferestrei incidentului. Rata de eşec a fost mică. Majoritatea execuţiilor au fost finalizate cu succes pe tot parcursul ferestrei. Conductele care nu au utilizat CV-ul nu au fost afectate de verificarea etapelor. ### Root Cause O actualizare recentă a serviciului CV a introdus conectarea în comun la o componentă a platformei interne, cu o durată de viață constantă mai lungă decât perioada de pauză în regim inactiv a acelei componente. Conexiunile inactive suficient de mult timp au fost închise în tăcere de către server; serviciul CV nu a detectat acest lucru și nu a avut nici o logică retry pentru astfel de eșecuri, ceea ce le face să iasă la suprafață direct ca verifica eșecuri pas. Problema a fost intermitentă pentru că a afectat doar conexiunile care s-au întâmplat să fie inactive suficient de mult pentru a expira. ### Metuation Durata de viață a conexiunii a fost redusă pentru a se încadra în intervalul de timp inactiv al serviciului de primire. Eșecurile au scăzut imediat la aproape zero și nu s-au observat alte eșecuri de acest tip în niciun mediu de producție. ### Next Steps Pentru a preveni recidiva, Harness: * ** Manipularea conexiunii Fix:** Tuned implicit keep-alive și activat retry automat pe defecțiunile de conectare, astfel încât erorile de conectare stald sunt manipulate transparent. * ** Adăugaţi rezistenţă la startup pas:** Introducerea retry cu backoff pentru apelul de serviciu intern la Start de verificare pas, astfel încât eșecuri tranzitorii izolate nu suprafață ca eșecuri pas imediat. * ** Impoved alerting:** Monitorizarea îmbunătățită a ratelor de eroare a conexiunii interne.

Traducere automată din actualizarea oficială a incidentului.

1. 6 octombrie 2026 la 11:58 UTCinvestigating

   În prezent investigăm această problemă.

2. 6 octombrie 2026 la 11:59 UTCinvestigating

   Continuăm să investigăm această problemă.

3. 6 octombrie 2026 la 12:24 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

4. 6 octombrie 2026 la 16:21 UTCresolved

   Acest incident a fost rezolvat.

5. 9 octombrie 2026 la 18:48 UTCpostmortem

   ## Rezumat Pe **Marți, 6 octombrie 2026**, conductele IaCM care utilizează ** plugin-ul OpenTofu** în **Prod1** nu a reușit intermitent pentru un cont de producțieAffected ruleaza secrete injectate cu succes, apoi pașii mai târziu temporizate sau au eșuat autentificarea. Aceeaşi conductă a reuşit de multe ori să se refacă, fără nicio schimbare de configurare. Execuţiile tipice au durat aproximativ 90 de minute. Alte module Harness nu au fost afectate în mare măsură. Nu avem nici un raport de pierdere a datelor clientului. Conductele care s-au terminat în timpul vieţii simbolice nu au fost afectate de acest defect. ## Root Cause Etapele de autentificare la IaCM au expirat după o oră. Controalele de politică mai târziu pe termen lung au respins jetonul, astfel încât etapa a expirat sau a eșuat autentificarea. Acea viaţă de o oră a fost reparată. Timp de aproximativ 90 de minute a trecut marca de o oră, motiv pentru care eșecurile au apărut pe conducte mai lungi și de multe ori eliminate pe o rejudecare mai scurtă. Un set separat de erori de plan în același cont a venit de la configurarea credibilă în spațiul de lucru al clienților și este în afara acestui incident. ## Impact * **Area produsului:** Conducte IaCM folosind plugin-urile IaCM care vorbesc cu OPA sdk. * ** Experienţa clientului:** timeouts intermitente şi eşecuri de autentificare după injectare secretă, pe rulează mai mult de aproximativ o oră. * **Mediu:** Prod1, un cont de producție * **Data:** Nicio pierdere de date raportată. ## Remediation * **Imediat:** A deschis o pagină de stare pentru contul afectat Prod1, și a expediat o schimbare interimară manager IaCM pentru o clasă de eșecuri observate în timp ce fix plugin a fost construit. * **Permanent:** Shipped un hotfix de extensie OpenTofu astfel încât expirarea jeton este configurabil. În producţie, durata de viaţă a fost ridicată la aproximativ 6 ore, astfel încât o conductă lungă să nu supravieţuiască jetonului. Hotfix a fost validat în QA și a fost trimis la Prod1. Ne cerem scuze pentru deranjul cauzat. Vă rugăm să contactaţi persoana de contact Harness dacă aveţi orice întrebări suplimentare.

Traducere automată din actualizarea oficială a incidentului.

1. 5 octombrie 2026 la 22:01 UTCinvestigating

   În prezent investigăm această problemă.

2. 5 octombrie 2026 la 23:50 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

3. 6 octombrie 2026 la 00:26 UTCmonitoring

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

4. 6 octombrie 2026 la 00:26 UTCmonitoring

   Continuăm să monitorizăm orice alte probleme.

5. 6 octombrie 2026 la 00:39 UTCresolved

   Verificat fix și rezolvat problemele SSO.

6. 9 octombrie 2026 la 16:17 UTCpostmortem

   ## Okta Application SP-Initiated SSO Login Eşecuri Sumarul Între 5 octombrie 2026, 18:18 UTC și 6 octombrie 2026, 00:26 UTC, unii clienți Harness nu s-au putut conecta la serverul Holded MCP prin intermediul SAML Single Sign-On \(SSO\). Autentificarea principală a portalului Harness a rămas pe deplin operațională. Utilizatorii afectaţi au văzut erori de autentificare sau au fost redirecţionaţi către o pagină SSO invalidă în loc să completeze sign-in. Problema a fost cauzată de ruperea schimbărilor într-o versiune de actualizare a serviciului de identitate Harness HarnessID. Am reparat-o cu o serie de hotfixs, și SSO login a fost complet restaurat pentru toți clienții afectați. # Impact Utilizatorii care au semnat la Harness MCP prin SAML SSO nu au putut finaliza autentificarea. Sesiunile MCP existente care s-au bazat pe SSO nu au putut fi reîmprospătate, astfel încât unii utilizatori au trebuit să se înscrie din nou și nu au putut. Autentificare non-SSO la MCP găzduit a lucrat în timpul cea mai mare parte a incidentului. Nu au fost pierdute sau expuse date ale clienților. Clienții care utilizează propria configurație generică de aplicații SAML 2.0 în Okta nu au fost afectați. Cauza rădăcină La 29 septembrie 2026, o versiune actualizată a aplicației Harness a fost publicată în rețeaua de integrare Okta. Actualizarea a adăugat suport pentru înregistrarea mai multor răspunsuri \(ACS\) URL-uri, astfel încât clienții care rulează Harness în mai multe regiuni sau medii ar putea configura mai multe URL-uri de răspuns. Harness include o valoare AssertionConsumerServiceURL în cererea de autentificare SAML pe care o trimite la Okta. Înainte de această actualizare, Okta nu a validat această valoare pentru cazurile de aplicare fără URL-uri ACS suplimentare configurate și a returnat în schimb afirmația SAML la URL-ul implicit ACS aplicației. După actualizare, această validare a devenit activă în toate cazurile de aplicare existente, inclusiv în cele în care clientul nu a configurat un URL ACS suplimentar. Deoarece valoarea solicitată nu a fost prezentă în lista înregistrată a instanței, Okta a returnat o eroare HTTP 400. Aplicația actualizată a trecut prin revizuirea standard a OIN, care include verificarea înapoi-compatibilitate împotriva instalațiilor existente ale integrării publicate. Această modificare a comportamentului de validare pentru cazurile fără URL-uri ACS suplimentare configurate nu a fost evidențiată în timpul revizuirii, astfel încât a ajuns la clienți în momentul eliberării. # Remediere ** Răspuns imediat ** Pe pagina de stare au fost publicate două programe de lucru: conectați-vă de pe placa Harness din Okta \(IdP-inițiat login\), care nu a fost afectată, sau înregistrați URL-ul Okta SSO al aplicației în câmpul URL ACS suplimentar al aplicației Harness Okta. Harness angajat fiecare client raportat afectat direct și validat lor de sign-in. **Rezoluţie** Rularea aplicației înapoi la versiunea anterioară a fost evitată în mod deliberat, deoarece aceasta ar amâna doar aceeași perturbare la următoarea versiune. Fiecare client afectat a fost în schimb deblocat prin înregistrarea URL ACS, și lucrăm cu Okta pentru a face validarea URL ACS condiționată din nou, astfel încât cazurile fără URL-uri ACS suplimentare configurate să se comporte exact așa cum au făcut-o înainte, și nu este necesară nicio acțiune a clientului. Articole de acțiune Pentru a preveni repetarea acestor probleme, Harness va lua următoarele măsuri 1. Lucrul cu Okta pentru a restabili validarea ACS a URL-ului condiţionat, astfel încât cazurile fără URL-uri ACS suplimentare configurate să se comporte exact ca înainte şi nu este necesară nicio acţiune a clientului. 2. Publicarea unui ghid de configurare dedicat pentru aplicația Harness OIN în documentația Harness, inclusiv răspunsul \ (ACS\) URL cerințe. 3. Adăugați un pas independent de verificare înainte de lansare împotriva configurațiilor existente ale clienților pentru orice actualizare viitoare a aplicației Okta publicate, alături de propria revizuire a Okta. 4. Migrați autentificarea utilizatorului la ID Harness, care elimină dependența de acest comportament de validare în întregime.

Traducere automată din actualizarea oficială a incidentului.

1. 29 septembrie 2026 la 20:31 UTCinvestigating

   În prezent investigăm această problemă.

2. 29 septembrie 2026 la 20:31 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

3. 29 septembrie 2026 la 20:57 UTCidentified

   Am identificat o problemă care se aplică numai pentru autentificarea iniţiată de SP prin aplicaţia publicată Harness Okta. După o actualizare recentă la această aplicație, acele încercări de autentificare au returnat o eroare HTTP 400 atunci când URL-ul SSO configurat lipsea din URL-uri ACS suplimentare. Configurațiile generale SAML 2.0 în Okta nu sunt afectate. Soluţii imediate: Utilizaţi login iniţiat IDP. Începeţi logarea de pe tigla aplicaţiei Harness din Okta. Sau Adăugați URL-ul Harness SSO la URL-uri ACS suplimentare în aplicația Harness Okta publicată.

4. 2 octombrie 2026 la 00:33 UTCresolved

   Acest incident a fost rezolvat.

5. 7 octombrie 2026 la 18:30 UTCpostmortem

   # 1. Rezumat Începând cu 29 septembrie 2026, clienții care se înscriu la Harness prin intermediul aplicației publicate Harness în Okta Integration Network \ (OIN\) nu au reușit să completeze autentificarea SP-inițiată SSO. Utilizatorii afectaţi au primit o eroare HTTP 400 de la Okta în loc să fie semnaţi. Problema a fost introdusă printr-o modificare a modului în care Okta a validat răspunsul solicitat \ (ACS\) URL pentru instalațiile existente ale aplicației Harness publicate. Lucrările au fost publicate într-o oră de la primul raport, iar fiecare client afectat a fost deblocat. # 2. Impact * Impactul s-a limitat la clienţii care au folosit aplicaţia publicată Harness de la reţeaua de integrare Okta pentru autentificarea iniţiată de SP \ (începerea sign-in de la Harness\). Aceste încercări au returnat o eroare HTTP 400 din Okta. * IdP-inițiat de conectare, a început de la placa Harness în Okta, a continuat să lucreze pe tot parcursul. * Clienții care utilizează propria lor SaML 2.0 aplicații generice în Okta nu au fost afectate. * Nu au fost pierdute sau expuse date ale clienților. # 3. Cauza rădăcină La 29 septembrie 2026, o versiune actualizată a aplicației Harness a fost publicată în rețeaua de integrare Okta. Actualizarea a adăugat suport pentru înregistrarea mai multor răspunsuri \(ACS\) URL-uri, astfel încât clienții care rulează Harness în mai multe regiuni sau medii ar putea configura mai multe URL-uri de răspuns. Harness include o valoare AssertionConsumerServiceURL în cererea de autentificare SAML pe care o trimite la Okta. Înainte de această actualizare, Okta nu a validat această valoare pentru cazurile de aplicare care nu au avut URL-uri ACS suplimentare configurate, și pur și simplu a returnat afirmația SAML la URL-ul implicit ACS aplicației. După actualizare, această validare a devenit activă în toate cazurile existente ale aplicației, inclusiv în cele în care clientul nu a configurat niciodată un URL ACS suplimentar. Deoarece valoarea solicitată nu a fost prezentă în lista înregistrată a instanței, Okta a respins cererea de autentificare cu o eroare HTTP 400. Aplicația actualizată a trecut prin revizuirea standard a OIN, care include verificarea înapoi a compatibilității cu instalațiile existente ale unei integrări publicate. Această modificare a comportamentului de validare pentru cazurile fără URL-uri ACS suplimentare configurate nu a fost apărută în timpul revizuirii, astfel încât a ajuns la clienți la lansare. # 4. Remediere ** Răspuns imediat ** Pe pagina de stare au fost publicate două lucrări: conectați-vă de pe placa Harness în Okta \(IdP-inițiat login\), care nu a fost afectată; sau înregistrați URL-ul Okta SSO al aplicației în câmpul URL ACS suplimentar al aplicației Harness Okta. Suport angajat fiecare client afectat direct și validat sign-in cu ei. **Rezoluţie** Rularea aplicației înapoi la versiunea anterioară a fost evitată în mod deliberat, deoarece aceasta ar amâna doar aceeași perturbare la următoarea versiune. Fiecare client afectat a fost în schimb deblocat prin înregistrarea URL-ului ACS, și lucrăm cu Okta pentru a face validarea URL-ului ACS condiționată din nou, astfel încât cazurile fără URL-uri ACS suplimentare configurate să se comporte exact așa cum au făcut-o înainte și nu este necesară nicio acțiune a clientului. # 5. Obiecte de acțiune Pentru a preveni repetarea acestor probleme, lucrăm la Traducerea şi adaptarea: - Da. Colaborarea cu Okta pentru a restabili validarea condiționată a URL-ului ACS, astfel încât cazurile fără URL-uri ACS suplimentare configurate să se comporte exact ca înainte și nu este necesară nicio acțiune a clientului. Adauga un pas independent de verificare pre-lansare impotriva configuratiilor clientilor existente pentru orice actualizare viitoare a aplicatiei Okta publicate, alaturi de propria recenzie a lui Okta.

Traducere automată din actualizarea oficială a incidentului.

1. 29 septembrie 2026 la 18:45 UTCinvestigating

   În prezent investigăm această problemă.

2. 29 septembrie 2026 la 21:55 UTCmonitoring

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

3. 29 septembrie 2026 la 22:01 UTCresolved

   Acest incident a fost rezolvat.

4. 2 octombrie 2026 la 22:40 UTCpostmortem

   ### Rezumat Între aproximativ **11:37 AM și 3:01 PM PDT \(18:37 **Root Cause** Acest lucru s-a datorat în primul rând saturaţiei NAT-ului nostru, care a fost exacerbat de o capacitate de calcul a furnizorului temporar de nori, prevenind furnizarea de noi VM acolo. Impact * Clienții care rulează Linux CI auto-hosted construiește în noi-vest1 fierăstrău **permitent built/pipeline eșecuri**, nu o pană completă. * Erorile cu care se confruntă clienţii au inclus Git payouts, de exemplu, ** Remediation ** * **Imediat:** Rezechilibrat ARM build-VM sarcina de la saturate ne-vest1 calea spre central1 \ [parțial limitat de central1 capacitate\); a repornit căile afectate Cloud NAT, care stabilizat rețea de conducte. **Action items** 1. Asigurați poarta de acces NAT suplimentară / capacitate IP \ (In progres\) 2. Îmbunătățește detectarea saturației NAT și alertarea înaintea impactului clientului. 3. Evaluarea suprataxelor de capacitate interregională, astfel încât penuria de calcul a unei singure regiuni să nu blocheze atenuarea eșuării.

Traducere automată din actualizarea oficială a incidentului.

1. 29 septembrie 2026 la 14:41 UTCinvestigating

   În prezent investigăm această problemă.

2. 29 septembrie 2026 la 15:54 UTCmonitoring

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

3. 29 septembrie 2026 la 15:57 UTCmonitoring

   Continuăm să monitorizăm orice alte probleme.

4. 29 septembrie 2026 la 18:49 UTCresolved

   Acest incident a fost rezolvat.

5. 2 octombrie 2026 la 05:37 UTCpostmortem

   ** Summary ** Clienţii de pe Prod-2 au înregistrat rate ridicate de eşec în conductele de verificare continuă. Locurile de muncă de verificare nu au reușit să completeze sau să raporteze erori, deoarece lucrătorii de colectare a datelor CV-uri nu au putut comunica cu serviciul platformei care le coordonează activitatea. Acest lucru a fost cauzat de un vârf de trafic neașteptat la unul dintre sistemele noastre de suport. Serviciul a fost restaurat prin eliminarea componentei afectate a platformei. Nu s-au înregistrat pierderi de date sau corupţii. ** Impactul clientului ** Clientii care utilizeaza Verificare continua pe Prod-2 a vazut locuri de munca conducta de verificare esueaza sau timpul in timpul ferestrei incidentului. O parte semnificativă a cazurilor de locuri de muncă de verificare care au avut loc în această perioadă s-a încheiat cu un eșec operațional. Conductele care nu utilizează CV-ul au continuat să funcționeze normal. **Root Cause** O procedură de furnizare automată de mari dimensiuni a creat un număr semnificativ de lucrători persistenți care monitorizează CV-urile într-o perioadă scurtă de timp, ceea ce a depășit o componentă a platformei partajate. Creşterea bruscă a apelurilor efectuate concomitent a epuizat conexiunile de reţea disponibile în fiecare instanţă de servicii. **Contenție** Limita maximă de scalare pentru serviciul CV a fost ridicată, permițându-i să extindă capacitatea de a satisface cererea. Eşecurile s-au oprit la scurt timp după ce s-a terminat ieşirea. **Următoarele etape** Pentru a preveni recidiva, Harness: * **Creștere a capacității headroom și adăugarea balustrade de alimentare:** Creșterea limitei de scalare a serviciului CV pentru menținerea headroom-ului sub sarcini de spargere și introducerea limitării ratei pentru furnizarea în vrac a serviciilor monitorizate. * ** Îmbunătățirea rezilienței:** Adăugați exponențial backoff și nervozitate pentru retries lucrătorilor, și de a folosi un bazin de conectare reutilizabil pentru a reduce cheltuielile generale și pentru a preveni eșecurile tranzitorii de la descompunerea sub convailități mari. * ** Îmbunătățește monitorizarea și alertarea:** Sporirea alertei pentru ratele anormale de creștere a lucrătorilor pe cont, astfel încât condiții similare sunt detectate și au acționat mai devreme.

Traducere automată din actualizarea oficială a incidentului.

1. 29 septembrie 2026 la 13:12 UTCresolved

   Pe 28 septembrie 2026, am observat o problemă cu copierea fișierelor din magazinul Harness în timpul etapei de export, unde fișierele au fost copiate ca fișiere nule/goale. Ca urmare, toate conductele care au utilizat API-uri Filestore au fost blocate în timpul ferestrei incidentului. Problema a fost cauzată de o lansare a steagului care a fost returnată odată ce problema a fost descoperită. Toate operaţiile au revenit la normal.

2. 1 octombrie 2026 la 17:28 UTCpostmortem

   ### Rezumat Pe 28 septembrie 2026, unii clienți de pe Prod-2 eșecuri experimentate în pașii conductei CD care citesc conținutul File Store folosind expresiile conductei \(ex., Expresiile afectate returnate nul în loc de conținutul de fișier așteptat, ceea ce face pașii dependenți să eșueze sau să se comporte incorect. Problema a fost urmărită la o actualizare platformă care a înăsprit controalele de autorizare pe API File Store. Actualizarea a fost rulat înapoi, iar expresiile File Store au fost de lucru în mod normal de atunci. ### Customer Impact * Doar pașii conductei pe Prod-2 care citesc conținutul File Store prin expresii au fost afectate. Conductele care nu folosesc expresiile File Store nu au fost afectate. * Expresii afectate rezolvate la nul, provocând pași care depind de configurare sau setări fișiere pentru a eșua sau produce ieșire incorectă. * Nu a fost modificat conţinutul magazinului File. Nu au fost expuse dosare, secrete, acreditări sau artefacte şi nu s-au pierdut date. ### Root Cause Ca parte a unei inițiative de securitate în curs de desfășurare, Harness a desfășurat controale mai stricte de autorizare pe mai multe platforme API, inclusiv API care servește conținutul File Store. Atunci când o conductă evaluează o expresie File Store, un serviciu intern Harness apelează un alt pentru a prelua fișierul. Noile verificări ale autorizaţiei au eşuat, ceea ce a dus la respingerea cererilor, iar expresiile nule. ### Metuation Odată ce actualizarea platformei a fost identificată ca fiind cauza, a fost rulat înapoi în mediul de producție. Expresiile magazinului de fișiere s-au rezolvat corect de la reluare. Nu este necesară nicio acțiune a clienților. ### Măsuri preventive și pașii următori * ** Audit a afectat API:** Analizați toate API-urile în care s-au aplicat controalele mai stricte ale autorizației pentru a se asigura că apelurile interne de serviciu la serviciu sunt corecte. * ** Îmbunătățește acoperirea testului:** Îmbunătățește suitele automate de testare pentru a include evaluarea expresiei File Store peste căile de execuție a conductei

Traducere automată din actualizarea oficială a incidentului.

1. 23 septembrie 2026 la 20:17 UTCinvestigating

   Investigăm în prezent probleme de conectivitate care afectează clienții ale căror medii sunt protejate de firewall-uri Palo Alto Networks. Aceste firewall-uri blochează conexiunile la API-urile Harness, ceea ce poate duce la: - Execuții de conducte eșuate - Incapacitatea de a implementa cereri - Temporizări intermitente la accesarea caracteristicilor platformei Harness - Eșecuri de integrare cu instrumente terțe părți - Conectivitate delegata cu platforma Harness Această problemă nu este cauzată de o întrerupere a serviciului Harness, ci mai degrabă de regulile firewall de pe partea de rețea. Consilierim clienţii să facă o excepţie pentru obiectivele DNS.

2. 24 septembrie 2026 la 08:43 UTCmonitoring

   Diminuarea disponibila: Traficul Harness blocat de politica de securitate a retelei Am identificat o problemă în cazul în care unii clienți ar putea fi în imposibilitatea de a accesa Harness deoarece traficul Harness este clasificat ca Dacă vă confruntaţi cu această problemă: Vă rugăm să contactați echipa de rețea/Firewall/CyberSecurity a organizației dumneavoastră și să solicitați ca traficul necesar Harness să fie permis prin politica dvs. Palo Alto firewall. Ca o atenuare, clienţii pot permite categoria de tip AI-Platform După actualizarea politicii firewall, accesul la Harness ar trebui restabilit. Important: Politica firewall este gestionata de echipa de retea/securitate a clientului. În cazul în care obiectivul Harness este clasificat incorect de Palo Alto, clienții pot solicita, de asemenea, o revizuire URL-categoria de la Palo Alto Networks.

3. 25 septembrie 2026 la 17:10 UTCresolved

   După consultarea cu Palo Alto Networks, putem confirma că pe 23 septembrie 2026, app.harness. Io a fost clasificat ca un serviciu al platformei AI de către echipa Palo Alto Networks. Palo Alto Networks a trimis un anunț clienților în august cu privire la reclasificare. Această schimbare poate plasa Serviciul Platformei AI în cadrul unei politici diferite decât aplicația.harness. fosta categorie de reguli IO, Informaţii informatice şi internet. Politica aplicată depinde de setările clienţilor. Clienții Harness ar trebui să discute această clasificare și alertele cu echipa lor de rețea internă și Palo Alto Networks.

4. 13 octombrie 2026 la 04:50 UTCpostmortem

   .

Traducere automată din actualizarea oficială a incidentului.

1. 22 septembrie 2026 la 16:40 UTCinvestigating

   În prezent investigăm această problemă.

2. 22 septembrie 2026 la 17:14 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

3. 22 septembrie 2026 la 18:01 UTCmonitoring

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

4. 22 septembrie 2026 la 18:38 UTCresolved

   Acest incident a fost rezolvat.

5. 2 octombrie 2026 la 22:05 UTCpostmortem

   Sumarul Pe 22 septembrie 2026, trei dintre porțile noastre de rețea de ieșire într-o regiune au devenit nesănătoase și au început să respingă un procent mic de noi încercări de conexiune de ieșire. Problema a fost rezolvată în aceeaşi zi, fără să se mai repete sau să se mai urmărească impactul. Cauza de bază a fost un tampon saturat de monitorizare a traficului intern pe aceste porți de acces, care a cauzat controalele lor de sănătate să răspundă prea lent și să se marcate nesănătoase. # Impact * Doar trei cazuri de acces într-o regiune au fost afectate; alte regiuni şi alte porţi din aceeaşi regiune nu au fost afectate. * Nu a fost nici un eșec în cascadă , problema a fost pe deplin rezolvată cu o singură rundă de reporniri gateway , și nu a avut loc după aceea . Cauza rădăcină Portile noastre de retea de iesire ruleaza o componenta interna care monitorizeaza traficul retelei pentru vizibilitate operationala. Sub un trafic ridicat susținut, tamponul intern al acestei componente a devenit saturat, care a creat backpresh suficient de sever pentru a încetini propriile răspunsuri de sănătate-verificare dincolo de timeout echilibrul nostru de sarcină permite. Odată depăşită perioada de pauză, balanţa de sarcină a marcat porţile afectate nesănătoase şi a început să respingă o porţiune de noi conexiuni destinate acestora. Expedierea efectivă a pachetelor a continuat să funcționeze normal pe parcursul incidentului. Aceasta a fost în mod specific o problemă de sănătate și monitorizare-buffer, nu un eșec al capacității de transfer de bază a porților. # Rezoluţie Cele trei cazuri afectate de poartă au fost repornite manual, care au curăţat tamponul de monitorizare saturat şi au restabilit imediat comportamentul normal de control al sănătăţii. Respingerile conexiunii s-au oprit imediat ce repornirea a fost finalizată şi nu a mai fost necesară nicio intervenţie suplimentară. # Acțiuni preventive Traducerea şi adaptarea: - Da.

Traducere automată din actualizarea oficială a incidentului.

1. 22 septembrie 2026 la 14:00 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

2. 22 septembrie 2026 la 14:08 UTCmonitoring

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

3. 22 septembrie 2026 la 14:20 UTCresolved

   Acest incident a fost rezolvat.

4. 2 octombrie 2026 la 22:10 UTCpostmortem

   La fel ca şi cauza anterioară.

Traducere automată din actualizarea oficială a incidentului.

1. 21 septembrie 2026 la 16:39 UTCinvestigating

   În prezent investigăm această problemă.

2. 21 septembrie 2026 la 17:12 UTCidentified

   Problema a fost identificată și se pune în aplicare o soluție.

3. 21 septembrie 2026 la 18:27 UTCmonitoring

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

4. 21 septembrie 2026 la 18:33 UTCresolved

   Acest incident a fost rezolvat.

5. 29 septembrie 2026 la 22:39 UTCpostmortem

   ## Rezumat Pe 21 septembrie 2026, clienții din Prod 2 s-au confruntat cu o degradare și apoi, în mare măsură, cu borduri de desfășurare indisponibile timp de aproximativ trei ore. Problema a fost cauzată de un set de întrebări de analiză din spatele acelor tablouri de bord care citeau mult mai multe date decât aveau nevoie, ceea ce a epuizat capacitatea bazei de date care le servea. O repornire la rulare a serviciului afectat restaurat borduri complet, iar platforma a fost stabilă de atunci. ## Impactul clientului Pagini de bord încărcate lent sau temporizate între 14:48 și 18:11 UTC. Executarea conductei și înregistrarea implementării sunt efectuate pe infrastructuri separate și au continuat să funcționeze în mod normal. Nu s-au înregistrat pierderi de date sau corupţii. ## Root Cause Interogările tabloului de bord lipseau un filtru cu rază de timp pe coloana utilizată pentru a împărți cel mai mare tabel în segmente săptămânale, astfel încât fiecare interogare să citească toate datele istorice în loc de perioada solicitată. Corectitudinea nu a fost niciodată afectată Pe măsură ce volumul de date a crescut, costul acestor citiri a depășit ceea ce baza de date ar putea servi, și retries de întrebări care nu au dat rezultate suplimentare, astfel încât condiția nu a fost clară până la reluarea serviciului. ## Metuation * Efectuat o repornire de rulare a serviciului afectat, care a oprit ciclul de rejudecare și a permis bazei de date pentru a finaliza munca sa remarcabilă * Confirmat bord latență și utilizarea conexiunii baza de date a revenit la niveluri normale ## Next Steps Pentru a preveni recidiva, Harness: * Adăugați filtrul lipsă de interval de timp la întrebările de bord afectate, astfel încât fiecare citește doar perioada solicitată * Înlocuiți retries imediat cu retries delimitate, suport-off * Îmbunătăţirea detecţiei prin adăugarea de alertă privind utilizarea conexiunii bazei de date şi costul execuţiei per-query

Traducere automată din actualizarea oficială a incidentului.