Когда докупить ресурсов дешевле, чем переписывать код

MAATRIX

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

Два пути к одной проблеме

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

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

Путь второй: увеличить ресурсы сервера — добавить RAM, ядра CPU, перейти на более быстрый диск (NVMe вместо SSD), поднять тариф. Это вертикальное масштабирование: тот же сервер, но мощнее. Проблема с производительностью при этом часто исчезает не потому, что она решена, а потому, что железо теперь справляется с неэффективностью с запасом.

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

Что на самом деле стоит время разработчика

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

Составляющие этой стоимости:

• Зарплата и накладные расходы за часы диагностики, профилирования, написания фикса, тестирования и код-ревью. Для нетривиальной проблемы производительности это редко «пара часов» — чаще дни или недели, особенно если баг проявляется только под реальной нагрузкой и не воспроизводится локально.
• Альтернативная стоимость — то, что команда НЕ сделает за это время. Пока разработчик оптимизирует старый модуль, он не делает новую фичу и не двигает роадмап. Для растущего стартапа это часто самая дорогая часть уравнения — время до релиза может стоить больше, чем сама оптимизация.
• Риск регрессии. Переписывание рабочего, пусть и неэффективного кода — это всегда риск сломать что-то смежное. Нужны тесты, staging-окружение, аккуратный rollout — тоже время и тоже деньги, которые редко попадают в изначальную оценку.
• Дефицитность ресурса. Хороших разработчиков, разбирающихся в конкретной части системы, обычно немного, и их время нельзя купить мгновенно — в отличие от вычислительных ресурсов, которые продаются здесь и сейчас.

Здесь важна честность: если задача «найти и убрать один явный N+1-запрос» — это часы, а не недели, и оптимизация почти всегда выигрывает у докупки железа. А вот если речь про «переписать модуль обработки платежей на другую архитектуру» — это принципиально другой порядок затрат, и его нужно оценивать трезво, а не по ощущению «ну переписать — не так уж сложно».

Что на самом деле стоит вертикальное масштабирование

Вторая сторона уравнения выглядит проще, но у неё тоже есть нюансы, которые часто упускают.

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

• Downtime на апгрейд. У большинства провайдеров увеличение CPU/RAM на уже существующем VPS требует перезагрузки, а иногда — миграции на другой физический хост. Для сервиса с жёсткими SLA это тоже стоимость, которую нужно закладывать в окно с минимальной нагрузкой.
• Рост счёта во времени. Разовый апгрейд — это одна цифра, но если нагрузка продолжает расти, а код остаётся неэффективным, счёт будет расти вместе с трафиком, и разовое решение превращается в постоянно растущую статью расходов.
• Эффективность масштабирования не линейна. Удвоение CPU не всегда даёт удвоение полезной пропускной способности — многое зависит от того, упирается ли код в один поток и нет ли блокировок, которые не дают параллелизму раскрыться. Иногда ресурсы просто простаивают, потому что узкое место было не в CPU, а, например, в дисковых операциях.
• Архитектурный потолок. Вертикальное масштабирование упирается в физические лимиты конкретной конфигурации — максимум CPU и RAM, которые вообще можно поставить на тариф или физический хост.

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

Простая методика сравнения

Чтобы не спорить на эмоциях, полезно свести оба варианта к одним единицам — деньгам за период (например, за квартал) — и сравнить напрямую.

Формула для стоимости оптимизации:

Стоимость_оптимизации = (часы_разработки × стоимость_часа_разработчика)
                       + альтернативная_стоимость_отложенных_задач
                       + стоимость_риска_регрессии

Формула для стоимости докупки ресурсов:

Стоимость_докупки = (новый_тариф − текущий_тариф) × количество_месяцев_до_следующего_решения
                   + стоимость_простоя_на_апгрейд

Дальше — сравнение на понятном горизонте, например на 3-6 месяцев вперёд, а не «навсегда», потому что нагрузка продолжит расти и переменные изменятся.

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

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

Когда докупка ресурсов — правильный выбор

Есть набор ситуаций, где вертикальное масштабирование — не откладывание проблемы, а обоснованное решение:

• Дедлайн жёстче, чем объём работы по оптимизации. Запуск через неделю, а рефакторинг требует месяц — докупка ресурсов не альтернатива оптимизации, а единственный способ пережить пиковую нагрузку без деградации сервиса.
• Нагрузка временная или сезонная. Распродажа, рекламная кампания, всплеск трафика после публикации в СМИ — под такие пики почти всегда дешевле временно поднять тариф, чем переписывать архитектуру ради нагрузки на несколько дней.
• Команда маленькая, а фронт задач большой. Если у вас один-два разработчика и очередь задач, которые двигают бизнес, время команды объективно дороже и дефицитнее, чем разница в цене между тарифами.
• Проблема ещё не локализована. Прежде чем переписывать код, нужно понять, что именно тормозит, — а профилирование само требует времени. Докупка ресурсов снимает остроту, не мешая расследованию.
• Запас всё равно нужен по другим причинам — вы и так планировали рост базы пользователей, и апгрейд не разовая заплатка, а часть заранее спланированной ёмкости.

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

Где проходит потолок вертикального масштабирования

Честность методики требует признать: докупка ресурсов не может продолжаться бесконечно, и важно заранее понимать, где у неё заканчивается запас прочности.

Физический предел конфигурации. У любого тарифа или любого физического сервера есть максимум CPU-ядер, RAM и производительности диска, который вообще можно на него поставить. Когда вы упираетесь в этот потолок, следующий шаг — либо переезд на более мощный выделенный сервер (что тоже не бесконечно), либо горизонтальное масштабирование (несколько серверов вместо одного более мощного), либо всё-таки оптимизация кода. Дальше расти вертикально уже некуда.

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

Неэффективный код никуда не девается. Докупка ресурсов маскирует симптом, а не лечит причину. Если в основе проблемы лежит, например, алгоритм с квадратичной сложностью, то при достаточном росте объёма данных никакое количество RAM и CPU не спасёт — квадратичный рост обгонит любое линейное увеличение мощности сервера. В какой-то момент кривая роста нагрузки и кривая роста стоимости ресурсов расходятся так, что оптимизация становится не желательной, а обязательной.

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

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

Как не превращать временное решение в постоянную переплату

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

Фиксируйте, что именно и почему докуплено. Заведите короткую запись (issue, заметку в трекере) с датой, тарифом до и после и гипотезой, какой код стоит за проблемой. Без этого через полгода никто не вспомнит, что апгрейд был временной мерой, а не осознанным ростом.

Мониторьте утилизацию, а не только факт «стало лучше». Если после апгрейда CPU и RAM снова упираются в потолок через пару недель — проблема не в объёме ресурсов, а в их использовании. Базовый мониторинг метрик сервера (загрузка CPU, память, IO диска) показывает тренд, а не только факт падения.

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

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

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