Разработка веб-сервиса: от 5 модулей до продакшена

Разработка веб-сервиса отличается от разработки сайта одним: сайт можно сдать, а сервис приходится эксплуатировать. Он живёт, растёт, ломается под нагрузкой и требует, чтобы обновления заезжали на боевой сервер без паники. Я это прошёл на своём продукте — платформе ПКМаркетинг, у которой сейчас больше 13 000 пользователей и гос. IT-аккредитация. Разберу путь от первых модулей до продакшена: что делали в каком порядке и почему именно так.

Сервис начался не с идеи, а с накопленного «жира»

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

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

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

Первое решение: 5 модулей из 50

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

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

Критерий отбора первых модулей был простой и я его до сих пор использую в клиентских проектах:

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

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

Архитектура: за что платят внутри

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

В платформе внутри микросервисы, очереди и кэширование. Объясню человеческим языком, зачем каждое.

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

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

Кэширование — повторный одинаковый запрос отдаётся из памяти, а не считается заново. Это разница между «страница открылась» и «страница думает шесть секунд».

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

Всё это закладывается на старте. Переделывать архитектуру потом дороже, чем сделать сразу с запасом.

Продакшн и CI/CD — до беты, а не после

Момент, который большинство проектов откладывает, а потом получает боль.

Когда сервис парсинга дошёл до состояния «можно показывать», я первым делом поднял отдельный продакшн-сервер и сел за CI/CD-пайплайн. Смысл простой: чтобы изменения сразу залетали на боевой сервер и применялись без боли и страданий.

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

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

Закрытая бета вместо громкого запуска

Дальше — закрытая бета: узкий круг людей, которые реально работают руками в этой области. Не «все желающие», а те, чью рутину сервис должен заменить.

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

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

Что из этого забрать, если вы заказываете веб-сервис

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

Список модулей и их порядок. Не «что должно быть в итоге», а что идёт первым, вторым и третьим, и чем мы уже сможем пользоваться после первого этапа.

Границы первого этапа в письменном виде. Сервис — это то место, где объём растёт по ходу сам собой, если его не зафиксировать.

Инфраструктура в смете отдельной строкой. Сервер, деплой, бэкапы, мониторинг. Это не «накладные расходы», это часть продукта.

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

Кто отвечает за поддержку пользователей. Это отдельная роль и отдельное время, а не «разработчик посмотрит в свободную минуту».

Разработка веб-сервиса — марафон, где выигрывает не тот, кто запустил всё сразу, а тот, у кого после первого месяца работы система не разваливается от каждой правки.

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