Niektórzy użytkownicy mogą zobaczyć zwiększony czas oczekiwania na pracę w systemie gen2 Docker ze względu na problemy z przepustowością.
identified
Dodamy dodatkowe możliwości, aby pomóc złagodzić tę kwestię. Uwaga: Nadal widzimy opóźnienia do 20 minut na 2xlarge.
identified
Czas oczekiwania na 2xdual docker prace wracają do normy. Będziemy nadal aktualizować, jak przepustowość będzie online.
identified
Czas oczekiwania na 2xdual docker jest teraz poniżej 60 sekund.
Czas oczekiwania na inne rozmiary zasobów nie został naruszony przez ten incydent i pozostaje poniżej 10 sekund.
monitoring
Widzieliśmy pełne odzyskanie czasu oczekiwania na pracę dokerów.
resolved
Czas oczekiwania na pracę w gen2 Docker został odzyskany, a praca działa w normalnym czasie oczekiwania.
postmortem
Podsumowanie
Od 15: 44 do 20: 55 UTC 21 października klienci prowadzący Gen 2 Docker jobs widzieli zwiększony czas oczekiwania na rozpoczęcie pracy. Opóźnienia były najdłuższe na 2xlarge klasy zasobów, gdzie praca czekała do 20 minut. Incydent był spowodowany ograniczoną dostępnością instancji w chmurze, które skonfigurowaliśmy, aby zaspokoić popyt, szczególnie w przypadku 2xdual jobs.
W odpowiedzi nasz zespół inżynieryjny skonfigurował dodatkowe typy instancji, skonfigurował dodatkowe klastry Gen 2 Docker. O 20: 55 czasu oczekiwania powróciły do normy i incydent został rozwiązany.
Po rozwiązaniu tego incydentu, rozszerzyliśmy naszą flotę dokerów Gen 2 na dodatkowe obszary chmur i nadal aktywnie stajemy w tych regionach, aby zapobiec podobnym incydentom w przyszłości.
Oryginalna strona statusu znajduje się tutaj: [21 października - Zwiększony czas oczekiwania Docker gen2] (https: / / status.circleci.com / invents / 5jb50gh55gtj).
# # Tło
Kiedy CircleCI wykonuje zadanie Dockera, ustalamy je na jednej z kilku klastrów przypadków w chmurze i każda instancja jest w stanie wykonać wiele odizolowanych zadań. Planowanie pracy na instancji chmur jest klasycznym ["bin packing problem"] (https: / / en.wikipedia.org / wiki / Bin _ packing _ problem): znalezienie dostępnej pojemności, która pasuje do wymaganej klasy zasobów CPU, pamięci i pamięci. Większe klasy zasobów, takie jak 2xlarge są trudniejsze do dopasowania niż mniejsze, które pakują się razem ściślej.
Dostarczamy instancje chmur używając rankingu typów instancji. Jeśli dostawca chmur nie może dostarczyć pierwszego wyboru, wracamy do następnego typu na liście. Utrzymujemy również minimalny rozmiar floty: minimalna liczba przypadków pozostaje w toku, tak abyśmy nie rezygnowali z mocy produkcyjnych, gdy popyt jest niski. Powyżej tej minimalnej wielkości floty, dodajemy przypadki wraz ze wzrostem popytu.
Gdy nie ma wystarczającej pojemności do wykonania obciążenia pracą, kolejka, że praca aż zdolność będzie dostępna.
# Co się stało
_\ (Wszystkie czasy UTC\) _
Począwszy od 15: 44 dnia 21 października, popyt na Gen 2 2xlarge klasy zasobów gwałtownie wzrosła, i nie dostarczyliśmy dodatkowych zdolności wystarczająco szybko, aby nadążyć. Nasz zespół inżynieryjny rozpoczął śledztwo. Do 19: 25, czas oczekiwania na Gen 2 2xlarge klasy zasobów osiągnął 20 minut, a czas oczekiwania na inne klasy zasobów również wzrosła.
Do 19: 56, nasz zespół inżynieryjny skonfigurował dodatkowe typy instancji do floty Gen 2, aby uzyskać większą pojemność online, a do 19: 59 zaopatrywaliśmy te typy instancji. O 20: 11 dodaliśmy kilka dodatkowych klastrów Gen 2 i zwiększyliśmy minimalny rozmiar floty na tych klastrach.
Do 20: 35 liczba miejsc pracy w kolejce powróciła do normalnego poziomu, a do 20: 41 95% 2 x dużych miejsc pracy zaczynało się w ciągu 4 sekund. Rozwiązaliśmy ten incydent o 20: 55.
Po rozwiązaniu tego incydentu dodaliśmy dodatkowe regiony chmur dla miejsc pracy Dockera, aby zwiększyć przepustowość.
Przyszłe zapobieganie i usprawnienie procesu
Podjęliśmy już następujące kroki w celu poprawy czasu rozpoczęcia pracy, w tym pozyskiwania zdolności z większej liczby miejsc pracy, rezerwowania większej zdolności dla dużych klas zasobów oraz wdrażania szybszego zaopatrzenia.
* * Dodaliśmy dodatkowe regiony pracy Dockera. * * Niedawno dodaliśmy dodatkowe obszary chmur dla miejsc pracy maszyn, a teraz zrobiliśmy to samo dla miejsc pracy Docker.
* * Będziemy aktywnie kontynuować dodawanie dodatkowych obszarów chmur dla pracy Docker i maszyny * *.
* * Dodaliśmy dodatkowe grupy Gen 2 * *. Zkonfigurowaliśmy kilka dodatkowych klastrów Gen 2, aby szybciej planować miejsca pracy, a także aby uzyskać większą pojemność.
* * Rozszerzyliśmy zbiór typów instancji chmur, których używamy i zwiększyliśmy nasz minimalny rozmiar floty. * * Zkonfigurowaliśmy dodatkowe typy instancji. Zwiększyliśmy również minimalny rozmiar floty dla Gen 2, aby zaspokoić obecny popyt bazowy.
* * Zmodyfikowaliśmy nasz harmonogram zadań, aby ustalić priorytety planowania większych klas zasobów. * * Zmieniliśmy sposób, w jaki planujemy miejsca pracy, aby zrównoważyć czas oczekiwania w sposób bardziej sprawiedliwy we wszystkich klasach zasobów oraz aby bardziej efektywnie pakować miejsca pracy w dostępne przypadki.
# # Wnioski
Doświadczenie Klienta jest naszym najwyższym priorytetem i zobowiązujemy się do ciągłego zwiększania niezawodności naszych systemów, aby dopasować zaufanie naszych klientów do nas. Dziękujemy naszym klientom za cierpliwość, podczas gdy nasz zespół pracował nad rozwiązaniem tego incydentu.
Prosimy o kontakt z naszym zespołem wsparcia w razie jakichkolwiek pytań lub wątpliwości.
Zwiększony czas oczekiwania na pracę w systemie macOS na m4pro.big
Początek 20 października 2026 15:58 UTC · 2h 16m
IssuesDrobny incydent
Dotknięte komponenty
macOS Jobs
investigating
Widzimy zwiększony czas oczekiwania na niektóre zadania z MacOS używając klasy m4pro.large zasobów. Prowadzimy śledztwo i wkrótce dostarczymy nowe informacje. Dziękuję za cierpliwość.
monitoring
Klienci wykonujący zadania z MacOS w klasie m4pro.large nadal widzą zwiększony czas oczekiwania, a niektóre miejsca pracy czekają do 30 minut. Monitorujemy to i wkrótce podzielimy się kolejną aktualizacją.
monitoring
Czasy oczekiwania dla m4pro.large są nadal podwyższone ze względu na duże zapotrzebowanie. Wszystkie m4pro.medium są normalne. Aktywnie monitorujemy, doceniamy cierpliwość.
monitoring
Czas oczekiwania na pracę z MacOS w klasie m4pro.large zasobów wracają do normy. Jobs przy użyciu Xcode 27.0 teraz czeka średnio ~ 3,5 minuty, w dół z około ~ 40 minut na szczycie. Praca przy użyciu Xcode 26.6 i 26.4.1 nadal działa przez zaległości, który jest clearing. Czas oczekiwania na m4pro.medium jest w normie. Będziemy dzielić się kolejną aktualizacją, jak tylko będziemy monitorować.
resolved
Czas oczekiwania na pracę w systemie macOS w klasie m4pro.large powraca do normy. Dziękujemy za cierpliwość, podczas gdy zaległości oczyszczone.
Opóźnia rozpoczęcie pracy w systemie Mac, który używa Xcode 26.6.0
Początek 14 października 2026 14:47 UTC · 1h 13m
IssuesDrobny incydent
Dotknięte komponenty
macOS Jobs
investigating
Od około 14: 00 UTC klienci pracujący w systemie Mac OS, którzy używają Xcode 26.6.0 w klasie dużych zasobów M4 Pro, doświadczają opóźnień w rozpoczęciu pracy. Czas oczekiwania wynosi 30 minut lub więcej.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie badają. Dostarczymy kolejną aktualizację do 15: 30 UTC.
identified
Opóźnienia w uruchamianiu zadań z MacOS, które używają Xcode 26.6.0, odzyskały wartość. Od około 15: 11 UTC, zadania w systemie MacOS, które używają Xcode 26.4, doświadczają opóźnień rozpoczynających się, z czasem oczekiwania około 30 minut.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują nad rozwiązaniem tego problemu. Dostarczymy kolejną aktualizację do 15: 45 UTC.
resolved
W dniach od około 14: 00 UTC do 15: 51 UTC w dniu 14 października klienci realizujący zadania z zakresu MacOS, którzy korzystają z Xcode 26.6.0 lub Xcode 26.4 doświadczyli opóźnień w rozpoczęciu pracy. Od około 14: 00 UTC, miejsc pracy, które używają Xcode 26.6.0 w klasie dużych zasobów M4 Pro czekał 30 minut lub więcej, aby rozpocząć, a te opóźnienia odzyskane około 15: 12 UTC. Od około 15: 11 UTC, zadania, które używają Xcode 26.4 czekał około 30 minut, aby rozpocząć.
Kwestia została rozwiązana i cała jej funkcjonalność wróciła do normy. Dziękujemy za cierpliwość, podczas gdy nasz zespół pracował nad wdrożeniem poprawki.
Nastąpiło opóźnienie w naszej infrastrukturze danych, co spowodowało opóźnienia w budowaniu danych, a niektóre powiadomienia stały się widoczne. Pracujemy nad łagodzeniem skutków.
identified
Co ma wpływ:
Klienci uruchamiają rurociągi, a klienci polegają na wychodzących hakach i e-mailach oraz powiadomieniach Slack.
Czego można się spodziewać?
Od 11: 15 UTC:
- Rurociągi są nadal tworzone, podczas gdy jest to w toku, ale jeszcze nie przetworzone, więc pobieranie może skutkować duplikatami rurociągów.
- Nie wysyła się wychodzących haczyków i powiadomień transakcyjnych (Slack i email).
- Stan rurociągu może nie być widoczny.
- Dane dotyczące opłat za użytkowanie na stronie Project Usage będą nieświeże.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują nad rozwiązaniem tego problemu.
Następna aktualizacja:
Dostarczymy kolejną aktualizację do 13: 30 UTC.
identified
Między 11: 15 UTC a około 13: 00 UTC, rurociągi zostały utworzone, ale nie zostały przetworzone, a wychodzące haki i powiadomienia transakcyjne (Slack i e-mail) nie zostały wysłane.
Co ma wpływ:
Klienci uruchamiają rurociągi, a klienci polegają na wychodzących hakach i e-mailach oraz powiadomieniach Slack.
Czego można się spodziewać?
- Od około 13: 00 UTC, rurociągi są przetwarzane ponownie i rozpoczynają pracę.
- Większość miejsc pracy rozpoczyna się obecnie w ciągu około 4 minut, a niektóre czekają do około 10 minut. Rurociągi uruchomione w trakcie incydentu są nadal przetwarzane i mogą trwać dłużej.
- Haki i powiadomienia zostały wznowione.
- Rurociągi są nadal przetwarzane z zaległości, więc pobieranie może skutkować duplikatami rurociągów.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują nad rozwiązaniem tego problemu.
Następna aktualizacja:
Dostarczymy kolejną aktualizację do 14: 00 UTC.
identified
Od 11: 15 UTC, klienci doświadczyli zakłóceń w rurociągach i powiadomień. Między 11: 15 UTC a około 13: 00 UTC, rurociągi zostały utworzone, ale nie zostały przetworzone, a wychodzące haki i powiadomienia transakcyjne (Slack i e-mail) nie zostały wysłane.
Co ma wpływ
Klienci pracujący i pracujący oraz klienci przeglądający dane dotyczące użytkowania na stronie Project Usage.
Czego można się spodziewać?
- Rurociągi są ponownie przetwarzane, łącznie z rurami uruchomionymi podczas incydentu.
- Od około 13: 25 UTC, przepływy pracy i miejsca pracy zaczynają się z rosnącymi opóźnieniami, jak pracujemy przez zaległości. Większość miejsc pracy rozpoczyna się obecnie w ciągu około 10 minut, a niektóre czekają do około 25 minut.
- Spodziewamy się pracować przez ten zaległości około 14: 35 UTC.
- Przepływy z rurociągów uruchomionych w trakcie incydentu nadal czekają na rozpoczęcie, więc pobieranie może skutkować podwójnym przepływem pracy.
- Dane dotyczące opłat za korzystanie ze strony Project Usage są obecnie nieaktualne.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują nad rozwiązaniem tego problemu.
Następna aktualizacja
Dostarczymy kolejną aktualizację do 14: 30 UTC.
identified
Od 11: 15 UTC, klienci doświadczyli zakłóceń w rurociągach i powiadomień. Między 11: 15 UTC a około 13: 00 UTC, rurociągi zostały utworzone, ale nie zostały przetworzone, a wychodzące haki i powiadomienia transakcyjne (Slack i e-mail) nie zostały wysłane.
Co ma wpływ
Klienci pracujący i pracujący oraz klienci przeglądający dane dotyczące użytkowania na stronie Project Usage.
Czego można się spodziewać?
- Opóźnienie rozpoczęcia pracy i miejsc pracy ulegają poprawie. Większość miejsc pracy zaczyna się w ciągu około 3 minut, w dół od około 10 minut o 13: 50 UTC.
- Niektóre przepływy pracy z rurociągów uruchomionych podczas incydentu nadal czekają do około 40 minut, aby rozpocząć.
- Praca przez zaległości trwa nieco dłużej niż oczekiwano. Oczekujemy, że oczyścimy go o 14: 45 UTC.
- Przepływy z rurociągów uruchomionych w trakcie incydentu nadal czekają na rozpoczęcie, więc pobieranie może skutkować podwójnym przepływem pracy.
- Dane dotyczące opłat za korzystanie ze strony Project Usage są obecnie nieaktualne.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują nad rozwiązaniem tego problemu.
Następna aktualizacja
Dostarczymy kolejną aktualizację do 15: 00 UTC.
identified
Od 11: 15 UTC, klienci doświadczyli zakłóceń w rurociągach i powiadomień. Między 11: 15 UTC a około 13: 00 UTC, rurociągi zostały utworzone, ale nie zostały przetworzone, a wychodzące haki i powiadomienia transakcyjne (Slack i e-mail) nie zostały wysłane. Między 13: 00 UTC a 14: 40 UTC, przepływy pracy i miejsca pracy zaczęły się z opóźnieniami, podczas gdy my pracowaliśmy przez zaległości.
Co ma wpływ
Klienci pracujący i pracujący oraz klienci przeglądający dane dotyczące użytkowania na stronie Project Usage.
Czego można się spodziewać?
- Backlog przepływów pracy z rurociągów uruchomionych podczas incydentu oczyszczone około 14: 40 UTC.
- Większość prac zaczyna się w ciągu około 30 sekund, a niektóre czekają do około 3 minut.
- Dane dotyczące opłat za korzystanie ze strony Project Usage są obecnie nieaktualne.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie nadal pracują nad podstawowym zagadnieniem.
Następna aktualizacja
Dostarczymy kolejną aktualizację do 15: 10 UTC.
monitoring
Od 11: 15 UTC, klienci doświadczyli zakłóceń w rurociągach i powiadomień. Między 11: 15 UTC a około 13: 00 UTC, rurociągi zostały utworzone, ale nie zostały przetworzone, a wychodzące haki i powiadomienia transakcyjne (Slack i e-mail) nie zostały wysłane. Między 13: 00 UTC a 14: 40 UTC, przepływy pracy i miejsca pracy zaczęły się z opóźnieniami, podczas gdy my pracowaliśmy przez zaległości.
Co ma wpływ
Klienci pracujący i pracujący oraz klienci przeglądający dane dotyczące użytkowania na stronie Project Usage.
Czego można się spodziewać?
- Backlog rurociągów i przepływów roboczych z incydentu został oczyszczony.
- Od około 14: 45 UTC, większość przepływów pracy i miejsc pracy zaczynają się w ciągu około 15 sekund, a czasy rozpoczęcia nadal wracają do normy.
- Dane dotyczące opłat za korzystanie ze strony Project Usage są obecnie nieaktualne.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie monitorują wyzdrowienie.
Następna aktualizacja
Dostarczymy kolejną aktualizację do 15: 20 UTC.
monitoring
Od 11: 15 UTC, klienci doświadczyli zakłóceń w rurociągach i powiadomień. Między 11: 15 UTC a około 13: 00 UTC, rurociągi zostały utworzone, ale nie zostały przetworzone, a wychodzące haki i powiadomienia transakcyjne (Slack i e-mail) nie zostały wysłane. Między 13: 00 UTC a 14: 40 UTC, przepływy pracy i miejsca pracy zaczęły się z opóźnieniami, podczas gdy my pracowaliśmy przez zaległości.
Co ma wpływ
Klienci przeglądają gazociągi, przepływy pracy i miejsca pracy w UI CircleCI, a klienci przeglądają dane dotyczące wykorzystania na stronie Project Usage.
Czego można się spodziewać?
- Przepływy pracy i praca na czas.
- Interfejs CircleCI jest 30 minut do tyłu. Pojawienie się nowych przepływów pracy i zmian stanu może trwać tak długo.
- Nasi inżynierowie aktywnie pracują nad przyspieszeniem procesu przetwarzania, aby UI mogło nadrobić zaległości.
- Proszę unikać pobierania przepływów roboczych, które nie pojawiają się jeszcze w UI, ponieważ może to tworzyć duplikaty.
- Dane dotyczące opłat za korzystanie ze strony Project Usage są obecnie nieaktualne.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują nad zmniejszeniem tego opóźnienia.
Następna aktualizacja
Dostarczymy kolejną aktualizację do 16: 00 UTC.
monitoring
Od 11: 15 UTC, klienci doświadczyli zakłóceń w rurociągach i powiadomień. Między 11: 15 UTC a około 13: 00 UTC, rurociągi zostały utworzone, ale nie zostały przetworzone, a wychodzące haki i powiadomienia transakcyjne (Slack i e-mail) nie zostały wysłane. Między 13: 00 UTC a 14: 40 UTC, przepływy pracy i miejsca pracy zaczęły się z opóźnieniami, podczas gdy my pracowaliśmy przez zaległości.
Co ma wpływ
Klienci prowadzący przepływy pracy i miejsca pracy, klienci przeglądający rurociągi, przepływy pracy i miejsca pracy w UI CircleCI oraz klienci przeglądający dane dotyczące wykorzystania na stronie Project Usage.
Czego można się spodziewać?
- Od około 15: 15 UTC przepływy pracy i miejsca pracy zaczynają się od coraz większych opóźnień. Większość miejsc pracy rozpoczyna się obecnie w ciągu około 4 minut, a niektóre czekają do około 20 minut.
- Interfejs CircleCI pozostaje średnio około 30 minut w tyle, a niektóre aktualizacje trwają dłużej. Pojawienie się nowych przepływów pracy i zmian stanu może trwać tak długo.
- Proszę unikać pobierania przepływów roboczych, które nie pojawiają się jeszcze w UI, ponieważ może to tworzyć duplikaty.
- Dane dotyczące opłat za korzystanie ze strony Project Usage są obecnie nieaktualne.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują nad zmniejszeniem tych opóźnień.
Następna aktualizacja
Dostarczymy kolejną aktualizację do 16: 30 UTC.
monitoring
Od 11: 15 UTC, klienci doświadczyli zakłóceń w rurociągach i powiadomień. Między 11: 15 UTC a około 13: 00 UTC, rurociągi zostały utworzone, ale nie zostały przetworzone, a wychodzące haki i powiadomienia transakcyjne (Slack i e-mail) nie zostały wysłane. Między 13: 00 UTC a 14: 40 UTC, przepływy pracy i miejsca pracy zaczęły się z opóźnieniami, podczas gdy my pracowaliśmy przez zaległości. Od około 15: 15 UTC, przepływy pracy i miejsca pracy znowu zaczynają się z opóźnieniami.
Co ma wpływ
Klienci prowadzący przepływy pracy i miejsca pracy, klienci przeglądający rurociągi, przepływy pracy i miejsca pracy w UI CircleCI oraz klienci przeglądający dane dotyczące wykorzystania na stronie Project Usage.
Czego można się spodziewać?
- Opóźnienie rozpoczęcia pracy i miejsc pracy przestało rosnąć i zaczyna się zmniejszać. Większość prac zaczyna się w ciągu około 4 minut, a niektóre czekają do około 25 minut.
- Interfejs CircleCI jest teraz około 20 minut do tyłu, od około 30 minut. Pojawienie się nowych przepływów pracy i zmian stanu może trwać tak długo.
- Proszę unikać pobierania przepływów roboczych, które nie pojawiają się jeszcze w UI, ponieważ może to tworzyć duplikaty.
- Dane dotyczące opłat za korzystanie ze strony Project Usage są obecnie nieaktualne.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują nad zmniejszeniem tych opóźnień.
Następna aktualizacja
Dostarczymy kolejną aktualizację do 17: 00 UTC.
monitoring
Od 11: 15 UTC, klienci doświadczyli zakłóceń w rurociągach i powiadomień. Między 11: 15 UTC a około 13: 00 UTC, rurociągi zostały utworzone, ale nie zostały przetworzone, a wychodzące haki i powiadomienia transakcyjne (Slack i e-mail) nie zostały wysłane. Między 13: 00 UTC a 14: 40 UTC, przepływy pracy i miejsca pracy zaczęły się z opóźnieniami, podczas gdy my pracowaliśmy przez zaległości. Od około 15: 15 UTC, przepływy pracy i miejsca pracy znowu zaczynają się z opóźnieniami.
Co ma wpływ
Klienci prowadzący przepływy pracy i miejsca pracy, klienci przeglądający rurociągi, przepływy pracy i miejsca pracy w UI CircleCI oraz klienci przeglądający dane dotyczące wykorzystania na stronie Project Usage.
Czego można się spodziewać?
- Opóźnienie rozpoczęcia pracy i miejsc pracy utrzymuje się na stałym poziomie. Większość miejsc pracy zaczyna się w ciągu około 4 minut, a niektóre czekają do około 8 minut, w dół od około 25 minut.
- Interfejs CircleCI pozostaje średnio około 20 minut w tyle, a niektóre aktualizacje trwają dłużej. Pojawienie się nowych przepływów pracy i zmian stanu może trwać tak długo.
- Proszę unikać pobierania przepływów roboczych, które nie pojawiają się jeszcze w UI, ponieważ może to tworzyć duplikaty.
- Dane dotyczące opłat za korzystanie ze strony Project Usage są obecnie nieaktualne.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują nad zmniejszeniem tych opóźnień.
Następna aktualizacja
Dostarczymy kolejną aktualizację do 17: 30 UTC.
identified
Od 11: 15 UTC, klienci doświadczyli zakłóceń w rurociągach i powiadomień. Między 11: 15 UTC a około 13: 00 UTC, rurociągi zostały utworzone, ale nie zostały przetworzone, a wychodzące haki i powiadomienia transakcyjne (Slack i e-mail) nie zostały wysłane. Między 13: 00 UTC a 14: 40 UTC, przepływy pracy i miejsca pracy zaczęły się z opóźnieniami, podczas gdy my pracowaliśmy przez zaległości. Od około 15: 15 UTC, przepływy pracy i miejsca pracy znowu zaczynają się z opóźnieniami.
Co ma wpływ
Klienci uruchamiający gazociągi oraz działający przepływ pracy i miejsc pracy, klienci przeglądający gazociągi, przepływy pracy i miejsca pracy w UI CircleCI oraz klienci przeglądający dane dotyczące użytkowania na stronie Project Usage.
Czego można się spodziewać?
- Od około 17: 00 UTC opóźnienia znacznie wzrosły. Większość miejsc pracy zajmuje teraz około 12 minut, a niektóre czekają do około 30 minut.
- Od 17: 15 UTC, niektóre prace nie zaczynają się.
- Rurociągi są przetwarzane wolniej, więc niektóre mogą trwać dłużej.
- Interfejs CircleCI jest ponad godzinę do tyłu. Pojawienie się nowych przepływów pracy i zmian stanu może trwać tak długo.
- Proszę unikać pobierania przepływów roboczych, które nie pojawiają się jeszcze w UI, ponieważ może to tworzyć duplikaty.
- Dane dotyczące opłat za korzystanie ze strony Project Usage są obecnie nieaktualne.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują nad rozwiązaniem tego problemu.
Następna aktualizacja
Dostarczymy kolejną aktualizację do 18: 00 UTC.
identified
Od 11: 15 UTC, klienci doświadczyli zakłóceń w rurociągach i powiadomień. Między 11: 15 UTC a około 13: 00 UTC, rurociągi zostały utworzone, ale nie zostały przetworzone, a wychodzące haki i powiadomienia transakcyjne (Slack i e-mail) nie zostały wysłane. Między 13: 00 UTC a 14: 40 UTC, przepływy pracy i miejsca pracy zaczęły się z opóźnieniami, podczas gdy my pracowaliśmy przez zaległości. Od około 15: 15 UTC, przepływy pracy i miejsca pracy znowu zaczynają się z opóźnieniami.
Co ma wpływ
Klienci uruchamiający gazociągi oraz działający przepływ pracy i miejsc pracy, klienci przeglądający gazociągi, przepływy pracy i miejsca pracy w UI CircleCI oraz klienci przeglądający dane dotyczące użytkowania na stronie Project Usage.
Czego się spodziewać?
- Od około 17: 00 UTC, widzimy wzrost opóźnień. Większość miejsc pracy zajmuje teraz około 25 minut, a niektóre czekają do około godziny.
- Od około 17: 15 UTC, niektóre przepływy pracy w toku nie powiodły się i niewielka liczba miejsc pracy nie rozpoczyna się.
- Nowe rurociągi są w kolejce, a start trwa dłużej.
- Interfejs CircleCI jest ponad godzinę do tyłu. Pojawienie się nowych przepływów pracy i zmian stanu może trwać tak długo.
- Proszę unikać pobierania przepływów roboczych, które nie pojawiają się jeszcze w UI, ponieważ może to tworzyć duplikaty.
- Dane dotyczące opłat za korzystanie ze strony Project Usage są obecnie nieaktualne.
Nasi inżynierowie nadal pracują nad rozwiązaniem problemu.
Następna aktualizacja
Dostarczymy kolejną aktualizację do 18: 30 UTC.
identified
Co się zmieniło od ostatniej aktualizacji?
* Interfejs CircleCI jest o godzinę do tyłu i do około 90 minut na niektóre aktualizacje. Przepływy pracy i miejsca pracy mogą być już uruchomione, lub mogą być uruchomione, nawet jeśli Interfejs pokazuje je jako nie rozpoczęte lub nie pokazuje ich w ogóle.
* Roboty, które są uruchomione, zaczynają się szybciej. Większość zaczyna się teraz w ciągu około 15 minut, w dół od około 28 minut, choć niektóre nadal czekają ponad godzinę.
* Nowe rurociągi są coraz bardziej opóźnione.
* Niektóre przepływy pracy nadal zawodzą. Przepływy robocze, które nie mogły być przetwarzane w czasie, są oznaczone jako nieskuteczne.
* Należy unikać pobierania przepływów roboczych, które nie pojawiają się jeszcze w UI, ponieważ może to tworzyć duplikaty.
Nadal trwa:
Dane dotyczące opłat za użytkowanie na stronie Project Usage są nieaktualne.
Następna aktualizacja
Dostarczymy kolejną aktualizację do 19: 00 UTC.
identified
Co się zmieniło od ostatniej aktualizacji?
* Praca zaczyna się szybciej. Większość zaczyna się teraz w ciągu 8 minut, spada od około 15 minut, a najdłuższe oczekiwania spadły z ponad godziny do około 45 minut.
* Interfejs CircleCI zaczyna nadrabiać zaległości, ale wciąż jest w tyle. Przepływy pracy i miejsca pracy mogą być już uruchomione, lub mogą być uruchomione, nawet jeśli Interfejs pokazuje je jako nie rozpoczęte lub nie pokazuje ich w ogóle.
* Rurociągi są przetwarzane szybciej, ale nowe rurociągi są nadal opóźnione.
Nadal trwa
* Niektóre przepływy pracy i miejsca pracy nadal zawodzą.
* Należy unikać pobierania przepływów roboczych, które nie pojawiają się jeszcze w UI, ponieważ może to tworzyć duplikaty.
* Dane o opłatach za korzystanie ze strony Project Usage są nieaktualne.
Następna aktualizacja
Dostarczymy kolejną aktualizację do 19: 30 UTC.
identified
Od naszej ostatniej aktualizacji, zadania zaczynają się szybciej: większość zaczyna się teraz w ciągu około 6 minut, w dół od około 8 minut. Interfejs CircleCI nadrabia zaległości, ale nadal jest godzinę do tyłu. Nowe rurociągi są przetwarzane w miarę ich przybycia.
Jobs może już działać, nawet jeśli UI jeszcze ich nie pokazuje, więc proszę unikać pobierania przepływów roboczych, które nie pojawiają się w UI.
Dostarczymy kolejną aktualizację do 20: 00 UTC.
identified
Liczba miejsc pracy zaczyna się szybciej, a mniej spada: większość miejsc pracy zaczyna się w ciągu około 4 minut, spada od około 6 minut, a najdłuższe oczekiwania spadły z około 30 minut do około 20 minut.
Rurociągi z wcześniejszego zdarzenia są obecnie przepracowywane.
Interfejs CircleCI jest nadal w tyle, a niektóre starsze aktualizacje mogą zająć dłużej, aby się pojawić. Jobs może już działać, nawet jeśli UI jeszcze ich nie pokazuje, więc proszę unikać pobierania przepływów roboczych, które nie pojawiają się w UI.
Dostarczymy kolejną aktualizację do 20: 30 UTC.
identified
Od około 20: 48 UTC nie rozpoczynają się nowe przepływy pracy i miejsca pracy. Tymczasowo wstrzymaliśmy się z rozpoczęciem nowej pracy, aby nasze systemy mogły nadrobić zaległości w pracy już w toku, w tym opóźnione aktualizacje UI CircleCI i API. Starsze aktualizacje pojawiają się teraz w UI i API, jak ten zaległości oczyszcza. Nowe rurociągi są nadal akceptowane i w kolejce
Proszę unikać pobierania rurociągów lub przepływów roboczych w tym czasie, ponieważ może to utworzyć duplikaty po wznowieniu pracy.
Dostarczymy kolejną aktualizację do 22: 00 UTC.
identified
Od naszej ostatniej aktualizacji, większość rurociągów, które zostały opóźnione wcześniej w incydencie zostały przetworzone, a ich przepływy pracy są w kolejce do rozpoczęcia. Nowe przepływy pracy i miejsca pracy pozostają wstrzymane, a my przygotowujemy się do bezpiecznego wznowienia pracy. Opóźnione aktualizacje nadal pojawiają się w Interfejsie CircleCI i API.
Proszę nadal unikać pobierania rurociągów lub przepływów roboczych, ponieważ może to utworzyć duplikaty po wznowieniu pracy.
Dostarczymy kolejną aktualizację do 22: 30 UTC.
identified
Od czasu ostatniej aktualizacji zaczęliśmy stopniowo wznawiać pracę, a niektóre w kolejce przepływy pracy i miejsca pracy zaczynają się od nowa. Większość pracy w kolejce nadal czeka, a miejsca pracy, które się zaczynają, mogły czekać ponad godzinę. Ostrożnie zwiększamy tempo, aby uniknąć przeciążenia naszych systemów. Opóźnione aktualizacje nadal pojawiają się w Interfejsie CircleCI i API.
Prosimy o dalsze unikanie pobierania rurociągów lub przepływów roboczych, ponieważ może to tworzyć duplikaty w kolejce pracy ponownie.
Dostarczymy kolejną aktualizację do 23: 00 UTC.
identified
Rozpoczęło się wiele szeregowych przepływów pracy i miejsc pracy, a Interfejs Internetowy CircleCI i API nadrabiają zaległości i pokazują aktualizacje zwykle z nielicznymi opóźnieniami. Kontynuujemy pracę w kolejce. Jobs z kolejki może czekać około godziny lub więcej, aby rozpocząć, a niektóre zadania Linux czeka do około 10 minut na pojemność.
Proszę nadal unikać ściągania podczas pracy w kolejce w dalszym ciągu przetwarzać.
Dostarczymy kolejną aktualizację do 23: 30 UTC.
identified
Nadal pracujemy nad znaczącym zaleceniem w kolejce przepływów pracy i miejsc pracy. Czasy oczekiwania się poprawiają, ale pozostają dłuższe niż zwykle, a niektóre miejsca pracy trwały ponad godzinę. Interfejs CircleCI i API pozostają aktualne. Proszę unikać pobierania rurociągów lub przepływów roboczych podczas usuwania zaległości, ponieważ może to tworzyć duplikaty. Dostarczymy kolejną aktualizację do 00: 00 UTC.
identified
Od naszej ostatniej aktualizacji, zaległości w kolejce przepływów pracy i miejsc pracy został oczyszczony, od około 23: 47 UTC. Przepływy pracy i miejsca pracy zaczynają się w ciągu kilku sekund, a Interfejs CircleCI i API są aktualne. Dokładnie monitorujemy nasze systemy, aby zapewnić ich stabilność. Dostarczymy kolejną aktualizację do 00: 30 UTC.
identified
Przepływy pracy i miejsca pracy nadal zaczynają się normalnie, w ciągu kilku sekund, i CircleCI Interfejs i API pozostają aktualne. Powiadomienia o skażeniu i e-mailu opóźnione wcześniej w incydencie są nadal dostarczane.
Dane dotyczące opłat za użytkowanie na stronie Project Usage są nieaktualne.
Nadal uważnie monitorujemy nasze systemy i dostarczymy kolejną aktualizację do 01: 15 UTC.
monitoring
Przepływy pracy i miejsca pracy rozpoczynają się i pracują normalnie, a Interfejs CircleCI i API są aktualne. Kontynuujemy ścisłą obserwację naszych systemów, aby zapewnić ich stabilność.
Dostarczymy kolejną aktualizację do 02: 00 UTC.
resolved
Między 11: 15 UTC a 23: 47 UTC w dniu 9 października klienci doświadczyli opóźnień i awarii w zakresie rurociągów, przepływów pracy i miejsc pracy, wraz z opóźnieniami w zakresie UI CircleCI, API i powiadomień.
Od 11: 15 do około 13: 00 UTC, rurociągi zostały utworzone, ale nie przetworzone, a wychodzące haki i Slack e-mail powiadomienia nie zostały wysłane. Od około 13: 00 do 14: 40 UTC, przepływy pracy i miejsca pracy zaczęły się z opóźnieniami podczas pracy przez zaległości.
Od około 15: 15 do 20: 48 UTC, przepływy pracy i miejsca pracy zaczęły się z rosnącymi opóźnieniami, do około godziny, a CircleCI UI i API spadły do około 2 godzin. W tym czasie niektóre miejsca pracy nie rozpoczęły się, a niektóre niepostępowe przepływy pracy zawiodły.
Od 20: 48 do około 22: 10 UTC, tymczasowo wstrzymaliśmy rozpoczynanie nowych przepływów pracy i miejsc pracy, aby nasze systemy mogły się odzyskać. Nowe rurociągi zostały zaakceptowane i w kolejce w tym czasie. Od około 22: 10 do 23: 47 UTC, kolejki pracy i miejsc pracy wznowione i zostały przetworzone. Niektórzy z nich czekali do około 2 godzin.
Kwestia została rozwiązana i cała jej funkcjonalność wróciła do normy. Dane o opłatach za korzystanie ze strony Project Usage nie są jeszcze aktualne i będą aktualizowane, gdy nasze dane zostaną uzupełnione. Klienci, których praca nie powiodła się w tym oknie, mogą wznowić pracę. Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracowali nad wdrożeniem poprawki.
postmortem
## Summary
Between 11:15 UTC and 23:47 UTC on October 9, CircleCI customers experienced hours-long delays and failures across pipelines, workflows and jobs, along with delays in the CircleCI UI, API and notifications.
* From 11:15 to 13:00 UTC, pipelines were created but not processed, and outbound webhooks and Slack and email notifications were not sent.
* From 13:00 to 14:40 UTC, workflows and jobs started with delays while we worked through the backlog.
* From 15:15 to 20:48 UTC, workflows and jobs started with increasing delays, of up to about an hour, and the CircleCI UI and API fell behind by up to about 2 hours. During this time, some jobs failed to start and some in-progress workflows failed.
* From 20:48 to 22:10 UTC, we temporarily paused starting new workflows and jobs so our systems could recover. New pipelines were accepted and queued during this time.
* From 22:10 to 23:47 UTC, queued workflows and jobs resumed and were successfully processed. Some of them had waited up to about 2 hours.
* By 23:47, the incident was mitigated.
The status page for this incident can be found at [October 9 - Delay in data appearing in UI and API](https://status.circleci.com/incidents/6cfhhlr4rmm0). Customers experienced a similar incident earlier in the week at [October 6 - Delays in pipelines, workflows, UI data, and notifications](https://status.circleci.com/incidents/z4hbq8h49j8c).
Multiple CircleCI services use Temporal backed by Postgres as a reliable queueing mechanism, and both incidents had the same cause: the rate of writes to Temporal's Postgres instance were faster than Postgres’s transaction log could archive those writes. In both cases, this caused multi-hour delays in processing both pipelines and status notifications.
We evaluated several mitigations, then paused new workflow starts so the system could recover safely, and ramped back up gradually. We then throttled work back up until our systems returned to normal.
To permanently resolve the bottleneck, we have split work across multiple Temporal instances, each with its own independent database and worker clusters, and we load-balance across them. We had already scheduled infrastructure work starting the week of October 12 that would have removed this exact bottleneck and prevented these incidents. So starting 19:11 on October 9 our engineering team implemented, tested, and rolled out a simpler version of these changes within a few hours. We further added new alerting and tuned the underlying databases for better performance under high load.
Customers whose jobs failed during this window may rerun them.
## Background
To run customer jobs, CircleCI executes a series of steps: we accept customer pipelines; we assign jobs for those pipelines to workers; we deliver status updates for those pipelines and jobs; and we charge customers for the credits those jobs consume. Each of these steps is implemented by an independent service, with reliable queues in between.
Historically we have implemented these reliable queues with RabbitMQ on top of durable storage, with exponential backoff and dead letter queues for reliability. Over the last year, we have increasingly reimplemented our reliable queues on [Temporal](https://temporal.io/), which provides far better durability and reliability guarantees over a simpler and more powerful programming model. Our build service \(which turns a pipeline config into an executable plan\), our workflow orchestrator service \(which distributes tasks onto workers\), our notification service \(which delivers status updates\), and our charging service \(which charges customers for credits\) all now use Temporal.
Temporal stores the state for its workflows and activities \(called “history”\) in a database, and this is the only component in a Temporal instance that is synchronous and stateful. As a consequence, a Temporal instance’s ability to accept and execute workflows is dependent on the write rate of its backing database. We have also configured Temporal to delete completed workflows and activities from its history 3 days after they complete.
At the time of this incident, we used a single clustered Temporal instance backed by a Multi-AZ Postgres RDS instance for all of these reliable queues. While a Multi-AZ RDS instance is resilient to zone failures, it maintains database consistency via a single write-ahead-log \(WAL\). At the time we had configured our Postgres instance to store its WAL on a Dedicated Log Volume \(DLV\) so log writes did not compete with data writes. The database archives the log continuously to backup storage, and it can only reuse space on the volume after the log has been archived. If the database writes logs faster than it archives, the volume fills and Postgres has no space to the write its WAL log. Then the database stops accepting incoming writes and goes entirely read-only. An RDS DLV is limited to 1TB of storage and 3000 IOPS and per AWS these limits are hardcoded and cannot be increased.
## What Happened
_\(All times UTC\)_
One of the contributing factors to the October 6 incident was that we were processing a high rate of Temporal history deletions at the same time as incoming work, which in turn put pressure on the backing database. To resolve the October 6 incident, we changed cleanup settings on Temporal’s largest tables and moved the transaction log back to its dedicated volume. These changes eliminated the major source of transaction log writes, but did not consider the additional log writes from scheduled deletions. Because we have configured Temporal to delete completed workflows and activities from its history 3 days after they complete, the October 6 history was scheduled to be deleted on October 9.
Starting at 08:00 on October 9, Temporal began processing those scheduled deletions, and as a consequence free space on the Postgres DLV began dropping precipitously, from 0.8TB at 08:00 to 0.1TB by 10:10. Our monitoring alerted at 10:28 and we declared an incident at 10:31. While our infrastructure team was investigating, at 11:15 the DLV ran out of space and the Postgres instance went read-only. This stopped all Temporal processing in its tracks.
At 11:42, we restarted Postgres to move the WAL log from the DLV onto the data volume and use the spare disk space and IOPS there. This maneuver had mitigated the incident on October 6, and we knew it would take roughly 60 minutes.
While the database was restarting, we began implementing several load-shedding techniques upstream of Temporal:
* We began investigating whether we should shed incoming workloads altogether to keep the rest moving, but ultimately decided that this would provide no value.
* At 12:29, we flagged off credit charging updates, which represented 12% of Temporal activities. This left the Pipeline Usage page with stale charging data, until we would backfill it, but would not lose data or prevent pipelines from running.
At 12:59, the database was back up and began processing work that had queued since 11:15 and by 14:40, this backlog had cleared and jobs were starting on time. However, by 15:15, delays returned as database’s routing cleanup had fallen far behind on the tables Temporal uses to track queued and scheduled work. Those tables normally hold tens of thousands of deleted rows awaiting cleanup, but by late afternoon, they held tens of millions of rows. Every Temporal operation had to read past those rows, so the database spent much more processing time on each one and Temporal ran slower. This resulted in customers continuing to see hour-long delays in starting pipelines and in status updates.
For the next several hours we attempted various mitigations, including:
* Manipulating Temporal configuration values to reduce database pressure. This had minimal effect.
* Running manual vacuum jobs to clean up dead rows in Postgres. This ended up competing for CPU with queries themselves, and was ultimately counterproductive. We cancelled them at 17:45 to relieve the pressure on the database load.
* We began trying to move all of the notification usecases to a separate Temporal instance. This represented 18% of Temporal activities. We successfully finished moving notifications by 17:07.
* At 17:16, we successfully implemented an optimization in our representation of pipeline state, which reduced it by 5%. That in turn reduced the size of database writes and therefore data pressure on the Postgres WAL log.
None of these fully mitigated the issue.
By 20:48, we realized that Postgres was now thrashing on database CPU and was no longer bottlenecked on log writes. We further realized that our upstream systems were both submitting new work and also retrying work that had earlier been submitted and failed. Recognizing that we were in a classic retry storm, we paused all incoming and retry work and let it queue up, in order to allow the database to fully complete in-process work. We then slowly throttled up queued work from 22:07 to keep the database at a sustainable load.
This fully succeeded by 23:47 when all queued work had started, and we closed the incident at 02:08 on October 10.
## Future Prevention and Process Improvement
### Multiple Temporal Instances
In parallel with incident mitigation and resolution, starting at 19:11 on October 9, we also began standing up multiple sharded Temporal instances and implementing the ability to load-balance incoming work between them.
Each of the multiple Temporal instances maintains its own independent database and worker clusters, and so is isolated from the others. As a postmortem action item from the October 6 incident, we had already scheduled infrastructure work that would have removed the bottleneck of a single Temporal instance and Postgres database, starting October 12 and expecting to take 2 weeks. On October 9, we realized that this work simply could not wait, so our engineering team implemented, tested, and rolled out a simpler version of the planned changes within a few hours.
These changes completed successfully at 01:45 on October 10.
**In addition, we are changing how we store and monitor transaction logs.** Our Temporal database no longer uses the fixed-size log volume. We are adding alerts on how far log archiving falls behind and how fast the database writes logs, so we can act hours earlier than we did on October 9.
**We are also revisiting the Temporal's deletion schedule.** Temporal deletes finished work a few days after it runs, so a busy day returns as database load later in the week. We are changing when and how quickly those deletions run.
**We are changing how our systems retry when Temporal is slow.** On October 9, our systems retried failed work against Temporal and added to its load. As we committed after the October 6 incident, we are changing our systems to wait for Temporal to recover so work is not dropped.
## Conclusion
Customer experience is our top priority, and we commit to continually improving the reliability of our systems to match the trust that our customers place in us. We thank our customers for their patience while our team worked to resolve these incidents.
Please reach out to our support team with any questions or concerns.
Klienci mogą mieć podwyższony czas oczekiwania na maszyny. Pracujemy nad rozwiązaniem tego problemu.
identified
Klienci korzystający z pracy na maszynach Linuksa doświadczają zwiększonego czasu oczekiwania, średnio około 11 minut, przy czym najdłuższy czas oczekiwania przekracza 30 minut na średnich, arm.medium i arm.big klasy zasobów. Nasi inżynierowie zidentyfikowali problem i pracują nad jego naprawą. Dostarczymy kolejną aktualizację do 14: 00 UTC.
identified
Klienci korzystający z pracy na maszynach Linuksa doświadczają zwiększonego czasu oczekiwania, średnio około 40 minut, przy czym najdłuższy czas oczekiwania przekracza 50 minut. Większość klas zasobów Linuksa dotyczy, w tym średnich, dużych, xlarge, 2xlarge i ich odpowiedników Arm. Nasi inżynierowie zidentyfikowali problem i pracują nad jego naprawą. Dostarczymy kolejną aktualizację do 14: 30 UTC.
identified
Klienci korzystający z pracy na komputerze Linuksa i zdalnego Dockera doświadczają podwyższonych czasów oczekiwania. Czas oczekiwania zaczął się zmniejszać i teraz średnio około 20 minut, a najdłuższy czeka ponad 40 minut na niektórych klasach zasobów. Nasi inżynierowie zidentyfikowali problem i pracują nad jego naprawą. Dostarczymy kolejną aktualizację do 15: 00 UTC.
identified
Rozwiązanie zostało uruchomione i czas oczekiwania maleje, ale klienci korzystający z pracy maszyny Linuksa i zdalny Docker nadal doświadczają opóźnień. Czas oczekiwania obecnie średnio około 11 minut, z najdłuższym czeka ponad 35 minut na niektórych klas zasobów. Pracujemy nad jak najszybszym zwiększeniem wydajności. Dostarczymy kolejną aktualizację do 15: 30 UTC.
identified
Czas oczekiwania nadal maleje, ale klienci korzystający z pracy na komputerze Linuksa i zdalnego Dockera nadal doświadczają opóźnień. Czas oczekiwania średnio około 6 minut. Najdłuższe oczekiwania, do około 20 minut, są na 2xlarge, arm.2xlarge i gpu.nvidia. małe klasy zasobów. Pracujemy nad jak najszybszym zwiększeniem wydajności. Dostarczymy kolejną aktualizację do 16: 00 UTC.
identified
Czas oczekiwania nadal maleje, ale klienci korzystający z pracy na komputerze Linuksa i zdalnego Dockera nadal doświadczają opóźnień. Czas oczekiwania obecnie średnio około 90 sekund, z najdłuższym czeka do około 6 minut na niektórych klas zasobów. Pracujemy nad jak najszybszym zwiększeniem wydajności. Dostarczymy kolejną aktualizację do 16: 30 UTC.
monitoring
Czasy oczekiwania dla klientów korzystających z pracy na komputerze Linuksa i zdalnego Docker powróciły do normy. Monitorujemy, aby potwierdzić, że czas oczekiwania pozostaje stabilny, a my nadal dodajemy przepustowość. Dostarczymy kolejną aktualizację do 16: 30 UTC.
resolved
Między 12: 40 UTC a 16: 00 UTC 8 października klienci korzystający z pracy na maszynach Linuksa i zdalnego Dockera doświadczyli zwiększonego czasu oczekiwania. Sprawa została rozwiązana i czas oczekiwania powrócił do normy. Dziękujemy za cierpliwość, podczas gdy nasz zespół pracował nad wdrożeniem poprawki.
postmortem
Podsumowanie
Od 1 października klienci CircleCI doświadczyli wielu incydentów, które spowodowały opóźnienia i błędy w realizacji rurociągu klientów. Istnieją dwie przyczyny\ (niezwiązane\), z których oba zespół inżynieryjny CircleCI aktywnie łagodzi:
* Dostępna pojemność obliczeniowa w chmurze
* Infrastruktura wewnętrzna
# # Dostępna pojemność obliczeniowa w chmurze
* * * Problem * *: Popyt na wysoce wydajne przypadki chmur rośnie bardzo szybko w całej branży, co wywiera presję na typy instancji dostawców chmur, które używamy do wykonywania zadań klientów.
* * * Incydenty * *:
* [Podwyższone czasy oczekiwania na pracę maszynową] (https: / / status.circleci.com / invents / jn756xtsy4xg)
* [Zwiększone czasy oczekiwania na Docker Gen2] (https: / / status.circleci.com / invents / 39rfrjmk5pvd)
* [Podwyższony poziom podczerwieni nie odpowiada zadaniom klientów] (https: / / status.circleci.com / invents / 0z31ldjd8m5v)
* [Opóźnienie rozpoczęcia pracy maszyny] (https: / / status.circleci.com / invents / tj6wdnfjwr64)
* [Opóźnienia w uruchomieniu Gen 2 Docker Jobs] (https: / / status.circleci.com / invents / 22mrv46g6n7g)
* * * Mitigacje i rezolucje * *:
* Rozszerzamy nasz zestaw regionów chmury obliczeniowej o dodatkowe regiony z dostępnymi instancjami wysokiej wydajności.
* Pracujemy również nad zapewnieniem dodatkowej gwarantowanej przepustowości przez naszych partnerów w chmurze obliczeniowej w naszych istniejących regionach.
* Rozszerzamy zestaw rodzajów instancji, które możemy zaoferować klientom.
* 9 października 2026 roku opublikujemy szczegółowy raport o incydentach.
Infrastruktura wewnętrzna
* * * Problem * *: Przydzielamy przepływy pracy klienta do wielu dostawców obliczeń za pomocą usługi orchestracji przepływu pracy. Usługa ta jest obecnie chroniona przez przepustowość zapisu jednej bazy danych.
* * * Incydenty: * *
* [Opóźnienia w rurociągach, przepływach pracy, danych UI i powiadomień] (https: / / status.circleci.com / invents / z4hbq8h49j8c)
* [Utrzymanie infrastruktury nadzwyczajnej] (https: / / status.circleci.com / invents / g60yc9bvvkmx)
* * * Mitigacje i rezolucje * *:
* Do 23 października 2026 roku planujemy wdrożyć wiele zbędnych instancji orchestracji pracy, każdy z własną bazą danych, która pozwoli nam podzielić ładunek orchestracji między nimi.
Nasze zaangażowanie
Dla uniknięcia wątpliwości,
* Te szczególne incydenty nie są związane z trwającymi przerwami w Github
* Obecnie nie migrujemy naszej infrastruktury lub usług
* Nie jesteśmy obecnie pod cyberatakiem
Doświadczenie Klienta jest naszym najwyższym priorytetem i zobowiązujemy się do ciągłego zwiększania niezawodności naszych systemów, aby dopasować zaufanie naszych klientów do nas. Dziękujemy naszym klientom za cierpliwość, podczas gdy nasz zespół pracował nad rozwiązaniem tych incydentów i pracuje nad zapobieganiem przyszłym incydentom.
Prosimy o kontakt z naszym zespołem wsparcia w razie jakichkolwiek pytań lub wątpliwości.
Zwiększony czas oczekiwania zadania dla Docker Gen2
Początek 7 października 2026 18:54 UTC · 1h 11m
IssuesDrobny incydent
Dotknięte komponenty
Docker Jobs
identified
Zwiększony jest czas oczekiwania na pracę w Docker Gen2.
identified
Uwaga: Opóźnienia będą bardziej widoczne dla osób biegających po Docker "xlarge" i powyżej.
monitoring
Nadal widzimy kolce w zadaniach, ale średnio czas oczekiwania wygląda lepiej dla wszystkich Docker Gen2.
resolved
Ten incydent został rozwiązany.
postmortem
/ Podsumowanie
W okresie od 1 października do 8 października 2026 r. klienci CircleCI doświadczyli pięciu odrębnych incydentów, w których praca czekała dłużej niż zwykle na rozpoczęcie lub nie zaczęła się. Trzy incydenty były spowodowane ograniczoną dostępnością instancji przez naszego operatora chmur. Jeden z nich był spowodowany problemem konfiguracji w naszej infrastrukturze planowania, a drugi ograniczeniem pamięci na wewnętrznej usłudze, którą podnieśliśmy podczas incydentu.
* * * Październik 1, 07: 57 do 10: 24 UTC: * * Docker Gen 2 miejsc pracy czekał do 30 minut, aby rozpocząć. Problem z konfiguracją uniemożliwił serwerom Gen 2 korzystanie ze swoich wysokowydajnych lokalnych dysków. Podczas wybuchu w ruchu, dyski zapasowe nasycone i praca zwolniła.
* * * 7 października 13: 27 do 14: 06 UTC: * * Praca maszyny czekała dłużej niż zwykle, ponieważ nie mogliśmy zdobyć wystarczającej ilości maszyn wirtualnych od naszego dostawcy chmur.
* * * 7 października 14: 24 do 15: 21 UTC: * * Niektóre miejsca pracy nie powiodły się z błędem w infrastrukturze, a przepływy pracy zostały opóźnione. Usługa, która daje każdej pracy jej konfigurację przy startup zabrakło pamięci i ponownie uruchomione.
* * * 7 października, 18: 49 do 20: 05 UTC: * * Docker Gen 2 miejsca pracy czekały dłużej niż zwykle, ponieważ nie mogliśmy zdobyć wystarczających instancji od naszego dostawcy chmur.
* * * 8 października, 12: 48 do 16: 00 UTC: * * Praca maszyny Linuksa i praca zdalnego Docker czekał do 50 minut, aby rozpocząć. Nasz dostawca chmur nie miał wystarczającej liczby typów instancji, o które prosimy, a usterka w logice, która wybiera inny typ instancji powstrzymała nas od używania alternatyw.
Praca, która czekała podczas tych incydentów była opóźniona, a nie stracona. Klienci, których praca nie powiodła się z błędem w infrastrukturze podczas incydentu z 7 października od 14: 24 do 15: 21 UTC mogą je ponownie uruchomić.
Oryginalne strony stanu można znaleźć poniżej:
* [1 października - Opóźnienia w starcie Gen 2 Docker Jobs] (https: / / status.circleci.com / invents / 22mrv46g6n7g)
* [7 października - Opóźnienie rozpoczęcia pracy maszyny] (https: / / status.circleci.com / invents / tj6wdnfjwr64)
* [7 października - Podwyższony poziom podczerwieni nie odpowiada zatrudnieniu klientów] (https: / / status.circleci.com / invents / 0z31ldjd8m5v)
* [7 października - Zwiększony czas oczekiwania na Docker Gen2] (https: / / status.circleci.com / invents / 39rfrjmk5pvd)
* [8 października - Podwyższony czas oczekiwania na pracę maszynową] (https: / / status.circleci.com / invents / jn756xtsy4xg)
* * * Background * *
Każda praca na CircleCI wymaga obliczeń. Tam skąd pochodzą te obliczenia zależy od wykonawcy.
Praca dokerów działa na klastrach serwerów, które rozkładają pracę na flotę instancji. Programista jest oprogramowaniem na serwerach, które decydują, która instancja wykonuje każde zadanie. Gen 2 Docker pracy prowadził na jednym z takich klastrów w czasie 1 października. Zadania Gen 1 Docker są rozłożone na kilka klastrów.
Roboty maszynowe, w tym zdalne prace Docker, uzyskać dedykowaną maszynę wirtualną. Zdalne zadanie Dockera jest obsługiwane jako zadanie maszyny Linuksa od złożenia poprzez zapewnienie. Usługa zaopatrzenia maszyn wymaga każdej maszyny od naszego dostawcy chmur w jednym z dwóch regionów, które zwykle używamy do pracy maszynowej. Gdy dostawca nie może dostarczyć typu instancji, o którą prosimy, usługa odpada: żąda innego typu instancji lub innego regionu z listy, którą posiadamy. Praca czeka, aż maszyna będzie dostępna.
Kiedy jakaś praca się rozpoczyna, zwraca się do usługi konfiguracji zadania o jej konfigurację. Ta usługa działa jako zestaw kapsuł, które są małymi kopiami tego samego programu. Jeśli zatrzyma się zbyt wiele kapsuł, pozostałe kapsuły przenoszą więcej ładunku, a miejsca pracy nie mogą rozpocząć się do czasu powrotu do zdrowia.
Ścieżki te zależą od trzech rodzajów pojemności: przepustowości naszych systemów rozkładowych, dostaw instancji od naszego dostawcy chmur oraz pamięci i liczby kopii usług, które rozpoczynają pracę. Niedobór któregokolwiek z nich sprawia, że praca czeka lub zawodzi.
* * * What happed * *
_\ (Wszystkie czasy UTC\) _
# # # * * 1 października: Docker Gen 2 prace opóźnione do 30 minut * *
O 07: 44, aktywność dysków na serwerach, które planują zadania Gen 2 Docker wzrosła do 90% pojemności i została tam. O 07: 57 liczba miejsc pracy Docker czekających na początek zaczęła rosnąć, a czas oczekiwania wzrastał wraz z nim. Automatyczny alarm wzywał inżyniera o 08: 08. Ogłosiliśmy incydent o 08: 42.
O 08: 43 inżynierowie zidentyfikowali wysokie opóźnienie dysków na serwerach rozkładowych. Najpierw wierzyli, że dyski są zbyt wolne dla obciążenia, więc przygotowali zmianę na szybszy typ dysku. O 09: 01 zespół zgodził się na dwa strumienie pracy: przenieść serwery na szybsze dyski i dodać drugi klaster Gen 2, aby miejsca pracy zostały podzielone na dwie grupy.
O 09: 41 inżynierowie znaleźli przyczynę. Każdy serwer rozkładowy posiada bezpośrednio dołączone do niego szybkie dyski, a terminarz ma na celu utrzymanie tam swoich danych roboczych. Serwery te działają na obrazie systemu operacyjnego o zaostrzonym zabezpieczeniu, a na tym obrazie nie używano szybkich dysków. Scheduler zapisał swoje dane do wolniejszych dysków sieciowych. Skrypt, który ustawia szybkie dyski nie powiódł się bez błędu, a luka w logowaniu na tych serwerach ukryła błąd. Gen 2 ruch również stał się coraz bardziej gwałtowny. Wolniejsze dyski nasycone podczas tych wybuchów, i harmonogram spadł w tyle.
Czas oczekiwania osiągnął szczyt o 09: 54, kiedy prace na Gen 2 klasy średnich zasobów czekał do 30 minut. O 09: 55 inżynierowie zastosowali regulator, który prawidłowo ustawił szybkie dyski. O 10: 11, grafik zaczął stawiać miejsca pracy szybciej, co potwierdziło, że serwery mogą nadążać za nowymi miejscami pracy. Czas oczekiwania na Gen 2 średnio spadł do 13 minut o 10: 14, 7 minut o 10: 17 i 1 minuta 30 sekund o 10: 20. Przesunęliśmy stronę o 10: 24 i rozwiązaliśmy ten incydent o 10: 45.
O 11: 20, drugi klaster Gen 2 rozpoczął pracę.
# # # * * 7 października, 13: 27 do 14: 06: Podwyższone czasy oczekiwania na pracę maszyny * *
Ogłosiliśmy incydent o 13: 27, po tym jak zobaczyliśmy podniesioną kolejkę i czas oczekiwania. Zapisaliśmy na stronie o 13: 31. O 13: 31 inżynierowie zauważyli, że staramy się zdobyć maszyny wirtualne do pracy maszynowej i że liczba miejsc pracy czekających na rozpoczęcie pracy była wysoka głównie do pracy maszynowej. O 13: 34, czas oczekiwania został podniesiony przez wykonawców.
O 13: 48, czas oczekiwania zaczął się poprawiać, kiedy więcej maszyn stało się dostępne, a my rozwiązaliśmy ten incydent o 14: 06.
7 października, 14: 24 do 15: 21: Niepowodzenie pracy i opóźnienia w pracy
Krótko po tym, jak poprzedni incydent został zaznaczony jako rozwiązany, ogłosiliśmy nowy incydent o 14: 24 ze względu na gwałtowny spadek liczby miejsc pracy zgłoszonych do naszych systemów egzekucyjnych. O 14: 26 inżynierowie zauważyli, że kapsuły usługi konfiguracji pracy są ponownie uruchamiane. Punkty, które ponownie uruchomią, pozostawiają mniej kopii usługi do odpowiedzi na wnioski, a zadania, które nie mogły odzyskać konfiguracji po powtarzających się próbach nie powiodło się z błędem infrastruktury. Przepływy pracy, które były już uruchomione czekał na aktualizacje z miejsc pracy, które nie rozpoczęły.
O godzinie 14: 35 inżynierowie zwiększyli ilość dostępnej pamięci do kapsuł i zwiększyli liczbę kapsuł, co dało usłudze więcej kopii, aby udostępnić ładunek. Zwiększyliśmy również ilość dostępnych informacji na temat ofert pracy i liczba wiadomości płynących przez nasz system przepływu pracy powróciła do normalnego poziomu. O 14: 44 przesunęliśmy stronę statusu do monitorowania.
Pody w usłudze konfiguracji zadań osiągnęły swoje ograniczenia pamięci i ponownie rozpoczęły pracę. Zwiększyliśmy przydziały pamięci i ilość kapsuł, a usługa została odzyskana. O 15: 13 zwiększyliśmy liczbę przypadków w naszych klastrach dokujących Gen 2, abyśmy mogli szybko pracować nad zaległością oczekujących miejsc pracy. Rozwiązaliśmy ten wypadek o 15: 21.
# # # * * Październik 7, 18: 49 do 20: 05: Podwyższone czasy oczekiwania dla Docker Gen 2 jobs * *
Ogłosiliśmy nowy incydent o 18: 49, po tym jak Generał Docker 2 czas oczekiwania wzrósł. O 18: 51 inżynierowie potwierdzili, że brak dostępnych instancji powstrzymywał nas od zdobycia ich wystarczająco dużo, co zwiększyło czas oczekiwania. Czasy oczekiwania różniły się wielkością klasy zasobów.
O 19: 52, przeciętny czas oczekiwania był krótszy niż godzinę wcześniej, gdy więcej pojemności stało się dostępne, choć krótkie kolce kontynuowane, i przesunęliśmy stronę statusu do monitorowania. Rozwiązaliśmy ten incydent o 20: 05.
# # # * * 8 października: Maszyna Linux i zdalne zadania Docker czekać do 50 minut * *
Ogłosiliśmy incydent o 12: 48 po tym, jak zobaczyliśmy dużą liczbę miejsc pracy czekających na start i długi czas oczekiwania na pracę maszyny i zdalnego Dockera. O 12: 49 inżynierowie widzieli, że nasz dostawca chmur nie może dostarczyć wystarczającej ilości przypadków. Opóźnienia nadal się wspinały.
O 13: 13 zaczęliśmy badać logikę, która wybiera inny typ instancji lub region, kiedy nasz pierwszy wybór jest niedostępny. O 13: 24 podejrzewaliśmy, że defekt w tej logice powstrzymuje nas od używania innych typów instancji w naszym głównym regionie, więc wyłączyliśmy nasz region zapasowy i potwierdziliśmy przyczynę defektu. Inżynierowie zaczęli pracować nad naprawą i wdrożyli ją o 14: 49. Usługa zaczęła prosić o inne instancje i zaczęła maszyny w dużych ilościach. O 14: 58 kolejka miejsc pracy czekających na maszynę systematycznie spadała. Przeciętny czas oczekiwania w klasie zasobów nadal spada w ciągu następnej godziny, gdy pracowaliśmy przez zaległości oczekujących miejsc pracy.
O 16: 00, kolejka miejsc pracy czekających na maszynę oczyszczona i liczba miejsc pracy oczekiwania powróciła do normy. Przesunęliśmy stronę o 16: 09 i rozwiązaliśmy ten incydent o 16: 35.
* * Future Prevention and Process Improvement * *
Podejmujemy następujące kroki w celu wzmocnienia odporności czasu rozpoczęcia zatrudnienia, w tym dywersyfikacji dostaw, logiki awaryjnej i wcześniejszego wykrywania.
* * Rozwijamy nasze regiony obliczeniowe. * * W dniach 7 i 8 października nasz dostawca chmur nie mógł dostarczyć wystarczającej ilości przypadków w regionach, z których korzystaliśmy. Dodajemy nowe regiony do naszej logiki awaryjnej w celu zajęcia się skokami popytu, które przewyższają nasze preferowane regiony.
* * Naprawiamy logikę, która wybiera inny typ instancji. * * W dniu 8 października defekt nie pozwalał na używanie innych instancji w tym samym regionie. Podczas tego incydentu wprowadziliśmy rozwiązanie, a teraz przeglądamy i przekształcamy tę logikę w całość, testując ją, tak, że brak jednego przypadku przenosi pracę do drugiego.
* * Rozwijamy typy instancji, które oferujemy i zabezpieczamy dodatkową pojemność. * * Współpracujemy z naszym dostawcą usług w chmurze, aby zarezerwować dodatkową przepustowość w naszych istniejących regionach i dodajemy typy instancji, na których można pracować. Popyt przemysłu na wysokowydajne obliczenia rośnie. Zróżnicowujemy gdzie i w jaki sposób pobieramy przepustowość, aby nasi klienci byli izolowani od zmienności dostaw.
* * Dodaliśmy drugi klaster dokerów Gen 2, więc pęki są rozprowadzane po dwóch klastrach. * * Dodajemy również alarmy o nasyceniu dysku serwera rozkładowego oraz o tym, jak szybko terminarz umieszcza zadania, a także alarm, który uruchamia się, gdy serwer rozpoczyna pracę bez jego szybkich dysków w użyciu. Sprawiliśmy, że skrypt konfiguracji dysku nie powiódł się z błędem i przywróciliśmy wysyłkę dziennika z tych serwerów tak, że podobny problem jest widoczny wcześniej.
Doświadczenie Klienta jest naszym najwyższym priorytetem i zobowiązujemy się do ciągłego zwiększania niezawodności naszych systemów, aby dopasować zaufanie naszych klientów do nas. Dziękujemy naszym klientom za cierpliwość, podczas gdy nasz zespół pracował nad rozwiązaniem tych incydentów. Prosimy o kontakt z naszym zespołem wsparcia w razie jakichkolwiek pytań lub wątpliwości.
Podwyższony poziom upadłości w zakresie zatrudnienia klientów
Początek 7 października 2026 14:27 UTC · 54m
IssuesDrobny incydent
Dotknięte komponenty
Pipelines & Workflows
investigating
Prowadzimy śledztwo w sprawie wzrostu liczby przypadków niepowodzeń w zakresie zatrudnienia klientów.
monitoring
Widzimy oznaki powrotu do zdrowia. Czas oczekiwania Docker Gen2 jest nieznacznie podniesiony i monitorujemy.
resolved
Ten incydent został rozwiązany.
postmortem
/ Podsumowanie
W okresie od 1 października do 8 października 2026 r. klienci CircleCI doświadczyli pięciu odrębnych incydentów, w których praca czekała dłużej niż zwykle na rozpoczęcie lub nie zaczęła się. Trzy incydenty były spowodowane ograniczoną dostępnością instancji przez naszego operatora chmur. Jeden z nich był spowodowany problemem konfiguracji w naszej infrastrukturze planowania, a drugi ograniczeniem pamięci na wewnętrznej usłudze, którą podnieśliśmy podczas incydentu.
* * * Październik 1, 07: 57 do 10: 24 UTC: * * Docker Gen 2 miejsc pracy czekał do 30 minut, aby rozpocząć. Problem z konfiguracją uniemożliwił serwerom Gen 2 korzystanie ze swoich wysokowydajnych lokalnych dysków. Podczas wybuchu w ruchu, dyski zapasowe nasycone i praca zwolniła.
* * * 7 października 13: 27 do 14: 06 UTC: * * Praca maszyny czekała dłużej niż zwykle, ponieważ nie mogliśmy zdobyć wystarczającej ilości maszyn wirtualnych od naszego dostawcy chmur.
* * * 7 października 14: 24 do 15: 21 UTC: * * Niektóre miejsca pracy nie powiodły się z błędem w infrastrukturze, a przepływy pracy zostały opóźnione. Usługa, która daje każdej pracy jej konfigurację przy startup zabrakło pamięci i ponownie uruchomione.
* * * 7 października, 18: 49 do 20: 05 UTC: * * Docker Gen 2 miejsca pracy czekały dłużej niż zwykle, ponieważ nie mogliśmy zdobyć wystarczających instancji od naszego dostawcy chmur.
* * * 8 października, 12: 48 do 16: 00 UTC: * * Praca maszyny Linuksa i praca zdalnego Docker czekał do 50 minut, aby rozpocząć. Nasz dostawca chmur nie miał wystarczającej liczby typów instancji, o które prosimy, a usterka w logice, która wybiera inny typ instancji powstrzymała nas od używania alternatyw.
Praca, która czekała podczas tych incydentów była opóźniona, a nie stracona. Klienci, których praca nie powiodła się z błędem w infrastrukturze podczas incydentu z 7 października od 14: 24 do 15: 21 UTC mogą je ponownie uruchomić.
Oryginalne strony stanu można znaleźć poniżej:
* [1 października - Opóźnienia w starcie Gen 2 Docker Jobs] (https: / / status.circleci.com / invents / 22mrv46g6n7g)
* [7 października - Opóźnienie rozpoczęcia pracy maszyny] (https: / / status.circleci.com / invents / tj6wdnfjwr64)
* [7 października - Podwyższony poziom podczerwieni nie odpowiada zatrudnieniu klientów] (https: / / status.circleci.com / invents / 0z31ldjd8m5v)
* [7 października - Zwiększony czas oczekiwania na Docker Gen2] (https: / / status.circleci.com / invents / 39rfrjmk5pvd)
* [8 października - Podwyższony czas oczekiwania na pracę maszynową] (https: / / status.circleci.com / invents / jn756xtsy4xg)
* * * Background * *
Każda praca na CircleCI wymaga obliczeń. Tam skąd pochodzą te obliczenia zależy od wykonawcy.
Praca dokerów działa na klastrach serwerów, które rozkładają pracę na flotę instancji. Programista jest oprogramowaniem na serwerach, które decydują, która instancja wykonuje każde zadanie. Gen 2 Docker pracy prowadził na jednym z takich klastrów w czasie 1 października. Zadania Gen 1 Docker są rozłożone na kilka klastrów.
Roboty maszynowe, w tym zdalne prace Docker, uzyskać dedykowaną maszynę wirtualną. Zdalne zadanie Dockera jest obsługiwane jako zadanie maszyny Linuksa od złożenia poprzez zapewnienie. Usługa zaopatrzenia maszyn wymaga każdej maszyny od naszego dostawcy chmur w jednym z dwóch regionów, które zwykle używamy do pracy maszynowej. Gdy dostawca nie może dostarczyć typu instancji, o którą prosimy, usługa odpada: żąda innego typu instancji lub innego regionu z listy, którą posiadamy. Praca czeka, aż maszyna będzie dostępna.
Kiedy jakaś praca się rozpoczyna, zwraca się do usługi konfiguracji zadania o jej konfigurację. Ta usługa działa jako zestaw kapsuł, które są małymi kopiami tego samego programu. Jeśli zatrzyma się zbyt wiele kapsuł, pozostałe kapsuły przenoszą więcej ładunku, a miejsca pracy nie mogą rozpocząć się do czasu powrotu do zdrowia.
Ścieżki te zależą od trzech rodzajów pojemności: przepustowości naszych systemów rozkładowych, dostaw instancji od naszego dostawcy chmur oraz pamięci i liczby kopii usług, które rozpoczynają pracę. Niedobór któregokolwiek z nich sprawia, że praca czeka lub zawodzi.
* * * What happed * *
_\ (Wszystkie czasy UTC\) _
# # # * * 1 października: Docker Gen 2 prace opóźnione do 30 minut * *
O 07: 44, aktywność dysków na serwerach, które planują zadania Gen 2 Docker wzrosła do 90% pojemności i została tam. O 07: 57 liczba miejsc pracy Docker czekających na początek zaczęła rosnąć, a czas oczekiwania wzrastał wraz z nim. Automatyczny alarm wzywał inżyniera o 08: 08. Ogłosiliśmy incydent o 08: 42.
O 08: 43 inżynierowie zidentyfikowali wysokie opóźnienie dysków na serwerach rozkładowych. Najpierw wierzyli, że dyski są zbyt wolne dla obciążenia, więc przygotowali zmianę na szybszy typ dysku. O 09: 01 zespół zgodził się na dwa strumienie pracy: przenieść serwery na szybsze dyski i dodać drugi klaster Gen 2, aby miejsca pracy zostały podzielone na dwie grupy.
O 09: 41 inżynierowie znaleźli przyczynę. Każdy serwer rozkładowy posiada bezpośrednio dołączone do niego szybkie dyski, a terminarz ma na celu utrzymanie tam swoich danych roboczych. Serwery te działają na obrazie systemu operacyjnego o zaostrzonym zabezpieczeniu, a na tym obrazie nie używano szybkich dysków. Scheduler zapisał swoje dane do wolniejszych dysków sieciowych. Skrypt, który ustawia szybkie dyski nie powiódł się bez błędu, a luka w logowaniu na tych serwerach ukryła błąd. Gen 2 ruch również stał się coraz bardziej gwałtowny. Wolniejsze dyski nasycone podczas tych wybuchów, i harmonogram spadł w tyle.
Czas oczekiwania osiągnął szczyt o 09: 54, kiedy prace na Gen 2 klasy średnich zasobów czekał do 30 minut. O 09: 55 inżynierowie zastosowali regulator, który prawidłowo ustawił szybkie dyski. O 10: 11, grafik zaczął stawiać miejsca pracy szybciej, co potwierdziło, że serwery mogą nadążać za nowymi miejscami pracy. Czas oczekiwania na Gen 2 średnio spadł do 13 minut o 10: 14, 7 minut o 10: 17 i 1 minuta 30 sekund o 10: 20. Przesunęliśmy stronę o 10: 24 i rozwiązaliśmy ten incydent o 10: 45.
O 11: 20, drugi klaster Gen 2 rozpoczął pracę.
# # # * * 7 października, 13: 27 do 14: 06: Podwyższone czasy oczekiwania na pracę maszyny * *
Ogłosiliśmy incydent o 13: 27, po tym jak zobaczyliśmy podniesioną kolejkę i czas oczekiwania. Zapisaliśmy na stronie o 13: 31. O 13: 31 inżynierowie zauważyli, że staramy się zdobyć maszyny wirtualne do pracy maszynowej i że liczba miejsc pracy czekających na rozpoczęcie pracy była wysoka głównie do pracy maszynowej. O 13: 34, czas oczekiwania został podniesiony przez wykonawców.
O 13: 48, czas oczekiwania zaczął się poprawiać, kiedy więcej maszyn stało się dostępne, a my rozwiązaliśmy ten incydent o 14: 06.
7 października, 14: 24 do 15: 21: Niepowodzenie pracy i opóźnienia w pracy
Krótko po tym, jak poprzedni incydent został zaznaczony jako rozwiązany, ogłosiliśmy nowy incydent o 14: 24 ze względu na gwałtowny spadek liczby miejsc pracy zgłoszonych do naszych systemów egzekucyjnych. O 14: 26 inżynierowie zauważyli, że kapsuły usługi konfiguracji pracy są ponownie uruchamiane. Punkty, które ponownie uruchomią, pozostawiają mniej kopii usługi do odpowiedzi na wnioski, a zadania, które nie mogły odzyskać konfiguracji po powtarzających się próbach nie powiodło się z błędem infrastruktury. Przepływy pracy, które były już uruchomione czekał na aktualizacje z miejsc pracy, które nie rozpoczęły.
O godzinie 14: 35 inżynierowie zwiększyli ilość dostępnej pamięci do kapsuł i zwiększyli liczbę kapsuł, co dało usłudze więcej kopii, aby udostępnić ładunek. Zwiększyliśmy również ilość dostępnych informacji na temat ofert pracy i liczba wiadomości płynących przez nasz system przepływu pracy powróciła do normalnego poziomu. O 14: 44 przesunęliśmy stronę statusu do monitorowania.
Pody w usłudze konfiguracji zadań osiągnęły swoje ograniczenia pamięci i ponownie rozpoczęły pracę. Zwiększyliśmy przydziały pamięci i ilość kapsuł, a usługa została odzyskana. O 15: 13 zwiększyliśmy liczbę przypadków w naszych klastrach dokujących Gen 2, abyśmy mogli szybko pracować nad zaległością oczekujących miejsc pracy. Rozwiązaliśmy ten wypadek o 15: 21.
# # # * * Październik 7, 18: 49 do 20: 05: Podwyższone czasy oczekiwania dla Docker Gen 2 jobs * *
Ogłosiliśmy nowy incydent o 18: 49, po tym jak Generał Docker 2 czas oczekiwania wzrósł. O 18: 51 inżynierowie potwierdzili, że brak dostępnych instancji powstrzymywał nas od zdobycia ich wystarczająco dużo, co zwiększyło czas oczekiwania. Czasy oczekiwania różniły się wielkością klasy zasobów.
O 19: 52, przeciętny czas oczekiwania był krótszy niż godzinę wcześniej, gdy więcej pojemności stało się dostępne, choć krótkie kolce kontynuowane, i przesunęliśmy stronę statusu do monitorowania. Rozwiązaliśmy ten incydent o 20: 05.
# # # * * 8 października: Maszyna Linux i zdalne zadania Docker czekać do 50 minut * *
Ogłosiliśmy incydent o 12: 48 po tym, jak zobaczyliśmy dużą liczbę miejsc pracy czekających na start i długi czas oczekiwania na pracę maszyny i zdalnego Dockera. O 12: 49 inżynierowie widzieli, że nasz dostawca chmur nie może dostarczyć wystarczającej ilości przypadków. Opóźnienia nadal się wspinały.
O 13: 13 zaczęliśmy badać logikę, która wybiera inny typ instancji lub region, kiedy nasz pierwszy wybór jest niedostępny. O 13: 24 podejrzewaliśmy, że defekt w tej logice powstrzymuje nas od używania innych typów instancji w naszym głównym regionie, więc wyłączyliśmy nasz region zapasowy i potwierdziliśmy przyczynę defektu. Inżynierowie zaczęli pracować nad naprawą i wdrożyli ją o 14: 49. Usługa zaczęła prosić o inne instancje i zaczęła maszyny w dużych ilościach. O 14: 58 kolejka miejsc pracy czekających na maszynę systematycznie spadała. Przeciętny czas oczekiwania w klasie zasobów nadal spada w ciągu następnej godziny, gdy pracowaliśmy przez zaległości oczekujących miejsc pracy.
O 16: 00, kolejka miejsc pracy czekających na maszynę oczyszczona i liczba miejsc pracy oczekiwania powróciła do normy. Przesunęliśmy stronę o 16: 09 i rozwiązaliśmy ten incydent o 16: 35.
* * Future Prevention and Process Improvement * *
Podejmujemy następujące kroki w celu wzmocnienia odporności czasu rozpoczęcia zatrudnienia, w tym dywersyfikacji dostaw, logiki awaryjnej i wcześniejszego wykrywania.
* * Rozwijamy nasze regiony obliczeniowe. * * W dniach 7 i 8 października nasz dostawca chmur nie mógł dostarczyć wystarczającej ilości przypadków w regionach, z których korzystaliśmy. Dodajemy nowe regiony do naszej logiki awaryjnej w celu zajęcia się skokami popytu, które przewyższają nasze preferowane regiony.
* * Naprawiamy logikę, która wybiera inny typ instancji. * * W dniu 8 października defekt nie pozwalał na używanie innych instancji w tym samym regionie. Podczas tego incydentu wprowadziliśmy rozwiązanie, a teraz przeglądamy i przekształcamy tę logikę w całość, testując ją, tak, że brak jednego przypadku przenosi pracę do drugiego.
* * Rozwijamy typy instancji, które oferujemy i zabezpieczamy dodatkową pojemność. * * Współpracujemy z naszym dostawcą usług w chmurze, aby zarezerwować dodatkową przepustowość w naszych istniejących regionach i dodajemy typy instancji, na których można pracować. Popyt przemysłu na wysokowydajne obliczenia rośnie. Zróżnicowujemy gdzie i w jaki sposób pobieramy przepustowość, aby nasi klienci byli izolowani od zmienności dostaw.
* * Dodaliśmy drugi klaster dokerów Gen 2, więc pęki są rozprowadzane po dwóch klastrach. * * Dodajemy również alarmy o nasyceniu dysku serwera rozkładowego oraz o tym, jak szybko terminarz umieszcza zadania, a także alarm, który uruchamia się, gdy serwer rozpoczyna pracę bez jego szybkich dysków w użyciu. Sprawiliśmy, że skrypt konfiguracji dysku nie powiódł się z błędem i przywróciliśmy wysyłkę dziennika z tych serwerów tak, że podobny problem jest widoczny wcześniej.
Doświadczenie Klienta jest naszym najwyższym priorytetem i zobowiązujemy się do ciągłego zwiększania niezawodności naszych systemów, aby dopasować zaufanie naszych klientów do nas. Dziękujemy naszym klientom za cierpliwość, podczas gdy nasz zespół pracował nad rozwiązaniem tych incydentów. Prosimy o kontakt z naszym zespołem wsparcia w razie jakichkolwiek pytań lub wątpliwości.
Klienci mogą doświadczać zwiększonego czasu oczekiwania na zadania Machine Job, badamy przyczynę i aktualizacji, gdy wiemy więcej.
monitoring
Widzimy oznaki ożywienia i monitorowania sytuacji.
resolved
Incydent został rozwiązany. Dziękuję za cierpliwość
postmortem
/ Podsumowanie
W okresie od 1 października do 8 października 2026 r. klienci CircleCI doświadczyli pięciu odrębnych incydentów, w których praca czekała dłużej niż zwykle na rozpoczęcie lub nie zaczęła się. Trzy incydenty były spowodowane ograniczoną dostępnością instancji przez naszego operatora chmur. Jeden z nich był spowodowany problemem konfiguracji w naszej infrastrukturze planowania, a drugi ograniczeniem pamięci na wewnętrznej usłudze, którą podnieśliśmy podczas incydentu.
* * * Październik 1, 07: 57 do 10: 24 UTC: * * Docker Gen 2 miejsc pracy czekał do 30 minut, aby rozpocząć. Problem z konfiguracją uniemożliwił serwerom Gen 2 korzystanie ze swoich wysokowydajnych lokalnych dysków. Podczas wybuchu w ruchu, dyski zapasowe nasycone i praca zwolniła.
* * * 7 października 13: 27 do 14: 06 UTC: * * Praca maszyny czekała dłużej niż zwykle, ponieważ nie mogliśmy zdobyć wystarczającej ilości maszyn wirtualnych od naszego dostawcy chmur.
* * * 7 października 14: 24 do 15: 21 UTC: * * Niektóre miejsca pracy nie powiodły się z błędem w infrastrukturze, a przepływy pracy zostały opóźnione. Usługa, która daje każdej pracy jej konfigurację przy startup zabrakło pamięci i ponownie uruchomione.
* * * 7 października, 18: 49 do 20: 05 UTC: * * Docker Gen 2 miejsca pracy czekały dłużej niż zwykle, ponieważ nie mogliśmy zdobyć wystarczających instancji od naszego dostawcy chmur.
* * * 8 października, 12: 48 do 16: 00 UTC: * * Praca maszyny Linuksa i praca zdalnego Docker czekał do 50 minut, aby rozpocząć. Nasz dostawca chmur nie miał wystarczającej liczby typów instancji, o które prosimy, a usterka w logice, która wybiera inny typ instancji powstrzymała nas od używania alternatyw.
Praca, która czekała podczas tych incydentów była opóźniona, a nie stracona. Klienci, których praca nie powiodła się z błędem w infrastrukturze podczas incydentu z 7 października od 14: 24 do 15: 21 UTC mogą je ponownie uruchomić.
Oryginalne strony stanu można znaleźć poniżej:
* [1 października - Opóźnienia w starcie Gen 2 Docker Jobs] (https: / / status.circleci.com / invents / 22mrv46g6n7g)
* [7 października - Opóźnienie rozpoczęcia pracy maszyny] (https: / / status.circleci.com / invents / tj6wdnfjwr64)
* [7 października - Podwyższony poziom podczerwieni nie odpowiada zatrudnieniu klientów] (https: / / status.circleci.com / invents / 0z31ldjd8m5v)
* [7 października - Zwiększony czas oczekiwania na Docker Gen2] (https: / / status.circleci.com / invents / 39rfrjmk5pvd)
* [8 października - Podwyższony czas oczekiwania na pracę maszynową] (https: / / status.circleci.com / invents / jn756xtsy4xg)
* * * Background * *
Każda praca na CircleCI wymaga obliczeń. Tam skąd pochodzą te obliczenia zależy od wykonawcy.
Praca dokerów działa na klastrach serwerów, które rozkładają pracę na flotę instancji. Programista jest oprogramowaniem na serwerach, które decydują, która instancja wykonuje każde zadanie. Gen 2 Docker pracy prowadził na jednym z takich klastrów w czasie 1 października. Zadania Gen 1 Docker są rozłożone na kilka klastrów.
Roboty maszynowe, w tym zdalne prace Docker, uzyskać dedykowaną maszynę wirtualną. Zdalne zadanie Dockera jest obsługiwane jako zadanie maszyny Linuksa od złożenia poprzez zapewnienie. Usługa zaopatrzenia maszyn wymaga każdej maszyny od naszego dostawcy chmur w jednym z dwóch regionów, które zwykle używamy do pracy maszynowej. Gdy dostawca nie może dostarczyć typu instancji, o którą prosimy, usługa odpada: żąda innego typu instancji lub innego regionu z listy, którą posiadamy. Praca czeka, aż maszyna będzie dostępna.
Kiedy jakaś praca się rozpoczyna, zwraca się do usługi konfiguracji zadania o jej konfigurację. Ta usługa działa jako zestaw kapsuł, które są małymi kopiami tego samego programu. Jeśli zatrzyma się zbyt wiele kapsuł, pozostałe kapsuły przenoszą więcej ładunku, a miejsca pracy nie mogą rozpocząć się do czasu powrotu do zdrowia.
Ścieżki te zależą od trzech rodzajów pojemności: przepustowości naszych systemów rozkładowych, dostaw instancji od naszego dostawcy chmur oraz pamięci i liczby kopii usług, które rozpoczynają pracę. Niedobór któregokolwiek z nich sprawia, że praca czeka lub zawodzi.
* * * What happed * *
_\ (Wszystkie czasy UTC\) _
# # # * * 1 października: Docker Gen 2 prace opóźnione do 30 minut * *
O 07: 44, aktywność dysków na serwerach, które planują zadania Gen 2 Docker wzrosła do 90% pojemności i została tam. O 07: 57 liczba miejsc pracy Docker czekających na początek zaczęła rosnąć, a czas oczekiwania wzrastał wraz z nim. Automatyczny alarm wzywał inżyniera o 08: 08. Ogłosiliśmy incydent o 08: 42.
O 08: 43 inżynierowie zidentyfikowali wysokie opóźnienie dysków na serwerach rozkładowych. Najpierw wierzyli, że dyski są zbyt wolne dla obciążenia, więc przygotowali zmianę na szybszy typ dysku. O 09: 01 zespół zgodził się na dwa strumienie pracy: przenieść serwery na szybsze dyski i dodać drugi klaster Gen 2, aby miejsca pracy zostały podzielone na dwie grupy.
O 09: 41 inżynierowie znaleźli przyczynę. Każdy serwer rozkładowy posiada bezpośrednio dołączone do niego szybkie dyski, a terminarz ma na celu utrzymanie tam swoich danych roboczych. Serwery te działają na obrazie systemu operacyjnego o zaostrzonym zabezpieczeniu, a na tym obrazie nie używano szybkich dysków. Scheduler zapisał swoje dane do wolniejszych dysków sieciowych. Skrypt, który ustawia szybkie dyski nie powiódł się bez błędu, a luka w logowaniu na tych serwerach ukryła błąd. Gen 2 ruch również stał się coraz bardziej gwałtowny. Wolniejsze dyski nasycone podczas tych wybuchów, i harmonogram spadł w tyle.
Czas oczekiwania osiągnął szczyt o 09: 54, kiedy prace na Gen 2 klasy średnich zasobów czekał do 30 minut. O 09: 55 inżynierowie zastosowali regulator, który prawidłowo ustawił szybkie dyski. O 10: 11, grafik zaczął stawiać miejsca pracy szybciej, co potwierdziło, że serwery mogą nadążać za nowymi miejscami pracy. Czas oczekiwania na Gen 2 średnio spadł do 13 minut o 10: 14, 7 minut o 10: 17 i 1 minuta 30 sekund o 10: 20. Przesunęliśmy stronę o 10: 24 i rozwiązaliśmy ten incydent o 10: 45.
O 11: 20, drugi klaster Gen 2 rozpoczął pracę.
# # # * * 7 października, 13: 27 do 14: 06: Podwyższone czasy oczekiwania na pracę maszyny * *
Ogłosiliśmy incydent o 13: 27, po tym jak zobaczyliśmy podniesioną kolejkę i czas oczekiwania. Zapisaliśmy na stronie o 13: 31. O 13: 31 inżynierowie zauważyli, że staramy się zdobyć maszyny wirtualne do pracy maszynowej i że liczba miejsc pracy czekających na rozpoczęcie pracy była wysoka głównie do pracy maszynowej. O 13: 34, czas oczekiwania został podniesiony przez wykonawców.
O 13: 48, czas oczekiwania zaczął się poprawiać, kiedy więcej maszyn stało się dostępne, a my rozwiązaliśmy ten incydent o 14: 06.
7 października, 14: 24 do 15: 21: Niepowodzenie pracy i opóźnienia w pracy
Krótko po tym, jak poprzedni incydent został zaznaczony jako rozwiązany, ogłosiliśmy nowy incydent o 14: 24 ze względu na gwałtowny spadek liczby miejsc pracy zgłoszonych do naszych systemów egzekucyjnych. O 14: 26 inżynierowie zauważyli, że kapsuły usługi konfiguracji pracy są ponownie uruchamiane. Punkty, które ponownie uruchomią, pozostawiają mniej kopii usługi do odpowiedzi na wnioski, a zadania, które nie mogły odzyskać konfiguracji po powtarzających się próbach nie powiodło się z błędem infrastruktury. Przepływy pracy, które były już uruchomione czekał na aktualizacje z miejsc pracy, które nie rozpoczęły.
O godzinie 14: 35 inżynierowie zwiększyli ilość dostępnej pamięci do kapsuł i zwiększyli liczbę kapsuł, co dało usłudze więcej kopii, aby udostępnić ładunek. Zwiększyliśmy również ilość dostępnych informacji na temat ofert pracy i liczba wiadomości płynących przez nasz system przepływu pracy powróciła do normalnego poziomu. O 14: 44 przesunęliśmy stronę statusu do monitorowania.
Pody w usłudze konfiguracji zadań osiągnęły swoje ograniczenia pamięci i ponownie rozpoczęły pracę. Zwiększyliśmy przydziały pamięci i ilość kapsuł, a usługa została odzyskana. O 15: 13 zwiększyliśmy liczbę przypadków w naszych klastrach dokujących Gen 2, abyśmy mogli szybko pracować nad zaległością oczekujących miejsc pracy. Rozwiązaliśmy ten wypadek o 15: 21.
# # # * * Październik 7, 18: 49 do 20: 05: Podwyższone czasy oczekiwania dla Docker Gen 2 jobs * *
Ogłosiliśmy nowy incydent o 18: 49, po tym jak Generał Docker 2 czas oczekiwania wzrósł. O 18: 51 inżynierowie potwierdzili, że brak dostępnych instancji powstrzymywał nas od zdobycia ich wystarczająco dużo, co zwiększyło czas oczekiwania. Czasy oczekiwania różniły się wielkością klasy zasobów.
O 19: 52, przeciętny czas oczekiwania był krótszy niż godzinę wcześniej, gdy więcej pojemności stało się dostępne, choć krótkie kolce kontynuowane, i przesunęliśmy stronę statusu do monitorowania. Rozwiązaliśmy ten incydent o 20: 05.
# # # * * 8 października: Maszyna Linux i zdalne zadania Docker czekać do 50 minut * *
Ogłosiliśmy incydent o 12: 48 po tym, jak zobaczyliśmy dużą liczbę miejsc pracy czekających na start i długi czas oczekiwania na pracę maszyny i zdalnego Dockera. O 12: 49 inżynierowie widzieli, że nasz dostawca chmur nie może dostarczyć wystarczającej ilości przypadków. Opóźnienia nadal się wspinały.
O 13: 13 zaczęliśmy badać logikę, która wybiera inny typ instancji lub region, kiedy nasz pierwszy wybór jest niedostępny. O 13: 24 podejrzewaliśmy, że defekt w tej logice powstrzymuje nas od używania innych typów instancji w naszym głównym regionie, więc wyłączyliśmy nasz region zapasowy i potwierdziliśmy przyczynę defektu. Inżynierowie zaczęli pracować nad naprawą i wdrożyli ją o 14: 49. Usługa zaczęła prosić o inne instancje i zaczęła maszyny w dużych ilościach. O 14: 58 kolejka miejsc pracy czekających na maszynę systematycznie spadała. Przeciętny czas oczekiwania w klasie zasobów nadal spada w ciągu następnej godziny, gdy pracowaliśmy przez zaległości oczekujących miejsc pracy.
O 16: 00, kolejka miejsc pracy czekających na maszynę oczyszczona i liczba miejsc pracy oczekiwania powróciła do normy. Przesunęliśmy stronę o 16: 09 i rozwiązaliśmy ten incydent o 16: 35.
* * Future Prevention and Process Improvement * *
Podejmujemy następujące kroki w celu wzmocnienia odporności czasu rozpoczęcia zatrudnienia, w tym dywersyfikacji dostaw, logiki awaryjnej i wcześniejszego wykrywania.
* * Rozwijamy nasze regiony obliczeniowe. * * W dniach 7 i 8 października nasz dostawca chmur nie mógł dostarczyć wystarczającej ilości przypadków w regionach, z których korzystaliśmy. Dodajemy nowe regiony do naszej logiki awaryjnej w celu zajęcia się skokami popytu, które przewyższają nasze preferowane regiony.
* * Naprawiamy logikę, która wybiera inny typ instancji. * * W dniu 8 października defekt nie pozwalał na używanie innych instancji w tym samym regionie. Podczas tego incydentu wprowadziliśmy rozwiązanie, a teraz przeglądamy i przekształcamy tę logikę w całość, testując ją, tak, że brak jednego przypadku przenosi pracę do drugiego.
* * Rozwijamy typy instancji, które oferujemy i zabezpieczamy dodatkową pojemność. * * Współpracujemy z naszym dostawcą usług w chmurze, aby zarezerwować dodatkową przepustowość w naszych istniejących regionach i dodajemy typy instancji, na których można pracować. Popyt przemysłu na wysokowydajne obliczenia rośnie. Zróżnicowujemy gdzie i w jaki sposób pobieramy przepustowość, aby nasi klienci byli izolowani od zmienności dostaw.
* * Dodaliśmy drugi klaster dokerów Gen 2, więc pęki są rozprowadzane po dwóch klastrach. * * Dodajemy również alarmy o nasyceniu dysku serwera rozkładowego oraz o tym, jak szybko terminarz umieszcza zadania, a także alarm, który uruchamia się, gdy serwer rozpoczyna pracę bez jego szybkich dysków w użyciu. Sprawiliśmy, że skrypt konfiguracji dysku nie powiódł się z błędem i przywróciliśmy wysyłkę dziennika z tych serwerów tak, że podobny problem jest widoczny wcześniej.
Doświadczenie Klienta jest naszym najwyższym priorytetem i zobowiązujemy się do ciągłego zwiększania niezawodności naszych systemów, aby dopasować zaufanie naszych klientów do nas. Dziękujemy naszym klientom za cierpliwość, podczas gdy nasz zespół pracował nad rozwiązaniem tych incydentów. Prosimy o kontakt z naszym zespołem wsparcia w razie jakichkolwiek pytań lub wątpliwości.
Opóźnienia w rurociągach, przepływach pracy, danych UI i powiadomień
Początek 6 października 2026 16:00 UTC · 5h 18m
OutagePoważny incydent
Dotknięte komponenty
Pipelines & WorkflowsNotifications & Status Updates
investigating
Co ma wpływ
Klienci korzystający z rurociągów i przepływów roboczych CircleCI, w tym z wyświetlacza danych UI, powiadomień wychodzących oraz haków internetowych wychodzących.
Czego można się spodziewać?
Opóźnia powstawanie rurociągów oraz powstawanie przepływów pracy i miejsc pracy. Dane dotyczące pracy, przepływu pracy i rurociągu mogą zająć do 15 minut, aby pojawić się w UI. Powiadomienia i haki są opóźnione o 1 minutę.
Następna aktualizacja
Dostarczymy kolejną aktualizację w ciągu 30 minut lub jak mamy więcej informacji do przekazania.
investigating
Od 15: 47 UTC klienci mogą również zobaczyć nieudaną pracę, oprócz wcześniej zgłoszonych opóźnień. Nasi inżynierowie nadal badają i łagodzą problem.
identified
Od 16: 02 UTC, rurociągi całkowicie zawodzą, więc w tym momencie nie ma nowych przepływów pracy ani miejsc pracy. Jest to oprócz opóźnień i nieudanych miejsc pracy zgłoszonych wcześniej. Nasi inżynierowie nadal pracują nad złagodzeniem tej kwestii i będziemy dzielić się większą ilością informacji, jak tylko ją zdobędziemy.
identified
Od 16: 39 UTC zaczynamy dostrzegać ożywienie nowych rurociągów i przepływów pracy, a miejsca pracy zaczynają znowu funkcjonować. Nasi inżynierowie kontynuują prace nad naprawą i udostępnią więcej informacji, jak tylko je zdobędziemy.
identified
Podczas gdy rurociągi, przepływy pracy i miejsca pracy są ponownie uruchomione, klienci mogą nadal widzieć dłuższe niż zwykle opóźnienia między miejscami pracy w obiegu pracy, a notyfikacje na zewnątrz są opóźnione o około 1 minutę. Powiadomienia i aktualizacje statusu w systemie kontroli wersji zaczynają ponownie wychodzić.
Nasi inżynierowie nadal pracują nad pełnym wyzdrowieniem.
identified
Klienci w dalszym ciągu doświadczają dłuższych niż zwykle opóźnień między miejscami pracy w ramach obiegu pracy, jak również opóźnień w powiadomieniach odchodzących.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie kontynuują badania i prace nad złagodzeniem problemu. Będziemy dzielić się kolejną aktualizacją w ciągu najbliższych 30 minut, lub wcześniej, jeśli więcej informacji stanie się dostępne.
identified
Klienci nadal doświadczają dłuższych niż zwykle opóźnień przed rozpoczęciem pracy i rozpoczęciem pracy, w niektórych przypadkach do około 30 minut. Poprawia się to w porównaniu z wcześniejszymi zdarzeniami, ale nadal występują opóźnienia. Opóźnienia w powiadomieniach z zewnątrz uległy poprawie.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie nadal pracują nad przywróceniem normalnego czasu rozpoczęcia pracy. Będziemy dzielić się kolejną aktualizacją w ciągu najbliższych 30 minut, lub wcześniej, jeśli więcej informacji stanie się dostępne.
identified
Klienci nadal doświadczają opóźnień. Większość zaczyna się teraz w ciągu około 20 minut, poprawione z około 40 minut wcześniej w incydencie. Bardzo niewielka liczba przepływów pracy mogła czekać dłużej niż 1 godzinę.
Nasi inżynierowie dokonali zmian, które poprawiły stabilność obsługi, a pozostałe opóźnienia wynikają z zaległości w pracy, które powstały podczas incydentu. Backlog maleje, a my skupiamy się na szybszym oczyszczeniu. Będziemy dzielić się więcej informacji w miarę postępów.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują w zaległości. Będziemy dzielić się kolejną aktualizacją w ciągu najbliższych 30 minut, lub wcześniej, jeśli więcej informacji stanie się dostępne.
identified
Opóźnienia w zakresie przepływów pracy i nowych miejsc pracy nadal maleją. Większość zaczyna się teraz w ciągu około 10 minut, poprawiony z około 40 minut wcześniej w incydencie. Bardzo niewielka liczba przepływów pracy mogła czekać dłużej niż 1 godzinę. Jeśli twoja praca nie zaczęła się, proszę, powtórz pracę. Opóźnienia w powiadomieniach z zewnątrz uległy poprawie.
Pozostałe opóźnienie wynika z zaległości prac, które powstały podczas incydentu, i że zaległości zmniejszyła się o ponad połowę. Oczekujemy, że zaległości zostaną usunięte za około 15 minut. Będziemy dzielić się inną aktualizacją po jej oczyszczeniu, lub w ciągu najbliższych 30 minut.
identified
Zazaległości związane z opóźnioną pracą zostały usunięte, a przepływy pracy zaczynają się ponownie bez opóźnień w powiadomieniach. Jednak klienci korzystający z pracy Docker i Linux w wielu klasach zasobów, w tym średnich, dużych i 2xlarge gen2, mogą teraz zobaczyć zadania czekające w kolejce na kilka minut przed rozpoczęciem. Nasi inżynierowie nadal pracują nad złagodzeniem tego problemu. Jeśli twoja praca nie zaczęła się, proszę, powtórz pracę.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie nad tym pracują. Będziemy dzielić się kolejną aktualizacją w ciągu najbliższych 30 minut, lub wcześniej, jeśli więcej informacji stanie się dostępne.
monitoring
Przepływy pracy i miejsca pracy zaczynają się normalnie, a czas oczekiwania na pracę Dockera i Linuksa powrócił do normy. Nasi inżynierowie nadal monitorują ten problem. Jeśli twoja praca nie zaczęła się, proszę, powtórz pracę.
Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie nad tym pracują. Będziemy dzielić się kolejną aktualizacją w ciągu najbliższych 30 minut, lub wcześniej, jeśli więcej informacji stanie się dostępne.
resolved
Od około 15: 30 UTC do 20: 30 UTC w dniu 6 października 2026 roku, klienci doświadczyli opóźnień i niepowodzeń wpływających na rurociągi, przepływy pracy i miejsca pracy.
Od około 16: 02 UTC do 16: 39 UTC, rurociągi zawodziły i nie mogły rozpocząć się żadne nowe przepływy pracy ani miejsca pracy. Po wznowieniu służby, przepływy pracy i miejsca pracy zaczęły się z opóźnieniami do około 20: 00 UTC. Czas rozpoczęcia wynosił średnio około 40 minut na ich szczycie, a bardzo niewielka liczba przepływów pracy czekała ponad 1 godzinę. Powiadomienia i haki były również opóźnione do około 19: 00 UTC, zazwyczaj o około minutę.
W miarę jak zaległości w opóźnionej pracy zostały usunięte, wynikający z tego wzrost popytu wywierał presję na naszą zdolność wykonywania zleceń, powodując dalsze opóźnienia w pracy Dockera i Linuksa. Od około 19: 45 UTC do 20: 30 UTC, te zadania czekały w kolejce dłużej niż zwykle przed rozpoczęciem. Na szczycie, około 20: 05 UTC, oczekiwania osiągnęły do około 8 minut dla 2xlarge gen2, 6 minut dla xlare gen2 i mniej niż 5 minut dla kilku innych klas zasobów.
Problem został rozwiązany, a cała jego funkcjonalność wróciła do normy. Klienci, których praca nie powiodła się w tym oknie, mogą wznowić pracę. Dziękujemy za cierpliwość, podczas gdy nasz zespół pracował nad wdrożeniem poprawki.
postmortem
Podsumowanie
W dniu 6 października 2026, od 15: 30 do 20: 30 UTC, klienci CircleCI doświadczyli opóźnień w tworzeniu rurociągów oraz początkowych przepływów pracy i miejsc pracy. Od 15: 48 do 16: 38 UTC nie rozpoczęły się przepływy pracy ani miejsca pracy, a rurociągi uruchomione od 16: 02 UTC nie powiodły się. Krócej, okresowe opóźnienia zaczęły się wcześniej, o 13: 30 UTC. Dane zawarte w Interfejsie Internetowym CircleCI, powiadomienia oraz aktualizacje statusu zobowiązań dla dostawców kontroli wersji również zostały opóźnione.
Incydent rozpoczął się w bazie danych za naszą usługą orchestracji przepływu pracy, która koordynuje każdy rurociąg, przepływ pracy i pracę na CircleCI. Rutynowa konserwacja na największych tabelach bazy danych napisała dzienniki transakcji szybciej niż baza danych mogłaby je archiwizować, a dzienniki wypełniły wolumen pamięci zapisany dla nich. Aby baza danych nie stała się tylko czytelna, nasi inżynierowie przenieśli logi do głównego wolumenu pamięci. Ten ruch wyłączył bazę danych na 50 minut. Kiedy wróciła baza danych, przetwarzała pracę w około połowie normalnej szybkości, dopóki nasi inżynierowie nie zmienili ustawień bazy danych o 18: 19 UTC. Potem przepracowaliśmy zaległości, a czas rozpoczęcia pracy powrócił do normy o 20: 30 UTC.
Klienci, których praca nie powiodła się w tym oknie, mogą je ponownie uruchomić.
Data urodzenia: ok.
# # Tło
Kiedy uruchamiasz rurociąg, CircleCI przekazuje go do organizacji pracy. Ta usługa śledzi stan każdego przepływu pracy i pracy, decyduje, kiedy każda praca jest gotowa do pracy, i przekazuje gotową pracę do naszej floty egzekucyjnej. Dysponuje także danymi o pracy, które widzisz w Interfejsie, powiadomieniami i statusami, które wysyłamy po zakończeniu pracy.
Usługa orchestracji przechowuje swój stan w bazie danych. Baza danych zapisuje każdą zmianę w dzienniku transakcji przed jego zastosowaniem i przechowuje te dzienniki na dedykowanym woluminie pamięci masowej. Archiwizuje logi w sposób ciągły, aby móc ponownie wykorzystać tę przestrzeń. Jeśli archiwizacja jest w tyle, a głośność się wypełnia, baza danych przestaje przyjmować pisma, a żadna nowa praca nie może ruszyć do przodu.
Baza danych prowadzi również okresowy proces konserwacji\ (autovacuums\) na każdej tabeli, aby jej wewnętrzne zapisy były ważne z biegiem czasu. Na bardzo dużej tabeli, proces ten czyta każdą stronę tabeli i pisze dużą ilość dzienników transakcji.
# Co się stało
_\ (Wszystkie czasy UTC\) _
Od 10: 02 dnia 6 października nasz monitoring wywołał krótkotrwałe ostrzeżenia o błędach w służbie orkiestralnej. Każdy alarm został oczyszczony w ciągu 15 minut. Nasi inżynierowie widzieli podobne krótkie alarmy wcześniej, a system nie wykazywał żadnych innych oznak stresu, więc za każdym razem postępowali zgodnie z protokołem startowym, a każdy wpis został sprawdzony na swojej części przez i rozpoczął pracę, aby ostrzeżenia były mniej wrażliwe.
Około 12: 40, wraz z regularnym obciążeniem, które generuje własne dzienniki transakcji, proces konserwacji na kilku największych tabelach bazy danych zaczął pisać dodatkowe dzienniki transakcji szybciej niż baza danych mogła je archiwizować, a objętość dziennika zaczęła wypełniać.
O 13: 30, służba orkiestralna zaczęła zwalniać. W ciągu 15: 30 niektóre rurociągi i miejsca pracy trwały dłużej, w krótkich wybuchach. O 13: 35 nasz monitoring ponownie ostrzegł, tym razem wraz z powiązanymi alarmami z kilku innych usług. Inżynierowie infrastruktury postępowali zgodnie z protokołami alarmowymi, wyjaśniając niektóre wpisy. Wpisy powróciły o 14: 30, a po dalszym dochodzeniu ogłosiliśmy incydent o 14: 54. Powinniśmy byli wcześniej rozpoznać kombinację ostrzeżeń i omówić, w jaki sposób ustalamy to poniżej.
Po ogłoszeniu incydentu, nasi inżynierowie wyśledzili spowolnienie do procesu konserwacji\ (anty-wraparound autopróżni\). Baza danych uruchamia ten proces automatycznie, jeśli zostanie anulowana, więc nasi inżynierowie zmienili ustawienia, aby pomóc mu szybciej skończyć. O 15: 30 opóźnienia były ciągłe, a niektóre miejsca pracy zaczęły zawodzić.
O 15: 43, wolumen dziennika transakcji był prawie pełny. Jeśli jest wypełniona, baza danych przestałaby przyjmować pisma i żadna praca nie mogłaby działać. Nasi inżynierowie postanowili przenieść logi transakcji na główny wolumen pamięci masowej bazy danych, który miał mnóstwo wolnego miejsca. Ruch wymagał, aby baza danych się wyłączyła, a my nie mogliśmy przewidzieć z góry jak długo to potrwa.
Ruch rozpoczął się o 15: 47. Od 15: 48 do 16: 38, orchestracja nie mogła przetworzyć żadnej pracy. Klienci mogą nadal uruchamiać rurociągi, ale nie zaczęły się przepływy pracy ani miejsca pracy, a od 16: 02 nowo uruchomione rurociągi zawiodły. Umieściliśmy na naszej stronie statusu o 15: 58 i podniósł go do większego przestoju o 16: 20. Podczas gdy baza danych była wyłączona, nasi inżynierowie przygotowali zastępczą bazę danych jako zapas. Oryginalna baza danych była pierwsza, więc trzymaliśmy ją w użyciu.
O 16: 38, baza danych wróciła do sieci i praca zaczęła znów płynąć. Z dziennikami transakcji i regularnymi danymi udostępniającymi teraz te same dane, baza danych działała wolniej niż wcześniej. Od 16: 38 do 18: 19, orchestracja wykonywała pracę w około połowie normalnej stawki, a praca czekała dziesiątki minut, aż do około 50 minut najdłużej. W tym czasie baza danych musiała skończyć archiwizowanie zaległości dzienników transakcji, zanim mogliśmy przenieść je z powrotem do dedykowanego wolumenu. Zbadaliśmy i wdrożyliśmy także kilka zmian parametrów bazy danych, aby zatrzymać dalsze prace konserwacyjne przed rozpoczęciem i przygotowaniem sposobów na ograniczenie prac osiągających usługę. Wraz z zamienną bazą danych przygotowaliśmy również kompletny stos usług w tym czasie, abyśmy mogli przenieść się do niego z ryzykiem utraty danych i zdecydowali się na ten ruch.
O 18: 19 nasi inżynierowie zmienili ustawienia bazy danych, aby skrócić czas, jaki każdy zapis wydaje na przechowywanie. Odzyskano prędkość przetwarzania, a zaległości zaczęły się wyjaśniać. Aby go szybciej wyczyścić, dodaliśmy bazę danych i pojemność serwerów do systemów, które rozdają zadania naszej flocie egzekucyjnej. Około 19: 55, nowe miejsca pracy znów zaczęły się punktualnie.
Backlog dotarł do naszej floty egzekucyjnej. Od 19: 49 do 20: 30, niektóre prace Docker na większych klas zasobów czekał do około 10 minut, aby rozpocząć, podczas gdy pojemność wzrosła. O 20: 30 czas rozpoczęcia pracy wrócił do normy. Przesunęliśmy stronę o 20: 32 i rozwiązaliśmy ten incydent o 21: 19.
Około 3500 miejsc pracy nie zaczęło się w czasie incydentu. Klienci mogą wznowić te prace. Nie znaleźliśmy dowodów na to, że CircleCI prowadził jakąś pracę więcej niż raz. Klienci, którzy wznowili pracę, podczas gdy pierwotny bieg był jeszcze opóźniony, mogli widzieć oba biegi zakończone. Roczny plan klienci mogą pracować ze swoim zespołem konta w celu przeglądu wykorzystania.
Przyszłe zapobieganie i usprawnienie procesu
Podejmujemy następujące kroki, aby zapobiec nawrotom i poprawić czas reakcji:
* * Dodajemy alarmy o warunkach, które spowodowały ten incydent. * * Nasz monitoring załapał się na spowolnienie, ale nie mieliśmy żadnego ostrzeżenia co do tego, jak pełny był wolumen dziennika transakcji, ani jak daleko archiwizacja była w tyle. Dodajemy alarmy o obu, a także alarmy o konserwacji bazy danych, która je napędza, abyśmy mogli działać wcześniej. Zwracamy również uwagę na wszystkie nasze alarmy, aby zapewnić, że hałaśliwe lub wrażliwe alarmy nie ukrywają prawdziwych problemów.
* * Dostrajamy sposób, w jaki proces konserwacji\ (autopróżni\) działa w naszej bazie danych. * * Patrzymy na częstotliwość i agresywność, z jaką autoodkurzacze działają w naszej bazie danych. Śledzimy również rozmiar tych tabel w czasie, aby pozostawały w bezpiecznych granicach.
* * Usuwamy pojedynczy dziennik transakcji wąskie gardło. * * Wszystkie utwory w serwisie orchestracyjnym przechodzą obecnie przez jedną bazę danych i jeden dziennik transakcji, więc kiedy logarytm się zawalił, każdy rurociąg, przepływ pracy i praca spowalniały wraz z nim. Oceniamy dwa podejścia: podział usługi na wiele instancji baz danych, każdy z własnym dziennikiem transakcji, i przeniesienie go do rozproszonej bazy danych zbudowanej, aby rozprzestrzeniać się pisze w wielu węzłach. Każde podejście ograniczyłoby efekt zaległości do części obciążenia pracą.
* * Sprawiamy, że nasze systemy czekają na powrót do służby orkiestralnej. * * Podczas incydentu, niektóre miejsca pracy zawiodły, ponieważ nasze systemy poddały się po ponownym spróbowaniu. Pracujemy nad zmianą tego zachowania.
* * Ulepszamy aktualizacje naszej strony statusu podczas długich incydentów. * * Klienci powiedzieli nam, że nasze wczesne aktualizacje nie były wystarczająco szczegółowe. Aktualizujemy nasze wytyczne, więc aktualizacje obejmują konkretne skutki i terminy wcześniej.
Uzasadnienie
Doświadczenie Klienta jest naszym najwyższym priorytetem i zobowiązujemy się do ciągłego zwiększania niezawodności naszych systemów, aby dopasować zaufanie naszych klientów do nas. Dziękujemy naszym klientom za cierpliwość, podczas gdy nasz zespół pracował nad rozwiązaniem tego incydentu. Prosimy o kontakt z naszym zespołem wsparcia w razie jakichkolwiek pytań lub wątpliwości.
Klienci mogą wystąpić opóźnienia w uruchomieniu Docker Gen 2 Jobs. Pracujemy nad zwiększeniem przepustowości systemu do tego czasu.
identified
Zidentyfikowaliśmy przyczynę i aktywnie pracujemy nad rozwiązaniem problemu. Dziękuję za cierpliwość.
identified
Naprawa została zakończona i zaczynamy obserwować powrót do zdrowia.
monitoring
Widzimy, że czas kolejki wraca do normalnego poziomu i monitoruje.
resolved
Ten incydent został rozwiązany.
postmortem
/ Podsumowanie
W okresie od 1 października do 8 października 2026 r. klienci CircleCI doświadczyli pięciu odrębnych incydentów, w których praca czekała dłużej niż zwykle na rozpoczęcie lub nie zaczęła się. Trzy incydenty były spowodowane ograniczoną dostępnością instancji przez naszego operatora chmur. Jeden z nich był spowodowany problemem konfiguracji w naszej infrastrukturze planowania, a drugi ograniczeniem pamięci na wewnętrznej usłudze, którą podnieśliśmy podczas incydentu.
* * * Październik 1, 07: 57 do 10: 24 UTC: * * Docker Gen 2 miejsc pracy czekał do 30 minut, aby rozpocząć. Problem z konfiguracją uniemożliwił serwerom Gen 2 korzystanie ze swoich wysokowydajnych lokalnych dysków. Podczas wybuchu w ruchu, dyski zapasowe nasycone i praca zwolniła.
* * * 7 października 13: 27 do 14: 06 UTC: * * Praca maszyny czekała dłużej niż zwykle, ponieważ nie mogliśmy zdobyć wystarczającej ilości maszyn wirtualnych od naszego dostawcy chmur.
* * * 7 października 14: 24 do 15: 21 UTC: * * Niektóre miejsca pracy nie powiodły się z błędem w infrastrukturze, a przepływy pracy zostały opóźnione. Usługa, która daje każdej pracy jej konfigurację przy startup zabrakło pamięci i ponownie uruchomione.
* * * 7 października, 18: 49 do 20: 05 UTC: * * Docker Gen 2 miejsca pracy czekały dłużej niż zwykle, ponieważ nie mogliśmy zdobyć wystarczających instancji od naszego dostawcy chmur.
* * * 8 października, 12: 48 do 16: 00 UTC: * * Praca maszyny Linuksa i praca zdalnego Docker czekał do 50 minut, aby rozpocząć. Nasz dostawca chmur nie miał wystarczającej liczby typów instancji, o które prosimy, a usterka w logice, która wybiera inny typ instancji powstrzymała nas od używania alternatyw.
Praca, która czekała podczas tych incydentów była opóźniona, a nie stracona. Klienci, których praca nie powiodła się z błędem w infrastrukturze podczas incydentu z 7 października od 14: 24 do 15: 21 UTC mogą je ponownie uruchomić.
Oryginalne strony stanu można znaleźć poniżej:
* [1 października - Opóźnienia w starcie Gen 2 Docker Jobs] (https: / / status.circleci.com / invents / 22mrv46g6n7g)
* [7 października - Opóźnienie rozpoczęcia pracy maszyny] (https: / / status.circleci.com / invents / tj6wdnfjwr64)
* [7 października - Podwyższony poziom podczerwieni nie odpowiada zatrudnieniu klientów] (https: / / status.circleci.com / invents / 0z31ldjd8m5v)
* [7 października - Zwiększony czas oczekiwania na Docker Gen2] (https: / / status.circleci.com / invents / 39rfrjmk5pvd)
* [8 października - Podwyższony czas oczekiwania na pracę maszynową] (https: / / status.circleci.com / invents / jn756xtsy4xg)
* * * Background * *
Każda praca na CircleCI wymaga obliczeń. Tam skąd pochodzą te obliczenia zależy od wykonawcy.
Praca dokerów działa na klastrach serwerów, które rozkładają pracę na flotę instancji. Programista jest oprogramowaniem na serwerach, które decydują, która instancja wykonuje każde zadanie. Gen 2 Docker pracy prowadził na jednym z takich klastrów w czasie 1 października. Zadania Gen 1 Docker są rozłożone na kilka klastrów.
Roboty maszynowe, w tym zdalne prace Docker, uzyskać dedykowaną maszynę wirtualną. Zdalne zadanie Dockera jest obsługiwane jako zadanie maszyny Linuksa od złożenia poprzez zapewnienie. Usługa zaopatrzenia maszyn wymaga każdej maszyny od naszego dostawcy chmur w jednym z dwóch regionów, które zwykle używamy do pracy maszynowej. Gdy dostawca nie może dostarczyć typu instancji, o którą prosimy, usługa odpada: żąda innego typu instancji lub innego regionu z listy, którą posiadamy. Praca czeka, aż maszyna będzie dostępna.
Kiedy jakaś praca się rozpoczyna, zwraca się do usługi konfiguracji zadania o jej konfigurację. Ta usługa działa jako zestaw kapsuł, które są małymi kopiami tego samego programu. Jeśli zatrzyma się zbyt wiele kapsuł, pozostałe kapsuły przenoszą więcej ładunku, a miejsca pracy nie mogą rozpocząć się do czasu powrotu do zdrowia.
Ścieżki te zależą od trzech rodzajów pojemności: przepustowości naszych systemów rozkładowych, dostaw instancji od naszego dostawcy chmur oraz pamięci i liczby kopii usług, które rozpoczynają pracę. Niedobór któregokolwiek z nich sprawia, że praca czeka lub zawodzi.
* * * What happed * *
_\ (Wszystkie czasy UTC\) _
# # # * * 1 października: Docker Gen 2 prace opóźnione do 30 minut * *
O 07: 44, aktywność dysków na serwerach, które planują zadania Gen 2 Docker wzrosła do 90% pojemności i została tam. O 07: 57 liczba miejsc pracy Docker czekających na początek zaczęła rosnąć, a czas oczekiwania wzrastał wraz z nim. Automatyczny alarm wzywał inżyniera o 08: 08. Ogłosiliśmy incydent o 08: 42.
O 08: 43 inżynierowie zidentyfikowali wysokie opóźnienie dysków na serwerach rozkładowych. Najpierw wierzyli, że dyski są zbyt wolne dla obciążenia, więc przygotowali zmianę na szybszy typ dysku. O 09: 01 zespół zgodził się na dwa strumienie pracy: przenieść serwery na szybsze dyski i dodać drugi klaster Gen 2, aby miejsca pracy zostały podzielone na dwie grupy.
O 09: 41 inżynierowie znaleźli przyczynę. Każdy serwer rozkładowy posiada bezpośrednio dołączone do niego szybkie dyski, a terminarz ma na celu utrzymanie tam swoich danych roboczych. Serwery te działają na obrazie systemu operacyjnego o zaostrzonym zabezpieczeniu, a na tym obrazie nie używano szybkich dysków. Scheduler zapisał swoje dane do wolniejszych dysków sieciowych. Skrypt, który ustawia szybkie dyski nie powiódł się bez błędu, a luka w logowaniu na tych serwerach ukryła błąd. Gen 2 ruch również stał się coraz bardziej gwałtowny. Wolniejsze dyski nasycone podczas tych wybuchów, i harmonogram spadł w tyle.
Czas oczekiwania osiągnął szczyt o 09: 54, kiedy prace na Gen 2 klasy średnich zasobów czekał do 30 minut. O 09: 55 inżynierowie zastosowali regulator, który prawidłowo ustawił szybkie dyski. O 10: 11, grafik zaczął stawiać miejsca pracy szybciej, co potwierdziło, że serwery mogą nadążać za nowymi miejscami pracy. Czas oczekiwania na Gen 2 średnio spadł do 13 minut o 10: 14, 7 minut o 10: 17 i 1 minuta 30 sekund o 10: 20. Przesunęliśmy stronę o 10: 24 i rozwiązaliśmy ten incydent o 10: 45.
O 11: 20, drugi klaster Gen 2 rozpoczął pracę.
# # # * * 7 października, 13: 27 do 14: 06: Podwyższone czasy oczekiwania na pracę maszyny * *
Ogłosiliśmy incydent o 13: 27, po tym jak zobaczyliśmy podniesioną kolejkę i czas oczekiwania. Zapisaliśmy na stronie o 13: 31. O 13: 31 inżynierowie zauważyli, że staramy się zdobyć maszyny wirtualne do pracy maszynowej i że liczba miejsc pracy czekających na rozpoczęcie pracy była wysoka głównie do pracy maszynowej. O 13: 34, czas oczekiwania został podniesiony przez wykonawców.
O 13: 48, czas oczekiwania zaczął się poprawiać, kiedy więcej maszyn stało się dostępne, a my rozwiązaliśmy ten incydent o 14: 06.
7 października, 14: 24 do 15: 21: Niepowodzenie pracy i opóźnienia w pracy
Krótko po tym, jak poprzedni incydent został zaznaczony jako rozwiązany, ogłosiliśmy nowy incydent o 14: 24 ze względu na gwałtowny spadek liczby miejsc pracy zgłoszonych do naszych systemów egzekucyjnych. O 14: 26 inżynierowie zauważyli, że kapsuły usługi konfiguracji pracy są ponownie uruchamiane. Punkty, które ponownie uruchomią, pozostawiają mniej kopii usługi do odpowiedzi na wnioski, a zadania, które nie mogły odzyskać konfiguracji po powtarzających się próbach nie powiodło się z błędem infrastruktury. Przepływy pracy, które były już uruchomione czekał na aktualizacje z miejsc pracy, które nie rozpoczęły.
O godzinie 14: 35 inżynierowie zwiększyli ilość dostępnej pamięci do kapsuł i zwiększyli liczbę kapsuł, co dało usłudze więcej kopii, aby udostępnić ładunek. Zwiększyliśmy również ilość dostępnych informacji na temat ofert pracy i liczba wiadomości płynących przez nasz system przepływu pracy powróciła do normalnego poziomu. O 14: 44 przesunęliśmy stronę statusu do monitorowania.
Pody w usłudze konfiguracji zadań osiągnęły swoje ograniczenia pamięci i ponownie rozpoczęły pracę. Zwiększyliśmy przydziały pamięci i ilość kapsuł, a usługa została odzyskana. O 15: 13 zwiększyliśmy liczbę przypadków w naszych klastrach dokujących Gen 2, abyśmy mogli szybko pracować nad zaległością oczekujących miejsc pracy. Rozwiązaliśmy ten wypadek o 15: 21.
# # # * * Październik 7, 18: 49 do 20: 05: Podwyższone czasy oczekiwania dla Docker Gen 2 jobs * *
Ogłosiliśmy nowy incydent o 18: 49, po tym jak Generał Docker 2 czas oczekiwania wzrósł. O 18: 51 inżynierowie potwierdzili, że brak dostępnych instancji powstrzymywał nas od zdobycia ich wystarczająco dużo, co zwiększyło czas oczekiwania. Czasy oczekiwania różniły się wielkością klasy zasobów.
O 19: 52, przeciętny czas oczekiwania był krótszy niż godzinę wcześniej, gdy więcej pojemności stało się dostępne, choć krótkie kolce kontynuowane, i przesunęliśmy stronę statusu do monitorowania. Rozwiązaliśmy ten incydent o 20: 05.
# # # * * 8 października: Maszyna Linux i zdalne zadania Docker czekać do 50 minut * *
Ogłosiliśmy incydent o 12: 48 po tym, jak zobaczyliśmy dużą liczbę miejsc pracy czekających na start i długi czas oczekiwania na pracę maszyny i zdalnego Dockera. O 12: 49 inżynierowie widzieli, że nasz dostawca chmur nie może dostarczyć wystarczającej ilości przypadków. Opóźnienia nadal się wspinały.
O 13: 13 zaczęliśmy badać logikę, która wybiera inny typ instancji lub region, kiedy nasz pierwszy wybór jest niedostępny. O 13: 24 podejrzewaliśmy, że defekt w tej logice powstrzymuje nas od używania innych typów instancji w naszym głównym regionie, więc wyłączyliśmy nasz region zapasowy i potwierdziliśmy przyczynę defektu. Inżynierowie zaczęli pracować nad naprawą i wdrożyli ją o 14: 49. Usługa zaczęła prosić o inne instancje i zaczęła maszyny w dużych ilościach. O 14: 58 kolejka miejsc pracy czekających na maszynę systematycznie spadała. Przeciętny czas oczekiwania w klasie zasobów nadal spada w ciągu następnej godziny, gdy pracowaliśmy przez zaległości oczekujących miejsc pracy.
O 16: 00, kolejka miejsc pracy czekających na maszynę oczyszczona i liczba miejsc pracy oczekiwania powróciła do normy. Przesunęliśmy stronę o 16: 09 i rozwiązaliśmy ten incydent o 16: 35.
* * Future Prevention and Process Improvement * *
Podejmujemy następujące kroki w celu wzmocnienia odporności czasu rozpoczęcia zatrudnienia, w tym dywersyfikacji dostaw, logiki awaryjnej i wcześniejszego wykrywania.
* * Rozwijamy nasze regiony obliczeniowe. * * W dniach 7 i 8 października nasz dostawca chmur nie mógł dostarczyć wystarczającej ilości przypadków w regionach, z których korzystaliśmy. Dodajemy nowe regiony do naszej logiki awaryjnej w celu zajęcia się skokami popytu, które przewyższają nasze preferowane regiony.
* * Naprawiamy logikę, która wybiera inny typ instancji. * * W dniu 8 października defekt nie pozwalał na używanie innych instancji w tym samym regionie. Podczas tego incydentu wprowadziliśmy rozwiązanie, a teraz przeglądamy i przekształcamy tę logikę w całość, testując ją, tak, że brak jednego przypadku przenosi pracę do drugiego.
* * Rozwijamy typy instancji, które oferujemy i zabezpieczamy dodatkową pojemność. * * Współpracujemy z naszym dostawcą usług w chmurze, aby zarezerwować dodatkową przepustowość w naszych istniejących regionach i dodajemy typy instancji, na których można pracować. Popyt przemysłu na wysokowydajne obliczenia rośnie. Zróżnicowujemy gdzie i w jaki sposób pobieramy przepustowość, aby nasi klienci byli izolowani od zmienności dostaw.
* * Dodaliśmy drugi klaster dokerów Gen 2, więc pęki są rozprowadzane po dwóch klastrach. * * Dodajemy również alarmy o nasyceniu dysku serwera rozkładowego oraz o tym, jak szybko terminarz umieszcza zadania, a także alarm, który uruchamia się, gdy serwer rozpoczyna pracę bez jego szybkich dysków w użyciu. Sprawiliśmy, że skrypt konfiguracji dysku nie powiódł się z błędem i przywróciliśmy wysyłkę dziennika z tych serwerów tak, że podobny problem jest widoczny wcześniej.
Doświadczenie Klienta jest naszym najwyższym priorytetem i zobowiązujemy się do ciągłego zwiększania niezawodności naszych systemów, aby dopasować zaufanie naszych klientów do nas. Dziękujemy naszym klientom za cierpliwość, podczas gdy nasz zespół pracował nad rozwiązaniem tych incydentów. Prosimy o kontakt z naszym zespołem wsparcia w razie jakichkolwiek pytań lub wątpliwości.
Klienci mogą wystąpić opóźnienia w aktualizacjach UI
Początek 16 września 2026 14:55 UTC · 4h 35m
IssuesDrobny incydent
Dotknięte komponenty
CircleCI APICircleCI UI
investigating
Badamy opóźnienie w udostępnianiu danych dotyczących rurociągu. Rury nadal działają, ale dane o nich mogą być opóźnione w UI lub API.
identified
Zidentyfikowaliśmy tę kwestię i pracujemy nad rekultywacją. Dziękuję za cierpliwość.
identified
Dane dotyczące rurociągu są obecnie dostępne jako normalne, z wyjątkiem wyników badań, które mogą być nadal opóźnione. Nadal nad tym pracujemy, dziękuję za cierpliwość.
monitoring
Wszystkie dane dotyczące rurociągu są teraz dostępne jako normalne. Będziemy nadal monitorować powrót do zdrowia.
Klienci mogą wystąpić opóźnienia w aktualizacjach UI
Początek 15 września 2026 14:42 UTC · 2h 20m
IssuesDrobny incydent
Dotknięte komponenty
CircleCI UI
investigating
Obecnie mamy do czynienia z opóźnieniem w gromadzeniu danych dotyczących rurociągu w ramach inicjatywy UE.
identified
Zaczynamy dostrzegać poprawę.
resolved
Incydent wpływający na dane dotyczące rurociągu w UI został już rozwiązany. Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracowali nad zmniejszeniem opóźnień.
Ze względu na zwiększone błędy sieciowe i opóźnienia widzimy zwiększony czas oczekiwania na pracę w systemie macOS. Prowadzimy śledztwo z naszym dostawcą hostingu.
investigating
Czas oczekiwania na pracę w MacOS maleje, a my kontynuujemy śledztwo.
monitoring
Nasz dostawca hostingu MacOS wdrożył łagodzące i widzieliśmy lepsze opóźnienia. Będziemy nadal monitorować.
resolved
Czas oczekiwania na pracę z MacOS 'em wraca do normy.
Kwestie załadunku rurociągów dla niewielkiej liczby projektów
Początek 10 września 2026 20:25 UTC · 1m
IssuesDrobny incydent
Dotknięte komponenty
CircleCI UI
identified
Niewielka liczba klientów może zauważyć błędy lub nie być w stanie załadować strony rurociągów dla projektów z ostrzeżeniami deprecated- config, przy użyciu klasycznego widoku rurociągów. Klienci na widok nowych rurociągów nie mają wpływu. Zidentyfikowaliśmy przyczynę i ustaliliśmy przyczynę.
monitoring
Wprowadzono rozwiązanie i monitorujemy wyniki.
resolved
Ten incydent został rozwiązany. Niewielka liczba klientów, którzy stworzyli rurociągi między 18: 53 UTC a 19: 24 UTC, które zawierały config przy użyciu zdeprecjonowanej składni config będzie widział ich zadania typu build- type nie rozpocząć. Klienci, których prace lub rurociągi zawiodły, mogą je ponownie uruchomić.
Wykryliśmy problemy sieciowe wpływające na naszą infrastrukturę Mac. Prowadzimy śledztwo i wkrótce dostarczymy nowe informacje. Klienci mogą doświadczyć kolejki w tym czasie.
identified
Zidentyfikowaliśmy problem sieciowy z naszym dostawcą infrastruktury Mac i pracujemy z nimi nad rozwiązaniem problemu. Zaczynamy dostrzegać poprawę, ale spodziewamy się, że klienci nadal mogą zobaczyć kolejkę. Niedługo się dowiemy.
monitoring
Nasz dostawca infrastruktury Mac zastosował rozwiązanie tego problemu sieciowego i widzimy, że czas kolejki wraca do normy. Będziemy mieć oko na sprawy jeszcze przez jakiś czas. Niedługo się dowiemy.
resolved
Nie widzieliśmy żadnego wpływu na kolejkę i wszystko wróciło do normy. Doceniamy waszą cierpliwość, pracując nad rozwiązaniem i monitorowaniem tej kwestii.
Częste błędy podczas przeglądania korzystania z planu UI lub korzystania z planu wywołania API
Początek 26 sierpnia 2026 15:43 UTC · 27m
IssuesDrobny incydent
Dotknięte komponenty
CircleCI APICircleCI UI
identified
Klienci mogą doświadczać błędów przerywanych podczas przeglądania wykorzystania planów UI lub korzystania z API planu wywołania. Zidentyfikowaliśmy tę kwestię i aktywnie pracujemy nad złagodzeniem tych błędów.
monitoring
Zminimalizowaliśmy problem z wykorzystaniem API planu i odpowiednie strony w UI ładują poprawnie.
Między 19: 49 UTC a 21: 07 UTC w dniu 25 sierpnia 2026 roku, klienci próbujący zalogować się do CircleCI za pomocą GitHub nie byli w stanie się zalogować i otrzymali od GitHub błąd stwierdzający, że adres URL jest nieprawidłowy. Klienci, którzy już się zalogowali, nie ucierpieli. Problem został rozwiązany i GitHub logowanie działa normalnie. Dziękujemy za cierpliwość, podczas gdy nasz zespół pracował nad wdrożeniem poprawki.
