Всем привет, я Михаил Шпаков, руковожу отделом разработки. Захотелось поработать над каким-то проектом для души. В результате родилась платформа Statuser.

В этой статье я расскажу, как вечерами и на выходных делал Statuser (и продолжаю делать): с какими проблемами сталкивался, как выбирал стек, как не бросил проект на полпути — и что получилось в итоге.

Последние несколько лет в работе стало больше менеджмента: процессы, планирование, встречи, координация команд. Со временем я начал ловить себя на мысли, что очень хочется что-то поделать руками. Вернуться к коду, попробовать собрать продукт от начала и до конца, пройти путь не как менеджер, а как разработчик и автор идеи. Заодно — погрузиться в продуктовую часть, потрогать всё: интерфейсы, фичи, маркетинг, пользовательский опыт.

Так родился простой сервис для мониторинга доступности сайтов и серверов. Я хотел сделать его:

• с минималистичным и понятным интерфейсом;

• ориентированным в первую очередь на разработчиков, девопсов, админов;

• с набором действительно нужных фич, ничего лишнего.

❯ Идея проекта и первые шаги

Я довольно быстро определился с тем, что именно хочу сделать. Мониторинг — тема мне близкая: и по работе в облаке, и по личному опыту. Падения, медленные отклики, истёкшие SSL-сертификаты, забытые домены — всё это встречал в жизни не раз. Хотелось иметь простой и надёжный инструмент, который работает «из коробки», не требует заморочек и настройки Prometheus + Grafana + alertmanager, и понятен сразу.

На рынке таких решений много. Среди самых известных — UptimeRobot, Pingdom, BetterStack. Они полезны, и каждый по-своему хорош, именно благодаря им у меня сформировался свой вижн: я хотел собрать инструмент, который:

• максимально простой и лаконичный — чтобы даже человек без технической подготовки мог разобраться;

• при этом — удобный и функциональный для разработчиков, девопсов и админов — тех, кто работает с продакшеном каждый день;

• визуально приятный и быстрый;

• делает немного, но делает это хорошо.

В приоритете были:

• простота запуска, без конфигурационных YAML-джунглей;

• максимальная наглядность: статус виден сразу, без лишних графиков и переключений;

• фокус на разработчиков и админов, которые хотят видеть, жив ли сайт или API, и быстро понять, что пошло не так.

Я начал с минимального функционала: одна проверка по HTTP. Сервис каждую минуту отправлял запрос и, если сайт недоступен, слал письмо на указанный емейл. Это уже было полезно — я подключил несколько своих доменов и убедился, что всё работает.

Первую версию — простое приложение с базовой логикой — я собрал буквально за пару дней, используя NestJS на бэке и Next.js на фронте. Использовал ChatGPT для генерации шаблонов кода, моделей, простых обработчиков — и это сильно ускорило старт.

Когда появилась необходимость как-то управлять проверками, стал набрасывать простую админку. Захотелось: добавить новую проверку, отредактировать, отключить. Но быстро понял, что нужна уже настоящая панель управления, с аккаунтами, входом, настройками и нормальным интерфейсом.

Так минимальная идея постепенно начала обрастать логикой, интерфейсами и дополнительными фичами. Всё это делалось по вечерам и выходным — без дедлайнов, но с удовольствием.

❯ Функциональность: как Statuser развивался и становился удобнее

Я запустил проект в декабре 2024 года. Сначала Statuser просто «тихо жил» — я подключил свои проекты, наблюдал за метриками, отлаживал систему. Но довольно быстро начали появляться первые реальные пользователи: кто-то приходил из поисковиков, кто-то по прямым ссылкам, которые я отправлял своим друзьям и знакомым. Люди пробовали сервис, подключали свои сайты, и, что особенно приятно — начинали задавать вопросы. Где посмотреть статистику за месяц? А можно уведомления в Telegram-группу? А как насчёт ping или проверки порта?

Так появилась первая настоящая обратная связь — сигнал, что продукт кому-то нужен. Стало ясно, что нужно двигаться дальше: развивать функциональность, давать больше гибкости, расширять возможности настроек. Вопросы пользователей стали естественным роадмапом, и я начал добавлять фичи — по мере приоритетов и доступного времени. Это стало хорошим двигателем развития.

Сначала появилась возможность отправлять уведомления не только на email, но и в Telegram — как в личные чаты, так и в группы. Это сильно улучшило скорость реакции и сделало сервис удобнее для команд.

Потом начал расширять сами типы проверок:

• добавил ping и опрос TCP-портов;

• возможность выбрать HTTP-метод (GET, POST, HEAD и др.);

• задать заголовки и тело запроса — удобно для проверки API;

• настроить таймаут;

• отключить следование за 3xx-редиректами, если это важно для логики проверки.

Отдельно добавился блок контроля SSL-сертификатов и доменов. Сервис сам следит за сроком действия и присылает уведомления заранее:

— по SSL за 14, 7, 3 и 1 день до окончания,

— по домену — за 30, 14, 7, 3 и 1 день.

Это помогает избежать тех самых «вдруг всё упало из-за просроченного сертификата», которые случаются неожиданно, но регулярно. Или ситуации вроде: «домен оказался не продлён, сайт теперь уводит на парковку с рекламой» — и ты узнаёшь об этом не первым, а после клиента.

Каждую недоступность я стал оформлять в отдельный инцидент — с полной диагностикой из всех регионов, откуда шли проверки. В карточке инцидента в зависимости от типа проверки отображаются:

• код ошибки;

• тайминг запроса от curl;

• зарезолвленные IP;

• результаты выполнения mtr, traceroute и nmap;

• SSL-сертификат, полученный через openssl;

• скриншот страницы;

• заголовки и тело ответа HTTP.

Внутри инцидента можно посмотреть таймлайн событий, оставить комментарий или постмортум — удобно, если сервисом пользуется команда и нужно зафиксировать, что случилось и почему.

❯ Технологии, стек и архитектура

Когда стало понятно, что сервис будет расти, я решил подойти к нему как к настоящему продукту — с нормальным бэкендом, фронтендом, базой, деплоем и инфраструктурой.

Я на запуске выбрал те технологии, которые, с одной стороны, были мне хорошо знакомы, а с другой — позволяли быстро двигаться и без лишних затрат запускать фичи. Хотелось сфокусироваться на продукте, а не тратить время на борьбу с конфигурацией или непривычным стеком. Поэтому получился баланс между удобством разработки, гибкостью и возможностью масштабирования в будущем.

Для бэкенда — NestJS. Удобный, хорошо масштабируемый фреймворк с архитектурой, которая мне близка: контроллеры, DTO, модули, строгая структура.

Для фронтенда — Next.js. Он позволяет быстро собирать современные интерфейсы, поддерживает SSR, тёмную/светлую тему, роутинг, статику — всё, что нужно для продакшена.

Компоненты собирал на ShadCN — они аккуратные, легко настраиваются и визуально мне очень нравятся. Без перегруза, со здравыми дефолтами, и при этом остаётся возможность быстро их подстроить под нужды интерфейса. Отличный вариант, когда хочется быстро собрать удобный UI без кастомизации на старте.

Я давно работаю в облаке и, естественно, для проекта тоже выбрал облачную инфраструктуру — это удобно, надёжно и позволяет сосредоточиться на продукте.

• Приложение развёрнуто в Kubernetes: фронтенд и бэкенд оформлены как отдельные деплойменты, у каждого — свои поды, конфигурации и переменные окружения.

• Снаружи доступен только один балансировщик — он обслуживает домен, автоматически выпускает и обновляет SSL-сертификаты и направляет трафик в Ingress кластера.

• Все внутренние сервисы общаются по приватной сети, наружу не торчит ничего, кроме самого балансировщика.

• Доступ ограничен через облачный Firewall — чтобы лишнего не светилось.

• База данных — PostgreSQL в облаке. Проверки выполняются каждую минуту, и данных со временем становится всё больше: нужно хранить как текущие статусы, так и полную историю — для графиков, отчётов, анализа инцидентов. Облачная база берёт на себя бэкапы, мониторинг и отказоустойчивость, но я дополнительно настроил ежедневные резервные копии на S3 — потому что, как показывает опыт, бэкапов много не бывает.

• S3 используется для хранения бэкапов и артефактов: результатов проверок в инцидентах, пользовательских аватарок, статических файлов.

• Для отправки писем — обычный облачный SMTP-сервис. Просто, стабильно и без лишних забот.

Для проверок из разных регионов я написал отдельного агента, который развёртывается на VDS в нужной географии. Он выполняет проверки и отправляет результаты в основной сервис по HTTP. Агент упакован в Docker, благодаря чему легко масштабируется и позволяет быстро запускать инстансы в новых локациях — сейчас это Москва, Амстердам и Алматы.

На каждой VDS настроено несколько IP-адресов, чтобы снизить вероятность блокировок со стороны проверяемых ресурсов. Конфигурация агента унифицирована: все настройки хранятся в Git, что упрощает развёртывание, обновление и поддержку.

Процессы сборки и выката я сразу автоматизировал. Использую GitHub Actions: настроен пайплайн, который по тегу собирает контейнер, пушит его в реестр и деплоит в кластер или на VDS с агентом. Это удобно, предсказуемо и даёт гибкость — можно легко разносить staging и production, запускать preview-версии и тестировать отдельные фичи из веток.

❯ Что дальше?

Я продолжаю развивать Statuser — добавляю новую функциональность, улучшаю интерфейс и стараюсь сделать сервис максимально полезным для тех, кто работает с инфраструктурой, сайтами и продакшеном. Хочется не только писать код, но и рассказывать о проекте: делиться опытом, выходить на профильные площадки, писать статьи и просто быть в диалоге с сообществом.

В ближайшее время появятся несколько новых крупных функций:

• Создание собственных статус-страниц — с возможностью объединять серверы в группы, настраивать индексацию в поисковиках, ограничивать доступ по паролю, включать вайт-лейблинг и многое другое. Первая версия уже готова примерно на 60%.

• Публичное API — чтобы можно было автоматизировать управление мониторингом.

• Появится Passkey для входа, а также двухфакторная авторизация через Telegram и email, просто потому что мне самому нравится этим пользоваться.

Сейчас Statuser — это pet-проект, и мне по-прежнему нравится заниматься им в свободное время. Такой формат даёт гибкость, позволяет экспериментировать и не перегореть. Но при этом у проекта уже появилась аудитория, и стало понятно, что он может быть полезен не только как личный инструмент, но и как продукт с коммерческой ценностью.

План такой:

• бесплатный тариф останется навсегда — в нём будет всё необходимое для небольших личных и пет-проектов: HTTP-проверки, уведомления, статус инцидентов и другие возможности. В нём можно будет добавить до 10 серверов, этого хватит для большинства базовых сценариев;

• платный тариф будет включать расширенные возможности: больше серверов в мониторинге, короткие интервалы мониторинга, диагностика инцидентов и многое другое;

• в перспективе, возможно, появятся несколько уровней тарифов — для команд, фрилансеров, бизнеса.

❯ Заключение

Этот проект для меня — возможность оставаться в практике, развивать инженерное мышление и делать что-то полезное своими руками. Он начался как простая идея, и постепенно вырос в полноценный сервис, которым пользуются другие люди. Это вдохновляет продолжать работу.

Если вы прочитали до этого места — спасибо!

Буду рад любым вопросам, обратной связи и идеям. Возможно, вы сталкивались с похожими задачами в мониторинге или запускали свои pet-проекты — расскажите.

И если хочется, чтобы я подробнее раскрыл какую-то часть — стек, архитектуру, процесс разработки или, например, работу с обратной связью — просто напишите в комментариях, обязательно отвечу.

А сервер для мониторинга можно взять у нас в Timeweb Cloud :)

За последние годы многие компании и даже целые отрасли перевели свои процессы в цифру. Ритейл, как одна из наиболее перспективных сфер, обладает огромным потенциалом для внедрения современных технологий. Традиционные методы контроля и анализа постепенно уступают место решениям на базе искусственного интеллекта. Как именно ИИ меняет ритейл, какие задачи он уже решает и какие перспективы открывает?

Рынок ИИ в ритейле

Согласно данным Mordor Intelligence, в 2024 году мировой объем рынка технологий искусственного интеллекта в ритейле достиг порядка $9,65 млрд, к 2029 году он возрастет до $38,92 млрд.

В России интерес к ИИ также растёт. По данным СберИндекса, объёмы розничной торговли увеличились на 15% за год, несмотря на рост издержек по всей цепочке поставок. Это создаёт спрос на инструменты, которые помогают повысить управляемость и снизить потери. ИИ всё чаще становится таким помощником.

Архитектура ИИ-систем в магазинах

Искусственный интеллект в ритейле применяется для оптимизации различных процессов, от улучшения взаимодействия с клиентами до повышения эффективности бизнес-операций и управленческих решений.

Системы мониторинга в ритейле строятся на базе данных, полученных с объекта. Одним из основных источников информации — это камеры видеонаблюдения. С их помощью технологии компьютерного зрения позволяют решать широкий круг задач: от контроля сотрудников и анализа очередей до мониторинга целевой аудитории и построения тепловых карт маршрутов покупателей.

Например, тепловые карты позволяют визуализировать поведение клиентов — где они чаще останавливаются, какие зоны обходят стороной, где проводят больше времени. Это помогает понять востребованность товарных полок и эффективность планировки торгового пространства.

Контроль работы сотрудников

Искусственный интеллект помогает отслеживать эффективность и производительность персонала. Системы компьютерного зрения фиксируют, насколько качественно сотрудники выполняют свои обязанности, например, правильно ли они выкладывают товары и своевременно ли обслуживают клиентов. Это позволяет выявлять области для улучшения и повышать общий уровень клиентоориентированности.

ИИ способен различать сотрудников и клиентов с помощью обучения на униформу или использования специальных меток. После определения типа человека (сотрудник или покупатель) система отслеживает действия. При определении работника магазина ИИ-решение может классифицировать, например, такие действия, как: выкладка товара, помощь покупателям, установка ценников, нахождение в определённой зоне без активности. Это позволяет собирать объективную статистику по качеству и интенсивности работы персонала.

Для повышения точности в систему могут дополнительно встраиваться модули анализа движения для увеличения количества классов различаемых действий.

Один из кейсов применения такой технологии — распознавание разницы между активной работой сотрудника и использованием телефона в личных целях.

Интеграция с кассовыми и аудиосистемами

В дополнение к данным ИИ использует другие источники информации:

• данные с чеков и кассовых аппаратов позволяют определить, какие товары наиболее востребованы и из чего состоит структура покупательской корзины;

• аудиоданные применяются для оценки работы кассиров, в частности — соблюдение регламентов и скриптов продаж (например, предлагаются ли карты лояльности, упоминаются ли акции);

• RFID-метки, прикреплённые к дорогостоящим товарам, отслеживают их перемещение и предотвращают фрод (кражи);

Однако в этом направлении компании действуют осторожно: видео– и аудиомониторинг требует строгого соблюдения законодательства и этики.

Противодействие мошенничеству и контроль на кассах

Системы компьютерного зрения и машинного обучения анализируют видеопотоки с камер наблюдения, распознавая необычные действия посетителей и сотрудников.

Такие алгоритмы могут фиксировать:

• попытки спрятать товар, не оплатив его;

• подозрительное поведение, например, длительное нахождение в одной зоне без явной цели;

• резкие движения, которые могут свидетельствовать о краже;

• манипуляции с упаковками или антикражными метками.

При обнаружении аномальных действий система отправляет сигнал сотрудникам службы безопасности, позволяя им быстро реагировать. В некоторых случаях ИИ интегрируется с POS-терминалами, анализируя соответствие чека и фактически вынесенных товаров.

Такие технологии уже активно используются в крупных торговых сетях, помогая снижать потери и обеспечивать безопасность магазинов.

Особое внимание уделяется зонам самообслуживания, где часто происходят попытки краж. Камеры с широким углом обзора устанавливаются так, чтобы отслеживать действия рук покупателя — пробивает ли он товар, корректно ли перемещает его на весы и кладёт ли в пакет тот самый продукт, который пробил. Это позволяет выявлять распространённые нарушения, связанные с подменой товаров или обходом весового контроля.

Контроль качества товара с помощью компьютерного зрения

Помимо мониторинга персонала ИИ-агенты расширяют аналитические сценарии на оценку качества и соответствия товара. На приёмке и выкладке используются нейросетевые модели, способные:

• считать и проверять ценники — детектировать наличие, правильность привязки и актуальность ценников к позиции.

• классифицировать состояние продукции — отличать спелые и вялые фрукты, выявлять брак или повреждения упаковки.

• контролировать полноту выкладки — сравнивать фактическое размещение товара с эталонной выкладкой и своевременно сигнализировать о недостаче.

Приватность и соответствие законодательству

В России с недавних пор действует жёсткий регламент на работу с биометрическими данными: сбор и хранение отпечатков пальцев, распознавание лиц или голос возможны только при прямом согласии сотрудников и обязательной регистрации в уполномоченных органах. В ответ на это большинство компаний в ритейле переходит на другие способы идентификации. Например, мы разработали систему небиометрической идентификации через невидимые маркеры. Подобные решения позволяют контролировать рабочие процессы и передвижения персонала, не нарушая законодательства и защищая права сотрудников.

Как ИИ-технологии работают в ритейле: процесс сбора и анализа данных

Процесс сбора и анализа данных включает три основных этапа:

1. Сбор данных. На этом этапе определяется пул источников: уже установленные или дополнительные камеры (общего вида и широкоугольные для зон самообслуживания, точечные над кассами), направленные микрофоны для контроля регламентов общения с посетителями, данные с POS-терминалов и учётных систем (1С и др.). Все источники данных, используемые для обучения модели ИИ, должны соответствовать ряду важных требований. Во-первых, обеспечивать одномоментность — то есть фиксировать события с точными и согласованными временными метками, что необходимо для корректного анализа последовательностей и временных взаимосвязей. Во-вторых, поддерживать постоянное обновление — данные должны поступать в реальном или близком к реальному времени, особенно если модель планируется применять в динамичных бизнес-процессах. И, наконец, источники должны отличаться высокой надёжностью: быть доступны круглосуточно, обеспечивать стабильную передачу и хранение данных без потерь и сбоев, что критично для качества ИИ-системы.

2. Анализ информации. На втором этапе платформа объединяет поступающие видеозаписи, звук и данные продаж, чтобы автоматически выделить в них ключевые события и аномалии. Система «видит» и классифицирует действия сотрудников и одновременно «слушает» зал, отмечая важные фразы даже в условиях повышенного уровня шума. Параллельно проверяется, совпадают ли данные с касс и складского учёта с тем, что показывают камеры: есть ли расхождения в продажах или остатках. Если выявляются подозрительные или нерабочие моменты, например отсутствие ценников — платформа автоматически формирует уведомление и структурированный отчёт. В результате магазин получает готовую картину работы по ключевым показателям без ручного просмотра часов видео и таблиц.

3. Обработка и отчетность. Агрегированные выводы по всем источникам данных сохраняются в системе и визуализируются в дашборде. Менеджмент получает оперативную сводку по ключевым метрикам и имеет возможность посмотреть данные как в реальном времени, так и за выбранный период.

Эффекты от внедрения и влияние на бизнес-процессы

Основной эффект от внедрения ИИ в ритейле — это повышение прозрачности процессов. Бизнес получает доступ к объективной информации о том, как работает персонал, какие зоны магазина наиболее загружены, и где возможны потери. Особенно это важно для оценки KPI, ротации персонала и принятия решений по премированию.

Системы также позволяют уточнять профиль покупателей, определять пол и возраст аудитории, анализировать поведенческие паттерны. Это помогает не только в планировке торгового пространства, но и в персонализации маркетинга.

По данным опроса, проведенного Nvidia, ритейлеры отмечают ряд значительных преимуществ от внедрения нейросетей в свою работу. Среди главных эффектов — снижение операционных расходов: у 28% компаний они сократились на 5–15%, а у 23% — более чем на 15%. Кроме того, 28% опрошенных зафиксировали рост выручки в пределах 5–15%, а 15% сообщили об увеличении доходов свыше 15%.

Что сложно автоматизировать, и куда движется рынок

Несмотря на успехи, остаются задачи, которые ИИ пока решает неидеально. Например, определение факта кражи требует комплексного анализа — только видео недостаточно. Необходимо сопоставление данных с кассы, движения покупателя и товарного учёта. Также ИИ не всегда может корректно интерпретировать сложное социальное поведение, особенно в нестандартных ситуациях. Система может фиксировать, что товар взят с полки, но не пробит. Однако покупатель мог просто временно отложить его или не дойти до кассы.

Тем не менее рынок развивается. В ближайшие годы можно ожидать появления решений, способных не только фиксировать события, но и предсказывать их: например, автоматическое прогнозирование пиков нагрузки, адаптация выкладки под спрос, автономное управление персоналом в реальном времени.
Больше про ИИ пишу здесь

ИИ в ритейле — это уже не эксперимент, а рабочий инструмент. Его внедрение требует системного подхода, но при правильной реализации он даёт бизнесу ощутимые результаты. Современные решения позволяют ритейлерам контролировать процессы, сокращать потери и повышать эффективность без прямого давления на персонал. ИИ становится не надзором, а помощником — и это главное изменение, которое он приносит в индустрию.

Нам часто пишут пользователи, которые хотят мониторить качество каналов связи — не просто проверять “доступен ли хост”, а действительно оценивать стабильность сети и реагировать на деградации. Один из таких пользователей недавно подключил мониторинг для нескольких регионов, и его запрос дал нам полезный импульс для доработок.

Рассказываем, какие улучшения появились в RMON.

Ping стал умнее

Раньше проверка ping в RMON отправляла один пакет — это было достаточно для грубой оценки, но плохо отражало реальное состояние канала. Теперь всё иначе:

• Можно указать количество ICMP-пакетов в настройках проверки.

• Система собирает и отображает:

  • min RTT

  • max RTT

  • avg

  • mean

Это особенно полезно, если канал нестабилен: одиночный ping может случайно показать “всё хорошо”, хотя на деле теряются пакеты или резко плавает задержка.

| Возможность | SmokePing | RMON |

|-----------------------------|----------------|---------------------------|

| Графики RTT и потерь | ✅ Да | ✅ Да |

| Группировка алертов | ❌ Нет | ✅ Да |

| Настраиваемое кол-во пакетов| ✅ Частично | ✅ Да |

| Интерактивный веб-интерфейс | ❌ (CGI) | ✅ Современный UI |

| MTR из разных регионов | ❌ Нет | ✅ Да |

| Проверки из нескольких точек| ❌ (1 сервер) | ✅ Геораспределённые агенты |

| Telegram/Slack уведомления | Только через внешние скрипты | ✅ Встроено |

| API | ❌ Ограничен | ✅ Полноценный REST API |

SmokePing — отличный инструмент для исторического анализа задержек. Но он устарел в архитектуре, плохо масштабируется по регионам и требует обвесов для алертов.

RMON же изначально создавался с упором на:

• простую установку;

• удобный интерфейс;

• встроенные нотификации и API;

• и главное — распределённый мониторинг из разных географий.

Группировка алертов

Пользователи с несколькими агентами в разных регионах сталкивались с таким сценарием:

"Падает один хост — и мы получаем 5+ одинаковых алертов от каждого региона".

Теперь алерты по одному хосту автоматически агрегируются:

• Вы получаете единое уведомление со списком всех регионов, где обнаружена проблема.

• Упрощается логирование, снижается "шум" в системах алертинга (Telegram, Slack и т.п.)

MTR на месте

Мы добавили возможность запускать MTR (traceroute с расширенной статистикой) из конкретного региона:

• Прямо из веб-интерфейса или API

• Можно быстро проверить маршрут от нужного агента до целевого хоста

Это особенно удобно при отладке проблем между регионами, в CDN, или при работе с провайдером.

Что дальше

Мы продолжаем развивать RMON как инструмент для распределённого мониторинга, ориентированный на:

• телеметрию от агентов из разных регионов;

• гибкую конфигурацию проверок;

• удобную интеграцию с Telegram, Slack, Prometheus, Zabbix и другими системами.

Если вы хотите точно знать, где и когда у вас реально деградирует сеть — попробуйте RMON: https://rmon.io