Привет, меня зовут Михаил Шпаков, я руковожу разработкой в Timeweb Cloud — это крупный облачный провайдер с большой командой и множеством внутренних и внешних продуктов.
Последние несколько лет в работе стало больше менеджмента: процессы, планирование, встречи, координация команд. Со временем я начал ловить себя на мысли, что очень хочется что-то поделать руками. Вернуться к коду, попробовать собрать продукт от начала и до конца, пройти путь не как менеджер, а как разработчик и автор идеи. Заодно — погрузиться в продуктовую часть, потрогать всё: интерфейсы, фичи, маркетинг, пользовательский опыт.
Так родился statuser.cloud — простой сервис для мониторинга доступности сайтов и серверов. Я хотел сделать его:
с минималистичным и понятным интерфейсом,
ориентированным в первую очередь на разработчиков, девопсов, админов,
с набором действительно нужных фич, ничего лишнего.
В этой статье я расскажу, как вечерами и на выходных делал 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-проект, и мне по-прежнему нравится заниматься им в свободное время. Такой формат даёт гибкость, позволяет экспериментировать и не перегореть. Но при этом у проекта уже появилась аудитория, и стало понятно, что он может быть полезен не только как личный инструмент, но и как продукт с коммерческой ценностью.
Поэтому в будущем Statuser станет условно-бесплатным сервисом с несколькими тарифами — по модели, близкой к тому, как это реализовано в UptimeRobot.
План такой:
бесплатный тариф останется навсегда — в нём будет всё необходимое для небольших личных и пет-проектов: HTTP-проверки, уведомления, статус инцидентов и другие возможности. В нём можно будет добавить до 10 серверов, этого хватит для большинства базовых сценариев;
платный тариф будет включать расширенные возможности: больше серверов в мониторинге, короткие интервалы мониторинга, диагностика инцидентов и многое другое;
в перспективе, возможно, появятся несколько уровней тарифов — для команд, фрилансеров, бизнеса.
Сейчас Statuser находится в режиме публичного тестирования — все функции доступны бесплатно. Можно подключить свои проекты, посмотреть, как сервис работает на практике, и при желании оставить обратную связь — это очень ценно и поможет мне сделать проект лучше и удобнее для пользователей.
❯ Заключение
Этот проект для меня — возможность оставаться в практике, развивать инженерное мышление и делать что-то полезное своими руками. Он начался как простая идея, и постепенно вырос в полноценный сервис, которым пользуются другие люди. Это вдохновляет продолжать работу.
Если вы прочитали до этого места — спасибо!
Буду рад любым вопросам, обратной связи и идеям. Возможно, вы сталкивались с похожими задачами в мониторинге или запускали свои pet-проекты — расскажите.
И если хочется, чтобы я подробнее раскрыл какую-то часть — стек, архитектуру, процесс разработки или, например, работу с обратной связью — просто напишите в комментариях, обязательно отвечу.
Сервис можно посмотреть и попробовать здесь: statuser.cloud
Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩
