Ten sam schemat powtórzył się w sierpniu tyle razy, że przestał przypominać zdarzenie. Na stronie statusu pojawia się wpis o podwyższonej liczbie błędów albo obniżonej wydajności, a po jakimś czasie komunikat o rozwiązaniu. Rano 24 sierpnia taki wpis objął okno od 6:50 do 9:36 czasu polskiego, a wraz z nim czat, interfejs programistyczny, Claude Code oraz Cowork. Pojedynczo taka przerwa nie jest tematem. Staje się nim dopiero wtedy, gdy zajrzeć do rejestru, w którym Anthropic odnotowuje awarie Claude i drobniejsze zakłócenia. Wpisów z sierpnia, licząc do 24 dnia miesiąca, jest tam dwadzieścia.
Awaria z 24 sierpnia trafiła dokładnie w początek dnia pracy
Incydent nosi nazwę “Elevated errors for multiple models” i został zamknięty tego samego dnia. Anthropic podał w komunikacie kończącym, że użytkownicy widzieli podwyższoną liczbę błędów od 4:50 do 7:36 czasu uniwersalnego. W Polsce oznacza to okno od 6:50 do 9:36, czyli mniej więcej od pierwszej kawy do rozkręcenia się dnia w większości biur.
Zasięg był szeroki. Ucierpiały cztery usługi naraz: strona claude.ai, interfejs programistyczny, Claude Code oraz Cowork. W pierwszym komunikacie Anthropic wymienił cztery modele: Mythos 5, Fable 5, Opus 5 i Opus 4.8. W kolejnej aktualizacji dodał, że problem obejmował także inne, niewymienione z nazwy modele Claude. Najmocniejszym z tej rodziny jest dziś Claude Opus 5.
Warto od razu ustawić proporcje, bo od tego zależy sens całej reszty. To nie była godzina zero i całkowita niedostępność. Wpis na stronie statusu mówi o zwiększonym odsetku błędów w odpowiedziach, a nie o wyłączeniu usługi. W praktyce oznacza to, że część zapytań wracała z błędem i wymagała ponowienia. Dla kogoś, kto rozmawia z modelem w przeglądarce, to irytacja. Dla procesu, który wysyła zapytania automatycznie i nie ma obsługi ponowień, to zatrzymanie roboty.
Dwadzieścia wpisów w dwadzieścia cztery dni
Liczbę policzyliśmy samodzielnie, z kanału RSS historii incydentów. Metoda jest prosta i każdy może ją powtórzyć. W odczycie z 24 sierpnia kanał zwracał dwadzieścia pięć ostatnich pozycji i sięgał wstecz do 27 lipca, więc całe okno sierpniowe mieściło się w nim z zapasem. Nie było ucięte i nie brakowało w nim początku miesiąca. Warto pamiętać, że kanał jest rotujący, więc przy późniejszym odczycie najstarsza pozycja będzie już inna. Sierpniowe wpisy dają się dzięki temu wypisać co do dnia.
Rozkład jest przy tym mocno nierówny. Wpisy pojawiły się w trzynastu dniach sierpnia, a w jedenastu nie było ich wcale. Miesiąc zaczął się od serii 3, 4 i 5 sierpnia, po czym przyszło sześć dni ciszy. Potem ruszył najdłuższy ciąg: od 12 do 20 sierpnia każdy kolejny dzień ma na stronie statusu przynajmniej jeden wpis. Po nim znów cisza przez 21, 22 i 23 sierpnia, a przerwał ją dopiero poranek 24 sierpnia.
Dziewięć dni z rzędu wymaga jednego zastrzeżenia, bo inaczej liczba brzmi mocniej, niż na to zasługuje. Wpis datowany na 15 sierpnia jest ogonem awarii, która zaczęła się poprzedniego wieczoru. Anthropic podał tam wprost, że wpływ trwał od 20:00 czternastego do 0:11 piętnastego. Licząc według chwili rozpoczęcia, a nie zamknięcia, seria rozpada się na 12-14 i 16-20 sierpnia. Dziewięć kolejnych dni z wpisem to fakt, ale dziewięć osobnych awarii to już nadinterpretacja.
Nie każdy wpis na stronie statusu znaczy to samo
Liczba dwadzieścia jest prawdziwa i jednocześnie myląca, jeśli zostawić ją bez rozbicia. Wpisy dzielą się na bardzo różne zdarzenia i uczciwość wymaga to powiedzieć.
Rozpiętość czasu trwania jest ogromna. Tam, gdzie Anthropic podał konkretne okno wpływu, najkrótsze zajęło dwadzieścia cztery minuty, a najdłuższe cztery godziny i jedenaście minut. Między tymi dwoma punktami mieści się cała reszta. Sumowanie ich w jedną wielkość nie miałoby sensu.
Różny jest też charakter. Większość wpisów opisuje obniżoną wydajność albo podwyższoną liczbę błędów, a nie całkowitą niedostępność usługi. Część dotyczy jednego modelu, część mówi ogólnie o wielu modelach naraz. Żaden sierpniowy komunikat nie stwierdza przy tym awarii wszystkich modeli jednocześnie.
Co najmniej cztery z dwudziestu wpisów w ogóle nie opisują awarii modelu. Jeden dotyczy dostępu do samej strony statusu i błędu certyfikatu. Drugi konektorów do usług Google, przy których Anthropic zaznaczył, że podstawowe funkcje działają dalej. Trzeci logowania przez oAuth, a czwarty Claude Code w przeglądarce wraz z powiązanymi usługami. Do rachunku awarii modelu wchodzą więc tylko formalnie.
Wreszcie zdarzały się dni z kilkoma wpisami naraz. Czwartego sierpnia były trzy, czternastego również trzy. Liczba wpisów nie przekłada się więc na liczbę dni z kłopotami, co jest kolejnym powodem, żeby nie robić z dwudziestki nagłówka samego w sobie.
Czego strona statusu nie mówi i czego z niej nie wyczytamy
Tu trzeba się zatrzymać, bo to najczęściej pomijana część takich zestawień. Strona statusu jest rejestrem zdarzeń, nie ich wyjaśnieniem, i milczy w czterech sprawach naraz.
Przyczyn tam nie ma. W żadnym z dwudziestu wpisów nie pada informacja, co konkretnie zawiodło. Brakuje też analiz powdrożeniowych, które w innych firmach bywają publikowane po większych awariach.
Próżno szukać liczby dotkniętych użytkowników albo zapytań. Ani strona statusu, ani kanał RSS nie podają żadnej takiej wielkości, więc zdanie o tym, ilu osobom coś przestało działać, nie miałoby się tu na czym oprzeć.
Osobną sprawą jest to, czy incydenty mają wspólne źródło. Kuszące byłoby zszycie dwudziestu wpisów w jedną opowieść o infrastrukturze przeciążonej po premierach kolejnych modeli. Byłaby to jednak nasza hipoteza podana jako ustalenie, a Anthropic niczego takiego nie twierdzi.
Zostaje wreszcie pytanie, czy to więcej niż zwykle, i na nie też nie ma odpowiedzi. Kanał RSS obejmuje tylko dwadzieścia pięć pozycji, więc w odczycie z 24 sierpnia lipiec był w nim widoczny dopiero od 27 dnia miesiąca. Porównanie sierpnia z lipcem wymagałoby pełnych danych za oba miesiące. Bez nich każde zdanie o rekordzie byłoby zmyślone. To samo dotyczy porównań z OpenAI czy Google, których stron statusu w tym samym oknie nie czytaliśmy.
Pierwsza Misja AI · Kodożercy
AI bez technikaliów – kurs i certyfikat
Pierwsza Misja AI to kurs Kodożerców dla absolutnych początkujących. Fabuła w konwencji science fiction, gamifikacja, ćwiczenia na żywym modelu, certyfikat na koniec.
Zacznij Pierwszą Misję →
Częstotliwość zmienia rachunek inaczej niż pojedyncza awaria
Pojedynczą przerwę da się przeczekać i właściwie każdy dostawca ma do niej prawo. Kiedy pisaliśmy o dwóch awariach Claude w ciągu jednego dnia pod koniec lipca, sensem tamtego tekstu było samo zdarzenie. Tutaj sens jest inny, bo zmienia się nie skala, tylko rozkład.
Różnica jest praktyczna, nie retoryczna. Awaria raz na kwartał to zdarzenie, na które planuje się zwykły zapas czasu. Wpisy odnotowane w trzynastu z pierwszych dwudziestu czterech dni sierpnia każą zadać inne pytanie niż po pojedynczej przerwie. Trzeba przy tym pamiętać, o czym ten rachunek mówi, a o czym nie. Rejestr pokazuje, jak często dostawca odnotowywał kłopot u siebie, a nie jak często stanął konkretny proces ani jakie było prawdopodobieństwo, że dotknęło to akurat nas. Do planowania i tak jest to jedyna liczba, jaką mamy z pierwszej ręki.
Sedno leży w tym, że dostawca modelu bywa obecnie jedynym punktem, przez który przechodzi cały przepływ. Obsługa zgłoszeń, generowanie opisów produktów, wstępna analiza dokumentów, podpowiedzi w edytorze kodu. Każda z tych rzeczy działa świetnie do momentu, w którym po drugiej stronie rośnie liczba błędów. Wtedy proces bez własnej obsługi błędów po prostu staje. Pisaliśmy już o tym w szerszym ujęciu przy badaniu o ciągłości działania firmy opartej na jednym dostawcy a sierpniowy rejestr daje do tamtej rozmowy konkretny materiał.
Co z tego wynika dla kogoś, kto ma model w procesie
Odpowiedź nie brzmi “uciekać od Anthropica”, bo nie mamy danych, żeby powiedzieć, że gdzie indziej jest lepiej. Brzmi raczej: przestać zakładać, że interfejs programistyczny modelu jest tak samo pewny jak baza danych stojąca we własnej serwerowni.
Trzy rzeczy dają się zrobić bez przebudowy czegokolwiek. Pierwsza to obsługa ponowień z rosnącym odstępem, bo ogranicza ona skutki błędów przejściowych, a właśnie takie opisuje większość sierpniowych wpisów. Druga to rozdzielenie procesów pilnych od tych, które mogą poczekać do wieczora. Okno z 24 sierpnia trwało niecałe trzy godziny, więc zadanie z luźnym terminem miało szansę w ogóle się z nim nie zetknąć. Trzecia to zwykłe logowanie odmów po stronie własnej aplikacji, żeby po fakcie wiedzieć, ile zapytań przepadło, zamiast zgadywać ze strony statusu dostawcy.
Osobno warto zapisać sobie samą stronę statusu jako źródło, do którego się zagląda, a nie tylko klika w panice. Historia incydentów jest jawna i darmowa, a jej przeczytanie zajmuje kilka minut. To tańsza forma badania dostawcy niż czekanie, aż dowiemy się o problemie od klienta.
Podsumowanie
Sierpniowa seria nie jest katastrofą i nie ma sensu jej tak przedstawiać. Awarie Claude i drobniejsze zakłócenia trafiają do jednego rejestru, a odnotowane tam zdarzenia mają bardzo różną wagę, od dwudziestoczterominutowej przerwy po ponad cztery godziny. Większość opisano jako obniżoną wydajność, a nie brak usługi. Jednocześnie nie jest to drobiazg, bo wpisy z trzynastu z pierwszych dwudziestu czterech dni sierpnia to już nie pojedynczy wypadek przy pracy. Przyczyn nie znamy, liczby dotkniętych użytkowników nie znamy i nie da się na tej podstawie powiedzieć, czy u konkurencji wygląda to lepiej. Wiadomo natomiast tyle, że kto oparł działający proces na jednym dostawcy modelu, ten w pierwszych dwudziestu czterech dniach sierpnia miał trzynaście dni z wpisem w rejestrze dostawcy. Co z tego wynika dla planowania pracy bez dostawcy, policzyliśmy osobno w tekście o ciągłości działania firmy opartej na jednym dostawcy.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
