Дашборд, собранный с ИИ, доведён до состояния, когда на него можно положиться
Владелец собрал внутренний дашборд аналитики отзывов сам, с помощью ИИ. Инструмент прижился: им ежедневно пользовался отдел. Дальше нужно было понять, можно ли на нём строить работу — и что чинить в первую очередь. За 8 рабочих дней: аудит, 27 устранённых дефектов, авторизация с нуля, 287 автотестов там, где не было ни одного, — и перестроенный обмен данными между дашбордом, базой и конвейером сбора.
Прототип, который перерос сам себя
Приложение собрал сам владелец — с помощью ИИ, без инженерного опыта. И собрал удачно: инструмент закрывал реальную задачу, прижился и стал частью ежедневной работы отдела. Отзывы с маркетплейсов собирались автоматически, размечались по типу проблемы и превращались в задачи для ответственных.
Ровно поэтому и возник вопрос: на инструменте уже держится процесс — можно ли на него полагаться дальше? Заказчик задал его до первого серьёзного сбоя, а не после. Это редкость: обычно инженера зовут, когда данные уже потеряны.
27 дефектов, из них 6 критических
- –Восемь точек, открытых на запись из интернета без какой-либо проверки: изменить данные мог кто угодно, кто знал адрес.
- –Записи терялись молча. Интерфейс показывал «сохранено», а данные до хранилища не доходили — сбой только писался в лог.
- –Правки уходили в чужие задачи: строка адресовалась по порядковому номеру, а он менялся при сортировке.
- –Автоматический конвейер затирал ручные решения сотрудников при каждом запуске.
- –Дашборд жил в стороне от базы данных: показывал цифры из таблицы-снимка, хотя свежие данные уже лежали в хранилище. Люди принимали решения по картине прошлого месяца.
- –Настройки на сервере не применялись: код их загрузки лежал в блоке, который выполняется только при локальном запуске. Приложение молча работало на значениях по умолчанию.
- –Проверка работоспособности опрашивала соседнее приложение на другом порту — и по его ответу перезапускала наше.
- –Ни одного автотеста. Любое изменение проверялось руками.
От разбора к рабочей системе
- ✓Авторизация с нуля: три роли и разграничение доступа ко всем точкам входа. Проверка не даёт добавить новый адрес, не назначив ему уровень доступа.
- ✓Запись с подтверждением вместо «отправил и забыл»: повторные попытки при сбое и честная ошибка вместо ложного «сохранено».
- ✓Постоянные идентификаторы задач вместо адресации по номеру строки.
- ✓Три системы сведены в один контур. Дашборд, база данных и конвейер сбора работали порознь. Решения сотрудников перенесены в базу — в отдельные поля, которых ИИ-классификация не касается; конвейер научился пересобирать задачу из исправленных данных, не обращаясь к платной модели повторно; дашборд получил прямой доступ к базе с минимально необходимыми правами. Теперь решение человека переживает любой прогон автоматики, а цифры на экране — живые.
- ✓Достроено то, чего не хватало в работе: групповая правка — отметить несколько отзывов и перенести в нужный отдел одной кнопкой; управление пользователями с мгновенным отключением уволенного; аналитика качества в разрезе поставщиков; пометка задач, потерявших актуальность; индикатор заполнения таблицы, у которой есть жёсткий предел.
- ✓287 автотестов, и каждый проверен на способность падать: тест, который не умеет краснеть, ничего не доказывает.
- ✓Восстановлена документация: техническое описание, журнал изменений, инструкция по развёртыванию и откату — ничего этого не было.
На чём собрано
Что изменилось
- →27 дефектов найдено и устранено, из них 6 критических.
- →0 → 287 автотестов.
- →8 → 0 точек, открытых на запись из интернета.
- →Самопроизвольные перезапуски каждые 3 минуты → ноль.
- →Восстановление после обрыва связи с внешним сервисом: 50 минут вручную → секунды автоматически.
- →Первая загрузка 25 → 12 секунд, повторная — доли секунды.
- →Заполненность ключевого поля в задачах 9,7% → 100%; корректных оценок 35% → 100%.
- →Контроль просрочки не срабатывал ни разу за всё время — после починки сразу выявил сотни просроченных задач.
- →Решения сотрудников больше не затираются автоматикой, а дашборд показывает живые данные, а не снимок прошлого месяца.
- →Перенос данных в новую схему — без единого расхождения на десятках тысяч записей.
Порядок работы
Система внутренняя, доступ закрыт — показываю схему процесса.
Сначала понять, что происходит и чем рискуем, — потом чинить. Порядок работ определял аудит, а не догадки.
Почему этому можно верить
Работает в продакшене, ежедневно используется сотрудниками компании; доступ закрыт — внутренняя система. Все изменения проходили независимую проверку: тесты писались от требований, а не от готового кода, и каждый проверялся на способность обнаружить поломку. Часть задач осознанно вынесена в бэклог и передана заказчику вместе с описанием — работа не выдаётся за законченную там, где она не закончена.
Как это можно повторить у вас
У вас похожая ситуация?
Напишите в Telegram или на email — разберём, чем собрано ваше приложение, кто им пользуется и что стоит проверить в первую очередь.