Wielokrotne usługi Atlassian doświadczają problemów
- investigating
Mamy problemy z wieloma produktami Atlassian. Nasze zespoły badają kolejne aktualizacje, w tym zostaną udostępnione w ciągu 1 godziny.
- identified
Zidentyfikowaliśmy, że główna przyczyna problemu jest związana z brakiem infrastruktury przez naszego operatora chmury publicznej. Współpracujemy z nimi ściśle w celu złagodzenia tej kwestii. Dostarczymy dalsze aktualizacje, gdy staną się dostępne.
- identified
Nasze zespoły kontynuują prace nad ograniczeniem niedoboru infrastruktury od naszego publicznego dostawcy chmur. Dostarczymy dalsze aktualizacje, gdy będą dostępne.
- identified
Kontynuujemy współpracę z naszym publicznym dostawcą chmur w celu złagodzenia tej kwestii. Zaczynamy dostrzegać pewne ożywienie w regionach poza Wschodnią USA, jednak użytkownicy na całym świecie mogą nadal doświadczać problemów z pewnymi cechami produktu. Są one wymienione na dole każdej strony produktu.
- monitoring
Zagadnienie leżące u podstaw infrastruktury publicznej, która dotyczyła asynchronicznego przetwarzania zdarzeń, zostało złagodzone, a wszystkie usługi, których to dotyczy, powracają do normy. Obecnie pracujemy nad usuwaniem zaległości związanych z wydarzeniami kolejowymi, co oznacza, że niektóre działania (takie jak powiadomienia, aktywatory automatyki i synchronizacja danych) mogą być w stanie zdegradowanym. Będziemy nadal monitorować i dostarczać aktualizacje po usunięciu zaległości.
- monitoring
Monitorujemy sytuację, gdy usługi wracają do normy. Jesteśmy obecnie w trakcie usuwania zaległości wydarzeń w kolejce. Dostarczymy kolejne informacje za około godzinę.
- monitoring
Nasze usługi są teraz w pełni sprawne. Kontynuujemy odtwarzanie wszystkich zdarzeń, które zostały pominięte podczas incydentu i czynimy postępy. Dostarczymy kolejną aktualizację po zakończeniu powtórzeń. W przypadku jakichkolwiek bieżących problemów prosimy o kontakt z naszym zespołem wsparcia. Przepraszamy za zakłócenia i dziękujemy za cierpliwość.
- resolved
W dniu 8 maja 2026 r. niektórzy klienci wykorzystujący produkty Atclassian doświadczyli wyższych poziomów błędów i pogorszyły wydajność. Problem został teraz rozwiązany, a usługa działa normalnie dla wszystkich klientów dotkniętych.
- postmortem
Wszystkie poniższe daty i godziny znajdują się w UTC, chyba że wskazano inaczej. Podsumowanie 8 maja 2026 w godzinach 00: 22-06: 08 jeden z naszych dostawców usług hostingowych doznał poważnego incydentu w określonej strefie dostępności na Prod- wschód, co doprowadziło do sytuacji, w której klienci Atclassian doświadczali zdegradowanej wydajności i opóźnień w operacjach w tle i automatyzacji. Incydent rozpoczął się 8 maja 2026 o godzinie 00: 22 i został wykryty w ciągu 4 minut przez zautomatyzowane systemy monitorowania. Nasze zespoły pracowały nad przywróceniem dostępu do rdzenia do 06: 08. Końcowe oczyszczenie zaległych procesów i drobnych problemów postępuje w etapach stamtąd został ukończony iteralnie o 19: 15. * * * IMPACT * * Podstawową infrastrukturą, której dotyczył ten incydent, był gazociąg do przetwarzania zdarzeń w regionie Prod- wschód, który rozdziela wydarzenia pomiędzy usługi Atclassian i stanowi podstawę operacji w tle, takich jak automatyzacja, indeksowanie wyszukiwania, powiadomienia, synchronizacja zezwoleń. * Między 00: 22 a 06: 08 incydent infrastrukturalny w naszym hostingu wywołał awarię w naszym gazociągu przetwarzania zdarzeń. * O 02: 50, połknięcie zdarzenia nie powiodło się w niezmienionej strefie dostępności, stopniowo przywracając przepływy na żywo. * O 06: 08, niezawodność dla nowego spożycia w prod- wschód odzyskał do 100%. Pozostała praca polegała na drenażu nagromadzonych zaległości międzyregionalnych komunikatów, które zakończyły się o 17: 00. * Do 18: 48, Automation przetwarza ich zaległości zdarzeń, które zostały utworzone podczas przetwarzania Automatyzacja Między godziną 00: 22 a 02: 50 klienci z zasadami automatyzacji wywołanymi wydarzeniami pochodzącymi z regionu wschodniego doświadczyli znacznego ograniczenia egzekucji. Podczas tego okna zasady automatyki wywołanej zdarzeniami nie wypaliły, ponieważ wydarzenia, które je wywołały, nie były dostarczane. Zasady autoryzacji, oszczędzania i zasady uruchamiane ręcznie, przez harmonogramy lub przez haki nie zostały naruszone. O godzinie 02: 50 infrastruktura przetwarzania zdarzeń nie powiodła się w niezmienionej strefie dostępności, przywracając dostawy wydarzeń na żywo do Automatyzacji i pozwalając na rozpoczęcie normalnej realizacji nowych zasad wywołanych przez zdarzenia. Jednakże zdarzenia powstające w trakcie okna zderzeniowego musiały być ponownie odtwarzane przed przeprowadzeniem opóźnionych automatyzacji. Począwszy od 08: 28, służby wyższego szczebla odtwarzały swoje wydarzenia w kolejkach w skoordynowanej kolejności, a wszystkie powtórne wydarzenia były przetwarzane do 18: 48. Podczas okna powtórki klienci mogli doświadczyć zasad automatyzacji, które mogą być wykonywane później niż się spodziewano, niewielkiej liczby przepisów osiągających dzienne limity przetwarzania z powodu powtórki skompresowanej oraz zasad wrażliwych na czas, które nie będą wypełniane zgodnie z oczekiwaniami w przypadku przekroczenia wewnętrznych progów czasowych. * * Jira and Jira Service Management * * Między godziną 00: 22 a 02: 50 klienci z najemcami, którzy byli gospodarzami w regionie wschodnim, doświadczyli zakłóceń w Jira i Jira Service Management, takich jak automatyzacja, wraz z krótkim okresem zwiększonych błędów podczas awarii infrastruktury. Podstawowe doświadczenia Jiry, w tym widok na problem, tablice i nawigacja projektu, były dostępne przez cały incydent. Na dostarczanie produktu leczniczego Jira miały wpływ główne skutki, uniemożliwiające usługom niższego szczebla otrzymywanie zdarzeń związanych z cyklem życia. To miało wpływ na zasady automatyzacji wywołane przez wydarzenia Jira, AI agent orchestration w Jira, powiadomienia o aktualizacjach emisji i przejściach, wyszukiwanie indeksacji nowo utworzonych lub zmodyfikowanych problemów, a także interakcje między Jirą a innymi produktami Atlassian. O godzinie 02: 50 infrastruktura przetwarzania zdarzeń nie powiodła się w niezmienionej strefie dostępności, przywracając dostawy nowych wydarzeń. Wszystkie zdarzenia wygenerowane podczas okna uderzenia zostały zachowane w kolejce odzyskiwania i wymagane ponowne odtwarzanie. Zaczęło się o 08: 28 i skończyło o 12: 00. Podczas okna powtórki klienci mogli doświadczyć zasad automatyzacji, wykonujących później niż oczekiwano, opóźnionych powiadomień przybywających kilka godzin po uruchomieniu działania, tymczasowych luk w wynikach wyszukiwania treści stworzonych lub zmodyfikowanych w czasie trwania okna zderzeniowego oraz przepływów pracy agenta AI, które nie zostały zakończone zgodnie z oczekiwaniami w przypadku przekroczenia wewnętrznych progów czasowych. * * Confluence * * Między godziną 00: 22 a 02: 50 klienci z najemcami gościli w regionie Prod- wschód doświadczyli zakłóceń w świadczeniu usług w Konfluence. Spowodowało to opóźnienia w poszukiwaniu indeksowania, powiadomień, automatyzacji i synchronizacji zezwoleń. Podstawowa infrastruktura przetwarzania zdarzeń nie powiodła się w niezmienionej strefie dostępności, po której w normalnych warunkach wznowiono działalność w zakresie połączeń na żywo. Jednakże zdarzenia powstające podczas okna uderzenia zostały ułożone w kolejce do powtórki, a niektóre usługi w tle pozostały opóźnione do czasu zakończenia tej powtórki i powiązanych prac walidacyjnych. Między 10: 14 a 17: 00, w celu przywrócenia spójności danych, zakończono masową powtórkę wszystkich zadań związanych z kolejką. Podczas i bezpośrednio po oknie powtórki, klienci mogli doświadczyć wyników wyszukiwania nieodzwierciedlających treści wytworzonych lub zmodyfikowanych w czasie przestoju, opóźnionych lub brakujących powiadomień o aktywności strony i komentarza, zasad automatyzacji odpalania później niż oczekiwano, oraz krótkich opóźnień w synchronizacji zezwoleń dla najemców polegających na przyrostowej synchronizacji tożsamości. * * Bitbucket and Pipelines * * Między godziną 00: 22 a 06: 08 klienci korzystający z Bitbucket and Pipelines doświadczyli niepowodzeń i zdegradowanej funkcjonalności w przepływach pracy spowodowanych przez zdarzenia. Podstawowe operacje Git, w tym pchnięcie, ciągnięcie i klon, nie zostały naruszone i nadal działają normalnie przez cały incydent. Automatyczne uruchamianie rurociągów inicjowane przez pchnięcie lub ciągnięcie zdarzenia żądanie były niedostępne w oknie uderzenia. Połączenia kolejki, niestandardowe kontrole łączenia, detonatory oparte na Forgespace, zmiany w pozwoleniach w miejscu pracy, a także niektóre przepływy rezerw w miejscu pracy. Klienci stosujący kolejki łączące nie byli w stanie połączyć wniosków o przyciągnięcie, a niektóre kroki rurociągowe zawiodły, ponieważ praca w kolejce przyczyniła się do podwyższenia limitów wzajemnych. Około godziny 03: 57, rurociągi zostały przekonfigurowane, aby konsumować wydarzenia za pomocą alternatywnej ścieżki, przywracając automatyczne uruchamianie rurociągu. Kolejki połączeń, niestandardowe kontrole łączenia, wyzwalacze Forge i inne dotknięte przepływy pracy zostały stopniowo przywrócone w momencie odzyskiwania podstawowej infrastruktury przetwarzania zdarzeń. Wszystkie usługi Bitbucket i Pipelines zostały potwierdzone w pełni operacyjne do 06: 08. Po odzyskaniu w kolejce zostały poddane przeglądowi i ponownie rozegrane wydarzenia tam, gdzie można bezpiecznie przywrócić spójność danych w zakresie rozliczeń, rejestrowania audytów i innych procesów w tle. * * Usługi tożsamości * * Między godziną 00: 22 a 02: 50 klienci z najemcami, którzy byli gospodarzami w regionie wschodnim, doświadczyli opóźnień w propagowaniu tożsamości i zmian w składzie grupy w odniesieniu do produktów pochodzących z regionu Atclassian. Operacje tożsamości podstawowej, w tym uwierzytelnianie, logowanie i bezpośrednie zarządzanie grupą, nie zostały naruszone i nadal funkcjonowały normalnie w trakcie całego incydentu. Wpływ był ograniczony do asynchronicznych operacji, które zależą od rurociągu przetwarzania zdarzeń. Obejmowało to opóźnienia w dostarczaniu członkostwa w grupie i zmiany profilu użytkownika produktów takich jak Jira i Confluence, które miały wpływ na synchronizację zezwoleń na dopływ i przepływy synchronizacji tłumu. Niewielka liczba synchronizacji tożsamości opartej na SCIM oraz przepływów roboczych związanych z zasilaniem terenu również napotkała tymczasowe opóźnienia. Po odzyskaniu infrastruktury przetwarzania zdarzeń, w razie potrzeby ponownie odtworzyno kopię zapasową zdarzeń związanych z tożsamością i katalogiem grupowym, przywracając późniejszą spójność w odniesieniu do produktów, których to dotyczy. Nie zgubiono żadnych danych. Zmiany w składzie grupy, aktualizacje profilu użytkownika oraz zdarzenia związane z rezerwami, które miały miejsce w trakcie okna oddziaływania, zostały zatrzymane i przetworzone po odzyskaniu. * * * PLAN DZIAŁAŃ NAPRAWCZYCH I NASTĘPNE STAPY * * Wiemy, że przestoje wpływają na wydajność. Podczas gdy nasze procesy monitorowania i odbudowy pomogły nam szybko zareagować, incydent ten uwydatnił możliwości dalszego wzmocnienia odporności na usługi napędzane przez zdarzenia. Traktujemy priorytetowo ulepszenia, które: * * * Wzmocnienie zasięgu awarii * * tak krytyczne przetwarzanie zdarzeń może odzyskać bardziej sprawnie podczas zakłóceń infrastruktury. * * * Wzmocnienie obsługi odzyskiwania * * więc powtórzone zdarzenia mogą być przetwarzane szybciej. Przepraszamy klientów, których usługi zostały dotknięte w trakcie tego incydentu; podejmujemy natychmiastowe kroki w celu poprawy wydajności i dostępności platformy. Dzięki. Atakować Obsługa Klienta.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.