От 10 к 100 пользователям: что ломается первым и почему это почти никогда не сервер

MAATRIX

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

Почему сервер почти всегда выдерживает этот скачок

Стоит сразу закрыть вопрос с инфраструктурой, чтобы не возвращаться к нему как к главной теме. Сто активных пользователей — это, за редкими исключениями (тяжёлые ML-инференсы, обработка видео, real-time с постоянными сокет-соединениями на каждого), нагрузка в единицы-десятки запросов в минуту на типичном веб-сервисе. Один процесс на бэкенде, одна база PostgreSQL или MySQL в контейнере, один nginx перед ними — эта связка без всякого тюнинга обслуживает такой поток без заметной просадки. Разница между 10 и 100 пользователями для сервера ощущается примерно как разница между «почти простаивает» и «слегка занят», а не как «упирается в потолок».

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

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

Поддержка: от личной переписки к системе обработки обращений

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

При ста пользователях эта иллюзия рушится быстро:

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

Закрывать это стоит не тяжёлой helpdesk-системой с SLA и очередями приоритетов — это оверинжиниринг для сотни пользователей, симметричный тревоге про сервер. Достаточно минимальной структуры: каждое обращение получает номер и статус, история хранится в одном месте. Рабочий вариант, который поднимается за вечер, — Telegram-бот с тикетами: разобран целиком, с архитектурой и кодом, в статье про бота поддержки клиентов с тикетами. Идея простая:

Клиент пишет боту → создаётся тикет с номером
  → сообщение пересылается в группу операторов (с меткой тикета)
  → оператор отвечает реплаем → бот пересылает ответ клиенту
  → вся переписка и статусы — в одной таблице базы данных

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

UX: то, что прощали десять энтузиастов, не простят сто обычных пользователей

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

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

Типичные места, где это проявляется впервые:

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

Edge cases: баги, которые «никто не встречал», потому что их некому было встретить

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

Характерные категории таких edge cases на раннем этапе:

• Гонки при повторном клике. Пользователь дважды нажал «Оплатить» или «Отправить», потому что кнопка не заблокировалась и не показала индикатор загрузки — создаётся два заказа вместо одного. При десяти внимательных пользователях это могло не случиться ни разу. При ста — случается почти неизбежно: у кого-то будет медленный интернет и он нажмёт повторно из нетерпения.
• Необычные, но валидные данные. Имя с дефисом или апострофом, email с плюсом (user+test@example.com), номер телефона в нестандартном формате, эмодзи в свободном текстовом поле — редкость у первых доверенных пользователей, но норма для случайной сотни.
• Часовые пояса и локали. Если часть новых пользователей не из того региона, что первые десять, всплывают баги с датами: «событие завтра» показывается как вчерашнее.
• Параллельные действия с одной сущностью. Два пользователя одновременно редактируют один объект (общий документ, комментарий) — при десяти такое совпадение почти невозможно физически, при ста рано или поздно случится.
• Устаревшее состояние в UI. Пользователь открыл вкладку утром, что-то поменялось на сервере за день, вечером он действует поверх устаревших данных — конфликт, которого не было, пока все были синхронизированы вручную, через личное общение с основателем.

Честная рекомендация — не пытаться закрыть все мыслимые edge cases заранее, это бесконечная работа на таком масштабе. Продуктивнее — как только баг проявился хотя бы раз, не списывать его на «редкий случай, само пройдёт», а фиксировать: что произошло, воспроизводится ли, сколько пользователей могло затронуть. На этом масштабе достаточно примитивного баг-трекера (таблица или доска в Trello/Notion) — без записи повторяющиеся частные случаи выглядят как разрозненные жалобы, а не как один системный баг.

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

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

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

• Дубликаты пользователей или заказов. Человек зарегистрировался дважды с разными email, забыв пароль. Или заказ создался дважды из-за той самой гонки при повторном клике из предыдущего раздела.
• Несогласованный ввод. Название страны один раз вписано как «Россия», другой — как «РФ», третий — как «Russia», потому что поле было текстовым, а не выпадающим списком, и пока записей было немного, никто не следил за единообразием.
• Пустые или мусорные значения там, где ожидались реальные данные. Поле «телефон» заполнено как «-» или «нет», потому что оно было обязательным, а номера под рукой не было, — тест на скорую руку стал постоянной записью в базе.
• Устаревшие связи между таблицами. Пользователь удалил аккаунт, но его записи в связанных таблицах остались с битой ссылкой, потому что каскадное удаление никогда не тестировалось — просто не было случая.

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

-- Ищем email, встречающиеся больше одного раза
SELECT email, COUNT(*) AS cnt
FROM users
GROUP BY LOWER(TRIM(email))
HAVING COUNT(*) > 1
ORDER BY cnt DESC;

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

-- Простейшая защита от будущих дублей на уровне базы,
-- а не только на уровне формы регистрации
ALTER TABLE users ADD CONSTRAINT users_email_unique UNIQUE (LOWER(email));

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

Куда действительно стоит смотреть на этом масштабе

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

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

Частые вопросы