/ KONTEKST
Jedna osoba, jeden pipeline, zero zespołu ops
Prowadzę małą firmę z produktami cyfrowymi, w której pipeline agentowy wykonuje większość mechanicznej roboty: research, pisanie, ilustracje, render PDF, publikacja w sklepie, potem posty na pięciu platformach. Przez większość dni działa bez nadzoru. O to właśnie chodzi.
Bez nadzoru dowiadujesz się też, co twój monitoring faktycznie mierzy. W ciągu dwóch tygodni trafiłem na trzy awarie, które technicznie nie miały ze sobą nic wspólnego, a strukturalnie miały wszystko. Opisuję je w kolejności, w jakiej je znalazłem, z takim poziomem szczegółu, jakiego sam bym oczekiwał.
/ AWARIA 01
Plik, który według każdego narzędzia był w porządku
Jeden produkt nie chciał się opublikować na Instagramie. Wszystkie pozostałe przechodziły. Ta asymetria od razu wyklucza dane logowania i uprawnienia, bo one zabijają wszystko albo nic. Problemem musiał być sam plik.
Wideo wyglądało idealnie. Narzędzie do metadanych raportowało poprawny kodek, długość, rozdzielczość i bitrate. Plik pobierał się po HTTPS z kodem 200 i właściwym typem zawartości. Meta przyjęła upload, mieliła go siedemdziesiąt sekund i zwróciła gołe ERROR bez powodu.
Haczyk polega na tym, że narzędzia do metadanych czytają nagłówki. Nagłówki były całe, a właściwe dane klatek to były śmieci, najpewniej z dwóch renderów ścigających się o ten sam plik wyjściowy. Odczyt kontenera nie mówił nic. Zdekodowanie każdej klatki powiedziało wszystko:
ffmpeg -v error -i output.mp4 -f null -Czysty plik nie wypisze nic. Ten uszkodzony wypisał ścianę błędów o nieprawidłowych jednostkach NAL i brakujących obrazach. Warto wiedzieć: YouTube przyjął ten sam plik bez mrugnięcia, bo agresywnie go przekodował i zamaskował uszkodzenie. Jedna platforma bardziej rygorystyczna od innych nie jest platformą upierdliwą. Jest jedyną, która mówi ci prawdę.
Naprawą nie był sam ponowny render. Renderery zapisują teraz do pliku tymczasowego, dekodują go w całości żeby udowodnić że jest poprawny, i dopiero wtedy atomowo przenoszą go na docelowe miejsce. Uszkodzony render nie może już nadpisać dobrego pliku.
/ AWARIA 02
Backup, który po cichu przestał działać
Mój backup offsite chodzi co noc na timerze systemd. Sprawdzenie pokazywało timer aktywny i włączony oraz usługę, która zakończyła się sukcesem. Oba zielone. Najnowszy snapshot w zdalnym repozytorium miał trzy dni.
Co się stało: jednej nocy krok czyszczenia starych snapshotów zawisł na martwym połączeniu do magazynu. Jednostka nie miała limitu czasu startu, więc systemd czekał. W nieskończoność. Timer nie uruchomi usługi, która już się uruchamia, więc każda kolejna noc była po cichu pomijana. Stan jednostki, który odczytywałem, czyli activating (start), nie jest stanem błędu, więc nic w całym systemie nie uznało tego za problem.
Dwie zmiany. Limit czasu startu, żeby zawieszony bieg został ubity zamiast blokować wszystkie następne. I sprawdzanie wieku najnowszego snapshotu zamiast stanu jednostki, bo jednostka odpowiada na pytanie „czy się wykonałem", a pytanie biznesowe brzmi „czy mam świeży backup". To są różne pytania i tylko jedno z nich ma znaczenie w momencie odtwarzania.
/ AWARIA 03
Konto, które zeszło do zera
Ta jest wstydliwa, bo najbardziej zwyczajna. Konto finansujące wszystkie wywołania modeli wyczerpało środki. Każde zadanie zależne od modelu zaczęło padać natychmiast: research, pisanie, krytyka jakości, tłumaczenia. Pipeline był praktycznie martwy przez dwa dni.
To, co widziałem, to jedno powiadomienie dziennie, że zaplanowane zadanie wyszukiwania nisz się nie powiodło. Brzmi dokładnie jak przejściowa czkawka po stronie dostawcy, czyli rzecz, która naprawdę się zdarza i którą nauczyłem się ignorować. Prawdziwy komunikat siedział w stack trace, którego nikt nie wyświetla: twoje saldo kredytów jest zbyt niskie.
Kosztem nie były kredyty. Kosztem były dwa dni, przez które produkcyjny system nie robił nic, a jego dashboard pozostawał zielony, bo awaria płatnicza i niestabilne API wyglądają z zewnątrz identycznie.
Naprawa to przypadek szczególny, który zwraca się natychmiast: przeszukiwanie błędów nieudanych zadań pod kątem markerów rozliczeniowych i podnoszenie osobnego, głośnego alertu, który nazywa dostawcę i linkuje do jego panelu płatności. Raz na dostawcę na dobę, żeby zadanie cykliczne nie zasypało powiadomień. Awarie rozliczeniowe nie są przejściowe i nigdy nie powinny mieć kształtu błędów przejściowych.
/ WZORZEC
Każdy check zadawał złe pytanie
Trzy niepowiązane systemy, jeden kształt. W każdym przypadku coś raportowało sukces, nie produkując niczego użytecznego:
- Enkoder zakończył się kodem zero i zapisał plik, którego nie da się zdekodować.
- Timer był aktywny i nie wyprodukował snapshotu od trzech dni.
- API zwróciło poprawną odpowiedź HTTP, która akurat znaczyła, że konto jest puste.
Każdy mój check mierzył proces. Żaden nie mierzył artefaktu. Kody wyjścia, stany jednostek i kody odpowiedzi opisują maszynerię, a maszyneria potrafi pracować pięknie, nie produkując niczego, co da się wykorzystać.
Stąd zasada, którą stosuję teraz wszędzie: sprawdzaj wynik, nie przebieg. Nie „czy render się skończył", tylko „czy plik się dekoduje". Nie „czy timer jest włączony", tylko „ile ma lat najnowszy snapshot". Nie „czy wywołanie wróciło", tylko „czy wróciło z treścią". Każde z tego kosztuje kilka linii i łapie klasę awarii, na którą dashboardy są strukturalnie ślepe.
/ JEŚLI PRACUJESZ Z AGENTAMI
Autonomia podnosi koszt cichej awarii
To ma większe znaczenie przy agentach niż przy zwykłych usługach, z jednego powodu: nikt nie patrzy. Aplikacja webowa, która się psuje, zostaje zgłoszona przez użytkowników w kilka minut. Pipeline bez nadzoru może nie produkować niczego przez wiele dni, a jedynym świadkiem jest log, którego nikt nie czyta. Autonomia zamienia każdą cichą awarię w długą awarię.
Jeśli masz wynieść z tego jedną rzecz: zajrzyj do własnych health checków i zapytaj przy każdym, czy mógłby przejść w sytuacji, gdy monitorowana rzecz jest kompletnie zepsuta. U mnie odpowiedź brzmiała „tak" trzy razy, a dowiedziałem się o tym tylko dlatego, że platforma obsługująca klientów okazała się bardziej rygorystyczna niż moje własne narzędzia.
