IT + Опыт

Публикую свои мысли и инсайты на тему разработки и бизнеса в моем ТГ-канале, подписывайтесь😉

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

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

Почему это важно, или Истории из жизни

История первая: "Облачный" сюрприз

Представьте ситуацию: вы запустили крутой проект, который неожиданно начал расти. Клиенты идут, деньги капают, вы уже мысленно паркуете 223/Лисян у офиса... И тут бац! Сайт падает под нагрузкой, а техдир в панике пишет в слак: "Нам срочно нужно в облака!". Через месяц вы смотрите на счет от Amazon и понимаете, что придется продать почку. Знакомо?

История вторая: "Как в Netflix!"

Или другая ситуация: вы, начитавшись модных статей про облака и микросервисы, сразу заряжаете проект на AWS. "Как в Netflix!" - говорите вы команде. А через полгода плачете, глядя на счета за сервера, которые используются на 10% своей мощности. Спойлер: Netflix можно, а вам пока нет.

История третья: "Firebase за 100k USD в месяц"

А вот вам реальный кейс из жизни, от которого я тоже охре... удивился.

На Новогодних праздниках ко мне записался на консультацию фаундер одного из стартапов с просьбой переработать уже существующее приложение и показал счет от Google Cloud за Firebase, Storage и еще несколько сервисов от Google на 100k+ USD/месяц.

И это при всего 78 000 MAU (активных пользователей в месяц)!

В чем была проблема? Основные расходы были на облачную бд Google Cloud - Firestore, из-за небольшой ошибки в архитектуре приложения при обновлении списка чатов у пользователя в мессенджере внутри приложения - выполнялось по 50 000 запросов за один раз, у каждого пользователя!

В итоге количество операций чтения в Firestore доходило до 2 МИЛЛИАРДОВ в день, КАРЛ! А количество операций записи в бд — до 1 миллиарда/дейли

Тут должен был быть нудный текст про виды баз данных, особенности подсчета запросов и прочее душнилово, но я вас пожалею)))

У Google ресурсов много, ему не жалко — любой каприз за ваши деньги. А обычный VPS или даже выделенный сервер просто бы лег от такой нагрузки, и это было бы сигналом, что что-то явно не так.

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

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

…В итоге решили вместе с уже клиентом переделать это приложение на использование Supabase — это современная платформа, построенная на основе PostgreSQL, которая отлично подходит для управления данными и упрощает работу с серверной частью. По сути, это такой удобный инструмент, который предоставляет базу данных с API “из коробки”.

Дополнительно выбрали достаточный на данный момент VPS: 8vCPU, 16 ГБ оперативной памяти. Такая конфигурация стоит обойдется около 50 дол. в месяц и спокойно выдерживает до 200 RPS (запросов в секунду), если архитектура проекта нормально оптимизирована.

Благодаря переходу на Supabase и отказу от облачных сервисов удастся:

• сократить ежемесячные расходы более чем в 2000 раз;

• улучшить производительность за счёт правильной настройки базы данных;

• избавиться от скрытых переплат за “удобные” сервисы, которые в итоге оказались просто дорогими.

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

Когда реально нужны облака:

• Когда инвесторы сказали "надо" (и дали денег)

• Когда у вас реально сотни тысяч и миллионы пользователей

• Когда вам позарез нужны их специальные сервисы типа AI или анализа больших данных и то можно подключить их по API например

VPS/VDS: ваш лучший друг на старте

Виртуальный сервер — это как студия в спальном районе. Не так пафосно, зато своё и платежи адекватные. За $10-50 в месяц вы получаете нормальный сервер, который потянет большинство проектов на старте. И да, это не опечатка — реально от 10 баксов.

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

Выделенные серверы: для тех, кто дорос

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

Давайте поговорим про нагрузку, или Почему RPS это не рок-группа

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

Как посчитать RPS:

Формула для расчета:

Количество активных пользователей в час × Среднее количество их действий в минуту) ÷ 60 = Запросы в секунду (RPS)

Например, если у вас 1000 пользователей в час, и каждый делает примерно 5 кликов в минуту, получаем: (1000 × 5) ÷ 60 = 83 запроса в секунду.

Какой сервер вам реально нужен

Для тех, кто только запустился (до 50 RPS):

Вам хватит простого VPS за $10-50 в месяц. Это как первая машина — не Ferrari, но довезёт куда надо. Идеально подойдет для небольшого интернет-магазина или приложения

Для растущих проектов (50-500 RPS):

Пора думать о мощном VPS или выделенном сервере за $50-250. Как раз для популярного маркетплейса или сервиса доставки, который уже нашёл своих клиентов.

Для серьёзных пацанов (500+ RPS):

Тут уже без мощных выделенных серверов, облаков и прочих кубернетисов - никуда. От $150 в месяц, и это только начало. Но если у вас такая нагрузка — скорее всего, вы уже можете себе это позволить.

Как понять, что пора апгрейдиться

Есть несколько верных признаков:

• Время ответа стабильно превышает 200-300 мс

• Появляются ошибки при пиковых нагрузках

• Нагрузка на CPU держится стабильно выше 80%

• Памяти остаётся меньше 20%

Так же если у вас Стартап - не бойтесь что сервер ляжет от нагрузки, во первых до этого нужно еще дорасти, и "переехать" на более мощный сервер не так сложно. А еще хочу поделиться, может, не самым популярным наверное мнением: если сервер лег — значит, вы реально достигли успеха! Ваш проект живет, развивается, привлекает внимание, и это отличный знак! Переезжаем на более крутой сервер и ставим перед собой новую цель — снова “положить” его, разгоняя бизнес дальше!

Про масштабирование, Kubernetes и прочие фентиплюшки — это тема для отдельной статьи.

Реальные тесты на реальном железе

Как мы мучали сервер за 700 рублей

А вот вам реальный кейс из жизни: только что сданный проект приложения с backend частью на Supabase Self Hosted, крутящийся на простеньком VPS за 700 рублей в месяц (2 vCPU, 4GB RAM).

Чтобы не быть голословными, как и всегда при сдаче проекта, мы решили устроить нашему VPS настоящую пытку. Нет, мы не включали ему песни Моргенштерна на repeat — мы использовали Grafana k6 для стресс-тестирования. Если вы не знаете, что это такое, представьте толпу голодных студентов, штурмующих столовку в перерыве между парами. Примерно так же k6 генерирует нагрузку на ваш сервер.

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

Что мы намерили:

• 93.33 RPS (Requests Per Second, а не Рок Против Спида)

• Время ответа 72 мс

• 0 ошибок

И всё это на достаточно сложном, комбинированном запросе к нескольким таблицам в БД — с JOIN'ами и прочими SQL-извращениями. А наш малыш справился!

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

• Оптимизация базы данных

• Правильная настройка кеширования

• Грамотное управление соединениями

• Отсутствие лишних сервисов, которые съедают ресурсы

Финальные мысли, или Как не облажаться

Начинайте с малого. Серьёзно. Нет ничего постыдного в том, чтобы стартовать с простого VPS. Instagram тоже не сразу переехал в облака. Растите постепенно, следите за метриками и не ведитесь на модные словечки вроде "микросервисы", облачная БД и "serverless", пока реально в этом не нуждаетесь.

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

P.S. Тема очень обширная, тут можно целую книгу написать. Если у вас есть вопросы — задавайте в комментариях, постараюсь помочь. Есть экспертиза в Разработке/DevOps/продукте, так что обязательно что-нибудь придумаем.

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

Главное помните: технологии должны помогать бизнесу расти, а не тянуть его на дно необоснованными расходами.

Удачи в развитии ваших проектов!

Генерация иерархии классов и реализация методов. Методы по принципу «возьми из одной таблицы столбцы A, B, C и из второй таблицы столбцы D, E, F, немного по колдуй с математикой и верни объект». Тут тоже в целом все ок. Никаких проблем нет

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

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

Генерация в больших объемах. Понадобился мне скрипт, создающий структуру папок проекта и раскидывающий типовой шаблонный код по файлам проекта. Модель без проблем создала скрипт и сгенерировала шаблонный код. Потом мне понадобилось, чтобы этот же скрипт подготавливал базовые тесты для создаваемых эндпоинтов, и вот тут-то, как говорится, началось. Скрипт преодолел некую отметку по количеству токенов, и качество генерации сильно упало: контроль идентификаторов полетел, начали использоваться имена классов, которые не объявлялись, какие-то классы совсем перестали использоваться. Ничего критичного, но неприятно. В моем случае проблемы начались где-то с отметки 400+ строк bash-кода со вставками Python-кода, который раскидывался по файлам. Да, решение не лучшее, но на тот момент мне оно показалось интересным

Генерация документации. На небольших объемах все идеально. Но стоит превысить те же 400+ строк, но уже в Markdown-разметке, как начинается потеря деталей в описании методов. Описания становятся более короткими и менее информативными. Тоже терпимо, особенно если нужно просто получить заготовку, в которую будешь сам вписывать описания и добавлять новые методы

В целом мне все нравится, особенно учитывая, что я использую явно урезанный бесплатный вариант взаимодействия с моделью через чат. Думаю, через API можно будет увеличить объем контекста и выход модели. Но даже такое дилетантское использование модели позволяет ускорить разработку и переложить всю рутину на ИИ

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

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

Для тех, кто еще думает идти ли в IT в 2025 году, предлагаю посетить мой ТГ-канал. Там вы сможете найти кучу нытья о жизни программиста и кое-какие мысли о том, куда катится IT. Но чувствую, что весь предыдущий контент стремительно теряет релевантность и актуальность. На всякий случай ссылка на канал: https://t.me/it_hat

• проведение количественных исследований

• A/B тесты

• ad-hoc запросы

• построение дешбордов

• внедрение и анализ метрик

• изучение поведения пользователей

• генерация гипотез

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

Продуктовый аналитик помогает ответить на вопросы:

• Почему это сделали?

• Кто и когда это сделал?

• Как это сделали?

Из цифр в инсайты для бизнеса

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

Хочу разобрать все это на конкретном примере! Давайте представим, что мы продуктовые аналитики в компании, которая занимается продажей цветов и у них есть сайт и приложение, в котором есть возможность заказывать букеты. У нас вроде как все хорошо с нашим продуктом, мы куда-то развиваемся, что-то делаем, но пока что непонятно, на что это влияет.

Постановка задачи

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

Окей, задача есть, теперь мы можем приступать к дальнейшим действиям!

Находим исторические данные по исследованиям / уточняем у заказчика

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

• есть ли какие-то предположения, почему у нас мало клиентов доходят до оплаты?

• были ли какие-то исследования воронки до этого / кто может делал какое-то смежное исследование

• были ли какие-то технические сбои?

Здесь я хочу обратить внимание на технические сбои и правильность отображения графиков, потому что может быть так, что у нас просто неправильные данные, а мы уже бьем тревогу, хотя на самом деле все нормально. Уделяйте время проверке данных!

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

Вопрос: "Где хранятся данные?" мы задавать не будем, ведь мы продуктовые аналитики знаем, где они лежат - в БД, поэтому в следующем шаге мы будем исследовать наши данные!

Поиск нужных цифр

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

Посмотрел бы на дополнительные метрики, такие как:

• MAU / DAU / WAU

• ARPPU

• AOV

• NPS, CSAT

• Время, проведенное на странице

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

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

Почему так?

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

В данном случае, что мы можем предположить:

• пользователю непонятно, как проходить воронку

• пользователь не хочет проходит полную воронку, потому что ему что-то не нравится

• пользователь не может пройти полную воронку, потому что его что-то блочит на техническом уровне

• у нас очень много “мусорных” пользователь, у которых нет цели приобрести букет, они просто заходят на сайт, т.е на сайт попадает не та аудитория

• технический сбой в данных

На этом этапе мы также делаем выводы и идеи, как это улучшить. Затем мы переходим к “прожарке” гипотезы.

Валидация идей

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

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

Решение конкретной проблемы

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

И вскоре у нас уже есть готовое решение! Спустя небольшое время, после того, как проблема была пофикшена, мы возвращаемся к данным и видим, что количество пользователей, которые доходят до шага с оплатой начинает по-немногу расти! А это значит, что мы справились с нашей задачей и смогли помочь бизнесу.

Заключение

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

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