Gdy zależność się załamuje: nasz raport po incydencie z 22–23 czerwca
22 czerwca 2026 roku nasz główny partner od asynchronicznych zadań i zarządzania kolejkami, Trigger.dev, doświadczył katastrofalnej, rozciągniętej na wiele regionów awarii kaskadowej. Ponieważ nasza podstawowa infrastruktura platformy mocno opiera się na ich silniku do obsługi zadań w tle, webhooków i kluczowych workflow, ta awaria po stronie dostawcy natychmiast stworzyła dla naszej aplikacji incydent o wysokiej severities. Trigger.dev opublikowało własny, transparentny opis techniczny tutaj: [Raport o incydencie Trigger.dev (22 czerwca 2026)](https://trigger.dev/blog/incident-report-jun-22-2026). Poniżej znajdziesz spójny opis tego, jak awaria ich infrastruktury bezpośrednio przełożyła się na naszą wewnętrzną oś czasu inżynieryjnego i jak wyprowadziliśmy się z całkowitej ciemności.
Dopasowana oś czasu
| Czas (UTC) | Co wydarzyło się po stronie dostawcy (Pełny raport) | Co wydarzyło się wewnętrznie / nasze doświadczenie |
|---|---|---|
| 22 czerwca, 19:00 | Iskra: Niedobór mocy w us-east-1 w AWS powoduje, że około 10 000 uruchomień zaczyna piętrzyć się w kolejce po stronie dostawcy. | Nasze zadania w tle po cichu zaczynają się zacinać. Kolejki zaczynają rosnąć pod spodem. |
| 22 czerwca, 20:09 | Załamanie: Upstreamowy control plane Kubernetes osiąga 100% CPU, traci quorum bazy danych i **us-east-1** całkowicie przestaje działać. | Nasze środowisko produkcyjne przestaje przetwarzać uruchomienia. Tysiące zadań w całej platformie zostaje zablokowanych w backlogu. |
| 22 czerwca, 21:58 | Zespół po stronie dostawcy aktywnie walczy z pętlą „reconnection storm”. | Zgłoszenie incydentu: Notujemy podwyższony poziom błędów i uruchamiamy wewnętrzny pokój incydentowy. |
| 23 czerwca, 00:59 | Dostawca zaleca użytkownikom ręczne przeniesienie obciążeń do regionu eu-central-1. | Przydzielono lidera incydentu: Pokój reagowania na incydent zostaje w pełni aktywowany, a do obsługi oceny międzyregionowej przydzielony zostaje lider. |
| 23 czerwca, 01:01 - 02:10 | Dostawca wdraża awaryjną aktualizację panelu, aby umożliwić masowe przenoszenie uruchomień między regionami. | Aktywna mitygacja: O 01:10 zespół ręcznie anuluje nasze zakolejkowane uruchomienia w USA, żeby zwolnić zablokowaną pojemność wykonawczą konta, i kieruje cały nowy ruch do regionu europejskiego. Do 02:10 wiadomości zaczynają znów być przetwarzane. |
| 23 czerwca, 02:02 - 02:33 | Dostawca ręcznie zwiększa pojemność swojej bazy danych. | Podniesienie wagi do krytycznej: Ponad 30 000 naszych własnych zadań jest teraz w kolejce i czeka. Zespół publikuje krytyczną aktualizację statusu na naszej publicznej stronie statusu. |
| 23 czerwca, 04:35 - 05:05 | Aktualizacje infrastruktury po stronie dostawcy spowalniają wykonanie z powrotem do żółwiego tempa. | Wąskie gardło webhooków: Tempo przetwarzania spada. Do 05:05 identyfikujemy, że kolejka dostarczania webhooków jest głównym wąskim gardłem, które nie chce się opróżnić. |
| 23 czerwca, 08:38 | Druga fala kaskadowa: Przekierowany globalny ruch przeciąża europejski region dostawcy, całkowicie go wyłączając. | Całkowity zastój: Oba regiony po stronie dostawcy są teraz w praktyce martwe. Mamy ponad 13 000 zadań zamrożonych w locie, całkowicie zdanych na odzyskanie działania po stronie dostawcy. |
| 23 czerwca, 10:34 | Zespół po stronie dostawcy walczy o przywrócenie europejskiego regionu do działania. | Wdrożenie bezpiecznika: Gdy uświadamiamy sobie, że główna warstwa przetwarzania w tle jest całkowicie zatrzymana, nasz zespół przechodzi z mitygacji infrastruktury do obejścia architektonicznego. Wdrażamy awaryjny hotfix we wszystkich kluczowych środowiskach aplikacji i API, aby tymczasowo wyłączyć zarządzanie zadaniami asynchronicznymi. |
| 23 czerwca, 10:41 | Dostawca nadal pracuje nad zmianą rozmiaru węzłów control plane. | Natychmiastowa ulga: Obejście architektoniczne działa bezbłędnie. Omiatając zamarznięte kolejki w tle, kluczowe procesy aplikacji wracają na bezpośrednie ścieżki wykonania. Inżynieria potwierdza: „Maile znowu przepływają.” |
| 23 czerwca, 17:06 | Dostawca w końcu stabilizuje oba regiony i przywraca szybkość przetwarzania. | Kolejka opróżniona: Inżynieria potwierdza, że nasze kolejki w obu regionach całkowicie się opróżniły. Wydajność systemu wraca do normy. |
| 23 czerwca, 19:31 | Stabilność po odzyskaniu działania utrzymuje się. | Incydent rozwiązany: Systemy działają w pełni normalnie; zespół przechodzi do procesu przeglądu po incydencie. |
Najważniejsze wnioski i ocena naszego doświadczenia
Choć raport po stronie dostawcy skupiał się na dostrojeniu bazy danych i infrastrukturze klastra, nasza wewnętrzna ocena koncentruje się na łagodnej degradacji i odporności architektury.
1. Siła „kill switcha”
Decydujący moment naszego odzyskiwania działania nastąpił o 10:34 UTC. Gdy druga strefa naszego dostawcy się załamała, przeszliśmy od prób zarządzania kolejkami w tle do wdrożenia obejścia strukturalnego.
-
Obejście: Wdrażając globalną zmianę konfiguracji, aby wyłączyć zadania w tle, praktycznie odcięliśmy przewód do naszej uszkodzonej zależności. To zmusiło kluczowe transakcje użytkowników, takie jak e-maile z potwierdzeniem rezerwacji, do tymczasowego ominięcia zamarzniętego silnika w tle i przetwarzania bezpośrednio.
-
W ciągu 7 minut kluczowe funkcje biznesowe zostały całkowicie przywrócone dla naszych użytkowników, co pokazuje, że wbudowane, przełączalne ścieżki awaryjne dla głównych zewnętrznych zależności to bezdyskusyjny wymóg wysokiej dostępności.
2. Zarządzanie pułapkami współbieżności w wielu regionach
W fazie mitygacji nawigowanie po konfiguracji wieloregionalnej ujawniło nieoczekiwane ograniczenia platformy. Zadania utkwione w pośredniej fazie w regionie USA nadal zużywały globalną pojemność wykonawczą naszego konta, nawet po tym, jak skierowaliśmy aplikację do Europy.
- Kluczowe było zidentyfikowanie i wykonanie precyzyjnego masowego anulowania zablokowanej puli US o 01:10, aby uwolnić pojemność wykonawczą w nowo wybranym regionie europejskim.
3. Utwardzanie zasięgu wybuchu po stronie dostawcy
Choć nasze awaryjne obejście uratowało sytuację w krytycznych przepływach, takich jak e-maile, nadal mieliśmy ponad 13 000 zadań siedzących martwo w zamarzniętych kolejkach po stronie dostawcy, aż do pełnego odzyskania działania.
- Droga naprzód: Na przyszłość analizujemy projekt bardziej lokalnego bufora. W przypadku zadań w tle lub wychodzących webhooków rozważamy wdrożenie lekkiej wewnętrznej kolejki przejściowej, która może lokalnie przechowywać zadania podczas blackoutu po stronie dostawcy, zapewniając poprawną kolejność podczas odtwarzania.
Podsumowanie
Ostatecznie nasz zespół inżynierski skutecznie zdiagnozował złożoną pułapkę współbieżności w wielu regionach, przekierował ruch i wdrożył kreatywne obejście architektoniczne, które uratowało doświadczenie naszych użytkowników na kilka godzin przed tym, jak nasz dostawca zdołał ustabilizować swoją infrastrukturę.
Wiemy, że to był bardzo trudny moment dla zespołu Trigger.dev. Szanujemy ich i nadal mamy świetne partnerstwo. Ten wpis ma po prostu pokazać naszą stronę incydentu i to, jak zareagował nasz zespół.