Historia awarii Knowbe4

1. 20 października 2026 11:37 UTCidentified

   Zidentyfikowaliśmy przyczynę rejestracji domeny, która nie jest w stanie udzielić porad i pracujemy nad wdrożeniem rozwiązania. Będziemy nadal publikować na naszej stronie statusu wszelkie nowe informacje lub aktualizacje.

2. 21 października 2026 15:33 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

3. 23 października 2026 14:55 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 13 października 2026 15:03 UTCinvestigating

   Obecnie badamy problem wpływający na logowanie konsoli. Dostarczymy więcej aktualizacji tutaj, gdy będzie dostępna.

2. 13 października 2026 15:07 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

3. 13 października 2026 16:15 UTCresolved

   Ten incydent został rozwiązany.

4. 14 października 2026 14:29 UTCpostmortem

   / Podsumowanie W dniu 13 października 2026 r., od około 14: 19 do 15: 05\ (UTC\), klienci we wszystkich regionach nie byli w stanie zalogować się do konsoli KnowBe4 Security Awareness Training\ (SAT\), KnowBe4 Learner Experience oraz do konsoli PhishER poprzez KnowBe4 SAT. SAML i logi hasła zwróciły błędy, a konsola KnowBe4 SAT nie pojawiła się na platformie KnowBe4. Niektóre procesy w tle, w tym synchronizacja użytkownika i e-maile szkoleniowe, również nie powiodły się w tym czasie. Incydent został spowodowany przez wydanie produkcji, które kolidowało z kolejną zmianą naszego kodu. Odwróciliśmy uwolnienie, a loginy odzyskano w regionach między 14: 59 a 15: 05\ (UTC\). W wyniku tej kwestii nie doszło do utraty danych. * * * Root Cause * * Wprowadzanie kodu usunęło wartość konfiguracji startowej, aby przyspieszyć czas uruchamiania aplikacji. Oddzielny komponent, dodany do naszego kodu po testowaniu pierwotnej zmiany, nie uwzględnił tej zmienionej wartości. W rezultacie każda próba zapisania rekordu użytkownika spowodowała błąd, w tym aktualizację, która zapisuje próby zapisania. * * * Oddziaływanie klienta * * Klienci we wszystkich regionach nie mogli zalogować się do konsoli KSAT poprzez SAML lub hasło. Nie mieli też dostępu do Learner Experience i nie mieli dostępu do konsoli PhishER poprzez konsolę KnowBe4 SAT. Nowe tworzenie użytkowników, synchronizacja użytkowników i e-maile treningowe nie powiodły się w tym czasie, ale zostały automatycznie ponownie wypróbowane po ponownym uruchomieniu. * * * Litigation and Remediation * * Odkryliśmy, że rozmieszczenie usunęło wartość konfiguracji, której nadal potrzebuje inny komponent. Zostało to złagodzone poprzez cofnięcie wydania i potwierdziliśmy poprawę we wszystkich regionach poprzez bezpośrednie kontrole i automatyczne testy. Odwróciliśmy również pierwotną zmianę kodu źródłowego i przygotowaliśmy poprawioną wersję, która zawiera korektę kompatybilności, dzięki czemu oryginalna poprawa może zostać bezpiecznie przywrócona. * * * Prewencyjne środki * * Dodajemy dodatkowe weryfikacje kodów i badania na potrzeby rozmieszczenia.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 13 października 2026 08:47 UTCinvestigating

   Otrzymaliśmy raporty, że add- in KnowBe4 e-mail bezpieczeństwa pokazuje błąd "Add- in KnowBe4 e-mail bezpieczeństwa zapobiega wysyłaniu tej wiadomości" podczas wysyłania e-maili. Badamy tę kwestię i uaktualnimy tę stronę, gdy będziemy mieć więcej informacji.

2. 13 października 2026 11:07 UTCmonitoring

   Zaimplementowaliśmy rozwiązanie dla Web Add- w wysyłaniu błędów i monitorujemy wyniki, aby upewnić się, że nie pojawią się dalsze problemy.

3. 13 października 2026 13:41 UTCresolved

   Ten incydent został rozwiązany.

4. 20 października 2026 12:48 UTCpostmortem

   Od poniedziałku, 12 października 2026 r., około 14: 25\ (UTC\), do wtorku, 13 października 2026 r., około 15: 07\ (UTC\), niektórzy klienci w UE mieli trudności z wysyłaniem e-maili z Microsoft Outlook. Dotknięte wiadomości nie zostały wysłane, a add- w dodatku KnowBe4 Email Security wyświetlono następujący błąd: "Add- in KnowBe4 Email Security uniemożliwia wysłanie tej wiadomości". Kwestia ta została spowodowana błędem w przygotowaniu wersji add- in do wydania, która stworzyła dwie nieco różne wersje tej samej wersji. Kiedy Outlook ładuje add- in, pobiera zestaw plików, które muszą pasować. W przypadkach UE Outlook czasem otrzymywał pliki z obu kopii, więc add- in nie mógł zakończyć ładowania, a wiadomość nie została wysłana. Niektóre urządzenia również zapisały nieudany pobór, więc błąd trwał na tych urządzeniach do momentu zastosowania poprawki. Aby rozwiązać ten problem, nasz zespół skorygował plik dodanyw UE, tak aby każdy klient otrzymał zestaw pasujący. Następnie opublikowaliśmy zaktualizowaną wersję add- in do wszystkich regionów, które usunęły wszystkie zapisane błędy. KnowBe4 Email Security add- in powrócił do normalnej wydajności około 15: 07\ (UTC\) 13 października 2026. Aby zapobiec tego typu kwestii w przyszłości, zmieniamy sposób, w jaki add- in wersje są przygotowywane i publikowane, tak, że każda wersja zawsze produkuje ten sam zestaw plików i każdy klient otrzymuje tę samą wersję w tym samym czasie. Zmieniamy również add- in tak, że nieudany pobieranie plików add- w nie są zapisywane na urządzeniach. Na koniec dodamy ostrzeżenia o błędach w załadowaniu, aby wykryć je wcześniej. W wyniku tej kwestii nie doszło do utraty danych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 28 września 2026 21:10 UTCinvestigating

   Obecnie badamy problem degradacji wydajności dla Prevent and Protect na naszych amerykańskich serwerach.

2. 29 września 2026 13:44 UTCmonitoring

   Zidentyfikowaliśmy problem z amerykańskimi instancjami Prewencji i Ochrony, który doprowadził do pogorszenia wydajności. Wprowadzono rozwiązanie i będziemy nadal monitorować tę kwestię.

3. 2 października 2026 10:32 UTCresolved

   Ten incydent został rozwiązany.

4. 6 października 2026 15:51 UTCpostmortem

   / Podsumowanie Od poniedziałku, 28 września 2026 roku, około 16: 00\ (UTC\), do środy, 30 września 2026 roku, około 12: 35\ (UTC\), niektórzy klienci doświadczyli opóźnionego przepływu poczty i przerywanych problemów dostępu do amerykańskich instancji Prewencji i Ochrony. 28 września nasze monitorowanie wykazało duży ruch sieciowy, z kolcami w górnej części każdej godziny. Niektórzy klienci zaczęli doświadczać przerywanych problemów z dostępem do amerykańskich instancji konsoli Prevent and Protect. Wewnętrzne przeglądy, że przetwarzanie poczty zależy od rozpoczęcia czasu, a wiadomości były w kolejce w wyniku. Klienci zgłosili to do naszego zespołu wsparcia, a my zamieściliśmy ogłoszenie o statusie. Wyniki odzyskano później tego dnia, gdy zmniejszył się ruch w USA. 29 września nasi inżynierowie dokonali przeglądu danych z poprzedniego dnia poprzez bramy pocztowe, usługi wewnętrzne, od których zależą, oraz warstwę sieciową. Opóźnienia w przepływie poczty i problemy z dostępem do konsoli powróciły krótko, a następnie ustąpiły wraz z zmniejszeniem ruchu sieciowego, zgodnie z tym samym wzorem co 28 września. 30 września, z około 12: 19 do 12: 35\ (UTC\), nasz zespół zwiększył przepustowość amerykańskich usług sieciowych, podczas gdy usługa była kontynuowana. Ich obciążenie spadło natychmiast po zmianie, a zapobieganie i ochrona powróciły do normalnej wydajności około 12: 35\ (UTC\) 30 września 2026. Monitorowaliśmy ruch w godzinach szczytu od 30 września do 1 października i nie widzieliśmy nawrotów. W wyniku tej kwestii nie doszło do utraty danych. * * * Root Cause * * Kwestia ta została spowodowana ograniczeniem przepustowości usług sieciowych, które obsługują ruch dla naszych amerykańskich usług przetwarzania poczty. Podczas szczytu ruchu, a zwłaszcza podczas godzinowych skoków, usługi sieciowe nie mogły przetwarzać połączeń wystarczająco szybko. To dodało opóźnienia w ruchu przechodzącym przez nie i spowodowało pewne połączenia do spadku. Ten ruch zawierał wewnętrzne żądania naszych bram pocztowych wysłać, aby sprawdzić członków listy dystrybucyjnej, więc odpowiednie polityki są stosowane. Żądania te podlegają ścisłemu limitowi czasowemu, tak że powolne przeglądanie nie może wstrzymać przetwarzania poczty na czas nieokreślony. Gdy usługi sieciowe opóźniły wnioski powyżej tego limitu, nie powiodły się. W rezultacie przetwarzanie poczty zwolniło, a wiadomości były w kolejce. Dwa czynniki utrudniły rozpoznanie problemu. Po pierwsze, niektóre wnioski wewnętrzne wykorzystały również te usługi sieciowe i zostały dotknięte limitem przepustowości. Po drugie, usługi sieciowe zaczęły się pogarszać, zanim ich obliczenia osiągnęły poziomy, które normalnie sygnalizowałyby problem. Standardowy monitoring nie wykrył nasycenia sieci, więc przyczyna była dłuższa. Znalezienie bezpiecznego sposobu na zwiększenie przepustowości bez przerywania obsługi również wymagało czasu, dlatego rozwiązanie zostało zastosowane 30 września. * * * Litigation and Remediation * * Dowiedzieliśmy się, że amerykańskie służby sieciowe nie miały wystarczającej pojemności, by poradzić sobie z szczytowym ruchem. Ograniczyliśmy to poprzez zwiększenie ich zdolności w sposób, który utrzymywał obsługę przez cały okres zmian. Po zwiększeniu przepustowości usługi sieciowe obsługiwały ruch szczytowy bez dalszych problemów. Odkryliśmy również, że samo obliczanie nie jest wiarygodnym znakiem nasycenia sieci. Rozszerzyliśmy nasze monitorowanie, aby śledzić wskaźniki zdrowia sieci, oprócz obliczania wykorzystania. Wreszcie okazało się, że trudno było znaleźć miejsce, w którym upadły wewnętrzne wnioski. Dodaliśmy logowanie, które pokazuje gdzie wewnętrzne żądania zawodzą i czas. * * * Oddziaływanie klienta * * Podczas szczytu ruchu w Stanach Zjednoczonych w dniach 28 i 29 września niektórzy klienci doświadczyli opóźnień w przetwarzaniu i dostarczaniu poczty przychodzącej i wychodzącej poprzez Prevent and Protect. Wiadomości adresowane do list dystrybucyjnych mogły być przetwarzane wolniej, podczas ponownego sprawdzania. Niektórzy klienci mieli również przerywane trudności z zalogowaniem się do konsoli amerykańskiej lub z jej wykorzystaniem. Wpływ zmniejszył się każdego dnia w miarę zmniejszania się ruchu w USA, a kolejka pocztowa była przetwarzana po odzyskaniu zdolności przewozowej. Po zmianie 30 września nie widzieliśmy dalszej degradacji podczas ruchu szczytowego. * * * Prewencyjne środki * * Aby zapobiec tego typu problemom w przyszłości, zwiększyliśmy przepustowość amerykańskich usług sieciowych i rozszerzyliśmy nasze monitorowanie, aby śledzić wskaźniki zdrowia sieci, oprócz obliczania wykorzystania. Dodaliśmy też logowanie, aby poprawić widoczność do nieudanych żądań wewnętrznych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 24 września 2026 17:53 UTCinvestigating

   Zidentyfikowaliśmy problem z Protect, który doprowadził do degradacji wydajności, a nasz zespół inżynieryjny szuka rozwiązania.

2. 24 września 2026 18:39 UTCmonitoring

   Zidentyfikowaliśmy problem z Protect, który doprowadził do degradacji wydajności. Wprowadzono rozwiązanie i będziemy nadal monitorować tę kwestię.

3. 24 września 2026 19:57 UTCinvestigating

   Zidentyfikowaliśmy problem z Protect & Prevent, który doprowadził do degradacji wydajności, a nasz zespół inżynieryjny szuka rozwiązania.

4. 24 września 2026 21:46 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

5. 25 września 2026 09:16 UTCresolved

   Ten incydent został rozwiązany.

6. 6 października 2026 15:51 UTCpostmortem

   / Podsumowanie Od czwartku, 24 września 2026, około 17: 07\ (UTC\), do piątku, 25 września 2026, około 09: 16\ (UTC\), niektórzy klienci doświadczyli przerywanej powolności, błędów i opóźnionego przepływu poczty dla amerykańskich instancji Ochrony i Zapobiegania. W dniu 24 września niezwykle duży wzrost ruchu pocztowego umieścił trwałe obciążenie na usługach sieciowych, które obsługują ruch dla naszego amerykańskiego przetwarzania poczty. Monitoring powiadomił nas o 17: 07\ (UTC\). Niektórzy klienci widzieli powolny lub przerywany dostęp do Protect i sporadyczne błędy podczas wczytywania stron lub zaawansowanych opcji. Dostęp był niespójny, więc niektórzy klienci mogli korzystać z Protect podczas gdy inni widzieli błędy. Przetwarzanie poczty za pośrednictwem amerykańskich instancji zwolniło, a niektóre wiadomości były opóźnione lub nie pojawiały się w skrzynce odbiorczej moderowania, gdy oczekiwano. Wydajność wydawała się poprawiać, więc przesunęliśmy nasze powiadomienie o stanie do monitorowania o 18: 39\ (UTC\). Problem później się powtórzył, a klienci zgłosili ciągłą powolność do naszego zespołu wsparcia. O 19: 57\ (UTC\), przenieśliśmy zawiadomienie z powrotem do badania i rozszerzyliśmy go również do Prevent jak wpływ stał się jaśniejszy. Nasz zespół monitorował uszkodzone systemy, podczas gdy zwiększona ilość poczty spadła. Ponieważ obciążenie usług sieciowych wróciło do normy, odzyskano przetwarzanie poczty, a kolejki pocztowe wróciły do normy z dnia na dzień. Potwierdziliśmy, że Protect ładuje normalnie i że wiadomości testowe są dostarczane ponownie, a następnie kontynuujemy monitorowanie. 25 września 2026 r. ochrona i zapobieganie powróciło do normalnej wydajności ok. 09: 16\ (UTC\). W wyniku tej kwestii nie doszło do utraty danych. * * * Root Cause * * Problem ten został spowodowany przez niezwykle duży wzrost ruchu poczty elektronicznej. Zwiększony wolumen umieścił trwałe obciążenie na usługach sieciowych, które obsługują ruch dla naszego amerykańskiego przetwarzania poczty. Te usługi sieciowe działają w granicach stałej przepustowości, a ich przepustowość nie może być zwiększona podczas skoku. Ponieważ nie mogli nadążyć za gwałtownym wzrostem, zwolnili, a niektóre procesy nie powiodły się z przerwami. W rezultacie duża ilość poczty została ustawiona w kolejce do przetwarzania poczty w USA, niektóre strony i działania w Protect zwróciły błędy, a niektóre wiadomości zostały opóźnione lub nie pojawiły się w skrzynce moderacyjnej, gdy oczekiwano. Dwa czynniki utrudniły zarządzanie tą kwestią. Po pierwsze, ponieważ dostęp nie powiódł się w sposób przerywany, niektóre kontrole odniosły sukces, podczas gdy klienci nadal dostrzegali błędy, co utrudniło ich odzyskanie. Po drugie, nasze monitorowanie wykazało obciążenie szczytowe usług sieciowych bardziej wyraźnie niż obecne obciążenie, co utrudniło ocenę w czasie rzeczywistym, czy obciążenie było nadal wyższe. * * * Litigation and Remediation * * Ustaliliśmy, że usługi sieciowe obsługujące przetwarzanie poczty amerykańskiej osiągnęły swoje stałe limity zdolności przewozowej podczas skoku ruchu, a ich zdolność przewozowa nie mogła być zwiększona w czasie wydarzenia. Nasz zespół monitorował dotknięte systemy, podczas gdy zwiększony wolumen poczty ustąpił i obciążenie serwisowe sieci wróciło do normy. Przetwarzanie poczty zostało następnie odzyskane, a kolejka była przetwarzana. Ponieważ problem ten wcześniej uległ poprawie przed powtórzeniem, potwierdziliśmy na kilka sposobów powrót do zdrowia przed rozwiązaniem tego incydentu. Potwierdziliśmy, że Protect ładuje normalnie, że wiadomości testowe są dostarczane poprzez amerykańskie przetwarzanie poczty oraz że prośby o wsparcie postępują normalnie. Monitorowaliśmy również z dnia na dzień i nie otrzymaliśmy żadnych nowych raportów od klientów na instancjach amerykańskich. * * * Oddziaływanie klienta * * Niektórzy klienci mieli wolny lub przerywany dostęp do Protect, a czasami zauważyli błędy podczas wczytywania stron lub zaawansowanych opcji. Przetwarzanie poczty za pośrednictwem amerykańskich instancji zostało opóźnione dla Protect and Prevent. W niektórych przypadkach wiadomości były opóźnione lub nie pojawiały się w skrzynce odbiorczej moderacyjnej, gdy były spodziewane. Klienci, których poczta jest zaszyfrowana, odszyfrowywana lub moderowana w miarę jak przechodzi przez nasze amerykańskie przetwarzanie poczty, są bardziej podatni na skutki. Większość klientów Protect za pomocą add- in nie zostały dotknięte przez opóźnienia przetwarzania poczty. Konsole Protect and Prevent pozostawały dostępne, chociaż niektóre działania konsoli zostały dotknięte przez wolniejsze przetwarzanie poczty. * * * Prewencyjne środki * * Aby zapobiec tego typu problemom w przyszłości, udoskonalamy nasze monitorowanie niezwykłego wzrostu głośności poczty elektronicznej. Ulepszamy również nasze monitorowanie, aby pokazać obecne obciążenie naszych usług sieciowych, nie tylko wartości szczytowe. Ponadto, oceniamy sposoby zwiększenia przepustowości naszej sieci dynamicznie podczas nagłego skoków ruchu oraz oceniamy długoterminowe ulepszenia infrastruktury sieciowej obsługującej przetwarzanie poczty amerykańskiej. Od tego czasu zwiększyliśmy również przepustowość amerykańskich usług sieciowych w odpowiedzi na [późniejszy incydent] (https: / / status.knowbe4.com / invents / 9wc6rjm8g70v).

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 23 września 2026 09:52 UTCidentified

   Otrzymaliśmy zgłoszenia użytkowników otrzymujących komunikaty błędów "Access Denied" podczas próby logowania. Zidentyfikowaliśmy tę kwestię i pracujemy nad wdrożeniem rozwiązania i zaktualizujemy tę stronę, kiedy będziemy mieli więcej informacji.

2. 23 września 2026 10:57 UTCmonitoring

   Problem został zidentyfikowany i został wdrożony fix i będzie aktualizować tę stronę, gdy będziemy mieć więcej informacji.

3. 23 września 2026 14:58 UTCresolved

   Ten incydent został pomyślnie rozwiązany i wszystkie systemy są w pełni sprawne.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 23 września 2026 09:00 UTCinvestigating

   Otrzymaliśmy doniesienia, że niektórzy użytkownicy nie są w stanie z powodzeniem złożyć zgłoszenia webform. Badamy tę kwestię i uaktualnimy tę stronę, gdy będziemy mieć więcej informacji.

2. 23 września 2026 10:47 UTCidentified

   Problem został zidentyfikowany i został wdrożony. Aktualizacja zawierająca więcej informacji będzie następować odpowiednio.

3. 23 września 2026 10:58 UTCmonitoring

   Problem został zidentyfikowany i został wdrożony fix i będzie aktualizować tę stronę, gdy będziemy mieć więcej informacji.

4. 23 września 2026 14:58 UTCresolved

   Ten incydent został pomyślnie rozwiązany i wszystkie systemy są w pełni sprawne.

5. 20 października 2026 15:53 UTCpostmortem

   W środę, 23 września 2026 r., od około 08: 15 do 11: 18\ (UTC\), niektórzy klienci doświadczyli spowolnienia i nieudanej składania formularzy w brytyjskich instancjach Secure Webform. Kwestia ta została spowodowana przez ograniczenia wydajności baz danych w brytyjskim środowisku produkcyjnym po ostatniej zmianie. Ustawienie bazy danych spowodowało również nieefektywne działanie niektórych zapytań. W rezultacie czas reakcji się zwiększył, a niektóre formularze nie powiodły. Aby rozwiązać ten problem, nasz zespół tymczasowo wstrzymał zadanie synchronizacji tła, aby zmniejszyć obciążenie, skorygował ustawienia bazy danych, aby poprawić wydajność zapytania i zwiększyć przepustowość pamięci masowej. Bezpieczne formularze internetowe powróciły do normalnej wydajności do 11: 18\ (UTC\). Aby zapobiec tego typu problemom w przyszłości, dodajemy dodatkowe monitorowanie przepustowości bazy danych. Poprawiamy również wydajność zadania synchronizacji tła. W wyniku tej kwestii nie doszło do utraty danych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 21 września 2026 09:32 UTCinvestigating

   Otrzymaliśmy raporty, że użytkownicy nie są w stanie wysyłać e-maili poprzez Internet Access (Secure Message Portal) w regionie Wielkiej Brytanii, z błędem "503 Usługa niedostępna". Badamy tę kwestię i uaktualnimy tę stronę, gdy będziemy mieć więcej informacji.

2. 21 września 2026 14:36 UTCmonitoring

   Wprowadziliśmy naprawę i monitorujemy wyniki.

3. 21 września 2026 14:38 UTCmonitoring

   Nadal monitorujemy wszelkie dalsze problemy.

4. 22 września 2026 08:27 UTCresolved

   Ten incydent został pomyślnie rozwiązany i wszystkie systemy są w pełni sprawne.

5. 8 października 2026 13:45 UTCpostmortem

   W poniedziałek, 21 września 2026, od około 08: 55 do wtorku, 22 września 2026, około 14: 30\ (UTC\), niektórzy użytkownicy doświadczyli błędów i nie mogli wysyłać e-maili przez Internet Access\ (Secure Message Portal\) w regionie Wielkiej Brytanii. Ten incydent został spowodowany błędem konfiguracyjnym podczas aktualizacji bazy danych, co doprowadziło do zakłóceń w obsłudze. Aby rozwiązać ten problem, cofnęliśmy konfigurację, a Web Access wrócił do normalnej wydajności do 14: 30\ (UTC\) 22 września 2026. Aby zapobiec tego typu problemom w przyszłości, dokonujemy przeglądu i aktualizacji naszej konfiguracji bazy danych. W wyniku tej kwestii nie doszło do utraty danych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 18 września 2026 11:07 UTCinvestigating

   Otrzymaliśmy raporty, że użytkownicy nie są w stanie zalogować się do DE i UK instancji KSAT. Badamy tę kwestię i uaktualnimy tę stronę, gdy będziemy mieć więcej informacji.

2. 18 września 2026 16:48 UTCresolved

   Ten incydent został rozwiązany.

3. 8 października 2026 14:07 UTCpostmortem

   / Podsumowanie 17 września 2026 roku praca w tle archiwizowała dużą grupę użytkowników i przebiegała jako jedna bez ograniczeń transakcja bazy danych. Transakcja ta zablokowała dużą liczbę wierszy użytkowników, powodując, że region USA loguje się na czas, ponieważ zapisują do tej samej tabeli. Po naciśnięciu limitu wykonania platformy, zadanie zostało przerwane i automatycznie przepróbowane pięć razy w odstępach 15-minutowych, co skutkuje 75-minutowym przerwaniem. Aby rozwiązać problem, wprowadziliśmy rozwiązanie, które oddzieliło loginy od zamka. Następnie wprowadziliśmy kolejne rozwiązanie dla regresji wprowadzonej przez zmianę logowania, jak również dla pracy archiwalnej. * * * What happed * * Poprzednia zmiana przeniosła akcję "archiwizuj wszystkich użytkowników" z synchronicznego, time- out web w nieograniczone zadanie tła. Kiedy duża grupa użytkowników została archiwizowana, to wywołało nowe zadanie tła. Praca zablokowała wszystkie dotknięte rzędy użytkowników w jednej transakcji, wykonując per- użytkownik pisze i synchronicznego połączenia zewnętrznego usługi przed zobowiązaniem. Próby logowania, które piszą do tej samej tabeli, były ustawione w kolejce za zamkniętą pracą i w czasie dla użytkowników amerykańskich. Gdy zadanie osiągnęło 15-minutowy limit wykonania platformy, zakończono transakcję pośrednią, transakcję wycofano, a zadanie przeniesiono do kolejki. Cykl ten wystąpił pięć razy, co spowodowało 75-minutową przerwę. Po wykryciu awarii wewnętrznie o 22: 35\ (UTC\) ogłoszono incydent i wezwano inżyniera, aby zareagował. Ograniczenie do oddzielenia działania zapisu od przepływu logowania zostało zastosowane około 23: 44\ (UTC\). Samo łagodzenie wywołało regresję: każdy użytkownik w jakimkolwiek regionie, który wcześniej pomylił hasło, nie mógł się już zalogować, ponieważ resety nieudanych prób logowania próbowały zapisać do bazy danych tylko do odczytu. Do 09: 17\ (UTC\) w dniu 18 września 2026 roku, rozwiązanie tej regresji zostało wprowadzone w różnych regionach. Oryginalne zadanie US- tylko archiwum powtórzyło się dwa razy w godzinach 13: 45-14: 05\ (UTC\) zanim stałe rozwiązanie zostało zastosowane około 15: 00\ (UTC\). Incydent został w pełni rozwiązany do 19: 12\ (UTC\) 18 września 2026. * * * Root Cause * * Nieograniczony, single- transaction tło zadanie dla archiwalnego użytkownika grupy dużych miał wyłączne zamki na wielu wierszach dotkniętych, blokując proces logowania własny wiersz pisać. Wcześniejsza zmiana w celu przesunięcia tej operacji poza czas oczekiwania na stronie internetowej i do pracy w tle usunęła jedyny pozostały limit czasu trwania. 15-minutowy limit wykonania platformy uruchomił automatyczne cykle kill- and- redelivery, powtarzając 5-minutowy argument blokady i powodując 75-minutowe okno wyłączenia. * * * Findings and Mitigations * * Odkryliśmy, że nieograniczona transakcja archiwalna zablokowała dużą liczbę uszkodzonych wierszy użytkowników, blokując inną tabelę. Zostało to złagodzone w krótkim czasie poprzez oddzielenie zależności zapisu procesu logowania od dotkniętej tabeli, a następnie ustalone w dłuższej perspektywie przez skorygowanie zadania archiwum. Odkryliśmy również, że nieskoordynowane współzależności pracowników wzmacniają kłótnie blokady. W perspektywie krótkoterminowej zostało to złagodzone poprzez ręczne zmniejszanie współzależności pracowników. Długoterminowe rozwiązanie do staggera i serializacji tych miejsc pracy jest planowane. Wreszcie, odkryliśmy, że regresja login- fix spowodowała awarię logowania w regionie all- region dla użytkowników z wcześniej nieudanymi próbami, ponieważ pisma zostały odrzucone przez bazy danych tylko read-. Ustalono to poprzez ukierunkowaną zmianę kodu, która została wdrożona i zweryfikowana we wszystkich regionach. * * * Preventive Measures * * Ulepszamy nasze archiwalne operacje grupowe poprzez ich odbijanie, przetwarzanie w małych, zaangażowanych partiach i utrzymywanie połączeń zewnętrznych poza transakcją bazy danych. Dodamy również zmianę-check do określonego pracownika tła, aby pominąć pisma, które niczego nie zmieniają. Na koniec dodamy bezpośrednie alarmy dotyczące wieku transakcji w bazie danych i usuwamy opóźnienia, oprócz okresowych kontroli pośrednich. * * * Oddziaływanie klienta i odzyskiwanie * * Niepowodzenie Loginu trwało około 75 minut w regionie USA. Dwa krótkie, tylko US- tylko nawroty wystąpiły następnego ranka i zostały oczyszczone ręcznie w ciągu kilku minut. Niektóre działania admin, takie jak zarządzanie użytkownikami, również zostały naruszone. Loginy partnerów nie uległy zmianie. Regresja wtórna trwała około 10 godzin i dotyczyła wszystkich regionów dla użytkowników, którzy wcześniej nie powiodła się próba logowania. Do popołudnia 18 września potwierdzono pełne ożywienie we wszystkich regionach, a strona statusu została zaznaczona jako rozwiązana. W wyniku tej kwestii nie doszło do utraty danych. * * * Wnioski * * Pojedyncza nieograniczona transakcja w tle, połączona z automatycznym mechanizmem ponownego testowania, spowodowała brak logowania w regionie USA. Określone zadanie i jego ponowne zachowanie zostały naprawione, a logowanie nie zależy już od ustawionej ścieżki zapisu. Regresja o takim samym incydencie i dwa drobne nawroty ustąpiły w ciągu kilku godzin. Dalsze działania zapobiegawcze, w tym koordynacja pracowników i monitorowanie transakcji w bazie danych, są opisane powyżej.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 17 września 2026 22:44 UTCinvestigating

   Otrzymaliśmy raporty, że użytkownicy nie są w stanie zalogować się do amerykańskiej instancji KSAT. Badamy tę kwestię i uaktualnimy tę stronę, gdy będziemy mieć więcej informacji.

2. 18 września 2026 01:28 UTCmonitoring

   Zastosowaliśmy rozwiązanie i monitorujemy wyniki, aby upewnić się, że nie pojawią się dalsze problemy.

3. 18 września 2026 14:02 UTCinvestigating

   Otrzymaliśmy nowe raporty, że użytkownicy nie są w stanie zalogować się do amerykańskiego KSAT. Badamy tę kwestię i uaktualnimy tę stronę, gdy będziemy mieć więcej informacji.

4. 18 września 2026 16:47 UTCresolved

   Ten incydent został rozwiązany.

5. 5 października 2026 21:16 UTCpostmortem

   / Podsumowanie 17 września 2026 roku praca w tle archiwizowała dużą grupę użytkowników i przebiegała jako jedna bez ograniczeń transakcja bazy danych. Transakcja ta zablokowała dużą liczbę wierszy użytkowników, powodując, że region USA loguje się na czas, ponieważ zapisują do tej samej tabeli. Po naciśnięciu limitu wykonania platformy, zadanie zostało przerwane i automatycznie przepróbowane pięć razy w odstępach 15-minutowych, co skutkuje 75-minutowym przerwaniem. Aby rozwiązać problem, wprowadziliśmy rozwiązanie, które oddzieliło loginy od zamka. Następnie wprowadziliśmy kolejne rozwiązanie dla regresji wprowadzonej przez zmianę logowania, jak również dla pracy archiwalnej. * * * What happed * * Poprzednia zmiana przeniosła akcję "archiwizuj wszystkich użytkowników" z synchronicznego, time- out web w nieograniczone zadanie tła. Kiedy duża grupa użytkowników została archiwizowana, to wywołało nowe zadanie tła. Praca zablokowała wszystkie dotknięte rzędy użytkowników w jednej transakcji, wykonując per- użytkownik pisze i synchronicznego połączenia zewnętrznego usługi przed zobowiązaniem. Próby logowania, które piszą do tej samej tabeli, były ustawione w kolejce za zamkniętą pracą i w czasie dla użytkowników amerykańskich. Gdy zadanie osiągnęło 15-minutowy limit wykonania platformy, zakończono transakcję pośrednią, transakcję wycofano, a zadanie przeniesiono do kolejki. Cykl ten wystąpił pięć razy, co spowodowało 75-minutową przerwę. Po wykryciu awarii wewnętrznie o 22: 35\ (UTC\) ogłoszono incydent i wezwano inżyniera, aby zareagował. Ograniczenie do oddzielenia działania zapisu od przepływu logowania zostało zastosowane około 23: 44\ (UTC\). Samo łagodzenie wywołało regresję: każdy użytkownik w jakimkolwiek regionie, który wcześniej pomylił hasło, nie mógł się już zalogować, ponieważ resety nieudanych prób logowania próbowały zapisać do bazy danych tylko do odczytu. Do 09: 17\ (UTC\) w dniu 18 września 2026 roku, rozwiązanie tej regresji zostało wprowadzone w różnych regionach. Oryginalne zadanie US- tylko archiwum powtórzyło się dwa razy w godzinach 13: 45-14: 05\ (UTC\) zanim stałe rozwiązanie zostało zastosowane około 15: 00\ (UTC\). Incydent został w pełni rozwiązany do 19: 12\ (UTC\) 18 września 2026. * * * Root Cause * * Nieograniczony, single- transaction tło zadanie dla archiwalnego użytkownika grupy dużych miał wyłączne zamki na wielu wierszach dotkniętych, blokując proces logowania własny wiersz pisać. Wcześniejsza zmiana w celu przesunięcia tej operacji poza czas oczekiwania na stronie internetowej i do pracy w tle usunęła jedyny pozostały limit czasu trwania. 15-minutowy limit wykonania platformy uruchomił automatyczne cykle kill- and- redelivery, powtarzając 5-minutowy argument blokady i powodując 75-minutowe okno wyłączenia. * * * Findings and Mitigations * * Odkryliśmy, że nieograniczona transakcja archiwalna zablokowała dużą liczbę uszkodzonych wierszy użytkowników, blokując inną tabelę. Zostało to złagodzone w krótkim czasie poprzez oddzielenie zależności zapisu procesu logowania od dotkniętej tabeli, a następnie ustalone w dłuższej perspektywie przez skorygowanie zadania archiwum. Odkryliśmy również, że nieskoordynowane współzależności pracowników wzmacniają kłótnie blokady. W perspektywie krótkoterminowej zostało to złagodzone poprzez ręczne zmniejszanie współzależności pracowników. Długoterminowe rozwiązanie do staggera i serializacji tych miejsc pracy jest planowane. Wreszcie, odkryliśmy, że regresja login- fix spowodowała awarię logowania w regionie all- region dla użytkowników z wcześniej nieudanymi próbami, ponieważ pisma zostały odrzucone przez bazy danych tylko read-. Ustalono to poprzez ukierunkowaną zmianę kodu, która została wdrożona i zweryfikowana we wszystkich regionach. * * * Preventive Measures * * Ulepszamy nasze archiwalne operacje grupowe poprzez ich odbijanie, przetwarzanie w małych, zaangażowanych partiach i utrzymywanie połączeń zewnętrznych poza transakcją bazy danych. Dodamy również zmianę-check do określonego pracownika tła, aby pominąć pisma, które niczego nie zmieniają. Na koniec dodamy bezpośrednie alarmy dotyczące wieku transakcji w bazie danych i usuwamy opóźnienia, oprócz okresowych kontroli pośrednich. * * * Oddziaływanie klienta i odzyskiwanie * * Niepowodzenie Loginu trwało około 75 minut w regionie USA. Dwa krótkie, tylko US- tylko nawroty wystąpiły następnego ranka i zostały oczyszczone ręcznie w ciągu kilku minut. Niektóre działania admin, takie jak zarządzanie użytkownikami, również zostały naruszone. Loginy partnerów nie uległy zmianie. Regresja wtórna trwała około 10 godzin i dotyczyła wszystkich regionów dla użytkowników, którzy wcześniej nie powiodła się próba logowania. Do popołudnia 18 września potwierdzono pełne ożywienie we wszystkich regionach, a strona statusu została zaznaczona jako rozwiązana. W wyniku tej kwestii nie doszło do utraty danych. * * * Wnioski * * Pojedyncza nieograniczona transakcja w tle, połączona z automatycznym mechanizmem ponownego testowania, spowodowała brak logowania w regionie USA. Określone zadanie i jego ponowne zachowanie zostały naprawione, a logowanie nie zależy już od ustawionej ścieżki zapisu. Regresja o takim samym incydencie i dwa drobne nawroty ustąpiły w ciągu kilku godzin. Dalsze działania zapobiegawcze, w tym koordynacja pracowników i monitorowanie transakcji w bazie danych, są opisane powyżej.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 16 września 2026 17:47 UTCidentified

   Zidentyfikowaliśmy problem powodujący login i dostęp do kont na naszej brytyjskiej instancji.

2. 16 września 2026 18:16 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

3. 16 września 2026 20:58 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 11 września 2026 12:43 UTCresolved

   Na Septerber 8th uświadomiliśmy sobie, że przychodzące wiadomości HTML renderowane częściowo lub pusto w programie Classic Outlook ze względu na rutynową aktualizację biblioteki HTML w systemie Defend 's Harfull-Code-Demotion Engine interacting with Classic Outlook' s Legislative Word rendering engine. Nowy Outlook i Outlook w sieci nie zostały naruszone. To był ściśle problem wyświetlania: żaden e-mail nie został opóźniony, utracony, lub zagrożony, a wykrywanie zagrożeń pozostał w pełni aktywny. Maszynownia odwróciła aktualizację, aby przywrócić normalne renderowanie. Jeśli tymczasowo wyłączone usuwanie kodu szkodliwego podczas tego okna, należy ponownie włączyć go w celu zapewnienia pełnej ochrony.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 4 września 2026 10:53 UTCinvestigating

   Otrzymaliśmy raporty o problemie z dostawą e-mail weryfikacji MFA for Workspace. Badamy tę kwestię i uaktualnimy tę stronę, gdy będziemy mieć więcej informacji.

2. 4 września 2026 14:24 UTCmonitoring

   Otrzymaliśmy raporty, że problem z dostawą e-mail weryfikacji MFA for Workspace został złagodzony przez Microsoft, i monitorujemy wyniki.

3. 7 września 2026 08:25 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 26 sierpnia 2026 16:19 UTCinvestigating

   Zidentyfikowaliśmy problem, w którym użytkownicy mogą odczuwać opóźnienia w przetwarzaniu wiadomości, a nasz zespół inżynieryjny szuka rozwiązania.

2. 26 sierpnia 2026 16:46 UTCmonitoring

   Nasz zespół inżynieryjny wdrożył rozwiązanie problemu powodującego opóźnienia w przetwarzaniu wiadomości w firmie PhishER, a my monitorujemy wyniki.

3. 26 sierpnia 2026 19:51 UTCresolved

   Nasz zespół inżynieryjny wdrożył rozwiązanie problemu powodującego opóźnienia w przetwarzaniu wiadomości w firmie Phisher.

4. 16 października 2026 20:36 UTCpostmortem

   / Podsumowanie Podczas rutynowego rozmieszczania w dniu 26 sierpnia 2026 r. ramy zarządzania infrastrukturą nieoczekiwanie usunęły zarówno podstawowe kolejki przetwarzania wiadomości, jak i kolejki wtórne, które zawierają komunikaty, które nie mogły być przetwarzane. Spowodowało to tymczasowe przerwanie dostawy poczty e-mail do skrzynek odbiorczych klientów firmy PhishER. W wyniku tej kwestii nie doszło do utraty danych. * * * Root Cause * * 24 sierpnia 2026 roku, wewnętrzna zmiana konfiguracji pozostawiła zapis konfiguracji na żywo poza synchronizacją z naszym kodem. Późniejsza aktualizacja kodu nie odwróciła tych zapisów. Kiedy rutynowe rozmieszczenie produkcji odbyło się w dniu 26 sierpnia 2026 roku, aktywny kod konfiguracji nie zawierał przeniesionych rekordów zasobów. W związku z tym rozmieszczenie traktuje aktywne kolejki jako niezarządzane zasoby i usuwa je. * * * Litigation and Remediation * * Automatyczne monitorowanie zaalarmowało nas o spadku częstotliwości przetwarzania wiadomości i zespół reagowania na incydenty został złożony. Odkryliśmy, że kolejki zostały usunięte. W perspektywie krótkoterminowej zostało to złagodzone poprzez ponowne uruchomienie miejsc pracy związanych z produkcją, aby odtworzyć brakujące kolejki. Następnie potwierdziliśmy, że przetwarzanie poczty elektronicznej w czasie rzeczywistym wznowiło się. W końcu ponownie odtworzyliśmy ładunki e-mail przechowywane w pamięci masowej w chmurze podczas przestoju na skrzynki odbiorcze klientów. * * * Timeline * * Wszystkie czasy są w UTC. * * * 24 sierpnia 2026, 18: 41: * * Wewnętrzna zmiana konfiguracji zapisała zaktualizowane rekordy zasobów do konfiguracji produkcji na żywo. * * * 26 sierpnia 2026, 15: 15: * * Wdrożenie produkcji usunęło przychodzące kolejki i kolejki, które przechowują wiadomości, które nie mogły być przetwarzane w produkcji, zatrzymując wysyłkę e-mail na skrzynki odbiorcze klientów. * * * 26 sierpnia 2026, 15: 59: * * Nasz zautomatyzowany monitoring zaalarmował zespół inżynieryjny, że nie ma wiadomości, a zespół reagowania na incydenty został wezwany. * * * 26 sierpnia 2026, 16: 01: * * Potwierdziliśmy, że kolejki zostały usunięte i zweryfikowane, że przychodzące ładunki e-mail były nadal przechowywane bezpiecznie. * * * 26 sierpnia 2026, 16: 15: * * Zidentyfikowaliśmy błąd konfiguracji jako główną przyczynę. 26 sierpnia 2026, 16: 25. Nasz zespół wznowił prace produkcyjne, a kolejki zostały odtworzone. * * * 26 sierpnia 2026, 18: 44: * * Nasza automatyczna powtórka zakończyła dostarczanie wszystkich zaległych e-maili na skrzynki odbiorcze klientów. * * * Prewencyjne środki * * Aby zapobiec tego typu problemom w przyszłości, usunęliśmy krok konfiguracji życia z kontroli przed połączeniem i oddzieliliśmy planowanie rozmieszczenia od zmian produkcji. Dodaliśmy również automatyczne kontrole, aby potwierdzić stan zdrowia kolejki po zakończeniu wydania. * * * Oddziaływanie klienta * * Od 15: 15 do 16: 25\ (UTC\) w dniu 26 sierpnia 2026, przychodzące wiadomości przesłane do Phisher nie były przetwarzane na skrzynki odbiorcze. Przychodzące ładunki pocztowe były bezpiecznie przechowywane w pamięci masowej w chmurze przez cały czas trwania zakłóceń. Po przywróceniu kolejki, automatyczna powtórka dostarczona wiadomości e-mail na skrzynki odbiorcze klientów. Wszystkie zaksięgowane wiadomości zostały dostarczone przez 18: 44\ (UTC\). W wyniku tego problemu nie utracono żadnych danych e-mail klienta.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 21 sierpnia 2026 08:52 UTCinvestigating

   Otrzymaliśmy raporty, że Gmail Fish Alert Button pokazuje błąd "[reportPhishAttempt ()] Wystąpił błąd wewnętrzny. Proszę spróbować jeszcze raz". Badamy tę kwestię i uaktualnimy tę stronę, gdy będziemy mieć więcej informacji.

2. 21 sierpnia 2026 12:03 UTCidentified

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

3. 21 sierpnia 2026 13:08 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

4. 21 sierpnia 2026 14:57 UTCresolved

   Ten incydent został rozwiązany.

5. 26 sierpnia 2026 15:55 UTCpostmortem

   W piątek, 21 sierpnia 2026, od około 05: 20 do 12: 55\ (UTC\), niektórzy klienci doświadczyli przerywanych awarii podczas korzystania z Gmail Phish Alert Button add- w celu zgłaszania podejrzanych e-maili, otrzymywanie wiadomości "Wystąpił błąd wewnętrzny" zamiast udanego potwierdzenia raportu. Problem dotyczył klientów we wszystkich regionach, przy czym największy poziom błędu koncentrował się w regionach usługowych UE-Zachód i USA-Wschód. Problem ten został spowodowany zakłóceniem usługi buforowania na platformie Google Apps Script, na której add- in polega do przechowywania konfiguracji sesji dla użytkownika. Usługa zaczęła przerywać zwracanie pustych wyników po przeczytaniu, a jednocześnie akceptować nowe pisma, powodując, że wpłynął na oświadczenia raportu nie. KnowBe4 bezpośrednio zaangażował Google i złożył formalny raport o błędzie w przedziale od 12: 19 do 12: 39\ (UTC\). Objętość błędu gwałtownie spadła wkrótce po oczyszczeniu stanu Vendorside, a przycisk Alert Gmail phish powrócił do normalnej wydajności o około 12: 55\ (UTC\). Aby zapobiec tego typu problemom w przyszłości, kontynuujemy współpracę z Google w celu śledzenia rozwiązania problemu buforowania. W wyniku tej kwestii nie doszło do utraty danych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 18 sierpnia 2026 14:29 UTCinvestigating

   Badamy problem powodujący, że raport o niedostawie (NDR) zostanie zwrócony, gdy wiadomość jest zgłaszana za pośrednictwem przycisku alarmowego Phish i "Wyślij nam kopię" jest włączona w ustawieniach konta

2. 18 sierpnia 2026 15:26 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

3. 18 sierpnia 2026 20:14 UTCresolved

   Ten incydent został rozwiązany.

4. 30 września 2026 20:06 UTCpostmortem

   We wtorek, 18 sierpnia 2026 r., od około 14: 10 do 14: 55\ (UTC\), klienci korzystający z przycisku Phish Alert\ (PAB\) z funkcją * * Wyślij nam Kopiuj * * z włączoną funkcją otrzymywania raportów o braku dostawy dla skrzynki * * Wyślij nam Kopiuj * *. Problem ten został spowodowany zmianą konfiguracji wspólnej infrastruktury routingu e-mail. Zmiana ta zmieniła nazwę komponentu komunikacyjnego używanego zarówno przez nasze środowiska inscenizacyjne jak i produkcyjne. Ponieważ zasada produkcji zależała od tego współdzielonego komponentu, zmiana nazwy spowodowała niepowodzenie dostawy do * * Wyślij nam Kopiuj * * i uruchomił raporty o braku dostawy. Aby rozwiązać ten problem, nasz zespół zaktualizował wybraną konfigurację w celu odniesienia się do poprawnego komponentu, a funkcja * * Wyślij nam kopię * * powróciła do normalnej wydajności o 14: 55\ (UTC\). Aby zapobiec tego typu problemom w przyszłości, rozdzielamy konfiguracje routingu e-mail dla naszych środowisk inscenizacji i produkcji. Łączymy również dotychczasowe konfiguracje z obecnymi standardami zarządzania infrastrukturą. W wyniku tej kwestii nie doszło do utraty danych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 5 sierpnia 2026 19:29 UTCinvestigating

   We are currently investigating an issue affecting Google PhishRIP queries, which may cause them to fail.

2. 5 sierpnia 2026 21:24 UTCmonitoring

   Based on our investigation into the recent errors affecting Google PhishRIP queries, it appears these may be related to suspended Gmail accounts. We are continuing to monitor the issue.

3. 6 sierpnia 2026 21:56 UTCresolved

   Upon further investigation we have determined that the errors affecting Google PhishRIP queries were related to individual issues on Google accounts.

1. 4 sierpnia 2026 19:19 UTCidentified

   Zidentyfikowaliśmy problem uniemożliwiający załadowanie konta w konsoli SAT.

2. 4 sierpnia 2026 19:51 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

3. 5 sierpnia 2026 12:17 UTCresolved

   Ten incydent został rozwiązany.

4. 28 września 2026 14:35 UTCpostmortem

   We wtorek, 4 sierpnia 2026, od około 18: 22 do 19: 43\ (UTC\), niektórzy klienci doświadczyli problemów wczytywania * * Ustawienia konta * * strony w konsoli KnowBe4 w regionach CA, DE, UE, UK i USA. Kwestia ta została spowodowana serią zmian aplikacji, które zwiększyły złożoność żądania GraphQL używanego przez doświadczenie Ustawienia Konta. Każda zmiana pozostawała poniżej skonfigurowanego progu złożoności platformy, gdy była oceniana indywidualnie, ale łącznie, wniosek przekroczył ten próg i uniemożliwił załadowanie strony. Inżynieria określiła próg złożoności jako czynnik wnoszący wkład i wprowadziła zmianę korygującą rozpoczynającą się około 19: 14\ (UTC\). Po sprawdzeniu fix we wszystkich dotkniętych regionach konsola KnowBe4 powróciła do normalnej wydajności około 19: 43\ (UTC\). Aby zapobiec tej kwestii w przyszłości, zwiększyliśmy próg złożoności. W wyniku tej kwestii nie doszło do utraty danych.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 28 lipca 2026 20:00 UTCinvestigating

   Badamy sprawę związaną z nieoczekiwanie poddanym kwarantannie e-mailem przez PhishRIP

2. 28 lipca 2026 20:35 UTCmonitoring

   W odniesieniu do tej kwestii wdrożono rozwiązanie, a pytania FishRIP nie podlegają już nieoczekiwanej kwarantannie wiadomości. Nadal badamy pytania, które mogły mieć wpływ

3. 29 lipca 2026 18:58 UTCresolved

   Ten incydent został rozwiązany.

4. 30 lipca 2026 16:38 UTCpostmortem

   / Podsumowanie W dniu 28 lipca 2026 r. Łagodne e-maile, które nie spełniały ustawionych kryteriów nadawcy, zostały poddane kwarantannie na niektórych kontach klientów. Automatyczne bilety na monitoring i obsługę klienta szybko ujawniły problem. Maszynownia cofnęła zmianę w ciągu około 25 minut od ogłoszenia incydentu i zatrzymała niezamierzoną kwarantannę. Następnie maszynownia ręcznie przywracała niewłaściwie izolowane maile do skrzynek odbiorczych klientów. * * * Root cause * * 28 lipca 2026, wprowadziliśmy aktualizację obsługi technicznej do serwisu zapytań za PhishRIP. Ta aktualizacja została zaprojektowana w celu poprawy obsługi nieprawidłowego adresu nadawcy, pozwalając systemowi powrócić do wyszukiwania tylko części domeny adresu. Istniejąca logika walidacji używała jednak wyrażenia regularnego, które wymagało symbolu "@" w polu nadawcy. Gdy w zapytaniu użyto domeny gołej, takiej jak [example.com] (http: / / example.com) bez nazwy użytkownika lub symbolu "@", regex oznaczył domenę jako nieprawidłową. Ten konflikt pomiędzy istniejącą walidacją a aktualizacją wyszukiwania domowego spowodował, że system całkowicie zrzucił kryteria nadawcy. Zapytanie dotyczyło skrzynek odbiorczych z wykorzystaniem tylko pozostałych parametrów, dopasowywania i kwarantanny e-maili, które znajdują się daleko poza planowanym nadawcą. * * * Timeline * * Wszystkie czasy są w UTC. 124; * * Czas * * 124; * * Zdarzenie * * 124; {C: $999966} {f: 124; 19: 36 124; Nasz zautomatyzowany monitoring wykrył anomalie wzorców wykonywania zapytań i powiadomił naszych inżynierów, którzy natychmiast rozpoczęli dochodzenie. VIId; Numer 124; 19: 51 124; Kwestia została eskalacyjna do wysoce dotkliwego incydentu produkcyjnego, a zespół odpowiedzi został złożony. VIId; 124; 19: 52 124; Nasz zespół wsparcia nasilił pierwsze bilety klientów, którzy zgłosili niespodziewane kwarantanny, potwierdzając alarm monitorujący. 124; 19: 54 XI124; Przyczyną było ostatnie pytanie API, a inżynieria zaczęła cofać zmianę. 124; 20: 00 124; Komunikaty Incydent zostały umieszczone na naszej stronie statusu, FishRIP oznaczone jako Degraded. 124; 20: 16 124; rozmieszczenie zostało całkowicie odwrócone. 124; 20: 35 124; Kontrole produkcji potwierdziły, że pytania dotyczące tematu i domeny były ponownie dopasowywane tylko do ich zamierzonych celów i że żadne dalsze wiadomości nie były poddawane kwarantannie w błędzie. Nasza strona statusu została odpowiednio zaktualizowana. VIId; 124; 20: 39 124; Maszynownia rozpoczęła przywracanie nieprawidłowo poddanego kwarantannie e-maila. 124; 03: 49\ (następnego dnia\)\ 124; Przywrócenia zostały zakończone dla wszystkich zestawów zapytań klientów zalogowanych przez nasz zespół wsparcia. / Łagodzenie i rekultywacja * * code revert. * * Zważaliśmy wstrzymanie aktywnych operacji PhishRIP w połowie biegu przeciwko zwrotowi kodu. Zatrzymanie zadań w tle zakłóciłoby legalny przepływ pracy w zakresie bezpieczeństwa dla każdego najemcy, tak więc powrót był lepszym rozwiązaniem. Kod ten został wprowadzony i zweryfikowany w produkcji w ciągu około 40 minut od eskalacji. * * Odbudowa poczty elektronicznej. * * Aby uniknąć wypuszczenia naprawdę złośliwych e-maili z powrotem do środowiska klientów, ręcznie je odrestaurowaliśmy, a nie luzem. Inżynieria użyła wewnętrznych narzędzi admin do przywracania e-maili w partiach, i pracowała z Support, aby zweryfikować każdy ID konta, ID zapytania i otrzymać zgodę klienta najpierw. Wszystkie zgłoszone konta zostały przywrócone z dnia na dzień. * * * Środki zapobiegawcze * * * * * Regresja obejmuje * *: Dodajemy testy jednostkowe i integracyjne tylko domain-, nie- standardowe i bose-strun nadawców, aby złapać te sprawy wejściowe przed wdrożeniem. * * * Query guardrails * *: Dodajemy kontrolę w silniku zapytania, która blokuje zapytania przed uruchomieniem, jeśli ich podstawowe parametry filtrowania zostaną obniżone podczas oceny. * * * Wnioski * * Spowodowała to jedna zasada walidacji: regex, który zakładał, że każde pole nadawcy zawiera '@'. Kiedy zapytania używały gołej domeny, to założenie zrzuciło filtr nadawcy i zapytania dopasowały znacznie więcej poczty niż zamierzono. Naprawa była prosta, gdy ją znaleźliśmy, a powrót zatrzymał szkody w ciągu około 25 minut od ogłoszenia incydentu. Przywracanie poczty podlegającej kwarantannie było trudniejszym procesem: nie mogliśmy masowo przywracać e-maili bez ryzykowania autentycznie złośliwych e-maili wracających do skrzynki odbiorczej. Nasz zespół zdecydował się postępować ostrożnie, pracując kontem z support przez całą noc. Dwa środki zapobiegawcze wykryłyby to wcześniej: test obejmujący jedynie pytania nadawców domain- oraz barierkę, która odmawia przeprowadzenia zapytania, gdy filtr nadawcy został usunięty. Oba są teraz zaplanowane. Bezpośrednia kwestia została rozwiązana i wszystkie zgłoszone rachunki zostały przywrócone. * * * Glossary * * * * * PhishRIP: * * Funkcja PhishER, która pozwala administratorom szukać i kwarantanny pasujące phishing e-maile w każdym skrzynce użytkownika w organizacji. * * * Regex\ (wyrażenie regularne\): * * Wzór używany w oprogramowaniu do wyszukiwania tekstu i walidacji danych wejściowych, takich jak sprawdzenie, czy adres e-mail jest poprawnie sformatowany. * * * Kod odwrócony: * * Bakowanie aktualizacji oprogramowania, aby powrócić do poprzedniej stabilnej wersji.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 17 lipca 2026 13:18 UTCinvestigating

   Prowadzimy dochodzenie w sprawie niezdolności użytkowników do zakupu licencji Protect na magazynie. Będziemy aktualizować tę stronę, gdy będziemy mieli więcej informacji.

2. 17 lipca 2026 18:55 UTCmonitoring

   Zastosowaliśmy rozwiązanie i monitorujemy wyniki, aby upewnić się, że nie pojawią się dalsze problemy.

3. 20 lipca 2026 18:24 UTCinvestigating

   Otrzymaliśmy raporty, że klienci nie są w stanie kupić licencji Protect na magazynie. Badamy tę kwestię i uaktualnimy tę stronę, gdy będziemy mieć więcej informacji.

4. 29 lipca 2026 18:40 UTCmonitoring

   Wprowadziliśmy naprawę sklepu internetowego i monitorujemy wyniki, aby upewnić się, że nie pojawią się dalsze problemy.

5. 17 sierpnia 2026 21:02 UTCmonitoring

   Kontynuujemy monitorowanie wdrożonego rozwiązania dla sklepu internetowego, aby zapewnić, że nie pojawią się dalsze problemy.

6. 11 września 2026 15:04 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.