Понятные лимиты использования для общих систем

Почему случайные стены раздражают хороших клиентов

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

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

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

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

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

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

Случайные стены также создают проблемы для поддержки. Люди обращаются в вашу команду не потому, что им действительно нужна дополнительная ёмкость, а потому что им нужно объяснение. Это тревожный сигнал. Хороший лимит должен быть достаточно предсказуем, чтобы пользователи могли объяснить его себе сами.

Справедливые лимиты делают две вещи одновременно. Они защищают систему и показывают клиентам, что на самом деле создаёт нагрузку. Если правило ни того, ни другого не делает, оно больше похоже на ловушку, чем на квоту.

Найдите действия, которые создают большую часть нагрузки

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

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

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

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

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

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

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

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

Ставьте квоты вокруг шумных операций

Правило простое: считайте действие, которое создаёт нагрузку.

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

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

Отделите громкие операции от повседневной работы. Импорты, экспорты, массовые обновления, генерация отчётов, API-рассылающие задачи и фоновые перестроения часто нуждаются в отдельной квоте. Это сохраняет плавность обычного просмотра и редактирования, защищая систему от задач, которые заполняют очереди, нагревают CPU или блокируют базы данных надолго.

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

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

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

Хорошее практическое правило легко запомнить. Повседневные действия должны казаться почти неограниченными. Затратные действия должны считаться ясно, отдельно и так, чтобы пользователи могли прогнозировать их использование.

Как установить квоту

Начните с оценки стоимости, а не с догадок. Измерьте одно действие от первого запроса до последнего фонового шага. Простой клик может вызвать чтение базы, очереди, повторы, генерацию файлов и уведомления. Если учитывать только первый запрос, вы рассчитаете не то.

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

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

Прежде чем фиксировать число, задайте несколько прямых вопросов. Попадает ли действие в хранилище, очереди или внешние API? Создаёт ли один клик больше работы через несколько минут? Будут ли повторы считаться против той же квоты? Может ли нормальная команда достигнуть лимита во время недельного всплеска? Придётся ли поддержке объяснять правило каждый день? Если ответы вызывают сомнения — квота, вероятно, неверно настроена.

Добавьте мягкие предупреждения перед жёсткими блокировками. Показывайте оставшийся ресурс прямо в продукте и предупреждайте до исчерпания. Уведомление на ~70% и ещё одно ближе к лимиту обычно достаточно. Когда кто-то достигает предела, назовите действие, покажите время сброса и предложите следующий разумный вариант.

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

Объясняйте лимит прямо в продукте

Лимит работает лучше, когда люди видят его прямо перед использованием. Если экспорты потребляют намного больше серверного времени, чем обычный просмотр страницы, поместите квоту рядом с кнопкой «Экспорт», а не на странице тарифов или в глубоком разделе справки.

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

Держите текущее использование рядом с действием. Короткая строка под кнопкой часто достаточна: "12 из 20 экспортов использовано в этом месяце" или "Осталось 3 запуска партий сегодня." Это работает лучше, чем общий баннер, потому что отвечает на реальный вопрос: могу ли я сделать это сейчас?

Сообщайте точно, когда счётчик сбрасывается. "Сброс 1 мая" гораздо яснее, чем "ежемесячный лимит". Лучше показать и цикл, и дату. Много запросов в поддержку возникает потому, что пользователи не знают, означает ли "месяц" календарный месяц, платёжный или последние 30 дней.

Используйте формулировки, похожие на обычную речь. "Экспортов осталось в этом месяце" понятнее, чем "остаток месячного допуска операций". "API-вызовов использовано сегодня" — ясно. "Тяжёлых задач осталось на неделе" тоже понятно, если вы заранее определите, что считать тяжёлой задачей.

Короткая причина помогает: "Этот лимит сохраняет общую ёмкость доступной для всех" — достаточно. Длинная политическая заметка рядом с кнопкой обычно только ухудшает ситуацию.

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

Предупреждайте людей перед достижением лимита

Люди легче принимают лимиты, когда продукт даёт им время отреагировать. Тихое предупреждение на 70–80% работает лучше, чем внезапная блокировка на 100%. Команды могут замедлиться, изменить план или запросить больше ресурсов до того, как работа остановится.

Показывайте предупреждение там, где выполняется работа. Если кто-то запускает длительный экспорт, массовый импорт или AI-задачу, держите живой счётчик на экране, чтобы он видел, сколько квоты займёт задача. Домыслы раздражают людей.

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

Для командных аккаунтов важна прозрачность. Админы должны видеть, кто использовал квоту, когда это произошло и какое действие её съело. Это избегает привычной игры в обвинения, где все говорят, что нажимали только один раз.

Когда пользователь всё-таки достигает лимита, формулируйте сообщение спокойно и конкретно. Скажите, что произошло, какое действие его вызвало, когда произойдёт сброс и что можно сделать дальше. "Лимит экспортов достигнут. Ваша команда использовала 50 экспортов сегодня. Следующий сброс: 02:00 UTC. Вы можете поставить этот экспорт в очередь или обратиться к администратору" — лучше, чем просто "Запрос не выполнен."

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

Простой пример из общего приложения

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

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

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

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

Команда продукта исправила квоту — перестала считать просмотры страниц и начала учитывать экспорты. Обычный просмотр остался свободным. Большие экспорты получили понятный месячный лимит.

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

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

Ошибки, которые отпугивают пользователей

Один общий лимит для всех функций выглядит просто, но обычно кажется несправедливым. Открытие дашборда, экспорт 50 000 строк и запуск AI-задачи не стоят системе одинаково. Когда всё делит одну квоту, аккуратные пользователи натыкаются на стену, а тяжёлые операции проходят мимо.

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

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

Предупреждения должны приходить достаточно рано, чтобы помочь. Уведомление на 80% даёт команде время закончить работу, сократить расточительность или попросить более высокий лимит. Уведомление на 100% — это не предупреждение, это экран отказа.

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

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

Люди принимают лимиты, когда правила разумны. Они уходят, когда продукт ведёт себя как слот-машина, где каждая попытка что-то стоит, а никто не видит счётчик.

Быстрые проверки перед запуском

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

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

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

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

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

Что делать дальше

Начните с одной шумной операции. Выберите действие, которое создаёт наибольшую нагрузку или счёт, и сначала поставьте там понятную квоту. Обычно это массовые экспорты, большие импорты и повторяющиеся AI-задачи. Если менять все лимиты одновременно, люди не поймут, что именно решило проблему.

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

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

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

Иногда рост выявляет более глубокие проблемы продукта и инфраструктуры, а не только неудачный счётчик. В такой ситуации полезен внешний ревью. Oleg Sotnikov через oleg.is консультирует стартапы и небольшие компании по архитектуре продукта, затратам инфраструктуры и операциям, ориентированным на AI. Такое ревью особенно полезно, когда обращения в поддержку растут, количество неудачных задач увеличивается или расходы в облаке растут быстрее, чем использование.