Не просто «чинить баги»: как техподдержка помогает приложению расти и экономить деньги владельца

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

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

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

Нельзя починить то, чего не видишь

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

До этого момента команда ориентировалась на логи в консоли. Это примерно как следить за здоровьем по самочувствию: пока не заболело всерьёз — всё нормально. Дашборд — другое дело. Он показывает проблему до того, как о ней напишет первый разозлённый пользователь.

Как фриз на 0,2 секунды убивает конверсию

На графиках сразу стало видно аномалию: несколько запросов к базе данных выполнялись за 10 и более секунд. Это запросы, которые блокировали Event Loop — пока они работали, приложение буквально зависало для всех остальных пользователей в этот момент.

Нашли. Вынесли в отдельный рефакторинг. Переписали логику запросов.

После — цифры изменились кратно:

1. Event Loop Lag (задержка обработки запросов) упала с 0,1–0,2 секунды до менее 0,02 с. Разница в 10 раз. Именно это пользователи ощущают как «отзывчивость» — когда нажал кнопку и сразу что‑то произошло, без паузы.
2. Потребление памяти снизилось с пиковых 700–1000 МБ до стабильных ~300 МБ. Меньше памяти — меньше нагрузки на сервер, меньше риска сбоев при всплесках трафика.
3. Среднее время ответа API не превышает 2 секунд. Единственное исключение — синхронизация товаров с 1С, и это ожидаемо: там идёт большой обмен данными.

Маленькие фичи, которые двигают продукт

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

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

Фото в протоколах. Платформа работает с профессионалами beauty‑индустрии. В разделе протоколов процедур добавили возможность прикреплять до 10 фотографий — техники введения, инструкций, схем. Контент стал содержательнее, а специалисты получили инструмент, который они давно просили.

НДС и ЮКасса. Отдельная история — и отдельная боль для любого бизнеса на российском рынке. Настроили передачу ставки НДС из 1С по каждой товарной позиции при создании онлайн‑заказа. Теперь в фискальном чеке НДС отражается корректно по каждой строке — так, как требует законодательство. Это не опциональная доработка: без неё бизнес работает с риском налоговых нарушений и некорректной фискализации. Настройка потребовала синхронизации между 1С, бэкендом приложения и API ЮКассы — три разные системы, у каждой свои форматы данных. Сделали без изменения бизнес‑логики приложения.

Как выбрать модель поддержки: штат, аутсорс или своя команда

Типичный расчёт владельца продукта: «наймём системного администратора». Средняя зарплата такого специалиста в регионах — от 80 000 рублей, в — от 150 000. Плюс налоги, больничные, онбординг.

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

На практике у владельца продукта есть три основных модели организации поддержки — и у каждой свои сильные стороны и ограничения.

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

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

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

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

Чек‑лист: как понять, что с поддержкой вашего приложения что‑то не так

Три вопроса, которые стоит задать прямо сейчас:

1. Есть ли у вас мониторинг? Не логи в консоли, а именно дашборд — Grafana, Sentry или хотя бы базовый APM. Если нет, вы узнаёте о проблемах от пользователей, а не раньше них.
2. Знаете ли вы среднее время ответа вашего API? Если цифра больше 2–3 секунд — где‑то есть медленный запрос, который тормозит всё остальное.
3. Сколько времени проходит от бага до фикса? Если больше рабочего дня — у вас нет системной поддержки, есть реакция на пожары.

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

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

Что с этим делать прямо сейчас: практические шаги

Кейс FILARAcosmo хорошо иллюстрирует несколько универсальных принципов, которые можно применить к любому работающему продукту.

Сначала измерьте, потом чините. Любое улучшение начинается с понимания текущего состояния. Если у вас нет мониторинга — начните с этого, прежде чем браться за оптимизацию. Grafana + Prometheus — это open source, бесплатный стек, который можно развернуть самостоятельно. Для небольших проектов достаточно базовой настройки за один‑два дня работы.

Переводите технические метрики в бизнес‑язык. Event Loop Lag в 0,2 секунды сам по себе ничего не говорит владельцу продукта. Но если добавить: «при такой задержке конверсия в оформление заказа снижается на X%» — решение об инвестировании в оптимизацию принимается иначе. Попросите вашу команду или подрядчика всегда переводить технические показатели в бизнес‑последствия.

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

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