Как я по вечерам разрабатывал Statuser — платформу для мониторинга доступности приложений
В этой статье Михаил Шпаков, руководитель разработки в Timeweb Cloud, рассказывает, как вечерами и в выходные он делал Statuser (и продолжает делать): с какими проблемами сталкивался, как выбирал стек, как не бросил проект на полпути — и что получилось в итоге.
Привет, меня зовут Михаил Шпаков, я руковожу разработкой в Timeweb Cloud — это крупный облачный провайдер с большой командой и множеством внутренних и внешних продуктов.
За 8 лет в IT я прошел путь от инженера до руководителя команды разработки. Мы с командой построили с нуля инфраструктуру, где более 40 сервисов — от виртуальных машин до управляемых Kubernetes-кластеров и баз данных. За почти 4 года команда разработки выросла с 3 до 30 человек, а платформа стала одним из лидеров среди IaaS-решений в России — с десятками тысяч пользователей и устойчивой репутацией в сообществе.
Последние несколько лет в работе стало больше менеджмента: процессы, планирование, встречи, координация команд. Со временем я начал ловить себя на мысли, что очень хочется что-то поделать руками. Вернуться к коду, попробовать собрать продукт от начала и до конца, пройти путь не как менеджер, а как разработчик и автор идеи. Заодно — погрузиться в продуктовую часть, потрогать всё: интерфейсы, фичи, маркетинг, пользовательский опыт.
Так родился statuser.cloud — простой сервис для мониторинга доступности сайтов и серверов. Я хотел сделать его:
- с минималистичным и понятным интерфейсом;
- ориентированным в первую очередь на разработчиков, девопсов, админов;
- с набором действительно нужных фич, ничего лишнего.
В этой статье я расскажу, как по вечерам собрал продукт, который сегодня помогает десяткам команд мониторить доступность сервисов: какие ошибки допустил, как развивал функциональность, что сработало — а что нет.
Идея проекта и первые шаги
Я довольно быстро определился с тем, что именно хочу сделать. Мониторинг — тема мне близкая: и по работе в облаке, и по личному опыту. Падения, медленные отклики, истекшие 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.
Внутри инцидента можно посмотреть таймлайн событий, оставить комментарий или постмортум — удобно, если сервисом пользуется команда и нужно зафиксировать, что случилось и почему.
Появилась и еженедельная рассылка отчетов — каждый понедельник на почту и в телеграм приходят результаты мониторинга за прошлую неделю с расчётом SLA по каждому ресурсу. Это удобно для анализа стабильности сервисов в динамике.
Большинство новых фич появляются по запросам пользователей или из моего собственного видения рынка и болей, с которыми я сам сталкивался. Но иногда просто хочется отвлечься и сделать что-то «для души» — так, например, появился 2FA через TOTP — он не критичен, но добавляет безопасность и его просто захотелось реализовать.
Что происходит сейчас
Statuser развивается без платного продвижения: никакой рекламы, партнерок или PR. Всё органически — кто-то находит через поиск, кто-то приходит по ссылке в чате, кто-то делится с коллегами. На момент публикации в сервисе зарегистрировано 418 аккаунтов, из них 326 активно используют мониторинг, подключив хотя бы один ресурс. Всего система отслеживает 1075 сайтов, API и серверов.
Каждый день Statuser выполняет около миллиона проверок. Архитектура с самого начала строилась с прицелом на стабильность: проверка — лёгкая, распределённая, и сервис даже не «замечает» этот объем. Всё работает предсказуемо, без узких мест — и это отдельный повод для внутренней гордости.
Пользователи — очень разные. Кто-то мониторит pet-проекты и Telegram-ботов, кто-то следит за корпоративными сайтами и API. Есть небольшие продуктовые команды, есть фрилансеры, есть инфраструктурщики, которым важно просто «знать, что всё работает».
Фидбек приходит постепенно. Кто-то просто пишет «спасибо», кто-то даёт идеи. Один из первых клиентов сказал:
Ребята, спасибо вам за ваш сервис. Он действительно удобный и полностью закрывает потребности в мониторинге сайтов.
Пока масштаб скромный, но сервис уже закрывает реальные боли: позволяет вовремя узнавать о сбоях, экономит время и убирает рутину из мониторинга.
Сложности и ошибки
Когда делаешь проект один — без команды, бюджета и жестких сроков — сложностей хватает. Главное испытание не в технологиях, а в выносливости: нужно уметь удерживать мотивацию, распределять силы и не перегореть на полпути.
Statuser я развиваю вечерами и по выходным. Звучит просто, но на практике это один из самых трудных аспектов. По будням я фуллтайм в Timeweb Cloud — команда, процессы, принятие решений. После насыщенного рабочего дня не всегда получается переключиться в режим «инди-разработчика». Иногда всё идёт легко, и ты в потоке. А иногда — просто хочется закрыть ноутбук и отключиться от всего.
Бывало, что начинал писать фичу в 22:30, залипал на баге и засыпал в полтретьего — зная, что утром всё равно надо быть на стендапе. На выходных тоже не всегда просто: выбраться с семьей или доделать очередную настройку мониторинга? В какой-то момент понял, что начинаю выгорать — хотел успеть всё, но терял кайф.
Перестроился: перестал ставить себе жесткие цели, стал планировать задачи покороче — на 30–60 минут. Даже одна строчка кода — это движение вперёд. Такой темп оказался более устойчивым: он не мешает работе и даёт возможность не терять интерес к проекту. Statuser не обязан расти каждый день — но он обязательно должен оставаться для меня интересным.
Когда у Statuser появилось около 50 первых пользователей, я впервые почувствовал, что проект начинает «жить своей жизнью». И как это обычно бывает — первый серьёзный факап не заставил себя ждать.
Однажды произошёл сбой в логике проверок, и сервис начал массово слать уведомления — в Telegram и на email. На момент, когда я понял, что что-то пошло не так и остановил рассылку, уже ушло больше 800 сообщений. Люди начали писать, кто-то отключал проверки, кто-то просто молчал — но я отлично понял, как важно контролировать такие сценарии.
После этого я серьёзно переработал систему оповещений: добавил защиту от массовых срабатываний, ввёл лимиты и интервалы между нотификациями. Одновременно усилил логику проверок, чтобы сбой в одной локации не приводил к ложной тревоге по всем регионам.
Это был неприятный, но полезный урок. В продакшене может случиться всё что угодно, и если ты делаешь инструмент, на который кто-то уже начинает полагаться — нужно думать о надёжности с самого начала.
Что дальше?
Я продолжаю развивать Statuser — добавляю новую функциональность, улучшаю интерфейс и стараюсь сделать сервис максимально полезным для тех, кто работает с инфраструктурой, сайтами и продакшеном. Хочется не только писать код, но и рассказывать о проекте: делиться опытом, выходить на профильные площадки, писать статьи и просто быть в диалоге с сообществом.
В ближайшее время появятся несколько новых крупных функций:
- Создание собственных статус-страниц — с возможностью объединять серверы в группы, настраивать индексацию в поисковиках, ограничивать доступ по паролю, включать вайт-лейблинг и многое другое. Первая версия уже готова примерно на 60%.
- Публичное API — чтобы можно было автоматизировать управление мониторингом.
- Появится Passkey для входа, а также двухфакторная авторизация через Telegram и email, просто потому что мне самому нравится этим пользоваться.
Сейчас Statuser — это pet-проект, и мне по-прежнему нравится заниматься им в свободное время. Такой формат даёт гибкость, позволяет экспериментировать и не перегореть. Но при этом у проекта уже появилась аудитория, и стало понятно, что он может быть полезен не только как личный инструмент, но и как продукт с коммерческой ценностью.
Поэтому в будущем Statuser станет условно-бесплатным сервисом с несколькими тарифами — по модели, близкой к тому, как это реализовано в UptimeRobot.
Сейчас Statuser — это pet-проект, и мне по-прежнему нравится заниматься им в свободное время. Такой формат даёт гибкость, позволяет экспериментировать и не перегореть. Но при этом у проекта уже появилась аудитория, и стало понятно, что он может быть полезен не только как личный инструмент, но и как продукт с коммерческой ценностью.
План такой:
- бесплатный тариф останется навсегда — в нём будет всё необходимое для небольших личных и пет-проектов: HTTP-проверки, уведомления, статус инцидентов и другие возможности. В нём можно будет добавить до 10 серверов, этого хватит для большинства базовых сценариев;
- платный тариф будет включать расширенные возможности: больше серверов в мониторинге, короткие интервалы мониторинга, диагностика инцидентов и многое другое;
- в перспективе, возможно, появятся несколько уровней тарифов — для команд, фрилансеров, бизнеса.
Сейчас Statuser находится в режиме публичного тестирования — все функции доступны бесплатно. Можно подключить свои проекты, посмотреть, как сервис работает на практике, и при желании оставить обратную связь — это очень ценно и поможет мне сделать проект лучше и удобнее для пользователей
Заключение
Этот проект для меня — возможность оставаться в практике, развивать инженерное мышление и делать что-то полезное своими руками. Он начался как простая идея, и постепенно вырос в полноценный сервис, которым пользуются другие люди. Это вдохновляет продолжать работу.
Если вы прочитали до этого места — спасибо!
Буду рад любым вопросам, обратной связи и идеям. Возможно, вы сталкивались с похожими задачами в мониторинге или запускали свои pet-проекты — расскажите.
И если хочется, чтобы я подробнее раскрыл какую-то часть — стек, архитектуру, процесс разработки или, например, работу с обратной связью — просто напишите в комментариях, обязательно отвечу.
Сервис можно посмотреть и попробовать здесь: statuser.cloud.
Подписывайтесь на наш vc-блог — так вы ничего не пропустите, ведь впереди вас ждёт ещё много полезных и интересных публикаций.
Чтобы идти в ногу со временем и даже быть немного впереди, присмотритесь к нашим сервисам, решениям и инструментам.
Размещайте и запускайте свои проекты в облаке — будущее уже здесь!