Автоматизация подписочного сервиса: как я в одиночку держу платный продукт в проде

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

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

Как было в начале: о сбоях я узнавал последним

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

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

Для бизнеса, который ты ведёшь один, это не масштабируется. Нельзя вырасти, если единственный «монитор» сбоев — недовольный пользователь.

Поворот: о сбое я узнаю раньше клиента

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

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

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

Где здесь моя ручная работа — скажу честно, без приукрашивания. Переключение клиента отрабатывает по маршрутам, которые я задал заранее; а вот починить упавший узел или совсем вывести его из ротации — по-прежнему на мне. Разница в том, что теперь я делаю это спокойно, по сигналу мониторинга, пока клиенты уже работают через другой узел, — а не в аврале под шквал жалоб.

Что ещё держится само

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

• Оплата и выдача доступа. Оплата идёт через встроенный платёжный инструмент — клиенту не нужно вводить карту на стороннем сайте. Сразу после оплаты система сама создаёт учётную запись и присылает доступ, без моего участия. Это проверяемый факт архитектуры: оплатил — получил, за секунды. (Если случается редкий технический сбой, система честно пишет клиенту, что доступ откроют вручную, и сигналит мне, — это страховка, а не штатный путь.)

• Срок и автоистечение. Доступ действует ровно оплаченный срок. Когда он заканчивается, закрывается сам по таймеру — мне не нужно вручную отслеживать, у кого что закончилось.

• Напоминания о продлении. За день до окончания и в день истечения клиенту уходит спокойное напоминание с возможностью продлить.

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

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

Что это дало

Главное — жалоб на сбои больше нет. Не потому что сбоев не бывает (они бывают у всех), а потому что в момент сбоя клиент уже переключился на рабочий узел, а я чиню упавший по сигналу мониторинга — раньше, чем кто-то заметил. Клиент остаётся в неведении о проблеме, и это лучший результат, какой может быть.

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

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

Что из этого применимо к вашему бизнесу

За моим случаем стоят всего два принципа, и оба переносятся почти на любой бизнес.

Первый — мониторинг вместо ручного контроля. Если о проблеме у вас узнают от клиента (звонок «почему не работает», жалоба в чате), значит, человек стоит там, где должна стоять система. Везде, где вы узнаёте о сбое последним, можно поставить наблюдение, которое сигналит раньше.

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

Это не чудо и не замена людей роботами. Это перенос предсказуемой рутины на систему, чтобы люди занимались тем, что требует людей. Как устроен мониторинг, который сигналит раньше клиента, я разобрал отдельно. Платежи в подписке (выдача доступа, напоминания и автоистечение) разберу отдельно.

Если у вас есть процесс, где о проблеме узнают последним или где люди вручную делают одно и то же по кругу, — напишите мне, обсудим вашу задачу предметно.