Перенос нагрузки из облака: что спросить, прежде чем решиться

Почему этот выбор быстро становится дорогим

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

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

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

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

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

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

Что вы на самом деле переносите

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

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

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

Здесь важны простые целевые показатели. Если база данных умирает, как быстро она должна вернуться? Сколько данных вы можете позволить себе потерять? Если восстановление занимает шесть часов, приемлемо ли это или это серьёзная бизнес‑проблема?

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

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

Проверьте, насколько предсказуем ваш трафик на самом деле

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

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

Начните с нескольких месяцев реального использования. Сравните обычные дни с концом месяца или квартала. Сравните дневной трафик с ночной пакетной обработкой. Посмотрите сезонные колебания — распродажи, ежегодные обновления подписок. Ищите короткие всплески на 10–30 минут: они часто наносят больше вреда, чем длительный монотонный рост.

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

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

Один простой тест поможет: выдержит ли ваша конфигурация пиковую нагрузку, пока одна машина будет недоступна из‑за обновлений или аппаратного сбоя? Если ответ «нет», оценка слишком плотная.

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

Проверьте, кто будет управлять этим каждую неделю

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

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

Сделайте владение явным. Решите, кто устанавливает обновления безопасности и планирует перезагрузки, кто проверяет бэкапы и проводит тесты восстановления, кто реагирует на оповещения по дискам, питанию и сети, и кто меняет железо или открывает тикет у вендора при отказе.

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

Этот пробел имеет цену. Команда, хорошо знакомая с AWS или Google Cloud, всё равно может нуждаться во времени, чтобы изучить прошивки хранилища, настройки BIOS, RAID, конфигурации коммутаторов и инструменты удалённого управления. Учтите это время на обучение в плане, а также более медленную работу в первые месяцы.

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

Если ваша команда не способна решить любую проблему самостоятельно, рано подключать контракты поддержки. Оплата поддержки оборудования, remote hands или частичной помощи ops часто дешевле, чем заставлять небольшую команду разработчиков учиться на ошибках в процессе простоя. Честная расстановка сил для self‑hosted систем важнее оптимистичных расчётов.