Historia awarii Harness

1. 27 października 2026 19:52 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 27 października 2026 19:58 UTCinvestigating

   Gazociągi CI na infrastrukturze VM nie działają na etapie Initialize, ponieważ zadanie trafia do delegata poza planowaną pulą

3. 27 października 2026 21:15 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

4. 27 października 2026 22:16 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

5. 27 października 2026 22:24 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 19 października 2026 07:46 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 19 października 2026 08:02 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 19 października 2026 08:04 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

4. 19 października 2026 08:21 UTCresolved

   Ten incydent został rozwiązany.

5. 23 października 2026 18:21 UTCpostmortem

   / Podsumowanie W dniu 19 października 2026 r., między 12: 10 a 12: 55 AM PDT, klienci na Prod4 doświadczyli błędów i przerywanej niedostępności usług rurociągów Harness. Ciężkie egzekucje rurociągów doprowadziły do gwałtownego wzrostu procesora i wykorzystania pamięci w serwisie rurociągu, a przez krótki czas wszystkie przypadki serwisowe były niedostępne. Inżynieria uprzęży skalowała usługę zarówno pionowo, jak i poziomo, która została przywrócona. Naprawiamy podstawowe zachowanie. * * * Root Cause * * 19 października duża liczba równoległych egzekucji z bardzo dużymi wykresami wykonania doprowadziła do znacznego wzrostu zasobów klastrów. Serwis przechowuje i pobiera ten pełen wykres wykonania dla celów wizualizacji i dalszego postępu rurociągów do kolejnych stanów. Nasze autoskalowanie na Prod4 zajęło więcej czasu niż zwykle do skalowania zasobów ze względu na gwałtowny wzrost CPU i pamięci. W części fix, aktualizacja wykresu wykonania będzie teraz przetwarzać wykres zmienia się stopniowo zamiast pełnego wykresu. Jest on rozwijany w sposób stopniowy i zostanie w najwcześniejszym czasie całkowicie rozwinięty. * * Impact * * * Dotknięci użytkownicy: Klienci na Prod4. * Symptom: niedostępność funkcji rurociągu w platformie Harness. * Dane: Brak utraty danych. * Sugerowana praca: Nie wymaga od klientów. Inżynieria uprzęży rozwiązała problem. * Czas trwania uderzenia: Około 20 minut pełnej niedostępności i zdegradowanej wydajności przez 25 minut. Uprząż nadal monitorował po odzyskaniu i potwierdzone stabilność platformy z klientami. * * * Remediation * * * * Natychmiastowa * * Inżynieria uprzęży skalowała obsługę rurociągu zarówno pionowo\ (więcej zasobów na instancję\), jak i poziomo\ (więcej instancji\) oraz usuwała przypadki w niezdrowym stanie. Liczba przypadków ustabilizowana i normalna obsługa została przywrócona. System pozostanie skalowany, aż do końca. * * Stałe elementy naprawcze i działania * * Aby zapobiec takim problemom ponownie, Harness 1. Dostrajanie procesu auto uzdrawiania / skalowania tak, że uderzenie jest mimimalne do zera. 2. Optymalizacja przepływu wykresu wykonania tak, aby duże wykresy mogły być przetwarzane szybciej.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 15 października 2026 10:10 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 15 października 2026 10:10 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 15 października 2026 10:27 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 15 października 2026 08:04 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 15 października 2026 08:05 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 15 października 2026 08:09 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

4. 15 października 2026 08:15 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 13 października 2026 01:06 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 13 października 2026 01:07 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 13 października 2026 01:56 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

4. 13 października 2026 04:29 UTCresolved

   Ten incydent został rozwiązany.

5. 23 października 2026 03:16 UTCpostmortem

   . .

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 12 października 2026 15:25 UTCinvestigating

   Obecnie doświadczamy błędów HTTP 429 (ograniczenie rate-), gdy Harness Cloud buduje dostęp do Maven Central, co może mieć wpływ na wykonanie budowy. Nasz zespół aktywnie współpracuje z Sonatypem, aby jak najszybciej rozwiązać ten problem. Dostarczymy dalsze aktualizacje w miarę postępów.

2. 12 października 2026 19:31 UTCresolved

   Ten incydent został rozwiązany.

3. 23 października 2026 03:06 UTCpostmortem

   tldr:\ (Była krótka stawka ograniczająca przez maven central\) Więcej szczegółów do naśladowania

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 8 października 2026 10:23 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

2. 8 października 2026 10:53 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 października 2026 21:46 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 6 października 2026 21:47 UTCinvestigating

   Nadal badamy tę kwestię.

3. 6 października 2026 22:03 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

4. 6 października 2026 22:30 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

5. 6 października 2026 22:30 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki. Mamy potwierdzenie, że naprawiamy problem.

6. 6 października 2026 22:44 UTCresolved

   Ten incydent został rozwiązany.

7. 23 października 2026 02:12 UTCpostmortem

   1. Podsumowanie W dniu 6 października 2026 r., rurociągi zawierające etap IaCM nie były w stanie rozpocząć prac nad Produd1 przez około dwie godziny. Dotknięci użytkownicy zauważyli błąd, gdy rurociąg próbował stworzyć swój plan realizacji. Rurociągi, które nie korzystały z etapu IaCM, nadal przebiegały normalnie przez cały okres. Podstawową przyczyną była wewnętrzna wada logowania w usłudze, która obsługuje wykonanie etapu IaCM: w specyficznym, rzadkim stanie czasowym, że system logowania usługi może skończyć czekając na siebie na czas nieokreślony, co z kolei zablokowało szerszy proces odpowiedzialny za przygotowanie planów realizacji rurociągu. Kwestia ta została wywołana przez niezwykle dużą aktywność dziennika z rurociągu jednego klienta. Rozwiązaliśmy natychmiastowy wpływ przewracając usługę z powrotem do poprzedniej stabilnej wersji, a stały kod fix jest obecnie w trakcie testowania. # 2. Uderzenie * Wszystkie rurociągi wykorzystujące etap IaCM na Prod1 nie mogły rozpocząć się przez około dwie godziny. * Wiele klientów na klastrze Prod1 zostały dotknięte. * Rurociągi, które nie korzystały z etapu IaCM, nie zostały naruszone i nadal działa normalnie. * W wyniku tego incydentu nie utracono żadnych danych. * Jako efekt uboczny cofnięcia używanego do rozwiązania tego incydentu, czasowo cofnięto niepowiązane rozwiązanie dla jednego klienta\ (przedłużając czas ważności pewnego symbolu uwierzytelniającego podczas długotrwałych gazociągów\). Naprawa została ponownie zastosowana tego samego wieczoru. # 3. Root Cause Usługa odpowiedzialna za etapy rurociągów IaCM loguje swoją działalność poprzez wewnętrzną kolejkę: wiadomości logowania są umieszczane w kolejce, a jeden pracownik tła stale z niej czyta i wypisuje wiadomości. Oddzielnie, ta usługa ma filtr, który może przepisać dotkliwość niektórych wiadomości dziennika z powrotem do tej samej kolejki. W określonym, wąskim stanie czasowym, to stworzyło impas, jeśli kolejka zdarzyła się być całkowicie pełna w dokładnym momencie, przepisywana wiadomość została z powrotem do niego, jeden pracownik odpowiedzialny za uwolnienie przestrzeni w kolejce sam utknął czekając na przestrzeń do uwolnienia, warunek, który nigdy nie mógł rozwiązać, ponieważ była to jedyna rzecz, która mogła uwolnić tę przestrzeń. Gdy to się stało, każda inna część usługi, która musiała się zalogować, również utknęła w oczekiwaniu, które weszło w proces tworzenia plantacji lodowców i nie powiodło się w przypadku jakiegokolwiek rurociągu wykorzystującego etap IaCM. # 4. Rozdzielczość * Zrolował usługę z powrotem do jej ostatniej stabilnej wersji, która rozwiązała natychmiastowy incydent. # 5. Działania zapobiegawcze 1. * * Optymalizacja wady podstawowej * *: Optymalizacja i dostrojenie filtra logowania tak, aby przepisywanie dotkliwości wiadomości odbywało się na wątku, który wygenerował linię dziennika, zamiast być ponownie wprowadzany przez kolejkę tego samego pracownika tła, eliminując całkowicie stan impasu. 2. * * Wzmocnienie monitorowania stanu zdrowia w loging- kolejka * *: dodaj wskaźniki i ostrzegaj w tej kolejce wewnętrznej, aby ta klasa stron nasycenia nasz zespół on-call automatycznie zamiast polegać na raportach klientów. 3. * * Ocena granic i wykonanie wysokich testów warunków skrajnych z bardzo dużych rurociągów * *:

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 16 października 2026 10:41 UTCresolved

   W dniu 7 października 2026 r., od 08: 00 UTC do 11: 00 UTC (1: 30 PM do 4: 30 PM IST), niektóre egzekucje rurociągów na klastrze Prod 7 spowodowały nieregularne niepowodzenia w ocenie stopniowej polityki (OPA).

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 października 2026 12:54 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

2. 6 października 2026 15:35 UTCresolved

   Ten incydent został rozwiązany.

3. 10 października 2026 01:57 UTCpostmortem

   Podsumowanie Klienci na Prod 2 doświadczyli przerywanych awarii kilku etapów weryfikacji przy starcie. Dotknięte kroki nie powiodły się krótko po uruchomieniu z komunikatem wskazującym, że ciągła weryfikacja\ (CV\) nie może dotrzeć do wewnętrznej usługi Uprząż. Kwestia ta wynikała z niedawnej aktualizacji usługi, która wprowadziła łączenie połączeń w celu poprawy wydajności i niezawodności z zachowaniem żywej ustawień niezgodnych z czasem odbioru usługi. Dane klientów nie zostały utracone ani uszkodzone. # # # Uderzenie klienta Klienci korzystający z CV Sprawdź kroki na Prod-2 widział przerywane awarii kroku w oknie incydentu. Wskaźnik porażki był niski - większość egzekucji zakończyła się sukcesem w całym oknie. Rurociągi, które nie korzystały z CV Sprawdzić kroki nie zostały naruszone. # # Root Cause Niedawna aktualizacja usługi CV wprowadziła łączenie połączeń z wewnętrznym komponentem platformy, z czasem zachowania dłuższym niż czas bezczynności tego komponentu. Połączenia bezczynne wystarczająco długo były cicho zamknięte przez serwer; usługa CV nie wykryła tego i nie miała ponownie logiki dla takich awarii, powodując ich do powierzchni bezpośrednio jako Weryfikacja awarii kroku. Problem ten był przerywany, ponieważ dotyczył tylko połączeń, które okazały się bezczynne wystarczająco długo, aby wygasnąć. - Łagodzenie Czas trwania połączenia został skrócony do czasu bezczynności usługi odbiorczej. Nieprawidłowości spadły do niemal zera natychmiast, i nie zaobserwowano kolejnych awarii tego typu w żadnym środowisku produkcyjnym. * * Next Steps * Aby zapobiec nawrotom, Harness będzie: * * * Napraw obsługę połączenia: * * Zmodyfikowany domyślny keep- alive i włączone automatyczne ponowne wypróbowanie awarii połączenia, tak aby błędy stale-połączenia były obsługiwane w przejrzysty sposób. * * * Dodaj odporność na starcie kroku: * * Wprowadzić ponowną próbę z cofnięciem dla wewnętrznego połączenia serwisowego na początku etapu weryfikacji, tak więc pojedyncze, przejściowe awarie nie pojawiają się jako bezpośrednie awarie kroku. * * * Poprawa alarmowania: * * Zwiększone monitorowanie poziomu błędów wewnętrznych połączeń.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 października 2026 11:58 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 6 października 2026 11:59 UTCinvestigating

   Nadal badamy tę kwestię.

3. 6 października 2026 12:24 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

4. 6 października 2026 16:21 UTCresolved

   Ten incydent został rozwiązany.

5. 9 października 2026 18:48 UTCpostmortem

   Podsumowanie W dniu 6 października 2026 r. Ten sam rurociąg często odniósł sukces po ponownym uruchomieniu, bez zmiany konfiguracji. Typowe nieudane egzekucje trwały około 90 minut. Inne moduły Uprzęży nie były w znacznym stopniu uwzględniane. Nie mamy raportu o utracie danych klientów. Rurociągi, które zakończyły się wewnątrz symbolicznego życia nie zostały naruszone przez tę wadę. # # Root Cause # Etapy IaCM wybiły żetony uwierzytelniające, które wygasły po godzinie. Policy sprawdza później w dłuższej perspektywie czasu, a następnie odrzucił token, więc krok przekroczył czas lub nie uwierzytelnianie. Ta jedna godzina życia została naprawiona. Biegi około 90 minut przekroczyły jednogodzinny znak, dlatego awarie pojawiły się na dłuższych rurociągach i często oczyszczone na krótszą ponowną próbę. Oddzielny zestaw błędów w planie na tym samym koncie pochodzi z konfiguracji kredytowej w miejscu pracy klienta i jest poza tym incydentem. # # Impact * * * Powierzchnia produktu: * * Gazociągi IaCM wykorzystujące wtyczki IaCM rozmawiające z OPA sdk. * * * Doświadczenie klienta: * * przerywane przerwy czasowe i błędy uwierzytelniania po tajnym wstrzyknięciu, działa dłużej niż około godziny. * * * Środowisko: * * Prod1, jedno konto produkcyjne Dane: Nie zgłoszono utraty danych. Uzasadnienie # # Regeneracja * * * Natychmiastowe: * * Otworzyła stronę statusu dla danego konta Prod1 i przesłała tymczasową zmianę menedżera IaCM dla jednej klasy zaobserwowanych awarii podczas gdy plugin fix został zbudowany. * * * Stała: * * Wysłany hotfix wtyczki OpenTofu, więc token event jest konfigurowalny. W produkcji żywotność została podniesiona do około 6 godzin, więc długi rurociąg nie przetrwa symbolu. Hotfix został zatwierdzony w QA i przeniesiony do Prod1. Przepraszamy za zakłócenia. W razie dalszych pytań należy skontaktować się z kontaktem wspierającym Harness.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 5 października 2026 22:01 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 5 października 2026 23:50 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 6 października 2026 00:26 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

4. 6 października 2026 00:26 UTCmonitoring

   Nadal monitorujemy wszelkie dalsze problemy.

5. 6 października 2026 00:39 UTCresolved

   Zweryfikowano problemy dotyczące SSO.

6. 9 października 2026 16:17 UTCpostmortem

   # # Okta Application SP- Inicjated SSO Login Uzasadnienie # Streszczenie Uzasadnienie Między 5 października 2026, 18: 18 UTC a 6 października 2026, 00: 26 UTC niektórzy klienci Harness nie byli w stanie zalogować się do serwera Harness Hosted MCP za pośrednictwem SAML Single Sign- On (SSO\). Autoryzacja głównego portalu Harness pozostała w pełni operacyjna. Zaznaczeni użytkownicy widzieli błędy w logowaniu lub zostali przekierowani do niepoprawnej strony SSO zamiast do zakończenia logowania. Uzasadnienie Kwestia ta została spowodowana przełamaniem zmian w aktualizacji wersji usługi Harnessid. Naprawiliśmy go z serii hotfixów, a logowanie SSO zostało w pełni przywrócone dla wszystkich zainteresowanych klientów. Uzasadnienie # Impact Uzasadnienie Użytkownicy logujący się do Harness MCP za pośrednictwem SAML SSO nie byli w stanie dokończyć uwierzytelniania. Istniejące sesje MCP, które opierały się na SSO, nie mogły być odświeżone, więc niektórzy użytkownicy musieli się ponownie zalogować i nie mogli. Non-SSO loguje Hosted MCP pracował podczas większości incydentu. Nie utracono ani nie ujawniono danych klientów. Klienci stosujący własną konfigurację aplikacji SAML 2.0 w Okcie nie mieli wpływu. # Root Cause 29 września 2026 roku zaktualizowana wersja aplikacji Harness została opublikowana w sieci integracji Okta. Aktualizacja dodała wsparcie dla rejestracji wielu adresów URL odpowiedzi\ (ACS\), tak aby klienci prowadzący firmę Harness w kilku regionach lub środowiskach mogli skonfigurować więcej niż jeden adres URL. Uzasadnienie Uprząż zawiera wartość AssertionConsumerServiceURL w żądaniu uwierzytelniania SAML wysłanym do Okty. Przed tą aktualizacją Okta nie potwierdził tej wartości dla instancji aplikacji bez dodatkowych adresów ACS skonfigurowanych i zamiast tego zwrócił asercję SAML do domyślnego adresu ACS aplikacji. Po aktualizacji walidacja ta stała się aktywna we wszystkich istniejących instancjach aplikacji, w tym tych, w których klient nigdy nie skonfigurował dodatkowego adresu ACS. Ponieważ żądana wartość nie była obecna na liście, Okta zwrócił błąd HTTP 400. Uzasadnienie Zaktualizowana aplikacja przeszła przez standardowy przegląd publikacji OIN w Okcie, który obejmuje weryfikację kompatybilności wstecznej z istniejącymi instalacjami opublikowanej integracji. Ta zmiana w zachowaniu walidacji dla instancji bez dodatkowych skonfigurowanych adresów ACS nie została ujawniona podczas tej recenzji, więc dotarła do klientów w momencie wydania. # Remediation * * Natychmiastowa odpowiedź * * Uzasadnienie Na stronie statusu opublikowano dwa zestawy robocze: zaloguj się z płytki Harness w Okta\ (IdP- inicjowane logowanie\), która nie została naruszona, lub zarejestruj URL Okta SSO aplikacji w polu Dodatkowe ACS URL aplikacji Harness Okta. Uprząż zaangażował każdego zgłoszonego klienta bezpośrednio i potwierdził ich logowanie. Uzasadnienie * * Resolution * * Uzasadnienie Powracając aplikację z powrotem do poprzedniej wersji, celowo uniknięto, ponieważ to tylko odroczyłoby te same zakłócenia do następnego wydania. Każdy poszkodowany klient został odblokowany poprzez rejestrację ACS URL, a my pracujemy z Oktą, aby ponownie uzależnić walidację ACS URL, tak aby przypadki bez dodatkowych skonfigurowanych ACS URL zachowywały się dokładnie tak, jak wcześniej, i nie jest wymagane działanie klienta. # Pozycje działania Aby zapobiec ponownemu wystąpieniu takich problemów, Harness podejmie następujące działania: Uzasadnienie 1. Praca z Okta w celu przywrócenia warunkowej walidacji ACS URL, więc przypadki bez dodatkowych skonfigurowanych adresów ACS zachowują się dokładnie tak jak wcześniej i nie jest wymagane działanie klienta. 2. Opublikuj dedykowany poradnik konfiguracji aplikacji OIN firmy Harness w dokumentacji firmy Harness, w tym wymagania dotyczące odpowiedzi\ (ACS\) URL. 3. Dodaj niezależny wstępny krok weryfikacji w stosunku do istniejących konfiguracji klienta dla każdej przyszłej aktualizacji do opublikowanej aplikacji Okta, obok własnego przeglądu Okta. 4. Migracja uwierzytelniania użytkownika do ID Harness, co całkowicie usuwa zależność od tego zachowania walidacyjnego.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 29 września 2026 20:31 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 29 września 2026 20:31 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 29 września 2026 20:57 UTCidentified

   Zidentyfikowaliśmy problem, który dotyczy tylko logowania inicjowanego przez SP- za pośrednictwem opublikowanej aplikacji Harness Okta. Po ostatniej aktualizacji do tej aplikacji, próby logowania zwróciły błąd HTTP 400, gdy skonfigurowany URL SSO był brakujący z dodatkowych adresów ACS. Konfiguracje ogólne SAML 2.0 w Okcie nie ulegają zmianie. Rozwiązania natychmiastowe: Użyj logowania inicjowanego przez IDP. Uruchom logowanie z płytki aplikacji Harness w Okcie. Lub Dodaj swój URL SSO do dodatkowych adresów ACS w opublikowanej aplikacji Okta Harness.

4. 2 października 2026 00:33 UTCresolved

   Ten incydent został rozwiązany.

5. 7 października 2026 18:30 UTCpostmortem

   1. Podsumowanie Począwszy od 29 września 2026 roku, klienci, którzy podpisali się w Harness poprzez opublikowaną aplikację Harness w sieci integracji Okta\ (OIN\), nie byli w stanie zakończyć logowania SSO inicjowanego przez SP-. Dotknięci użytkownicy otrzymali błąd HTTP 400 od Okta zamiast być wpisani. Kwestia ta została wprowadzona poprzez zmianę sposobu, w jaki Okta zatwierdziła żądaną odpowiedź\ (ACS\) URL dla istniejących instalacji opublikowanej aplikacji Harness. Zagrożenia zostały opublikowane w ciągu godziny od pierwszego raportu, a każdy poszkodowany klient został odblokowany. # 2. Uderzenie Uzasadnienie * Impact był ograniczony do klientów przy użyciu opublikowanej aplikacji Harness z Okta Integration Network dla SP- inicjowane logowanie\ (początek sign-in z Harness\). Próby te zwróciły błąd HTTP 400 z Okty. * IdP- inicjowane logowanie, rozpoczęte z płytki Harness w Okta, nadal działa przez cały. * Klienci stosujący własną konfigurację aplikacji SAML 2.0 w Okcie nie byli narażeni. * Dane klientów nie zostały utracone ani ujawnione. # 3. Root Cause 29 września 2026 roku zaktualizowana wersja aplikacji Harness została opublikowana w sieci integracji Okta. Aktualizacja dodała wsparcie dla rejestracji wielu adresów URL odpowiedzi\ (ACS\), tak aby klienci prowadzący firmę Harness w kilku regionach lub środowiskach mogli skonfigurować więcej niż jeden adres URL. Uprząż zawiera wartość AssertionConsumerServiceURL w żądaniu uwierzytelniania SAML wysłanym do Okty. Przed tą aktualizacją, Okta nie potwierdził tej wartości dla instancji aplikacji, które nie miały dodatkowych skonfigurowanych adresów ACS i po prostu zwrócił asercję SAML do domyślnego adresu ACS aplikacji. Po aktualizacji walidacja ta stała się aktywna we wszystkich istniejących instancjach aplikacji, w tym tych, w których klient nigdy nie skonfigurował dodatkowego adresu ACS. Ponieważ żądana wartość nie była obecna w zarejestrowanej liście instancji, Okta odrzuciła żądanie uwierzytelniania przy pomocy błędu HTTP 400. Zaktualizowana aplikacja przeszła przez standardowy przegląd publikacji OIN, który obejmuje weryfikację kompatybilności wstecznej z istniejącymi instalacjami opublikowanej integracji. Ta zmiana w zachowaniu walidacji dla przypadków bez dodatkowych skonfigurowanych adresów ACS nie została ujawniona podczas tej recenzji, więc dotarła do klientów przy wydaniu. # 4. Regeneracja * * Natychmiastowa odpowiedź * * Na stronie statusu opublikowano dwa zestawy robocze: zaloguj się z płytki Harness w Okta\ (IdP- inicjowane logowanie\), która nie została naruszona; lub zarejestruj URL Okta SSO aplikacji w polu Dodatkowe ACS URL aplikacji Harness Okta. Wsparcie dotyczyło każdego dotkniętego klienta bezpośrednio i zatwierdzone sign-in z nimi. Uzasadnienie * * Resolution * * Powracając aplikację z powrotem do poprzedniej wersji, celowo uniknięto, ponieważ to tylko odroczyłoby te same zakłócenia do następnego wydania. Każdy poszkodowany klient został odblokowany poprzez rejestrację ACS URL, a my pracujemy z Oktą, aby ponownie uzależnić walidację ACS URL, tak aby przypadki bez dodatkowych skonfigurowanych ACS URL zachowywały się dokładnie tak, jak wcześniej i nie wymaga się żadnych działań klienta. # 5. Pozycje akcji Aby zapobiec powtórzeniu się takich problemów, pracujemy nad: 124; * * Pozycja działania * * 124; - PROCES124; Praca z Oktą w celu przywrócenia warunkowego walidacji ACS URL, więc przypadki bez dodatkowych skonfigurowanych adresów ACS zachowują się dokładnie tak jak wcześniej i nie jest wymagane działanie klienta. VIId; PROJEKT 124; Opublikować dedykowany przewodnik konfiguracji aplikacji OIN Harness w dokumentacji Harness, w tym wymagania odpowiedzi\ (ACS\) URL. DODATKOWE 124; Dodać niezależny etap weryfikacji wstępnego wydania w stosunku do istniejących konfiguracji klienta dla każdej przyszłej aktualizacji do opublikowanej aplikacji Okta, obok własnego przeglądu Okta. PROJEKT 124; Zmigrować uwierzytelnianie użytkownika do ID Harness, co całkowicie usuwa zależność od tego zachowania walidacyjnego. VIId

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 29 września 2026 18:45 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 29 września 2026 21:55 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

3. 29 września 2026 22:01 UTCresolved

   Ten incydent został rozwiązany.

4. 2 października 2026 22:40 UTCpostmortem

   Podsumowanie Od około * * 11: 37 do 3: 01 PM PDT\ (18: 37- 22: 01 UTC\) w dniu 29 września 2026 * * klienci korzystający z Harness CI samodzielnie hostowali Linuksa w * * prod1 / prod2\ (us- west1\) * * doświadczyli przerywanych awarii sieciowych podczas wykonywania rurociągu - głównie Git / timeout podczas pobierania kodu źródłowego. * * Root Cause * * Wynika to przede wszystkim z nasycenia naszego NAT, które zostało dodatkowo zaostrzone przez tymczasowego operatora chmur obliczeniowych pojemności, zapobiegając nowych rezerw VM tam. # # Impact * Klienci prowadzący samodzielnie hostowane Linux CI buduje w nas -west1 piła * * przerywany build / gazociągów awarii * *, nie pełne przestoju. * Obserwowane błędy w obsłudze klienta obejmują Git fetch timeout, np. 'Nie powiodło się podłączenie do portu github.com 443: Połączenie w czasie " * * Regeneracja * * * * * Natychmiastowe: * * Zbalansowany ładunek ARM build- VM z nasyconej ścieżki użytkownika - west1 w kierunku centralnego1\ (częściowo ograniczony przez centralny1 pojemność\); ponownie uruchomiony dotknięte bramki Cloud NAT, które ustabilizowały sieć rurociągów. * * Action Elements * * 1. Zabezpieczenie dodatkowej bramy NAT / pojemności IP\ (w toku\) 2. Poprawa wykrywania nasycenia NAT i ostrzeganie przed wpływem na klienta. 3. Oszacować możliwości międzyregionalne, aby jeden region nie blokował niewystarczającego obliczenia.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 29 września 2026 14:41 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 29 września 2026 15:54 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

3. 29 września 2026 15:57 UTCmonitoring

   Nadal monitorujemy wszelkie dalsze problemy.

4. 29 września 2026 18:49 UTCresolved

   Ten incydent został rozwiązany.

5. 2 października 2026 05:37 UTCpostmortem

   / Podsumowanie Klienci na Prod-2 odnotowali podwyższone wskaźniki awarii w gazociągach ciągłych weryfikacji. Roboty weryfikacyjne nie zakończyły się lub nie zgłosiły błędów, ponieważ pracownicy zajmujący się zbieraniem danych CV nie mogli komunikować się z usługą platformy koordynującą ich pracę. Było to spowodowane nieoczekiwanym skokiem ruchu jednego z naszych systemów. Usługa została przywrócona poprzez skalowanie dotkniętego komponentu platformy. Nie doszło do utraty danych ani korupcji. Uzasadnienie * * Uderzenie klienta * * Klienci stosujący Continuous Weryfikacja na Prod-2 widzieli awarię lub przerwa w pracy rurociągu podczas okna zdarzenia. Znaczna część przypadków pracy weryfikacyjnej, która miała miejsce w tym okresie, zakończyła się niepowodzeniem operacyjnym. Rury niewykorzystujące CV nadal funkcjonowały normalnie. Uzasadnienie * * Root Cause * * Duży zautomatyzowany proces tworzenia rezerw stworzył znaczną liczbę stałych pracowników monitorujących CV w krótkim czasie, co przytłoczyło wspólny komponent platformy. Nagłe zwiększenie liczby równoległych połączeń wychodzących wyczerpało dostępne połączenia sieciowe w każdym przypadku usługi. Uzasadnienie * * Litigation * * Podniesiono maksymalny limit skalowania dla usługi CV, pozwalając jej na zwiększenie zdolności produkcyjnych w celu zaspokojenia popytu. Wypadki ustały krótko po zakończeniu skalowania. Uzasadnienie * * Next Steps * * Aby zapobiec nawrotom, Harness będzie: * * * Zwiększ pojemność i dodaj zabezpieczenie: * * Podnieść limit skalowania usług CV w celu utrzymania zagłówka pod obciążeniem rozrywającym i wprowadzić ograniczenie stawki dla masowej dostawy monitorowanych usług. * * * Poprawa odporności: * * Dodać wykładniczy backuff i jitter dla pracownik retries, i używać wielokrotnego użytku pula połączeń w celu zmniejszenia napowietrznych i zapobiec przemijające awarie z łączenia się pod wysokim konkursem. * * * Poprawa monitorowania i ostrzegania: * * Wzmacnianie ostrzegania o nienormalnych wskaźnikach wzrostu liczby pracowników zatrudnionych na rachunku bieżącym, tak więc podobne warunki są wykrywane i reagują na wcześniej.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 29 września 2026 13:12 UTCresolved

   28 września 2026 roku zaobserwowaliśmy problem z kopiowaniem plików z pliku Harness podczas etapu eksportu, gdzie pliki były kopiowane jako puste / puste pliki. W rezultacie wszystkie rurociągi wykorzystujące API Filestore zostały zablokowane w czasie zdarzenia. Problem został spowodowany przez fabułę Flagi, która została odwrócona po odkryciu problemu. Wszystkie operacje wróciły do normy.

2. 1 października 2026 17:28 UTCpostmortem

   Podsumowanie W dniu 28 września 2026 r. niektórzy klienci na Prod-2 doświadczyli awarii w krokach rurociągu CD, które czytają zawartość sklepu z plikami przy użyciu wyrażeń rurociągu\ (np. '\). Związane wyrażenia zwróciły null zamiast oczekiwanej zawartości pliku, powodując, że zależne kroki zawodzą lub zachowują się nieprawidłowo. Problem został wyśledzony do aktualizacji platformy, która zaostrzyła kontrole autoryzacji API sklepu plików. Aktualizacja została cofnięta, a wyrażenia File Store działają normalnie od tego czasu. # # # Uderzenie klienta * Tylko kroki rurociągu na Prod-2, które czytają zawartość File Store za pomocą wyrażeń zostały naruszone. Rurociągi, które nie korzystają z wyrażeń File Store, nie miały wpływu. * Związane wyrażenia zostały usunięte do zeru, co powoduje, że kroki, które zależą od konfiguracji lub ustawień plików, nie powiodą się lub nie wytworzą nieprawidłowego wyjścia. * Nie zmodyfikowano zawartości sklepu plików. Nie ujawniono żadnych akt, tajemnic, dokumentów ani artefaktów, ani też nie utracono żadnych danych. # # Root Cause W ramach trwającej inicjatywy w zakresie bezpieczeństwa firma Harness wprowadziła bardziej rygorystyczne kontrole autoryzacji na kilku platformach API, w tym API obsługujące zawartość File Store. Kiedy rurociąg ocenia wyrażenie ze sklepu plików, jedna wewnętrzna usługa Uprząż wzywa inną do pobrania pliku. Nowe kontrole autoryzacyjne nie powiodły się, w wyniku czego wnioski zostały odrzucone, a wyrażenia zwrócone zerowe. - Łagodzenie Gdy aktualizacja platformy została zidentyfikowana jako przyczyna, została cofnięta przez środowisko produkcyjne. Wyrażenia File Store zostały poprawnie rozwiązane od momentu cofnięcia. Nie jest wymagane działanie klienta. # # # Środki zapobiegawcze i kolejne kroki * * * API dotknięte audytem: * * Przegląd wszystkich API, w których zastosowano bardziej rygorystyczne kontrole autoryzacji w celu zapewnienia prawidłowego rozliczania połączeń z usługami wewnętrznymi. * * * Poprawa pokrycia testowego: * * Wzmocnienie zautomatyzowanych zestawów testowych w celu uwzględnienia oceny ekspresji File Store między ścieżkami realizacji rurociągu

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 23 września 2026 20:17 UTCinvestigating

   Obecnie badamy kwestie łączności wpływające na klientów, których środowisko jest chronione przez zapory Palo Alto Networks. Te zapory blokują połączenia z API Harness, co może skutkować: - Nieudane egzekucje rurociągów - Niemożność rozmieszczenia aplikacji - Przerwa w czasie dostępu do funkcji platformy Harness - Niepowodzenie integracji z narzędziami trzeciej partii - Delegować łączność z platformą Harness Problem ten nie jest spowodowany przerwami w obsłudze firmy Harness, ale raczej zasadami firewalla po stronie sieci. Doradzamy klientom zrobić wyjątek dla naszych punktów końcowych DNS.

2. 24 września 2026 08:43 UTCmonitoring

   Dostępne ograniczenia: Ruch uprzęży zablokowany przez politykę bezpieczeństwa sieci Zidentyfikowaliśmy problem, w którym niektórzy klienci mogą nie być w stanie uzyskać dostępu do Harness, ponieważ ruch Harness jest klasyfikowany jako "platforma AI-" przez kontrolę bezpieczeństwa sieci Palo Alto, a następnie zablokowany przez klienta firewall / INET polityki. Jeśli doświadczasz tego problemu: Proszę skontaktować się z zespołem sieciowym / Firewall / CyberSecurity i poprosić, aby wymagany ruch Uprzęży był dozwolony poprzez politykę zapory Palo Alto. Jako środek łagodzący, klienci mogą zezwolić na kategorię "AI- Platform" URL dla wymaganych punktów końcowych Harness, lub dodać dotknięte domeny Harness / FQDN do zatwierdzonej / dopuszczalnej listy organizacji, zgodnie z ich polityką bezpieczeństwa. Po aktualizacji polityki firewall, należy przywrócić dostęp do Harness. Ważne: Polityka firewall jest zarządzana przez sieć / zespół bezpieczeństwa klienta. Jeśli punkt końcowy Harness jest nieprawidłowo sklasyfikowany przez Palo Alto, klienci mogą również poprosić o przegląd kategorii URL z Palo Alto Networks.

3. 25 września 2026 17:10 UTCresolved

   Po konsultacji z Palo Alto Networks możemy potwierdzić, że 23 września 2026 r. Io został sklasyfikowany przez zespół Palo Alto Networks jako platforma AI. W sierpniu Palo Alto Networks przesłało klientom zawiadomienie o zmianie klasyfikacji. Zmiana ta może objąć usługę platformy AI inną polityką niż app. Harness. Poprzednie zasady Io kategoryzacji, Komputer i Internet Info. Stosowana polityka zależy od ustawień klienta. Klienci Harness powinni przedyskutować tę kategoryzację i wpisy z ich wewnętrznym zespołem sieciowym i Palo Alto Networks.

4. 13 października 2026 04:50 UTCpostmortem

   .

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 22 września 2026 16:40 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 22 września 2026 17:14 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 22 września 2026 18:01 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

4. 22 września 2026 18:38 UTCresolved

   Ten incydent został rozwiązany.

5. 2 października 2026 22:05 UTCpostmortem

   # Streszczenie 22 września 2026 roku trzy z naszych bram sieciowych w jednym regionie stały się niezdrowe i zaczęły odrzucać niewielki procent nowych prób połączenia. Kwestia ta została rozwiązana tego samego dnia problem całkowicie bez dalszego nawrotu lub następstw na wpływ. Podstawową przyczyną był nasycony wewnętrzny bufor monitorowania handlu na tych bramach, co spowodowało, że ich kontrole zdrowotne reagowały zbyt wolno i zostały oznaczone niezdrowe. # Impact * Tylko trzy punkty bramki w jednym regionie zostały naruszone; inne regiony i inne bramy w tym samym regionie nie zostały naruszone. * Nie było awarii kaskadowej, problem został w pełni rozwiązany z jednej rundy bramki ponownie uruchamia, a następnie nie było następstw - w kwestiach. # Root Cause Nasze wychodzące bramki sieciowe prowadzą wewnętrzny komponent, który monitoruje ruch sieciowy dla widoczności operacyjnej. Pod stałym wysokim natężeniem ruchu, wewnętrzny bufor tego komponentu stał się nasycony, co spowodowało, że ciśnienie wsteczne na tyle poważne, aby spowolnić własne odpowiedzi bramki zdrowia - sprawdzić poza czas nasz balancer obciążenia pozwala. Po przekroczeniu tego czasu, balancer obciążenia oznaczył uszkodzone bramy niezdrowe i zaczął odrzucać część nowych połączeń przeznaczonych dla nich. Faktyczne przesyłanie pakietów nadal działało normalnie przez cały incydent. Był to szczególnie problem zdrowia - sprawdzanie i monitorowanie - bufora, a nie awaria podstawowych funkcji przekazywania bramek. # Resolution Trzy dotknięte przypadki bramki zostały ręcznie uruchomione ponownie, które oczyściły nasycony bufora monitorowania i natychmiast przywrócić normalne zachowanie kontroli zdrowia. Odrzucenie połączenia ustało zaraz po zakończeniu restartu i nie było potrzeby dalszych interwencji. # Działania zapobiegawcze 124; * * Działanie * * 124; - 124; Zastąpić obecne podejście do monitorowania handlu na wszystkich bramkach bardziej efektywnym, bardziej ogólnym wdrażaniem, które nie może być nasycone w ten sposób i które ostrzega znacznie przed jakimkolwiek widocznym dla użytkownika wpływem. Wdrożenie automatycznego, okresowego zastępowania długotrwałych instancji bramek w ustalonym harmonogramie, więc żadna instancja nie może gromadzić rodzaju degradacji związanej z wiekiem obserwowanej w tym incydencie. VIId; PROGRAM 124; Migracja instancji bramki do zoptymalizowanej infrastruktury sieciowej o znacznie bardziej dedykowanej przepustowości sieci, lepiej przystosowany do trwałego ruchu o dużej przepustowości. PROJEKT 124; Zwiększyć wykorzystanie istniejącego bufora monitorującego, podczas gdy dłuższe zastępowanie jest toczone. 124; Wzmocnienie ostrzeganie szczególnie na bramce zdrowia - sprawdzanie latencji reakcji, złapać wczesne oznaki degradacji, zanim stanie się widoczne dla użytkownika. VIId

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 22 września 2026 14:00 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

2. 22 września 2026 14:08 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

3. 22 września 2026 14:20 UTCresolved

   Ten incydent został rozwiązany.

4. 2 października 2026 22:10 UTCpostmortem

   Tak samo jak poprzednia przyczyna.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 21 września 2026 16:39 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 21 września 2026 17:12 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 21 września 2026 18:27 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

4. 21 września 2026 18:33 UTCresolved

   Ten incydent został rozwiązany.

5. 29 września 2026 22:39 UTCpostmortem

   Podsumowanie W dniu 21 września 2026 r. klienci w Prod 2 doświadczyli degradacji, a następnie w dużej mierze niedostępności desek rozdzielczych rozmieszczenia przez około trzy godziny. Problem ten został spowodowany przez zestaw zapytań analitycznych za tymi tablicami rozdzielczymi czytając znacznie więcej danych niż potrzebowali, które wyczerpały możliwości bazy danych obsługującej je. Ponowne uruchomienie dotkniętej usługi przywrócone deski rozdzielcze w pełni, a platforma jest stabilny od. # # Uderzenie klienta Strony deski rozdzielczej załadowane powoli lub w czasie między 14: 48 a 18: 11 UTC. Pipeline realizacji i wdrożenia prowadzenia rejestracji oddzielnej infrastruktury i nadal działać normalnie. Nie doszło do utraty danych ani korupcji. # # Root Cause # Zapytania na desce rozdzielczej brakowało filtra time- range w kolumnie używanej do podziału największej tabeli na segmenty tygodniowe, więc każde zapytanie odczytywało wszystkie dane historyczne zamiast tylko okres, którego dotyczy wniosek. Poprawność nigdy nie została naruszona - deski rozdzielcze zwróciły właściwe wyniki; tylko ilość danych odczytanych do ich produkcji była nadmierna. Wraz ze wzrostem wolumenu danych koszty tych odczytów przekroczyły to, co baza danych może służyć, a powtórne próby niepowodzących zapytań dodały dalszego obciążenia, tak więc warunek nie został wyjaśniony do czasu wznowienia usługi. # # Łagodzenie * Wykonał toczący się restart dotkniętej usługi, która zatrzymała cykl ponownego testowania i pozwoliła bazy danych zakończyć swoje wybitne prace * Potwierdzone latencja deski rozdzielczej i korzystanie z podłączenia do bazy danych powróciło do normalnego poziomu # # Następne kroki Aby zapobiec nawrotom, Harness będzie: * Dodaj brakujący filtr zakresu czasu do dotkniętych zapytań deski rozdzielczej, więc każdy czyta tylko żądany okres * Zastąp natychmiastowe powtórzenia ograniczonymi, cofającymi się powtórzeniami * Poprawa wykrywania poprzez dodanie alerting na korzystanie z połączenia z bazą danych i koszt wykonania per- query

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.